This article was printed in CONTROL's June 2009 edition.
By Paul Miller
Perhaps because distributed software objects play well in a common network and technology environment, their growing role in process automation seems to follow a logical evolution.
In the beginning, there were simple data tags, such as pressure, level, flow or temperature process variables. With tag data, dedicated connections need to be created to get the data from the source, typically a PLC or process controller, to the consumer, typically an HMI, alarming, trending or historian application. Then, as object-oriented programming (OOP) developed, tags evolved into objects. Objects feature multiple attributes, including both behavior and state, in addition to the process variable data. By definition, objects also display inheritance characteristics that allow users to replicate and modify them for re-use. Standards such as Microsoft’s Distributed Component Object Model (DCOM) enabled connections between different objects in the same computer or computing platform.
Now, templates, services and the architectures they fit into are emerging and taking on and extending some of the capabilities first explored by OOP.
Templates Simplify Engineering for Power
“The concept of templates helped me out quite a bit,” says Hal Allen, SCADA analyst at Santee Cooper Power (www.santeecooper.com) in Monks Corner, S.C. Allen recently implemented an InFusion SCADA system from Invensys Process Systems (www.ips.invensys.com) to monitor and manage 56 electrical substations for the state-owned utility (Figure 1). “When you get an InFusion system, you have many devices created from pre-defined analog and digital objects provided with the system. A template can be derived from another template, or an object can be derived from a template, and then you can go back and make wholesale changes to everything that has been derived from that.
“In the initial phase of the project, I created my devices from the generic discrete and analog device templates, so that now I have a hierarchical view of how the devices, breakers for example, work in the field. Once you have all these devices built as a template, then you can easily create your real-world objects. If you’ve created a couple of hundred devices and then realize you left something out or need to change something, then you can go back and make a change in one place and have all the hundreds of objects created from that template updated automatically.
“A good example of a device that I created from the analog device object is a transformer, which is an integral part of a substation. We have transformers at different voltage levels, and some are older than others, but they all have some common attributes. My philosophy was to create a base transformer object template having common transformer attributes, such as a fan or a megawatt value. Then I just modify the template as needed to represent the actual transformer.”
SOAs Enable Cross-Platform Communication
Distributed object technology simplifies data access in a network, so it’s used in many advanced industrial automation systems. It’s based on vendor-developed standards, such as DCOM and the Object Management Group’s Common Object Request Broker Architecture (CORBA) standard for UNIX platforms. The OPC Foundation’s (www.opcfoundation.org) Data Access (DA) is one popular example. OPC DA servers and clients, based on Microsoft software, provide data connectivity between different vendors’ intelligent devices, such as PLCs, and software applications, such as HMIs, alarm packages, trending packages, historians, etc.
Distributed object technology represented a big leap forward for the industry, but neither DCOM nor CORBA functions well in a cross-platform environment or through network firewalls. To overcome such cross-platform interoperability issues, the IT world developed the concept of standard “services,” including web services. These services are now making their way into the industrial world where they are helping to break down artificial functional barriers to enable software to map to actual work processes more closely.
“The idea with services is that if you define a service that represents an interface between two systems, then the manifestation of the plant itself and the interface are independent of each other,” says Mike Brooks, staff technologist in global manufacturing at Chevron Refining (www.chevron.com) in San Ramon, Calif. “There probably will still be objects within the scheme, but instead of communicating from within DCOM or CORBA, where the objects are instantiated from the hub, now they’re decoupled with a service.”
Dave Hardin, a system architect at Invensys, explains that, “Services define the interface and communication mechanisms between objects and other software components. These interfaces and mechanisms become the communication contract to which each system must adhere. Some services, web services for example, support widely used protocols, platforms and systems. Other services support specific communication functionality, such as fast data transfer, strong security, failure resilience or event messaging. The contract forms the basis for interoperability and helps decouple the functions performed by the service from the technology used to implement the service.