2012 ISA

Safety and Security Division Symposium

RAGAGEP FOR LOPA/SLMM/SIS COMPLIANCE

Crowne Plaza Anaheim

Anaheim, CA, United States

REVISED ISSUE – 4/19/2011

NIGEL JAMES

979-299-9893

Abstract: A collection of RAGAGEP implementation challenges and the case studies that provide
an improved methodology.
 ISA2012 Safety and Security Symposium – Anaheim, California

1 THE ULTIMATE SAFETY TEST

As a parent, do you trust your child’s life to a $30 smoke alarm? Most of us do. But there is a
$10,000 F&G Detection System available—why don’t you buy that for your child? Is your child’s
life not valuable and important enough?

We all make the same decisions that we are criticizing the plants for making. We buy the $30
smoke alarm because it the most cost effective. In our business, we spend our effort on the policy
and not on the safety. Then, do we check the $30 smoke alarm’s battery every month and have our
child write down proof that it is still good? That’s what we require of the plants.

If you’re not careful, RAGAGEP and S-84 are the “$10,000 F&G system,” and if you can do it for
$30, why not? Industry has built the $10,000 system that we put on everything and we have lost
focus on what’s important.

Two points to be learned from this: Are you over engineering the solution? Are you maintaining
and managing what you have built per the standard?

1.1 LET’S PLAY JEOPARDY

Answer: 20 SMEs in a room with 50 different opinions.

Question: What is defining RAGAGEP?

Recognized and generally accepted good engineering practices or RAGAGEP—what a mouthful

and what a quagmire we have created with this one phrase. When speaking in terms of general
references, it is acceptable, but when you have to decide if you are compliant or not, then this
becomes a nebulous challenge.

As an industry, we need to minimize the effort and costs on the bureaucracy of the law and focus
on making policies and practice simple, effective, and sustainable. This paper provides examples
of what we’ve learned from several projects where we experienced RAGAGEP for a compliance
activity.

2 WHAT IS RAGAGEP?
RAGAGEP was born from OSHA 1910.119 – Process Safety Management of Highly Hazardous
Chemical, and there are many writing on the general definition of RAGAGEP; here are three:

2
Distributed with permission of author(s) by ISA [2012]
Presented at 2012 Safety and Security Division Symposium; http://www.isa.org
 ISA2012 Safety and Security Symposium – Anaheim, California

• The Process Safety Management (PSM) of Highly Hazardous Chemicals (HHC) standard, 29
CFR 1910.119, is intended to prevent or minimize the consequences of a catastrophic release of
toxic, reactive, flammable, or explosive HHCs from a process. Specifically, OSHA 29 CFR
1910.119 (D) (3) (ii) states: The employer shall document that equipment complies with
recognized and generally accepted good engineering practices.
• EPA Risk Management Program (RMP) also refers to RAGAGEP in 40 CFR 68.73: Inspection
and testing procedures shall follow recognized and generally accepted good engineering
practices. Therefore, RAGAGEPs are engineering, operation, and maintenance activities based
on established codes, standards, and recommended practices. Such a practice establishes
engineering performance criteria based on these established codes, standards, and
recommended practices. It is a benchmark against which performance can be judged. However,
without a specific engineering expectation, this is still too vague.
• Per OSHA Fact Sheet (10/12/2010) RAGAGEPs are voluntary guidelines often produced by
organizations specializing in producing industry standard documents. Examples of RAGAGEP
producing entities include the National Fire Protection Association (NFPA) and the American
Petroleum Institute (API). The PSM standard requires employers covered under the standard to
comply with RAGAGEPs.
However, OSHA does not stipulate RAGAGEP, but leaves this up to the Owner/Operator. There
is no specific definition of what constitutes RAGAGEP. OSHA and the industry have initiated an
effort to get agreement on the list of RAGAGEP, but as of today, nothing has been finalized.

2.1 HOW DOES S-84 FIT?

