Object Oriented Industrial Programming (OOIP), Part 1

Object Oriented Industrial Programming (OOIP), Part 1
Object Oriented Industrial Programming (OOIP), Part 1

Industrial controls software engineering has unique requirements for high reliability and for ease of use by a broad spectrum of users. Those are the reasons why graphical languages have been the mainstay of industrial controls programing and industrial controls engineers tend to wait for the latest trends in computer science mature before adoption (such as symbolic addressing and data structures which both matured for 20 years before entering the industrial controls mainstream).
 
Object Oriented Programming (OOP) began to be used by computer scientists in the 1990s but has been slow to be adopted into the Industrial Controls world due to its complexity and the lack of a supporting graphical language environment. Fortunately, industrial software vendors are beginning to address those issues and provide many of the benefits of OOP to the controls world without the complexity. 
 
This article will show an example of one of those tools, show how engineers can take advantage of these benefits by mastering a small subset of OOP concepts, and show how programming with objects is a natural and intuitive technique for controlling the object-based physical world.


Definition of OOP in industrial controls

The Industrial Controls community and the Computer Science community tends to differ on the interpretation of the term Object Oriented Programming (OOP). To avoid confusion in this article, we will refer to the industrial controls interpretation as Object Oriented Industrial Programming (OOIP) and differentiate it as follows: 

  • Object Oriented Programming (OOP)
    • includes the full suite of computer science OOP features
    • primarily text-based
    • typically the domain of highly educated computer scientists
  • Object Oriented Industrial Programming (OOIP)
    • uses the concepts of Encapsulation, Composition, and Abstraction to build systems from self-contained reusable Function Blocks
    • primarily graphics-based
    • usable by controls engineers and plant technicians with minimal training

 


The evolution of OOIP

In the early days of industrial automation, programming was flat. We read the inputs, scaled the inputs, generated alarming on the inputs, performed the control algorithms to generate outputs, performed alarming on the outputs, scaled the outputs, and wrote the outputs using memory mapped I/O (as shown in Figure 1).  Later when Functions became available, we consolidated some of the duplicate code, but the process was still essentially flat.




Figure 1: Original Flat Programming Style

When control software began to accommodate multiple tasks, industrial programmers adopted a centralized task-oriented approach.  This approach divided the operations up into separate tasks and then a sequence of centralized processes performed each separate operation on the tags in the program.  The first task would read all the inputs, the next task would scale all the inputs, the next would perform alarming on the scaled points and so on as shown in Figure 2.



Figure 2: Task-Oriented Programming Style

This centralized task-oriented approach was a big advancement over the flat approach, but it suffered from the need to modify each task when new functionality was added to the program.  In addition, task-oriented programming often made it difficult to see the flow of information and to understand the cause and effect relationships in the control code.  These drawbacks made programming more difficult to design and more complicated for technicians to maintain (particularly younger team members schooled in OOP and less comfortable with task-oriented programming). 
 


Figure 3: Object Oriented Programming Style

OOIP turns the task-oriented process on its side as shown in Figure 3.  Instead of the functionality being spread out amongst many tasks, the functionality is contained inside “Objects”.  Since industrial control plants consist of objects (such as: motors, conveyors, valves, and sensors), Object Oriented Programming is a natural choice for industrial controls … perhaps even more than the computer programming for which OOP was originally created!  In fact, objects for the controls can be designed to correspond to the objects in the plant or machine in such a way that the control program begins to look very similar to the plant design as shown in Figure 4.  With the right control diagram editor, the plant design and the control design could be one in the same!


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

To implement OOIP, controls engineers only need master two key OOP concepts:  Encapsulation and Composition. 

Encapsulation

Encapsulation allows objects to be created which contain all the functionality and data necessary to control its matching plant or machine object.  The user does not need to know or understand the underlying implementation … they just use it!  A good analogy is a car engine.  The engine encapsulates pistons, valves, bearings, and a multitude of other objects and complex functionality.  The driver doesn’t need to know how an engine works, they only need to understand and interact with its interfaces: the start button and the accelerator pedal.

The Analog Input block which appears on the lower left side of Figure 4 and detailed in Figure 5 is a good example of OOIP Encapsulation.  This block encapsulates all the complexity of an Analog Input including scaling, clamping, filtering, override, rate-of-change alarming, and high/low alarming.  The programmer is only concerned with the configuration of the block (the inputs on the left ending in _CI) and the outputs to the program (Output_PO and SmoothedOutput_PO).  The programmer doesn’t need to understand or be concerned with the underlying complexity.  Just drop it in and use it … just like the engine in your car.  
 


Figure 5: Analog Input Function Block


Composition

Composition is the ability to declare and use multiple copies of an object without making copies of the object.  In IEC61131-3, these objects are called “Function Blocks”.  A Function Block is a data type in the same way that an Integer or a Real is a data type.  “Instances” of Function Blocks are created by declaring them in exactly the same way instances of integers are declared.  Behind the scene, the compiler allocates unique memory for the variables in each instance of the Function Block in exactly the same way it would allocate memory for an instance of an Integer.  And, just like one can declare an unlimited number of integers (up to the memory capacity), one can declare an unlimited number of instances of a particular Function Block.  Figure 7 shows how an object is instantiated and used in the CODESYS Continuous Function Chart (CFC) editor.



Figure 6: Instantiating an object in the CODESYS Continuous Function Chart editor

An analogy I like to use in my training classes is that of the Ford Mustang as shown in Figure 7. The 1964 Ford Mustang is vehicle “Type” (in exactly the same way an Integer is a date “Type”). You cannot drive the 1964 Ford Mustang “Type” until an instance of it is created (in exactly the same way you cannot use an Integer until it is declared).  So, the workorder which instructs the Ford assembly line to create an instance of a 1964 Ford Mustang for you is analogous to the declaration which instructs the compiler to allocate Integer memory for you.  In this way, the 1964 Ford Mustang in your driveway becomes your instance of that data type.


Figure 7: Function Blocks

But just as you can declare (and the compiler can allocate memory for) numerous integers, the factory can manufacture numerous instances of the Mustang vehicle “Type." In this way, your neighbor can have her own 1964 Ford Mustang which is completely independent of yours. Their functionality is completely encapsulated in each instance of the object (potential quantum entanglement not withstanding). 
 

Coming Up Next

Part 2 of this series will show how three more concepts: Abstraction, Interfaces, and Nesting can be used to assemble lower-level objects into objects of greater complexity, and how this can be repeated to build an entire plant or machine from a set of basic building blocks. It will also show how I/O is mapped to objects distributed throughout a design, how parameter inputs can be added to objects to enhance their reusability, and how a central configuration service can be created which allows these parameters to be managed from a single CSV file or SQL database. 
 

Summary

Tool vendors are beginning to make the benefits of OOIP available to Controls Engineers.  To leverage those benefits, controls engineers need only master two key OOP concepts: Encapsulation and Composition.  With that knowledge, controls engineers can encapsulate the functionality of physical objects into matching control objects, and then instantiate those objects to create a control design which mirrors the plant or machine design.  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

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

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

Read more

Did you enjoy this great article?

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

Subscribe