Peak SSE Sign up

News

Standards · Functional safety

New IEC guidance on object-oriented software in safety-related systems

Published 12 October 2026 · Source: IEC

Lines of programming code on a computer screen
Photo: Pexels

What happened

On 16 July 2025 the International Electrotechnical Commission (IEC) published IEC TR 61508-3-3:2025, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3-3: Object-oriented software in safety-related systems. It is a Technical Report (Edition 1.0, 52 pages) from IEC subcommittee SC 65A, the committee responsible for IEC 61508.

According to IEC's description, the report proposes which topics to consider, and which methods and techniques to use, when designing object-oriented software so that it is of suitable quality for functional safety applications. It is a supplement to the IEC 61508 series and has to be read with IEC 61508-3, the software part of the standard. It does not replace any part of IEC 61508-3: the rules there still apply and are not repeated. IEC lists among them the software lifecycle, the involvement of the assessor, modularisation, information hiding, proving and conventional testing, the basic aspects of documentation, low coupling and high cohesion, the responsibilities and training of people, and operational experience.

Why it matters

IEC's description of the report says object-oriented languages are now seen as state of the art, but that several statements in IEC 61508-3 seem to exclude their use. A note to Table A.4 of IEC 61508-3:2010 (detailed design) says the suitability of object-oriented development for safety-related systems is still debated, and points to Annex G of IEC 61508-7 for guidance.

IEC's description also points to notes in some tables under which their use might be justified, such as Table B.1 (design and coding standards). Its note says that dynamic objects, on the execution stack or on a heap, may impose requirements on both available memory and execution time. It then says three of the table's measures need not be applied if the compiler ensures that enough memory for all dynamic variables and objects is allocated before runtime, or that a safe state is reached if memory allocation fails, and that response times meet the requirements.

The new report takes up those concerns, memory allocation and predictable timing, and sets out methods and techniques intended to reduce systematic faults to the levels required by the respective systematic capabilities. It proposes a way to justify the use of object-oriented software in safety-related applications.

This is useful guidance, and it is guidance rather than new requirements: the report proposes, IEC 61508-3 still governs, and the assessor still has to be satisfied. Its value is a shared starting point. A team that wants to use an object-oriented language on safety-related software can now cite a published IEC document for the methods it applies, not only the table notes.

The argument will still stand or fall on evidence. The concerns the report addresses are the ones the notes to Table B.1 already name, so a project's coding standard, its rules on memory allocation and its timing analysis are where the work is. Teams that already restrict a language to a subset for safety work should read the report alongside their coding standard and check that the two agree.

Sources