As the famous saying goes, “the three most important factors in real estate are location, location and location.” For distributed control systems (DCS) used to control sophisticated processes in many industries, the equivalent can be just as easily summed up as “standards, standards and standards.”
The DCS serves as the hub of a manufacturer’s operations and controls. It monitors key variables, such as flow, applied temperatures, pressure, level and material conveying/handling. A DCS’ human-machine interface (HMI) collects data from the production equipment, and presents it in a “human-factored” manner for operators.
Still, there are infinite variables related to the type of equipment, material being processed, operators’ actions and the control system. The DCS must be designed to handle common disturbances as well as unexpected anomalies in a predictable way.
Unfortunately, designing a DCS application from scratch is like staring at a blank sheet of paper; it can be configured in almost any way imaginable. It’s a double-edged sword that can lead to a robust system that delivers precise and predictable control if done carefully. When poorly done, it can lead to lost product, process interruptions and safety issues.
The potential for poor configuration only accentuates the need for established standards and best practices for DCS design. Many professional organizations and associations define the standards and best practices for process control systems. However, most provide only general guidelines that can be applied to any DCS.
There are many ways to achieve a level of standardization in programming and design to create a robust DCS. Standardization begins with a commitment to a shared design philosophy, adoption of best practices, and utilization of tools and techniques that reduce programming complexity and time for similar processing equipment.
Every application configuration should begin with a well-defined design philosophy. Most DCS applications are created and maintained by teams of engineers, so they should all be rowing in the same direction. The best results will be achieved when all contributors to the overall process control application follow the same best practices and techniques. When they don’t, the result is unintended process errors and a system that’s difficult to maintain.
Every engineer contributing to the application should strive to write their logic in the same way. The standard practices used should be well documented and taught to everyone responsible for the control system. In fact, it would be an appropriate indication of a well-designed DCS if control systems engineers can’t identify the specific programmer by looking at the program logic or by observing its execution.
One specific area of DCS design that illustrates the benefit of an established, shared philosophy is alarm management. In process automation, an alarm is defined as an audible and/or visible means of indicating an equipment malfunction, process deviation or abnormal condition requiring a response.
Poorly designed and maintained alarm management systems can overwhelm operators with chattering and nuisance alarms under normal conditions and debilitating alarm floods when abnormal states emerge. When this occurs, it can be difficult for operators to ascertain and act on the most critical alarms, which contributes to abnormal situations resulting in lost production and serious accidents.
Organizations such as the American National Standards Institute (ANSI) and the International Society of Automation (ISA) released updated guidelines related to alarm management. The ANSI/ISA 18.2 standard addresses the entire lifecycle of alarm management from design and configuration through performance monitoring, auditing, and enforcement for the life of the control application.
The ISA committee determined that an alarm should only be used if it requires an operator’s response. However, that is probably the number one thing most processing plants violate. They use alarms for all kinds of notifications, alerts and reminders.
Process automation companies have incorporated a standards-based approach to application development, focusing on differentiating alarms that require immediate attention from less urgent notifications, alerts and messages. For example, Valmet’s D3 DCS is designed to meet or exceed the requirements outlined in ISA-18.2, albeit with slightly different terminology. This includes limiting alarms, supporting alarm prioritization, alarms by classification, and allowing dynamic alarm management.
HMI standardization
To facilitate operator monitoring and control, a DCS uses the HMI for a visual overview of process systems and to monitor critical status and control information.
A properly designed graphical user interface (GUI) improves situational awareness, reduces workload, and enables operators to view the entire process at-a-glance, so they can focus on mitigating abnormal situations.
Although the best practices for any control system are dictated by a standardized approach to configuring the application software, the challenge of designing a system from the ground up is admittedly a daunting task. However, a properly designed DCS can deliver robust and predictable control with constant monitoring of process conditions, clear and concise communications with operators and smart alarm management. Just keep in mind the three most important factors: standards, standards and standards.
Robert Ard is director of applications engineering at Valmet (www.valmet.com), a developer and supplier of process technologies, automation and services for the pulp, paper, energy, marine and other process industries. He’s writing a comprehensive guide to control system design to assist manufacturers, tentatively titled “How to D3.” The book is expected to be published in 4Q23.
