Pilot Plant Safety Standards

Pilot plant operations are common throughout the petrochemical, pharmaceutical and food industries. Despite this wide prevalence, few if any standards exist governing the safe design, construction and operation of such equipment. What exists is generally copied or scaled down from plant operations, developed internally or following good engineering practice. As a result, most organizations find themselves struggling to independently determine what guidelines they should apply to their own units as well as trying to determine what others in their field are doing. Over time these efforts usually result in the development of some sort of internal company “standards” governing pilot plants. They may be formal or informal, detailed or general, comprehensive or spotty but they almost always end up existing in some form or other. When properly developed and deployed these standards can increase safety and efficiency significantly. Their absence can, conversely, create a higher potential for incidents and lower effectiveness.

This paper will address some of the issues involved in trying to develop, deploy and use these standards.

Why Develop Standards?

Most organizations try to develop pilot plant standards for several reasons:

o To ensure safety by providing a proven safe design for reference and use by all personnel.

o To provide a “how to” guide for new and less experienced engineers, designers and researchers.

o To settle on the "best" of several competing approaches.

o To provide guidance to the craftspeople (in-house or contract) building and maintaining the pilot plants.

In general, most organizations start off with a few informal guidelines that deal with specific problem areas which have caused wider spread difficulties. They then progress to areas which arise frequently in an effort to force some standardization. This usually leads to a desire to develop some guidelines for best practices and often finally results in design and operational guidelines. A few organizations even go so far as to try and tie all these phases together into one comprehensive set of standards, similar to those in wide use throughout the industry for designing process units.

Types of Standards

Standards tend to fall into three broad categories:

1. Prescriptive designs for common recurring needs where the organization wants to enforce a common, uniform approach. In this case, the organization wants to discourage novel approaches and is usually willing to accept some level of added expense and redundancy in exchange. Most prescriptive standards are fairly rigorous and usually have some level of “overkill” built in to address all perceived issues, even when the likelihood of such an issue rising in a specific installation is small.
2. Performance requirements for recurring research requirements that vary widely due to program and research needs and cannot be addressed in a prescriptive fashion. In this case, the standard concentrates on setting criteria for the final design accepting that how this is achieved will vary. Some performance standards tend to incorporate prescriptive elements. These require different prescriptive design given the specific performance need (which is usually also set or defined by the standard) or set guidelines for selecting between several prescriptive designs. Others are more general with few if any prescriptive elements.
3. Risk assessment guidelines for analyzing one of a kind special which cannot be identified in advance or vary too widely for any specific set of approaches. These standards are the hardest to develop and focus on what conditions suggest what set of actions. However, they usually leave the final assessment and decision to the review team.

While most standards fall into one category or another, some may incorporate elements of more than one.

Prescriptive standards are relatively easy to develop. Almost all organizations, even those most adamant that they possess no standards, will have “ways we do that here”. They may be formal, documented and easily retrievable or casual although well know or entirely based on an accepted body of common practice. The more formal the standard the easier it is to find, learn, update and enforce. However, it is usually also more expensive and time consuming to develop and more often to provoke resistance from more “free spirited” or more “knowledgeable” personnel. Informal standards are less daunting to develop, often more widely accepted and usually more easily changed. However, they are often subject to mutation, misinterpretation and deliberately being routinely ignored. I contend that the more formal standards usually pay back the investment in their creation faster and generally end up being more useful in achieving the desired ends.

How Restrictive Should a Standard Be?

The best pilot plant standards are those that allow multiple approaches with adequate guidance for selecting the best one. Even prescriptive standards can have several ways of doing the same thing with rules for which one should be used in what situation. Typically one approach will be more strongly favored than another as cheaper, operationally more desirable, less space intensive or whatever. This can be obvious, allowed to spread through word of mouth or – better yet – explained in the standard itself. However, the existence of alternatives makes the standards seem less stifling, lowers the number of deviations and makes their use and enforcement easier. It also allows common alternate needs to be satisfied without interpretation, deviations or rework.

One cautionary note: if the purpose of the standard is uniformity then this is not the time for alternatives. If one wants all one’s gas cylinders piped the same then allow only one method. However, a lack of alternatives raises the effort needed to ensure that the standard addresses all the needs likely to arise. Otherwise there will be deviation upon deviation which will nullify any attempt at uniformity. This generally increases the length and complexity of the standard. This is not always a bad idea as a truly comprehensive standard can often survive for decades effectively with only minimal updating.

Common Problems with Standards

