In the realm of industrial automation (OPC UA), seamless communication among devices is paramount for achieving efficient and synchronized operations. One of the pivotal technologies facilitating this communication is the OPC (OLE for Process Control) protocol. OPC serves as a standardized interface that enables diverse industrial automation systems to exchange data seamlessly, fostering interoperability among devices from different manufacturers.

As industries increasingly embrace automation for enhanced productivity and operational efficiency, OPC emerges as a crucial enabler, ensuring that disparate components within a system can communicate harmoniously. This introduction delves into the significance of OPC communication in the context of industrial automation, shedding light on its role in creating a cohesive and interconnected network of devices for optimal performance.

Table of Contents

What is OPC

OPC, short for Open Platform Communications (formerly known as OLE for Process Control), comprises a suite of software technologies designed to offer a unified interface for the control and data exchange of diverse devices. These specifications were formulated by the OPC Foundation, an international non-profit organization established in 1994 by prominent manufacturers in the field of industrial automation. The primary objective behind OPC's inception was to furnish engineers with a universal interface, enabling them to control a wide array of devices seamlessly.

Integrating OPC client support proved to be a game-changer for SCADA system developers, eliminating the necessity to manage numerous drivers for diverse devices. Meanwhile, equipment manufacturers, through the incorporation of an OPC server, acquired assurance that their products could be seamlessly utilized by users across a spectrum of SCADA systems.

OPC Technology Overview:

The prevailing standard, OPC DA, holds widespread adoption, yet it carries a notable limitation. Developed on contemporary Windows technologies such as OLE, ActiveX, COM/DCOM, its structure reflected the technology landscape at the time. However, as the industry evolved, embracing diverse operating systems and technologies, a need for platform independence arose.

Consequently, the OPC technology underwent a transformation, leading to the development of the OPC UA (Unified Architecture) standard, constructed on open, cross-platform technologies. This shift ensures adaptability across various operating systems and aligns with the evolving technological landscape.

However, OPC technology encompasses various standards, each delineating specific functions for particular purposes. The current standards include:

OPC DA (Data Access):

The predominant standard facilitating real-time data exchange with devices such as PLC, DCS, HMI, CNC, and others.

OPC HDA (Historical Data Access):

Providing access to previously stored data and historical information.

OPC AE (Alarms & Events):

Offering on-demand notification functions for diverse events, including emergency situations, operator actions, and informational messages.

OPC Batch:

Encompassing functions for step and recipe control within the technological process.

OPC DX (Data eXchange):

Facilitating data exchange between OPC servers over an Ethernet network. The primary aim is to create gateways for seamless data exchange among devices and programs from different manufacturers.

OPC Security:

Defining functions for organizing client access rights to OPC server data.

OPC XML-DA (XML-Data Access):

Providing a flexible, rule-driven format for data exchange using XML, SOAP, and HTTP.

OPC Complex Data:

An extension of OPC DA and XML-DA specifications, allowing servers to work with complex data types such as binary structures and XML documents.

OPC Commands:

A set of programming interfaces enabling OPC clients and servers to identify, send, and control commands executed in a controller or I/O module.

OPC UA (Unified Architecture):

The latest specification, distinguished by its departure from Microsoft COM technology, ensuring cross-platform compatibility.

Where OPC is Utilized

Typically, OPC technology serves the purpose of facilitating data exchange between controllers and a SCADA system. However, its application extends beyond this conventional use, allowing the organization of complex systems across multiple tiers within the process control system.

OPC consists of two integral components: the OPC client and the OPC server. The OPC server software actively communicates with diverse devices through dedicated device drivers via fieldbuses. On the other hand, the OPC client software is commonly integrated into the SCADA system, functioning to receive data from the OPC server. This dual-component structure enables seamless communication and data transfer between different elements of a comprehensive process control system.

In the context of a company's Automation and Control System (ACS), various hierarchical levels can be identified:

The lower level encompasses fieldbuses and individual controllers.
The middle level pertains to shop networks.
The APCS (Advanced Process Control System) level corresponds to the operation of SCADA-type systems.
The MICS (Management Information and Control System) level represents enterprise resource management applications, including ERP (Enterprise Resource Planning) and MES (Manufacturing Execution Systems).

Each of these distinct layers can be effectively served by an OPC server. The OPC server functions by providing data either to an OPC client situated at a higher layer or to an adjacent device within the same layer. This hierarchical structure ensures seamless communication and data transfer across the various levels of the Automation and Control System.

Working Principle of OPC DA

The OPC DA server facilitates the exchange of data (both writing and reading) between the client program, typically a SCADA system, and the end devices. In OPC, data is represented as a Tag variable with various properties. These variables can assume any type allowed in OLE, including various integer and real types, boolean, string, date, arrays, etc. Variable properties can be categorized as required, recommended, or custom.

