How to Manage Bypasses Using SLM

by | Oct 22, 2019 | Blog News, Process Safety

How to Manage Bypasses Using SLM

IEC 61511 Part 1, contains extensive discussions of the design and operating procedures for SIF bypasses. Clause 16.2 describes operational requirements such as:

  • Performing a hazard analysis prior to initiating a bypass
  • Having operational procedures in place for when a protective function has been bypassed
  • Logging of all bypasses.

How to Manage Bypasses Using SLM – through a robust Bypass management and logging function that meets all of the requirements of IEC-61511 and integrates with the performance analysis and reporting functions of the SLM Operate-Maintain (OM) Module. SLM OM Module uses the Bypass Authorization object and Work Flow to initiate, approve and record the execution of Protective Function Bypasses. SLM does not limit the use of Bypasses to just SIFs. In SLM, any protective function may have a Bypass Authorization associated with it.

Read more about the Benefits of Effective Bypass Management 

The figure below illustrates how the Work Flow supports the tasks required on how to manage bypasess using SLM:

A Bypass Authorization is initiated by any authorized SLM user. In practice this will usually be a member of the Operations Staff for a Unit, often a shift foreman or Operations Engineer. The originator is guided to enter the information required to support the Bypass Authorization. This includes:

  • Basic Bypass information such as the reason for the Bypass, the anticipated start date and time and the maximum time which the Protective Function is to be Bypassed
  • Hazard Assessment information – this includes an identification and assessment of the potential severity of hazards that may occur while the Protective Function is Bypassed and the corrective measures that should be taken if the hazard occurs
  • Operation Procedures that are required to be used to mitigate potential hazards that may occur while the Protective Function is Bypassed
  • Identification of the Devices associated with the Protective Function that will be Bypassed

Once this information is provided, the user then may submit the Bypass Authorization for Approval. The Bypass Authorization is submitted to the designated Approver, typically an Operations Supervisor of Manager. The Approver reviews the Bypass Authorization and either Approves or Disapproves the request.

Once the Bypass Authorization is Approved, the Operations team may execute the Bypass as planned. The originator or other authorized user may then record the start date and time of the Bypass in the Bypass Authorization. If a Bypass is expected to exceed the time requested in the original Bypass Authorization submittal, the user may request approval for a Bypass Extension by filling in the data in the Bypass extension section of the Bypass Authorization object. When approved, this will update the authorized Bypass time and prevent the Bypass from being reported as exceeding its authorized time.

When the Bypass is completed, the originator or other authorized user then enters the date and time when the Protective Function is returned to service and then close the Bypass Authorization. Closing of the Bypass Authorization results in the Bypass data being added to the SLM Events that are used to analyze Protective Function and Device performance.

SLM contains performance views that capture all Bypasses for a Function, Unit and Site. The analysis functions include reporting on the number of bypasses, time in bypass and identification of Bypass Events that exceeded the authorized bypass time. SLM will also compute the effect of Bypasses on a Protective Function’s in-service performance, such as computing the in-service reduction in the Functions’ RRF or PFD. Functions that have excessive Bypasses will also show up on the Unit and Site bad actors lists.

 

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s Safety Lifecycle Management software.

Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

I Like Logic Diagrams

by | Oct 14, 2019 | Blog, Functional Safety, Process Safety

I Like Logic Diagrams

I like logic diagrams, although I’m often in the minority, to do the detailed design of a Safety Instrumented Function (SIF). Others believe that Cause and Effect (C&E) Diagrams are all that is needed. My view is that C&E’s are an effective overview tool when it comes to familiarizing people that aren’t part of the design team with a SIF’s function. However, when it comes to clearly and unambiguously defining how a SIF, or any other logic function works, I find the logic diagram to be the best tool.

C&E’s just are not very good in conveying stuff like timing or sequencing, rather they are quite confusing. C&E’s are good at saying if an input condition exists, this is the output condition. But more complex things such as timing, permissives and other things that usually exist can’t be readily defined in a C&E. Suddenly you are trying to figure out what Notes 6, 12, and 19 actually mean. Users programming from C&E’s, particularly for larger systems can easily make mistakes or misinterpret the intent. I find myself to be quite capable of misinterpreting all those notes.

