Can AI Code Be Safe? IEC 61508's 16 Software Properties

As generative AI accelerates software creation, the real question is no longer how fast we can write code, but what properties that code must have, especially when functional safety is involved.

IEC 61508 Part 3 covers functional safety for software. Central to part 3 is the concept of “desirable safety properties of software”. These are not features to be implemented directly, but qualities that should emerge from a rigorously implemented software lifecycle.

Figure 1: Excerpt from IEC 61508-3:2010 7.4.2.13

There are 16 such properties:

1. Completeness
2. Correctness
3. Freedom from faults
4. Freedom from ambiguity
5. Simplicity and understandability
6. Freedom from interference
7. Can be verified and validated
8. Predictability
9. Fault tolerance
10. Freedom from common cause faults
11. Repeatability
12. Defined configuration
13. Traceable closure of issues
14. The ability to be safely modified
15. Timeliness
16. The ability to be assessed as compliant

The standard does not expect developers to ‘design in’ each property individually; instead, properties are expected to emerge as evidence from the application of the standard's specified lifecycle requirements. Put another way, by following the process set out in IEC 61508, we should have sufficient confidence that these desirable properties have been met. At least this is the goal of the standard that each desirable property of the software (completeness, correctness, traceability, etc.) will emerge. There are over 200 requirements in the standard that contribute to the emergence of these properties.

Since this is just a blog, I don’t have the capability to provide definitions for each of these, but IEC 61508-7:2010 Annex F provides definitions in the context of the software lifecycle phases. So, for instance, “defined configuration” above might be “precisely defined testing configuration” in one context and “precisely defined validation configuration” in another context.

Similarly, in the context of the software safety requirements specification, we have for completeness “The Software Safety Requirements Specification addresses all the safety needs and constraints resulting from earlier phases of the safety lifecycle and allocated to the Software.” But in the context of software module testing and integration, completeness is defined as “The software testing examines the software behaviour sufficiently thoroughly to ensure that all the requirements of the Software Design Specification have been addressed”.

Figure 2: An extract from IEC 61508-7:2010 table F.1 explaining what the properties mean in the context of a software safety requirements specification

Informative Annex C gives a set of techniques which if followed with the proper level of rigor, appropriate for the SIL of the safety function, will lead to the desirable properties emerging.

Figure 3 Excerpt from IEC 61508-3:2010 table C.1

The table above uses the desirable properties 1, 2, 3, 5, 6, and 7.  It also advocates that the techniques can be applied at various levels of rigor, with R1 being proposed for SIL 1 or SIL 2, R2 if available for SIL 3, and the highest available rigour for SIL 3.

Note – I have stayed with SIL above since it is used in the currently available 2010 version of the standard, the new version due to be released in late 2026 or early 2027 correctly uses SC (systematic capability) instead of SIL (safety integrity level). SC is one aspect of meeting a SIL; PFH/PFD is another.

Some might ask about other desirable properties of software; these are general properties as distinct from “desirable safety properties of software “and not specifically called out in IEC 61508. These properties include:

1. Efficiency in terms of the resources used
2. Portability
3. Scalability
4. Interoperability
5. Security
6. Reusability

But IEC 61508 only deals with safety related requirements. You can’t ignore those other properties, but they are not relevant to safety. Efficiency is not a priority for safety unless it impacts safety, but IEC 61508 has requirements for meeting timing constraints. Similarly, portability is not important for safety, and usability is covered by the human factor requirements in IEC 61508.

The key message is that IEC 61508 treats software safety not as a single verification step, but as the systematic creation of evidence that these desirable properties genuinely exist. If your software is generated by AI, will this still be possible?

Perhaps in a future blog, I will try to cover in more detail the use of Part 3 Annex C, but in this blog, I only wanted to talk about the desirable safety properties of software. For now, I will just state that:

• IEC 61508-3 requires that desirable properties exist
• IEC 61508-7 Annex F explains what those properties mean in context
• IEC 61508-3 Annex C shows which techniques contribute to those properties

Related Blogs

1. The Verdict's In: Verilog is Software?
2. Functional Safety for Software

For previous blogs in this series, see here.

For the full suite of ADI blogs on the EngineerZone platform, see here.

For the full range of ADI products, see here.