Every safety instrumented function has three parts that work in sequence: a sensor that detects the hazard, a final element that acts, and a decision-maker in the middle that reads the sensor and commands the final element. That middle role is the logic solver. This page treats the logic solver as a function within a safety loop rather than as a piece of hardware, so it complements rather than repeats a general safety-PLC description.
Logic Solver in one line: A logic solver is the controller in a safety instrumented function that receives sensor inputs, evaluates the trip logic against them, and issues the command to drive the final elements to their safe state. It is the decision-making subsystem of the loop, sitting between sensors and final elements, and it carries its own share of the loop's probability of failure on demand.
A safety instrumented function is best understood as a chain of three subsystems: sensors, the logic solver, and final elements. The sensors report the process condition, the final elements bring the process to a safe state, and the logic solver is the part that decides whether a trip is warranted and then commands it. It is the reasoning step in the loop, and every trip has to pass through it.
What the logic solver actually does is compare live inputs against configured trip settings and apply the voting and cause-and-effect rules the safety engineer specified. A cause-and-effect matrix lists which detected conditions, the causes, must produce which output actions, the effects, and the logic solver is the engine that enforces that matrix on every scan. When a monitored input crosses its trip point, or when a voted group of inputs agrees that a hazard is present, the logic solver drives the corresponding outputs to their safe state.
Treating the logic solver as a role, not a box, matters because the same physical controller may host many independent safety functions, each with its own sensors, trip logic, and final elements. The hardware is shared, but each function is evaluated on its own terms. Keeping the loop-level view in mind is what lets engineers reason about one function's integrity without getting lost in the controller that happens to run it.
A logic solver used for safety is deliberately not an ordinary control controller. It is built and certified so that its own failures are either detected and driven to the safe state or are extremely unlikely to leave a trip command unexecuted. Internal diagnostics run continuously, and the design assumes that the safe state is reached by removing a signal, so that losing power or losing the controller itself still trips the process rather than stranding it.
The logic solver also contributes its own probability of failure on demand to the loop. When engineers total the safety function's PFD, the logic solver's share sits alongside the sensor share and the final element share, and although it is often the smallest of the three, it is never zero. Its diagnostic coverage, its architecture, and how often it is proof tested all feed into that number.
Just as importantly, a safety logic solver is kept functionally separate from the basic process control that runs the plant day to day. Independence between the layer that operates the process and the layer that protects it means a fault or a bad change in normal control cannot silently disable the protection. The logic solver is the guardian of that separation on the decision side of the loop.
The logic solver executes trips autonomously and does not wait for a supervisory system to act, but operators still need to see what it is doing. Trip status, which inputs are in alarm, whether any input is bypassed or forced, and when the last demand occurred are all information the wider monitoring layer should surface. Visibility into the logic solver is what turns a silent guardian into something a crew can trust and audit.
SCADA and cloud monitoring sit above the logic solver as a window, not as a controller. They read and display the safety function's state so that operators know a valve tripped closed, engineers know which cause fired, and compliance staff can see the history of demands and bypasses. The safety action itself remains inside the certified logic solver, where it belongs, while the record and the operator awareness live in the monitoring layer.
Merobix reads that status into a browser dashboard so a supervisor watching an unattended site can see a trip the moment it happens, know which detected condition caused it, and confirm no safety inputs are left in bypass after maintenance. The logic solver keeps making the decisions on its own, and the cloud layer makes those decisions and their history visible to the people responsible for the process.
A safety PLC is one common way to build a logic solver, but the logic solver is really the role that piece of hardware plays in the safety loop. Relays, solid-state trip units, or certified controllers can all serve as logic solvers. Thinking in terms of the role keeps the focus on the function rather than the brand of hardware.
It sits in the middle, between the sensors and the final elements. Sensors feed it the process condition, it evaluates the trip logic, and it commands the final elements to the safe state. It is the decision-making subsystem of the three that make up the function.
Yes. A logic solver executes its trip logic autonomously and drives the outputs to the safe state without waiting for an operator or a supervisory system. Monitoring layers can display what it did, but the decision and the command originate in the logic solver itself, which is why it must be certified and kept independent from normal control.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.