This is a brief explanation of one of the fundamental aspects of the structure of an automated project applied to Industry 4.0, data transmission technologies, specifically OPC UA. It is essential in project development and in how its architecture is composed.
Introduction
One of the most common challenges within the automation or specialized production industry is the ability to share real-time information from components and sensors within a production process.
In the manufacturing and especially the automation industry, selecting a protocol that suits our needs is a matter of utmost importance that cannot be taken lightly. We must understand the critical aspects of the project we are working on and the characteristics and strengths of each protocol used in the industry. Just like a language, the components of our project must communicate in the best possible way, ensuring zero loss of data and information that could be vital at a given moment.
This arises from the need for companies to carry out productive processes in pursuit of the ideal Industry 4.0. The main objective of industrial automation is for companies to achieve better results and ensure greater productivity.
All of this is achieved through a thorough reading of data and information and its corresponding analysis for correct interpretation so that decisions can be made to improve production or manufacturing quality.
Automating a production process allows us to maximize operational capacity. This is achieved through significant data and information exchange that serves strategic tasks and speeds up decision-making and approvals.
Currently, most devices can use almost any communication protocol, so we shouldn't have issues choosing a standard for the entire development. However, it's important to consider and investigate whether any of our instruments will use a specific communication protocol.
Some of the most used information transmission technologies in the industry are TCP/IP, Modbus, OPC Classic, OPC UA, Profinet, MQTT, Powerlink, CANopen, and ControlNet.
In this article, we will explore one of the most promising standards in the sector, the OPC UA standard, which offers certain capabilities that have brought numerous improvements and conveniences to the world of automation. These are two of the most used standards in automation, and they provide us with capabilities that we can leverage for the type of projects we need to develop. We will delve into the characteristics of each, as well as the advantages and disadvantages they offer.
Differences between OPC Classic and OPC UA
Going back in time, we find the creation of OPC (currently known as OPC Classic). A communication method that offered the capability to link components and systems using different communication protocols to transmit information.
OPC aimed to access all this data generated from a single place. However, this standard had some areas for improvement, such as using proprietary Microsoft technologies, which limited this communication. It was also prone to cyberattacks, lacking any integrated security mechanisms.
Therefore, we later had OPC UA, a revised and improved OPC standard designed to address some of OPC Classic's weaknesses.
Firstly, the data transmission protocol changed. From using Microsoft technologies, it moved to using TCP/IP connections (Transmission Control Protocol/Internet Protocol), which is compatible with various software systems, embedded systems, and other PC platforms.
Regarding security, OPC UA has integrated controls and devices that restrict who can access information, and it can authenticate and encrypt data from the start of the transmission.
Even compared to OPC Classic, OPC UA, thanks to its scalable design, allows us to expand our system to almost any type of equipment, from mobile phones to cloud applications. It is designed with a multi-layered architecture that can adapt to almost any resource limitation.
OPC UA
The OPC UA standard is not a protocol in itself but rather a data connectivity method that facilitates communication between equipment and control systems. It is capable of providing users with open and independent connectivity in data transmission.
It is expected to visualize OPC communication as an intermediate abstraction layer between the Data Source and the Data Client. This way, data can be transmitted without one knowing anything about the other, without forcing them to replace their protocols with OPC; their native protocols can be retained. Thus, the application can exchange information with the device without communicating directly.
Depending on the project needs, there are several types of OPC to use:
- OPC DA (Data Access): Mainly used for real-time data transfer between control systems and field devices.
- It is the most commonly used data specification, and almost any type of data can be established within it, from integer values or text strings to more complex objects made up of various data types.
- Each item contains: Name, Value, Timestamp, Quality
- OPC HDA (Historical Data Access): This OPC variant focuses on obtaining historical data stored in control systems, databases, or a remote terminal unit.
- The analysis of these data can be used to measure trends, predict failures, and evaluate performance, among many other uses.
- OPC A&E (Alarms and Events) focuses on monitoring and managing alarm configuration, event logging, and real-time plant condition tracking.
An OPC architecture mainly comprises two OPC components, the OPC Client and the OPC Server. OPC Servers can be likened to translators, as they connect OPC clients and components to the world of devices and data sources. This communication is carried out bidirectionally, transferring information from the data source to the Client whenever requested.
Typically, these servers are integrated into the database itself. For example, in our setups, we almost always use PLC devices as OPC servers so that, in an integrated way, access to each of the data or objects stored in the information server can be manipulated directly from an OPC client without involving additional devices. The ability to use a PLC as an OPC server is commonly a feature of the device itself.
On the other hand, OPC Clients represent the data's destination. Their job is to initiate and control communication with OPC Servers through requests received directly from the application they are embedded in. In other words, when we have an application where we want to control data directly from an OPC Server, we need to integrate an OPC Client to enable communication with this standard.
Source
InfoPLC.net. (n.d.). Guía para entender la tecnología OPC. Retrieved from https://www.infoplc.net/files/documentacion/comunicaciones/infoplc_net_guia_para_entender_la_tecnologia_opc.pdf
AES Global Services. (2024). Communication protocols in industrial automation. Retrieved June 20, 2024, from https://aesgs.com/blog/communication-protocols-in-industrial-automation