Often many common issues are not addressed leading to some confusion.  This is usually due to inadequate identification of the scope of the issue to be covered when the standard was developed. This almost always leads to a host of varying interpretations which confuse the issues and result in a serious reduction in effectiveness.  The best approach is to ask a wide variety of end users to review the standard and comment upon any missing areas. A careful oversight and prompt and detailed feedback as it is first deployed also helps to identify any missing areas. These should then be included in a fast revision. Another reason for missing issues is a tendency to consciously avoid addressing certain problem areas due to a desire to avoid limiting flexibility or lack of a perceived right answer.  If flexibility is desired it can be built into the standard. (In this case the standard almost always becomes more of a performance standard.) If there does not appear to be an obvious right answer then this suggests additional work, always popular in overloaded organizations, is required. If the team developing the standard cannot come up with a good answer, how likely are those folks in the field? If the situation is common or likely to arise then ensuring safe operations suggests that taking the time to find as good an answer as possible before it is critically necessary is probably wise. Rarely will a better answer be found when people are rushed and desperate.

Some solutions provide limited if not inadequate detail, assuming a strong common basis exists among the population using the standards.  This can be true when a standard is first written but usually changes with time. In some cases the commonality assumed does not really exist. Asking an experienced outsider to review the proposed standard, a so called cold eyes review, helps tremendously in identifying areas inadequately explained.

Many standards have a very uneven coverage reflecting the lack of an organized overall plan when they were developed.  Some areas are covered in great detail while others are covered cursorily or ignored completely.  Widely varying interpretations of the slighted or ignored areas can then arise. Again a cold eyes review can help to identify these areas. Looking at previous safety reviews for recurring areas where the standards do not seem to have offered any guidance also helps.

Some proposed solutions or approaches are mandated without adequate experience. As a result, problems arise that make their utility (if not their viability) suspect. The worst thing that can happen to a standard is a realization that to make the mandated system work, the operators must modify, ignore or short cut some of the provisions. The best approach is to test each new proposed solution before publication. Alternately a careful watch should be kept of the first few installations with a concurrent willingness to quickly modify the standard to address any problems. There is a natural resistance to changing something developed after much hard work; however, the willingness to make any necessary changes is a strong factor in a standard’s effectiveness and acceptance. We all know no one is perfect and the willingness to quickly admit a mistake and correct it goes a long way towards obtaining buy in form the ultimate users.

The decision basis for standards, particular for arbitrary or controversial rulings is rarely documented. While everyone feels they will never forget the contentious effort to reach that conclusion, time ensures that the original participants are no longer available, the concerns forgotten or now imperfectly understood and the logic behind the decisions unfathomable. As a result, gross misperceptions and bad interpretations will almost certainly arise over time. Always document the reason or logic for difficult decisions. This helps future standards reviewers and enforcers in evaluating special cases or future changes. It also prevents incorrect or misleading information from becoming accepted over longer periods, leading to inappropriate future decisions. And if new information becomes available, it allows easy recognition of any need for revision.

Once written, too many organizations think the act of simply publishing the standards is adequate to ensure their proper use. Sadly, they are usually disappointed as some people always fail to learn about them, others fail to use them and many apply them incorrectly. Training in the extent, applicability and content of standards is required to ensure employee adherence. New standards require training for all current affected employees while new employees need training in all current standards. This training need not be very formal or extensive but provision of a question and answer period frequently helps answer common concerns and identify problems areas. The feedback also helps identify obvious problem areas such as poor wording or missed concerns allowing these to be addressed promptly.

Developing standards in most research organizations is a task approached with the same fervor and interest as a root canal without a pain killer. As a result, there is always a temptation to assign the effort to the most defenseless, new hires, interns or those who have proven to be less successful in other assignments. How calm would you be if your heart surgeon noted that your oncoming operation was going to be very difficult so it was being assigned to an intern fresh out of Medical school? Standards development requires experienced personnel to be effective. If the development is important then you need your best and most technically competent personnel.

Standards Enforcement

One of the most contentious areas of standards for pilot plants is enforcement. Are the standards to be recommended or mandatory? Passions, not to mention hackles, egos and turf wars, always rise on this subject. Research personnel feel mandatory standards stifle creativity, raise costs, make routine operations needlessly difficult, increase equipment complexity and waste significant resources in development, maintenance and understanding the requirements. Recommended standards, on the other hand, are often ignored completely, quoted but not followed, implemented partially or even incorrectly and usually fail to result in achieving the goals of uniformity, best practices and increased safety.

How can these two competing issues be addressed? The problems with mandatory standards are usually due to a variety of other issues rather than being mandatory. Common problems include:

