Does your control system have style?

When starting a control system integration project, care must be taken to begin with specifications which communicate end-user preferences to ensure the final delivery meets the expectations of all stakeholders. The development of these specifications is crucial not only to the initial success of the project, but also to the long-term operation and maintainability of the system.

For a new control system, hard-side specifications are the easiest to develop because there are so many resources available. Construction Specifications Institute (CSI) has pre-built sections for controllers and software packages. If the desired detail cannot be found from those sources, control system hardware and software vendors such as Rockwell or Siemens can provide detailed sections. If an end user is looking for bids from more than one vendor, these vendor-supplied specifications must be combed through to make sure they can be met by multiple bidders.

The challenge comes when the end user tries to specify the soft side of controls. It’s important to ask a few basic questions at the start:

• What is the desired look and feel for the screen?
• How will the operator use it?
• What about the maintenance and engineering staff?

From the color of an operating pump to the structure of tags in the controller, these are the items which most define a user’s interface with the control system, and yet they are rarely addressed in the specifications.

The best course of action is to start with a style guide. Style guides have been around forever in other fields. The Associated Press Stylebook covers the use of capitalization, punctuation, and other grammar in news reporting. The Modern Language Association (MLA) publishes the MLA Handbook for research papers, detailing how to attribute sources and write bibliographies. In the technical fields, the Institute of Electrical and Electronics Engineers (IEEE) style addresses research papers as well. In the marketing field, corporate style guides capture fonts, colors, logos, and other information for use across multiple media platforms.

There is no limit to what can be added to a control system style guide, but the following six areas where the work of standardization has the most return on investment:

1. Color

Is red stop and green go? Or is red energized and green safe? Mechanical systems have long relied on the former, while electrical systems the latter. The correct answer is whatever keeps the operators safe. But that correct answer needs to be implemented.

Start by listing the colors used in the facility outside of the control system. Are process pipes painted? Are there pilot lights on control panels? Are there stack lights on the equipment? Preexisting colors which are familiar to the operations and maintenance team should be the building blocks for the color section of the style guide.

Once the master color list is compiled, inevitably there will be duplicates. To resolve this, ask what the operators’ priorities are. Normally, these will be fault, alarm, or other abnormal states. These should get the bold colors. Less important items can be given less important colors by adding opacity or choosing pastels.

The style guide should present this information objectively. Light green for condenser water piping sounds good, but light green means different things to different people. Instead, specify RGB (144,238,144) or HEX code #90EE90 along with an example color block. Also be aware that “no color” is as important as color choices, so make sure the style guide captures background items which should not have color.

Remember that approximately one in 10 men are colorblind, making it difficult to distinguish red from green. These and other operator-specific limitations should be included in decision-making. 

2. Symbols.

How does an operator know when a loop is in manual mode? Is it a picture of a hand, or an “M” in a circle, or just the lack of a bold “A”? ISA101, Human Machine Interfaces for Process Automation Systems, recommends using both color and symbols to communicate with the operators. This color/symbol combination is the same approach adopted by smart phone developers with indisputable success.

At a glance, phone users can distinguish between the “f” for Facebook and the bird logo for Twitter. The operators should be able to make the same instantaneous calls on their systems, and continuity of symbols is one of the best ways to help this happen.

If possible, add bitmaps of pictures to the style guide for these symbols. As with color, “capital M in a square box” gives some information, but an example will minimize confusion. And don’t stop symbol choices with modes (auto, manual, maintenance). What should a pump look like? A blower? A valve? Allowing integrators the freedom to choose their favorite symbol, as opposed to having a fixed standard, has the potential to result in operator confusion.

3. Abbreviations.

How many times have you looked at someone’s shorthand and wondered “What were they thinking?” At times, the conclusion drawn from a series of abbreviations is the opposite of what was intended. In other instances, an individual’s shorthand just looks like typos. Visualization space, even on larger 27-inch monitors, is limited. Unless three-point font is chosen, words may need to be shortened. Just like colors and symbols, establishing abbreviation standards is essential.

Start with engineering units. Are the default units for pressure displayed as “psi” or “psig”? Are gallons per minute displayed as “GPM” or “gal”? Once units are established, move to equipment: tanks, pumps, heat exchangers, boilers, chillers, etc. All have working abbreviations that mean something to specific operators. What about raw components, utilities, facility locations, and finished materials? Compile a list of abbreviations that means the most to the people who will be working with them and use the style guide to maintain consistency.

4. Security levels.

Personnel is always changing, so the style guide is not the appropriate place for tracking individual users and their credentials. It is important to outline security levels as they apply to the staff in general. It’s important to differentiate between what operators trained to do compared to what the mechanics and engineering staff is trained to address.

Unless they are guided, operators may have access to loop tuning parameters with which only mechanics are trained to work, or they may not have access to the alarm-shelving tools they are accustomed to and more than competent enough to handle. Try starting this with a matrix and limit the number of classifications to between three and five, if possible. 

5. Naming convention.

After the system is installed, end users will inevitably be doing maintenance and updates to the system. This is where the “under the hood” portions of control system design become important. Nothing is quite as frustrating as opening someone else’s program only to discover they used abbreviations and shorthand that have nothing to do with process to which they are now applied.

How does any specific team think about their process? For example, is the supply air temperature transmitter on the clean room air handler known by loop number (TT-123), or function (AHU1SAT), or even manufacturer (burnsRTD)? This is how the tag will be found in the program code, and how the team will be able to troubleshoot the equipment during that middle-of-the-night outage. Making sure tags mean something to the team members, and not just the integrator, can be time and money saved.

This same question about the process and team applies to the visualization package. Operators need to see their process defined in a way they can understand. Alarm logs and historical trends have hundreds, thousands, or even tens of thousands of tags to sort through. This is the opportunity to make sure the data they are searching for can be found efficiently. 

6. Code organization.

Modern programming platforms allow for a higher level of organization than ever before. If it is anticipated that the team will be maintaining the code at some later date, they should dictate how things should be organized. The result can be organized by plant area, function, equipment, or some other category, but it should be something the team will immediately identify as their own.

The list of things that can be added to the style guide can go on forever. But like with everything, there are trade-offs. Diminishing returns is one; that is, not getting payback on the time invested adding additional detail. Unnecessary cost of implementation is another; for example, when asking for things one might feel are helpful results in costs of implementation that outweigh the benefits.

But these costs rarely outweigh the benefit of entering your next project with a plan. Making sure the style guide captures colors, symbols, abbreviations, and the rest of the team’s priorities goes a long way toward codifying that plan. And remember, a system integrator or consultant may have value adds for the style guide that the team has not even thought of.

Try working up the first draft internally, then engage the integrator or consultant as a reality check before publication. As with all good specifications, the style guide is a living document. Keep it updated and include it with the hard-side specifications to make sure your next control system project meets all of the team’s expectations.

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our WTWH Media editorial team and getting the recognition you and your company deserve. Click here to start this process.