Communicate: Avoid assumptions like the plague
By Michael Whitt
There are certain design tasks and group interactions key to the development of a computerized process control system.
Systems integration (SI) represents a vast category in that development, and it includes software development, data communications, and operability issues.
SI comes from others outside the normal engineering process. Most architectural and engineering (A&E)-type firms do not provide this as an organic service, so SI is not a typical or basic engineering activity. If a customer needs this service and needs it from outside his or her own organization, the A&E firm usually employs a subcontractor or hires a third-party firm that specializes in SI. As with most things, there are exceptions to this rule.
Whether the SI service is from the customer's internal systems group or by an external third-party vendor, a new dimension enters the project.
From the system integrator's perspective, the proper determination of what to do is usually much more difficult than determining how to do it. Sometimes the communication gap between the systems integrator and the customer is so large they may not even realize they are not communicating until too late.
Thus, every control systems project should be approached "by-the-numbers." One should avoid assumptions at all cost. The task may not be a Saturn V moon shot, but if it is worth the expense of doing at all, it is still important enough to do right.
One must check and crosscheck every aspect of the control scheme, especially when it is possible to do so in a relatively cost-effective manner. Whether you are the customer, the engineer, or the systems integrator, the communication techniques are paramount in defining what to do.
First, consider the division of labor. What constitutes the SI task envelope?
Designing and deploying a control package is a very intricate task that involves virtually every organization on the project team. However, the responsibilities of the systems integrator are generally consistent from one project to the next.
Core SI tasks include software development, HMI configuration, and data communications. Peripheral tasks include operator training and maintenance team training.
Systems integrators will, naturally, develop a keen understanding of plant operations during the software development process. That makes them the best candidates for authorship of the technical manuals and for user training.
An operations and maintenance manual is usually required to describe the new controls from both the operations and the maintenance perspectives. Training manuals for each group may also be required. The integration team often leads the training evolution itself.
In some cases, it even makes sense to include the control system cabinetry as an SI deliverable. Sometimes customers want a Factory Acceptance Test prior to shipment to demonstrate software capability and scope compliance.
When systems integrators "turnkey" the entire control system, including the cabinetry, it gives them complete responsibility, thus minimizing the number of interfaces and streamlining the process. Not all integrators have design capability, however.
As might be expected from such a set of tasks, good communication among the various organizations is imperative. This can be daunting and can be more so die to the wide gulf in technical expertise that can exist among the groups.
The programming team may not be familiar with the production process; the production team may know very little about programming; and the design team may not be an expert at either.
So, how do you proceed? Establishing a division of labor and a communications scheme very early to avoid costly rework later is imperative. We will look at some tools and techniques for getting buy-in from all parties before the programming process begins in coming editions of this department.
ABOUT THE AUTHOR
Michael Whitt (firstname.lastname@example.org) is an ISA Senior Member and the I&C (instrumentation and controls) manager at Mesa Associates. His book is Successful instrumentation and control systems design, ISA Press, 2004.