18.3 Modification, Decommissioning, and MOC
Key Takeaways
- ISA/IEC 61511-1:2018 Clause 17 requires management of change with impact analysis before modifying a SIS; changes that affect safety return the lifecycle to the appropriate earlier phase and require re-verification and re-validation of impacted SIFs.
- Changing a trip from 80% to 90% is an SRS change that can shorten process safety time, alter demand rate and sensor accuracy at the new point of range, and invalidate LOPA independent-protection-layer credit until SIL and LOPA are re-verified.
- Voting, maximum bypass duration, and logic-solver firmware are modifications: they change architecture, time-at-risk, or systematic capability and cannot be treated as operations preferences.
- Bypassing an independent protection layer that LOPA credited leaves residual risk that must be assessed; compensating measures and a time limit are MOC issues, not informal workarounds.
- Clause 18 decommissioning is allowed only after confirming the hazard is gone or remaining protection layers meet risk criteria; leaving a SIF in service after the process changed can protect the wrong scenario or nuisance-trip the new envelope.
Why MOC is the last safety-lifecycle gate on the exam
NCEES PE Control Systems 2027 item 5.G tests modification and decommissioning / management of change. ISA/IEC 61511-1:2018 Clause 17 (modification) and Clause 18 (decommissioning) are the supplied-standard counterparts. A SIF that was correctly validated can be made wrong by a one-line setpoint change, a “temporary” 72-hour bypass that never comes off, a firmware patch, or a process revamp that nobody mapped back to LOPA. MOC is the mechanism that forces impact analysis before the change, then verification and validation after it.
Clause 17 requires a procedure: identify the change, analyze impact on functional safety, authorize competent approval, implement only the approved scope, update documentation, and re-verify and re-validate impacted SIFs. Application-program and firmware changes typically need validation of every SIF those changes can touch, not a smoke test of one loop. Returning to an earlier lifecycle phase is required when the change affects hazard analysis, allocation, SRS, design, or SIL verification—not only when someone replaces a like-for-like transmitter.
Changes that look small and are not
Trip point. The setpoint is an SRS parameter. Moving it changes where the SIF acts relative to the hazardous event, the remaining process safety time, possible demand rate, and whether the sensor still has accuracy and overrange margin at the new point of the calibrated range.
Voting. Changing 1oo2 to 2oo3 (or 1oo1 to 1oo2) is an architecture change. PFDavg, spurious trip rate, hardware fault tolerance, common-cause modeling, and the SRS voting statement all move. Wiring, application program, HMI discrepancy handling, and proof-test procedures move with them.
Bypass duration. The maximum allowed bypass time is a time-at-risk constraint. It contributes to average unavailability. Stretching “4 hours with a dedicated operator” to “72 hours until the specialist arrives” is a LOPA and SRS change, even if the bypass key is the same key.
Firmware. Logic-solver or smart-positioner firmware is part of the systematic capability argument. A vendor “patch” can change diagnostics, timing, or I/O behavior. Configuration control, impact analysis, and validation of impacted SIFs are required. Loading firmware because the technician was already in the cabinet is not MOC.
Bypassed IPL in LOPA. LOPA assigned risk reduction to specific independent protection layers. If that IPL is bypassed—SIF, relief path, interlock, or BPCS function credited as an IPL—the residual risk is the scenario without that credit. MOC must show compensating measures, a duration, and that remaining IPLs still meet the company’s risk criteria. A verbal “we’ll watch it” is not an IPL.
Worked example: operator requests 80% to 90%
SIF-201 still trips V-201 high pressure at 8.0 barg, which is 80% of a 10.0 barg URV. The PSV is set at 10.0 barg. Process safety time in the SRS was 12 s, measured from the 8.0 barg demand to the hazardous overpressure if no SIF action occurs. Operations asks to raise the trip to 9.0 barg (90%) because normal swings cause spurious trips during feed-gas composition changes.
Impact on the SRS: the demand/trip setting is now 9.0 barg. Reset, bypass, and voting statements may stay, but the functional requirement changed. The 80% figure on the cause-and-effect chart, the HMI, the proof-test procedure, and the SAT record are all wrong until updated.
Impact on process safety time and SIL: the process is closer to the PSV/MAWP when the SIF finally acts. The 12 s process safety time cannot be reused without recalculation from 9.0 barg. If the new PST is 5 s and the installed valve still needs 6 s to close (the SAT number from 18.1), the SIF cannot meet the new timing even if it met the old 6-of-12 s criterion. Sensor accuracy, damping, and overrange behavior at 90% of URV must be confirmed. Spurious-trip complaints may mean the demand rate or noise assumption in verification was wrong; raising the trip without fixing filtering or voting can trade nuisance trips for a late trip.
Impact on LOPA: the SIF’s IPL credit required it to act in time and to be independent. Shorter PST can remove that credit. Initiating-event frequency may change if the unit now runs closer to the limit. Other IPLs (PSV, operator response) may see a different time to act. The LOPA worksheet and any SIL target derived from it must be reopened. If residual risk is then too high, options are restore 80%, speed up the final element, add an IPL, or change the process—not a silent 90% download.
The correct path is MOC: PHA/LOPA review, SRS revision, SIL re-verification including timing, application-program change control, re-validation (timed SAT of the new setpoint), proof-test procedure update, and operator training. The incorrect path is “operations preference, same SIL.”
Decommissioning a SIF — and the reverse trap
Clause 18 decommissioning is appropriate when the hazard the SIF exists to prevent is gone, or when remaining protection layers meet risk criteria without that SIF. Examples: the vessel is permanently removed, the inventory is substituted to a non-hazardous fluid, or an inherent-safety change eliminates the scenario. The review must check adjacent SIFs that shared sensors, solenoids, or valves; operating procedures and bypass lists; proof-test schedules; P&IDs; SRS; and LOPA. Physically isolate so the decommissioned function cannot be left in a half-alive bypass. Removing the logic while leaving a valve that still strokes on another SIF is not decommissioning of the shared final element.
The reverse trap is leaving the SIF in service after the process changed. A unit revamp raises throughput, changes composition, or adds a recycle. The old 80% trip may now sit inside the new normal envelope (nuisance trips, then bypasses) or may sit too far from the new hazardous event (no protection). A SIF that is “still there” is not automatically still the right IPL. Process change is a Clause 17 modification of the SIS context even if no wire is lifted. Re-run allocation and SRS; decommission if the function is obsolete; redesign if the new hazard needs a different SIF.
Change versus required re-verification
| Change | SRS update | SIL re-verification | LOPA / IPL review | Re-validation / proof-test update |
|---|---|---|---|---|
| Trip 80% → 90% | Yes — setpoint and likely PST | Yes — timing, accuracy, demand rate | Yes — IPL credit and initiating frequency | Yes — timed test at the new setpoint |
| Voting 1oo2 → 2oo3 | Yes — architecture | Yes — PFD, spurious trip rate, HFT, CCF | If IPL credit or nuisance-trip assumptions change | Yes — voting, discrepancy, and degraded-mode tests |
| Bypass max 4 h → 72 h | Yes — time-at-risk constraint | Yes — bypass unavailability term | Yes — duration without that IPL | Yes — bypass procedure and logging |
| Logic-solver firmware | Configuration baseline | Impact analysis; systematic capability | If SIF behavior or diagnostics change | Yes — impacted SIFs, not a single smoke test |
| IPL credited in LOPA is bypassed | Operating constraints | If the SIF itself is the bypassed IPL | Always — residual risk without that IPL | Compensating measures must be specified and testable |
| Hazard gone; decommission SIF | Remove SIF from SRS | Remaining SIFs that shared hardware | Confirm remaining IPLs meet criteria | Isolate, drop from test schedule, update procedures |
| Process envelope changed; SIF left as-is | Must review; likely yes | Likely — new PST, demand rate, independence | Must — new or obsolete scenarios | Likely — old SAT no longer matches the process |
MOC records, updated SRS, re-verification, and re-validation are the exam artifacts. “We will document it after start-up” is how a validated SIF becomes an unvalidated modification.
An operator requests changing a high-pressure SIF trip from 80% to 90% of transmitter range to reduce spurious trips. What is the required MOC view of SRS, SIL, and LOPA?
When may a SIF be decommissioned, and what is the reverse trap after a process change?
You've completed this section
Continue exploring other exams