Closing the gap: rethinking the middle ground for logic solvers in safety instrumented systems

For plant engineers working through a SIL verification, there’s a familiar fork in the road. You’ve identified a safety instrumented function, worked out the required safety integrity level, and now you need something to execute the logic. The options on the table usually look like this: a full safety PLC, capable of almost anything but expensive and often more than the application calls for, or a single-loop safety relay or trip amplifier, inexpensive and simple but limited to one input and one straightforward action.

For a lot of real-world SIFs, neither option fits well. A tank overfill protection scheme might need to monitor two redundant level transmitters, employ a 1oo2 voting scheme, and factor in a pump status signal before it trips a valve. That’s too much logic for a single loop device, but building a safety PLC project, complete with its own engineering, commissioning and lifecycle management, for one or two SIFs is hard to justify on cost grounds alone.

This gap between ‘too simple’ and ‘too much’ has been a persistent headache in functional safety design, particularly across Australian oil and gas, mining and water treatment sites where SIFs are often scattered rather than concentrated in one central location.

What sits in the middle

A newer category of safety logic solver, sometimes called a multiloop or multifunction safety logic solver, has emerged to address exactly this space. These units typically handle multiple input/output channels, support voting architectures such as 1oo2 or 2oo3, and include enough built-in maths and logic to cover moderately complex SIFs without requiring a complex programming environment.

Devices built for this space are now available from several instrumentation manufacturers, typically certified to IEC 61508:2010, with systematic integrity to SIL 3 and random integrity to SIL 2 in single-use, extending to SIL 3 in redundant configurations. In practice, that means they can be specified for an expansive range of SIFs, from a simple high-high alarm through to a multi-transmitter voting scheme, without engineers needing to over-specify a safety PLC just to get the voting logic they need.

What’s worth noting for plant and process safety managers is that these new logic solver offerings have a direct and positive effect on project economics and safety lifecycle costs. A device that can be configured through dropdown menus, radio buttons, voting logic checkboxes, and straightforward Excel-like equations, rather than complex ladder logic or function block programming, drastically reduces the overhead associated with commissioning and later modifying a SIF. This matters on sites where instrumentation and controls resources are stretched thin, which describes to many engineers the environment they find themselves in today.

Why this matters beyond the spec sheet

There’s a practical safety argument here too. When the only tools available are ‘too basic’ or ‘too complex’, safety practitioners or engineers sometimes end up either under-engineering a SIF (stretching a single loop device past what it was designed for) or over-engineering it (routing a simple trip through a full safety PLC, adding complexity and points of failure that weren’t necessary). Neither outcome is ideal from a functional safety management perspective, and both can complicate proof testing and lifecycle documentation down the track.

A properly selected logic solver gives engineers a solution that’s proportionate to the actual risk and complexity of the SIF in front of them. That’s not a small thing when you consider how much of the total cost of a safety system sits in engineering hours, documentation and ongoing maintenance rather than hardware alone.

For plants requiring safety instrumented functions, this middle category of logic solver functionality is worth a look during the next safety system review or SIL verification cycle.

A question worth asking at the next HAZOP or LOPA review

The broader point for anyone involved in specifying safety instrumented functions is to resist defaulting to the same two options out of habit. As SIFs get reassessed during a LOPA or HAZOP revalidation, it’s worth asking whether the logic solver originally chosen still fits the complexity of the function, or whether a mid-tier option would now do the job more efficiently — and with less unnecessary overhead — than the original selection.

That’s a conversation worth having with your instrumentation supplier or functional safety consultant before the next capital works cycle locks in another like-for-like replacement.

Image credit: iStock.com/kunagorn