Like Laying One Stone on Another

Object-Oriented Programming’s Building-Block Approach Means Faster Development Times and Increased Quality and Troubleshooting Efficiency

Share Print Related RSS
Page 1 of 2 « Prev 1 | 2 View on one page

By Jeff Miller

A common problem with many plants is that they have too many existing systems completed by too many different vendors with too many different standards. Whenever plants expand they tend to either 1) accept the control system standard from the vendor, or 2) pick the system in the plant they like the most, and request the vendor to use that as a guideline more than a standard. In today’s highly competitive global market this approach does not maximize value.

Having non-standard programming practices causes increased training burdens and longer troubleshooting and development times. As a result, companies have begun to standardize programming practices; yet few are taking advantage of the latest techniques to maximize the most current controls strategies now available. Recently control systems have increased CPU speeds, memory and bandwidth, and now offer the ability to adopt pieces of the object-oriented methodology that revolutionized the commercial software industry in the 90s.

What is object-oriented programming? It’s an approach that uses programming techniques to encapsulate code and support reusability for common recurring functions, promoting code modularity. The terms reusability and modularity should be emphasized because at the control layer, pure object-oriented programming cannot be implemented, but these aspects can be applied by creating an object-based programming methodology. The benefits of using these strategies are faster development times and increased quality and troubleshooting efficiency.

Certain control systems now lend themselves to an object-based approach, allowing the ability to define object templates and instances derived from object templates and giving programmers the ability to manufacture and configure core code as opposed to custom programming. Templates can be developed for each object at each of the software layers: the control layer, the supervisory layer and the Level III software layer. These templates include standard data structures, properties (alarm conditions, color, historization, etc.), and methods (scripting, logic, etc.) for each of the objects.

At each of these layers, the software can be segregated, but tightly integrated through its data structures. Each layer provides specific functionality within the control system and consists of standard objects that have companion objects in each of the other layers connected by the data structures. This means  the data can travel vertically between the layers, creatings a powerful model that allows for the separation of business rules from the control system and special processing to be done at the appropriate layer. 

Figure 1. Object-oriented programming templates can be developed for each object at each of the software layers.

Control Layer

At the control layer, all low-level machine and process control and all the interfaces to the real-world instrumentation, devices and equipment still occurs. The difference now is that a standard object, consisting of standard data structures, logic and I/O interface, is provided for each device and instrument type. Some standard process control system objects include:

  • Valve
  • Single Speed Motor (SSM)
  • Variable Frequency Drive (VFD)
  • Device controlled by PID
  • Analog Input Device
  • Analog Output Device
  • Digital Input Device
  • Digital Output Device
  • Totalizer

So how does this work? Why wouldn’t we create temperature, pressure and flowmeter standard objects? In essence we have. Each of these devices can be generalized to fit the analog input device object. The temperature may be an RTD, the level may be a 4-20mA signal, and the flowmeter may be pulses going to a high-speed counter card that ultimately gives a rate. The underlying processing logic for each device is exactly the same:

  1. Take a non-scaled value as an input;
  2. Provide a scaled value in the engineering units as an output to the process control system;
  3. Provide alarming and control limits as an output to the process control system;
  4. Provide an interface to the scaling, sample rate, alarming and control limits configuration as inputs.

With those assumptions, we can produce a model at the control layer where the core contains all of the standard code. Inside the core you will find the PLC logic to handle HMI interfacing, alarming, control limits, scaling and filtering. In an object-based system this code exists only once, and all instances reuse this code. There may be 1,000 devices that qualify as analog input standard objects, but only one set of the core logic exists in the processor. This has the effect of reducing the overall programming footprint within the PLC and decreases troubleshooting times because the technicial doesn’t have to look at extraneous code that has no effect on the actual sequencing of the process or system. It allows the engineers and/or maintenance people to focus on the critical sequencing of the system and not wade through logic that has been tested and verified inter-mixed with sequencing logic.

Figure 2. Object-oriented programming can produce a model at the control layer where the core contains all of the standard code to handle HMI interfacing, alarming, control limits.

Page 1 of 2 « Prev 1 | 2 View on one page
Share Print Reprints Permissions

What are your comments?

Join the discussion today. Login Here.


No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments