Safety Requirements Specification in a Capital Project Environment

Creation of the SRS early in a project's life saves time and money.

By Dr. Angela E. Summers, SIS-TECH SOLUTIONS, LLC April 1, 2000

B ecause U.S. domestic and international safety standards judge all phases of design against the safety requirements specification (SRS), development of the SRS is an important step in the safety instrumented system (SIS) lifecycle. ANSI/ISA S84.01-1996 ‘Application of Safety Instrumented Systems for the Process Industries,’ and draft IEC 61511 ‘Functional Safety Instrumented Systems for the Process Sector – Part 1: General Framework, Definition, System Software and Hardware Requirements’ indicate a need to develop an SRS document, but neither standard provides a clear purpose, scope, or timing of the SRS.

Both standards state the objective of the SRS is to:

  • Develop specifications for safety instrumented system design; and

  • Provide a placeholder to assemble a collection of related documents or information.

Unfortunately, the standards graphical representation of the SIS (Safety Instrumented System) lifecycle lead many to believe the SRS is generated as a single deliverable after the process hazards analysis (PHA). Further compounding the situation, neither standard provides clear differentiation between the SRS and typical capital project documentation, resulting in a wide assortment of SRS documents. At one extreme, some companies are doing nothing, assuming (hoping) the SRS is covered by current documentation. At the other extreme, others are requiring a comprehensive, new document developed by the design team. In the middle are those who are filling gaps in their current documentation to meet new requirements.

Big picture needed

Determining how best to develop the SRS requires a ‘big picture’ approach. Elements of the SRS will be developed, modified, and utilized throughout the SISs lifecycle, resulting in a need for a document that can easily evolve. Though the SRS serves as the basis for the SIS design, it is more than a ‘specification’ used to design the SIS. The SRS is the documentation needed to validate and test the SIS design and therefore becomes a dynamic document used as the basis for on-going management of change activities required by regulatory agencies such as the United States Occupational Safety and Health Administration (OSHA).

OSHA’s Process Safety Management (PSM) program requires the compilation and on-going maintenance of ‘process safety information.’ OSHA’s purpose in requiring process safety information is to ensure the existence of identified process hazards and how these hazards are being managed during plant operation. This makes the SRS the establishment of process safety information needed to define the safety functional requirements for the SIS.

The SRS functional requirement must include logic, and action’s required of the SIS when defined and monitored conditions become true. Included in the SRS functional requirement’s are:

  • Safe state of the process;

  • Process inputs and trip points;

  • Process outputs and actions;

  • Functional relationships, failure modes;

  • Manual shutdown and reset requirements;

  • Maintenance/bypassing requirements;

  • Response time requirements;

  • Human machine interface requirements; and

  • Independent protection layer risk reduction allocations.

Define risk reduction assumptions

Defining and documenting risk reduction assumptions related to other independent protection layers is key in defining and evaluating SIS performance criteria such as common mode failures, diagnostics, maintenance, functional testing, and reliability issues. Safety integrity requirements for the SIS provide the safety integrity level (SIL) and performance required for executing each safety function.

During a project’s lifecycle, the effect the SRS has on each step varies (see SRS lifecycle diagram). For a typical grass-roots project, the SRS is the focal point for the design of the SIS and interaction occurs between each lifecycle step and the SRS. To be a meaningful and accurately prepared document, the SRS must be developed and reviewed by a team of people with domain knowledge in the areas of process design, equipment design, operations, and maintenance.

Commencing with early feasibility studies, chemists and chemical engineers perform the research and development necessary to understand how to make product and control the process. Potential incident scenarios are discussed, including the initiating cause of the scenario and the consequence. Where a pilot plant is being built/used, these scenarios become the design basis for safeguards, focusing on the application of inherent safety principles to reduce the risk of an incident (see Phase 1 process hazard analysis diagram). When residual risk is deemed too high, additional measures are applied – typically in the form of additional independent protection layers. Lessons learned throughout the feasibility study become critical inputs to the SRS.

During early project phases, scenarios identified during the feasibility studies are examined, along with any other scenarios the team may identify. After the examination of inherent safety principles, the unmitigated frequency of each potential incident is estimated. At this point, the risk associated with each incident is established and evaluations conducted concerning the use of passive protection systems (e.g. pressure relief valve), active protection systems (e.g. critical alarms with operator response or SISs), and consequence mitigation systems (e.g. fire and gas) to determine each’s ability to reduce identified risk to tolerable levels.

Included in the SRS is a description of how each protection layer is intended to function, including assumptions made regarding their design integrity. Any codes or regulatory concerns (i.e., Federal, State, and/or Local) are clearly stated to ensure compliance. The SRS documents any hazardous incidents that are caused by nuisance tripping, and each remaining SRS element’s functional requirements, as described in the safety integrity requirements (see SRS Conceptual design phase diagram).

