Interfaces and methods are two modern programming concepts that provide essential functionality for object-oriented industrial programming (OOIP). Part 1 of this series introduced OOIP and showed how a control design is built by assembling self-contained objects in much the way the actual plant is assembled from self-contained objects as shown in figure 1.
Distributed objects
In OOIP, objects are distributed throughout a control design just like objects are scattered through a plant or piece of equipment. For instance, say a refrigerator manufacturing plant has an assembly line system, which has an insulation injection subsystem, which has a polyurethane processing subsystem, which has an isocyanate material subsystem, which has a tank subsystem. In this plant, thousands of sensor objects are distributed from the top-level assembly line down to the tank subsystems and throughout adjoining branches.
When the task-based programming approach described in part 2 became popular, no practical way existed to implement central services that could accommodate the distributed nature of an OOIP design. The only answer was to centralize the entire design. Fortunately, newer development environments have implemented features that allow the best of both worlds: distributed control objects (so the control design can mirror the plant design) and centralized services (to manage these distributed objects).
Part 2 introduced the analogy that the older task-based programming technique was akin to a strong centralized government where each tag had to be registered with the service it required (like the Bureau of Scaling, the Bureau of Alarming, and such). OOIP is more like a self-governing society where citizens largely take care of themselves, but even the most ardent fan of small government agrees some level of central government is necessary. How are these distributed objects configured? How are their alarms managed (aggregated, acknowledged and shelved)? How are their state values saved and restored in case of a power failure or controller replacement? Interfaces and methods play a key role in managing these tasks.
Methods
A method can be thought of as a function which belongs to a function block and can be accessed through the instance of that function block. Figure 2 shows an example of the “AnalogSensor” function block which has an “AcceptConfig” method and how an instance of “AnalogSensor” named “L1” is placed on the isocyanate tank deep in the refrigerator manufacturing plant described earlier. At startup, a central service can read the configuration information from a central database and pass the configuration parameters to that instance by making a call to that instance’s “AcceptConfig” method using its full path name, “Plant.AS1.II1.PP1. Isocyanate.L1.AcceptConfig”.
Methods also have access to their parent function block’s variables and can be overridden by methods in extended function blocks. Methods also can have access control to limit access to the parent only (private), the parent and all extended function blocks (protected), or be open to all (public).
Interfaces
Interfaces are a tool for organizing access to a function block’s methods. An interface is a contract made by a function block to support a specific set of methods and for those methods to have a specific set of inputs and outputs. In addition to making methods easier to manage, interfaces allow function blocks which agree to that contract to be treated as a homogeneous group. A central service can then manage all the function blocks as one set.
For example, say we have a variety of types of function blocks which need to know if it is day or night as shown in figure 3. Each of these function blocks agree to the “DayOrNightInterface” contract by adding the words “Implements DayOrNightInterface” to their declaration. Then, all instances of function blocks that have implemented the “DayOrNightInteface” (lines 3 and 4) can be assembled into an array of type “DayOrNightInterface” (lines 6 and 7). This array can then be used to notify the instances as a single group at dawn or dusk (Main implementation line 3).
In traditional programmable logic controller (PLC) programming, every function that needed to know if it is day or night would individually poll the light sensor. This is somewhat akin to the family vacation parody where each child in the station wagon keeps asking dad, “Are we there yet?”
Using methods and interfaces as in figure 3, the sensor is instead polled in one place and the functions are then notified when the status has changed. In this modern sports-utility vehicle (SUV), all the children pursue their own interests and trust dad to let them know when they arrive. The parents travel in peace.
Self-registration
The approach above works fine when the objects are all instantiated in the same program (for example, for an SUV full of children where, presumably, the dad knows all his children). Further steps are required for OOIP where instances of objects can be instantiated inside other objects and objects become distributed throughout the hierarchy of a plant design (such as in the refrigerator plant example above). In this type of system, additional features are used to allow the distributed objects to register themselves with a central service. This system is analogous to families taking a night Amtrak train on vacation where the dad lets the conductor know their destination and seat numbers. The conductor can wake up each family when approaching their destination.
This self-registration relies on a key feature in Controller Development Software (CoDeSys) shown in figure 4. [The CODESYS Group develops CoDeSys, a hardware-independent IEC 61131-3 automation software for developing and engineering controller applications.] Every function block that needs configuration services implements the “ConfigMgrInt” Interface and has “AcceptConfig” and “RegisterMyConfig” methods. The first line of the “RegisterMyConfig” method contains the “call_after_global_init_slot” attribute, which causes that method to be automatically executed when the programs initiates.
The remainder of the registration and configuration process is shown in figure 5. Each instance of each function block that implements “ConfigMgrInt” uses its “RegisterMyConfig” method to pass a pointer to itself, its function block name, and its instance name to the “ReceiveObjectRegistration” method of the “Configurator” central service. The configurator then places that information into an array of type “ConfigMgrInt”. The configurator obtains the configuration data for the configurable objects (from a .CSV file or SQL Database), finds the matching instance name in the array, and uses the pointer provided by the object at initiation time to pass this data to each object’s “AcceptConfig” method. The “AcceptConfig” method then writes the data to the appropriate configuration inputs.
Alarming, tuning parameters
The actual implementation of the configuration and alarm central service is shown in figure 6. Notice the configuration service also includes “ProvideConfigTitles” and “ProvideConfig” methods. These methods allow the system to write a well-formatted configuration parameter file with the configurations grouped by function block type prefaced with a parameter name header line as shown in figure 7. This file serves as an ideal starting point for the controls engineer to begin the configuration specification process.
Once the plant or equipment is up and running, these methods also can be used to store the configuration values of specific instances. This is useful for saving tuning parameters or other changes made to specific instances during operation or archiving snapshots of critical variable values so the state of the system can be restored after a power failure or controller replacement.
Intuitive control designs
OOIP allows engineers to create highly intuitive control designs by assembling control objects in the same way matching hardware objects are assembled in the plant or equipment. In addition to the concepts of OOIP described in Parts 1 and 2 of this series, methods and interfaces are two additional key features of OOIP. These features provide a way for objects that are distributed throughout the plant hierarchy to receive central services, such as configuration, alarming and checkpoints. Just as the best of other general software advancements have been adopted into the industrial controls world, OOIP is following that same pattern. OOIP and its related methods and tools represent the future of controls engineering.
This article was published in Control Engineering 09/2012. Author Gary L. Pratt, P.E., is president of ControlSphere Engineering.