Interested in linking to "OPC UA Up and Running"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
It’s been just over a year since the release of the OPC Unified Architecture (UA) specifications and users are now asking “So what exactly is it, and when can I get it?” Bringing a specification like OPC UA to completion is more akin to running a marathon then the 100m dash. After the crack of the pistol and the cheers at that start, there is a lot of hard work and dedication that is needed before enjoying the victorious finale.
What is OPC UA and what sets it apart from the existing OPC specifications? The primary purpose of the original OPC specification was to solve the integration problem between devices and PC based client applications. The automation industry’s desire for connectivity standardization has led to OPC being used in a wider range of applications than was originally considered. The scope now extends to enterprise level interoperability, which includes applications from the field level all the way to realm of Enterprise Report Planning software, across multiple hardware platforms, and in geographically diverse installations. As technology and market requirements change so must the interoperability standards, therefore OPC UA extends the scope of the classic OPC specifications and represents a transition from device connectivity to data connectivity. The single OPC UA architecture encompasses and unifies the functional data format for real-time, historical, event based and batch information, as well as allows for rich information model integration and vendor specific extensions.
The OPC UA specifications are implemented on a service base architecture, which leverages existing standards such as XML, SOAP and the WS initiatives. Services based implementations are supported by Microsoft as well as other operating systems. This means OPC UA targets more platforms, including embedded systems. This promotes the power of standard based connectivity across more layers of the enterprise. The OPC UA specifications also go farther in setting standards for application security, reliability, audit tracking and information management. These are key components in interoperable enterprise architecture.
Runners don’t begin a marathon without extensive training, and releasing a specification that addresses enterprise connectivity takes upfront preparation as well. Work began on developing the concepts, scope and specifications for OPC UA in early 2004. Since that time, the OPC UA working group created and refined draft versions, implemented proof-of-concept demonstrations, forged collaborations with other standards bodies and began the groundwork for implementation and certification stages. Throughout this entire process, vendors and end users provided valuable input and feedback on the emerging specifications. The results of this early work are now being realized.
Regardless of how much time is spent warming up; you can’t win the race until you actually start running. For any specification to be truly robust and validated, it needs to be implemented and tested. In order to be properly implemented, it must be deployed in a feature complete, stable format in a variety of test scenarios. For OPC UA, race day was the release of the key Core specification parts. Just like coming out of the blocks, the specification release is the beginning of the real work. Anyone can start a marathon, but it takes dedication, continued effort and steady progress in order to reap the rewards of the finish line.
Experience with specification development has taught the OPC Foundation how to avoid the common problem of trying to do too much, too quickly and having the specification ‘hit the wall’, lose critical momentum and fade away. The key to finishing a marathon is maintaining a steady pace. The key to a robust, functional specification is steady progress and completing set milestones. Over the past year that is exactly what the OPC UA working groups have been doing. The official release of the OPC UA specifications in June 2006 was the unveiling of the Release Candidate versions of the first five of twelve specification Parts to the general OPC community. Since that time, eight of the twelve parts have reached full release status. The OPC UA Specification Working Group is moving steadily towards having the final four Parts to Release status within the next few months. This involves incorporating feedback from the OPC community, early implementation efforts and testing.
Any software standard must be validated by actual code, so the OPC UA Early Adopter group began work well before the first specifications were released, and has been developing the industrial-grade software components necessary for successful OPC UA adoption. The existing OPC specifications make use of standard discovery and proxy components and so to does OPC UA. However a more encompassing specification means a more extensive suite of tools. The deliverables include core components for XML and binary services, security and discovery in C/C++, Java and Microsoft .NET versions. Also included are COM wrappers and proxies to allow for seamless migration and integration with existing OPC specifications. In addition, the Early Adopter group is developing feature complete OPC UA sample client and server applications in order to validate and test the specification documents. The Early Adopter group is made up of a significant number of committed vendor companies, and development progress has been steady.
The OPC Foundation has always strived to only create standards that users want and believes that any specification needs to be worth more than the paper it is written on.nTo that end, multiple activities have been going on to ensure support from the sideline spectators, namely end-users and other compatible standards bodies. The main forum for connecting with the end-users has been the OPC DevCon conferences that have been held yearly since the inception of OPC UA. The most recent event in June 2007 had attendees from all over the world and showcased current OPC UA developments.
In addition the OPC Foundation has been actively collaborating and partnering with industry standards bodies such as ISA, EDDL, FDT, MIMOSA, OAGi and others. The participation of members from OPC and collaboration organizations in respective standards development ensures OPC UA delivers a communications infrastructure that meets the needs of the industrial enterprise. The success of this program is clear from the recent announcement that the FDT Group would become a member of ECT (EDDL Cooperation Team) and work on defining a common OPC-UA Information Model for device descriptions. Two competing standards for device definition brought together by the OPC Unified Architecture.
Things are running well; so how far is the Finish Line? There is a lot of road behind us, and there is still some to go, but you could say OPC UA is now on the homestretch. The specification parts that define the core building blocks are complete, a solid feature rich OPC UA software development kit is available, and there are several OPC members currently developing OPC UA products. In addition the infrastructure needed for final compliance testing is well underway. There are still a few miles to go. In addition to releasing the outstanding specification parts, several key software development tasks and associated testing need to be completed. As with any significant software development effort, it takes time to fully develop, test, rework and ensure each component meets the expected quality requirements. Feature complete components are made available to OPC foundation members, but must be fully validated and production tested before they can be released to end users. This means that although some vendors from the Early Adopter group will soon provide pre-certification level OPC UA enabled products; there is still work to be done before OPC UA compliant products are commercially available. The parallel activities of; staged specification release, component and sample code development, and creating the certification infrastructure, as well as the collaboration and marketing efforts will ensure the lag time between ‘crossing the finish line’ and widespread product availability and adoption is minimized. The next generation of enterprise interoperability is not something that is achieved in a single burst of energy; rather it is steadily won one mile at a time.