ISA-S84 addresses the application of safety instrumented systems (SISs) for the process industries
and deals with the interface between SISs and other safety systems in requiring that a process
hazard and risk assessment be carried out. In 2000, OSHA recognized S84.01 as a RAGAGEP for
safety instrumented systems. Regulation and Standards moved from a Prescriptive basis to a
Performance basis:

• OSHA – 1910.1 19 PSM of Highly Hazardous Chemicals (law)

• IEC 61511
• 1996 ISA issued standard S-84 (standard)
• Adopted by ANSI – now replaced by ANSI/ISA S-84
• OSHA links – recognized ISA S-84 as representing good practices
“With respect to SIS, OSHA does not specify or benchmark S84.01 as the only
recognized and generally accepted good engineering practice.”

3
Distributed with permission of author(s) by ISA [2012]
Presented at 2012 Safety and Security Division Symposium; http://www.isa.org
 ISA2012 Safety and Security Symposium – Anaheim, California

The following graph shows the seven Lifecycle Phases and the governing documents for each
phase in regards to legal, normative, and informative issues.

3 NORMATIVE VS. INFORMATIVE

So the big debate is: What is enforceable? There is a false perception that it is everything in S-84
with a shall. In a Standard Interpretation Letter issued November 25, 2005, the Director of the
DEP, Richard Fairfax, supports this: “With respect to SIS, OSHA does not specify or benchmark
S84.01 as the only recognized and generally accepted good engineering practices.”

There are two terms used in industry that are critical for adherence to requirements. The terms are
Normative and Informative.

Normative describes the scope of the document and sets out provisions. Any text related to
meeting requirements is considered normative.

Informative provides additional information intended to assist the understanding or use of the
document. Informative text is not related to meeting requirements.

4
Distributed with permission of author(s) by ISA [2012]
Presented at 2012 Safety and Security Division Symposium; http://www.isa.org
 ISA2012 Safety and Security Symposium – Anaheim, California

However, OSHA, in its enforcement of the PSM regulation, reserves its right to pursue a broader
interpretation of RAGAGEP that may include materials designated herein as Informative. The
Normative standards and codes listed may include both normative and informative text (e.g., a
federal register notice includes the normative rule, but may also have a preamble with informative
text). Any informative item reviewed will always have a normative root reference.

4 CHALLENGES OF S-84 AND THE “SHALLS” STANDARD

The second debate is how to develop a compliance checklist to ensure you meet the intent.

S-84 is comprised of clauses and sections that use the word “shall” to issue directives and
establish requirements. There are 296 “shall” statements that cover the entire safety lifecycle from
design to decommissioning and are established as a best industry practice to govern SIS safety.
Given the importance of S-84 to RAGAGEP, it would seem intuitive to simply use the required
components of S-84 to create a checklist to verify safety systems. However, this approach has
several disadvantages:

• The S-84 standard does not lend itself toward practical use for an audit or questionnaire. An
example of this is clause 9; section 9.3.1 has three shalls and 9.3.2 has one shall. These four
shalls are all concerned with the details of a SIL 4 that can be answered with the review of the
SIL calc and the question: Is the SIF >4?
• Another example of this is found by analyzing the shalls in clause 16. There are 23 shalls in
clause 16, and these shalls can all be captured by four main topics: Operator Training,
Maintenance Training, Failure Demand, and Proof Testing. Thus, four documents concerning
these main topics will support the requirements of clause 16 and four questions can cover all
the requirements.
A pragmatic verification needs to be approached from a different frame of reference. The
preferred approach is asking a general question that touches multiple shalls. The interrelationship
of S-84 elements allows us to take this pragmatic approach. Therefore, an audit protocol based on
the shall list is contradictory to general accepted practices.

5 STEPS TO COMPLIANCE
We believe that when you complete these steps, you will be in compliance:

1. Define what you are doing – Performance Criteria for Defining RAGAGEP.
2. Document what you are doing – Create a Safety Lifecycle Management (SLM) Manual.
3. Verify what you did – Create a checklist of key items.
5
Distributed with permission of author(s) by ISA [2012]
Presented at 2012 Safety and Security Division Symposium; http://www.isa.org
 ISA2012 Safety and Security Symposium – Anaheim, California

