OPCUA
OPC Unified Architecture (OPCUCA) is a new technology created by the OPC Foundation that is more secure, reliable, and neutral (vendor-independent) for transmitting raw data and pre-processed information from the manufacturing floor to production planning or Enterprise Resource Planning (ERP) systems. Using OPCUCA technology, all the necessary information can reach every authorized application and every authorized person anytime, anywhere.
OPCUA is manufacturer-independent, applications can communicate with it, developers can use it to develop applications in different programming languages, and it is supported on different operating systems. OPCUA makes up for the shortcomings of existing OPC applications by adding important features such as platform independence, scalability, high availability, and Internet services.
OPCUA is no longer based on the Distributed Component Object Model (DCOM), but rather on a Service-Oriented Architecture (SOA). OPCUA can therefore connect more devices.
Today, OPCUA has become a bridge connecting enterprise-level computers with embedded automation components—independent of Microsoft, UNIX, or other operating systems.
Termination of Component Object Model (COM) / Distributed Component Object Model (DCOM)
Traditional OPC applications exchange data based on Microsoft's Component Object Model (COM) technology. Because the Windows operating system is widely used worldwide, and because it promotes the use of Windows computers in automation, COM technology has created conditions for the widespread use of OPC technology. In early 2002, Microsoft released the new .NET Framework and announced the cessation of COM technology development. While this does not mean that future Windows operating systems will not support COM, as a result of this cessation, the underlying technology of traditional OPC is no longer being developed and will inevitably be phased out sooner or later, necessitating the search for new replacement solutions.
Limitations of 2COM
In the 1990s, with the widespread adoption of Windows computers, a set of features introduced by Microsoft COM/DCOM technology were highly appreciated by both 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 security mechanisms enable remote access to data and programs from computers. However, DCOM security also presents challenges for installation engineers, system integrators, and developers managing projects, including OPC communication across PCs. Properly configuring DCOM security features is a difficult task requiring significant expertise. As a result, installation engineers and system integrators routinely opt for quick processes, imposing lax access permissions on all networked OPC computers, rendering most protections ineffective and allowing unauthorized remote access.
This practice violates information technology (IT) security requirements. Over the long term, it poses a risk of damage from careless or malicious individuals. While DCOM security settings often require specialized skills, configuring OPC communication functionality is very easy.
3OPC communication through firewalls
In the automation industry, the necessity for OPC communication to cross computer boundaries was recognized early on, which is another area where DCOM limits traditional OPC communication. DCOM requires multiple ports, such as authentication, data transmission, and a range of services, to establish a connection.
Therefore, many ports had to be opened in the firewall to allow DCOM communication to pass through. Each open port on the firewall represents a security vulnerability, providing a potential opportunity for hacker attacks. Tunneling technology in OPCUA is a widely accepted strategy that solves the DCOM restriction problem in traditional OPC products.
4. Using OPC on non-Windows platforms
In industrial applications, the near-ubiquitous Microsoft platform, with DCOM as a component of the operating system, is a key factor in the rapid adoption of traditional OPC. However, the integration concept of OPC fails when using other operating systems because they do not support DCOM. This is the case, for example, in the IT industry where Unix or Linux systems are frequently used.
The same applies to automation; some application areas explicitly reject the use of Windows operating systems. Embedded devices are another area where Windows struggles (except for Windows CE or embedded XP). Here, complex applications are directly embedded in field devices, PLCs , operator panels, and other devices. They run VxWorks, QNX, embedded Linux, RTOS, or other embedded operating systems without DCOM. Using OPC integration concepts in these areas is doomed to fail because OPC requires DCOM as a technological foundation, which is precisely what is lacking in embedded systems.
5. Implement cross-platform OPC communication via Web services
With the release of the OPCXML-DA specification in 2003, the OPC Foundation demonstrated for the first time a platform-independent approach and a method to overcome DCOM limitations. Today, many OPCXML-DA products demonstrate OPC technology based on web services.
However, XML-DA communication still lags behind DCOM in data throughput, with a communication speed 5 to 7 times slower. This speed is too slow for many automation requirements. Web service-based OPC communication is still useful because it enables cross-operating system communication, but further improvements in data transmission performance are needed.
6. Unified Data Model
To date, traditional OPC technology has three different types of OPC servers – data access servers, alarm and event servers, and historical data access servers. If a user needs to obtain the current value of a temperature sensor, an event where the temperature exceeds a limit, and a historical average temperature, then he must send three requests to access three servers.
Using different methods to process user access data, events, and historical data can be very time-consuming. Therefore, unifying these three object models can simplify this process, benefiting not only OPC product vendors but also system integrators and users.
7. Supports complex data structures
One major application of OPC is the operation and monitoring of serial communication or fieldbus-networked devices. To configure a device, the OPC client needs to write data types, which are then transmitted to the device via the OPC server, including the meaning of the data structure elements.
The OPC Foundation has created a methodology for describing complex data structures, known as the Complex Data Specification. However, with very few exceptions, most traditional OPC products on the market today cannot use the Complex Data Specification.
8. Ensure no data loss during communication.
The earliest defined data access allows client applications to periodically obtain the current state of process data. Data communication can be disrupted if the physical communication connection between the OPC client and the remote OPC server fails. When communication is disrupted, the data transmitted to the OPC client may be altered or even lost.
This type of data loss is not critical in some data access applications, such as trend logging, process monitoring, or process display. However, it is critical in other applications. 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, vendors need to implement specialized, extended methods. They use connection-based monitoring systems to ensure rapid detection of disconnected communication and automatic reconnection if communication is lost. Data access servers also incorporate data caching, redundancy, storage, and forwarding capabilities. These extended methods are useful but are not defined in traditional OPC specifications and vary from vendor to vendor.
9. Enhanced protection against unauthorized data access
As Ethernet-based communication continues to grow in the automation industry, automation and office networks have become intertwined. Simultaneously, the idea of vertical integration has created new demands, and this type of integration also introduces new security risks. OPC has also increased the use of remote maintenance and remote control concepts.
Here we reiterate that unauthorized peripheral access must meet more stringent information security requirements. With the rise of cybercrime, espionage, and sabotage, information technology security is becoming increasingly important – hence the increased security requirements for OPC usage. Traditional OPC vendors have not developed proprietary preventative measures and therefore cannot meet these security requirements.
10. Supports new command invocation.
In many applications, not only is reading and writing numerical values crucial, but executing commands is also essential, 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 OPCUA and cannot be used in traditional OPC.
Disclaimer: This article is a reprint. If it involves copyright issues, please contact us promptly for deletion (QQ: 2737591964). We apologize for any inconvenience.
