ARM-Processor Toolchains Accelerate Safety-Critical Compliance

With designers increasingly turning to ARM processors for safety-related applications spanning medical, transportation, avionics and industrial segments, the software that runs upon these processors has come under ever-tighter scrutiny as even the slightest error can have disastrous consequences.

 

To avoid these consequences, safety standards such as IEC 61508, and recent derivatives like ISO 26262 for automotive, provide guidance to reassure developers and customers that the software meets state-of-the-art best practices.

 

That said, determining which elements of the standards apply, justifying which ones do not, and then ensuring that the entire design is actually in compliance can be both daunting and time-consuming. Time is a luxury as fast-design-cycle consumer-level devices become increasingly integrated with the automobile’s safety systems, thereby putting added pressure on developers to adapt to meet the narrowing design-cycle windows.

 

Fortunately, tool-chain suppliers are uniquely positioned to support all safety-related software developers as they have a level of information and knowledge about the software development tools and their operation that the typical software developer doesn’t have.

 

This is particularly true with respect to compilers, which can directly impact the safety of a system and can possibly inject errors that may or may not be detected during subsequent functional design testing. As such, it behooves developers using ARM-based processors to look closely at what tool-chain vendors may have to offer to both ensure standards compliance while adapting to increasing time-to-market pressure.

 

 

ARM proliferation

 

Riding the mobile tsunami, and supported by an expanding ecosystem, ARM-based processors have found applications from smartphones and embedded devices at the edge, through to infrastructure equipment and data servers. Now designers are pulling them into safety-critical applications.

 

These applications include industrial (motor control, factory automation, remote monitoring); automotive (chassis control, body and safety, dashboard, intelligent sensors, engine control, antilock braking); medical (infusion pumps, pacemakers, patient monitoring); railway (signaling and communications control); nuclear (control panels, motor control, system monitoring) and avionics.

 

 

The widespread adoption has been driven by a need for more intelligence across systems, in general, but also by the need for integration and flexibility to lower cost and provide for more features and updates on the fly. Also, many functions that once used hard-coded logic to provide a set number of functions are now being consolidated into 32-bit microcontrollers being controlled by software, thereby creating a whole new problem set.

 

This migration toward microcontrollers and programmability pushes safety into the software domain, putting the onus upon developers of software for safety-critical applications to comply with IEC 61508. This standard, which originally governed functional safety for electrical and/or electronic (E/E) systems, now covers programmable electronic elements (E/E/PE) too, in recognition of the increasing application of computing elements in safety-critical systems.

 

 

Functional safety provides assurance that a safety-related system responds correctly to its inputs to ensure freedom from unnecessary risk or injury, either directly or indirectly.

 

As the language in IEC 61508 is vague, industry-specific standards were derived, such as EN50126/8/9 for rail transport, IEC 60601 for medical devices, IEC 60880 for nuclear power and ISO 26262 for road vehicles. The latter, ISO 26262, specifically covers safety-related systems implemented in mass production passenger cars with a maximum gross vehicle mass up to 3,500 kg. It excludes coverage of unique E/E systems in special-purpose vehicles such as vehicles designed for drivers with disabilities.

 

It’s not uncommon to find 150 microcontrollers in the standard automobile, and with consumer-oriented navigation systems now being integrated with driver assistance, motion-detection systems, propulsion, in-vehicle dynamics control and active and passive safety systems, automotive is a case study in how computing devices are moving into safety-critical systems.

 

Automotive is also tip of the spear with regard to the increasing pressure on developers of safety-critical systems to adapt to design cycles more in tune with consumer devices (12 to 18 months) versus long-life-cycles of anywhere from three to ten years.

 

With these 150 microcontrollers, all running some kind of software routine, something as basic as a compiler can set a system up for failure, simply by injecting a hard-to-find error that may or may not be detected during functional testing.

 

This is always a risk, but compliance IEC 61508, combined with ISO 26262, can reduce the risk to a tolerable level. IEC 61508 best practices, for example, advise the use of trusted tools at the outset.

 

However, compilers are considered offline support tools of classification T3, meaning they can directly or indirectly impact the executable code with the safety-related system. As such, their selection “shall be justified.” [IEC 61508-3 Section 7.4.4.3]

 

This justification can be come about through proven in-use evidence showing tool maturity and stability, as well as third-party assessment from an industry expert, and vendor collateral.

 

Best practices also extend to validating the output as well as the use of language subsets, such as MISRA C/C++. Testing the software that will run on a target is of course critical, but how do you know you’ve tested every possible scenario? After all, code that doesn’t execute can’t be tested. That’s where code coverage analysis kicks in to identify code that has not been executed, thereby helping to ensure you have thoroughly tested your application. Code coverage can be analyzed using source-code instrumentation or using trace data, noting that streaming trace is least intrusive.

 

With regard to language subsets, in many cases, high-level programming languages are incompletely, or ambiguously specified, resulting in different behavior from different compilers.

 

‘Strict mode’ and language subsets such as MISRA C/C++ are designed to remove these ambiguities, while at the same time: ensuring that the language used is consistent with the standard language; specifying rules for undefined behaviour; removing the option for tool-less use; enforcing consistent coding styles (e.g. /*…*/ versus //); improving readability; and reducing the overall scope of testing required.

 

ISO 26262 goes further than IEC 61508 by providing a more detailed framework within which safety-related systems based on other technologies can be considered. It goes all the way from life-cycle management to relationships with suppliers, but for software developers, it provides automotive-specific risk-based approach to determine integrity levels, called Automotive Safety Integrity Levels (ASILs).

 

It uses ASILs to specify applicable requirements of ISO 26262 so as to avoid unreasonable residual risk and also provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved.

 

Advice: Comply by default

 

The good news is that designs that began after ISO 26262 was published don’t necessarily have to comply with its guidelines to show ‘state of the art’ design practices for legal protection. However, smart companies are mandating compliance across the board as culturally it is general good practice and ensures consistency, but also to reduce costs, as what isn’t required one day, may well be required the next. Best to have it institutionalized from day one.

 

Yet compliance with both IEC 61508 and ISO 26262 requires documentation at every step, from justification of offline tool use, to tool behavior, manuals, hazards analysis, compiler defect reports, version histories, test reports, and reports on discrepancies between actual and expected results, just to mention a few.

 

This documentation is labor intensive, time consuming and costly, which is where tool-chain providers come in. They are experts in the tools. For example, they know how the compilers work and what not to use for safety-critical applications, as well as how to use it to get a determined output for safety-related development.

 

A case in point is the ARM Compiler toolchain, which was recently certified by TÜV SÜD, the Germany based authority on safety. This certification enables customers to apply the ARM Compiler build tools for safety-related development up to Safety Integrity Level 3 (SIL3, IEC 61508) and Automotive SILD (ASILD, ISO 26262) without further qualification activities. Augmenting the TÜV certification is the ARM Compiler Qualification Kit, which provides a Safety Manual, Defect Report, Test Report and Development process report as supporting data.

 

 

 

 

Such third-party certification and supporting vendor collateral can immediately eliminate literally man-months of time, effort, and associated costs, while also getting a product or design to market more quickly, and possibly guarantee the next design win in applications where fast design cycles mean timing is everything. To learn more about ARM’s solutions for safety-related software development, visit http://www.keil.com/safety or http://ds.arm.com/solutions/safety.