A supervisory platform writing into a SIL 2 trip loop
A pharmaceutical API plant runs a SIL 2 overpressure trip on a hydrogenation reactor in a certified SIS, with independent transmitters and a dedicated logic solver. The site proposes that Glacier Fabricant, running on a Windows server in the plant DMZ, be permitted to (a) write optimised setpoints to the BPCS and (b) nudge the SIS trip point during soft starts to avoid spurious trips. Glacier is domain-joined to corporate Active Directory. The SIS programming terminal currently sits on the same VLAN as the BPCS. A vendor support tunnel uses a shared local-admin credential and is enabled 24/7. Corporate IT reported ransomware in the enterprise two weeks ago. The SIS vendor states in writing that any write to the logic solver must originate from the safety application, and that trip-point changes require the key switch and a documented management of change. Reliability data: a single Glacier application server with no redundancy, 4 h MTTR, and a calculated availability of 99.1% against a 99.5% target for the supervisory layer.
1. Evaluate both proposed write paths and state what you will and will not implement.
Read the worked answer
Path (b) - writing or nudging the SIS trip point: refuse.
The trip point is part of the safety instrumented function. Changing it dynamically from a non-safety-rated platform breaches the safety lifecycle in three ways: the modified setpoint has not been assessed for the required SIL, the change has no management of change, and the write path introduces a non-safety-rated node into the logic solver's input. The vendor's written statement that writes must originate from the safety application is not a preference - acting against it invalidates the certification basis of the SIS. The spurious-trip problem is real, but the correct fixes are in the cause (transmitter voting, start-up bypass designed and approved within the SIS, or a properly engineered and validated setpoint change under MOC), not a live nudge from a Windows server.
Path (a) - optimised setpoints to the BPCS: conditionally acceptable, advisory-first.
Acceptable only if: Glacier cannot be credited as an independent protection layer in any cause-and-effect; the BPCS in question performs no safety function for this reactor; writes are bounded by hard range and rate limits enforced in the BPCS, not only in Glacier; every automatic write is logged with the model version and rationale; and an operator confirms or a time-limited auto-accept is explicitly approved by process safety. Start with advisory-only for a defined period and measure the accept rate and the outcome before enabling writes.
What I would put in writing. A design decision record stating that no data path from Glacier to the SIS logic solver will exist, with the risk assessment reference and the SIS vendor statement attached.
2. Design the zone and conduit architecture and the remote-access controls you would require.
Read the worked answer
Start from the asset inventory and the safety consequence, then place zones.
Zones.
- Safety zone: SIS logic solver and its engineering workstation. Highest restriction.
- Control zone: BPCS, plus the Glacier server if it writes to the BPCS.
- Supervisory/DMZ zone: Glacier Fabricant reporting, historian replica, remote-access jump host.
- Enterprise zone: corporate AD and IT.
Conduits.
- Safety zone to any other zone: no routed connection. Engineering access is by a local, physically controlled connection with the key switch, and the SIS programming terminal comes off the BPCS VLAN immediately - that shared VLAN is a finding in itself.
- Control to supervisory: firewall with an allowlist of specific addresses and OPC UA/MQTT ports, stateful inspection, no inbound initiation from supervisory into control except for the defined read/write pairs.
- Supervisory to enterprise: no direct trust. Glacier should not be a member of the corporate domain; use a separate identity store or a one-way trust with tightly scoped service accounts. Ransomware two weeks ago in the enterprise makes this urgent, not theoretical.
Remote access. Remove the shared local-admin credential. Per-user accounts with MFA, session recording, least privilege, time-limited enablement tied to a ticket, and automatic disable. The tunnel should be off by default and enabled per session, terminating on a jump host in the DMZ, never reaching the control or safety zones directly. Log and review every session.
Supporting controls. Patch management for the Glacier server and its OS, application allowlisting, backup and restore tested, and a documented incident response path that includes the safety zone.
3. The site asks whether 99.5% availability is achievable. Assess the numbers and specify what changes.
Read the worked answer
Run the arithmetic before answering, because the answer drives the architecture.
The budget. 99.5% availability is 0.5% downtime, about 43.8 h/yr. At the current 4 h MTTR that permits roughly 10.9 failures per year. The stated 99.1% implies MTBF of about 440 h - an unremarkable figure that yields close to 19 failures per year and about 79 h of downtime. So the design is short by roughly a factor of two on downtime, and it is short on failure frequency, not on repair speed alone.
Levers, in order of cost-effectiveness.
- Reduce MTTR. Cutting MTTR from 4 h to 1 h lifts the achievable availability to about 99.5% at the current failure rate. That means tested restore procedures, a documented rebuild image, spare disks, and a support contract with a response time, not just a phone number.
- Reduce failure frequency. Patch discipline, monitoring of disk and service health, and removal of the corporate domain join (which imports enterprise patching and reboot behaviour into an availability-critical node).
- Add redundancy. Redundant application servers with automatic failover add cost and add their own failure modes; unless failover is tested and the failover time counted as downtime, it will be asserted rather than demonstrated.
What I would state. 99.5% is achievable, primarily through MTTR reduction and failure-frequency control, and the target should be defined precisely - is it the server, the data path from the DCS, or the reporting function? Then define how it will be measured, because an availability figure that is never measured is a marketing number.