Read More about Modbus

Required variable properties include:

The current value of the variable, its type, and access rights (read and/or write).
The quality of a variable, determined by parameters such as measured value exceeding the dynamic range, lack of data, communication errors, etc. Typically represented as good/bad/indefinite, along with additional information.
The timestamp indicates when the variable received the given value.
The frequency of polling by the OPC server, defining when the variable's value is updated.
Variable description, providing user information about the variable.

Optional properties may include:

Range of value change.
Unit of measurement.
Other custom parameters.

Various modes are employed to read data from the OPC server:

Synchronous mode: The client sends a request to the server and awaits a response.
Asynchronous mode: The client sends a request and proceeds to other tasks. The server notifies the client after processing the request.
Subscription mode: The server sends only changed tags to the client, with a "dead zone" concept introduced to filter out noise in data.
Data refresh mode: The client simultaneously reads all active tags, excluding those labeled as "passive" to reduce processor load.

The client retrieves data from the OPC server either directly from the end device or from a buffer. While reading from the buffer is faster, the data may be outdated. The OPC server updates data periodically by requesting information from end devices.

Data is written to the end device in synchronous or asynchronous modes without intermediate buffering. In synchronous mode, the client waits for confirmation, while asynchronous mode allows the client to perform other tasks, receiving a notification from the server after the completion of the write operation.

Working Principle of OPC UA

OPC UA (Unified Architecture) stands as a contemporary standard for data transmission within industrial networks. It ensures secure and reliable communication between devices, boasting hardware and platform independence that facilitates interaction among devices operating on different systems.

Key strengths of OPC UA include its object-oriented information model, enabling data to be visualized in a web browser-style interface, and a service-oriented architecture (SOA). Unlike the previous need for multiple OPC servers (OPC DA for real-time data, OPC HDA for historical data, and OPC AE for events), OPC UA consolidates these functionalities into a single comprehensive standard. Departing from the traditional tag tree, OPC UA introduces the concept of nodes or objects, each encompassing variables, methods, and other data structures of a real object.

Data exchange now occurs through binary structures and XML documents. In addition to the conventional client/server model, OPC UA introduces a publisher/subscriber model. The standard incorporates mechanisms for redundancy support, seamlessly transitioning to another client if one becomes unavailable, and swiftly restoring communication in case of failure. Data transfer is facilitated through the transport layer using TCP, HTTP/SOAP, or HTTPS. OPC UA replaces Windows access control mechanisms with digital certificates, providing the ability to encrypt transmitted data.

OPC UA ensures backward compatibility with OPC DA through a specialized wrapper and proxy module. Unlike OPC DA, which requires middleware for data transfer through routers and firewalls, OPC UA operates without this intermediary. The specification of OPC UA is detailed in several parts outlining the logic of operation for servers and clients, as defined in the IEC 62541 standard.

Example of OPC UA Server

An instance of an OPC UA server is exemplified by the MX-AOPC UA Suite developed by MOXA, comprising three distinct programs:

Server: Functioning as a program designed for acquiring data from Modbus devices.
Viewer: A program integrated within the Server, facilitating the visualization of tags and server status.
Logger: Tailored for logging the history of data changes, featuring seamless integration with databases and cloud solutions.

Primarily tailored for MOXA I/O modules with a focus on the Active Tag function, MX-AOPC UA Server also extends support to third-party devices utilizing Modbus RTU and Modbus TCP protocols. The Active Tag function enables the immediate update of channel states following their modification, eliminating the need for a command from the server.

MX-AOPC UA Logger offers the capability to transmit data to Microsoft Azure Cloud, as well as databases such as Microsoft SQL Server, MySQL, Oracle, Microsoft Office 2003 Access, or Excel via ODBC.

Ensuring data protection, MX-AOPC UA implements encryption through the Basic128Rsa15 key and confirmation with the X509 certificate. This robust suite of programs from MOXA exemplifies a comprehensive OPC UA solution with versatile functionalities for data acquisition, visualization, logging, and secure data transmission to various cloud and database platforms.

Challenges in Adopting OPC Technology

Embracing OPC technology offers significant advantages in streamlining communication protocols within automated processes. However, the transition from lower layer protocols, such as Modbus and Profibus, to OPC may present certain considerations.

Performance Considerations:

While the appeal of a unified OPC-based system is evident, converting industrial protocols to a PC format may introduce delays and consume additional computing power. Comparative tests indicate that direct integration of SCADA systems with industrial protocols can be twice as fast as routing through an intermediary OPC server. This becomes particularly crucial in scenarios requiring real-time monitoring.

