The development of the SIS SRS is one of the most important activities of the whole SIS safety life cycle. It is through this specification that the user is able to define how he wants each SIF to be designed and integrated into a SIS. Final validation of the SIS is carried out using this specification. The safety requirements shall be derived from the allocation of Safety Instrumented Function (SIF) and from those requirements identified during the Hazards and Risk Assessment.
It lists the design intent of the SIS, every detail of its design specification, and a slew of information needed during the operational phase, such as maintenance requirements. The SRS is first document when the need for the SIS is identified; this takes place immediately after risk analysis is completed. Then, after the full design details of the SIS have been elaborated, the SRS is updated to contain all the information necessary for complete execution of the lifecycle.
The purpose of having a centralized document of this type is to provide a single point of reference for all parties responsible for each phase of the lifecycle. Since the people involved are likely to be spread across many departments and organizations, it is critical to have an unambiguous definition of the SIS’s function and operation. Indeed, some of them will be performing their duties many years after the SIS is commissioned.
Another important function of the SRS is to provide a benchmark, against which the SIS itself can be validated, and its performance assessed. This allows reviewers to confirm or revise assumptions made during the safety analysis and SIS design periods.
The SIS requirements shall be expressed and structured in such a way that they are.
• Clear, precise, verifiable, maintainable and feasible.
• Written to aid comprehension and interpretation by those who will utilize the information at any phase of the safety life cycle.
These requirements shall be sufficient to design the SIS and shall include a description of the intent and approach applied during the development of the SIS safety requirements as applicable.
When is the SRS developed?
A reasonable approach is to develop the SRS in three stages.
Stage 1: An initial draft of the SRS should be developed at the end of the risk analysis section of the lifecycle. This draft is sometimes known as the “process SRS” or (the term we’ll use in this book) the “preliminary SRS.” At this point, only a subset of the complete SRS data will be available.
Stage 2: During basic SIS design, parameters such as the SIS’s mission time and preferred proof test interval should be defined. These should then be documented in an updated SRS, for use as input to SIL verification.
Stage 3: After completion of the SIL verification, all required SRS data should be available. At this point, a full SRS should be developed. This is sometimes known as the “design SRS” or “detailed SRS.” A detailed SRS is a
prerequisite for moving into the construction and commissioning phase.
There are ~ 28 requirements for Safety Requirements Specifications defined in IEC-61511-1:2016, define below.
1. Description of All SIFs
A description of all the SIF necessary to achieve the required functional safety (e.g., a cause-and-effect diagram, logic narrative).
Specify sensors, logic solver, voting and final elements. Define the trip direction (e.g. “pressure high”) and action (e.g. “close XV-1234”). This can be done in words or as a logic diagram. Each SIF’s design intent (why the SIF is needed) should also be specified.
2. Input and Output Devices
A list of the plant input (e.g. sensors) and output devices (e.g. actuators) related to each SIF which is clearly identified by the plant means of equipment identification (e.g., field tag list).
Tag numbers of sensors and final elements (if not already covered in item 1). Equipment brand and model (or a reference to a separate equipment list). Also include any auxiliary input/output devices such as valve limit switches, if needed as part of diagnostics.
3. Common Cause Failures
Requirements to identify and take account of common cause failures.
4. Definition of Safe State
A definition of the safe state of the process for each identified SIF, such that a stable state has been achieved, and the specified hazardous event has been avoided or sufficiently mitigated.
The process state that the SIF must achieve, to prevent or mitigate the harm. This is often misinterpreted as defining the state of the SIF (e.g. “XV-1234 closed”), but that would be just a repeat of information in item 1. Here, we should define the required state of the process system protected by the SIF (e.g. “No overpressure
of Separator D-100”). This is more meaningful as an input to future lifecycle activities including validation and Management of Change.
5. Combined State
A definition of any individually safe process states which, when occurring concurrently, create a separate hazard (e.g., overload of emergency storage, multiple relief to flare system).
Definition of any individually safe process states which, when occurring concurrently, create a separate hazard. For example, if multiple blowdown SIFs act simultaneously, the relief system may be overloaded. As a result, the SIS can be designed for staggered blowdown. This needs to be specified in the SRS.
6. Sources of Demand and Demand Rate
The assumed sources of demand and demand rate on each SIF. For example, demand is caused by basic process control system failure, and this is expected once every 10 years.
List the demand causes for each SIF, identified during HAZOP and considered during the SIL assessment.
7. Proof Test Intervals
Requirements relating to proof test intervals.
8. Proof Test Implementation
Requirements relating to proof test implementation. The maximum intended interval between proof tests, for each element of the SIF. Different intervals can be defined for each element if desired.
Specify any features such as bypasses needed to achieve proof testing, including partial valve stroke testing. Provide a reference to the proof test procedure for each testable device, or other justification for the proof test coverage values assumed in the SIL verification.
If proof testing is intended to be done with the process still running (online), define any additional protection needed while the SIF is unavailable, such as reduced throughput or extra personnel to monitor process hazards manually. In IEC 61511 this is known as a ‘compensating measure.’
9. Response Time Requirements
Response time requirements for each SIF to bring the process to a safe state within the process safety time.
The maximum allowed time from when the process reaches trip condition (e.g. high pressure) until the final elements complete their action. It would be advisable not to specify a shorter time than necessary, to avoid problems during validation if a short response time cannot be achieved. 1 min is a reasonable default, except for critical cases.
Traditionally, the response time has been set at 50% of the process safety time, but there is no specific basis for this. Note, it is not necessary to specify the response time for each subsystem (sensors, logic solver
and final element) individually.
10. Required SIL and Mode of Operation
The required SIL and mode of operation (demand/continuous) for each SIF. Safety Integrity Level represents design targets for systematic capability of the equipment, PFDavg or PFH verification numbers and architecture constraints.
11. SIS Process Measurements
A description of SIS process measurements, range, accuracy and their trip points. The process variables measured by the SIF, required trip points, and whether to trip on high or low value (or logic 1/0 for discrete
measurements).
The range and accuracy requirement for the instruments used to measure the process variables (only applicable to analog measurements).
12. SIF Process Output Actions
A description of SIF process output actions and the criteria for successful operation, e.g., leakage rate for valves.
13. Functional Relationships
The functional relationship between process inputs and outputs, including logic, mathematical functions and any required permissives for each SIF.
14. Manual Shutdown
Requirements for manual shutdown for each SIF. Specify any hand switch (or other means, such as a pull wire on a conveyor) required to trip the SIF manually. If no manual trip is required, this needs to be stated here.
15. Energize/De-energize to Trip
Requirements relating to energize or de-energize to trip for each SIF.
16. Reset Requirements
Requirements for resetting each SIF after a shutdown (e.g., requirements for manual, semiautomatic,
or automatic final element resets after trips).
Specify the facilities needed to reset SIFs after a trip, e.g. pushbuttons. Specify whether any SIFs will auto-reset and, if so, the conditions for reset including time delay. In general, low demand mode SIFs should remain in the tripped state and not auto-reset unless there is a clear operational need.
17. Spurious Trip Rate
Maximum allowable spurious trip rate for each SIF.
18. Failure Modes
Failure modes for each SIF and desired response of the SIS (e.g., alarms, automatic shutdown).
19. Startup/Restart Procedures
Any specific requirements related to the procedures for starting up and restarting the SIS.
20. Interfaces with Other Systems
All interfaces between the SIS and any other system (including the BPCS and operators).
21. Plant Modes of Operation
A description of the modes of operation of the plant and requirements relating to SIF operation within each mode.
22. Bypass Procedures
Requirements for bypasses including written procedures to be applied during the bypassed state which describe how the bypasses will be administratively controlled and then subsequently cleared.
23. Action on Detected Faults
The specification of any action necessary to achieve or maintain a safe state of the process in the event of fault(s) being detected in the SIS, taking into account of all relevant human factors.
24. Mean Repair Time
The mean repair time which is feasible for the SIS, taking into account the travel time, location, spares holding, service contracts, environmental constraints.
25. Dangerous Output States
Identification of the dangerous combinations of output states of the SIS that need to be avoided.
26. Environmental Extremes
Identification of the extremes of all environment conditions that are likely to be encountered by the SIS during shipping, storage, installation and operation. This may require consideration of the following: temperature, humidity, contaminants, grounding, electromagnetic interference/radio frequency interference (EMI/RFI), shock/vibration, electrostatic discharge, electrical area classification, flooding, lightning, and other related factors.
27. Normal and Abnormal Process Modes
Identification of normal and abnormal process operating modes for both the plant as a whole (e.g., plant start-up) and individual plant operating procedures (e.g., equipment maintenance, sensor calibration or repair). Additional SIFs may be required to support these process operating modes.
28. Survival in Major Accidents
Definition of the requirements for any SIF necessary to survive a major accident event, e.g., time required for a valve to remain operational in the event of a fire.
References
- IEC-61511
- Functional Safety from Scratch by Peter Clarke, xSeriCon
