Meeting the embedded requirements of high-integrity systems

by Anders Holmberg and Margareta Eriksson Hoerling, IAR Systems

Embedded systems are often found in complex safety-related products that place high demands on system integrity; in such cases, any malfunction could cause serious injury to people, equipment or the environment or even a person’s death. Some obvious examples can be found in the automotive industry, in aviation and in medical devices, but safety-critical applications also exist in nuclear power plants, public transportation and infrastructure and less obvious areas such as the chemical processing industry and even surveillance systems.

Figure 1: For safety-critical embedded systems such as those found in automotive or aviation applications, there can be no tolerance for errors that might be caused by poorly designed or documented software.

Ensuring that embedded systems will meet the stringent requirements of such applications presents a real challenge to the developer. Hardware components of a system, whether safety-critical or not, are often tested rigorously—and must generally comply with extensive regulations—but what does it take to confirm that the software parts of a system really are reliable? There are several aspects to this:

The development process and project management (i.e. design documentation, test documentation)
Requirements by authorities such as FDA and FAA in the US and their counterparts in other countries
Industry standards such as MISRA C and IEC 61508
Development tools such as compilers and real-time operating systems

This article will focus on this last item, and will discuss how development tools such as IAR Embedded Workbench and IAR visualSTATE can be used to ensure high integrity in embedded systems.

State machines in high-integrity systems

The International Electrotechnical Commission (IEC), formed in 1906, is the leading international standards organization for electrical and electronic technologies. Standards published by IEC typically become national standards all over the world.

IEC 61508 is the standard for functional safety, where safety is assessed according to four different levels, called Safety Integrity Levels (SIL). Part 3 of the standard is called ‘Software Requirements’, and covers the requirements for a software quality management system and for a software safety lifecycle, and also for functional safety assessment.

One of the explicit recommendations in IEC 61508 is the use of state machines as a design method to meet Safety Integrity Level 3 (SIL3) and above for event-driven systems. The aim is to express a specification unambiguously and consistently, so that some classes of mistakes and omissions can be detected.

IAR visualSTATE is a design tool that is based on state machines, and is particularly suited for high-integrity applications since it can also generate code from the design specification, thus eliminating a common source of manual translation errors. In addition the advanced verification engine can prove the absence or presence of certain properties directly on the specification level.

Figure 2: One of the explicit recommendations in IEC 61508 is the use of state machines, as employed in IAR visualSTATE, as a design method to meet Safety Integrity Level 3 (SIL3) and above for event-driven systems.

Validation and verification of high-integrity systems

The more complex a system is, the more difficult testing becomes. Particularly in an event-driven system, the number of possible combinations of inputs and preconditions simply grows too vast. Instead of manual testing, engineers must depend on tools that can test the logic and the behavior of the system.

IAR visualSTATE can help—both by analyzing test coverage on states, transitions and input/output, and by assisting in the creation of test vectors for complex state combinations. Furthermore it features a mathematical proof engine that can perform formal model checking to find unwanted dead-ends and unreachable states and transitions in a design.

RTOS

Many manufacturers of high-integrity products or safety-critical systems use their in-house real-time operating systems. However there are time-saving and cost-efficient alternatives available commercially. The process of certifying a product or system is a great deal more convenient if the RTOS involved is already certified, and therefore has all the required documentation in place to prove its feasibility.

Two examples of well tested and field-proven RTOSes for high-integrity systems are µC/OS-II from Micrium—which can be found in everything from medical devices to avionics—and the SCIOPTA RTOS, which has a long-standing association with high-integrity applications. The SCIOPTA pre-emptive multi-tasking high performance real-time kernel includes many built-in safety features that make it particularly suited to high integrity operation, including direct message passing. SCIOPTA is currently in the final stages of certification by TÜV, the international technical service and certification company, to the IEC 61508 standard at SIL3, a qualification that makes it an even more attractive option for developing high-integrity applications.

