Object Architectures in an Increasingly Services-Oriented World

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

1 of 6 < 1 | 2 | 3 | 4 | 5 | 6 View on one page

By Paul Miller, Contributing Editor

Distributed objects work well within a common technology and network environment.

In the beginning, we had 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).

As the concepts of object-oriented programming developed over time, tags evolved into objects (See sidebars at the end of this article). 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 user to replicate and modify them for re-use. Standards such as Microsoft's COM (Component Object Model) enabled connections between different objects within the same computer or computing platform.

According to Mike Brooks, Staff Technologist in Global Manufacturing at Chevron Refining in San Ramone, Calif., “Object technology in automation has been around for quite awhile. We developed some earlier object technologies back in the mid 1990s while I was at Object Automation and later at IndX, a company that I founded that subsequently was acquired by Siemens. IndX was built on a distributed object framework. This was pretty innovative object technology at the time built on an information model based on objects and classes of objects. We had objects that represented physical objects and we had class-based views against those objects. For example, if we had a compressor object, we could put six different views on the object so the planner or operator or maintenance guy could see the object.”


Delta V system in Petrobras control room
Delta V system in Petrobras control room.
Photo courtesy of Emerson

“While objects are fine,” said Brooks, “once you get the object structure built, and especially if you’re going across computers, with objects, you end up with a very fragile infrastructure that binds the work processes within the IT underpinnings. If you connect one database to another, it’s bound, and if you want to change it you have to get a whole bunch of IT guys to pull this part and rearrange it to put it all back together. COM and CORBA were technologies for distributed objects. These are now being supplanted by services-based technologies and for good reasons.”

According to Dave Hardin, a system architect at Invensys, “Object-oriented (OO) technology and architectures have been around in software world for quite some time. The concepts were becoming well-established in the software industry by the early 90s, and most modern software development embraces OO technology and related modeling languages such as UML (Unified Modeling Language) to describe the structure and behavior of systems. Over time, object concepts have emerged from the internals of application software and become more visible to end users. Some of the names are changing, but the core concepts remain alive and well. Users may not relate to ‘geeky’ software terms, such as ‘subclassing’ and ‘inheritance,’ but they do understand the concept of templates, deriving templates from base templates, and the concept of object instantiation and deployment. (See the sidebar, "Object Templates Simplify Engineering at Santee Cooper Power" at the end of this article) The object paradigm is natural and easy to understand. This speaks well of the ability for OO technology to describe real-world systems in a meaningful way.”

While a big improvement over simple tags, Microsoft’s COM bound the objects to the underlying IT infrastructure, making them both protocol- and platform-dependent and requiring the creation of well-defined and often inflexible object architectures.

According to Hardin, “The success of software object technology lead to the belief that objects should not be constrained by a hardware platform, but instead should be available transparently throughout a network. Why be limited by artificial barriers? This led to the development and widespread use of distributed object technologies.”


ABB IndustrialIT
ABB IndustrialIT makes extensive use of distributed object technology.
Photo courtesy of ABB

Distributed object technology, based on vendor-developed standards, such as Microsoft's distributed flavor of COM known as DCOM (Distributed Component Object Model) and the Object Management Group's CORBA (Common Object Request Broker Architecture) standard for UNIX platforms, is used in many of today’s advanced industrial automation systems. Distributed object technology simplifies data access within a network. OPC Data Access (DA) is one popular example. Microsoft-based OPC DA servers and clients are used throughout the industry to provide data connectivity between different vendors’ intelligent devices (such as PLCs) and software applications (HMIs, alarm packages, trending packages, historians, etc).

“OPC DA tags as objects probably represent the biggest footprint of DCOM distributed-type architectures in this market space today,” said Stephen Briant, FactoryTalk Services marketing manager at Rockwell Automation in Pittsburgh, Pa.

1 of 6 < 1 | 2 | 3 | 4 | 5 | 6 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.


No one has commented on this page yet.

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