ISA 84 (IEC 61511) is the standard for the design of safety instrumented systems in the process industry. It is recognized by the Occupational Safety and Health Administration (OSHA) in the U.S. as Recognized And Generally Accepted Good Engineering Practice (RAGAGAP).
Clause 1.a in the standard “specifies the requirements for achieving functional safety, but does not specify who is responsible for implementing the requirements (for example, designers, suppliers, owner/operating company, contractor); this responsibility will be assigned to different parties according to safety planning and national regulations.”
What follows are some portions of the standard. Read each item and consider who has the knowledge to determine and document such requirements.
Hazard and risk assessment: A description of the hazards, the required safety function(s) to prevent them, and their associated level of risk reduction. The standard states that this requires a multi-disciplinary approach.
Allocation of safety functions to protection layers: What protection layers will be appropriate (e.g., dikes, scrubbers, pressure relief, flare systems, safety instrumented systems, fire and gas systems, etc.).
Safety requirements specification: A listing of almost two dozen bullet points that need to be documented for each and every safety instrumented function. Some items are: what is the hazardous event that the function is protecting against, what input and output (field devices) need to be implemented to detect and prevent the event, what is the required response time of the function, what safety integrity level (i.e., level of performance) does the function need to meet, how are bypasses and resets to be implemented, how should the function respond in the case of a fault, what are the interface requirements to other systems, etc.
Operation and maintenance: Document the necessary operation and maintenance requirements ─ and perform them ─ so all the safety instrumented functions will perform when and as required.
Management of change: Verify that modifications to any safety instrumented function are properly planned, reviewed and approved prior to making the change.
Documentation: Confirm that the necessary information is available and documented in order that all phases of the safety life cycle can be effectively performed.
There are many reasons why end users have downsized and do not have the internal engineering support staff of decades gone by. However, downsizing too far and relying on outsiders can have very negative consequences, as was documented in the Texas City refinery accident of 2005 (e.g., the impact of staffing changes needs to be reviewed as part of management of change practices called out in OSHA’s Process Safety Management Regulation: CFR 1910.119).
I would argue that the most important portion of the life cycle is the development of the safety requirements specifications (just two out of 100 pages of the standard).
The UK Health and Safety Executive documented in their 1995 book “Out of control; why controls systems go wrong and how to prevent failure” that the majority of accidents involving control and safety systems failures (44 percent) were due to incorrect and incomplete specifications.
The knowledge needed to document these requirements resides in the end user organization and the process designer and/or licensor.
However, there have been cases where the end user has asked the control system vendor or integrator to develop the safety requirements specification. That’s a bit like a farmer asking the fox to come up with the design for a hen house. There’s also a serious and rather obvious potential conflict of interest.
An architect can design a house for you, but he can’t come up with your requirements all on his own.
Granted, he could ask you and your spouse hundreds of questions to pry the information out of you. But what will happen when you and your spouse have conflicting requirements, as you no doubt will?
Lockheed knows how to build planes, but they can’t come up with the requirements for what the Marines may need in their next aircraft. They could ask hundreds of questions as well, but every pilot and commander they interviewed would want something different.
Giving the Marines a copy of the plane Lockheed just developed for the Air Force would not satisfy their unique requirements! No doubt such a plane would break the first time it attempted to take off or land on an aircraft carrier.
If the user doesn’t ‘own’ the various portions of the life cycle, the findings and recommendations made by others will likely not be followed.
I have experienced too many cases where safety integrity levels determined by others were not implemented according to the requirements, required test intervals were not followed, suggested changes were not implemented, etc.
Whether you accept it or not, the overall responsibility for the specification and operation of your safety instrumented systems rests in your hands.
Visit Rockwell Automation's web site to learn more about process safety.
Paul Gruhn is a global process safety consultant for Rockwell Automation.
This blog was originally posted by Rockwell Automation here.