Embracing Safety Requirements Specifications

by | Nov 7, 2016 | Safety

Jim Cahill

Jim Cahill

Chief Blogger, Social Marketing Leader

The Institute of Measurement and Control is hosting the Functional Safety 2016 conference this week in London. This conference seeks to engage practitioners from a wide variety of industrial sectors who have responsibilities in any functional safety lifecycle phase to share views and best practices.

Emerson's Russell Cockman


Emerson’s Russell Cockman is presenting Why embrace the concept of the Safety Requirements Specification? Here is the abstract from the paper he submitted:

Process safety and functional safety have the same fundamental goal, to reduce the risk to people and the environment posed by intrinsically hazardous processes. The safety instrumented system (SIS) is only there because the process risk is not ALARP [as low as reasonably practicable] without it. The success of a safety instrumented function (SIF) is entirely dependent on it doing the right thing at the right time in the right way. Given this common goal it is strange that there is often such a disconnect between them throughout their lifecycle. This disconnect starts at the beginning of the safety lifecycle. How many SIS specifications do you see with no mention of the process being protected at all? It is no wonder that specifications are the source of so much failure, as we cannot tell from the specification what exactly is the design intent of each requirement, we just go on assuming that the requirement is right. If you look at the suggested SRS content in IEC61511-1 you can see that requirement of the process s dominate. However, the importance and significant benefits of the SRS are not appreciated.

Based on recent experiences of the author in helping customers prepare their SRS, we will explore the benefits in doing so and the change in approach required to get the most from this activity. We will look at how to make the SRS a valuable tool rather than just another document. It will give examples of where a dedicated SRS activity can yield positive benefits to the overall safety achieved.

Safety Requirement Specifications and ValidationIn his presentation, Russell looks at things often done both the right and wrong way, the safety lifecycle and some observations from his experiences working with process manufacturers and producers.

Industrial processes are most safe due to process design, automation design, system integration and testing, site integration, ongoing operations, maintenance and enhancements over time. Russell cites a study by the UK’s Health and Safety Executive that pointed to inadequate specification as the main cause of control system failure. This is due either to poor hazard analysis of the equipment under control or a failure to assess whether foreseeable failure modes of the control system would compromise the specification of the system.

An error made in the upfront process design phase can replicate and propagate through the project and operating lifecycle. These errors can lay dormant as hidden, systematic failures waiting for the right scenario. The experts do not knowingly make mistakes but as part of task-focused teams can collectively make mistakes and compound them.

The safety requirements specification (SRS) captures all the factors which influence the design and management of SIL-rated functions for the lifecycle. The SRS is also a reference for validation of a commissioned or modified SIS.

Russell shows a list of the content in an SRS, which includes:

  • a description of all the safety instrumented functions necessary to achieve the required functional safety
  • requirements to identify and take account of common cause failures
  • a definition of the safe state of the process for each identified safety instrumented function
  • a definition of any individually safe process states which, when occurring concurrently, create a separate hazard (for example, overload of emergency storage, multiple relief to flare system)
  • the assumed sources of demand and demand rate on the safety instrumented function
  • requirement for proof-test intervals
  • response time requirements for the SIS to bring the process to a safe state
  • the safety integrity level and mode of operation (demand/continuous) for each safety instrumented function
  • a description of SIS process measurements and their trip points
  • a description of SIS process output actions and the criteria for successful operation, for example, requirements for tight shut-off valves
  • the functional relationship between process inputs and outputs, including logic, mathematical functions and any required permissives
  • requirements for manual shutdown
  • requirements relating to energize or de-energize to trip
  • requirements for resetting the SIS after a shutdown
  • maximum allowable spurious trip rate
  • failure modes and desired response of the SIS (for example, alarms, automatic shutdown)
  • any specific requirements related to the procedures for starting up and restarting the SIS
  • all interfaces between the SIS and any other system (including the BPCS and operators)
  • a description of the modes of operation of the plant and identification of the safety instrumented functions required to operate within each mode
  • the application software safety requirements as listed in 12.2.2
  • requirements for overrides/inhibits/bypasses including how they will be cleared
  • the specification of any action necessary to achieve or maintain a safe state in the event of fault(s) being detected in the SIS. Any such action shall be determined taking account of all relevant human factors
  • the mean time to repair which is feasible for the SIS, taking into account the travel time, location, spares holding, service contracts, environmental constraints
  • identification of the dangerous combinations of output states of the SIS that need to be avoided
  • the extremes of all environmental conditions that are likely to be encountered by the SIS shall be identified. This may require consideration of the following: temperature, humidity, contaminants, grounding, electromagnetic interference/radiofrequency interference (EMI/RFI), shock/vibration, electrostatic discharge, electrical area classification, flooding, lightning, and other related factors
  • identification to normal and abnormal modes for both the plant as a whole (for example, plant start-up) and individual plant operational procedures (for example, equipment maintenance, sensor calibration and/or repair). Additional safety instrumented functions may be required to support these modes of operation
  • definition of the requirements for any safety instrumented function necessary to survive a major accident event, for example, time required for a valve to remain operational in the event of a fire

Safety Requirements Specification InputsWhat is usually seen in the SRS is a concentration on the logic solver and not the sensors and final elements in the safety instrumented functions. Technical specifications and logic definitions such as cause & effect charts and associate notes are usually present. Shutdown functions and not safety functions and other information not relevant to functional safety are seen.

What is often missing is a focus on the process with an understanding of hazard scenarios, how the safe state is achieved and the effects of combined hazards and scenarios. Also what is the SIF focused functionality for all process states and modes. Also missing are the device safety requirements including how device integrity and affected by the process and the restrictions and methods of testing devices.

The key is that the manufacturer must take ownership of the SRS as a unique document and not see it replaced by equipment specifications. It needs a unique identity to have a focus on the SIS, each SIF and the hazard it is protecting against. Expectations should be set that there are defined owners, require team input into the specification with documented roles & responsibilities, be safety-related in focus only, have process-driven content, and have a focus on requirements and not solutions. The SRS is fed from the process design parameters, hazard and operability (HAZOP) study and layers of protection analysis (LOPA).

With a properly executed SRS, you can properly validate the SIS, reduce the probability of systematic error, better understand the potential hazards, force focus on what is really safety related, and evaluate the specifications to the requirements of the process throughout the safety lifecycle.

You can connect and interact with other safety experts in the Safety Instrumented System group in the Emerson Exchange 365 community.

Popular Posts

Comments

Follow Us

We invite you to follow us on Facebook, LinkedIn, Twitter and YouTube to stay up to date on the latest news, events and innovations that will help you face and solve your toughest challenges.

Do you want to reuse or translate content?

Just post a link to the entry and send us a quick note so we can share your work. Thank you very much.

Our Global Community

Emerson Exchange 365

The opinions expressed here are the personal opinions of the authors. Content published here is not read or approved by Emerson before it is posted and does not necessarily represent the views and opinions of Emerson.

PHP Code Snippets Powered By : XYZScripts.com