OPC UA

What is OPC UA?

OPC UA is an indus­trial commu­ni­ca­tion protocol with a service-oriented archi­tec­ture and an infor­ma­tion modeling frame­work for indus­trial systems. You will also see the spelling OPC-UA; both refer to the same stan­dard. An OPC UA server runs on a device or soft­ware appli­ca­tion and exposes its data in a struc­tured address space. An OPC UA client, for example a SCADA system, an MES or an edge appli­ca­tion, connects to the server, browses the address space and reads, writes or subscribes to values. Because the spec­i­fi­ca­tion defines both the services and the data model, any OPC UA client can work with any OPC UA server, regard­less of vendor or oper­ating system.

In simple terms: OPC UA is a common language plus a secure tele­phone line between machines and soft­ware. The language defines how a temper­a­ture, a motor state or an alarm is described. The line makes sure only autho­rized part­ners can listen and talk.

What does OPC stand for, and what is the differ­ence between OPC and OPC UA?

OPC orig­i­nally stood for OLE for Process Control. The first OPC spec­i­fi­ca­tions from the 1990s, today called OPC Classic, included OPC DA (Data Access), OPC HDA (Histor­ical Data Access) and OPC A&E (Alarms and Events). They were based on Microsoft’s COM and DCOM tech­nology and there­fore tied to Windows. DCOM was hard to configure across networks and fire­walls, and each spec­i­fi­ca­tion covered only one type of data.

In OPC Classic, an OPC server provided data to OPC clients via DCOM, and each data type needed its own server. The OPC Foun­da­tion devel­oped OPC UA to replace these limi­ta­tions. The name now stands for Open Plat­form Commu­ni­ca­tions Unified Archi­tec­ture. OPC UA unifies data access, histor­ical data, alarms and methods in one frame­work, runs on any oper­ating system from small embedded devices to cloud servers, and does not depend on DCOM. OPC Classic servers can still be connected through wrap­pers and gate­ways, which helps in brown­field plants.

How does OPC UA work? The OPC UA archi­tec­ture

The OPC UA archi­tec­ture rests on three pillars, and the OPC UA spec­i­fi­ca­tion describes each of them in its own part.

The infor­ma­tion model and address space

Every OPC UA server orga­nizes its data as nodes in an address space: objects, vari­ables, methods and the refer­ences between them. A node has a type, so a client does not just see “value 87.3” but knows that it is the temper­a­ture of motor 2 in degrees Celsius, with limits and an engi­neering unit. This infor­ma­tion model is what sets OPC UA apart from a pure data transfer protocol.

Services and trans­port

The OPC UA protocol defines stan­dard­ized services that clients use to browse, read, write, subscribe and call methods. The most common trans­port is the binary OPC UA TCP protocol on port 4840. HTTPS and WebSockets are also defined. OPC UA runs over stan­dard Ethernet and IP networks, and in combi­na­tion with Time-Sensi­tive Networking (TSN) it can deliver deter­min­istic real-time commu­ni­ca­tion.

Built-in secu­rity

Secu­rity is part of the spec­i­fi­ca­tion, not an add-on. Every OPC UA appli­ca­tion has its own X.509 certifi­cate, which OPC UA uses to authen­ti­cate appli­ca­tions, supports user authen­ti­ca­tion, and signs and encrypts messages. Oper­a­tors can choose the secu­rity policy per connec­tion. Correctly config­ured, OPC UA meets the require­ments of indus­trial secu­rity stan­dards such as IEC 62443, which matters for OT secu­rity and the Cyber Resilience Act.

OPC UA client and server

The client-server model is the classic way to use OPC UA. Client soft­ware connects to the server, estab­lishes a secure session and works with the address space. A server can serve many clients, and an OPC UA appli­ca­tion can act as client and server at the same time, for example an edge gateway that collects data from several machines and offers it to the cloud. Typical OPC UA servers run in PLCs, drives, robot controllers, SCADA systems and almost every modern control system. Typical OPC UA clients are HMIs, histo­rians, MES, analytics tools and engi­neering soft­ware. Many devices now ship with a built-in OPC UA server, so connecting a new machine often means config­uring, not program­ming. This is the most common protocol used in indus­trial automa­tion to stan­dardize access to machine data.

OPC UA PubSub