• The standard has not been developed adequately. It fails to address many common needs. It does not give adequate guidance for how to do (or not do) certain things hiding behind platitudes or vague generalizations. It was not reviewed enough within the organization to allow easily identifiable problems to be noted and corrected before release.
• The standard is poorly written. Its language is vague or unclear. Its format is confusing and difficult to follow. It is too abbreviated and fails to adequately address enough common requirements.
• The standard has not been adequately updated. New technologies, new organizational requirements, new ways of trying to do business and a host of other changes occur daily. A standard must be reviewed frequently to address these changes and updated, revised or corrected accordingly. If not, it will end up being ignored with good reason.
• There is no clear and unambiguous way to request a deviation or variance from the standard. This promotes a feeling of helplessness particularly when the special circumstances seem to cry out for a different approach. (Would anyone suggest that going 5 MPH over the speed limit while trying to rush a bleeding family member to an emergency room is truly worthy of a speeding ticket?)

One effective approach to this contentious issue is to put the requirements of each standard against a graduated review process. This allows each standard to be more prescriptive without increasing the number of deviation requests yet ensuring safety. Suppose, for example, a standard gas piping system from a cylinder is mandated. The first level of the standard might prescribe exactly the valve type to be used. This allows a craftsperson or technician to install such a setup with no assistance. Alternate valve types may be allowed if an authorized individual (however one defines that) has confirmed the pressure and temperature rating and the materials of construction. The standard could allow anyone this option by simply placing a note to fie or filling out a simple form. A purge stream may be allowed if a supervisor has agreed that it is needed or desirable. Use of a non-standard flexible metal hose may be permitted after agreement from the local safety contact. A non-standard regulator may be substituted if an engineer has reviewed and approved it for the service. This contrived, and somewhat overly complex, example shows how a standard can be made fairly responsive to individual needs. Generally, only one or two levels or alternate permissions are allowed before requiring a deviation. Otherwise the system becomes too confusing and open to multiple interpretations. Similarly, the permissions are usually restricted to obvious concerns (someone has to check to make sure the substitute ball vale has the proper rating) and usually limited to a few key people (so that any decisions should be at least uniform). One can also use this approach to incorporate operational or maintenance requirements. These can be identified as “non-safety related” and a much less rigorous deviation procedure allowed. In many cases no permission is required and these sections are only recommended. However, their very inclusion goes a long way towards standardization. How many researchers really care what type steam trap they install?

Deviations from Standards

Surprisingly, one effective technique to address issues with mandatory standards is to provide a through, well thought out, documented and well defined deviation procedure from the beginning. This procedure should address what the requestor must do in order to obtain a deviation, who must review the request, what criteria the review group should apply and who has the authority to grant the deviation. Simply having all this detail spelled out in advance helps eliminate a lot of problems. Knowing that one must fill out form XYZ123 to change your mailing address may be annoying but not knowing exactly how to do it is really upsetting.

Commonly, a deviation is allowed whenever the requestor can show two conditions exist:

1. The standard cannot be applied in the requestor’s particular case without making the operation less safe and/or preventing a required part of the experiment; and
2. The requestor has provided some alternative means of ensuring safe operation.

A classic example would be a standard that requires a relief device on all reactors that can be over pressured. A requestor working with a very sensitive catalyst has found (or fears) that oxygen diffusion back through the relief device will poison the catalyst. As a result, the requestor asks to be allowed to eliminate the relief device substituting a high alarm shut off and automatic reactor vent instead.

This example shows several of the problems that any deviation procedure needs to address. Is the requestor’s concern legitimate enough to justify the deviation? (Can that much oxygen really back diffuse? Is the catalyst really that sensitive?) How much “proof” does the requestor need to provide? (Do they need to actually run tests to prove the concern is valid or is simply the concern adequate? Should the requestor be denied until the proof can be provided even at the risk of several ruined experiments or is simply the concern adequate?) How much effort should be required to comply with the existing standard before considering a deviation? (Could the requestor not simply buy a new reactor rated for a higher pressure than any feed source and hence then be allowed to eliminate the relief device thereby eliminating the need for a deviation. Or should a deviation be allowed to avoid this expense?) How safe is the proposed alternative measures? (Can the high pressure alarm fail? Will it react fast enough? Is it fail safe?) What if the request is less specific? Suppose the researcher simply does not like relief valves without a specific reason? Should the deviation even be considered?

A good deviation procedure should address all these issues and spell out what criteria the review team will apply to deciding to grant the deviation. Otherwise a series of inconsistent rulings will arise which always weaken acceptance and enforcement.

Every deviation should be reviewed by a small group (2-3 people) This avoids the appearance of favoritism or personal prejudice while also ensuring that something critical is less likely to be overlooked. The deviation process should be designed to take some time and effort to avoid frivolous requests or hasty judgments. All deviations should be logged and tracked. This allows for future deviations which are the same to be more easily assessed. If the requirements are the same, then the decision – baring new information – should be the same. It also allows the standards to be updated to reflect recurring new needs. Deviations that arise several times should be incorporated into the standards and hence stop being “deviations”.

Updating

