Chapter 8 of EN 50128 specifies the requirements for systems that are configured by application data or application algorithms. This blog summarizes the essential requirements of the standard and the practice-oriented challenges of software-configurable embedded systems.
At the first glance the configurability offers only advantages. The functional behavior of the entire system can be adjusted by simple and rapid changes in the application data to the desired behavior. The source code of the generic software is not to changed. A multiple reuse is possible thereby. If it is well done, even the unit tests should be reuseable, without any change. The EN 50128 also states that proven, generic software can be reused repeatedly in this way. These are important advantages.
Requirements of EN 50128 Chapter 8:
The standard requires that the generic software which is part of a configurable system is developed according to the same requirements of the standard as the non-configurable software.
Normative requirements for the application data:
Chapter 8.4.4 requests a proof that the generated application data are basically consistent and complete. Furthermore, it is required that each activity is documented, which is carried out to ensure the accuracy and completeness of data.
Normative requirements for the generic software:
Chapter 126.96.36.199 demands a clear and unambiguous separation, as well as the definition of an appropriate interface between generic software and application data.
Chapter 188.8.131.52 demands a significant restriction on use of the software, as long as it is not possible to consider all relevant combinations of data and algorithms in the verification and validation process.
Normative requirements for integration and verification of the entire system:
In chapter 8.4.5 it is demanded that
- integration tests are executed as part of the overall installation,
- the target system is put into full-featured operation, and
- a final acceptance process is applied for the target system.
This list of significant points shows that the standard is well aware of the complexity of such systems and the associated difficulties of a full verification. However, no strict guidelines are provided to handle this complexity.
Below I describe my experience with the verification of such systems in safety-relevant areas.
The complexity of the verification lies in the variety and variance of the application data and the resultant variants and different functional behaviors.
Looking on the functional requirements of such systems it becomes obvious that it is not possible to verify it (not even close to) 100%.
The verification of the configurable software and the validation/verification of the application data, as required by the standard is the first step. However, the verification of a generic software consists of two steps:
- Testing and
- Justifications of equivalence classes
The equivalence classes should be derived from the software architecture. Prerequisite to the success of this approach are good requirements and a detailed architecture. The big advantage is that the verification becomes valid, independent of any specific configuration for the application!
The standard also provides the option to verify the specific application data and the configured overall system. The advantage is that the verification becomes certainly significant easier because exactly one configuration is tested. The big drawback here is that the verification is only valid for one specific configuration. For each additional combination of generic software and application data the verification of the entire system needs to be rebuilt. A reuse of existing tests will be very limited, because the functional behavior of the system due to the different application data is changed.
The advantages of a configurable system are very high, in case you can make the verification general valid, i.e. independent of the individual application 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.