Check Your Software Tools for Standards Compliance

Before Starting Safety-Critical Projects

With software solutions playing an increasingly important role in safety-critical applications, malfunctions can interrupt essential services, damage the environment, or even result in loss of life.

That’s why the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) have created functional safety standards that software developers must comply with to certify that their software is safe. The ISO 26262 standard, for example, covers the qualification of automotive software components and product development at the software level. Other standards include EN 50128 / EN 50716 for the rail industry and IEC 61508, which is applicable to all industries.

Third-party tools

Developers of safety-critical applications must do everything in their power to ensure their development processes and application code meet these standards. But they must also consider the integrity of third-party or commercial off-the-shelf (COTS) tools and software components through qualification. Qualification can only be truly valid if it is carried out in precisely the same development environment and under the same use-case scenario that the developer used in the specific application.

Significant parts of a toolchain are usually beyond the software developer’s control. Compiler validation is crucial to deal with this. Because no compilers are bug-free, it is vital that any malfunctions are quickly identified so that the developer can avoid any compiler errors that impact the safety of their application.

Developers of safety-critical applications must also qualify the standard library they use, because code from the library is linked to the application and installed onto the target device. If any library component is defective, the functional safety of the entire application will be undermined.

Part of the code that typically ends up in an application includes pre-compiled library functions, such as those used in the standard libraries, which are often supplied in binary format as part of a software development kit (SDK). A common mistake is assuming that the code will be invariant because a library is provided in binary format. The reality is that library components are often use-case-sensitive because their header files feature macros and type-generic templates. This means that even if the SDK supplier pre-qualified the library using the same compiler delivered with the SDK, the specific use case, compiler options, and target hardware environment requirements are unlikely to be satisfied. This makes it extremely difficult to demonstrate compliance with functional safety standards.

So, what can be done to mitigate these issues? Developers need testing and qualification technology for compilers and libraries. They must also provide full traceability from individual test results back to requirements derived from the ISO language specification. Solid Sands is recognized as the world’s ‘one-stop shop’ for C and C++ compiler and library testing, validation and safety services and their product SuperGuard contains everything needed for standard library qualification in safety-critical product development.

Self-developed implementations

Solid Sands has developed SuperGuard, a qualification suite based on the Solid Sands SuperTest Compiler Test and Validation Suite, which has tracked ISO language specifications for more than 40 years. One of the suite’s key features is that it can be used to qualify standard library implementations for safety-critical applications for unmodified third-party library implementations as well as for self-developed or self-maintained implementations as shown in Figure 1.

Recently, Solid Sands added support for the qualification of C++ standard library headers to SuperGuard, which are particularly interesting to developers in the safety and automotive sectors. It enables C++ users to carry out C++ library qualification by providing the necessary proof.

It’s worth mentioning at this stage that effective requirements-based testing is not the only factor involved in producing reliable evidence that there are no known software errors capable of causing a violation of safety requirements. Also needed is structural code coverage for Automotive Safety Integrity Level D (ASIL D), the highest integrity level for automotive applications such as that shown in Figure 2. SuperGuard provides high structural code coverage and high modified condition/decision coverage (MC/DC) to deliver evidence of completeness. The suite also covers analysis and testing of equivalence classes, boundary values, and error guessing based on the best available knowledge and experience of a library function’s behavior.

Behavioral description

The main issue with the C and C++ standard library specifications is that although they provide a detailed behavioral description for each function, neither defines a clear set of requirements. Therefore, SuperGuard provides the necessary requirements for each function, which are derived from the behavioral descriptions. The suite’s tests are behavioral tests, which means they verify that the implementation’s behavior complies with the library specification, as demonstrated in Figure 3.

To check the implementation’s behavior, these tests are compiled and carried out in an execution environment, which means that the entire toolchain, including the target processor, is involved in each test. This makes the suite suitable for hardware-in-the-loop verification of the standard library. Another benefit is that minimal resources are required because most SuperGuard tests can run on systems with under 4K of memory, making it possible to use the test suite on very small embedded systems. 

RESOURCES
www.solidsands.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JULY 2024 #408  

Sponsor this Article