IEC 61508 and machine learning meet in one place in practice: Part 3, the software requirements. That is where a safety assessor will ask how the learned element was specified, built, verified and changed, and where most write-ups stop being specific. Our earlier article on functional safety and machine learning covered the SIL bands, ISO/IEC TR 5469 and the three architectures that let a deterministic monitor hold the integrity claim. This one takes the next step. It reads the clauses of IEC 61508-3 against an actual ML stack, including what the Edition 3 drafts now say, and ends with how we mapped a validation campaign onto them.
What IEC 61508 Edition 2 says about machine learning
Nothing, by name. The edition in force is Edition 2, dated 2010, and projects running today are assessed against it. Its software part predates deep learning in industrial control, and a systematic review that mapped 83 primary papers onto the IEC 61508-3 lifecycle concluded that the current version is not applicable to the verification of neural network based control software, because AI technologies are not recommended there.
The same review is worth reading for what it found missing. Against the Part 3 properties, research had concentrated on correctness, completeness, freedom from intrinsic faults and fault tolerance. Little effort went into repeatability, and no reviewed study addressed precisely defined test configurations or defence against common cause failure. Those happen to be the properties an assessor checks first on any software, learned or not.
What the Edition 3 drafts change
Part 3 names AI as a software technology class
The committee draft for vote of Part 3, document 65A/1169/CDV, adds a scope item that did not exist before. Part 3 does apply to software algorithms of software technology class I, and of classes II and III, with the classes defined in IEC 61508-4. The notes attached to that item relate the classes to the term artificial intelligence as defined in ISO/IEC 22989, and refer the reader to ISO/IEC TR 5469:2024 and the ISO/IEC TS 22440 series.
The first line of the draft's change list sets the limit: all requirements on the use of artificial intelligence, security and human factors are confined to those references to external guidance. Edition 3 brings ML inside the scope of Part 3 without writing ML-specific requirements into it.
Part 1 confines AI to hazard and risk analysis
The Part 1 draft does the same at system level. Its scope clarifies AI as a class of software technology, and the related requirements are limited to the hazard and risk analysis clauses, 7.1.2.3 and 7.4.2.3, plus references to external guidance. In practice this means the first place a learned element must appear is the hazard log: what it can do wrong and what that does to the process.
When it applies, and what it points to
The dates disagree. The IEC webstore forecast Part 1 Edition 3 for 22 October 2026, while the UK 61508 Association expects early 2027. The external guidance itself is not finished either. ISO/IEC TS 22440-1, the requirements part, is a committee draft whose comment period closed on 11 April 2026. So the standard will soon point at a requirements document that does not yet exist as a published text. Plan against Edition 2, write the case so it reads cleanly under Edition 3, and keep TR 5469 as the interpretive bridge.
Systematic capability is the quantity that matters
A SIL belongs to a safety function. What an element such as a software module carries is a systematic capability, on a scale of SC 1 to SC 4: the confidence that its systematic safety integrity meets the requirements of the specified SIL. The Edition 3 drafts clarify the distinction between the required SIL and the achieved SC, and that is where a learned component gets into trouble.
Part 3 grades its techniques against SC. The normative Annex A is the selection guide, and the informative Annex C relates the tables to properties such as completeness, correctness, freedom from intrinsic faults, understandability, predictability, testability and fault tolerance, and explains how to justify techniques that are not listed. That last provision is the legitimate opening for ML. You are not barred from using a technique the tables never mention. You are required to argue, property by property, that it achieves what the listed techniques would have achieved.
Run that argument honestly for a trained network and it splits cleanly. Predictability and testability can be argued with bounded inputs, frozen weights and a statistical validation record. Understandability and completeness against an a priori specification mostly cannot. That split is why the learned element usually takes the lower SC, and a deterministic element with a higher SC carries the rest.
Three routes for a pre-existing element, and why proven in use fails
Edition 2 gives three ways to claim integrity for a software element you did not develop under the standard. They are stated in IEC 61508-3:2010 clause 7.4.2.12, and the Edition 3 draft folds the detailed proven-in-use rules into Clause 7 and extends them to SC 3 and SC 4.
Route 1S: compliant development
The element was developed to Part 3 from the start. This is the right route for the deterministic shell around a model: the supervisor, the interlocks, the range checks, the fallback controller. It is rarely available for the model itself, because training is not a development process that the Annex A tables recognise.
Route 2S: proven in use
This is the route people reach for, and for ML it does not hold. The technical specification limits proven in use to SIL 1 or SIL 2. It then requires that every claimed combination of input data, execution sequence and timing relation is documented, and that the combinations used in the new application have occurred in previous use with the same relative frequency. A model moved to a new plant, a new feedstock or a new season breaks the frequency condition by definition. The specification also notes that meeting these conditions does not make software deterministic, because hidden internal states can change execution. A recurrent or stateful model is that note in its purest form.
Route 3S: assessment of a non-compliant development
This is where a learned element lives in practice. Whatever route you take, the element must come with a safety manual precise and complete enough to assess the integrity of a safety function that depends on it, including every assumption on which its justification depends. For a model, the assumptions are the operational design domain: input ranges, sensor configuration, process envelope. The ODD stops being a data science artefact and becomes a normative document that the integrator must honour.
What Part 3 already covers in an ML stack
Most of an ML deployment is not the model. Part 3 already has clauses for the rest, and using them takes a lot of the novelty out of the case.
The inference runtime is a pre-existing element
The standard states that its requirements on pre-existing elements apply to a run-time library or an interpreter. An inference engine executing a network graph is exactly that. It needs its own route and its own safety manual, separate from the model it runs.
The training toolchain is an off-line support tool
Part 3 classes development tools as off-line support tools T1, T2 or T3. T2 and T3 tools need documented behaviour and an assessment of how they could fail; T3 tools need evidence that they conform to their specification. Our engineering reading, which is not a stated clause, is that a quantiser or graph compiler that emits the deployed artefact behaves like a T3 tool, and a trainer that only produces weights for later verification behaves like a T2 tool. Either way, the tool version, parameters and scripts go into the configuration baseline and get requalified on every new version.
The weights are data, and Part 3 has guidance for data
Edition 2 already carries an annex of guidance for tailoring lifecycles associated with data driven systems, and clause 6.2.3 requires that every configuration item needed for safety integrity is maintained with unique identification. Edition 3 moves the data-driven guidance into its own annex. Treating the frozen weight file as a uniquely identified configuration item, hashed and versioned like source code, is the cheapest requirement in the whole case to satisfy and the one most often missed.
Online learning reopens the lifecycle every time
The IET is direct about this. Where ML can affect safety, online learning is not consistent with conventional functional safety standards, because any change needs an impact assessment and re-verification before the system returns to service. The same guidance makes a point that is easy to miss: an AI system can raise the number of demands a safety-related system must respond to. A learned controller that pushes the process towards its limits more often can move a protection function from the low demand column into the high demand column.
There is one structural exception worth designing for. TR 5469 observes that where a known scientific relationship links the parameters that determine a function's behaviour, the model can be transparent and sufficiently complete, so compatibility with functional safety requirements can be demonstrated. A model built on the governing equations of the process sits closer to that case than a generic network fitted to the same data. That is a large part of why we derive the equations first. The release mechanics, freeze, sign, deploy and roll back, are in our edge AI deployment pipeline article.
A Part 3 mapping from a campaign we ran
In the OptiVX programme, Equation Labs was primary R&D partner to Gemino on the core AI and ML work package, with a controller acting on a living cultivation process. The figures below are as published on equation-labs.co. This is how we would line them up against Part 3.
| Part 3 artefact | ML evidence | Measured in OptiVX |
|---|---|---|
| Software architecture, Route 1S element | Deterministic safety layer between policy and actuator | Under 2 ms |
| Timing in the safety requirements specification | End-to-end inference path on edge hardware | 285 ms, from 1.2 s |
| Route 3S safety manual, assumptions of use | Model fit inside the stated envelope | R-squared above 0.95 |
| Software aspects of system safety validation | Statistical campaign plus physical rig | 400 simulated years, zero safety violations, 500 L pilot basin |
| Lifecycle and documentation | Phase records and transfer set | 29 work phases; IntelliBot transfer, 400+ pages |
Two caveats, stated plainly. No SIL and no systematic capability was claimed for this stack. The campaign was built so that the question could be put to an assessor, not to answer it in advance. And the simulated years are only evidence if the simulator itself is held to account, which is the subject of our sim-to-real transfer article.
Certification bodies are engaging with this structure. The SAFEXPLAIN project's AI functional safety management process, which maps the safety lifecycle onto the AI lifecycle with IEC 61508 among its references, was reviewed by Exida and TUV Rheinland and judged suitable for future certifiability. Suitable for future certifiability is not a certificate, but it shows the direction. How the lifecycle phases themselves are planned is covered under the functional safety life cycle, and the constraints of running monitor and model on one device under edge AI functional safety.
FAQ
Does IEC 61508 Edition 3 allow machine learning in a safety function?
The Part 3 draft brings AI algorithms into scope as software technology classes and refers to TR 5469 and TS 22440 for detail. It adds no ML-specific requirements of its own beyond hazard and risk analysis, so the argument still has to be built from the existing properties and routes.
Can a neural network be claimed proven in use under IEC 61508?
Practically, no. Proven in use is limited to SIL 1 and SIL 2 and requires every claimed input combination to have occurred in previous use at the same relative frequency. A model redeployed to a different process, plant or operating season cannot show that.
Is ISO/IEC TS 22440 published yet?
Not as of October 2026. Part 1, the requirements, is at committee draft stage, and its comment period closed on 11 April 2026.
Can an AI controller change the demand mode of a safety function?
Yes. If a learned controller drives the process towards its limits more often, the protection function behind it is called more often. That can move it from low demand mode into high demand mode, where the target becomes a failure frequency per hour. Recheck the demand rate after the controller is commissioned, not only at design.