• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • COMPANY
  • PRODUCTS
  • HEICON BLOG
  • English
    • Deutsch
    • English
  • Menu Menu
You are here: Home1 / FuSa__General2 / Compiler for safety critical software – What needs to be done?

Compiler for safety critical software – What needs to be done?

FuSa__General

The compiler is the central “tool”, which is required for every software development. It forms the link between the human-readable high-level source code (e.g., C and C ++) and the machine code, interpretable for the hardware processor. For the development of safety critical software according to relevant functional safety standards special requirements apply for the tools used during the development. (Refer to tool qualification blog 1 and blog 2) Such functional safety standards are ISO26262 (car), EN50128 (rail), IEC61508 (automation, general) or DO178C (aerospace).  The compiler plays a special role here. On the one hand, it is the central tool for any development. On the other hand, the measures proposed in the standards can not be fully applied in practice. The blog shows a process from the aerospace industry how to use compiler for safety critical systems. This process can highly be recommended for other industries.

Typical tool qualification measure, used in almost all functional safety standards:

  1. Data from the historical use of the compiler
  2. Assessment of the development process of the compiler
  3. Test the functionality of the compiler
  4. Complete development of the compiler according to a standard of functional safety

The most powerful method No. 4 for safety reasons is practically not useable for compilers as they are built by commercial manufacturers. The cost for a compiler that is developed according to safety standards is such high that selling it with a profit is hardly possible in the relative small safety market.

Method No. 3 can not be successfully applied. Because a complete test of the functionality of a compiler is not possible for complexity reasons. The usage of this measure will results in either too many aspects remain untested, or the testing is just uneconomical.

Method No. 2 has not yet been really used in the safety market. The reason might be, that this method can not deliver sufficiently good results for compilers in particular.

This leaves only method 1. Finally, this measure is applied for compiler verification in all safety critical markets. I’m not aware of any safety critical project that would use a compiler that is completely new on the market. In all functional safety projects, compilers are used which are on the market for many years and have already been used in similar projects.

However, historical data does not provide a sufficient waranty for an individual projects! Because of this fact the aerospace industry has developed a process that significantly reduces the risk of remaining undetected compiler errors.

Minimising the risk of undetected compiler errors in the aerospace industry:

The process in the aerospace industry consists of two important additional elements:

  1. For each test (Unit- Integration- or Systemtest), exactly the same compiler settings are used, which are also used for the final operative source code.
  2. For particularly safety critcal projects (DAL A and B), a traceability from the object code to the high-level language source code (C and C ++) is required.

The experience of the last 20 – 30 years in aerospace clearly shows that the application of these two methods is very effective. In combination with the use of known compilers, the risk of undetected compiler errors is reduced to an absolute minimum. In all aerospace projects, which are known to me from the past 15 years, no errors have been found, even after years of field usage, which could be traced back to the compiler.

Therefore it is recommended for other industries to apply this process as well. All tests should be executed with the operating compiler and the corresponding settings. With a good test strategy and a thought through test environment at each level (unittest, integration test and system level), this is associated with hardly any extra effort.

On the other hand, as experience in aerospace shows, that the risk of undetected compiler errors decreases dramatically when tests that show both a structural coverage and a requirement coverage of 95% and more, no compiler errors were found.

Conclusion:

The complete functionality of a compiler can not be proved (see the discussion of method 3 above), but for a single project, the compiler functionality used is limited and therefore completely testable. This is exactly what is achieved with applying the recommended measures.

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

11. September 2017/1 Comment/by HEICON Global Engineering GmbH
Tags: ASIL, Compiler, DAL, Development process, EN50128, Functional Safety, IEC61508, ISO26262, proven in use argument, RTCA DO178, SIL, Software Engineering, Test, Testing, Tool Qualification, Validation, Verification
Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on LinkedIn
https://heicon-ulm.de/wp-content/uploads/2019/12/DI1A6023_klein_Functional_Safety.jpg 433 547 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2017-09-11 08:48:152021-02-03 21:47:16Compiler for safety critical software – What needs to be done?
You might also like
Validation and Verification Implicit Testing – A good idea (Part 1)?
Requirement Engineering How many level of Software requirements are necessary and useful?
Automotive Reuse scenarios in ISO 26262 (part 1)
Other Functional Safety Standards ISO 25119: Software Development for Tractors and Machinery for agriculture and forestry
Functional Safety Is the inverted V-model the secret to success?
Functional Safety FMEA – A powerful method, but not for software!
1 reply
  1. Anonymous says:
    27. June 2018 at 15:18

    Very nice overview on that topic. May become of more importance in future, because requirements for tools used in safety are under discussion within the standard comitees for IEC61508.

    Reply

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

Freedom from Interference – The practice in Industry!Functional SafetyRequirement EngineeringRequirement Engineering – Aspects which even not considerd in theory!
Scroll to top