I like logic diagrams because on the other hand, when done well, they are easy to interpret. The diagram symbols like those identified in a standard such as ISA 5.2 allow the user to clearly define almost everything you need. You can clearly and precisely cover set points, time delays, and complex relationships etc. Personally, I’ve used an amended version where input and outputs get more directly defined as power sources, dead bands for switches, whether the logic operates on an open or closed switch, or energizes or de-energizes a solenoid valve, etc.

Logic diagrams also can become a one to one road map for the Safety Instrumented System (SIS) programming. Most SIS programming languages have a function block option. This makes things a whole lot easier and saves a lot of time in programming, quality checking and field testing. It’s true that preparing a good logic diagram takes more time than putting together a C&E, but it’s my belief that you get your money back and then some just in simplicity and reduced errors. It’s simple to put a note on a C&E that someone might easily misunderstand, but in a logic diagram you have to sweat the details up front and not pass it on for a programmer to figure out (and everyone thereafter).

I think that logic diagrams are an investment. They take time to prepare yet start paying back at the time of programming. The real payout comes at the time of pre-startup validation. With well-reviewed logic diagrams, the potential errors in programming are pretty much beat out of the system by the time you get to checkout, loop testing, and validation. Well checked and tested systems can radically reduce startup time.

An example of what a logic diagram looks like:

A case study I cite is a process unit for which I was the lead control systems engineer. The process required over 100 distinct Interlock, sequence and SIFs as well as required over 400 logic diagrams to represent. We spent a ton of time developing the logic diagrams and a bunch more putting together test procedures and executing them.  We taught the Operators to read the logic diagrams, and during the first 6 months of operation, there was always one set or another open on a desk.

It took a lot of effort, and had real costs, when it was all said and done, we only had two logic glitches during startup (one of those was an unauthorized logic change made by a contract engineer at the last minute). The net result was that we were up and making on spec product in the first week of operation. The licensor’s startup engineers were amazed. Their feedback was that they always experienced that there would be 6 to 8 weeks of logic debugging before reliable production could be established. The extra 5 weeks of production paid for all of time we spent on logic diagrams and testing, many times over. That’s why I like logic diagrams.

 

 

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s Safety Lifecycle Management software.
Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

Promoting a Sustainable Process Safety Culture

by | Oct 10, 2019 | Blog, Blog News, Process Safety

Promoting a Sustainable Process Safety Culture

Promoting a sustainable process safety culture can be difficult. The Chemical Safety Board just issued their report on the November 2014 incident at the DuPont La Porte plant in which 4 people were killed:

Click here to read the full report.

Summary of the Report 

The report reads like so many others highlighting some issues with promoting a sustainable process safety culture.  The root cause was said to have been the fact that site and corporate management failed to implement Process Safety Management Systems. Furthermore, the report also cites multiple failures in the overall management of Process Safety. The core failure in this incident was that the facility had a very poor Safety Culture as summarized in the excerpt from the CSB Report. The CSB Report devotes an entire section on how the Process Safety deficiencies in this incident parallel the findings in an earlier CSB report on the 2005 BP Texas City Refinery explosion, despite the site being aware of the report and its findings. ®

DuPont La Porte did not use any type of robust, formal process safety culture assessment. Process safety culture can affect whether a site has a sense of vulnerability in terms of process safety management risks; complacency or overconfidence; and transparent, timely, and thorough responses to PSM concerns, action items, and issues, including leadership measures to prevent a “check-the-box” mentality (i.e., simply accomplishing a task as the objective rather than ensuring a high degree of focus on risk management and prevention). The Safety Perception Surveys conducted at the DuPont La Porte facility before the November 2014 incident were designed to lower OSHA total recordable injury rates [59, p. 8]. DuPont did not intend for these surveys to measure or address the perception of process safety performance.

One of the issues with promoting a sustainable Process Safety culture is that it’s hard without the right tools:

  • The tools that an organization typically has to manage day to day operations don’t fit the needs of Process Safety Management.
  • The tools that do exist are typically single purpose and result in isolation of data and limited availability across organizational boundaries.

It’s extremely easy for individuals to become disconnected as they often are not involved in day to day management of Process Safety and it becomes the perception that it’s taken care of by others. Add a management attitude such as existed at La Porte where there was a misplaced emphasis on measuring personnel safety with no corresponding concern for Process Safety and establishment of a sustainable Process Safety culture becomes impossible.

An effective Process Safety Program needs to make Process Safety information widely available to all employees involved in design, operation, and maintenance of the processes in order to keep them all involved on a daily basis. When a site is using the tools traditionally available for plant operations, information becomes isolated from personnel and is difficult to access. 

