We all have someone we love – a life partner, kids, friends, family or even a dog. These are the most important things in our lives – and we care deeply about the wellbeing of these special people (and animals) in our lives. We trust employers to make workplaces safe such that our most important ones can come back safely from work every day. Some workplaces have inherent dangers that are exposing people to unacceptable risks unless handled in a good way. How do we manage the most severe accident risks, such as explosion risk on an offshore oil platform, nuclear accidents, or releases of toxic chemicals, such as the horrific 1984 Bhopal accident?

When we build and operate such plants we need to know what the hazards are, and we need to plan barriers to avoid accident scenarios from developing. Risk management is thus integral to all sound engineering activity. A good description of a risk management process is given in ISO 30001 – such a process consists of several steps that should be familiar to practicing engineers and plant managers.

In the figure you can see this risk process explained. First of all, it is necessary to establish the context so that we can understand the impact of the risk – this is we need to ask questions such as;

• What is the business environment we are operating in?
• Who will be present and exposed to the risk?
• What type of training do these people have?
• Where is the plant located?
• Etc., etc.

Then, we work to identify risks. In a process plant this activity is typically done in a number of workshop meetings such as design reviews, and maybe the most important, the HAZOP (a Hazard and operability study). The risks identified are then analyzed, to see what the overall risk to the asset and the people operating it are. Based on the risk analysis, the risk is evaluated up against acceptance criteria; is the risk acceptable, or do we need to devise some scheme to lower the risk?

In most cases where major accident hazards are possible, some form of risk treatment is necessary. In fact, an overall principle for barriers against major accident hazards (MAH’s) that is included in many legislations is:

“A single failure shall not lead directly to an unacceptable outcome.”

This leads us directly to our next natural line of thought; we need to build barriers into our process to stop accidents from happening, or to at least make sure an accident development path is changed to avoid unacceptable outcomes.

Common practice in process engineering is to require two barriers against accident scenarios, and these shall be different in working principle and be able independently to stop an accident from occurring. In practice, one of these barriers would typically be mechanical system not relying on electronics at all – such as a spring-loaded pressure relieving valve. The other barrier is typically implemented in an automation system as a safety trip. It is to this latter barrier type, the Safety Instrumented Function (SIF) we apply the concept of safety integrity levels (SIL) and the reliability standards IEC 61511 and IEC 61508.

Taking overpressure in a pressure vessel as an example, we see how these barriers work to stop an accident from occurring. Assume a pressure vessel has a single feed coming from a higher pressure source, but where the pressure is reduced before entry into the vessel by using a pressure reduction valve (a choke valve). As long as the design pressure (the maximum allowable working pressure, MAWP) of the pressure vessel is below the pressure of the source, we have a potential for overpressurizing the tank. This is always dangerous – and particularly so if the contents are flammable (hydrocarbon gases, anyone?) or toxic (try googling methyl icocyanate). Clearly, in this situation, a single error in the choke valve can lead to a large release of dangerous material. Such errors may be due to material failure of the valve (e.g. fatigue), maloperation or a control system error if the valve is an actuated valve used as final element in a control system, for example for production rate control. Process safety standards, such as ISO 10418 or API RP 14C require such pressure vessels to be equipped with pressure safety valves, that will release the pressure to a safe location when the design pressure is exceeded (typically the gas is burnt in a controlled flaring process). That is one barrier. Another barrier would be to install a pressure transmitter on the tank, and a safety valve that will shut off the supply of the gas from the pressure source. This valve and measurement should be connected to a control system that is independent of the normal process control system – to avoid a failure in the control system from also disabling the barrier function.

To sum it up; by systematically identifying risks and evaluating them against acceptance criteria we have a good background for introducing barriers. All accident scenarios should be controlled with at least two independent barriers, where one of them should be instrumented and the other one preferably not. Instrumented functions should be in addition to the basic control system to avoid common cause failures. The Safety Instrumented System (SIS) should be designed in accordance with applicable reliability standards to ensure sufficient integrity. Finally – the design must comply with local regulations and required industry practice and guidance – such as applicable international or local standards.

