Establishing Automated Control of Plug-and-Play Components

Controlling modular, self-contained process skids (known as plug-and-play components) with an automation system can greatly increase a pharmaceutical manufacturing facility’s flexibility. This technique can help increase manufacturing process efficiency and allow operators to change process parameters easily. Establishing an automation system that communicates effectively with plug-and-play components can be difficult, however. Equipment and Processing Report asked Scott Sommer, automation technology manager at Jacobs Engineering Group (Conshohocken, PA), about the challenges this automation solution poses and the strategies that can overcome them.

Q: Is it important for employees who design the automation system to understand the unit operation that each plug-and-play device performs?

A: My experience has shown that, as with any process-control system implementation, the best systems are those that were designed by professionals who truly understood the process. Structured, modular, reusable code requires that each function be modeled in the process-control system and that all interactions between these modules be allowed or disallowed based on the function of the skid. Unless the automation professional clearly understands not only what the skid can do, but also what it should not be allowed to do, the operation of the skid will be neither efficient nor error-free.

Q: How do you manage data flow to and from plug-and-play devices?

A: Mapping data (or associating data) to and from the process skid and managing the mapping configuration in the process-control system are two obstacles to efficient operation. Because the configuration and the actual skid data reside on different sides of the cable, close attention must be paid to the definition, implementation, and maintenance of the data link. Changes in logic must consider not only the affect on Skid A, but also on Skids B and C. If Skid D is introduced, then the number of possible interactions increases dramatically. A well-written and well-structured user-requirements document, functional specification, and software-design specification will help keep all components and data strategies in the foreground. These elements will provide valuable documentation of what exists in the logic and how it is structured.

Q: Why is it a problem if skids’ controllers follow different standards and templates than those of your plant system?

A: Obviously, standardization of data table space helps the identification and control of these skids. Standardization can be achieved through harmonization of the data structures with the skid vendor or through code that rearranges the data into the proper format and structure (i.e., forced harmonization or interpretation).

Q: How does a control system recognize a plug-and-play device?

A: It can do this in several ways. When each skid has a unique node or address, the control system can check for the presence of a particular input–output (I/O) rack or node.

Or the control system can use a smart transmitter tag (such as those from HART or Foundation Fieldbus) to determine which skid is plugged in. Usually a pressure-indicating transmitter works well because most skids in a pharmaceutical or biopharmaceutical plant have them. Alternatively, a skid could use a wireless transmitter to broadcast its identity.

Another solution is for operators to establish a keyed control-system connection. In this case, a particular pin on the connection or a special encoded input can be used to determine which skid is plugged in. No two skids would use the same key pin.

Once a skid is identified, its attributes, including which instruments are present and their corresponding tags, can be retrieved from a table or data file.

Q: Why is tagging and numbering skids difficult when you have several skids with different configurations that plug into a common location?

A: The main issue is that several devices might share the same connection to the process-control system. If chromatography skids A, B, and C can all plug into process location 1, then the control system will need to determine which skid is plugged into that location and what physical I/O corresponds to that skid.

Overcoming this difficulty requires allocating the same I/O table space for each of the possible skids that could plug into a single location. In addition, the same location should be assigned within that I/O space for each possible instrument (e.g., instruments that measure inlet temperature, outlet temperature, and pump discharge pressure), so that the same equipment modules and control modules can be used within the control-system logic. If a device does not exist for one skid, then its table space should be left open and unused.