Safety Lifecycle Manager (SLM®)                                   

The SLM® application was developed to address the many shortcomings relative to Process Safety that exist in many plants today. The origins of the application were a direct result of the CSB and Baker Panel findings relative to the BP Texas City Refinery explosion.

The objectives of the development of SLM were:

  • Unify Process Safety data in one location so it is accessible to all personnel that need it. This includes PHA, LOPA, IPLs, Plant Assets that perform the functions required by IPLs or other functions, and Field Devices that are used to implement the functions and performance records for Plant Assets and Devices.
  • Provide the tools to perform PHA and LOPA studies within the SLM application.
  • Link Plant Assets to PHA, LOPA, and IPL data so the Process Safety requirements such as LOPA IPLs or PHA Safeguards that resulted in the Plant Assets being installed can be directly accessed from Plant Assets and vice-versa. This provides a very clear linkage between real functions and devices in the plant to the Process Safety reasons that they exist. This addresses the very real issue of IPLs not being clearly identified by LOPA Teams, or multiple LOPA teams identifying multiple IPLs that correspond to the same Plant Asset. The figure below illustrates these relationships.

  • Provide engineering tools that support design of safety instrumented systems (SIS) and safety instrumented functions (SIF) and maximize consistency of design. This includes tools to rapidly develop Safety Requirements Specifications (SRS) and evaluate SIF Probability of Failure upon Demand (PFD). Functional requirements for Safety Related Devices are clearly defined as are testing requirements and any operational requirements.
  • Provide the ability to define functional requirements for other non-SIF Protective Functions and Safeguards and their field Devices including alarms, interlocks, BPCS functions and non-instrumented protective functions.
  • Provide the ability to upload or link key documents directly with Process Safety related Assets. These may be operation and testing procedures or other documents or drawings.
  • Provide a complete Life Cycle management capability that allows for management of Protective Functions during operation and maintenance after initial design and installation. Events associated with the operation of Safety Related Plant Assets such as Demands, Testing, Bypasses and Failures may be recorded using simplified and consistent Work Flows. The figure below illustrates the relationship of Events to Plant Assets and Devices.

  • Provide a real time view of the performance of Protective Functions and their field Devices based upon the Event data contained in the database. Various Key Performance Indicators (KPI) allow the plant to understand the current state of performance and manage periodic testing and identify bad actors for which corrective action is required. Examples of various KPI’s are shown below.

How SLM® can help when promoting a sustainable Process Safety Culture

  • Instead of separation of various aspects of Process Safety, they are integrated in one web-based application that makes Process Safety information available to all personnel who have Process Safety interests.
  • SLM® allows personnel with Process Safety responsibilities to participate in Process Safety Management on a routine basis. Furthermore, personnel that are closest to various Events may be assigned responsibility to record those Events.

For example:

Operations personnel are responsible for entering Events for operational related items such as Demands, Bypasses, and Failures while maintenance personnel are responsible for monitoring testing that is approaching its due date as well as entering the results of testing and any other maintenance Events. This keeps personnel involved in the day to day management of Process Safety related Assets.

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s Safety Lifecycle Management software.

Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

 

How to Use Your Process Historian to Generate Automated Safety Lifecycle Manager (SLM) Events

by | Sep 19, 2019 | Blog, Functional Safety, Process Safety

How to Use Your Process Historian to Generate Automated Safety Lifecycle Manager (SLM) Events

Capturing Events in SLM generally requires manual entry of data by a user. However, this doesn’t need to be the case. It is possible to automatically extract Event data from a Process Historian. Setting it up takes some initial work, but once the setup has been done, the process of Event generation can be automated.

First, the user must have tags that exist in the basic process control system (BPCS) and Historian from which the Historian can capture changes in status. These are status tags that signify that an Event has occurred. A few examples of this are:

  • Alarm Activation
  • Safety Instrumented Function (SIF) Demands
  • Manual Trip Commands
  • SIF Bypasses
  • Fault/Failure Diagnostics
  • BPCS demands

In order to leverage this functionality, the underlying BPCS, Safety Instrumented System (SIS) alarm, and status tags need to be developed. See example in the figure below:

 

Then, once the necessary status data is available in the Historian, an external scanning program needs to be developed that will scan the Historian data for a set of tags on some routine basis, typically daily, but other intervals may be chosen.

