This website uses cookies primarily for visitor analytics. Certain pages will ask you to fill in contact details to receive additional information. On these pages you have the option of having the site log your details for future visits. Indicating you want the site to remember your details will place a cookie on your device. To view our full cookie policy, please click here. You can also view it at any time by going to our Contact Us page.

Making a smooth transition from OPC Classic to OPC UA

27 August 2014

Many users of OPC Classic are starting to consider how and when they should begin the migration to the new OPC Unified Architecture (UA). Jason Fletcher, regional manager for MatrikonOPC EMEA, offers some advice.

OPC UA represents an expansion of the standards for data connectivity previously established by OPC Classic. But, what does this mean for businesses that are currently using OPC or plan to do so in the future and who want to ensure they protect existing investments in OPC Classic? 

Currently, there are only a limited number of OPC UA solutions on the market. The most important thing is to identifying solutions that support both OPC Classic and OPC UA. To that end, OPC UA wrappers offer only a partially suitable option for ensuring communication between OPC Classic and OPC UA clients. 

To answer questions about the feasibility of migrating to OPC UA, it is first necessary to make clear which improvements and special features OPC UA offers above and beyond OPC Classic. 

OPC Classic limitations
The most widespread specifications of the classical OPC standard include OPC DA for the transmission of real-time data, OPC HDA for the communication of run data (or historical data) as well as OPC A&E, with which alarms and events can be communicated. In order to guarantee interoperability today, a separate OPC server is needed for each device in the process industry. The use of multiple OPC servers to connect all devices and applications may, however, lead to the internal communication structures becoming unclear. 

These OPC variations are based on the binary communication protocols from the Microsoft - Component Object Model (COM) and Distributed Component Object Model (DCOM). All control systems, machine interfaces and automation applications that are based on the Windows platform can exchange data smoothly with OPC Classic. Programmers are able to quickly realise interface implementations thanks to these close connections with Microsoft's object-oriented COM and DCOM technologies, but these close connections come at the expense of the flexibility and expandability of interfaces. 

A partial solution
Units using OPC Classic cannot communicate with OPC UA on their own. So-called wrappers provide a partial solution for handling communication between existing classical OPC servers and OPC UA. These establish a connection from OPC Classic to OPC UA and vice-versa. The introduction of wrappers is, however, only recommended in a few complex environments as each OPC server must be individually configured for use with the wrapper. In addition, these solutions lack the security functions and recovery mechanisms available with OPC UA. 

Unified communication 
OPC UA, which is configured to allow for easier, safer, and more interoperable communications, is the most multi-faceted and promising specification for data exchange. It offers and expands the standard functionality of OPC Classic and, in doing so, resolves the difficulties associated with security, platform dependence, and DCOM problems. 

Because of its service-oriented architecture (SOA), OPC UA can easily implement all established specifications such as OPC DA, OPC HDA, and OPC A&E. This occurs independent of the Microsoft DCOM technology, which is replaced by an open, platform independent protocol complete with integrated security mechanisms. This provides a connection between the company management level with UNIX systems and embedded automation components with different Windows and non-Windows operating systems. 

With OPC UA, complex data structures and multi-layered processes can be fully specified. For example, a user working with OPC Classic requires three different OPC servers to record the current value of a temperature sensor, the historical average temperature, and the occurrence of a temperature overshoot. DA, AE, and HDA, each with different semantics. With OPC UA, these tasks can be completed using a single component.

The OPC UA security concept is based on Internet standards and includes the possibility of user authentication, signing of messages, and encryption of user data. With OPC UA, data access is also possible over the Internet and firewalls, because it contains a specially developed TCP-based OPC UA binary protocol for the exchange of data. In addition, any message can be forwarded via an HTTP or any other port. Furthermore, OPC UA, with configurable timeouts, automatic error detection and recovery mechanisms, is comprehensively equipped to prevent data losses and secure high-availability systems.

Migration paths
It is clear that switching to OPC UA is worthwhile. The new specifications offer standardisation of the classical OPC specifications, a standardised possibility for overcoming DCOM problems, and an increase in the security of OPC products. As such, and speaking in the long-term, it is safe to assume that OPC UA will one day replace OPC Classic. 

An immediate switch to OPC UA, however, is not necessarily required for every business. Three different migration options allow users to choose the most effective scenario for their purposes. 

Scenario 1 – complete migration: Complete migration refers to replacing OPC Classic via a comprehensive switch to OPC UA. To that end, the Universal Connectivity Server (UCS) from MatrikonOPC can be used, for example. This is an individual OPC server, which supports universal connectivity and makes contact with multiple units, protocols, and APIs. With this process, the user achieves secure connectivity with all established management systems and applications via an individual server. 

At this time, however, a complete migration is only possible for simple architectures in businesses, because the number of available OPC UA solutions on the market is still relatively small. OPC UA solutions that provide parallel support for both OPC Classic and OPC UA are therefore especially important. 

Scenario 2 – partial migration: OPC UA has been designed to remain adaptable for the future and to support current implementations. In the intermediate phase, it will still be possible to use DCOM based OPC products together with UA products. 
Users can, as such, still run a variety of products from their favourite manufacturers. This allows for a soft migration as a second scenario, whereby users retain OPC Classic and integrate OPC UA step-by-step according to their needs and capabilities. The standardised service interface, which UCS – for example – makes available, serves as a natural expansion that can be integrated into the OPC architectures. The Universal Connectivity Server enables multiple data exchange protocols to communicate with data sources simultaneously, in real time, and in a secure fashion. Because of the support offered for the plug-in approach from MatrikonOPC’s UCS, businesses can quickly expand their system to include protocols for new units and ensure the proper flow of information. It also reduces the amount of work involved in configuring and adapting new OPC servers. It doesn’t matter which data a company would like to access from the newly added device or system (OPC DA, OPC HDA, OPC A&E, OPC UA, or OPC .Net); because the UCS acts as a gateway and integrates all OPC standards.

Scenario 3 – preliminary migration: A third possible option is the introduction of solutions that only make use of classical OPC specifications at the moment, but come already equipped with OPC UA functions. This allows for early preparation to be undertaken for a future migration. One possible scenario, within which this option could be utilised, would be that a business currently only needs to be able to access real time data for a control process. In such a situation, an OPC server that supports OPC DA would be sufficient. However, the company can ensure the best possible long-term ROI by choosing an OPC UA compatible solution now. In doing so, it becomes possible to react to applicable requirements and to expand the system without too great an effort. The use of solutions, such as MatrikonOPC’s UCS, enables users to continue to use existing specifications while, at the same time, being able to support OPC UA. In this scenario, businesses are able to prepare for the future today with OPC UA. 

Contact Details and Archive...

Print this page | E-mail this page