Standards all suffer from a desire to finish and move on; yet the updating process is always what separates a good standard from a poor standard. Standards are always in need of updating. The language which appeared so clear and concise in committee turns out to generate confusion in the field. The term everyone forgot to define adequately breeds confusion among the users. The table which appeared to summarize the requirements turns out to be decipherable by no one but the originator. The phrasing open to no misinterpretation generates some bizarre but widespread alternative interpretations. The list is endless!

Similarly, technology changes and new equipment forces a review of old approaches. New research needs arise and spread, resulting in requests no one imagined a short time before. Incidents occur and their lessons suggest modifications, changes or supplemental safeguards. Laws change and require new compliance actions be incorporated. Better ways to achieve a given operational or safety goals are developed and beg to be incorporated. Areas overlooked are identified and need to be addressed.

All of these issues make updating a critical piece of any standard. The updating process should be frequent, typically annually to every 5 years. (Sooner is always better.) It should start with a review of any issues with the standard since the last review. Ideally, someone should be collecting comments and questions about the standard as well as any deviation requests. These form the basis for deciding what needs to be changed. Often changes are trivial. Better wording, clarifying footnotes, a table which is easier to understand, a definition that answers numerous inquiries, etc. Other times, the standard should be modified to incorporate new ways of doing things. Sometimes this simply takes a deviation and incorporates the conditions and alternate safeguards into the standard. In our relief valve example, the update might include a provision to eliminate the relief device if a high pressure alarm and shut down is provided. In other cases, issues which have arisen but not resulted in a deviation should be assed and incorporated. For example, the effect of cheap electric mixers might suggest the need to address their construction if they have begun to completely supplant intrinsically non-sparking air motors.

How Can You Get Started?

A common and very effective way to develop a set of pilot plant safety standards is as follows:

• Gather a team consisting of a cross section of all personnel – engineers, designers, operators, supervisors, researchers, maintenance, etc. One representative from each area is usually sufficient but they should be among the most experienced and knowledgeable people available. While not everyone on the team needs to be a fervent fan of the process (some dissent is good to keep the team grounded in reality) obviously hostile personnel should be avoided as they simply sabotage the process.
• Ask each member to survey their area for recurring problems and issues, situations that seem to call out for standardized approaches and areas which have generated frustration with the best way to precede or implement. Check with the safety group for areas they continually see arising or problems with which they are struggling.
• Gather these inputs and try to arrange them in an organized fashion against a list of prospective standards. Generally, developing the list first, and then assigning each concern to a standard works best. Each concern should appear in only one standard or consistency becomes a major problem. However, listing the concern as a reference in other standards for ease of use is effective. Some concerns will not seem to fit anywhere. Simply keep them on a side list and try to figure out where they best belong as the process progresses. Occasionally a group will suggest a new standard.
• Assign someone to write the first, most vital and easiest standard. Review that draft with the team and settle on a format and approach. Be prepared to spend a lot of time arguing over the details. Once agreed, close down the discussion and move on.
• Assign someone to write each of the other standards. Assign someone else to review each draft. This review is simply designed to catch the obvious errors and save time. Assess the available effort and resources, make a realistic schedule and agree to work to keep it. Get management’s endorsement of the effort and effect or revise the schedule to reflect their constraints.
• Review each draft with the committee. Address any concerns, gaps or problems. Be willing to send off a person or sub-group to more fully analyze or investigate problem areas. Conversely do not become bogged down on wording or appearance. Appoint a style Czar who will rule quickly and absolutely on all such matters leaving the committee focused on content.
• Have the final drafts subjected to a cold eyes review by knowledgeable experts not involved with the standard. A review by one or two end users (such as another research professional and a senior operator or craftsperson) is also very helpful. Make sure the reviewer understands their role is to point out problems and concerns but not continually ask why the standard is necessary. Keeping the same reviewers is often helpful as then they get a sense of the entire scope of the effort.
• Publish the standard at a training session for the appropriate audience. This does not have to be overly formal or very long. Be ready to field questions. Take notes of any issues raised and decide if a fast clarification or revision is warranted.
• Monitor the first few uses of the standard closely to determine if something is amiss. Be ready to quickly correct obvious errors or omissions. Most will, surprisingly, be minor and easy to fix although often devastating if ignored.
• Continue to deploy the standards until complete.
• Set up a review schedule to have every standard evaluated on some reasonable cycle. Gather any deviations or know issues and poll the users for problems they have encountered. Then assess how the standard should be revised if necessary.

Summary

Developing pilot plant safety standards is never easy nor fast nor simple. However, it is a valuable activity that can significantly increase the safety of an organization’s pilot plant design, construction and operation. It usually pays for itself within a few years and almost always is judged a success if approached with care and an appreciation of the potential problems.