WARNING AND COMMENTS ON PROPOSED STANDARD ISA84.91.03

Nov 18, 2020. I hope you saw my prior post about draft standard ISA84.91.03. If not, please read it first.

84.91.03 (Process Safety Controls, Alarms, and Interlocks as Protection Layers) attempts to impose/mandate the rigorous and bureaucratic work processes, paperwork and tracking requirements of a SIS, to elements of tens of thousands of existing DCS systems that were not designed, managed, or operated like SISs. It has 8 “shoulds” and 111 “shalls” (mandatory.) I have completed 80 comments on the draft. It needs much more input from operations companies (or people with operations experience), not just functional safety consultants. There are MANY problems with this document. Comments are due Dec 11, 2020. If you don't comment, then don't complain about the result. Contact me at Billrhollifield AT gmail DOT com for instructions on how to comment and to obtain my comment sheet. It will take you a few minutes to set up, and as much time as you want preparing your comments. You can also read and use mine as a starting point.

From those 80 comments, here are 5 comments that summarize most of the problems with this document, and the suggested changes to address them. These are included in my comment spreadsheet, but I wanted the highlights in this post. Note that an ISA Standard with mandates (“shalls”) is enforceable by regulatory agencies, but an ISA Technical Report (TR), containing only information and recommendations, is not. This is a very important difference. If you make no other comments on the document, these are the 5 most important issues to bring up. Yes, they are wordy but I am explaining the issues thoroughly.

#1 Comment/Rationale. For section 1.

The ISA Standards Procedures (2017) defines: STANDARD: A document that embodies requirements (normative material) that, if not followed, could directly affect safety, interchangeability, performance, or test results. In general, such requirements should already be widely recognized and used. 

The last sentence is a major and important component of what is and is not allowed in a standard.

This document has about 111 mandatory requirements. The committee has provided no evidence that these requirements are in widespread use and proven in practice for the risk reduction (RR) scope of this document (1<RR<=10.) The requirements were essentially lifted from IEC61511, which has a scope of RR>10 and up to many orders of magnitude.

Based on this alone, the content of so many mandatory requirements fails to meet the test of what is allowable in a standard. This is a long list of unproven opinions of “what might be a good idea to do.” Opinion is not the basis for a standard.

This committee has also not widely surveyed existing practices in companies for successfully managing PSCAI of RR<=10. Such a survey might show what current accepted practice actually consists of.

In contrast, the principles in ISA 18.2-2009 had been widely proven in practice and effectiveness (hundreds of sites) for about 15 years prior to 18.2 being issued, and every “shall” was thoroughly vetted. That is the correct way to go about putting mandatory requirements in a standard. This committee is not following this important principle.

#1: Proposed Change

Here are three possible alternatives to solve the issue.

Option 1> The best way to proceed, and conform to the ISA Procedures document, would be to put out 91.03 as a non-mandatory ISA technical report – basically saying “Hey everyone, we are still having process safety accidents. Here is a framework of activities that might prevent them.” “Might,” because until tried, we have no way of knowing which of the 111 mandatory requirements it contains will actually work vs. just be a waste of time.

If that framework is seen to be logical, beneficial, and compelling, then industry will say “Hey, this is a great idea! Let’s try it!” and begin adopting it in part or in whole, and achieve the benefits - if any exist. And, likely make improvement modifications to the TR recommendations based on considerations such as real-world practicality. When that happens and becomes widely recognized and used, THEN a standard reflecting what is found in actual practice might be appropriate. That is not now, however.

Option 2> Take off the IEC61511 blinders. Do a large survey of actual practices in widespread use (many dozens of sites) and clearly shown to be effective, for PSCAI for RR<=10. Some of those might be worthy of codifying in a 91.03 standard (or might not.) Then, an accompanying Technical Report could be written to tell people “Hey, here are a hundred more things you could consider doing to improve your management of PSCAI for RR<=10.” If people find that compelling, and their use becomes widespread, then 91.03 could be revised at a later date to include more of them as mandatory.

