Building the Case for Object-Oriented Programming (OOP)

While not a panacea, the right applications yield impressive rewards

It may not change quickly, but the manufacturing process is changing constantly. Great leaps forward like electrification, computer numerical control, AI-enabled smart motors and networked automation were preceded by breakthrough thinking and followed by massive process gains in productivity, safety, and quality.

The programmable logic controller (PLC), a ruggedized computer for manufacturing equipment and processes, is one such breakthrough. Developed for replacing the hard wiring of thousands of electrical relays per application, the path to the right PLC programming strategy carries a lot of road signs competing for your attention. One of the most intriguing is object-oriented programming (OOP).

Early PLCs were designed to replace relay logic systems. These PLCs were programmed in ladder logic, which strongly resembles a schematic diagram of relay logic. Choosing ladder logic got the job done and was familiar to electrical engineers, technicians, and maintenance staff, reducing training demands. Other early PLCs used a form of instruction list programming based on a stack-based logic solver.

PLC programs are typically written in a special application on a personal computer, then downloaded by a direct-connection cable or over a network to the PLC. The program is stored in the PLC either in battery-backed-up RAM or some other non-volatile flash memory. Early PLCs, up to the mid-1990s, were programmed using proprietary programming panels or special-purpose programming terminals, often with dedicated function keys representing various logical elements of PLC programs. Proprietary programming terminals of the time displayed PLC program elements as graphic symbols, but plain ASCII character representations of contacts, coils, and wires were common. Programs were stored on cassettes. Facilities for printing and documentation were minimal due to lack of memory capacity.

PLC programs are typically written in a special application on a personal computer, then downloaded by a direct-connection cable or over a network to the PLC. The program is stored in the PLC either in battery-backed-up RAM or some other non-volatile flash memory.

Under the IEC (International Electrotechnical Commission) standard 61131-3, (third edition published in February 2013), PLCs can be programmed using standards-based programming languages. The most commonly used programming language is ladder diagram (LD) also known as ladder logic. It uses relay-based contact-coil logic to make programs like an electrical control diagram.

IEC 61131-3 currently defines five programming languages for programmable control systems: function block diagram (FBD), ladder diagram (LD), structured text (ST; similar to PASCAL), instruction list (IL; similar to assembly language), and sequential function chart (SFC). Experts have stated that even if ladder is initially the starting point, “everyone we work with gravitates toward ST over time.” That said, all these techniques emphasize logical organization of operations.

Function Block Diagrams use elementary blocks to represent functions and receive inputs from lines entering from the left. Lines exiting to the right represent output results.

Enter OOP

Pinning down the definition of object-oriented programming can be an interesting proposition. Wikipedia calls it a “paradigm.” Certain PLC providers call it a “principle,” others an “architecture.” Not a language, but supported by many modern high-level industrial programming languages including Java, C++, C#, and Python, perhaps “approach” works well in covering what OOP brings to the party.

Pre-IEC-61131-3, PLC programming was growing difficult for scaling as process applications grow increasingly complex, says Adam J. Cook, chief technical officer for Alliedstrand. “There was a desire for strategies to "break-up" the data and behavior into more manageable, isolated chunks to help readability, modification, and reuse,” he says. “Like Python and other existing high-level programming languages, the strategy chosen was to adopt object-oriented programming (OOP), which was proving to be quite resilient in constructing general software systems,” he says. “As a result, PLC vendors and the IEC standard have become more responsive and have put more focus on OOP.

Bob Trask of Beckhoff Automation states it even more clearly: “As a rule, PLC software development is no different than any other software development and all tools available to the software development world are also available for PLC software development.  (Source Control, UML, OOP, etc). When software is written in a consistent documented manner it will be easier to read, easier to modify, easier to re-use, and easier to update.  This saves time, which saves money.”

Sean Leonard, OPC product manager at Matrikon, adds further background. Historically, building a control system software application involved developing algorithms and data structures that solved a specific problem. The problem could be solved in a series of steps (or procedures). This method of programming is referred to as imperative or procedural programming. This approach to software development works extremely well if the problem only needs to be solved once and if the size of the problem is relatively small.

