In a previous blog, see here, I discussed the existing rules from IEC 61508:2010 for software tools used to develop a safety system. In this post I will discuss the proposed rules for IEC 61508 revision 3. These rules could change depending on the comments received when the drafts are circulated to the various national committees but given that most national committees are already represented on the IEC 61508 maintenance teams there is an expectation and hope that the proposed rules will not change dramatically.
The new rules will replace the existing rules from IEC 61508-3:2010 sub-clause 7.4.4 and will apply to software tools used to produce software elements or hardware elements.
I have always assumed that the old rules applied to tools used to produce hardware elements, but it seems not everybody was of the same understanding. Therefore, a clarification will be added in part 1 to make it clear that the software offline tool rules apply to both hardware and software elements. To me the new rules make sense. I have test driven them on some tools used to produce integrated circuits and they produced good results and were efficient to apply.
The new proposal for tools is risk based with tools ranked on TI (tool impact) 1 (lowest impact), 2 or 3 (highest impact), similar to the older T1, T2 and T3. This is combined with a ranking based on the confidence in the measures which would detect an error in the tools output of TD1 (lowest confidence), TD2 or TD3 (highest confidence). However, the SIL of the safety function being developed is now also included in the analysis on a scale of 1 to 4. The combination of TI, TD and SIL results in a TIL (tool integrity level) which then determines the requirements to permit the use of that tool in the development of the safety system.
Table 1 - TD/SIL/TIL balancing rules based on 61508 revision 3 proposals
The dependence on tool impact was always there in the old rules and while the SIL dependence is new it seems logical. The dependence on TD is also new and takes the rules closer to what is found in ISO 26262 (automotive).
As an example of applying the rules, the above table says that if you are developing software for a SIL 3 safety function and the TI=2 (medium) and the ability to detect errors in the tools output is rated as TD=2 (medium) then a TIL of 1 is required.
Alternatively, if you are developing a tool for a SIL 3 safety function with an TI of 3 (high) and a TD of 1 (low) then the TIL is 3.
Under the existing 2010 version of the standard, the SIL of the safety function and the confidence in measures to detect errors in the output of the tool are not directly evaluated. There was no equivalent of TIL.
Under the new system once the TIL has been determined then the requirements for each TIL will have to be followed. Some of the requirements relate to the tool developer and some to the tool user. Please beware as these rules are still could change.
The design of integrated circuits is heavily dependent on software tools. Previously the rules for tools used to produce integrated circuits came from IEC 61508-2:2010 Annex F and proven in-use tools were preferred. Proven in-use is now deprecated and the requirements for tools used to produce integrated circuits will be similar to those used to produce any other hardware or software elements for a safety system.
For module level and PCB level designs the new rules will apply to tools such as:
IEC 61508 is a basic safety standard and therefore changes within IEC 61508 could impact a lot of application areas. In addition, other standards such as ISO 13849 refer to IEC 61508 when it comes to embedded software or programmable electronics.
Access to the new rules will be available sometime in 2020 when the first draft of IEC 61508-3 is published. Hopefully this blog goes some way towards socializing the new rules. But be warned that the path of a standard is somewhat like that of a hurricane and the path can easily change between now and the time of publication.
As an aside I am always surprised that in the cyber security world there are very little requirements on the tools used to produce software. As an example of how a software tool can be the source of cyber security issues see the paper “Reflections on Trusting Trust” by Ken Thompson where he talks of how a compiler was subverted to modify something which looks like a login request to either accept the genuine password or one of the hacker's choosing. The one exemption to this is the new automotive cyber security standard ISO SAE 21434 which I suspect had a large participation from people who also worked on ISO 26262 and so were sensitized to the whole tool issue.
If you need more information on the topic, I would recommend the following:
DO-330:2011 – Software tool qualification considerations
DO-254:2000 – Design assurance for Airborne electronic hardware figure 11-1
ISO 26262-8:2018 clause 11
CENELEC 50128 and IEC 62279 standards - ISBN-13: 978-1848216341 – Page 289
ISO/SAE 21434 – Road Vehicles Cyber security