Component object-based supervisory systems — the benefits over traditional HMI development

There are several fundamental differences between component object-based and traditional tag-based human machine interface (HMI) and supervisory control and data acquisition (SCADA) products. This article explains the differences between the two methodologies and shows that significant savings in development can be achieved with a component object-based SCADA product, and explains how to calculate the savings.

Component-based software architectures have been around for many years in the commercial computing world. Object-oriented development has also been in use for some time. Both are only now starting to make their way into the process control and SCADA software community.

Tag-based supervisory systems

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. While simple and very portable from one project to another, a tag-based environment has the downfall of a flat namespace, with no inherent ability to link elements together 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. Re-use in a tag-based system is commonly instituted through dynamic or client-server referencing, which allows a common graphic to be created, and then a script is executed to switch the tags being viewed in run-time. Furthermore, because of the flat structure of the application, changes need to be sought out and analysed as to the effect on the rest of the application.

Object-oriented systems

Component-based and object-oriented development in the information technology (IT) world originally referred to tools which focused on releasing the developer from mundane, repetitive program tasks, while at the same time maximising re-use through the development of common components.

As you would expect, these tools are not an exact fit for the industrial environment. For one thing, systems integrators and production engineers are typically not computer programmers. Furthermore, there are some key architectural differences between IT and production automation applications. For example, general information technology applications typically involve database access from non-deterministic, forms-based interfaces that accomplish things like online banking, business reporting, financial accounting or static information look-up. Conversely, plant intelligence, production management or supervisory control applications involve the accessing of real-time data in PLCs, performing sophisticated calculations to determine flows and production numbers, displaying this real-time data in graphics-intensive client environments or analysis tools, and writing to and reading from production- and operational-related databases. The two environments are different enough to dictate that component object-based tools be purposely built for one setting or the other. There are tools in the market that facilitate component object-based architecture and are designed to help industrial customers with the development and maintenance of larger, more complex supervisory systems. Table 1 compares component object-based versus tag-based architecture.

	Component object based		Tag based
	Development	Runtime	Development	Runtime
Application structure	Hierarchical: Creation of components using object oriented workflow methodology	Hierarchical: Components representing physical devices, running coordinated in different locations when required	Hierarchical: Creation of graphical content sometimes using object orientation	Flat: Monolithic instances of software, running on one to many machines as separate applications’
Graphics development	Done last		Done first
Scripting	Developed in object templates as part of a component		Developed separately, linked to a graphical representation
Promotion of standards	Strictly enforced		Not strictly enforced
Global application changes	Propagated from object templates	Ability to distribute and exchange/enhance components as required	Based on graphics or changed in tools like Excel	Requires re-compile of application
Data representation	Logical constructs such as a physical device (ie, valve, pump) or logical device (ie, PID loop or calculation) as objects and components		Graphical devices as objects, tags

Table 1: Component object-based versus tag-based architectures

 

Benefits for manufacturing applications

In component object-based SCADA, application objects contain the 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 (KPIs), condition monitoring events, enterprise resource planning (ERP) data transfer operations and many other tasks that you want the plant information system to do. 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 organisation 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. These include common types of:

• plant devices and equipment
• operating procedures
• process measurements
• calculations
• graphics displays.

This allows a cookie-cutter approach, where typically small software programs are developed as objects or code modules that can be stamped out and joined together to form an application. Most automation vendors have this capability today. Where a component object based SCADA system is different is that after the cookies are stamped out you can change the stamp, and all of the cookies you already made are automatically changed (see Figure 1).

Figure 1: Replication and change propagation in component object-based architectures

This functionality is possible because when a SCADA package is truly component object based, it operates as a parent–child relationship, in which parent object templates are developed and then components are replicated or instantiated from the parent objects. Now all of the 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 for the following reasons:

• Application creation is optimised 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.

Object-oriented graphics with SCADA