Setup Complexity and Manual Input:

The implementation of an OPC server introduces complexities in configuration, and the manual input of numerous tags can be a time-consuming process. This drawback necessitates meticulous attention during the design phase of an automated process control system.

Licensing Costs:

Another consideration is the potential cost associated with OPC servers, as they are not always provided free of charge. In many instances, a separate license may need to be purchased for each PC, adding to the overall investment in the automation infrastructure.

Security Concerns in Cloud Transmission:

When the system transmits data over the Internet to the Cloud, the encryption scheme becomes a critical factor. Weak encryption can expose vulnerabilities, making the system susceptible to potential hacker attacks. This raises concerns about the overall security of the Industrial Control System (ICS).

In conclusion, while OPC technology offers a compelling solution for standardized communication, the decision to replace lower layer protocols should be weighed against performance considerations, setup complexities, licensing costs, and security implications, especially when transmitting data to external Cloud environments. A thorough evaluation is essential to strike the right balance between the advantages of OPC technology and the specific requirements of the automated process control system.

Advancements with OPC UA

OPC UA Technology Integration with TSN

Real-Time Operation:

OPC UA over TSN (Time-Sensitive Networking) is specifically engineered to support real-time operations. This integration harnesses the capabilities of OPC UA technology, employing a publisher/subscriber model in tandem with TSN.

Publisher/Subscriber Model vs. Client/Server Model:

While the traditional client/server model is effective in point-to-point connections, it encounters delays with numerous devices. The publisher/subscriber model, however, establishes a versatile one-to-many and many-to-many relationship. The server publishes data to the network, and each client can subscribe to receive this data.

Enhanced Quality of Service (QoS):

Ethernet with TSN complements existing Ethernet infrastructure by enhancing Quality of Service (QoS). This includes features such as bandwidth allocation, precise timing, low-latency assurance, and redundancy.

Streamlined Data Transmission:

TSN-enabled Ethernet facilitates the transmission of data in streams across various devices. Ethernet switches with TSN enable the allocation of dedicated bandwidth for each stream, ensuring real-time transmission. Multiple streams can be consolidated (network convergence) and transmitted simultaneously over the same network.

Tailored Standards for Different Devices:

As per OPC foundation, OPC UA will be segmented into four parts based on device performance and required capabilities:

Nano Embedded Device Server: Suitable for the smallest sensors.
Micro Embedded Device Server: Designed for cost-effective PLCs.
Embedded UA Server: Tailored for more powerful PLCs and border gateways.
Standard UA Server: A comprehensive implementation supporting all functions.

This strategic evolution positions OPC UA over TSN as a comprehensive solution, extending its application beyond traditional controller-to-SCADA communication to include sensors, IoT devices, and connectivity with local systems in the Cloud. The segmentation of OPC UA into distinct parts ensures adaptability to varying device capabilities and performance requirements.

Transformation from OPC DA to OPC UA

Undoubtedly, the OPC DA standard, while still in widespread use, no longer aligns with contemporary automation requirements. Rooted in legacy technology, it poses challenges in terms of configurability and falls short of meeting modern security standards. In response to these limitations, the industry has embraced the OPC UA standard—a modern alternative capable of data encryption and the establishment of unified data transmission systems extending from sensors to the Cloud.

The OPC UA standard not only addresses the deficiencies of its predecessor but also offers the potential for enhanced capabilities, especially when coupled with Time-Sensitive Networking (TSN) for real-time data transmission. While an immediate abandonment of OPC DA may not be necessary, a gradual transition and upgrade of existing systems to OPC UA is advisable. This evolution can be facilitated through the incorporation of special wrappers and proxy modules, allowing for a seamless and future-ready integration of the latest automation technologies.

Watch our Video on OPC UA

Conclusion

In essence, OPC technology, in its evolution from DA to UA and integration with TSN, emerges as a pivotal force reshaping the landscape of industrial automation. From its roots in facilitating real-time data exchange to its evolution into the versatile OPC UA standard, this protocol not only bridges the communication divide among devices but also propels industrial systems into an era of enhanced efficiency and interconnected operations. The integration of OPC UA with Time-Sensitive Networking further reinforces its capacity for real-time data transmission, offering a glimpse into a future where devices seamlessly communicate from sensors to powerful PLCs.

As we navigate the complexities of adoption, considering performance, setup intricacies, and security, the strategic transition from OPC DA to OPC UA emerges as a decisive step toward a more streamlined, interconnected, and future-ready industrial landscape, from the smallest sensors to powerful PLCs and beyond.

Comment us your suggestion to improve this article in comment box.

Kickstart OPC DA to OPC UA: IEC 62541 Modern Automation Standards