A Safety Requirements Specification is the key document that translates hazard and risk decisions into requirements for Safety Instrumented Functions. Without a clear SRS, a project can have a correct SIL assessment but still deliver a SIF that trips at the wrong setpoint, acts too slowly, uses the wrong voting, cannot be tested effectively or does not move the process to the intended safe state.
The SRS is therefore more than a tag list or cause-and-effect table. It should provide enough information for design, programming, verification, validation, operation and maintenance to understand what each SIF is required to do and what assumptions must remain true through its lifecycle.
Where the SRS sits in the functional safety lifecycle
The IEC 61511 functional safety lifecycle begins with hazard and risk assessment and allocation of risk reduction. Once a SIF has been identified and its target SIL established, the requirements need to be formally specified.
The SRS becomes the controlled reference against which the SIS design and later validation are checked.
Define the SIF purpose
Each SIF should have a concise description of the hazardous condition it protects against and the action it performs. For example, “On high-high separator pressure, isolate inlet gas to prevent vessel overpressure.”
This statement connects the function to the underlying risk scenario. It is more useful than a generic label such as “ESD trip.”
Define the initiating process condition
The SRS should identify the process variable or condition that triggers the SIF. This may be pressure, level, temperature, flow, gas detection or another measurable state.
The measurement range, units and relevant process conditions should be clear. Where multiple sensors are used, their voting arrangement should also be defined.
Specify the trip setpoint
The trip setpoint should be based on the process safety requirement rather than selected only from normal operating experience. It must allow enough margin between normal operation, alarm action, trip action and the hazardous limit.
Instrument accuracy, process dynamics, measurement lag and reset behaviour may also be relevant.
Define the safe state
The SRS should state the final action required to achieve or maintain a safe state. This may involve closing isolation valves, stopping rotating equipment, opening a depressurisation valve or executing a defined shutdown sequence.
Where multiple final elements are involved, their required positions and sequence should be explicit. “Trip plant” is often too vague for a safety requirement.
Specify process safety time and response time
Process safety time is the interval between development of the hazardous condition and the point at which the consequence can no longer be prevented by the SIF. The function must complete its action within the required time.
The SRS should therefore include a maximum response time or sufficient information to derive it. This requirement later supports design and validation.
Document the SIL target
The target Safety Integrity Level should be linked to the approved risk assessment or LOPA scenario. This preserves traceability and helps future reviewers understand why the function has that integrity requirement.
If the target depends on specific credited IPLs or conditional modifiers, those assumptions should remain accessible in the supporting risk records.
Define sensor voting and architecture requirements
The SRS should specify voting where required, such as 1oo1, 1oo2 or 2oo3 sensing. It may also define separation, diversity or independence requirements where these are important to the hazard scenario.
The final architecture is then checked during SIL verification.
Reset and restart philosophy
Some SIFs should latch after activation and require deliberate reset. Others may allow automatic reset under controlled conditions. The correct philosophy depends on the process hazard and operating strategy.
The SRS should define who can reset the function, what process conditions must be satisfied and whether additional checks are required before restart.
Bypass and override requirements
Maintenance may require a sensor, trip or final element to be bypassed. The SRS should identify whether bypass is permitted and what compensating measures or alarms are required.
Bypasses should be visible, controlled and time-limited. Our guide to proof testing and bypass management covers the operational implications in more detail.
Proof-test interval and testing requirements
The proof-test interval assumed in SIL verification should be recorded in the SRS or linked lifecycle documentation. The requirement should be achievable by the operating organisation and supported by an appropriate test procedure.
Where partial-stroke testing or online diagnostics are credited, the basis and required frequency should also be documented.
Environmental and process conditions
Field devices may be exposed to temperature extremes, vibration, corrosive service, hazardous areas, weather, fouling or other conditions that affect reliability. Requirements that influence device selection should be included or referenced.
A SIF designed without considering the actual service environment may meet a paper calculation but perform poorly in operation.
Interfaces with other systems
The SRS should identify relevant interfaces with the Basic Process Control System, fire and gas system, electrical systems, package controls and other shutdown layers. Shared components and dependencies need to be understood.
Where information is passed between systems, the required behaviour on communication failure should be clear.
Manual actions and operator interaction
If an operator action is part of the SIF or is required after a trip, the action should be specified clearly. Alarm presentation, response time and required controls should be consistent with the risk analysis.
Manual intervention should not be left as an unwritten assumption.
Validation requirements
The SRS is the basis for safety validation. Test cases should demonstrate that the installed function meets the specified trip condition, voting, safe state, timing, latching, bypass and interface requirements.
If a requirement cannot be tested, it may not be specified clearly enough.
Manage SRS changes through MOC
Changes to setpoints, voting, final elements, test intervals or bypass philosophy can alter the risk performance of the SIF. SRS changes should therefore be controlled through the project or facility Management of Change process.
The associated HAZOP, LOPA and verification basis may also require review.
What makes an SRS useful?
A useful SRS is specific, traceable and testable. It avoids copying generic statements into every SIF and focuses on requirements that designers and operators can implement and verify.
It should also distinguish the function from the overall SIS platform, so requirements remain tied to the actual safety function.
SRS development support
Pro Engineers supports SIF definition, SRS development, SIL verification and functional safety assessment alongside HAZOP and LOPA activities.
For development or review of a Safety Requirements Specification for a project or brownfield modification, contact Pro Engineers.