Essential Books for Mastering PLCs
(Download link for e-books)
OPC UA
The OPC Unified Architecture (OPC UA) is a new technology created by the OPC Foundation, which is more secure, reliable, and vendor-neutral, allowing for the transmission of raw data and pre-processed information from the manufacturing site to production planning or Enterprise Resource Planning (ERP) systems. With OPC UA technology, all necessary information can reach every authorized application and personnel anytime and anywhere.
OPC UA is independent of manufacturers, allowing applications to communicate with it, and developers can implement it using different programming languages across various operating systems. OPC UA addresses the shortcomings of existing OPC by adding important features such as platform independence, scalability, high availability, and internet services.
OPC UA is no longer based on the Distributed Component Object Model (DCOM) but is built on a Service-Oriented Architecture (SOA). Therefore, OPC UA can connect to more devices.
Today, OPC UA has become the bridge connecting enterprise-level computers with embedded automation components – independent of Microsoft, UNIX, or other operating systems.
1Termination of Component Object Model (COM)/Distributed Component Object Model (DCOM)
The data exchange between traditional OPC applications is based on Microsoft’s Component Object Model (COM) technology. The widespread use of the Windows operating system globally has facilitated the use of Windows computers in automation, thus creating conditions for the widespread adoption of OPC technology. In early 2002, Microsoft released a new .NET framework and announced the cessation of development for COM technology. Although this does not mean that future Windows operating systems will not support COM, the result of this cessation is that the foundational technology of traditional OPC is no longer being developed and will eventually be phased out, necessitating the search for new alternatives.
2Limitations of COM
In the 1990s, with the popularity of Windows computers, the features introduced by Microsoft’s COM/DCOM technology were highly appreciated by home computer users and industrial automation users. These features included copy and paste, drag and drop, linking and embedding. DCOM also provided a complete communication infrastructure with necessary security mechanisms such as authorization, authentication, and encryption.
DCOM’s security mechanisms enable remote access to data and programs. However, DCOM’s security mechanisms also pose challenges for installation engineers, system integrators, and developers managing projects, including OPC communication across PCs. Correctly configuring DCOM security features is a very difficult task that requires extensive expertise. As a result, installation engineers and system integrators often opt for quick processes, applying loose access authorizations on all networked OPC computers, leading to most protections being ineffective and allowing unauthorized remote access.
This practice contradicts the requirements of information technology (IT) security. Over the long term, there is a risk of damage from careless or malicious individuals. DCOM security settings often require special skills, while configuring OPC communication features is relatively easy.
3OPC Communication Through Firewalls
In the automation industry, the necessity for OPC communication to cross computer boundaries has long been recognized, which is another limitation of traditional OPC communication imposed by DCOM. DCOM requires multiple ports for authentication, data transmission, and establishing a connection with a series of services.
Therefore, many ports must be opened in the firewall to allow DCOM communication to pass through. Each port opened in the firewall poses a security risk, providing potential opportunities for hacker attacks. The tunneling technology in OPC UA is a widely accepted strategy that addresses the limitations of DCOM in traditional OPC products.
4Using OPC on Non-Windows Platforms
In industrial applications, the almost ubiquitous Microsoft platform, with DCOM as a component of the operating system, is a significant factor in the rapid acceptance of traditional OPC. However, the integration concept of OPC does not work well when using other operating systems that do not support DCOM. For example, in the IT industry, Unix or Linux systems are often used in such cases.
Automation is similar; some application areas explicitly refuse to use Windows operating systems. The embedded device field is another area where Windows has difficulty (except for Windows CE or Embedded XP). Here, complex applications are directly embedded into field devices, PLCs, operator screens, and other devices. They run on VxWorks, QNX, embedded Linux, RTOS, or other embedded operating systems without DCOM. In these areas, the integration concept of OPC is destined to fail because OPC requires DCOM as its technical foundation, which is precisely absent in embedded systems.
5Cross-Platform OPC Communication via Web Services
With the release of the OPC XML-DA specification in 2003, the OPC Foundation first demonstrated a way to overcome DCOM limitations that is independent of the Windows platform. Today, many OPC XML-DA products showcase web service-based OPC technology.
However, the data throughput of XML-DA communication still does not match that of DCOM, with communication speeds being 5 to 7 times slower. This speed is too slow for many automation requirements. The web service-based OPC communication capability is still useful as it enables cross-operating system capabilities, but further improvements in data transmission performance are needed.
6Unified Data Model
So far, traditional OPC technology has three different OPC servers – Data Access Server, Alarms and Events Server, and Historical Data Access Server. If a user needs to obtain the current value of a temperature sensor, an event where the temperature exceeds a limit, and the historical average temperature, they must send three requests to access three servers.
Accessing process data, events, and historical data using different methods takes a lot of time. Therefore, unifying these three object models can simplify such tasks, benefiting not only OPC product suppliers but also system integrators and users.
7Support for Complex Data Structures
One of the main applications of OPC is the operation and monitoring of devices connected via serial communication or fieldbus. To configure devices, OPC clients need to write data types through the OPC server to reach the devices, including the meanings of data structure elements.
The OPC Foundation has created methods to describe complex data structures, known as complex data specifications. However, most traditional OPC products on the market today, with few exceptions, cannot utilize complex data specifications.
8Ensuring Communication Without Data Loss
The initially defined data access allows client applications to periodically obtain the current state of process data. If there is a physical communication connection issue between the OPC client and the remote OPC server, data communication can be compromised. When communication is compromised, the data transmitted to the OPC client may change or even be lost.
This data loss is not critical in some data access applications, such as trend recording, process monitoring, or process display. However, in some applications, it is very critical. For example, OPC technology has become fundamental in areas such as the chemical or petrochemical industries, where seamless data recording is required.
To achieve this goal, suppliers need to implement special extended methods. They use connection-based monitoring systems to ensure quick detection of disconnected communication, automatically reconnect if communication is lost, and have data caching, redundancy, storage, and forwarding capabilities in the data access server. These extended methods are useful but are not defined in traditional OPC specifications and vary by supplier.
9Increased Protection Against Unauthorized Data Access
With the continuous growth of Ethernet-based communication in the automation industry, automation and office networks have become intertwined. At the same time, the idea of vertical integration has created new demands, which also brings new security risks. OPC has also increased the use of remote maintenance and remote control concepts.
Once again, regarding unauthorized access to peripherals, stricter information security requirements must be met. With the rise of cybercrime, espionage, and sabotage, information technology security has become increasingly important – thus, using OPC also comes with security requirements. Traditional OPC suppliers have not developed proprietary preventive measures, so they cannot meet these security requirements.
0Support for New Command Calls
In many applications, not only is reading and writing values very important, but executing commands is also crucial, such as starting or stopping a drive or downloading a file to a device. The OPC command specification defines how to execute these commands, but this is only valid in OPC UA and cannot be used in traditional OPC.
Essential Books for Mastering PLCs
(Download link for e-books)
(This article is a reprint from Xijia Transmission, copyright belongs to the original author. If any videos, images, or text used in this article involve copyright issues, please inform us immediately, and we will correct or delete the relevant content upon confirmation! No individual or organization bears related legal responsibilities.)