Client-server works well for one-to-one connec­tions, but it reaches its limits when one device has to send data to many receivers or when data needs to flow to the cloud. For these cases, the OPC Foun­da­tion added publish-subscribe to the spec­i­fi­ca­tion. With OPC UA PubSub, a publisher sends messages without knowing who receives them, and subscribers listen to the data they need.

PubSub supports two kinds of trans­port. Broker­less, it sends UADP messages via UDP multi­cast in the local network, suit­able for fast controller-to-controller commu­ni­ca­tion. Broker-based, it sends messages through a broker such as MQTT, typi­cally encoded as JSON, which makes OPC UA data easy to consume by cloud and IT appli­ca­tions. The infor­ma­tion model stays the same in both cases.

The Open Industry 4.0 Alliance builds on exactly this combi­na­tion. Its Open Edge Computing (OEC) compli­ance requires a secu­rity-enabled data bus based on MQTT and data exchange between appli­ca­tions based on MQTT and OPC UA PubSub. The OI4 message format uses OPC UA PubSub seman­tics, and asset infor­ma­tion follows OPC’s Vendor­Name­plate model.

Companion spec­i­fi­ca­tions: OPC UA for specific indus­tries

The base spec­i­fi­ca­tion defines how to model data, but not what a robot or a machine tool should look like. Companion spec­i­fi­ca­tions fill this gap. Industry asso­ci­a­tions and the OPC Foun­da­tion define stan­dard­ized infor­ma­tion models for device types and domains, for example for machine tools (the umati initia­tive), robotics, machine vision, pack­aging, process instru­ments, auto-ID devices and plas­tics machinery. A client that under­stands a companion spec­i­fi­ca­tion can work with every compliant device of that type without custom mapping. There is also a companion spec­i­fi­ca­tion that maps the Asset Admin­is­tra­tion Shell to OPC UA.

What is OPC UA used for?

OPC UA is used wher­ever indus­trial data must move between systems from different vendors:

• vertical inte­gra­tion from sensors and PLCs to SCADA, MES and ERP
• machine-to-machine commu­ni­ca­tion between controllers and produc­tion cells
• data access for analytics, condi­tion moni­toring and energy manage­ment
• connecting edge devices and cloud plat­forms in the indus­trial internet of things
• remote I/O and field-level commu­ni­ca­tion, increas­ingly with OPC UA FX (Field eXchange)

In the OI4 soft­ware-defined automa­tion project, members inte­grated OPC UA-based remote I/O instead of tradi­tional field­buses in a Kuber­netes-based demon­strator. In the energy moni­toring project, OPC UA is one of the proto­cols eval­u­ated to collect energy data from machines of different ages and vendors.

Bene­fits and features of OPC UA

OPC UA enables vendor-inde­pen­dent data exchange, and OPC UA provides the secu­rity and seman­tics that older proto­cols lacked. The main features of OPC UA:

• Inter­op­er­ability: one stan­dard instead of propri­etary drivers for every device
• Seman­tics: data arrives with its meaning, not as anony­mous values
• Secu­rity by design: authen­ti­ca­tion, signing and encryp­tion in the protocol
• Plat­form inde­pen­dence: from embedded devices to cloud servers
• Scal­a­bility: client-server for local access, PubSub for one-to-many and cloud
• Future-proofing: an open IEC stan­dard main­tained by a broad industry foun­da­tion

OPC UA, MQTT and the Asset Admin­is­tra­tion Shell

OPC UA is often compared with MQTT, but the two are not alter­na­tives in every case. MQTT is a light­weight trans­port without a built-in data model. OPC UA brings the model and can use MQTT as one of its trans­ports through PubSub. The Asset Admin­is­tra­tion Shell adds the life­cycle view: it describes every­thing about an asset, from name­plate to docu­men­ta­tion, while OPC UA delivers the live oper­a­tional data. Read MQTT vs OPC UA for a detailed compar­ison.

The future of OPC UA

Each new version of OPC UA has added features, and three devel­op­ments stand out. OPC UA FX extends the stan­dard to the field level and to controller-to-controller commu­ni­ca­tion, with TSN for deter­minism. PubSub over MQTT makes OPC UA data a natural input for cloud and data plat­forms. And the growing number of companion spec­i­fi­ca­tions turns OPC UA from a protocol into a library of stan­dard­ized machine descrip­tions. Together with the AAS and soft­ware-defined automa­tion, OPC UA is becoming part of an open, multi-vendor automa­tion stack.

Frequently asked ques­tions