The scanning program exports a file with a list of all status changes that occurred over the scan interval. Typically, this file contains the tag number of the tags associated with the status change, the status change (e.g. from Normal to Tripped, Normal to Bypass, Bypass to Normal, etc.) and the time stamp of the status change. On the SLM side, another program, the SLM Import Adapter, examines the Historian export file and generates the associated Event in SLM. In order to do this, SLM needs to have a table of the tags which may have a status change and enough information to allow SLM to generate the Event. Some of the information required is:

  • The Historian tag name and the SLM object name – These should be the same, but there is no guarantee they will be.
  • The type of Event with which the Historian tag is to be associated (e.g. Demand, Bypass, etc.)
  •  A list of Devices associated with the SLM object name for which SLM should create Device Events
  • Whether the Event is to be directly logged in SLM or submitted for Approval.

The SLM Import Adaptor is then used to generate the SLM Events. The Adaptor handles the messy behind the scenes details of creating the Events and any linkages to SLM Parents or Children. 

However, it should be noted that Historian tag status data cannot always provide all the data that a user may want to support SLM’s performance analysis and reporting functions.

For example, a SIF Demand Event generated from Historian data will record a SIF Demand in SLM, but probably won’t have enough data available to verify whether the Demand was executed successfully or identify what Devices were involved in the Demand.

It will usually be necessary for a user to review the automatically generated Event data and supplement it with additional information such as Pass/Fail status or creating or editing Device Events that should be associated with a Demand. This can be addressed by requiring that all automatically generated Events be entered into the SLM database as requiring Approval. This clearly identifies that new Events have been created and allow for review and completion prior to finalizing the Event.

While we have been discussing how SLM Events can be generated from Historian data, the same concepts can be applied to other Events such as Testing and Maintenance Events where data can be extracted from a Site’s Maintenance Management System and imported to SLM Events. 

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s Safety Lifecycle Management software.
Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

Functional Safety Assessment (FSA) – “A” is for Assessment

by | Sep 17, 2019 | Blog, Functional Safety

Functional Safety Assessment (FSA) – “A” is for Assessment

Functional Safety Assessment VS Functional Safety Audit

 When I chair a Functional Safety Assessment (FSA) for a Safety Instrumented System (SIS), there is usually a brief kickoff meeting with the personnel that will be involved in the assessment such as Engineering, Operations, Maintenance and Process Safety. They are often under the impression that they are being audited. However, that isn’t really the case.

IEC 161511 ed. 2 contains the following definitions:

3.2.24 Functional Safety Assessment (FSA):
Investigation, based on evidence, to judge the functional safety achieved by one or more SIS and/or other protection layers.

3.2.25 Functional Safety Audit:
Systematic and independent examination to determine whether the procedures specific to the functional safety requirements comply with the planned arrangements, are implemented effectively and are suitable to achieve the specified objectives.

An FSA is not intended to be a systematic deep dive into all aspects of the execution of Safety Life Cycle requirements. It is intended to be a review of the evidence that an organization can present to demonstrate that their activities, procedures and plans comply with the Safety Life Cycle requirements of the IEC/ISA Standards.

The Standards say that the FSA team shall include one senior competent person not involved in the project design team or involved in operation and maintenance of the SIS. That is an incredibly important requirement. The “senior competent person” needs to have the experience and judgment to know what to look for and to be able to assess what is found.

As that “senior competent person” for most FSA’s of which I’ve been the chair, I tend to take an initial high-level review of the documentation I’ve been provided. I’m not checking all the details. However, over my career I’ve been bitten enough times (sometimes by myself) to be able to sniff out where something is missing or where an organization that has produced a portion of the documentation hasn’t really thought about a particular part of the Life Cycle. That is when it may be time for a selective deep dive.

 The important issue is I’m not cross checking every single detail in each document. I’m assessing the overall quality of the documentation given to me, noting what documentation may be missing, and the answers I get when I’m discussing the SIS with various personnel that are involved. Only when I am able to ascertain that something is off is when I begin to devote the time to start looking with a little more attention to detail. When I find things that are incorrect, or incomplete, I will identify them, but I’m not going so deep as to say things like “Step 45 in the proof test procedure isn’t correct”. I’m going to look at the proof test procedure and review it to verify first that it exists and then if executed will it meet its stated objective. The FSA team doesn’t have the time to do a detailed design and documentation quality audit – that is the job of the organization that designs and owns the SIS and it’s an activity that should be done prior to the FSA.