As the size of the problems being solved by control system software applications increased, complexity also increased, making procedural programming cumbersome. Software developed using the procedural approach is often difficult to describe, maintain, and extend.

“From an economic perspective, an obvious way to profit from developing software is to reduce the amount of software code that needs developing”, Leonard continues. “Code re-use is one of the easiest ways to achieve this objective. Typically, the amount of code reuse achievable using the procedural methodologies is relatively small, meaning as programs become more complex, using the procedural approach to develop software eventually becomes less attractive”.

A fundamental breakthrough in software design was the concept of data abstraction using objects. Instead of developing software by modeling program flow, the software is modeled using objects. Objects are the nouns of the system. An object is a unit of structural and behavioral modularity that has properties inside code. Not only does such an object encapsulate design decisions, it also encapsulates behavior, identity, state, and even business rules of the system. The process of representing a problem as a set of cooperating objects, and the relationships between the objects is Object Oriented Programming.

Objects and Methods

Bob Trask presents OOP as a methodology. “It’s a way of thinking,” he says. Everything in the world is an object, including systems or machines, which are not only objects themselves, but composed of objects. “The evolution and development of a system is caused by the interactions among the objects inside or outside the system,” he explains.

Consider a bicycle. The bicycle is an object. Properties of the bicycle (frame, gears, pedals) also are objects, while the “verbs” of the object (applying brakes, shifting gears) are the object’s methods.

Encapsulation, inheritance, and polymorphism are object-oriented programming attributes that help organize code and extend efficient re-use.

With procedural programming, separate routines are called from the main program. In other words, a procedure call invokes the procedure. After the sequence is processed, the control flow proceeds right after the position from where the call was made.

Objects can include a number of routines and their data (“encapsulation”). Due to the countless methods and properties associated with any object, many interfaces can be defined for calls and data access. Objects include behaviors, things an object can do like procedures and functions in other languages. Objects also have attributes or properties, information an object “knows.” But probably most impactful, encapsulation and defined interfaces means objects can be reused.

Trask describes encapsulation as one of the “four pillars” of OOP, the other three being abstraction, inheritance, and polymorphism. Encapsulating defined objects allows consistency each time the same series of events, checks, or changes occur. Done correctly, it ensures attribute manipulation is done properly each time, which aids unit testing and code stability.

Abstraction in object-oriented programming means properties and methods can be “hidden” within objects, making for simpler interfaces and reducing the impact of changes. “OOP is about encapsulating data and functionalities within a discrete container, meaning it is an isolated component within a larger system,” adds Adam Cook. Not totally isolated, however, as inheritance means the container can inherit functionalities from other containers or function blocks; or multiple function blocks can prescribe to a common interface. “This greatly helps code organization, reuse, and cuts down on the cognitive load required.”

While inheritance allows existing objects to be extended without changing the original working code or the context, polymorphism allows tested algorithms, used with the object, to be reused with subsequent child class implementations without retesting the algorithm. These features combine to provide programming constructs aligned with framework design and code extensibility.

PLC Makers Support

This is not to say object-oriented programming can immediately replace all other coding methodologies. As previously mentioned, there are still plenty of machines programmed in ladder logic still running out there supporting manufacturing operations. “Both are alive and kicking,” says Mike Chen, director of the Automation Center Americas at Omron. “At the end of the day, people keep the machinery running. Whether you are a programmer, an operator, or a maintenance person, manufacturing companies have employees with different skill sets and expectations where both procedural and OOP methodologies can coexist and optimize productivity.”

OOP may increase market share in industry as the PLC programming talent pool continues to consolidate and shift from electrical engineers to programmers. Objects, encapsulation, and inheritance are good for handling complex arithmetic. “It’s also really useful for protecting intellectual property,” he adds. “OEMs can ship a machine to their customer and ensure that no one else can access the source code.”

While PLC suppliers like Omron continue supporting Ladder Logic and OOP programming, basic rules still apply. “You can’t just run and gun,” Chen notes. Up-front planning and decisions on how to best solve and code the applications is still required, taking into account company and departmental realities. Some manufacturers want to maintain current systems, others are planning for complete line replacement. Determining business priorities, functional and cultural, is crucial.

Process Objects in Action

