Organize objects into a hierarchy. Complex control systems are rarely flat. Direct control is generally at the bottom, managed by group supervisory code. That supervisory code is in turn supervised by more sophisticated control or sequential logic that is in turn manipulated by even more sophisticated procedural code, and on it goes. Diagrammatically, the hierarchy mimics the roots of a tree, with the various root hairs (field I/O) converging over and over again to form devices, groups, process functions, operations, procedures, etc., until everything combines into a common trunk (the operator). This natural hierarchy is dictated by the process and/or operating requirements and is generally not difficult for a process control engineer to uncover. Once known, it makes sense to structure the code objects in a similar hierarchy, with each object capable of performing its desired function while collaborating with other objects to carry out group actions.
ISA-88, being initially focused on batch processes, provides a thorough set of guidelines for properly sorting out the desired process/equipment hierarchy. The standard also defines different object types used to model the hierarchy, namely procedural and control. Procedural objects deal with the execution of pre-defined, recipe-driven operations that produce a product with the highest quality or in the greatest quantity. Ordering and sequencing of process steps are the principal focus of procedural objects.
By contrast, control objects provide coordinating and basic control functionality, but sometimes include equipment-specific procedural logic as well. Equipment modules (EM) and control modules (CM), which are the common variants of the control object, translate process-oriented functions into equipment actions and form the all-important interface between the control system and the physical plant. An appropriate collection of these workhorse objects can fully realize all of the operator-directed functionality of a process which does not require automation of its operating procedures. For this reason, a lot of care is taken to describe the details of their creation.
The corresponding workhorse elements of IEC 61499 are called basic and composite function blocks, but their purpose and intent generally matches that of EMs and CMs. One distinction of IEC 61499 is in how it further breaks down the function block into two separate parts, namely algorithms and equipment control charts (ECC). Algorithms manipulate process data and ECCs process event information. While EMs and CMs contain the same inherent functionality, ISA-88 does not specify that a clear separation exist between the two halves.
Utilize flexible mechanisms for communications between objects. A hierarchical control structure only works when objects can communicate effectively with each other. The communication mechanisms supporting the supervision of one object by another need to be simple and reliable, but also need to be flexible enough to permit more complex cases - where the conditional selection of which object is in charge at any given moment may be required (commonly needed for batch recipe execution). In this way, the hierarchy can be modified as needed at runtime, adapting to the varying needs of the process or the operating personnel. Reliable, but temporary, connections can be established between objects and then replaced with equally reliable connections with other objects when necessary. This is analogous to joining objects with Velcro rather than welding the pieces together.
Another aspect of inter-object communication is that of entity location and identification. In truly distributed systems, it is often a requirement that the communications between objects include information about the ID (e.g., DNS name) and sometimes location (e.g., network segment) of the message originator or recipient (or both). This is especially true of IEC 61499, where a stated goal is to achieve distributed control that permits the flexible assignment of execution responsibility for the various logic components across a widely distributed physical architecture. This is similar to the scheme employed by applications constructed from software-as-a-service (SaaS) components. This service-oriented architecture (SOA) permits any component of the system to reside anywhere in the network space without impeding the operation of the system as a whole. The execution flexibility gained by this approach is valuable for obvious reasons, but requires a sophisticated and well-structured messaging scheme that can be too much effort for many projects to justify. Therefore, since the degree of required flexibility – and resulting message complexity – varies for each project, choosing an appropriate messaging scheme to meet project goals should be left to the discretion of the solution designer.
Establish a proxy for external interfaces. When communication must cross boundaries of systems which are created or managed by different resources, it is a good idea to have a proxy object to facilitate data mapping and execution control (blocking or re-directing messages). These features can greatly enhance the flexibility of development and start-up efforts, not to mention ad-hoc troubleshooting of problems that arise later. Quite often, the interface is provided by a middleware product which already possesses these desired features; but when a sufficiently functional middleware solution doesn't already exist, a proxy object should be created to provide adequate user control of the communication link.
Establish well-defined and well-managed modes. Modes are an important aspect of control system design, and are a key mechanism used in the management of process constraints. Without modes, process constraints must be defined in a one-size-fits-all manner, which is obviously not the ideal case. With modes, however, situational awareness can be integrated into the operation of the process – invoking certain constraints when they are relevant and ignoring them when they are not.