Another aspect is that in most instances, the FSA team has little or no enforcement authority. The team can only identify the issues of concern in the FSA report and recommend actions that should be taken to address gaps. Sometimes the recommendations are very specific things to fix, or there may be long term organizational or procedural issues to address. The management of the organization that will own and operate the SIS has the responsibility to determine how and when to address the recommendations and how seriously they will take a finding of “Functional Safety has not been achieved”.

 Click here for more information about Functional Safety Assesments

 

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s Safety Lifecycle Management software.
Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

When Should You Conduct a Functional Safety Assessment (FSA)?

by | Sep 12, 2019 | Blog, Functional Safety, Process Safety

When Should You Conduct a Functional Safety Assessment (FSA)?

When Should You Conduct a Functional Safety Assessment (FSA)?

The ISA 84.01.00 and IEC 61511 ed. 2, Part 1, clause 5.2.6 safety standards require that every safety instrumented system (SIS) shall have a Functional Safety Assessment (FSA) performed prior to being placed into service.  A FSA is required in order to provide assurance that a SIS has been specified, designed, and tested in accordance with all phases of the Safety Lifecycle. These Standards identify 5 stages at which an FSA may be performed.

 The 5 STAGES

 

However, as is the case with safety standards, they don’t exactly explain when to perform the assessment rather leave the actual scheduling to the User. It is important to consider factors such as size, complexity experience, etc.

  

Important Factors to Consider:

  • If an organization is new to managing the Safety Lifecycle, it is a really good idea to conduct a FSA at each of the Stages identified in the Standards:

1.) First, after the HAZOP and LOPA’s have been performed and the Safety Requirements Specification (SRS) has been developed, perform the Stage 1 FSA on those items.

2.) Next, after the SIS design has been completed, perform the Stage 2 FSA on the design.

3.) Then, prior to startup, perform a Stage 3 FSA to assess the installation, testing and validation of the SIS and its Safety Instrument Functions (SIF).

This incremental process allows the newbie organization to learn about FSA’s and allows the organization to close any gaps identified with a minimum of impact on the overall project.

  • The same multiple stage procedure should also be followed on large projects where the SIS is only part of a larger design. Larger projects develop a momentum therefore, timely checks on the compliance of SIS specification and design are necessary to avoid substantial impacts on the project schedule and avoid expensive re-work.
  • An organization that is very experienced with SIS design and ownership may choose to defer the FSA until prior to startup. This scheduling assumes that the organization has well defined Safety Lifecycle procedures and standards and therefore have confidence that an FSA performed late in the SIS specification and design process will not identify serious gaps that might delay the startup. 
  • If a new SIS is being installed on an existing process or an existing SIS is being modified, it is usually during a unit turnaround. SIS and SIF testing and validation is usually the last step, so it is important to keep in mind that the operations team that takes part in the startup process might not appreciate waiting on an FSA.

This is why it’s a really good idea to have the FSA completed except for final items such as testing, validation and training assessments. This allows the FSA team to do a quick final assessment of these items and provide that necessary “Functional Safety has been achieved” guidance.

ADDITIONAL CONSIDERATIONS with STAGE 4:

It’s important to recognize that throughout the service life of a SIS, multiple Stage 4 FSA’s will need to be performed to assess in-service performance. Once again, the standards don’t define how often this occurs. We can figure on a nominal 4-5 years between Stage 4 FSA’s, but it all depends upon the process requirements and actual experience.  A poorly performing SIS or SIF may need more frequent assessments. The Stage 4 FSA’s should generally be scheduled ahead of turnarounds to allow time for any needed corrective measures to be implemented within the turnaround.  All this requires the performance data of the SIS (demands, failures, faults, testing history, etc.) be kept, managed, and organized in a quickly accessible manner. 

 Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s Safety Lifecycle Management software.

Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

What really should be in a Safety Requirements Specification (SRS)?

by | Sep 10, 2019 | Blog, Functional Safety, Process Safety

What really should be in a Safety Requirements Specification (SRS)?

IEC 61511 ed.2 and ISA 84.00.01 require that a Safety Requirements Specification (SRS) be prepared for each Safety Instrumented System (SIS). Clause 10 describes the requirements for the SRS. Clause 10.3.2 lists the minimum items that shall be addressed in the SRS. A total of 29 items are listed.