What does contract structures have to do with the safety of an industrial plant? A whole lot, actually. First, let us consider how contract structures regulate who does what on a large engineering and construction project. Normally, there will be an operator company that wants to build a new plant, be it a refinery, a chemical plant or an offshore oil platform. Such companies do not normally perform planning and construction themselves, nor do they plan what has to be done and separate this into many small work packages. They outsource the engineering, construction and installation to a large contractor – in the form of an EPC contract. The contractor is then responsible for planning, engineering and construction in accordance with contract requirements. Such contract requirements will consist of many commercial and legal provisions, as well as a large range of technical regulations. On the technical side, the plant has to be engineered and built in accordance with applicable laws and regulations for the location the plant is to be commissioned and used, as well as to company policies and standards, as defined by the operating company.

What is the structure of the EPC contractor’s organization then, and how does this structure influence the safety of the final design? There is a lot of variation out there, but common to all large projects is:

• A mix of employees and contractors working for the EPC company
• Separation of engineering scope into EPC contractor scope and vendor scopes
• Interface management is always a challenge

So – the situation we have is that long-term competence management is difficult due to a large number of contractors being involved. Communication is challenging due to many organizational interfaces. There is a significant risk of scope overlap or scope mismatch between vendor scopes. Finally, some interfaces will work well, and some will not.

Management of functional safety is a lifecycle activity that ties into many parts of the overall EPC scope. Hence, it is critical that everyone involved understands what his or her responsibilities are. Unfortunately, the competence level of various players on this field is highly variable; and an overall competence management scheme is hard to implement. The closest tool available across company interfaces is functional safety audits – a tool that seems to be largely underutilized.

Contracts tend to include functional safety requirements simply by reference to a standard. This may be sufficient in the situation where both parties fully comprehend what t this means for the scope of work, but most likely, there will be need for clarification regarding split of the scope, even in this case. In order to make interface management easer (or even feasible), the scope split should be included in the contract, as well as requirements to communication across interfaces and the existence of role descriptions with proper competence requirements. This would then be easier to work with for the people involved, including HR, procurement, quality assurance, HSE and other management roles.

A well-known fact from accident investigations is that the human factor plays a huge role. In many large accidents, the enquiry will mention organizational factors, leadership focus, procedures and training as important factors in a complex picture involving both human factors and technological factors. In the oil and gas industry it has been found that more than half of the gas leaks detected offshore are down to human factors and errors made during operation, maintenance or startup. On the other hand – humans may also play the role of the safeguard – an operator may choose to shut down a unit behaving suspiciously prior to any dangerous situation occurring, a vehicle driver may slow down to avoid relying heavily on the ABS system for braking on icy roads, an electrician suggests to exchange a discolored socket that otherwise is well-functioning. All of these are human actions that lower the risk. The human thus always comes into the risk picture and can both enhance the safety, and threaten the safety of an asset. This all depends on leadership, training, organizational maturity and attitudes. How do we deal with this in the context of safety integrity levels?

There are many practices. There are thorough methodologies for analysis of human performance as part of barrier systems available, such as human reliability analysis (HRA), developed first in the nuclear industry but now also commonplace in many sectors (petroleum, chemical industry, aviation and transport). On the other side there are the extremes of assuming “humans always fail to do the correct thing” or “humans always do the right thing”. When performing a SIL allocation analysis using typical methods for this such as layers of protection analysis or RiskGraph (both described in IEC 61511), an important thing to consider is: can the bad things be avoided by human intervention? In many cases humans can intervene, and then we do need to have a notion of how reliable the human is. Human performance is influenced by many factors, and these factors are analyzed in depth in the framework of HRA. During a LOPA very detailed analysis of the human contribution is usually not within the scope, and a more simple approach is taken. However, there are some important questions we can bring from the HRA toolbox that will help us build more trust into the numbers we use in the LOPA, or the trust we put in this barrier element in the RiskGraph:

• Is the operator well-trained and is the task easy to understand?
• Does the operator have the necessary experience?
• Does the organization have a positive safety culture?
• Are there many tasks to handle at once and no clear priorities?
• Is the situation stressful?
• Does the operator have time to comprehend the situation, analyze the next action and execute before it is too late?