5.1 SETTING A PERFORMANCE CRITERIA

One of the results of the collaborative discussion during the development of S-84 was the
development of performance criteria. The performance criteria requires the following five steps to
establish specific RAGAGEP references:

1. List the known publish standards and practices. (1st level) [Normative]
2. Identify key engineering activities that require interpretation. (2nd level) [Informative]
3. Provide 1-3 key examples of engineering outputs to which you can refer. (3rd level)
[Informative]
4. Verify that the examples either validate a single practice or identify a range of applications to
discuss which example is the right fit for the site.
5. We are looking for either Complementary (reinforces) or Contradictory methodologies. The
verifiers will evaluate based on their professional judgment and documented standards and
will compare to the corporate standard.
The purpose, scope, and guidance of each audit will determine the related criteria/questions that
will be used. Given the large amount of work to be performed to include all criteria described in
Chapters 4-25, it will likely be necessary to select which criteria/questions will not be included in
a given audit, given the typical time and resource contraints (Conducting Process Safety
Management Program Audits, page 89).

If there is a future item for which we cannot find a documented reference showing RAGAGEP,
the Verifiers will defer to BP’s engineering standard. A final and crucial step in a RAGAGEP
program is to ensure it is kept up to date as new standards, regulations, and practices are issued
and adopted. New standards are not applied to legacy systems.

5.1.1 EXAMPLE – Risk Matrix/RRF

1. List known published standards: ISA 84 Clause 9 (13 Shalls)

2. Identify key engineering activities:
– Allocate the safety functions to protection layers
– Determine the required SIF
– Determine for each SIF a targeted SIL
– Others
3. Provide 1-3 key examples:
– Following a proper LOPA process; have a proper Risk Matrix

6
Distributed with permission of author(s) by ISA [2012]
Presented at 2012 Safety and Security Division Symposium; http://www.isa.org
 ISA2012 Safety and Security Symposium – Anaheim, California

– Having a key list of layers of protection

– Using the right RRF number
4. Validate the examples to the key engineering activities
5. Is the practice Complementary or Contradictory?

5.1.2 EXAMPLE – Safety Requirement Specification (SRS)

1. List known published standards: ISA 84 Clause 10 (6 Shalls), 10.3.1 has 1 shall, but 27
components
2. Identify key engineering activities:
– Requirements derived from the allocation of SIFs and safety planning
– SIS requirements should be clear, precise, verifiable, maintainable, feasible, and
understandable
3. Provide 1-3 key examples:
– Document IO requirements (Hardware design)
– Functional Logic (Software design)
– SIL of each function (SIL calcs)
4. Validate the examples to the key engineering activities:
– Where do I go to ensure I am doing the SIL calc right?
– What software is considered effective?
– Document IO requirements (hardware design)
– Functional logic (software design)
– SIL of each function (SIL calcs)
5. Is the practice Complementary or Contradictory:
– There are 27, 19, and 14 SRS items in the above references; this defines the range.
– There are many ways to do SIL calcs; each one has advantages and disadvantages.

5.1.3 EXAMPLE – Operations and Maintenance

1. List known published standards: ISA 84 Clause 16 (23 shalls)

2. Identify key engineering activities:

7
Distributed with permission of author(s) by ISA [2012]
Presented at 2012 Safety and Security Division Symposium; http://www.isa.org
 ISA2012 Safety and Security Symposium – Anaheim, California

– Ensure each SIL is maintained for the SIF

– Ensure designed functional safety is retained
3. Provide 1-3 key examples:
– ISA=TR84.00.04-2005 Part 1, Technical Report Checklist No. 8, pgs 98-101
– “SIS Design, Analysis, and Justification,” Gruhn, Cheddie. Checklist pgs 278-279
– “Guidelines for Safe and Reliable Instrumented Protective Systems,” CCPS, par. 6.5-
6.7, pgs 206-212
4. Validate the examples to the key engineering activities:
5. Is the practice Complementary or Contradictory?

5.2 CREATE A SAFETY LIFECYCLE MANAGEMENT (SLM) MANUAL