In my experience (over 40 years) reviewing SRS’s produced by multiple organizations, the authors typically don’t read or understand the requirements, nor do they understand the overall intent of the SRS. Many I have reviewed have missed the mark badly. In many cases, the SRS has been treated as an “after the fact” document and as such has been bloated with tons of detailed design information while missing a majority of the standard requirements. When you actually dig into an SRS you typically find all sorts of things have been left out while the main focus tends to be on documenting what the engineers did. The sad thing is that some of these SRS’s have been produced by reputable companies that market themselves as SIS experts.

The first thing to know is that the SRS is required to be a “before design starts” document. The intent of the committees that wrote IEC 61511 ed. 2 and ISA 84 was to ensure that the SIS requirements be laid out before design starts, and to define the things required to be addressed during detailed design. The SRS is NOT a detailed design document. The SRS is used to guide detailed design of the SIS and should then be used to verify that the design actually meets the requirements. Any Organization that does not require that a complete SRS be prepared and approved prior to the start of detailed design isn’t in compliance with the RAGAGEP and thus is likely to be spending way too much money during the detailed design phase. If you have an SRS that conforms to the standards, the subsequent detailed design becomes a lot less expensive and is more effective.

That said, an SRS isn’t necessarily a short document, but it also doesn’t need to be a huge pile of papers that most become. AN SRS is not easy to write the first time around-I look back at some of my first efforts and cringe a bit. In order to be effective, there is a lot of learning that needs to happen. It’s really a good idea to be able to have a quality SRS example to work from if you are developing your first one.

