Configurable Software Systems in ISO26262 are discussed in part 6 Annex C. This blog summarizes important requirements of the standard and shows practice-oriented challenges of software-configurable embedded systems.
The use of calibration data in configurable systems offers a lot of advantages. The functional behavior of the entire system can be adjusted by simple and rapid changes in the calibration data without having to change the source code itself. This enables the multiple re-use of source code. If it is well done, even the unit tests should be reusable, included the measurement of the structural Source Coverage. These are quite important advantages.
ISO 26262-6: Requirements
The standard distinguishes between calibration and configuration data:
Calibration data: “Data that will be applied after the software build in the development process” Examples are e.g. vehicle-specific parameters.
Configuration data: ” Data that is assigned during software build and that controls the software build process ” as Pre-processor instructions.
The Annex C of ISO 26262-6 [Software] defines the following procedure:
C.4.6: The specification of the calibration data must consider the following points:
- valid values
- the intended use
- the data areas
- the scaling and the units of data
- the interdependencies of individual data
C.4.7: The verification shall demonstrate the use of the calibration data in the data area defined.
C.4.5: indicates that a combination of the following measures can demonstrate the complete verification of a configurable software:
a) verification of configurable software
b) verification of configuration data
c) verification of the configured software
A description is given in the standard, that the combination of a) and b) is a complete verification. Alternatively, a combination of b) and c) has to be carried out.
Note: The standard indicates that a configured software does not contain the calibration data. In my view, however, the in paragraph C.4.5 mentioned approach makes only sense if it includes the calibration data. Regarding the verification of software which contains calibration data, the standard says very little.
The complexity of the verification lies in the variety and variance of the calibration data, and the resultant high number of variants of different functional behaviors.
If you read functional requirements of such systems it becomes obvious that it is not possible to verify it 100%, because of the variety of calibration data and the resulting variety in the functional behavior.
The verification of calibrated software and the validation / verification of the calibration data (as defined in the standard C 4.5) are the first steps. However, to be complete, it has to include justifications (equivalence classes). The software architecture is the basis for the justifications. Therefore, the prerequisite to the success of this approach, are good requirements and a detailed architecture. The big advantage is that you can make the verification universal valid. This means, that it does not matter what particular set of calibration data is used, there is no need to update the performed verification.
The alternative, which is provided by the standard (to verify the configuration and calibration data, as well as the verification of the configured / calibrated software) is in its implementation certainly much simpler. Only one set of calibration data needs to be tested. The big drawback here is that the verification is valid only for this selected set of data.
The advantages of a configurable / calibratable software becomes tremendous if its verification is universal valid, i.e. it is valid, regardless of the individual calibration data.
Until 2015, I accompanied a project with the highest safety requirements, in which this procedure was successfully applied (due to my initiative).
I’ll be glad to help you also with any specific questions about your project. Send an email to: martin.heininger [at] heicon-ulm.de
An overview of the services can also be found on the HEICON homepage.