In order to write a SLM manual, you need to include the following sections:

1. Staffing/Competency
2. HAZOP/LOPA
3. SRS
4. Design
5. FSA
6. Proof Test Procedures
7. Training
8. Auditing
9. MOC

5.3 VERIFY WHAT YOU DID

The SLMM should be a standard document that notes how the end user will implement the shalls.
This should be a simple document that “say what you do, do what you say.”

While not explicit, the field checklist questions naturally flow across the elements of S-84. The
following table illustrates the high level interrelationship of PSM elements between verification
and the S-84 standards:

8
Distributed with permission of author(s) by ISA [2012]
Presented at 2012 Safety and Security Division Symposium; http://www.isa.org
 ISA2012 Safety and Security Symposium – Anaheim, California

PSM Element General Interview Questions S-84 Link

Design Have the right risks been identified? Clause 9 & 10

Is it designed correctly?
Does the SIL meet the risk?
Does the SRS show key design elements?
What are the supporting documents?
Key design/installation deficiencies from
experience and references:
• Bypass
• Alarm
• Valve Failure

Procedures Clause 16

Training

PSSR Clause 14

Mechanical Integrity

MOC Clause 17

Audits

RAGAGEP SLM manual, BMS Design Little of each

The questions covered for the SIF were focused on covering clause 9 and 10. The PSI documents
used to validate the design were the SIF Risk and the SRS. In addition, the SRS is interrelated to
clause 11.

The checklist workflow focused on these key areas:

1. Have the right risks been identified? (#1)

2. Is it designed correctly? (# 2)
3. Does the SIL meet the risk? (#3-6)
4. Does the SRS show key design elements? (#7-20)
5. What are the supporting documents? (#22-29)
6. Key design/installation deficiencies from experience and references:
– Bypass (#30)

9
Distributed with permission of author(s) by ISA [2012]
Presented at 2012 Safety and Security Division Symposium; http://www.isa.org
 ISA2012 Safety and Security Symposium – Anaheim, California

– Alarm (#31)
– Valve Failure (#32)

For the field checklists, we want to note Gruhn, page 204-205, and CCPS (green), page 204-205,
as complementary comparisons for installation and commissioning.

The field checklist workflow focused on these key areas:

• Was it installed to design requirements? (#33-35)

• Were there any changes since it was installed – MOC? (#36)
• Show the test schedule and procedures. (#37-39)
• Verify the logic. (#40) [This applies to hardware and software.]
• Verify operations are… (#41-42)
• Bypass/SORA? (#43)
• Alarms (#44, #46)
• Valve failure (#45, #47)
• Independence (#48)
• Reference the book we just bought and validates another company using checklists

6 CONCLUSION
Don’t Over Engineer It Don’t Over Verify It

10
Distributed with permission of author(s) by ISA [2012]
Presented at 2012 Safety and Security Division Symposium; http://www.isa.org
 ISA2012 Safety and Security Symposium – Anaheim, California

Are we over engineering our solutions? Regarding what you have built, are you maintaining and
managing it per the standards? If the policies are so complex, yet we don’t improve safety, we’ve
missed the point. The purpose of developing an implementation tool is that is has to be sustainable
and it has to make things safe. If we’ve only created a manual that no one follows, we’ve missed
the point. The performance criteria provide a simple, cost effective approach to a sustainable
process within our industry.

Over the development of S-84, in an attempt to cover all bases and solicit input throughout the
industry, the document that resulted is complete, but it is a bit repetitive and needs to be organized
for the application.

That’s what the checklists attempt to do and that’s why checklists are the way to go. Part of
RAGAGEP is to write questions that are representative and reflective for the key items. Checklists
increase the accuracy for the procedures in order to reference specific parts of training at a specific
time.

Checklists are used to automate or assist in covering all of your bases because you are going to
forget something and that can create a dilemma. While you can’t go wrong going through 100% of
the elements, it will always come down to time and money.

11
Distributed with permission of author(s) by ISA [2012]
Presented at 2012 Safety and Security Division Symposium; http://www.isa.org