ISO/ANSI C

For programmers, testers and code reviewers alike it is extremely important that the code they are working on has the exact meaning and semantics that would be expected from familiarity with the ISO/ANSI C standard language definition. Using a compiler that deviates from the standard not only means that time will be wasted trying to figure out exactly why the code is behaving strangely, but there is also the very real possibility that the developer will not even be aware that there are problems in the generated code until it is far too late to rectify them.

An equally important decision is to use a compiler where the implementation defined and undefined behavior according to the language standard is documented by the compiler vendor. In the rare circumstances where it might be a good idea to rely on implementation defined behavior, it will be much better if the code behavior is documented as this will give the user more confidence that it will behave as expected. If the compiler vendor is not documenting these corner cases, one cannot rely on the behavior of the generated code, if for example optimizations are turned on or the compiler version needs to be upgraded.

MISRA C

In addition to supporting ISO/ANSI C, the compilers from IAR Systems also support MISRA C. This is a software development standard produced by the Motor Industry Software Reliability Association, first introduced in 1998. The current edition (known as MISRA C:2004) was published in 2004.

The main purpose of the MISRA standard is to help achieve code that is safe, unambiguous, does not unnecessarily rely on implementation defined behavior, and is easily portable between different target architectures.

MISRA-C:2004 contains 141 rules, of which 121 are compulsory and the remaining 20 are advisory. The MISRA C checker is completely integrated with IAR C/C++ Compiler. The user can control from IAR Embedded Workbench which MISRA C rules are checked; the settings will be used for both the compiler and the linker.

The implementation of the MISRA C rules does not affect code generation, and has no significant effect on the performance of IAR Embedded Workbench. The compiler and linker only generate error messages, they do not actually prevent anyone from breaking the rules they are checking for. Individual rules can be enabled or disabled for the entire project or at file level. A log is produced at compile and link time, and this is displayed in the Build Message window of the IAR Embedded Workbench IDE as well as being saved to a file, as described in the IAR Embedded Workbench User Guide. A message, containing a reference to the relevant rule, is generated for every deviation from a required or advisory MISRA C rule, unless this feature has been disabled it.

Although MISRA C was developed by and for the automotive industry, its overall purpose—to facilitate code safety, portability and reliability in the context of embedded systems, specifically those systems programmed in ISO C—makes MISRA C a useful standard in other industries as well.

Validated tool chain

When working with high-integrity projects, it is preferable, or sometimes even a firm requirement, that only tool chains that can be trusted to perform according to specification are used. For a compiler tool chain this is especially important, since it can be very costly to find out late in a project that the selected tool chain does not fully conform to, for example, the C language standard.

To assess the standard conformance, performance and usability of IAR Systems tools, they are made available to third party assessors such as Phaedrus in the UK and Synchromesh Computing in the US.

Conclusions

In summary, when choosing a tools provider for safety-critical systems, a developer should ensure that the tools conform to ISO/ANSI C standards; that they are capable of supporting the requirements of IEC 61508 and preferably also MISRA C:2004; and that the implementation defined and undefined behavior according to the language standard is documented by the compiler vendor. Selecting a state machine design tool make it easier to comply with the IEC requirements for event driven systems. A tools provider with experience in safety-critical systems may also be able to offer references from existing customers and third-party assessors.

If an RTOS is to be used, it also makes sense to choose a commercial RTOS that is already documented and certified for safety-critical applications, and one that is seamlessly integrated in the same design environment as the tools.

Following these simple guidelines should give the developer confidence that their tools will not let them down when safety is of the utmost importance.

References

IEC, www.iec.ch
Micrium, www.micrium.com
Motor Industry Software Reliability Association, www.misra.org.uk
Phaedrus Systems, www.phaedsys.org
Sciopta Systems AG, www.sciopta.com
Synchromesh Computing, www.synchromeshcomputing.com
TÜV Rheinland Group, www.tuv.com