Detailed design comes from the SRS

The detailed design is an outgrowth of the SRS. Any deviation from the SRS is evaluated to ensure the risk reduction specified for each independent protection layer is not compromised. Construction and installation drawings, engineering specification sheets, loop drawings, and procedures are reviewed for consistency with the goal of the SRS to ensure all identified risks are mitigated to a tolerable level. The HAZOP (Hazard and Operational) study conducted on the final detailed design serves as the final checkpoint for SRS completion.

Contrary to what some companies are doing, the HAZOP is not the beginning of the SRS documentation. The pitfall with this approach occurs when SIL assignments are made during the HAZOP and subsequent design changes are necessary. Every project flow chart would suddenly have boxes for ‘Detailed Design HAZOP’ and ‘Detailed Design HAZOP Part 2: the new SIS’ resulting in a high cost approach of developing the SRS.

As mentioned earlier, development of the SRS for a grass roots facility occurs during feasibility and front-end loading. The completeness of the SRS is verified at the detailed design HAZOP study where any required modifications to the SRS are documented through proper change management and revision control procedures. The approved SRS becomes part of the process safety information, required in many countries as a demonstration of the risk analysis or functional safety assessment of the facility (see Phase 2 design diagram).

SRS development on existing processes

For an existing facility, the SRS is developed using existing process documentation but often the connection between HAZOP concerns and installed instrumentation is not clear in the available documents. The HAZOP can be used to identify the scenarios of interest, but a team of health and safety, process, operation, and maintenance personnel must be assembled to identify the existing safety functions that are used to mitigate the scenario risk and then determine the required/target SIL. When the target SIL is compared to the design SIL, system modifications (e.g. design, maintenance, test frequency, etc.) may be required.

Prior to start-up, the approved SRS is used to validate the installation, integrity, and functionality of the SIS. Any deviations from the SRS require a risk analysis to determine if the deviation impacts process safety. Validation documents created prior to start-up are:

  • Instrument calibration sheets;

  • Loop check results;

  • Energy source verification;

  • Pre-startup safety review;

  • Pre-startup acceptance test; and

  • Training on operational and maintenance procedures.

The SRS provides input to the operation, maintenance, and testing of the SIS. During the SIS front-end loading, integrity requirements were established for the SIS. During normal operation, the actual design integrity is highly influenced by diagnostics, testing, bypassing provisions, SIS access security, and management of change (MOC). Consequently, administrative controls must be established to emphasize the importance of repairing diagnosed faults, testing/repairing instrumentation, and preventing bypass of SIS functions to ‘ride out’ process upsets. The MOC program must be modified to ensure any changes to the SIS are assessed for impact on the required risk reduction documented in the SRS. Any modification must be documented in the SRS with revision control (see Management of change diagram).

Roles and responsibilities

Of all of the requirements in the standards, the SRS is the true ABM (anyone but me) deliverable, primarily because of its comprehensive coverage of safety, process, instrumentation, electrical, operation, maintenance, and testing issues. When the SRS is viewed as an evolving collection of information, it is easier to understand that the SRS is an Everyone deliverable. The roles and responsibilities matrix for the deliverables/documents is summarized in the following table.

Deliverable Health, Safety, and Environment Process Engineers and Chemists I&E Operations and Maintenance
Phase 1 PHA: SRS Development L/A P
Phase 2 PHA: SRS Completion L/A P P P
Phase 3 PHA: HAZOP L/A P P P
Conceptual Design (FEL) R L/A P R
SIS Detailed Design R R/A L R
Operating Procedures L/A P P
Maintenance and Testing Procedures R L/A R
Validation R P L/A P
L: Lead

The SRS is a thorough approach to the documentation of the SIS strategy for managing risk in the process, providing management with information concerning potential hazards and design documentation of the steps taken to mitigate those hazards.

The SRS provides assurance to insurers, regulators, plant personnel, and corporate management that safety systems are in place, effective, and being managed correctly.

The SRS fits well into front-end loading and proper use of the SRS can reduce downstream project design changes.

When the SRS information is shared throughout a Corporation for similar processes, best practices can be identified resulting in further cost savings and in the minimization of inconsistencies from one site to another. The SRS is a ‘living’ document that provides the rationale behind the design of the SIS. By following the flowchart and recommendations presented in this article, the SRS can easily be integrated into the normal design process, resulting in the most cost-effective implementation of the SIS standards.

Dr. Summers is president and founder of SIS-TECH SOLUTIONS, LLC (Houston, Tex.), is an active member of several safety standard committees, teaches a variety of safety system related courses, and provides consulting services to assist companies efficiently and reliably define, design, install, and test safety instrumented systems for processing industries. Dr. Summers may be reached at (713) 320-4777 or via eMail at .