Special Section: SCADA
Component object-based SCADA
Component object-based SCADA software improves productivity and lowers life-cycle cost of systems
By Steve Garbrecht
Supervisory control and data acquisition (SCADA) and supervisory human-machine interface (HMI) applications that developed using software that supports component objects can result in significant labor savings over traditional tag-based approaches.
Component and object-oriented software architectures have been successful for many years in the commercial computing world, but now these methods are making their way into the process control and SCADA software communities. The following terms are used to describe component software:
- Object-oriented programming (OOP): Programming language model organized around “objects” rather than “actions,” and data rather than logic. Historically, a program has been viewed as a logical procedure that takes input data, processes it, and produces output data. The programming challenge was seen as how to write the logic, not how to define the data. In contrast, object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them.
- Component: A component is a reusable program building block that can be combined with other components in the same or other computers in a distributed network to form an application. Components can be deployed on different servers within a network and can communicate with each other to perform services. Examples include a single button in a graphical user interface, a small interest calculator, or an interface to a database.
- Container: Components run within the context of a container. Examples of containers include web servers, application servers, and database servers.
- Component object-based: A system that uses an object-oriented development workflow to produce a componentized application that can be distributed across any number of computing resources. Because the linkage from component to component and from the development environment to the run-time environment is maintained, incremental changes can be made without having to shut down the entire system.
- Replication: The creation of components from object templates.
- Change propagation: The process of changing an object template once and then selectively distributing that change throughout an application, multiple applications, or an entire system.
From the inception of PC-based HMI and supervisory products, the development of data access, scripting, alarming, and data analysis has been based on the concept of tags. Although this approach can be simple and portable from one project to another, a tag-based environment uses a flat namespace, which is a shortcoming because individual elements cannot be linked or organized into more intelligent structures with built-in relationships and interdependencies.
Global changes to a tag database are typically done externally to the development environment, as a text file or in tools like Microsoft Excel, and then re-imported into the application. Reuse in a tag-based system is commonly instituted through dynamic or client-server referencing. The system creates a common graphic containing scripts that switch the tags in runtime. Because the application structure is flat, the user must then change each tag in the system and analyze how the change affects the rest of the application.
Component object-based systems
The concept of component-based or object-oriented development originated in the IT world. Its goal was to provide tools that would release the developer from mundane, repetitive program tasks, while at the same time maximizing reuse through the development of common components.
These tools are not an exact fit for the industrial environment. For example, there are some key architectural differences between IT and production automation applications. IT applications typically involve accessing databases from non-deterministic, forms-based interfaces that accomplish things like online banking, business reporting, HR management, financial accounting, or static information look-ups.
Conversely, plant intelligence, production management, or supervisory control applications involve acquiring real-time data, performing sophisticated calculations to determine flows and production numbers, displaying real-time data in graphics-intensive client environments or analysis tools, and/or writing to and reading from production and operational-related databases.
The two environments are different enough that there are component object-based tools purposely built for SCADA, control, and automation.
Comparing the systems
The following table contrasts component object-based and tag-based architectures:
Another major advantage over tag-based software is components in object-based architectures can easily be distributed across networks and work together for distributed control.
Benefits for manufacturing applications
In component object-based SCADA applications, application objects contain aspects or parameters associated with the device they represent. For example, a valve object can contain all the events, alarms, security, communications, and scripting associated with a device.
Objects do not just represent plant equipment. They can also model common calculations, database access methods, key performance indicators, condition-monitoring events, ERP data-transfer operations, and a variety of other production and performance management tasks.
Because these operations are modular, it is easy to add them to any and all parts of the application. For example, if there is a standard way your organization calculates and initiates a maintenance work order for a pump, you can encapsulate this function as an object and use it with any pump in the application.
Manufacturing applications typically have a number of common components, including common types of:
- Plant devices and equipment
- Operating procedures
- Process measurements
- Graphical displays
Component object-based development facilitates a cookie-cutter approach in which small software programs can be developed as objects/code modules, stamped out, and joined together to form an application. Some automation vendors have this capability today. Where a component object-based SCADA system is different is, after the cookies are stamped out, you can change the stamp, and all of the cookies you already made are automatically changed.
The first row of the “Replication of Objects and Change Propagation” image shows the replication of an object representing a diaphragm valve. Replication is the process during which components are created from object templates. The next row illustrates a change (manual to powered) being propagated throughout all the valves. Change propagation is accomplished by changing the Object Template, which can cause any or all of the associated components to change.
Replication and change propagation are possible because, when a SCADA package is truly component object-based, it operates within a parent-child relationship. The “parent” object templates are developed first. Then components are replicated or instantiated from the parent objects. These “children” are tied back to the parent, so a change in the parent can be replicated to all of the children. This is an extremely powerful development capability in that:
- Application creation is optimized by using object templates to automatically generate components (replication).
- Project changes are easily accommodated by making changes in the object template and having the components inherit the changes via change propagation.
- Ongoing system changes and expansions are easier and more cost effective because of automated replication and change propagation.
Develop once, reuse many times
The object-oriented approach to development enables simple drag-and-drop, click-to-select, or fill-in-the-text-box techniques. In most cases, this approach is easier than modifying scripts line-by-line. In addition, the number of syntax and run-time errors is minimized because the integrated development environment enforces system-specific rules. Users can develop objects once and then reuse them many times in the current application as well as future projects.
The term “object-oriented graphics” has been used in the SCADA environment since the early 1990s. Today, this term usually refers to the ability to build graphics and draw pictures based on classes or a hierarchy. Object-oriented graphics enable users to build a symbol and replicate it across a screen or HMI application. They can then edit the symbol and easily distribute the changes to all the similar symbols at the same time.
While this is useful functionality, SCADA applications require more than graphics. Much of the development work that goes into designing supervisory applications is spent on creating items or functionality such as:
- Alarm monitoring
- Animation scripts
- Security scripts
- Supervisory scripts
- Historical data storage
- Integration with other applications and SQL databases
- Event detection
- Flow and movement calculations
- Device integration
In order to fully realize the benefits of a component object-based architecture, a SCADA system today needs to depict all of these things, along with the graphics as objects.
The life-cycle savings associated with any SCADA development tool can be categorized into four basic areas, as seen in the chart on the right:
A simple example illustrates savings realized by developing SCADA systems using component object-based technology. Take a plant supervisory application that has, among other things, 27 double seat valves, each having six I/O points of interest that will be monitored.
In a traditional SCADA system, 162 tags (27 valves × six I/O per valve) would be created. In component object-based SCADA systems, a common valve object template is created, and components that represent each individual valve are instantiated or replicated from that object template. Now say it takes 0.4 hours per tag to develop the application using a traditional, tag-based SCADA system. This is not including graphics or PLC control logic development. Also estimate it takes two hours to develop a valve object template and an additional 20% more (or 0.4 hours) per component instance to customize each individual valve in the application.
Remember an object template encapsulates scripting, security, alarming, events, history configuration, and device communications. In a tag-based system, all of this needs to be programmed using additional memory tags.
Now suppose a customer requests a change that affects 10% of the application. Using tag-based SCADA software, it is reasonable to assume 10% of the effort spent on the original development would be applied to make the change. Alternatively, using component object-based SCADA software, because of the parent-child relationship between objects and components, the 10% change effort only needs to be applied to the object template.
Component object-based SCADA and Supervisory System software can save a great deal of time and improve quality. There are also life-cycle savings since systems require changes over time with additions and enhancements. If a line or process expansion is needed, existing configuration and development work can be easily replicated and modified to fit the new need. All changes to the existing configuration are tracked and logged.
ABOUT THE AUTHOR
Steve Garbrecht is vice president, Product, Solutions and Services Marketing for Invensys Operations Management. He has more than 20 years of experience in the industrial control and information management industry.