The phrase ‘object-oriented’ graphics has been used with SCADA since the early 1990s. It is generally used today to refer to the ability to build graphics and draw pictures based on classes or a hierarchy. Object-oriented graphics allow you to build a symbol and replicate it across a screen or HMI application, and then have visual changes made to all the similar symbols at the same time. While this is useful functionality, SCADA applications require more than graphics. For example, much of the work that goes into a supervisory application is for things like:

• 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 realise the benefit of a component object-based architecture, a SCADA system today needs to depict all of these things, along with the graphics as objects.

Development: object-based versus tag-based architecture

As with many new approaches to system development, using a component object-based SCADA package is different when compared to tag-based SCADA applications.

Tag-based systems

From the inception of PC-based HMI and SCADA software, users have built operator graphics and linked them to tags, which represented addresses in a PLC or a control system. The concentration was on the computer and the software application. The steps below are an example of how a traditional tag-based SCADA application is developed.

1. HMI application is created on a single computer.
2. Windows or displays are created for the application.
3. Graphics are created for the windows.
4. Tag definitions are imported from the PLC or manually configured.
5. Alarm and event detection scripts are defined for each tag.
6. Tags are linked to graphic elements.
7. Graphics animation scripts or links are created.
8. Input/output (I/O) tags are defined and linked to the application.
9. If the application is to be deployed in a client-server environment, the application is re-architected to centralise alarming, event detection, history archiving, graphics and I/O servers.

Changes to the system require shutting down the application, making changes to the many scripts and tag database references to enable the new functionality, and reloading the new HMI application on each workstation.

Object-based architecture

New software applications and architectures that incorporate integrated development environments have brought a new era to SCADA software development through the ability to create a complete plant device model. The developer is removed from the complexities of the computing environment and allowed to concentrate on ‘modelling’ how the production facility is laid out and the different manufacturing cells and processes that comprise plant-wide supervisory control. Once the plant model is captured, it is easy to implement supervisory control functions. A small investment in creating object templates yields big results in engineering productivity.

Life cycle savings

The life cycle savings associated with any SCADA development tool can be categorised into four basic areas:

• Initial development savings related to application generation: This represents the savings that result from the time saved when users develop applications by defining object templates once, and then generating components from those templates multiple times.
• Initial development savings related to application changes: This represents the development savings gained through the ability to propagate changes from object templates to all the components derived from those templates. When multiple application changes are requested during development, the savings can really add up.
• Maintenance savings throughout the system life cycle: Using a distributed system significantly reduces maintenance costs through the ability to remotely monitor, change and deploy software to all nodes in the network. This is especially important for geographically distributed networks because users can save both time and money by eliminating the need to travel to each site for maintenance or upgrades.
• Savings across all sites: These savings result from re-using the templates and applications created for this project on other projects. Companies use this to drive standards in their projects, which is particularly beneficial for systems integrators, OEM machine builders and facility operators.

What to look for when selecting a SCADA system

Component object-based development provides a number of advantages in development and maintenance of the application, but what about the computing architecture that hosts the SCADA system? The technical aspects of the system must also be considered:

• Does the development tool provide a realistic model of plant equipment and manufacturing, areas, processes or production lines?
• Can it easily be integrated with network security and allow centralised security configuration?
• Does it provide flexible device connectivity and the ability to interface to all the devices in the plant?
• Does it provide centralised diagnostic utilities?
• Can the application scale from a single node to many nodes without having to re-architect the application?
• Can HMI applications be remotely deployed to computers across the network?
• Does it provide a unified namespace which allows tag browsing across the entire supervisory network, both in run-time and in offline development?
• Can computing loads be distributed across multiple computers if needed?
• Does the system provide cost-effective redundancy using commercial off-the-shelf hardware?
• Is the alarm subsystem distributed?
• Is historical archiving defined during HMI development or is a separate tool required?

All of these are things that a SCADA package should and can do through the use of innovative software solutions available on the market today.

Wonderware Australia
www.wonderware.com.au