In many cases the operator will be well-trained exactly for the accident scenarios in question. Also, if designed correctly, there will be clear alarm prioritization and helpful messages from the alarm system – but it is always good to challenge this because quality of alarm design is varying a lot in practice. The situation is almost always stressful if the consequence of the accident is grave and there is some confusion to the situation but training can do wonders in handling such situations by resorting to reflex operating steps – think of basic training of field skills in the military. The last question is always important – does the operator have enough time? What enough time is, can also be hard to give a fixed limit on; for simple situations it is maybe sufficient with 10-15 minutes, whereas for more complex situations maybe a full hour would be needed for human intervention to be a trustworthy barrier element. Companies may have different guidelines regarding these factors – it should always be considered if these guidelines are in line with current knowledge of human performance. No shorter reaction times than 15 minutes should be allowed in analysis if credit is given to the operator. For unusual scenarios, such as the case is for “low-demand” safety functions, a PFD of the human intervention lower than 10% should not be used.

Giving credit to human intervention in SIL allocation is good practice – but the credit given should be realistic based on what we know about how humans react in these situations. Due to the large uncertainty, especially when performing a “quick-and-dirty” shortcut analysis such as discussed above, conservative values for human error should be assumed.

Also note that when a human action is included as an “independent protection layer” in a LOPA, the integrity of the entire barrier system includes this action as well. This means that in order to have control over barrier integrity, the company must carefully manage the underlying factors such as organizational maturity, safety leadership and competence management. Increased attention also to these factors in internal hazard reviews could lead to improved safety performance; maybe could the number of accidents with human errors as root cause be significantly reduced through more structured inclusion of human elements in barrier management thinking.

When we estimate the reliability of a safety instrumented function, we separate between “low demand” functions and “high demand” or “continuous demand” functions. These are all safety critical functions but their nature is different in terms of how frequently they must act on the system of study.

Consider for example the braking system on a train – the brakes need to work every time they are used – for every curve, for every station. The train driver will activate the brakes several times every hour. Obviously, this is a “high demand” system. As an example of the opposite, think of systems where we are monitoring some process and only acting if the system detects a dangerous state. A common example of this is an over-temperature trip on a heating system; if the temperature becomes too high in the system, the system shuts off power to the heater through a circuit breaker (assuming it is an electrical heater). Nobody will design a system such that its intention is to overheat, so this function would only need to activate when a specific scenario hits. Whether this is a “low demand” or “high demand” function depends on how often the function must work – and this again depends both on the “intrinsic frequency” of overheating, and other protection measures that may exist such as independent alarms or special operator training and procedures.

If you think of the stove guard installed in your kitchen that monitors overheating in the range area, what would the demand rate be? If we assume you are a 25-year old person and normally functioning as long as you are sober, you would not forget to turn off the plate on the oven more than once per year. In addition to this, you may get really drunk 10 times per year, and you cook something some of those times, with a higher probability of forgetting – say this also happens once per year – then you have an initial event rate of 2 times per year. Is this the demand rate on the stove guard function? It depends. Do you have any other measures that help you reduce the fire risk?

Typically you would have a smoke detector with alarm, and possibly the stove guard would also give you a pre-alarm. The smoke detector would be completely independent from the stove guard – and if it goes off you would react to it. This takes down the demand on the stove guard if you look at it solely as a way to stop fires from occurring (smoke comes before fire). We now assume that the smoke alarm works 1 out of 10 times and that you or a (sober) friend would always react correctly in this situation – it is normally easy to identify the smoke coming from the kitchen. Then we have reduced the demand on the stove guard to 2 x 0.1 = 0.2 times per year. This is safe to put in the bracket “low demand”. We did not count the pre-alarm on the stove guard itself on purpose, because it can have common cause failures with the core functionality of the stove guard – if one fails, the other one fails too.

The next natural question to ask in this connection is: “how reliable must the stove guard be”? We may conservatively assume that every 10th time there is a real demand on the guard and it does fail there will be a fire that can kill you and destroy the house. This risk is quite severe, and say you would only allow your house on average to burn down every 10.000 years, statistically speaking. This is your “acceptance criterion”. That is, you accept 0.0001 fires per year due to this potential source. We know the demand is 0.2 times per year – what is the allowable probability of failure on demand for the stove guard? This would be 0.0001 / 0.02 = 0.005. This means that we should require the system to have SIL 2 performance with a PFD of minimum 0.005 with this acceptance criterion, if we have a system developed in accordance with IEC 61508.

As a side note – the Norwegian research institute SINTEF has tested some stove guards. They tested 7 different types, and concluded that only 3 of them worked well. The reliability of the devices also depend on installation (location of sensors). This means that close to SIL 3 performance seems unreasonable to expect for the solutions on the market today. The SINTEF report is found at the Norwegian Directorate for Civil Protection’s website.