You couldn't build a house without tools and software is no different. IEC 61508 talks about two types of software tools. Online tools which run as part of the application and offline tools used during the development or manufacturing phases. Online software tools have the same requirements as any other piece of software in the safety system but what about offline software tools used to develop or test the software in the product. Offline software tools include things like compilers, editors, static analysis tools and requirements management tools. This blog discusses requirements related to offline software tools found in standards such as IEC 61508, ISO 26262 and D0-178C/D0-330.

I note that the requirements related to tools are far more onerous in functional safety than in other high integrity areas such as cyber security. That most cyber security standards have little if any requirements related to tools surprises me as does the fact that they have no requirements related to the development of integrated circuits which are at the root of most systems.

A simplified graphic showing a process compatible with the automotive ISO 26262 requirements is shown below. Firstly, all tools that you plan to be used are listed. Then if there, is something else in your development process which will detect an error in the tool output then no further analysis of the tool is required as shown by the flow chart below. While this is not the strictly IEC 61508 compliant, I like the approach because for most tools it provides a quick and easy exit point that the official process eventually gets to but after more steps.

Figure 1 - A simplified flow chart based on ISO 26262 requirements

Getting back to the IEC 61508 process there are 3 defined classes of tools

T1 – tools which have no impact on the executable code. The examples given in IEC 61508-4:2010 include text editors and requirements management tools. Perhaps a description more consistent with the examples given in the text are tools that are not used to produce the code or verify the code but even then it is hard to argue that a text editor is only a T1 tool.

T2 – tools which only impact on the verification of the executable code and can’t inject an error into the code but could cause an error to be missed e.g. static timing analysis tools

T3 – tools which can put an error in the code e.g. compilers

The first requirement is that the use of tools should be managed. This generally means that when doing your software safety plan, you should list all the tools you plan to use, what they will be used for and the version of the tool you plan to use.  A justification for the tool is also required.

Next you rank your tools as T1, T2 and T3 according to definitions above. If a tool is ranked as T2 or T3 you then need to think about how the tool can go wrong and what else in your development process would catch that error (mitigation measures inherent in your development process). If there is nothing that would catch such errors, then some suitable means to mitigate the errors must be identified.

Tools categorized as T2, T3 also must have suitable documentation. In addition, for tools classed as T3 additional evidence is required that it complies with that documentation. Evidence can be based on proven in use or a tool validation based on test cases.

For complicated tools with many functions each of the functions could be analysed separately as if it was several independent tools.

In IEC 61508 circles there is some debate as to whether the software offline tool requirements apply to hardware development tools or not. Tools for the development of integrated circuits are covered by the requirements of IEC 61508-2:2010 Annex F mostly relating to proven in use with proven in use given as perhaps 2 years of use in projects of similar complexity. In automotive it is clearer that the tool requirements apply regardless of whether it is hardware or software which is being developed. I believe this is the correct approach for developments based on IEC 61508 also.

Later in IEC 61508-3 table A.1 advocates the use of tools for requirements management and table A.3 the use of certified tools and certified translators.

Going forward there are plans to revamp the offline tool requirements in IEC 61508-3, watch this space.

I couldn’t find an appropriate video related to offline software tools so this will have to do – see entitled “OSHA Nightmares compilation”.

For next time the blog will cover the difference between verification and validation.