Object Architectures in an Increasingly Services-Oriented World

According to Neil Peterson, Delta V Product Manager for Wireless and Enterprise Integration at Emerson, “Distributed object technology has been the mainstay of process systems integration since the first release of OPC DA. Customers benefited from applications created by different vendors that were easy to integrate using a standard interface, rather than requiring custom programming. The caveat was that it required all integrated applications to be on the same operating system platform. This was OK, since most process systems had standardized on Microsoft Windows as the application platform. However, business systems are deployed across non-Windows platforms, and that has limited the integration of the process and business systems.”

According to Marc Leroux, collaborative production management marketing manager at ABB, “ABB has been delivering object technology and its benefits to our customers for many years; we introduced our flagship object-based System 800xA Extended Automation system in 2004, and before that we delivered these benefits with earlier versions of Industrial IT beginning in 2000. One of the basic concepts of the system is that it is possible to create a base object that is a representation of a real-world object; a pump or a valve for example. The base pump object, for example, already has all of the characteristics of a pump modeled in it. Specific types of pumps can be subclassed from the base pump, inheriting all of its characteristics. Once a specific device is modeled, instances of it can be implemented, exactly as they would be in the real world,” said Leroux.

“Any extension to the object, an ‘aspect’ in ABB terminology, which is added to the object, can be immediately made available throughout the system. For example, a maintenance manual for a specific type of pump is attached to the pump object; it is then available to all instances of the pump. Another example would be adding a new piece of software that could monitor and report on certain operational conditions inside of an object, monitoring levels or temperatures inside of a vessel, for example. This can be attached to the object at any point, and it immediately becomes available. Of course, these examples are relatively simple. The true benefit is in implementing a complex piece of code, monitoring the overall health of a heat exchanger or a reactor, for example. In an ABB environment, these can be added at any point after the system is implemented, and they become available for reuse.

SOA allows decomposition of applications into services. Source: Chevron Refining

“Another concept in the ABB architecture is that specific data elements, the current flow through a pump, for example, are maintained in one spot and referenced. This eliminates the need to replicate information in multiple spots and ensures the integrity of the information. In real-world terms, this approach greatly reduces engineering costs. By being able to subclass an object, the engineering effort is limited to what is specific to a particular type of object. The behaviors are well-known, reducing validation requirements, but the real benefit comes with making changes to an object. If a decision is made to make a system-wide change, the maximum run time for a specific type of motor that is common throughout the facility, for example, the change can be made in one spot, and all instances of that motor would be automatically updated to reflect this,” said Leroux.

Services-Oriented Architectures Provide Foundation for Cross-Platform Communications.

Certainly, distributed object technology represented a big leap forward for the industry. However, neither DCOM nor CORBA functions well in a cross-platform environment or through network firewalls. To overcome these types of cross-platform interoperability issues, the IT world began to develop 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-based solutions to map to actual work processes more closely.

The idea with services is that if you can 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,” commented Chevron’s Brooks. “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 de-coupled with a service.”

According to Hardin, “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.”

SOA maturity model. Source: Chevron Refining