UA provides basic infrastructure needed to create a client-server-based system, explains Harding, chief software architect of vendor ABB Process Automation Inc. (www.abb.com), Houston. Stressing that OPC-UA describes base services as well as a base object model, he says, “those services are defined for establishing secure connections with servers, reading, writing, eventing and calling methods, to name a few.” The services facilitate OPC-UA’s connectivity that spans vendors, legacy systems and the enterprise. “Using a set of services this small avoids the typical explosion of interfaces and methods found in other connectivity solutions,” Harding remarks. That’s good, because “this explosion results in highly complex systems that are difficult to understand and maintain.” End-users can thwart explosions with UA, because each time a new data source is introduced, no new service is required, he continues. “The same services are applied to new data sources by using the discovery capabilities of OPC-UA.” The object model presented to OPC-UA clients represents the other principal feature of UA’s overall functionality that allows communications between different technologies. Defined browse-and-query services “enable a client to ‘discover’ the server’s address space and object model,” Harding explains. Other standards build on that model, “exposing whatever information those standards have defined,” he says. Even unique operations defined by other standards but not covered by standard OPC-UA servers can be mapped to an OPC method, Harding adds. eXtensible markup language (XML)-based UA supports Web services transport and encoding. That’s because, Harding says, “the computing industry has embraced Web services as the standard interoperability technology.” So how does OPC-UA help? With Web services, “you have to discover the [programming] methods across the Web service and program against them,” Harding explains. With UA, though, programming is defined upfront, he says, so “integration with it is more configuration than a programming exercise.” This all means that OPC-UA’s platform- and communication-technology independence enables connections from the plant-floor embedded world to the enterprise world. “The embedded level demands high performance and small size, which OPC-UA provides through use of its binary protocol and ANSI [AmericanNational Standards Institute] C-based communication stack,” Harding states. And through OPC-UA’s native Microsoft .Net-based implementations, movement upward from plant Microsoft Windows-based systems occurs, he says. Finally, at the enterprise level, where Harding says Linux and Java are popular, “the Java implementation of OPC-UA is available.” UA ensures interoperability of all three of these implementation technologies and offers it in the preferred development languages of each platform, he adds. A good fitCurrently, OPC Foundation is working with or investigating several data-communication protocols or standards. Those or their groups include ECT (EDDL Cooperation Team)/EDDL (electronic device description language), FDI (future device integration), MIMOSA (Machinery Information Management Open Systems Alliance), GridWise, BACnet (Building and Automation Controls Networks), ISA S88 (Instrumentation, Systems and Automation Society’s Batch Control), ISA S95 (ISA’s Enterprise/Control Integration) and OMAC (Open Modular Architecture Control). C. Kenna Amos, [email protected], is an Automation World Contributing Editor.
Leaders relevant to this article: