Pitfalls when qualifying compiler libraries
Article By : Gerard Vink, TASKING
This article briefly outlines the ISO 26262 tool and library qualification requirements, describes the composition of a C compiler toolset including the dependencies between the components, and explains which qualification criteria apply to the various components.
ISO 26262 functional safety and ISO/SAE 21434 cybersecurity standards require software libraries, including libraries that are part of the compiler toolset, to be qualified before being integrated into automotive software. Both standards consider tool qualification and software library qualification as two independent and unrelated subjects. This general principle is valid for most types of tools and libraries, but it is questionable whether it is also valid for a compiler and associated libraries.
The implementation of a C compiler and associated libraries is based on the ISO/IEC 9899 standard (ISO C), this standard specifies a.o.:
• the characteristics of environments that translate and execute C programs (Clause 5), which underlie the requirements on the so called “startup code”;
• the language syntax, constraints, and semantics (Clause 6), which underlie the implementation of the compiler (the executable file, the tool) and associated run-time libraries;
• and the library facilities (Clause 7), which describe the contents of the header files and the behavior of the C library functions.
Gerard Vink
Each clause of the ISO C standard contains references to all other clauses, indicating dependencies between the startup code, the compiler, the runtime libraries, the header files, and the C library. It is therefore not clear in advance whether the tool qualification and/or the library qualification guidelines apply to a specific part of the compiler toolset, and whether changes to one part of the toolset invalidates the qualification of other parts.
This article briefly outlines the ISO 26262 tool and library qualification requirements, describes the composition of a C compiler toolset including the dependencies between the components, and explains which qualification criteria apply to the various components.
Tool Qualification and Library Qualification
Qualifying a compiler with regard to functional safety is generally seen as a solved problem, therefore this article emphasizes the qualification of software libraries. The ISO FuSa standard provides two methods for qualifying software components, such as the C library. One method is specific to commercial off-the-shelf components, the other is for components developed out of context.
Qualifying COTS Software Components
The requirements regarding the qualification of commercial off-the-shelf (COTS) software are described in part 8 chapter 12 of the ISO FuSa standard. Two requirements can potentially cause
problems when qualifying a C library. First, the requirements for the software component must be available, including requirements on the runtime environment and requirements about the numerical accuracy of algorithms used in mathematical functions, and second, this qualification method is only valid for an unmodified implementation of the software component.
It is usually not possible to extract these kinds of detailed requirements from the user documentation of a compiler toolset, making it difficult for parties other than the library developer to perform a reliable qualification. In addition, problems discovered during the qualification process cannot be fixed as this would modify the implementation of the software component, so one must work around the problems.
If the above can be resolved, the qualification effort boils down to showing a requirement coverage in accordance with ISO 26262 part 6, chapter 9 Software Unit verification, which requires access to the source code of the C library and the compiler run-time libraries, and a C library implementation specific test suite to satisfy the branch coverage requirement for ASILs B and C and the MC/DC coverage requirement for ASIL D.
Qualifying Out-of-Context Software Components
The requirements regarding the qualification of a Safety Element out of Context (SEooC) are described in part 10 chapter 12 of the ISO FuSa standard.
If the C library is considered as an SEooC, then the qualification of the library incorporates all ISO 26262 safety lifecycle steps that also apply to the development of automotive software. The technical safety concept must be developed based on the assumptions on the use of the software component. Subsequently the requirements about the product development at the software level must be satisfied which includes: the application of a suitable development process, specification of safety requirements, creating the software architectural design, doing software unit design and implementation, software unit verification, and specifying how to integrate the components.
In addition to the safety lifecycle to ensure that the component does not introduce additional hazards, the functional lifecycle to ensure the component works as intended must also be addressed.
This makes this qualification method far more elaborate and expensive to apply than the previous COTS-based approach.
The advantage for the user of a SEooC C Library is that the library can be used without any requalification effort. The safety documentation contains the assumptions on safe use and provides guidance on how to establish the validity of the assumptions during integration of the library.
Structure and Qualification of the Compiler Toolset
The Tools
Figure 1 shows the components of a compiler toolset and the relationship between the components. A C compiler toolset contains executables typically split into a compiler, an assembler, and a linker. For the qualification of these executables the tool qualification criteria from ISO 26262 part 8 chapter 11 apply.
A compiler toolset also contains so-called run-time libraries and a C library. There is a fundamental difference between these libraries. The run-time libraries are considered as an integral part of the executables that make up the compiler and are qualified using the tool qualification requirements.
While the C library is considered as a software component integrated into the automotive software and hence must be qualified differently.
Figure 1: Relations between Application Software, QClib, and Compiler Toolset.
The Compiler Runtime libraries
To understand why runtime libraries are considered an integral part of the compiler, it is necessary to understand what a “compiler runtime library” is and why such libraries exist. Suppose the target hardware supports 32-bit floating-point (FP) operations, but not 64-bit FP operations. Now the compiler developer needs to implement 64-bit FP operations using other instructions. The subroutines developed for this purpose are stored in a so-called floating-point runtime library. These subroutines are created by the compiler developer, are only called from compiler-generated code, are not specified in the user documentation, and are never called directly from the user’s application software. Therefore, these subroutines and the associated library are considered an integral part of the compiler tool and the qualification requirements for the tool apply. Conformity assessment bodies tend to follow this line of argumentation and take the view the runtime libraries are also qualified in the context of a compiler qualification.
The Header Files
It is debatable whether the header files should be considered an integral part of the compiler tool or of the C library. The content of the header files, also called standard include files, is specified in the ISO C standard in the chapter Library. The header files contain prototypes of the library functions and macros and type definitions used by library functions. So qualification criteria for software components should apply.
However, there are also dependencies between the header files and the compiler implementation, for example the values of the macros in the “limits.h” header file all depend on and must conform to the compiler implementation. Therefore, the qualification criteria for tools should apply.
Conformity assessment bodies tend to take the view that if the header files are developed by the same engineers who developed the compiler, then the header files are considered part of the compiler tool and are qualified in the context of a tool qualification. If a header file is modified in the context of a library qualification the tool qualification expires and must be redone.
The C Library Functions
The C library contains functions that perform basic operations such as memory operations, and low-level mathematical functions such as square root, power functions, trigonometric functions, and so on that are frequently used in automotive software. The functions of the C library are described in the user documentation, are called from the user’s application software, and are integrated in the automotive software in the same way as other software components. It is therefore “obvious” that a method for qualifying software components shall be applied when qualifying the C library. However, once diving into the details things get messy, below are a few examples.
Functions that implement floating point math operation are typically highly optimized and use facilities from a floating-point run-time library. The run-time libraries were qualified in the context of a tool qualification but now the intended use has changed, and software component qualification criteria apply to those run-time functions that are used by the C library.
The C library functions declared in the header file “fenv.h” access the floating-point environment. The floating-point environment is part of the compiler runtime environment, and its configuration affects the behavior of compiler-generated code and the behavior of floating-point runtime functions. So, for these functions it is debatable whether tool qualification, or software component qualification criteria, or both should apply.
The ASIL level for which a specific C library function is suited is also debatable. Some functions from the C library are inherently unsafe due to weaknesses in the earlier versions of the ISO C standard and the desire to keep the standard backward compatible. To correct the mistakes from the past the ISO C committee introduced Annex K which contains safe(r) variants of the unsafe functions. At TASKING we use the following argumentation when qualifying the unsafe functions: if a function is developed in accordance with ASIL x requirements then the function is qualified for use at ASIL x under the condition that the user applies the guidance provided in the safety manual. In addition TASKING adds the safer variant to the C library and recommends using that function.
The C library also contains functions that are typically not used in production software but are frequently used during the development of the software for logging and debug purposes, the most typical example is the printf function. Should such a function be part of a qualified C library or not? At TASKING we use the following argumentation: to not break existing application software when switching from a non-qualified library to a qualified library the latter should provide the same set of functions, where each function is qualified as suited for either QM, ASIL A, B, C, or D usage.
The Startup Code
The startup code of the compiler toolset can be delivered in multiple ways, as part of the C library, as a separate library, or as a set of source files that must be included in the user’s project. In all cases it is a software component that is integrated in the automotive software and thus the rules for software component qualification should apply.
The purpose of the startup code is to initialize the C run-time environment. The startup code initializes various MCU registers using linker symbols that are created by the compiler/linker and whose existence and values depend on the user’s source code. Furthermore, the startup code initializes the random-access memory (RAM) using a data structure called “the copytable” that is created by the compiler/linker and whose content depends on the user’s source code.
The border between what is part of the tool qualification and what is part of the software component qualifications is blurry, typically the construction of the linker symbols and data structures are considered to be part of the compiler qualification and the use of the symbols and data as part of the software component qualification.
Conclusion
Qualifying a C library in accordance with ISO 26262 is a complex and challenging process, as it requires in-depth knowledge of the FuSa standard, the ISO C library specification and the overall design of the compiler toolset. Careful attention to details is required to oversee the dependencies between all components of the compiler toolset. The required level of detail regarding the safety and functional requirements, the design, and interfaces between components is known only to the tool manufacturer. The stricter FuSa standards from the aviation industry therefore require that the discussed qualification activities must always be carried out by the tool manufacturer.
About the Author
Gerard Vink is Industry Specialist Product Definition at TASKING. He studied mechanical engineering and computer science and has long-term experience with the development of tools and processes for (embedded) software development. In his spare time he likes to race motorcycles and was Dutch champion in the RC1000 class in 2019.
