Meeting the embedded requirements of FuSa applications
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, the environment, or even a person’s death. Some prominent examples are the automotive industry, aviation, and medical devices. Still, safety-critical applications also exist in nuclear power plants, public transportation and infrastructure, and less obvious areas such as the chemical processing industry and surveillance systems.
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 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/C++ and IEC 61508 and many others like ISO 26262, IEC 62304, EN 50128/ EN 50657
- Development tools such as compilers and real-time operating systems
This article will focus on this last item and discuss how development tools such as IAR Embedded Workbench and IAR Visual State can ensure functional safety (FuSa) in embedded systems.
State machines in FuSa applications
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 Safety Integrity Levels (SIL) levels. Part 3 of the standard is called ‘Software Requirements’ and covers the requirements for a software quality management system, a software safety lifecycle, and a functional safety assessment.
One of the explicit recommendations in IEC 61508 is using 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 mistakes and omissions can be detected.
IAR Visual State is a design tool based on state machines. It 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 specific properties directly on the specification level. IAR Visual State generates bug-free code that also follows the standard guidelines of MISRA C/C++. The user can verify the model, e.g., by checking for dead ends, conflicting transitions, and domain errors. Try it in action.
Figure 1: One of the explicit recommendations in IEC 61508 is using state machines, as employed in IAR Visual State, as a design method to meet Safety Integrity Level 3 (SIL3) and above for event-driven systems.
Validation and verification of FuSa applications
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 grows too vast. Instead of manual testing, engineers must depend on tools that can test the system’s logic and behavior.
IAR Visual State can help by analyzing test coverage on states, transitions, and input/output and by creating 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.
Figure 2: There can be no tolerance for errors caused by poorly designed or documented software for safety-critical embedded systems, such as those found in automotive or aviation applications.
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 much more convenient if the RTOS involved is approved and has all the required documentation to prove its feasibility.
One example of well-tested and field-proven RTOSes for high-integrity systems is 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 suit high-integrity operation, including direct message passing. SCIOPTA is certified by TÜV to IEC61508 at Safety Integrity Level 3 (SIL3). This qualification makes it an even more attractive option for developing high-integrity applications.
Additionally, SAFERTOS from WITTENSTEIN high integrity systems is a pre-certified kernel for use in critical systems, is based on the FreeRTOS functional model but completely redesigned for the safety market. SAFERTOS was independently certified by TÜV SÜD and is available with complete life-cycle documentation and certification for several standards, including IEC61508 SIL3, EN62304, and FDA510(k).
For programmers, testers, and code reviewers alike, the code they work on must have the exact meaning and semantics 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 genuine 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 compiler vendor documents the implementation-defined and undefined behavior according to the language standard. 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. This will give the user more confidence that it will behave as expected. Suppose the compiler vendor is not writing these corner cases. In that case, 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.
Compliance with industry standards MISRA C/C++, CWE, and CERT C/C++
In addition to supporting ISO/ANSI C, the IAR C-STAT code analysis add-on from IAR also supports MISRA C/C++, CWE, and CERT C/C++.
IAR C-STAT performs several security checks for compliance with the MISRA rulesets and rules defined by the CERT C/C++ Secure Coding Standards and for several weaknesses described by CWE. To further simplify compliance tasks, IAR C-STAT provides output consistent with naming weaknesses in CWE.
The Motor Industry Software Reliability Association rules have spread worldwide and into different industry segments, and the ruleset is now the most widely used C subset in the embedded industry. MISRA-C:2012, the latest version, contains 143 rules and 16 so-called directives. The rules are classified as mandatory, required, or advisory and cover such areas as avoiding possible compiler differences like integer size, avoiding using functions and constructs that are prone to failure, limiting code complexity, and ensuring that the code is maintainable, for example by using naming conventions and commenting.
The Common Weakness Enumeration is a community-developed dictionary describing the weakness and its potential consequences, as well as possible mitigations, code samples, taxonomies, and references. It is intended to help better understand and manage software weaknesses and enable more effective selection and use of software security tools and services that can find these weaknesses.
Provides rulesets for secure coding in C as well as in C++. Each guideline includes a title, a description, a non-compliant code example, and examples of compliant solutions. The standards include guidelines for avoiding coding and implementation and low-level design errors. The criteria aim to eliminate insecure coding practices and undefined behaviors that can lead to exploitable vulnerabilities.
To further ensure high code quality, the runtime analysis tool IAR C-RUN can help find errors during runtime. IAR C-RUN performs runtime analysis by checking application execution directly within the development environment. It fits for arithmetic issues, bounds issues, and heap integrity and will tell you what went wrong and where.
The primary purpose of the industry standards is to help achieve safe, unambiguous code that does not unnecessarily rely on implementation-defined behavior and is easily portable between different target architectures.
Pre-Certified and Validated toolchain
To build applications with ensured functional safety, you must provide extensive documentation for selecting a particular toolchain and prove that you comply with specific requirements in your sector. Choosing a pre-certified solution will save time and cost, enabling you to focus more on your code and the application's features.
IAR provides certified editions of IAR Embedded Workbench and IAR Build Tools with cross-platform support for Linux (Ubuntu and Red Hat) and Windows.
The certified editions enable simplified validation of your application thanks to the included Functional Safety certificate from TÜV SÜD, Safety report from TÜV SÜD, and Safety guide.
The IAR Embedded Workbench IDE and IAR Visual State are tightly integrated. The generated source code files by IAR Visual State are handled automatically via the project connection file in the IDE, and the C-SPYLink plugin enables high-level state machine model feedback directly to the IAR C-SPY Debugger including graphical animation in the state machine.
In summary, when choosing a tools provider for safety-critical systems, a developer should ensure that the solutions conform to ISO/ANSI C standards, that they are capable of supporting the requirements of IEC 61508 and preferably also MISRA C/C++, CWE, and CERT C/C++ standards; and that the compiler vendor documents the implementation-defined and undefined behavior according to the language standard and can the source code can be tested and verified with static and runtime analysis tools, highly recommended for any embedded development and mandatory for certification efforts. Selecting a state machine design tool makes it easier to comply with the IEC and ISO requirements for event-driven systems, including automated code generation following the standard guidelines of MISRA C/C++. A solutions 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 already documented and certified for safety-critical applications and seamlessly integrated into the same design environment as the pre-certified tools.
Following these simple guidelines should give the developer confidence that their tools will not let them down when safety is paramount.