Chapter 6.7 of EN 50128 and EN 50657 support tools and languages defines requirements for software tools that are used in a safety-relevant development process. Project team members in safety projects discuss the content and meaning of this chapter again and again. The following article summarizes the essential requirements and derives a practical guide for use in the project. What EN 50128 and EN 50657 call Supporting Tools is often referred to as Tool Qualification.

Further blog posts on related topics are:

• Tool qualification – The phantom pain of functional safety (part 2)!
• Tool qualification – The phantom pain of functional safety (part 1)!
• IEC 61508 – Tool qualification – When? Why? How?
• Compiler for safety critical software – What needs to be done?

Classification of software tools:

EN 50128 and EN 50 657 define the following three tool classes in Chapter 3.1:

Tool class T1: generate no outputs which can directly or indirectly contribute tot he executable code (including data) oft he software.

Examples: A text editor or a requirement or design support tool with no automatic code generation capabilities, configuration control tools.

Tool class T2: supports the test or verification of the design or executable code, where errors in the tool can fail to reveal defects but cannot directly create errors in the executable software.

Examples: test harness generator, a test coverage measurement tool a static analysis tool

Tool class T3: generates outputs which can directly contribute to the executable code (including data) oft he safety related system.

Examples: A source code compiler, a data7algorithms compiler, a tool to change set points during system operation, an optimising compiler where the relationship between the source code program and the generated object code is not obvious, a compiler that incorporates an executable run-time package into the executable code.

According to both standards, no further measures need to be taken for T1 tools.
T2 tools must essentially have a specification or manual in which the behaviour of the tool is clearly defined and all instructions or boundary conditions relating to the application are listed. In addition, the tool choise shall be justified and a configuration management process must be in place.
T3 tools shall also meet the following requirements:

• A suitable combination of history of successful tool use in similar environment
• Diverse redundant code which allows the detection and control of failures
• Compliance with the safety integrity levels derived from the risk analysis of the process and procedures including the tools
• Tool validation results
  • A record of validation activities
  • The version of the tool manual being used
  • The tool functions being validated
  • Tools and equipment used
  • The results of the validation activity
  • Test cases and their results for subsequent analysis
  • Discrepancies between expected and actual results

Practice assessment:

For experienced functional safety experts, EN 50128 and EN 50657 define a very good framework. However, project practice shows that there are still many questions.

EN 50128 and EN 50657 support tools request, more strongly than other functional safety standards, the black box test of the tool used. These tests must be documented (test cases, test procedures, test results). The required specification of the tool is not clearly defined. A requirement specification and the user manual are evaluated more or less equally. The effort for a specification with atomic, testable requirements is usually time-consuming and expensive. The user manual is supplied free of charge with the tool. No direct statement is made about the quality or level of detail of the traceability between specification and tests.

A further aspect in practice is that the manufacturers of commercial tools often offer so-called tool qualification packages. These packages are usually attractive, because the tests and the corresponding documents are already finished and you “only” have to execute the tests once in your environment. However, in this case you have hardly any influence on the content of the delivered tool qualification package. From the point of view of the assessor, however, you are still responsible for the content, i.e. you must know and evaluate the content.

Practical guide for the use of supporting tools according to EN 50128 and EN 60567:

Regardless of who creates the qualification package tool, the following is recommended:

1. creating an overview of all software tools used in the project with a justification of the tool class (T1, T2, T3). For the vast majority of tools, the result will be T1.
2. creation of functional requirements describing the behavior of the tool
3. creation of test cases which describe what the following test specifically tests
4. traceable and plausible linking between requirements and test cases
5. documentation of requirement and test cases in a database
6. creation of automated test scripts including definition
7. use of a professional configuration and change management system

With this procedure you will be able to successfully use 80% – 90% of all software tools relevant in practice. I have described the procedure for the compiler in the blog Compiler for security-relevant software. I would like to make a further restriction for tools which can directly generate errors in an executable SIL3/SIL4 software. Even if the standard here is not so clear, it can be good in practice that further measures are required here.

I’ll be glad to help you also with any specific questions about your project. Send an email to: info [at] heicon-ulm.de

An overview of the HEICON services can also be found on the HEICON Homepage.