Saving time and improving efficiency is a universal priority. Rockwell Automation outlines how process objects saved notable time in commissioning a major processing plant. Time was vital for Yuhan-Kimberly’s converting plant in Kimcheon, South Korea. With the rapidly increasing demand for bathroom paper towels, it no longer was efficient or effective to import raw materials from the United States for processing and packaging in the Kimcheon facility. Yuhan-Kimberly needed to produce the raw materials in-house and decided to undertake a project to move the towel machine in the U.S. facility to Kimcheon.

This would require a major controls upgrade. Within this production process, Yuhan-Kimberly was running an outdated legacy distributed control system (DCS). Replacement parts were a challenge to find, and it was almost impossible to obtain the updated functions needed to improve efficiency to levels Yuhan-Kimberly wanted, such as additional machine safety options and a multidiscipline system that included a modern process solution and safety controls. Complicating the situation, to meet production targets, the new system migration would need to be completed quickly, with no downtime.

Yuhan-Kimberly began working toward replacing the facility's legacy control systems and modernizing the architecture to increase productivity and safety. The company wanted an integrated system that would provide full production line and recipe capabilities and solve quality and consistency issues problematic with the legacy DCS. Because of the old system's complexity, it was important that the new installation be user-friendly.

Yuhan-Kimberly secured bids from Rockwell Automation and other automation suppliers for converting the system, the company reports, which included controller, human-machine interface (HMI) and machine safety. It also analyzed the applications used on the legacy system and considered how those applications could be designed, migrated, installed and commissioned on a Rockwell Automation platform.

The new process control system centers on the Allen-Bradley ControlLogix programmable automation controller (PAC). Unlike traditional controllers, ControlLogix PACs provide multidisciplined control leveraging development tools, a network protocol, and service-oriented architecture, making it a fully integrated, scalable control platform that can be used throughout the Yuhan-Kimberly's plant.

The core advantage of this is a single hardware and software solution that includes an Integrated Architecture-based modern DCS, (PlantPAx) and machine safety control via a single industrial network: EtherNet/IP. To accelerate the migration process, maintain consistency and reduce installation time, the customer relied on the Rockwell

Automation Library of Process Objects. This Library is simple and convenient to use and allows operators to minimize system deployment and test time. As a result, this solution improved production efficiency, expedited the start-up process, and improved time to market.

According to the company, the Rockwell Automation Library of Process Objects shaved two months off implementation time, so operators installed the PlantPAx system ahead of schedule. They immediately took advantage of easier operating procedures. For example, instead of checking the logic programs one by one, (a legacy system requirement), operators were able to check and change the machine's operating condition and view the interlock status safely via the faceplate.

The smooth migration completed on the single platform reduced spare parts and training costs. Additionally, the modern DCS has reduced the total cost of ownership (TCO) while satisfying the customer's request for improved machine safety.

Claims and Truths

As with many technology decisions, building a case for object-oriented programming deserves the time devoted for research and due diligence to separate claims from truths.

Claim:  OOP can save significant time.

Truth:  As the Korean plant example shows, OOP took two months off of implementation time, and also provided notable operating and maintenance efficiencies. “But it does not speed up software development,” says Bob Trask. “Applied correctly, there are many opportunities for time savings.”

Claim:  OOP is better than procedural

Truth:  Paraphrasing Eisenhower, plans are meaningless, planning is essential. With poorly thought out operating goals, OOP code can be inefficient and needlessly complex.

Claim:  OOP is hard.

Truth:  “I think the perception is that OOP is difficult in some industry quarters - and that it always adds more difficulty than it is worth, which I do not think is always true,” replies Adam Cook. “Certainly, for simpler process applications, OOP can be overkill. But for programs of even moderate complexity and for operations that change quite a bit, OOP can be very helpful and pay some pretty big dividends down the line.

“Like all new things and taking into account that the industry gears have always moved slowly, OOP is going to be naturally foreign and scary. Industry training is improving across PLC vendors (who very typically already support IEC-61131-3 and the CFC extension), but even with extensive training offerings, it will take time.”

“It is up to the individual companies/teams to decide which ideas (if any) they like and will implement,” Bob Trask says of software development. “The key item is consistency, so long as all programmers follow the same approach, software becomes much more readable, re-usable and more robust.”