Serving Up Object Architectures

Standard Services Make IT Underpinnings Irrelevant, Allowing End Users to Focus on the Task at Hand

1 of 2 < 1 | 2 View on one page
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 ( in Monks Corner, S.C. Allen recently implemented an InFusion SCADA system from Invensys Process Systems ( 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 ( 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 ( 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.

1 of 2 < 1 | 2 View on one page
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • Paul Foxworthy a software developer and director of an IT consultancy from Melbourne defines "Bussiness Objects" in Wikipedia as "an entity within a multitiered software application that works in conjunction with the Data Access and Business Logic Layers to transport data." further the wikipage explains it's function as " Whereas a program may implement classes, which typically end in objects managing or executing behaviors, a business object usually does nothing itself but holds a set of instance variables or properties, also known as attributes, and associations with other business objects, weaving a map of objects representing the business relationships. A domain model where business objects do not have behaviour is called an anemic domain model. Business objects separate state from behavior because they are communicated across the tiers in a multi-tiered system, while the real work of the application is done in the business tier and does not move across the tiers." while for comprehension examples as "Chevron" or "Reliance" are bussiness objects where its attributes can be "Name or Call sign as registered in NSE or BSE respectively", "Fortune 500 Listed positions", "Age", "Area", "Country" and it could hold an 1-n association with its limited company (a collection of company instances). and thus can be coupled or de-coupled dynamically in contracts and form joint ventures in business spaces allowed by laws of the land and or logic of the business model which may be disruptive innovation and solves much of rigidity of limitation of creativity bound in limited material world but unlimited in virtual world. now about expanding unviverse or multiuniverse like WWW and handling this semantic world wide web,that may be possible by OWL objects. and remember there is no bottom line of this WORLD OBJECTS.


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