Option 3> Rather than convert the entire document to a TR, keep it as a standard with the most minimal of "shalls." This is primarily the requirement for MOC when dealing with PSCAI. All of the rest of the mentioned 61511 bureaucracy becomes content identified as “possibly useful or recommended.” Over time we can see which parts of that content is seen to be persuasive, and widely adopted, and actually used in the field. (If you read ISA-101 you may be surprised that it has almost no "shalls" - basically only that the HMI must have internal company documents, and be placed under MOC. The rest of the ISA-101 content is advisory “should” recommendations.) This document does NOT have to have 111 overblown mandates to be a standard, it can follow the ISA-101 model.

#2 Comment/Rationale For section 1.

The following is also true, as well-stated by Donald Dunn in an article on his Linked-in page: “The purpose of a standard is NOT to produce the best possible document from an outcome standpoint, or what one might call the highest threshold, which is what most people believe it is. The purpose of a standard, by definition of the standards development process of achieving consensus, is to define the minimum acceptable requirements for a topic. Of course, those who use the standards are at liberty to exceed those requirements.” Consensus is not some slim majority vote. Consensus is “the most a group can agree to” at this time.

This document is supposed to have both recommendations and requirements. It is supposed to represent the minimum requirements necessary to manage PSCAI for RR<=10. However, it has only 8 uses of the word "should" and 111 "shall" mandatory requirements. How can this possibly represent the minimum necessary? The answer is that it does not. The document began as a massive copy/paste job from 61511 and the inertia to keep all of that familiar structure and mandates has been immense.

There is no evidence that the ~110 mandatory requirements in this document are the minimum necessary for managing PSCAI as RR<=10 Protection Layers. There is no evidence that the committee has critically examined the appropriateness of these for that far-less amount of risk reduction. There is plenty of evidence that they were just lifted from IEC61511 and rubber-stamped. And there is certainly no evidence that there is widespread use of them for the scope of this document. If there were, dozens to hundreds of such sites could be easily confirmed. Without such evidence these fail to be appropriate for inclusion in an ISA standard. They are just a list of opinions.

If this document is issued as a standard (which it most definitely should not be in its current form) it will be considered RAGAGEP. Recognized and Generally Accepted Good Engineering Practice, and be enforceable by regulatory agencies. Now, while this may or may not be “GEP” (although significantly overkill) it is certainly not “RAGA” for its current scope of RR<=10.

#2: Proposed Change: Same three options as my comment #1.

#3 Comment/Rationale For section 1.

These is documented evidence of the following in email correspondence of industry professionals and committee leadership:

Quotes: “every industry practitioner who I’ve presented the contents to is not happy.”

This is evidence that this document does not represent industry consensus, and does not contain requirements that are already widely recognized and used.

Quote: “The standard is partly motivated by OSHA PSM, so I think it is useful to also think “What would OSHA PSM expect that we do?”

BRH Question: “Did OSHA commission or encourage or put expectations on this 84.91.03 effort to expand 84/61511 to other things? Or are we reading their minds? Please share any relevant communications from OSHA, or if it is the case, indicate that there were none.”

Answer: “There has not been any communication with OSHA regarding this document (to my knowledge).” 

Quote: "All that we’re doing is providing guidance on what is already required per the regulation, which has the weight of law, but is somehow being ignored because of widespread agreement to ignore it."

BRH reply: It is not an ISA committee’s job, role, or responsibility to write new requirements that become backdoor regulations because we feel that existing requirements are not being enforced by the government.

Quote: "With regards to the pushback from industry, the main complaint is that there aren’t enough maintenance resources to do the work that is already on the books. The push needs to go higher in the organization to provide the resources to get this necessary work done. The C-Suite is not going to cut loose maintenance budget because of a technical report, but when OSHA starts dropping fines like they did when ISA 84 was ratified, then the money to do the right thing will appear."

BRH reply: It is not an ISA committee’s scope or role to attempt to usurp the budget priorities of corporate management because somehow "we know better than they do." We are not an arm of OSHA and OSHA is not our cudgel to use based on a feeling that executive priorities are misplaced and “our favorite area” is not getting the attention we think it deserves. There are many other priorities being weighed at that level - things like cybersecurity, for example. This is not the place to mandate 111 new requirements for massive amounts of unproven bureaucracy, paperwork, and outside consultancy. A reading of the document raises reasonable concerns that it would be a major boon for the 61511-consultancy industry, which is also troubling.

