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.
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.
In 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:
What 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.
The post Embracing Safety Requirements Specifications appeared first on the Emerson Process Experts blog.