Class Based Unit Synchronization, The Case For Link Groups

To coordinate activities between units, take advantage of product functionality to greatly reduce controller code programming. Unit coordination is used during activities such as material transfer from one unit to another, may be used to coordinate recipe pause points in a unit while the recipe of another unit reaches a desired step, or may be used to transfer process data from one unit to another for further evaluation, etc.

Using product functionality to create a class-based solution while minimizing programming greatly simplifies the complexity of the code. The product functionality consists of link groups and Phase logic phase request (PXRQ for phase manager phases and RQ for classic OPC phases).

To better understand its usability, we will use a sample process consisting of units capable of transfer material with each other: One to Many, Many to One, Many to Many. In any of these examples keeping track of who the groups involved in a synchronization can be as simple as specifying the required pairs (more that two concurrent can be done as well) in the procedural (recipe) model.

Let’s look at several 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 the step. This functionality is of high value to the recipe authors since they can now control when the steps in one unit 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 since many of these can exist in each operation.In this example (example A) 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 and 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 receiving unit to determine how parameters may be adjusted based on the conditions of the partner.

Material transfers between units is based on a 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 bellow 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 (EM), 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 they will be two messages, the first one will indicate that the partners are ready for the transfer, 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.

Link groups is a capability within FTBatch that allows phases to communicate with each other via the batch server via recipe defined link groups, a class based recipe will allow all possible messaging and synchronization to be built. This functionality eliminates the need for custom code required to track what batches are running in each unit and then matching the set of units based on their batch ID. In addition, the batch server controls and track all information related to the communication between phases. Take advantage of product functionality to minimize custom code and reduce 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.