By Dave Harrold
Does this describe you?
Your job is to make informed business decisions. You understand the role of process control systems; you understand the role of safety instrumented systems, but you want a better understanding of safety instrumented system jargon and requirements, and you need to be able to explain safety instrumented systems to your boss
If so, keep reading because this article is for you.
Does this sound familiar?
The following conversation is taking place at the Springfield Snacks and Pesticides Plant between plant manager Mr. Montgomery Barns and supervisor of safety, Gomer Himpson. Let's listen in.
Gomer: Good morning Mr. Barns; how is your day going so far?
Mr. Barns: It's not a good morning when I see you, Himpson.
Gomer: You recall a few months ago that I told you our safety instrumented systems were due for a review?
Mr. Barns: I know that you annoy me about something every month.
Gomer: Well I got with Carl, Charlie and Lenny, and we went through our SIS with a fine-tooth comb. We did a HAZOP and a LoPA and found several of our SIFs were improperly assigned to SIL 1 when they should be SIL 2. We also found a few SIL 2 SIFs that could qualify as SIL 1s, but since we've always maintained diversity among our SIS logic solvers we can't just reclassify these SIFs. We did a preliminary look at the PFD of a few of these SIFs, and we think there is something we can do in the BPCS. Also Mr. Barns, ever since corporate insisted on extending the time between scheduled shutdowns, it is playing havoc with our full- and partial-stroke testing periods. Mr. B. I know I don't have to tell you how OSHA feels about IEC 61511 and IEC 61508. What would really be helpful is if we replaced our old SIS with one from the same vendor as our BPCS; that way everything would be "smart." Of course, that means we really need to install exida- and/or TÜV-certified sensors and final elements.
Mr. Barns: STOP! Have you lost your wits Himpson? You're talking in gibberish and everyone knows that the word "smart" should never be uttered by your lips.
So what do you think? Did Mr. Barns have a clue what Gomer was talking about? Would you? As ridiculous as it probably sounds right now, everything Gomer said made sense, but only if you have some knowledge of the jargon.
During the next few minutes we are going to dissect what Gomer was saying, and we'll also take a look at what it means in terms of safer processes.
". . .went through our SIS"
"I got with Carl, Charlie and Lenny and we went through our SIS with a fine tooth comb."
SIS is an acronym for Safety Instrumented System and is defined in safety standards as, "instrumented system used to implement one or more safety instrumented functions. An SIS is composed of any combination of sensor(s), logic solver(s) and final elements."
That definition provides some help, but let's look a bit closer at this SIS thing.
SIS logic solvers use the input provided by the sensors and execute the program logic that eventually results in an automated emergency shut-down. For example, a 1oo2 (read as one-out-of-two) logic design monitors two inputs. If either of those inputs changes states, the logic solver executes the shut-down sequence. A 2oo2 logic design uses two inputs, and both must agree in order for the logic solver to initiate the shut-down. There are a number of different design types, 1oo1, 1oo2, 2oo2, 2oo3, etc., and it is quite common to mix analog and discrete inputs. This is called using diverse technologies, and it is very useful in eliminating "false or nuisance" shut-downs resulting from common-cause failures.
SIS final elements are the pumps, motors, on/off valves, sometimes throttling valves, etc., that actually stop, close open, or whatever actions are necessary to bring the process to a safe shut-down state.
What Gomer was explaining to Mr. Barns was that he, Carl, Charlie and Lenny had conducted a through audit of the entire SIS―every sensor, logic solver and final element ―in order to compare what was installed and how it was done with what had originally been designed and specified.
Note: A communications network may or may not be a part of the SIS. If the logic solver uses some form of a communications network to connect with the inputs and/or outputs, then that communication network is part of the SIS, and thus becomes subject to all the design and testing requirements of the SIS. However, if the logic solver uses a communication network to connect to a non-safety controller and/or an operator interface, then that communication network is not part of the SIS.
Do not think that every safety application requires a microprocessor-based logic solver. It is still perfectly legitimate to use relays and stand-alone technologies. In fact, there may be situations that justify using a relay or stand-alone system alongside a microprocessor- based solution. Just be sure they remain separate and independent of one another.
…Did a HAZOP, LoPA, …"
"We did a HAZOP and an LoPA and found several of our SIFs were improperly assigned to SIL1 when they should be SIL 2."
The definitions of HAZOP and LoPA have been around a long time and are not confined to SIS discussions. Most companies have been conducting HAZOP and LoPAs for several decades.
HAZOP is short for HAZards and OPerability studies (analysis). HAZOPs are systematic methods used to examine complex facilities or processes in order to find ways to improve operational performance and potentially hazardous situations. It's noteworthy that about 60% to 65% percent of a typical HAZOP study focuses on the operability-related opportunities to improve product quality and overall operational performance.