Click here to read more about how Safety Requirements Specifications don’t have to be hard or expensive!

 An SRS should be focused on the following broad areas. Coincidentally, many of these areas are what are missing from the SRS’s I’ve seen. Within each of these, the items defined in IEC 16511/ISA 84 Clause 10.3 need to be included.

  • Hazard Prevention – The SRS needs to clearly identify the Hazard for which each of its Safety Instrumented Functions (SIF) is intended to prevent and the functions that the SIF’s must perform.
  • Operating Modes – The SRS needs to define when the SIF’s are required to be available and when they are not. The SRS needs to describe how and when a SIF is put into service and also how and when it is bypassed or removed from service. These descriptions need to be explicit and define what the detailed design needs to enable.
  • SIF Performance – The SRS must define the performance requirements for each SIF. IEC 161511 ed. 2 and ISA 84 are big on making sure that the SIF activates upon demand (this is usually categorized as a Probability of Failure upon demand (PFD). They aren’t as focused on the reverse, which is making sure that false trips don’t occur. The owner of the SIS needs to make sure the SRS addresses design requirements for both Availability (PDF) and Reliability (prevention of false trips). This means defining requirements for redundancy, voting groups, and similar design features that promote reliability without compromising availability.
  • Device Functional Requirements – The SRS needs to define the performance expectation for field devices such as:
    • Range
    • Accuracy
    • Response time
    • Shutdown valve stroke time
    • Leakage
    • Certifications for use

These are performance requirements and are not procurement specifications.

  • SIS Design Requirements – The SRS needs to identify the specific SIS and SIF design requirements and they need to address organization and site practices such as:
    • Acceptable component selection
    • Installation requirements
    • Wiring requirements

Note: It’s best that an organization produces a SIS Design Standard as a reference and not try to cram this data into the SRS. Some organizations have two Standards. Once for SIS physical design and installation and a second for SIS application software and programming.

  • Operation and Maintenance Requirements – The SRS needs to define testing and verification requirements for the SIS and its SIF’s over the SIS life. The SRS should define what procedures must exist such as:
    • Operating Procedures
    • Initial Validation
    • Periodic Test Procedures
    • Bypass Procedures
    • Performance Data Records
    • Periodic evaluations

The SRS doesn’t need to include these procedures but needs to identify the requirement that the procedures be developed and used.

What you don’t see in the items listed above is anything about doing data sheets or design drawings, etc. Those all come later and should never show up in an SRS. If an organization wants to produce a design book, that’s fine, but its separate from the SRS. 

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s SLM Safety Lifecycle Management software.

Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

5 Reasons You Should Invest in a Safety System (other than Safety)

by | Sep 6, 2019 | Blog, Functional Safety, Process Safety

5 Reasons You Should Invest in a Safety System (other than Safety)

When it comes to Safety Systems, there are two perspectives:

Those who have experienced a major incident  VS  those who have not.

Most of those who have experienced a major incident have no desire to experience another one. Those who have not are often unable or unwilling to recognize that they could be next. Unfortunately, these people far outnumber the enlightened, and more unfortunately they tend to overpopulate corporate management levels meaning they also control the budgets.

If you think “it won’t happen to me”, the perspective you’re taking is most likely a financial one, and short term financial at that. Therefore, aside from the “its illegal” and safety is a requirement argument, a financial argument also needs to be made. Safety can be looked at as an investment for many reasons (the list below is listed in no particular order of importance):

  • Reputation: Major incidents, while infrequent, costs lots and lots of money and can mess up your reputation for years. They can put you out of business and may have severe personal impact.
  • Compliance: HAZOP and LOPA procedures will tell you the exact consequences, how likely these incidents are to occur, and how much impact the consequences could have. You can save more money proactively preventing losses rather than the expense of reacting which can be way more expensive and time consuming.
  •  Responsibility: The argument may be made that the likelihood is “remote”. Often this is code for “Won’t happen while I am here”. The real value is realized when you add up the returns for all of the Safety Systems at a Site or in an Enterprise. The probabilities now become a certainty that one or more of the Safety Systems will have to function. So, it WILL happen while you are here.
  • Return on Investment (ROI) : If you multiply the cost of a consequence by the unmitigated probability of it occurring you get a value of that incident. Do the same thing with the probability adjusted for the presence of a Safety System you get a mitigated value. The difference is value of the Safety System. You can calculate a Return on Investment from that value for major consequences, it’s usually the best ROI you will find anywhere.
  • You save Money! : When a significant number of systems are considered, the value of Safety Systems is certain and can be calculated. It’s likely that a few Safety Systems will pay for the installation and maintenance of all the others, and possibly several times over.

If the management of an Enterprise or Site remains intransigent, it’s probably time to document who made the decision and then go find somewhere else to work. It’s probably not safe where you work now. It’s a sad thing, but very real, that some people just “have to have an incident”.

FREE DOWNLOAD: Learn more about the business reasons supporting investment in an integrated Safety Lifecycle Management program.  

 

 

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s SLM Safety Lifecycle Management software.

Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

Thoughts on Prescriptive Design – It Doesn’t Solve Everything, and Sometimes Doesn’t Solve Anything

by | Sep 4, 2019 | Blog, Functional Safety, Process Safety

Thoughts on Prescriptive Design – It Doesn’t Solve Everything, and Sometimes Doesn’t Solve Anything

Some Organization’s feel they can address the requirements of the Safety Lifecycle by developing prescriptive requirements. This can be effective in enforcing some level of conformance with Safety Lifecycle requirements, but it can also have the opposite affect if not done properly.

1.) Are the prescriptive requirements complete?

Compliance with the Safety Lifecycle is far more than a company standard simply stating “all fired heaters shall be equipped with a system that shuts down the heater upon unsafe conditions”. That is not very useful. The requirements need to be very specific and based upon real hazard assessments. For a prescriptive design program to be effective, the required designs need to address:

  • Anything that constitutes a robust design including identifying specific requirements such as specific required Safety Instrumented Functions (SIF) (e.g. heater fuel gas is shut off when the fuel gas pressure is less than the value required for minimum stable firing)
  • Details such as voting inputs and outputs, physical configuration, component selection, testing, etc.
  • A complete detailed Safety Requirements Specification (SRS)

Additionally, when a Safety Instrumented System (SIS) is designed based upon the prescriptive requirements, it still needs is own application specific SRS. An SRS in a standard can be a good starting point, however it still needs to be adapted to a Site’s practices

2.) Do the prescriptive design standards fall short?

Ownership requirements typically do not address Site organizations and procedures. However, they need to be addressed in order to assure that post design Safety Lifecycle functions (such as testing, performance reporting, performance reviews, training, etc.) are performed. If an organization has good prescriptive design standards they also have to make sure they follow up on the post design requirements.

3.) Is your overall Safety Lifecycle really complete?

Prescriptive design standards that don’t focus on the overall Safety Lifecycle requirements are often perceived by a Site as the end of the requirements. It’s very easy to get into a “we did what they told us to” culture instead of one that understands the entire Safety Lifecycle and makes it a part of their day to day best practices.

