This article was written by Todd Nydam of JWC Environmental and Graham Nasby, ISA leader and specialist in water and wastewater industrial automation technology.

Integrating controls from an equipment supplier successfully within a plant supervisory control and data acquisition (SCADA) system or distributed control system (DCS) requires communication on multiple levels. These include the process of design, mechanical fit up, and installation, as well as coordination to get the equipment to work in concert with the plant’s other control systems. Simply looking after mechanical and electrical details is not enough.

To be successful, the plant’s system integrator and the equipment supplier’s programmable logic controller (PLC) programmer must work with each other throughout the entire project’s development.

From the perspective of an equipment supplier, several things can help streamline the process of integrating packaged equipment into a plant. First and foremost is planning. Both parties – the plant designer and the equipment supplier – need to understand and appreciate what the equipment is supposed to be doing and how it will do it in the context of the entire plant. This includes both the process design and the controls design.

From an automation perspective, this means that the communications interfaces, and more importantly, the functionality the communication interfaces are supposed to accomplish, need to be well-defined and understood by both the system integrator and the equipment supplier. Putting down details on paper is highly recommended to ensure that everyone is on the same page. Also, any terminology used in the details should be clearly defined, as words can often be interpreted differently.

On a well-run project, integration issues will be sorted out well before equipment arrives on site for installation. Having to sort out such issues after equipment has been delivered is expensive for everyone involved, so it should be avoided whenever possible.

Here are some tips to keep in mind when working with an equipment supplier to provide packaged equipment for integration into a plant SCADA or DCS:

• Make sure both parties understand how the particular type of equipment typically works, and specifically how the individual
  Typical packaged system control panel
  piece of equipment has been designed to work by the equipment supplier. This understanding provides a reasonable basis to work from for any project-specific customization.
• Confirm what type of PLC is going to be used on the equipment, and how that PLC is expected to communicate with the plant-wide SCADA system. This includes clearly specifying what type of communications protocol will be used, whether it will be Ethernet, an industrial network, hardwired input/output (I/O) points, or a combination thereof.
• Determine the general SCADA control requirements of the owner. Is the SCADA system expected to only monitor the equipment? If so, what is it monitoring? Or, is there a need for the SCADA system to be able to send remote commands to the equipment? If the equipment is expected to receive commands from the SCADA, does the equipment need a switch to select whether it is under local or remote control? What sort of equipment status information needs to be sent to the SCADA?
• Determine the alarm and fault display requirements from the owner, as well as any equipment and control instrument status requirements. Put careful thought into how to display this status information, whether it will be on the equipment, on the SCADA system, or on both. Also think about how alarms are acknowledged or reset, as this also can be done on the equipment, via the SCADA system, and/or a combination of both-these need to be carefully planned so that operators will know what to expect.
• The owner must obtain a written description of the equipment control philosophy from the equipment supplier, and the equipment supplier needs to understand how the owner intends to use the equipment in the context of the entire plant. This will be beneficial when setting up SCADA parameters for active control of the equipment.
• The owner's system integrator and the equipment supplier's PLC programmer need to develop and agree on a list of data tags
  A headworks screen is an example of packaged equipment.
  to use for communications to and from the SCADA system. For Ethernet or industrial network-connected equipment, tags are the only way the two systems can "talk" to each other, so this needs to be carefully worked out before either side spends time and effort programming.
