Class-based Unit Coordination Utilizing Link Groups

Nov. 15, 2021
Take advantage of product functionality to coordinate activities between units.

Class-based recipes allow a single recipe to be executed against all Units that meet the required functionalities. Phases required to perform inter-unit coordination can be used to transfer information from any source unit to any destination unit utilizing Phase linking functionality. Based on the equipment arbitration requirements these coordination Phases can be shared among multiple units or can be created so each unit has its own instance of the required Phase.

A philosophical approach to an ISA-88 solution is that Phases should not depend on other Phases to perform their tasks unless they are involved in the same activity.

The basis for this design takes advantage of a product functionality called “Link Groups”. Link Groups are defined during the recipe definition and indicate what set of Phases are intended to be used in conjunction.

“Phase Requests” are Phase commands that can be user to communicate Phases with the batch service. These requests can be used to send information between Phases, to request and release resources, to upload report values on command, and many other Phase functionalities.

Some of the functional requirements of this coordination, consist of providing enough information to know what units are involved in the transfer, what equipment needs to be acquired, and in some cases, when multiple paths can be used to perform the transfer, determine the available paths, and select a valid one based on predefine resource arbitration rules.

To better understand the usability of this product coordination functionality, let’s look at several coordination scenarios:

Creating a recipe pause point in one unit until another unit reaches a specified step can be done with a basic Standard Synchronize Phase and it is typically assigned to each unit. The following diagram is of an ISA-88 Procedure that contains Two Unit Procedures, and each one of them contains an operation. In each of these operations we see a Synchronize Phase (Sync). The recipe reaching this phase first will have to wait until a specific phase in another operation reaches its Sync step. This functionality is of high value to the recipe authors since they can now control when the steps in one unit should run based on the steps of another unit. The link group line between these Sync phases is established by the recipe author and clearly define what phases work in a group, many of these can exist in each operation. In this example, one of the Phases is waiting to receive a message and the other will send a message and wait until a receiver is present. Once this link is established the Phase logic can be set to complete, the set of Phases complete, and the recipe now move on to the next steps. In this example, the recipe in Unit A is dependent on the recipe of Unit B. Only if unit B temperature is > xx degrees then we can start adding catalyst to unit A. 
  • Another case for these link groups is to send information or data from one unit to another. An example may be to share Unit data information or Unit conditions information to another Unit and allow the Phase or receiving unit to determine how parameters may be adjusted based on the conditions of the partner.
  • Material transfers between units is based on the combination of the two previous examples. A transfer OUT (X-OUT) or a transfer IN (X-IN) is reached within the operation of a unit, at this point we do not wish to command equipment of the active transfer until the partner has been linked. Many transfer phases may be active at the same time but only the pair involved in an active link should transfer information. In the diagram below we have a linked transfer pair. Note that for simplicity of controller logic and equipment coordination, all equipment involved in a transfer is controlled by One Equipment module. In this example, the transfer out Equipment Module is responsible for controlling and coordinating all equipment involved in the transfer from the source unit to any of many destinations. The Phase owning the EM receives a message from its link group partner. In this message the transfer Phase sending information to the receiving Phase will indicate who the destination Unit is. In the X-OUT and X-IN Phases there will be two messages: the first one will indicate that the partners are ready for the transfer, and once the EM determines that the material transfer is complete- the second message of the link will indicate that both phases can complete. Each operation can now proceed to their next step. 

    The following diagram is representative of a recipe Procedure that contains two Unit-Procedures, each of them containing one Operation and each one containing a transfer phase that is used to coordinate the transfer of material between Unit_1 and Unit_2. 

    Coordination between Units and transfer of information can be achieved using product functionality. Link groups is a capability that allows Phases to communicate with each other. Class-based recipes will allow possible messaging and synchronization to be built. This functionality eliminates the need for custom code often used to track what batches are running in each unit, and then match the set of units based on their batch ID to determine unit partners.

    Bottom line…take advantage of product functionality to minimize custom code and reduce overall programming effort! 
    Randy Otto is CEO of ECS Solutions, a certified member of the Control System Integrators Association (CSIA). For more information about ECS Solutions, visit its profile on the CSIA Industrial Automation Exchange.
    About the Author

    Randy Otto | CEO of ECS Solutions

    Randy Otto is the CEO of ECS Solutions and brings more than 25 years of experience in diverse industries, including glass fibers manufacturing and custom assembly machine manufacturing. Before joining ECS, Randy spent 10 years managing the delivery of assembly equipment for Integrated Systems Manufacturing and process control systems for Premier System Integrators. For most of the last 12 years, he has managed business development and sales for ECS. Randy graduated from Purdue University with a degree in electrical engineering technology. He has an MBA from the University of Southern Indiana.

    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...