The following technical discussion is part of an occasional series showcasing the ISA Mentor Program, authored by Greg McMillan, industry consultant, author of numerous process control books, 2010 ISA Life Achievement Award recipient and retired Senior Fellow from Solutia Inc. (now Eastman Chemical). Greg will be posting questions and responses from the ISA Mentor Program, with contributions from program participants.
In the ISA Mentor Program, I am providing guidance for extremely talented individuals from countries such as Argentina, Brazil, Malaysia, Mexico, Saudi Arabia, and the USA. This question comes from Aaron Doxtator.
Aaron Doxtator is a process control EIT with XPS | Expert Process Solutions. He has experience providing process engineering and controls engineering services, primarily for clients in the mining and mineral processing sector.
Aaron Doxtator’s First Question
I am working on a project that I believe many other sites may wish to undertake, and I was looking for best practice information.
Using ISA 18.2, we are performing an alarm audit using the rationalization and documentation process for all plant alarms. This has been working well, but an examination of the plant’s “bad actors” has slowed down the process. These bad actors are a significant portion of the annunciated alarms, but many of them are considered redundant in certain scenarios and could only be mitigated with state-based alarming.
While the rationalization and documentation process is useful for examining many of the nuisance process alarms, it quickly becomes much more complicated when state-based alarming is to be considered.
The high-level process to implement these changes is as follows:
- Identify the need for a state-based alarm;
- Perform a risk review/MOC process with all stakeholders;
- Implement the changes; and
- Document the state-based alarms.
Is there a recommended best practice that one could follow in order to document the state-based alarm changes?
Nick Sands’ Answer
ISA has a series of technical reports that give guidance on implementation of the standard. TR4 is on Advanced and Enhance alarming, including state-based alarming.
There is guidance that includes:
- Use redundant indications of states to minimize state-based logic failures.
- Be cautious about suppression of alarms that can indicate the transfer of material or energy to an undesired location (example is high temperature alarms on columns, high levels on tanks…)
ISA Mentor Program
The ISA Mentor Program enables young professionals to access the wisdom and expertise of seasoned ISA members, and offers veteran ISA professionals the chance to share their wisdom and make a difference in someone’s career. Click this link to learn more about the ISA Mentor Program.
Darwin Logerot’s Answer
In my experience, there are very few if any chemical or refinery units that would not benefit from state-based alarming (SBA). The basic problem is that most alarm systems are configured for only a single process condition (usually running at steady state), but real processes must operate through a variety of states: starting up, shutting down, product transitions, regeneration, partial bypass, etc. In these situations, alarm systems can and will produce multiple alarms that are meaningless to the operator (nuisance alarms). Alarm floods are the natural result. Alarm floods can be problematic in that they tend to distract the operator from the more important task at hand, can be misleading, and can hide important information.
Now, for a look at actually answering your question: ISA-18.2 TR4 as Nick cited is a good starting point for information on SBA. I will add some pointers and caveats as well:
- SBA at its core is a relatively simple concept – determine the current operating state of the process or system, then apply appropriate alarm attribute modifications. But, as in many situations, “the devil is in the details”. So, best advice is to consult with a knowledgeable practitioner before embarking on a SBA project.
- Apply SBA only to a well-rationalized alarm system, or in parallel with a thorough and principles-based rationalization.
- Apply state transition techniques to prevent nuisance alarms when the process transitions into a running state.
- Utilize commercially available software for SBA, rather than trying to develop custom logic and coding in the control system.
- Another available resource is the Alarm Management chapter in the Instrument and Controls Handbook recently published.
One final observation, I note that you referred to a bad actors review as slowing down the process. My normal approach is to not concentrate on the bad actors, but to conduct a comprehensive rationalization (adding SBA in the process) that includes all tags in the control system. The bad actors will be covered in this process.
Greg McMillan’s Answer
I suggest you check out the Control Talk columns with Nick Sands Alarm management is more than just rationalization and Darwin Logerot The dynamic world of alarms.
Aaron Doxtator’s Second Question
While most of my experience has involved using PLC/DCS (or just DCS) for plant control, some clients have expressed interest in shifting away from using a DCS altogether and utilizing exclusively PLC/SCADA. Aside from client preference, are there recommendations for when one solution (or one combination of solutions) may be preferred over the other?
Hunter Vegas’ Answer
I wanted to address your question about DCS versus PLC/SCADA. Historically DCS and PLC systems were very different solutions. A DCS was generally very expensive, had slow processing/scan times, and was specifically designed to control large, continuous processes (IE refineries, petrochemical plants) with minimal downtime. PLCs boasted very high speed processing, were designed for digital IO and sequencing, and typically utilized for machine control and smaller processes. Over the years both DCS and PLC manufacturers have modified their products to expand into that “middle ground” between the two systems. DCSs were made more scalable (to make them competitive in small applications) and added extensive sequencing logic to make them better suited for digital control. At the same time PLCs added much more analog logic, the ability to program in function blocks and other languages, and began incorporating a graphical layer to make them look and feel more like a DCS.
While the two systems are undeniably much more similar then they were in the past, there are definitely some significant differences between the two technologies that makes one better suited than the other in a variety of situations. Generally we try to remain “vendor agnostic” in our answers so I won’t specifically name names but I will say that the offerings of the DCS and PLC vendors vary widely and some systems have much more capabilities than the other. That being said I’ll try to keep my answer fairly generic.
DCS systems were specifically designed to allow online changes because they were designed for plants that can run years without a shutdown. In such a plant the ability to make programming changes, add cards and racks of IO, and even upgrade software while continuing to run is paramount. PLCs generally have some ability to make online changes but there can be extensive limitations to what can be changed while running. Unfortunately many PLC vendors will say “there are virtually no limits to the changes you can make while running” – and you typically find out the hard way that this is not true even when running redundant processors. If you are looking at installing a control system on a process that must run continuously for long periods, spend a lot of time talking with users (not salespeople) to understand what you truly can (and cannot) do while running. Sometimes the solution can be as simple as creating dummy racks and IO while you are down so you can add racks later.
DCS systems typically have much slower processing speeds/scan times than PLCs. While some very recent DCS processors boast high speeds, most controllers can only process a limited number of modules at high speeds and even that speed (50ms or so) is slow compared to a PLC. If the process is extremely fast, a PLC will likely outperform a DCS.
DCS systems are usually much better at handling various networks and fieldbuses though PLCs have been improving in this regard and several third party manufacturers are now selling PLC compatible network cards. If you have existing bus systems (ASI, Foundation Fieldbus, Profibus PA, Devicenet, Bacnet, Modbus, etc) look at the system carefully and make sure it can communicate with your network. Fortunately the IOT buzz has driven both DCS and PLC manufacturers to communicate over an increasingly large array of networks so most systems are getting better in this regard.
Batch capabilities vary significantly by manufacturer so that capability is hard to define on a PLC vs DCS level. I can name DCS manufacturers who have great batch functionality and others that have minimal capability and are very difficult to program. Similarly some PLCs have good batch capabilities and others have virtually none. If you have batch and are looking at a new control system take the time to dig deep and talk extensively with people who program those systems regularly. The better systems offer extensive aliasing capabilities, have few limits in executing logic in phases, have a good batch operator interface, have an integrated tag database, and allow changes to phases/operations even as a recipe is running. Weaker systems have limited ability to alias (you must create a copy of every phase even if they are identical other than tag names), have limitations in what logic can run in the phases, have poor interfaces, and limit online changes.
Probably the last major point is cost and what are you trying to do with the data. Historically DCSs have had a much better capability to handle classical analog control, advanced control algorithms, and batch processing. Because of that they typically utilize a tag count based pricing model. This pricing strategy can become very expensive if the system is mostly being utilized to bring in reams of data for display and historization but not using it specifically for control. If the process has very large tag counts but doesn’t require extensive control capability, a PLC/SCADA system can be a cheaper alternative.
I hope this helps. If you have any questions about a specific vendor, ask me directly and I can share my experience.
Greg McMillan’s Answer
Most of the PID capability I find valuable in terms of advanced features most notably external-reset feedback and enhancements to deal with large wireless update time and analyzer cycle times are not available in PLCs. The preferred PID Standard (Ideal) Form is less common and multiple PID structures by setpoint weights for integral and derivative modes and the ability to bumplessly write to the gain setting may not exist as well. Some PLCs use the Parallel or Independent Form that negates conventional tuning practices. Even worse, computation of the PID modes in a few PLCs uses signals is in engineering units rather than percent of scale leading to bizarre tuning requirements.
A pneumatically actuated control valve in the loop is much slower than a DCS that can execute every 100 milliseconds. If the loop manipulates a variable frequency drive speed without deadband and rate limiting or speed to torque cascade control, the process deadtime is less than 100 milliseconds, and the sum of time constants from signal filtering and transmitter damping is less than 200 milliseconds, the DCS may not be fast enough but this is a lot of “Ifs” rarely seen in the process industry where fluids are flowing through a pipeline. It is a different story in parts and silicon wafer manufacturing.
For Additional Reference:
Bill R. Hollifield and Eddie Habibi, Alarm Management: A Comprehensive Guide
Nicholas Sands, P.E., CAP and Ian Verhappen, P.Eng., CAP., A Guide to the Automation Body of Knowledge. To read a brief Q&A with the authors, plus download a free 116-page excerpt from the book, click this link.
Additional Mentor Program Resources
See the ISA book 101 Tips for a Successful Automation Career that grew out of this Mentor Program to gain concise and practical advice. See the InTech magazine feature article Enabling new automation engineers for candid comments from some of the original program participants. See the Control Talk column How to effectively get engineering knowledge with the ISA Mentor Program protégée Keneisha Williams on the challenges faced by young engineers today, and the column How to succeed at career and project migration with protégé Bill Thomas on how to make the most out of yourself and your project. Providing discussion and answers besides Greg McMillan and co-founder of the program Hunter Vegas (project engineering manager at Wunderlich-Malec) are resources Mark Darby (principal consultant at CMiD Solutions), Brian Hrankowsky (consultant engineer at a major pharmaceutical company), Michel Ruel (executive director, engineering practice at BBA Inc.), Leah Ruder (director of global project engineering at the Midwest Engineering Center of Emerson Automation Solutions), Nick Sands (ISA Fellow and Manufacturing Technology Fellow at DuPont), Bart Propst (process control leader for the Ascend Performance Materials Chocolate Bayou plant), Angela Valdes (automation manager of the Toronto office for SNC-Lavalin), and Daniel Warren (senior instrumentation/electrical specialist at D.M.W. Instrumentation Consulting Services, Ltd.).
About the Author
Gregory K. McMillan, CAP, is a retired Senior Fellow from Solutia/Monsanto where he worked in engineering technology on process control improvement. Greg was also an affiliate professor for Washington University in Saint Louis. Greg is an ISA Fellow and received the ISA Kermit Fischer Environmental Award for pH control in 1991, the Control magazine Engineer of the Year award for the process industry in 1994, was inducted into the Control magazine Process Automation Hall of Fame in 2001, was honored by InTech magazine in 2003 as one of the most influential innovators in automation, and received the ISA Life Achievement Award in 2010. Greg is the author of numerous books on process control, including Advances in Reactor Measurement and Control and Essentials of Modern Measurements and Final Elements in the Process Industry. Greg has been the monthly "Control Talk" columnist for Control magazine since 2002. Presently, Greg is a part time modeling and control consultant in Technology for Process Simulation for Emerson Automation Solutions specializing in the use of the virtual plant for exploring new opportunities. He spends most of his time writing, teaching and leading the ISA Mentor Program he founded in 2011.
Connect with Greg:
