OPC UA: helping devices to communicate with each other
Kevin Canham and Olaf Wilmsmeier of Harting look at the role of OPC UA in RFID system integration.
Communication among sensors, embedded devices and backend systems is a crucial element for implementing 'integrated industry' applications. With the advent of UHF RFID and other AutoID technologies for implementing the integrated industry philosophy, it is vital to ensure that the communicating parties can flexibly exchange the relevant information directly with one another and to integrate these technologies into the overall solutions as easily as possible.
This integration has been greatly eased by the advent of OPC - an abbreviation for OLE (object linking and embedding) for process control - and its associated unified architecture (OPC UA). The OPC Foundation approved the first draft of OPC UA in 2006, and in 2009 IEC standard 62541 represented the introduction of the OPC UA communication protocol as the new de facto standard for the automation sector. OPC UA is supported by all the leading automation manufacturers, and is independent of the platform and programming language used. It also offers greater security, with integrated 128- or 256-bit encryption, authentication and authorisation as well as data integrity based on signatures.
OPC UA is scalable from cloud-based servers all the way down to chip implementation. The same protocol allows RFID systems with a few data points to be networked in just the same way as control systems with more than 100,000 data points.
OPC UA follows a service-oriented architecture which allows services between IT systems to be structured and utilised. As usual, the communication protocol consists of a number of layers. The abstract description of services forms the functional basis. These services are called up by a protocol with the help of the transport layer. The protocol serialises or de-serialises the data of the network users, such as embedded devices, backend systems, visualisation systems and RFID readers, and sends the data over the network. This allows a very wide range of network users to exchange data with one another, independently of the operating system.
The ability for the individual communicating parties to act as both server and client is crucial for setting up sustainable communication structures. The fact that users can both request and provide data forms the basis for autarkic bidirectional communication among subsystems in the future. This includes both calling up functions and changing configuration parameters as well as event-controlled communication. For this purpose, the communicating parties can subscribe to events among themselves and consequently stipulate the events - the detection of a new RFID transponder, for example - for which they want to receive notification. Thanks to OPC UA's object-oriented approach, it is particularly easy for the individual devices' manufacturer-specific characteristics to be to be preserved without violating the standard.
OPC UA defines how to communicate, not what to communicate, and is therefore entirely application and device-neutral. The functions and variables that a device makes available are determined at run time if they are not known beforehand. A communicating party's complete data model can be retrieved. In this case, the data types (metadata) that are used are identified along with the functions and variables. It is therefore very easy to integrate unknown communicating parties into the infrastructure.
To further simplify such integration, the data models of device groups or applications typically found in the field can be pre-defined in so-called 'companion specifications'. These specifications contain the fundamental functional range including the data type description for the individual variables and the passed parameters.
The advantage of such a companion specification is obvious. As more manufacturers follow this recommendation and correspondingly implement their communication interfaces, the integration of different devices from different manufacturers into new applications will become faster. This saves time and increases the protection of the customers' investment.
In addition, these specifications can be individually expanded for specific devices or manufacturers thanks to OPC UA's object-oriented approach. Manufacturers can consequently keep their unique features while still making use of a widely accepted common communication basis. Because OPC UA provides possibilities to retrieve these unique functions from other communicating parties at runtime, its use is very simple.
Harting recognised the potential of OPC UA at an early stage with the development of a high-performance UHF RFID reader with an integrated OPC UA server, and is now using OPC UA to communicate in a very wide range of applications. The company is engaged in many aspects of Integrated Industry aspects, and is currently expanding its product range in the embedded devices area. It was also actively involved with the decision of AIM Deutschland (Association for Automatic Identification and Mobility) to work with the OPC Foundation to define a companion specification for AutoID devices.
This companion specification takes the different AutoID technologies back to a common communication interface or shared data model. Thanks to the flexibility of OPC UA, the differences between these technologies become irrelevant. For example, all AutoID technologies include a scan method that identifies new barcodes or RFID transponders. How this data is interpreted may vary depending on the technology, but it is still possible to describe this interpretation universally as far as the interface is concerned.
What this means for the integrator or customer is that the process of incorporating different AutoID devices, manufacturers and technologies into an overall infrastructure can now be significantly faster. At the same time, other important aspects of OPC UA, such as the increased security and the possibility to combine server and client functionality in one device, are also integrated.
This means that in the future, a change in the device hardware can be accomplished with much greater ease. This is particularly interesting for system integrators who want to use the best device on the market for this situation. There is no need for time-consuming familiarisation with another device-specific interface, and existing programs or interfaces to back-end systems can be reused. It is possible to use a standardised technique to interact with AutoID devices all the way from the PLC connection to the SAP interface.
Other News from Harting
Latest news about RFID & Wireless technology