• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • COMPANY
  • PRODUCTS
  • HEICON BLOG
  • English
    • English
  • Menu Menu
You are here: Home1 / FuSa_Automotive2 / ISO 26262 calibrateable Systems – Chance or Risk?

ISO 26262 calibrateable Systems – Chance or Risk?

FuSa_Automotive

ISO 26262 calibrateable Systems 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.

ISO26262 calibrateable Systems: practical experience

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.

Conclusion

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.

Related HEICON Blog posts

  • EN50128 configurable Systems – The solution?
  • Good safety development process – What is it?

Are you ready for a functional safety workshop, to identify improvement potentials in your development process? Send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.

 

 

 

30. April 2016/0 Comments/by HEICON Global Engineering GmbH
Tags: Calibration Data, Configurable Software, ISO26262, ISO26262 Verification, Validation and Verification
Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on Pinterest
  • Share on Reddit
https://heicon-ulm.de/wp-content/uploads/2020/03/DI1A6086_klein_Automotive.jpg 533 684 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2016-04-30 22:12:582021-02-05 21:43:32ISO 26262 calibrateable Systems – Chance or Risk?
You might also like
Functional Safety Compiler for safety critical software – What needs to be done?
Functional Safety FMEA – A powerful method, but not for software!
Automotive Reuse scenarios in ISO 26262 (part 1)
Requirement Engineering Requirement and Test Traceability – Any added value?
Automotive Reuse Scenarios in ISO 26262 (part 2)
Requirement Engineering How many level of Software requirements are necessary and useful?
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Categories

  • A_Requirement Engineering
  • B_Validation and Verification
  • C_Config- / Change Management
  • D_Security
  • FuSa__General
  • FuSa_Aerospace
  • FuSa_Agriculture
  • FuSa_Automotive
  • FuSa_Industrial
  • FuSa_Railway

Contact

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Phone: +49 7353 – 98 17 81
Mobile: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRINT  |  DATA PROTECTION

EN 50128 configurable Systems – The solution? Railway Requirement Engineering How many level of Software requirements are necessary and useful?
Scroll to top