• Depending on the type of SCADA system, the system integrator should work with the equipment supplier's programmer to group "like" data tags into arrays to reduce network communication overhead if this could be an issue. Any possible limitations or special considerations associated with the SCADA system or the PLC used on the vendor's equipment should be discussed beforehand by the programmers on the two sides.
• When working with equipment that will be connected to the plant network using Ethernet or an industrial network, the device IP or node addresses should be provided to the equipment supplier's programmer during the development phase. This will reduce the likelihood that the vendor will have to make an extra site visit to update the equipment's control program locally.
• If the SCADA system uses watch-dog timers or "heart beat" signals to ensure that communications between equipment supplier panels are working, the owner's system integrator needs to notify the equipment supplier's programmer of the preferred protocol. This helps ensure the process will not "run away" and helps minimize the chance of nuisance alarms on the SCADA system.
• For equipment that needs a "permissive" signal to be able to operate, clearly define how the permissive signal is generated. Is
  Vendor-provided HMIs and the plant's SCADA HMI have to be developed to work together as part of the design and implementation process.
  it being sent to the equipment by the SCADA system; does the equipment determine the permissive signal itself (e.g., checking a level using a level transmitter on the equipment); or are a combination of external SCADA signals and internal conditions needed for the equipment to start?
• Always arrange to have an "equipment online" signal sent from the equipment to the SCADA system. Then the SCADA system can trigger an alarm if the equipment has been turned off by mistake. The online signal also gives the SCADA system the ability to suppress nuisance alarms if the equipment has been taken out of service.
• Develop a mechanism to record and reinstate default set points on the equipment. This can be done for associated settings on the SCADA system, settings on the equipment itself, or both. Operators will likely see this as a "delighter," as it will allow them to get back to factory defaults if ad hoc changes to the operating parameters have caused the equipment to not work as well as when it was first installed.
• Clearly plan how equipment should respond when different types of possible faults occur with the equipment or associated parts of the SCADA system. For example, in the case of a headworks screen, when a fault condition occurs, grinders should typically be left running, unless upstream gates can be closed automatically. This will prevent the grinder from having to restart in a blinded condition, which can do damage. Usually each type of equipment will have a preferred, and a nonpreferred, type of automated fault response operation.

To successfully integrate equipment into a plant SCADA system, the secret is planning. Communication and coordination between the equipment supplier and the owner need to start early. As a rule, equipment suppliers want their product to work well, but to accomplish this they need to know as much as they can about the intended application of their equipment. This includes system integration and SCADA integration details.

In the system integration world, time is of the essence-the earlier instrumentation and controls-related discussions can take place, the better. A bit of additional communication, earlier in the process, can pay off handsomely for any packaged equipment installation. Remember, resolving issues in the field is expensive-it is much better to sort things out in the meeting room and in the factory before the equipment arrives at the job site.

It is true what they say, it all flows downhill! The submittal was late and lacking detail. The consultant had no comments on the control sequence. Equipment manufacturing took longer than expected, and you did not get an invitation to the factory acceptance test. A snowstorm delayed delivery, and the contractor was not going to dig a hole in frozen ground anyway. The project deadline is looming, and now it is all down to you! What is this equipment supposed to do? What human-machine interface (HMI) screens need to be developed? What I/O points are available? So much for another month's worth of weekends.

Once the equipment supplier releases the equipment for production, its programmable logic controller programmers can begin to provide details about hardware selection, control philosophy, communication protocols, I/O point and error handling, and data-tag structure. A little communication with the right person early on can save a lot of heartache. Pick up the phone, or send an email, and introduce yourself. Oh, and have that list of IP addresses ready, if you do not want it shipped with the supplier's default.

About the Author
Todd Nydam, P.E., is a senior R&D engineer with JWC Environmental, LLC. With training in systems design engineering, Nydam has been contributing to equipment and control philosophy design in the wastewater industry for more than 20 years.

Connect with Todd

About the Author
Graham Nasby, P.Eng., FS Eng., PMP, CAP is an industry-recognized leader in the water/wastewater community for his efforts with DCS/SCADA systems, standards development, raising cybersecurity awareness, and alarm management. Through his work with the International Society of Automation (ISA) and IEC, he has coauthored international standards in alarm management, cyber security, and HMI (human machine interface) design. He has also worked with the ISA, American Waterworks Association, Water Environment Federation, and other industry groups to author numerous articles on SCADA best practices, led the annual ISA Water/Wastewater and Automatic Controls Symposium, and contributed to other industry events.

Connect with Graham

A version of this article also was published at InTech magazine.