So apparently, the committee is taking upon itself to issue massive mandatory bureaucratic paperwork requirements for no other reason than "process safety isn't good enough and we think this will help." No regulatory impetus - just the committee’s opinion that this paperwork approach and rigorous structure that must be applied via 61511 is the ideal, perfect solution and therefore should be applied to a much broader and less consequential scope of plant automation. This is opinion, not fact, and opinion should not be the basis for putting something in a standard.

#3 Proposed Change: These statements are all the more reason that this document needs to be severely toned down, with both the motivations behind it and the requirements re-examined. It can be addressed by any of the three methods in the proposed prior comments.

#4 Comment/Rationale: For section 1.

Mandatory requirements in a standard become backdoor regulations, enforceable by regulatory agencies and the basis for fines and other actions. Regulations require cost-benefit analysis. This is easily seen – obvious - to be a very costly standard to comply with (person-hours of professionals). Why should we not hold ourselves to that same simple requirement? That would be a service to the reader and everyone affected by these mandates. It would provide a justification (or reveal the lack of one.)

Regarding benefits, despite a year of asking, no one has been able to provide a single example where implementing these >100 mandatory requirements would have prevented an accident at a site that is already in compliance with IEC61511 (which is mandatory all by itself.) Failure to follow an existing standard is not justification for writing a new one. If there are not at least several dozen such examples, where is the need for this very-costly-to-implement standard? We have an obligation to inform the reader regarding the benefits, not just pound them with 111 mandatory requirements.

For costs, I estimate that hundreds to perhaps thousands of person-hours (depending on site size) are necessary to attain compliance with this draft of 91.03 and hundreds more annually to remain compliant on an ongoing basis. This is a significant cost and resource impact. It deserves a justification to the reader and to industry. Am I estimating wrong? Prove it by doing a cost/benefit analysis. I do not feel it to be ethical to impose major costs on industry without the accountability of being up-front about it. How can we get behind supporting this if we do not know what it costs, when it is obvious that the cost will be substantial? What is the technical basis for avoiding a cost/benefit analysis? (I word the comment in this way because a prior request for a cost-benefit analysis was flatly refused.)

#4 Proposed Change

Add a cost/benefit section to the document or as an ancillary report available at the same time as the standard. Estimate the cost of initial compliance to all these mandates for a system consisting of 100 units each of mixed PSCAI of RR<=10. Then estimate the ongoing costs for retaining compliance. The reader can extrapolate to their site. This does not seem difficult to do. It would be preferable if it was done by a neutral third party. What possible technical objection could there be about being up-front with this?

#5 Comment/Rationale on section 1.3:

This "authority having jurisdiction" wording is nebulous. We do not know what "local regulatory authority" has jurisdiction to the specific things in this (worldwide) standard nor do we need to mention or consider them. There is a much better approach. In the document: give full jurisdiction and control over applicability and usage of the mandatory contents to the owner/operator. Then any interested regulatory agency can incorporate the standard or issue a regulation mentioning it and making mandatory any sections that they deem necessary. An agency can issue a regulation that says, for example, "All of sections 6 and 8 are mandatory" if they want to - PHMSA has been known to partially incorporate an API document in just such a way. Let's be clear and useful to the reader. Let's make the regulatory agencies do their own work. 

#5 Proposed Change

Reword 1.3 to say: ""This standard applies to PSCAI identified and classified as protection layers where the numeric Risk Reduction Claim does not exceed 10. For compliance to this document, the owner/operator of the facility involved has the sole authority to designate which, if any, of the requirements in this document must be followed.""  

This lets the facility owner apply common sense to the massive bureaucracy advocated by this document, and forces any applicable regulatory agency to do their own work, following their own comment/review process. It’s not our job to do their job for them.

++++++++++++

Bill Hollifield

ISA Fellow and participant in writing 3 ISA Standards and 10 ISA Technical Reports

Principal Alarm Management and HMI Consultant, PAS Global