If an Organization chooses to use prescriptive requirements it cannot be thought of as being a complete solution. It’s only a small part of the overall requirements. It may be a starting point, but there is a lot more consider.

The Next Step – Operations:

Make sure all prescriptive design standards are accompanied with very specific Safety Lifecycle requirements for the Operation phase of the Lifecycle. This includes requirements for meeting all of the other specific requirements as well as identification of who is responsible for what tasks and how they should report data. This can be difficult because every Site will want to do things their way unless they are provided lots of incentive. Without some level of enforcement, it’s far too easy for the Operations phase to fall apart with missed or incomplete testing, bypassed systems, poor or no data retention or reporting and no continuous process of reviewing performance and making the necessary improvements.

Learn more about the different roles and responsibilities in the safety Lifecycle.

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s SLM Safety Lifecycle Management software.

Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.

The Biggest Problem with Safety Lifecycle Management Roles and How You Can Fix It

by | Sep 2, 2019 | Blog, Process Safety

The Biggest Problem with Safety Lifecycle Management Roles and How You Can Fix It

The problem:

Many organizations are trying to figure out how to manage the Safety Lifecycle.  Leadership will often end up just appointing someone as “the SIS guy”.  Sometimes the role is given a fancy title, but the intent is to assign the issue of the entire Safety Lifecycle to someone. That someone is usually in engineering, who may or may not actually have the skills to take on the task. Leadership then thinks they’ve done all that is necessary. The poor person who gets handed the responsibility usually doesn’t have any authority to go along with it, but they are somehow expected to “make it happen”. The organizations that try this approach typically fail.

There are enough responsibilities to go around. An effective Safety Lifecycle Management program recognizes this and clearly identifies who has what responsibility focusing on each area of the Safety Lifecycle. If there is a central authority, they are given a very big management stick to hold every department fully accountable.

 Three main phases to consider:

 1.) Requirements Identification

This is where the Process Safety function in an organization has responsibilities that include: 

  • Define Risk Management Standards
  • Facilitate HAZOP and LOPA Studies
  • Clearly communicate results to the Engineering, Operations and Maintenance personnel

 The Requirements Identification process continues as modifications are made, new processes are added, and periodic re-validations are needed. Other groups with Safety Lifecycle responsibilities also fully participate in the identification of protective system requirements but the Process Safety function is in charge of it.

2.) Specification, Design, Installation

This is typically an Engineering Group that translate the basic requirements from the Process Safety function into real designs, as well as implement them. The responsibilities include:

  • Prepare the Safety Requirements Specification (SRS)
  • Assure that the design meets the SRS
  • Follow the detailed design
  • Inspect and validate testing

Along the way they are also responsible for assuring that all testing and maintenance procedures are prepared and approved. Also, engineering personnel will often be responsible for monitoring the performance to identify any changes that are needed to continue to meet the requirements of the design. 

This requires that events such as faults, failures, bypasses, demands, and testing, etc. be reported to the personnel responsible for evaluating performance. The personnel that assess protective system performance are also responsible for reporting the results to all groups that have related responsibilities, including Site Management.  

3.) Ownership

This starts during design while Operations and Maintenance procedures are being prepared.  Operations and Maintenance are trained and qualified personnel.

The  Operations responsibilities include:

  • Ensure that protective systems are operated in accordance with SRS requirements and operating procedures
  • Record all operational related events
  • Report all events to the personnel responsible for assessing the protective systems performance
  • Monitor testing requirements to make sure that all required testing is performed on schedule and according to testing procedures

The Maintenance responsibilities include: 

  • Perform testing and repairs as required by the schedule and procedures
  • Any repairs needed between testing intervals
  • Maintain all testing and repair records and report them to the personnel responsible for assessing protective systems performance
  • Schedule and plan period testing

The Fix

Because the Safety Lifecycle is a multi-organization endeavor, a collaborative approach is ideal.  The need for communication among various responsible groups requires clearly identified roles of responsibility for each area of the Safety Lifecycle. The Safety Lifecycle is not something that can just be handed off to anyone.  It’s a deep organizational commitment that involves qualified personnel doing specific parts of the job.  Management also needs to provide proper oversight to assure that the process is followed as required.

 

  Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick formed his company, Tehama Control Systems Consulting Services, and has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s SLM Safety Lifecycle Management software.

Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems.