By Jim Luth, OPC Foundation Technical DirectorTHE OPC Foundation has embarked on the creation of the Unified Architecture (OPC-UA), a completely new system design. Over time, OPC-UA will replace, modernize and enhance all the functionality of the existing OPC-defined interfaces. The following describes the technology and industry trends that led us down this path and explains how features of the new architecture will do more than just replace the existing technology.Microsofts Communication StrategyExisting OPC specifications are based on the Microsoft COM/DCOM model. When Microsoft released the .NET framework a few years ago, they made it clear that COM and DCOM technology were being relegated to legacy status. With the introduction of .NET, Microsoft presented the world with two new inter-process and remote communications technologies: Web Services and .NET Remoting. Although these new choices had advantages over COM, they also had some serious shortcomings.The most noticeable deficiency from an OPC perspective is performance. Despite this, OPC produced the XML-DA specification using Web Services. We did this knowing full well that it could never replace the COM based Data Access (DA) interface, because its performance was two to three orders of magnitude slower than COM.But, just like Microsoft provides multiple technologies to choose from, so does OPC. You can choose the COM or Web Services flavor of DA depending on your tradeoffs between speed and other attributes, such as cross-platform or Internet friendliness.Microsofts upcoming technology, code named Indigo, will combine all the best features of COM, MTS, Web Services, .NET Remoting and MSMQ into a single communications stack. Indigo sounds like the perfect Microsoft technology on which to base any future COM-replacement specifications, but another OPC goal is the move to platform independence. Ideally, OPC specifications should not be so tightly tied to proprietary Microsoft technology. Fortunately, Indigo is based on existing and in-the-works public Web Services specifications that ensure interoperability with non-Microsoft systems. Reworking Existing OPC Specs
The impetus to create the Unified Architecture came from an introspective look at the existing OPC Alarm & Events (A&E) interface and ways in which vendors using the interface would like to see it improved. Among Alarms & Events vendors, the number-one requested enhancement was: Better integration with DA.Here is an example of the integration problem. Alarms are typically defined as the excursion of a parameter beyond a specified threshold. OPC DA permits a client to browse to, read/write, and to subscribe to the temperature, but wont allow the client to alarm on it. The OPC A&E server is a separate server interface that allows the client to browse for alarms in an attempt to find one defined for the temperature. However, the client may not recognize that it is an alarm for the same temperature parameter that was read using OPC DA. This situation occurs because there is no requirement for the name of the temperature parameter to be the same in both servers. As a result, the user must have two separate client interfaces, browse two separate trees, and be able to reconcile naming differences between the two.The solution is to use the same browser, read, write and subscribe functions for both DA and A&E data, so that vendors are able to expose the alarms in a more natural way. UA will decouple the specific data structures that make HDA data different from A&E data for example, and allow the same generic method to operate on each.Forward and Backward Compatibility
Web Services is the only high-level application-to-application communications technology to be embraced by virtually all platform providers including Microsoft, IBM, Sun, and Linux. We believe that upcoming performance improvements will make this technology viable for OPC-UA. However, it is likely that at some point in the future Web Services will be dethroned by something bigger and better. To that end, the UA specification is written to be platform agnostic. Doing this greatly simplifies the task of migrating the OPC specification to other platforms when and if this becomes desirable.On the other hand, there are thousands of existing OPC Servers on the market that provide connectivity to field devices of all shapes and sizes. The OPC Foundation will provide generic wrappers to its members to OPC-UA-enable existing OPC Servers to accelerate the development of OPC-UA Clients.Working With Standards GroupsSeveral automation-related standards groups, such as ISA and MIMOSA, have produced information model specifications. ISA-S88, ISA-S95, and IEC TC 57-CIM are examples of such model specifications. With the popularity of XML and its capability to describe complex data and relationships using it, many of the model specifications have been extended to include standard XML Schemas. Although these model specifications are useful for unifying the nomenclature used to describe the entities, relationships and work flows associated with their respective domain, they provide no tangible interoperability from a software perspective. Even if a software application was to render data in XML using the prescribed Schemas, there is no standard to share or communicate these XML documents among applications.Having extensive, pragmatic experience producing practical industry standards for software interoperability, OPC is the logical organization to produce a specification that will allow the rich data described by these complex domain models to be exchanged among independently developed applications. Through joint working groups and a cross-pollination of members in other technical working groups, OPC is collaborating with other standards organizations to ensure OPC-UA is developed appropriately to meet this goal.
Jim LuthisOPC Foundation Technical Director and Chairman of the OPC-UA Working Group. He can be reached by e-mail at [email protected].
The impetus to create the Unified Architecture came from an introspective look at the existing OPC Alarm & Events (A&E) interface and ways in which vendors using the interface would like to see it improved. Among Alarms & Events vendors, the number-one requested enhancement was: Better integration with DA.Here is an example of the integration problem. Alarms are typically defined as the excursion of a parameter beyond a specified threshold. OPC DA permits a client to browse to, read/write, and to subscribe to the temperature, but wont allow the client to alarm on it. The OPC A&E server is a separate server interface that allows the client to browse for alarms in an attempt to find one defined for the temperature. However, the client may not recognize that it is an alarm for the same temperature parameter that was read using OPC DA. This situation occurs because there is no requirement for the name of the temperature parameter to be the same in both servers. As a result, the user must have two separate client interfaces, browse two separate trees, and be able to reconcile naming differences between the two.The solution is to use the same browser, read, write and subscribe functions for both DA and A&E data, so that vendors are able to expose the alarms in a more natural way. UA will decouple the specific data structures that make HDA data different from A&E data for example, and allow the same generic method to operate on each.Forward and Backward Compatibility
Web Services is the only high-level application-to-application communications technology to be embraced by virtually all platform providers including Microsoft, IBM, Sun, and Linux. We believe that upcoming performance improvements will make this technology viable for OPC-UA. However, it is likely that at some point in the future Web Services will be dethroned by something bigger and better. To that end, the UA specification is written to be platform agnostic. Doing this greatly simplifies the task of migrating the OPC specification to other platforms when and if this becomes desirable.On the other hand, there are thousands of existing OPC Servers on the market that provide connectivity to field devices of all shapes and sizes. The OPC Foundation will provide generic wrappers to its members to OPC-UA-enable existing OPC Servers to accelerate the development of OPC-UA Clients.Working With Standards GroupsSeveral automation-related standards groups, such as ISA and MIMOSA, have produced information model specifications. ISA-S88, ISA-S95, and IEC TC 57-CIM are examples of such model specifications. With the popularity of XML and its capability to describe complex data and relationships using it, many of the model specifications have been extended to include standard XML Schemas. Although these model specifications are useful for unifying the nomenclature used to describe the entities, relationships and work flows associated with their respective domain, they provide no tangible interoperability from a software perspective. Even if a software application was to render data in XML using the prescribed Schemas, there is no standard to share or communicate these XML documents among applications.Having extensive, pragmatic experience producing practical industry standards for software interoperability, OPC is the logical organization to produce a specification that will allow the rich data described by these complex domain models to be exchanged among independently developed applications. Through joint working groups and a cross-pollination of members in other technical working groups, OPC is collaborating with other standards organizations to ensure OPC-UA is developed appropriately to meet this goal.
Inside the Architecture
The OPC Unified Architecture will provide numerous features and advances over the existing OPC architecture: Complex data built-inThe existing Data Access Specification was enhanced recently with the release of the Complex Data Companion Specification. In UA, complex data will be the norm.Enhanced namespaceOPC-UA allows for unlimited node types and unlimited relationships. Furthermore, each node may participate in an unlimited number of relationships with other nodes. This flexibility ensures that there is no existing or future system that is too complicated to expose via UA. Rich base set of servicesThe base UA specification will define the necessary generic services to browse and query the namespace, read/write data and publish/subscribe events and data changes. UA-derived specificationsThe base UA specification will be purposely generic and not imply much semantics. The bulk of the functional areas addressed by the existing OPC specifications will be derived from the UA base specification. ScalabilityCompared with the existing OPC specifications, UA will scale to much larger enterprise-wide data modeling systems, as well as to much smaller embedded devices.Reliability and redundancyUA will build in the necessary diagnostics and features necessary for vendors to build high reliability systems. This includes hooks for redundancy.| About the Author |
