Object Oriented Industrial Programming (OOIP), Part 2: Abstraction, Nesting and Interfaces

Object Oriented Industrial Programming (OOIP), Part 2: Abstraction, Nesting and Interfaces
Object Oriented Industrial Programming (OOIP), Part 2: Abstraction, Nesting and Interfaces

New Object Oriented Industrial Programming (OOIP) techniques deliver the productivity gains of Object Oriented Programming (OOP) while maintaining the ease-of-use and reliability required for industrial controls applications. Part 1 of this series showed how OOIP can be used to build a plant or machine control program from a set of reusable components that mirrors the way your plant or machine is built from off-the-shelf components as shown in Figure 1. Part 2 of the series will show how blocks can build on other blocks to create large hierarchically partitioned systems and how to manage I/O and Configurations in an OOIP design. 

Figure 1: In OOIP, the Control Design is built from objects which match those in the physical plant or equipment design. Courtesy: Coherent Technologies.


Abstraction, nesting and interfaces

In addition to Encapsulation introduced in Part 1, Abstraction, Nesting and Interfaces are three additional concepts used in OOIP. Abstraction is where detail is grouped by level in a hierarchy so that the programmer only needs to deal with the relevant level of complexity at any one level of the design. Nesting allows Objects to instantiate other Objects to build and logically partition large hierarchical systems. And Interfaces provide a standardized means of interacting with the next level in the hierarchy. In the Mustang analogy from Part 1, the Vehicle has an engine, which has a starter, which has an armature, which has copper wire, which is mined and refined at certain locations around the world as shown in Figure 2. Abstraction allows you to leave the nested complexity of the engine and the mining of its copper to others where that level of detail is appropriate for their level in the hierarchy. You only need to know the Interfaces to engine–the ignition button and the accelerator pedal.

Figure 2: Encapsulation, Abstraction, Nesting, and Interfaces. Courtesy: ControlSphere

Figure 3 shows how Abstraction, Nesting and Interfaces can be used to build a hierarchical process plant. At the top level, the Plant program can nest (instantiate) two Reactor objects, each of which have abstracted away the complexity of two Auger objects which themselves have nested Motor and Shaft Encoder objects. The Shaft Encoder and Motor objects encapsulates all the functionality required to receive pulses from the shaft encoder and control the motor (such as close its contactor, monitor its aux contact or centripetal switch to verify it started, generate alarms if it doesn’t start, etc.). 

Figure 3: Implementing a Process Plant with Abstraction, Nesting, and Interfaces. Courtesy: ControlSphere

Thanks to Abstraction, our only concern at any one level of the hierarchy are the interfaces to the next level.  For instance, the Variable Speed Motor in the Auger has an interface to set the speed of the motor. At the Auger level, we have no need to know or deal with any of the underlying complexity of the motor, such as determining if the motor is responding or generating alarms. 

That is, unless there is a need to know if the motor is responding as would be the case if the Auger had redundant motors. However, in that scenario, the additional functionality would be abstracted away into an additional layer of hierarchy. Instead of the Auger instantiating a VSM, it would instantiate a Redundant VSM which itself would instantiate multiple VSMs and the logic to start a spare motor if the primary motor fails. The interface to the Redundant VSM would still only be the speed command. Each level encapsulates all the functionality it possibly can, and only looks to higher levels for that which it cannot possibly do itself.

Object configuration and IO mapping

The difference between task-based control described in Part 1 and object-based control described in Part 2 can be compared to different forms of governments. Task-based control is analogous to a strong centralized government where new functionality must register with the Federal Bureau of Scaling, and the Federal Bureau of Alarms, and such. Object-based control is analogous to a decentralized government where new functionality is self-supporting and can largely take care of itself.

Now, you might be thinking “Even the most ardent libertarian agrees there is a need for some level of government.” and “Not all 1964 Ford Mustangs are identical.  They have different features and options. How are these handled in OOIP?” and “How does global I/O memory work with OOIP?”  These are all very good questions. The first issue is addressed with Central Services, the second with Configuration Parameters, and the third with Full-Path I/O Mapping as follows.

To fully realize the reusability benefit of OOIP, I/O mapping and Parameters cannot be hard-coded into the instantiation of any object as they are in older programming techniques. For instance as shown in Figure 4, if the Pulse_FI input in the Shaft Encoder in the first Auger in the first Reactor was hard-coded to a global I/O variable, the Pulse_FI input for the other three shaft encoders would also be tied to the same global. That auger object, therefore, could not be reused. The same is true for configurations inputs such as PulsePerLiter_CI.  Hard-coded I/O or configuration is incompatible with modern OOIP programming techniques.

Figure 4: Hard-coded I/O and Configuration are incompatible with OOIP. Courtesy: ControlSphere

OOIP resolves the I/O issue with Full Path I/O Mapping. This is a natural progression for the memory-mapping in the 1970s and the global symbolic mapping of the 1990s. A Full Path Name is the dot-separated combination of the program name, followed by all the intervening instance names, and ending with the variable name (for instance: Plant.R1.A1.SE1.Pulse_FI). These Full Path Names are then used by the I/O editor to map the I/O to their appropriate process variables in the plant hierarchy as shown on the left side of Figure 5. 

Figure 5: OOIP with Full Path I/O Mapping and Centralized Configuration. Courtesy: ControlSphere

The Configuration issue is handled through a Central Service. On startup, instances of objects register themselves with a central Configurator Service and that service then obtains configuration data from a CSV file or an SQL database and distributes the values to each instance as shown in Figure 5. Configuration inputs simplify the design by allowing a small set of object types to meet the broadest possible set of needs. The next part in this article series will show how additional OOP techniques are used to implement the centralized configuration service. 

Figure 6: I/O Mapping via the configuration spreadsheet. Courtesy: ControlSphere

It could be said that the I/O mapping is just another configuration and should be treated the same as all the other configurations as shown in Figure 6. In addition to simplifying the programming, this allows updating I/O mapping on running systems. There is a link at the end of the article to a demo showing how this is done.

Characteristics of an OOIP environment

How do you know if your control system supports OOIP? Look for these capabilities:

  • a means to create self-contained control objects which correspond to matching plant objects and carryout all the functionality required for that plant object such as alarming, auditing, physical I/O, HMI I/O, scaling, control, etc.

  • a graphical editor allowing an unlimited number of instances of objects to be declared, instances of objects to be interconnected in arbitrary fashions, and objects to instantiate other objects into a hierarchy of arbitrary depth and complexity.  During runtime, the editor should allow for simple navigation of the hierarchy such as double-clicking on an instance of an object to descend into the project hierarchy and to navigate back. 

  • the ability to debug individual instances of objects during runtime, including: setting breakpoints within individual instances, single-stepping into individual instances, and viewing/changing the private variables of an instance of an object.

  • a means for instances of the same objects to be differentiated by assigning unique values to the instance’s configuration inputs anywhere the instance may be in the project hierarchy.   Preferably, these configuration values are sourced from a CSV/Excel file, SQL database, or via OPC UA. There must also be a way to search on the values of these configuration variables during runtime (for instance, to search on an ISA tag name configuration).

  • the ability to map physical I/O to any variable in any instance anywhere in the project hierarchy (including mapping an input point to multiple instances).  Composite I/O such as from a fieldbus device must be able to be mapped to individual variables, or to one or more data structure variables anywhere in the project hierarchy.  The tool must provide a way to trace the path of a signal from its input, through the logic and to the outputs it drives (likewise in reverse from the physical output back through the logic to the physical inputs which influence that output). 

  • the capability to build hierarchical HMI objects which match the hierarchical control objects and the ability to interconnect the two objects (and their potentially thousands of underlying interconnections) via the top-level object’s instance name.

  • the ability to print a “flattened” version of the hierarchical design showing the interconnections between the object instances and the unique configuration values on each instance.

  • the ability to implement Inheritance, Methods, Polymorphism, and Interfaces can be helpful. 

  • An active user community and lively forum where open-source Plant Objects and advice can be freely shared.

Coming Up Next

Part 3 of this series will describe the power of IEC61131-3 "Interfaces" and show how this feature allows distributed objects to register with a central service and show how to implement central services. Examples will include a central configuration service, which allows the configuration inputs for objects distributed throughout the plant to be written to or read from a centralized CSV or SQL database, a central storage service which allows tuning parameters to be gathered from distributed objects and backed-up in case of hardware failure, and a centralized alarm service, which allows objects to deal with their own alarms and coordinate through a central service.


In addition to Encapsulation and Instantiation discussed in Part 1 of this series, the concepts of Abstraction, Interfaces, and Nesting further promote reusability of objects and simplification of control system design. In addition, Full Path Mapping and centralized configuration services are critical enablers of reusable objects. In total, these features of OOIP allow the control system design to be built from objects in the same way the plant or equipment is built from objects so that the physical and control designs could become one in the same.  In the future equipment manufacturers could provide the control objects for their equipment.

Not only does OOIP make the design easy to build, it makes the design easy to troubleshoot for plant technicians and easy to maintain for future controls engineers.  Just as the best of other general software advancements have been adopted into the industrial controls world, Object Oriented Industrial Programming is following that same pattern.  OOIP is clearly the future of Controls Engineering.

More information

  • Part 1 of this article can be found here.
  • A clearinghouse for open-source OOIP Functions Blocks and design examples can be found here.
  • A demo on Configurable I/O mapping can be found here.
  • The CODESYS IDE used for the examples in this article can be downloaded at no charge from here. The download includes a complete SoftPLC which will run for 2 hours between resets. 
  • For a video demonstration of Object Oriented Industrial Programming, Simulation, and Configuring Objects, click here.
  • For more elaborate examples of Discrete, Batch, and Continuous control system designs implemented in OOIP, see this video.

About The Author

Gary L. Pratt, P.E. is president of ControlSphere Engineering.  Mr. Pratt’s career began with Chevron Corporate Engineering in 1982 and he recently retired as the president of the CODESYS Corporation of North America.  He holds patents in industrial controls and now concentrates on sharing his knowledge and experience with the next generation through IEC61131-3 and CODESYS training and consulting.  He can be reached at gary@controlsphere.pro.

Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..