As the famous saying goes, the three most important factors in real estate sales 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.”

A DCS system serves as the hub of a processor’s operations and controls and monitors key variables such as flow, applied temperatures, pressure, level and material conveying/handling. The DCS’ HMI collects all the data from the production equipment and presents it in a highly “human-factored” manner for an operator.

Still, there are infinite variables related to the type of equipment, the material being processed, the operator’s actions and the control system. The DCS must therefore be designed to handle common, expected 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. This is a two-edged sword that can lead to a robust system that delivers precise and predictable control if done carefully, or it could lead to lost products, process interruptions and even safety issues when done poorly.

The potential for poor configuration only accentuates the need for established standards and best practices in 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 distributed control system.

But there are many other ways to achieve a level of standardization in the 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.

Start with a well-defined design philosophy

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 can only be achieved when all contributors to the overall process control application follow the same best practices and techniques.

When this is not the case, the result is unintended process errors and a system that is 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 application if control systems engineers cannot 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 to the operator an equipment malfunction, process deviation, or abnormal condition requiring an operator 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, contributing to abnormal situations, lost production and even serious accidents.

Recently, organizations like ANSI (American National Standards Institute) and ISA (International Society of Automation) have 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.

Basically, what the ISA committee determined was that an alarm should only be used if it requires an operator’s response, and that is probably the number one thing most processing plants violate. They use alarms for all kinds of notifications, alerts and reminders.

Leading process automation companies have incorporated more of a standards-based approach to application development, focusing on differentiating alarms that require immediate attention from less urgent notifications, alerts and messaging. For example, there are some DCS systems that are designed to meet or exceed the requirements outlined in the ISA-18.2, albeit with slightly different terminology. This includes limiting alarms, supporting alarm prioritization, alarms by classification and allowing dynamic alarm management.

Standardization of the HMI

To facilitate operator monitoring and control, the DCS utilizes Human Machine Interfaces (HMI) for a visual overview of process systems and to monitor critical status and control information.

The DCS interface should display real-time process information in a complete customer-oriented graphical HMI. With standardization at top-of-mind, even seemingly minor details in the design of the presentation of the information have been considered in high-performance HMI layouts. Examples include consistent alarm notification terminology and phrasing, location on the screen and color coding.

A properly designed graphical user interface improves situational awareness, reduces workload and enables the operator to view the entire process at-a-glance so they can focus on mitigating abnormal situations.

Although the best practices for any control system have pursued a standardized approach to configuring the application software, the challenge of designing a system from the ground up is admittedly a daunting task.

In the end, however, it is clear that 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, as long as we keep in mind the three most important factors – it is all about standards, standards and standards.