Not All Control Integration Is Created Equal

Aug. 14, 2017
Completing important steps—not luck—is the key to a successfully implemented control system. A structured, disciplined methodology produces quality and value.

I wonder how many readers have enjoyed the benefits of a well-automated production system that operates seamlessly when recovering from power outages or operator mistakes. Conversely, plenty of readers might have suffered the problems caused by a poorly designed control system. Maybe some have experienced both. Is it just luck? Or is there some science involved? Here are key steps to get it right:

Information gathering and planning

At the very start, it is important to gather all the data you reasonably can to deliver a proposal that fits the end user’s needs and expectations. This deliberate, upfront communication with stakeholders allows us to determine the client’s process and how that process relates to the client’s business and project goals. From this collection of information, the control system integrator can develop a design specification document that can be reviewed and agreed upon by all the stakeholders before starting the design phase of the project.

Contingency management

Having nailed down the core of the deliverables for the project, it’s time to consider what potential contingencies need to be incorporated into the design. Unlike database programming, where the programmer controls every step of the transaction, the real-time control program can only do what the field data will allow.

As an example, perhaps the next step is to add some liquid to something, but it isn’t to temperature yet. What do you do then? Should that be accounted for in advance of starting or is that practical? How long can the process stay in that suspended state and still make a good product? Events such as that should be identified and a plan or set of plans incorporated into the design of the system. Simply getting stalled in the process isn’t a desirable feature of a well-designed system.

Structured, modular programming

One of the additional benefits of a design specification document is the ability to lay the programming modules out in a very specific way before coding begins. Using this style, programmers don’t have to think about what they want the system to do or how to lay it out while writing the syntax. They can concentrate on writing good, clean, well-documented code to execute what they have already thought through.

Extensive testing

A good project methodology will call for unit testing as the system goes through development. At the completion of development, a full integrated test to validate the performance of the system is a required step in the project methodology, to include the recovery from abnormal exits. It is important at this phase to have a documented test protocol to ensure that all the aspects mentioned in the design specification document perform as expected. In the event additional tests come to mind during testing, the team should ensure that those are documented and the desirable outcome stated before starting the test to observe the actual reaction of the system.

Warning

A methodology such as this will produce the best long-term benefit to the end user. It will come online faster, both reducing commissioning costs and producing good product sooner. This will not be the lowest upfront cost when purchasing the system, but will be the best value for the end user and the best total cost of ownership.

One way to reduce the cost of development is to start skipping parts of the above described methodology. Perhaps contingency management is only given a cursory look. Perhaps not so much time is given to upfront planning and information gathering from stakeholders, which could result in a reduction of valuable features for the end user. Perhaps a design specification document is bypassed, which would likely result in more fragmented programming code, then leading to something that isn’t as easily supported or modified.

As with many things, there are ways to reduce the cost of a control system, but is the corresponding loss of value worth it? I suggest finding out whether the integrator is certified by the Control System Integrators Association (CSIA), which requires an audit every three years to verify the integrator’s quality program.

A structured, disciplined methodology produces quality and value.

Ray Bachelor is chairman of the board at Bachelor Controls Inc., a certified member of the Control System Integrators Association (CSIA). For more information about Bachelor Controls, visit its profile on the Industrial Automation Exchange.

Sponsored Recommendations

Why Go Beyond Traditional HMI/SCADA

Traditional HMI/SCADAs are being reinvented with today's growing dependence on mobile technology. Discover how AVEVA is implementing this software into your everyday devices to...

4 Reasons to move to a subscription model for your HMI/SCADA

Software-as-a-service (SaaS) gives you the technical and financial ability to respond to the changing market and provides efficient control across your entire enterprise—not just...

Is your HMI stuck in the stone age?

What happens when you adopt modern HMI solutions? Learn more about the future of operations control with these six modern HMI must-haves to help you turbocharge operator efficiency...