CASE
STUDY
TWENTY YEARS, NO SRS:
RECONSTRUCTING SAFETY REQUIREMENTS FOR A PETROCHEMICAL UNIT
A petrochemical operator planning a unit revamp discovered it had no safety requirements specification for safety instrumented systems that had been in service for two decades. The SRS was reconstructed from the installed systems before the revamp proceeded.
| Challenge | Solution | Result |
|---|---|---|
| Safety instrumented systems in service twenty years with no SRS. | SRS reconstructed from as-installed systems and process hazard records. | A complete, maintainable SRS that the revamp could be specified against. |
Project Background
The operator was planning a revamp of a petrochemical unit that would modify process conditions and add equipment. Early in the project the engineering contractor asked for the safety requirements specification so that the effect of the modifications on the existing safety instrumented functions could be assessed. There was none. The unit had been commissioned two decades earlier under an engineering practice that documented the installed system in drawings and cause-and-effect charts but produced no SRS. Subsequent modifications had updated the drawings and left no record of safety requirements, because there was no document to update.
Without an SRS the operator could not say what its safety instrumented functions were required to do, only what they currently did. That distinction matters because a cause-and-effect chart records the implemented logic, not the requirement the logic was meant to satisfy. If a trip setting had been adjusted at some point in twenty years, nothing existed to say whether the new setting still met the original intent, or what the original intent had been.
The revamp made the gap urgent rather than merely untidy. Assessing the effect of a process change on a safety instrumented function requires knowing the function's requirements: the hazard it addresses, the process safety time, the required response, the safe state and the SIL target. Without those, the contractor could assess the effect on the implemented logic and not on the safety requirement, which is a materially weaker assessment and one the operator did not want to rely on for a modification affecting process conditions.
Reconstruction also carried a risk the operator was alert to. Writing an SRS by documenting what is currently installed produces a specification that validates the existing system by definition, including any errors in it. The exercise had to work forward from the hazards rather than backward from the logic, while still accounting for what was physically installed.
Arista Cyber reconstructed the SRS from the process hazard basis rather than from the installed logic, then reconciled the two, so that discrepancies surfaced as findings instead of being written into the specification.
Hazard Basis Review
Reviewed existing HAZOP and process hazard records to establish which hazards each safety instrumented function was intended to address.
Safety Function Definition
Defined each function from the hazard: initiating condition, required action, safe state and the process safety time available.
As-Installed Reconciliation
Compared each defined requirement against the installed logic, instrumentation and trip settings, and recorded every discrepancy.
Discrepancy Resolution
Worked through discrepancies with operations and engineering to determine whether the requirement or the implementation was correct.
SRS Authoring
Produced the safety requirements specification to IEC 61511 content expectations, covering functional and integrity requirements for every function.
Revamp Impact Basis
Delivered the SRS in a form the engineering contractor could assess the revamp modifications against.
Maintenance Handover
Established ownership and a management of change path so the SRS stays current rather than becoming another historical document.
The unit now has a safety requirements specification covering every safety instrumented function, stating what each function is required to do and why, with the hazard basis traceable behind it. The revamp was specified and assessed against that document rather than against a cause-and-effect chart.
The reconciliation step was where the value appeared. Working forward from the hazards and then comparing against the installed systems surfaced discrepancies that neither the drawings nor the operating experience had revealed, because the installed system had been internally consistent for twenty years and therefore looked correct. Some discrepancies were benign, reflecting a deliberate decision nobody had recorded. Others were not, and those became findings the operator addressed on their own merits rather than discovering them during the revamp or after an incident.
The handover arrangement matters as much as the document. An SRS reconstructed at considerable effort and then left unowned decays at the first modification, which is how the original gap formed. Assigning ownership and tying the SRS into the management of change process means the next modification updates it, and the operator does not face the same reconstruction exercise in another twenty years. The specification is also now the reference point for SIL verification, which the operator can commission knowing what the functions are actually required to achieve.
Who Should Engage Arista Cyber?
Operators with safety instrumented systems lacking a safety requirements specification, those facing a revamp or modification where the effect on safety functions must be assessed, and anyone whose SRS exists but has not been updated through successive modifications.
What's the Next Step?
Ready to establish what your safety instrumented functions are actually required to do? Contact Arista Cyber to scope an SRS engagement.
- Commission a safety requirements specification for your safety instrumented systems
- Request an SRS gap review before a planned revamp or modification
- Schedule a functional safety lifecycle assessment