Where AI can and cannot sit relative to a safety instrumented function

Most of the confusion in this area is vocabulary rather than engineering, so it is worth being precise before anything else.

An anomaly is a departure from an expected data pattern. An alert or notification is information sent to a person or a workflow, and it is not automatically a process alarm. An alarm is an indication requiring timely operator assessment or action under a site's alarm philosophy. A trip or interlock is logic that takes or prevents an action when defined conditions are met. And a safety instrumented function is a defined safety function with a required integrity across its sensor, logic solver and final element.

Those are five different things with five different sets of requirements, and a proposal that uses them interchangeably has not been engineered. Nearly every unsafe claim in this field is a category error between two of them rather than a technical mistake.

IEC 61511 requires the safety instrumented system to be independent of the basic process control system to the extent that its integrity is not compromised by anything the control system does. The purpose is to avoid common cause: a fault that disables both the layer that causes a demand and the layer that responds to it.

The word to notice is independence rather than separation. Physical separation is one way to achieve it and not the only one, and the applicable measure depends on the function and the architecture. Overstating it as a universal rule is a common error and it produces architectures justified on the wrong grounds.

For an analytics layer the consequence is direct. Reading information about safety system state through a proper read-only interface is generally acceptable. Writing into that path is not. Becoming something a safety function depends on, in the sense that the function would not achieve its required integrity without the analytics working, is not. If a proposal blurs that line, the answer is no regardless of the technical elegance.

The software in a safety function has to be justified, and the routes to justification include development to the required systematic capability, or evidence of proven use with a defined operating history and change record.

A machine learning component that adapts its own behaviour struggles with both. Systematic capability requires a development lifecycle with specification, verification and change control, and a model whose parameters move in response to data is changing without passing through that lifecycle. Proven in use requires that the thing in service is the thing that accumulated the history, and an adaptive model is not.

A model with frozen parameters, developed and verified under a proper lifecycle, treated as ordinary software, is a different proposition and does not have this problem. The distinction is whether the thing changes after it has been assessed, not whether it was built using machine learning in the first place.

That distinction is worth putting to any vendor claiming a role in a safety function: is the deployed artefact fixed, verified and under change control, and if it is, the conversation is about the assessment. If it is not, it is not a safety function component.

Informing hazard studies. A HAZOP or LOPA relies on assumptions about failure rates and demand rates that are frequently taken from generic data because plant-specific data was not available. Continuous operating history can replace some of those assumptions with measurements from this plant.

Measuring demand rate. A layer of protection analysis assumes an initiating event frequency. If a plant can count how often the condition actually arises, the analysis rests on evidence rather than on an estimate, and the answer can move in either direction.

Evidencing proof test intervals. Proof testing is scheduled on assumptions about degradation of the safety instrumented function's elements. Condition data on those elements supports a case for the interval being appropriate, or for changing it.

Detecting instrument degradation before it becomes a spurious trip or, worse, a failure to act on demand. A transmitter drifting is visible in cross-comparison long before it is visible as a fault, and spurious trips have their own safety consequence through the transients they cause.

All four sit outside the safety function, informing the engineering around it. That is where the value is, and it is substantial without requiring anything to be claimed about the function itself.

The practical architecture is a read-only path from the safety system to the analytics host, enforced somewhere the safety system can verify, with nothing flowing the other way and no dependency created in the reverse direction.

Enforcement matters more than intention. Rights on a server that the safety system itself applies, function code filtering on a device that inspects the protocol rather than only ports, or a unidirectional gateway that makes direction a physical property. The mechanisms are the same ones described in reading plant data without modifying the control system, applied with less latitude.

The dependency question is the subtler one and is worth asking explicitly at design: if the analytics host is switched off tomorrow, does any safety function behave differently. The answer has to be no, and it has to be demonstrable rather than asserted.

A functional safety assessor is going to ask a small number of specific questions, and having the answers written down before the meeting is most of the work.

What is the data flow, in which direction, and what enforces it. Which functions, if any, does the analytics contribute to, and at what claimed integrity. What is the failure behaviour of the analytics and what does it do to the plant. What is the change control on the analytics software, and does anything change in service without passing through it. And what is the competence and independence of whoever assessed the arrangement.

A proposal that answers those five clearly, and claims nothing about the safety function itself, is usually straightforward to approve. A proposal that claims a safety benefit and cannot describe its own change control is where these conversations become long.

Nothing here is a substitute for the applicable standard, the site's functional safety management arrangements or the assessor's own judgement. What is described is an architecture, not a compliance position.