What Safety Integrity is required for on-chip software?

Functional safety for software is covered by IEC 61508 part 3. Typically, software than runs on uC, uP and DSP is written by the applications people who buy our chips. But what about software that runs on integrated circuits and is supplied by an IC vendor such as Analog Devices.

Firstly, what is software, I show some definitions below and I would argue that it doesn’t really matter whether you call it software, firmware or embedded software the same rules apply, and those rules typically come from IEC 61508-3.

Figure 1 - Software and firmware definitions

A better definition of software is found in the book “Embedded Software Development for Safety Critical Systems” where it states “It may seem strange to ask what software is – intuitively people feel that they can differentiate between software and hardware. If it hurts when you drop it on your foot, it’s hardware”. In a future blog I will discuss if Verilog/VHDL code is software but for now let’s accept that it is not.

Types of software relevant to integrated circuits and supplied by your IC vendor include:

• Boot loaders / Boot ROM software
• “Logic blocks” implemented using an on-chip uC or DSP instead of fixed function logic
• Software test libraries
• Protocol stacks or libraries of drivers
• Sample code used to demonstrate how an IC will work

Figure 2 - An extract from the scope of IEC 61508-3

For all of the software types above the scope of IEC 61508-3 would appear to make it clear that IEC 61508-3 applies but let’s discuss them all in some more detail; as in functional safety there are always if’s and but’s and the answers are rarely yes/no.

Bootloaders:

A bootloader is one name for the piece of software that runs when an uC or DSP powers up and configures the IC by perhaps changing the RAM size, moving calibration coefficients from flash to RAM and perhaps implementing a protocol to allow programming of the flash over a serial port.

In the author’s view IEC 61508-3 clearly applies to such code but arguments could be made to reduce the burden of compliance. Such arguments might include:

• The code is simple with few decision points and its correctness can be verified by 100% testing without knowledge of the development process used
• That the code runs before the application code and the application code cannot jump back into the code and therefore cannot interfere with the application code

But either way that still means that IEC 61508-3 applies and your functional safety argument to justify a lower SIL or no SIL for the development of that code should be documented.

Software test libraries:

 An STL (software test library) is a piece of code that may be supplied by the IC vendor or a third party and is used to give diagnostic coverage on the uC / DSP on which it runs. You could try to argue that since a failure of the STL would not lead directly to a failure of the safety function that the SIL of such software could be 0 or at least less than that of the safety function using the IC on which the STL is run. However, it is in the authors view, that it would be very hard to argue that the STL is independent of the hardware it is checking and independent from any other safety related software running in the uC. Therefore, the STL probably needs to be developed to the same SIL as the safety function which relies on it. However, there is always the possibility to argue otherwise.

Logic blocks implemented with an on-chip uC or DSP:

If it walks like a duck and quacks like a duck, it is a duck. If the IC containing that code is part of a safety related system, then the code needs to be developed to IEC 61508-3 unless an accepted and valid argument is made as to why not. It doesn’t matter if the code is stored in flash, OTP, ROM or RAM it is still software in a safety system. Arguments that might reduce the compliance requirements include

• some external safety monitor not dependent on software which ensures safety
• the possibility to verify the code by testing alone (if simple code)
• the use of diversity at the system level to reduce the SIL of any on-chip code

Protocol stacks and libraries:

The assumption here is that the source code is not available to the end user. In that case since the software is running in the safety system it would typically need to be developed to the same SIL as the application software. Exceptions here might be if the protocol is a networking protocol stack and is part of the black channel in which case it does not need to be developed to a SIL. The person implementing the stack into their system does however have to ensure sufficient independence between the stack and any other safety related software in their system, including the SCL (safety communications layer) or all of the software takes on the higher SIL.

Sample code used to demonstrate how an IC might be programmed or works:

The assumption here is that such code is available in source code format. Therefore, there is no need for the IC developer to develop such code to IEC 61508-3. The person designing the IC into their system should apply IEC 61508-3 to the code themselves.

In summary software in a safety related system, regardless of whether developed by the IC vendor or the IC user needs to be developed to IEC 61508-3 or an argument made as to why IEC 61508 doesn’t apply or why it can be tailored based on valid documented safety argument. In particular, the use of identical redundancy does nothing to reduce the SIL required for such software.

A future blog will address the topic of whether HDL code is software.