Members Only | Ezine | Links | Legal Notice | Contact us |



East Bldg #134549


Structuring with SFC
do's & don'ts
V1.0 Official Release


PLCopen Safety
Part 1
Version 2.0 now released


Information Model
V1.01.09 RfC


PLCopen starts
new working group
on Industry 4.0










TC4 - Communication



PLCopen OPC-UA Server and Client architectures - What's in it for you?


Overview: Initiatives like Industry 4.0, Smart Factories, industrial Internet of Things, and others, have communication as key element. This means that efficiency in combining intelligent systems, sensors, and actuators becomes more and more important. This paper shows that current state-of-the-art solutions can fulfill already most demands, and with the extensions even the most demanding requirements will be able to be fulfilled with standard specifications, tools, and implementations. This will add in the acceptance of new technologies and architectures.

General Introduction

Communication in industrial control is not new. The famous CIM triangle is around 30 years old and today there are many old historically grown data exchange protocols being used in various industries. They offer little possibility to transport complex data and the extensibility is very limited.
However the world of industrial automation is changing. We want to provide more and more functionalities and to do so we want to connect more and more devices. And these devices become intelligent, or even part of an intelligent system themselves. And the aspect of security is top level priority with all communications. With this trend we need new solutions to make the programming, installation, maintenance and updates easier.
The organizations PLCopen and OPC Foundation have joined forces to make this happen, and provide solutions based on the OPC UA technology for all levels of automation.
Using the OPC UA communication as standard for the industrial environment will lead in many sectors of the industries to a completely new form of information exchange: if an industry sector has defined a specific profile e.g. a data structure or a function block, then the question of secure and efficient data exchange as well as the reusability of the visualization objects is already solved. With the combination of PLCopen and OPC UA, an additional level of interoperability is standardized on top of IEC61131-3 and industrial control.

Introduction OPC UA Technology

OPC Unified Architecture, or OPC UA, offers the basis for universal, open, hardware- and software independent, secure and reliable network communication i.e. provides the monitoring of configurable timeouts and connecting interruptions and encrypted communication. For this it uses a scalable Client/Server architecture, in which the Client initiates the data request and the Server responds and delivers, possibly over a secure channel, and out of the box, as shown in Fig. 1. This overall was the basis for PLCopen to use the OPC UA technology to harmonize the communication in industrial control, and that in cooperation with the OPC Foundation.

Figure 1: The client / server architecture of OPC UA

Mapping OPC UA Server Technology in IEC 61131-3

The first step for the joined working group was to map the definition of the OPC UA information model to the IEC 61131-3 software model. The OPC UA Information Model provides a standard way for Servers to expose objects to Clients. Objects in OPC UA terms are composed of other objects, variables and methods. In this case the Objects are used to represent IEC 61131-3 software model components like CtrlProgram, CtrlTask, CtrlResource and CtrlFunction Blocks, and Variables are used to represent values. This leads to a standard way how controllers with integrated OPC UA server technology expose data structures and function blocks to OPC UA clients like HMIs and ERP systems.
In fig. 2 we see in total four layers, with on top the two OPC UA related layers. In the 3rd layer, the link between IEC 61131-3 and OPC UA is depicted. Here the elements of the IEC Software Model are shown, which are mapped on the lowest layer to the control architectures.
This mapping is enhancing transparent communication, because today when an IEC 61131-3 control program is loaded on different control platforms from different control suppliers one can communicate with these controllers by using OPC UA and access process variables. However the representation in the namespace of the OPC UA servers is different for each platform: A visualization program must each time be adapted for each controller although the control code is identical.
This does not match the expectation from the customers that an identical control project is accessed via OPC UA in the same way. This is where the definition of PLCopen OPC UA steps in, defining the accessibility to the instances of the controller variables, as well as descriptions how complex data structures are constructed, the type of function blocks used, and which variable are in or out parameters. Other metadata can be the number of tasks and their cycle times. PLCopen took care that the entire IEC 61131-3 software model and the content of the controller programs are mapped into the OPC UA namespace. This namespace can be provided by an OPC UA server which is integrated into an embedded controller, even during runtime, and with harmonization in naming conventions, this would look the same to the different OPC UA clients, meaning to the different systems like HMI or ERP.
Overall, OPC UA defines ‘how’ to communicate and PLCopen defines ‘what’.

Figure 2: The IEC model is using OPC UA Device Integration as base

The specification for the PLCopen OPC UA Information model can be downloaded from the PLCopen website.

Adding OPC UA Client Technology in PLCopen / IEC 61131-3

In the modern world the strict separation of levels and the top-down approach of the information flow like defined in the CIM triangle, is losing its dominance. In a smart network, every device or service must be able to initiate independent communication with all other services.
To do so, PLCopen and OPC UA added the OPC UA Client functionality in the PLCopen / IEC 61131-3 controller, often besides the Server functionality. For this PLCopen and OPC Foundation defined a set of Client Function Blocks. With this functionality implemented on a controller it becomes possible to initiate a communication session to any other available OPC UA Server. The controller can exchange complex data structures horizontally with other controllers independently from fieldbus system, or vertically with other devices using an OPC UA server call in an MES/ERP system in order to collect data or write new production orders to the cloud. It allows a production line to be independently active in combination with integrated OPC UA Security features.
These include functionalities like Connect to create an (optional secure) transport connection of an OPC UA session, and Read and Write for both single elements and especially for a list of elements. One can create a subscription and add monitored items to this subscription; one can browse for a client to navigate through the address space of an OPC UA Server, to monitor events, and of course functionalities for diagnostics. In addition one can use a method call, with which one calls a routine running somewhere else, which can be in a cloud, and use the feedback locally, or can be on any intelligent system to which one can communicate.

The specification for the PLCopen OPC UA Client for IEC 61131-3 was first published as version 1.0 in 2014. The new edition is now published as version 1.1. and you can download this document PLCopen_OPC-UA Client for IEC 61131.3 as .pdf.

What is in it for you? New ways to communicate

By mapping the OPC UA information model to the PLCopen / IEC 61131-3 Software model one gets a unified look and feel to the OPC UA Server technology embedded in the different brands of controllers. This is the basis for communication “Out-of-the-Box”, which can include security. If one harmonizes naming conventions throughout the company, one can even easily link a template in the HMI to the applicable data (structure) in the controller independent of the brand, as long as it support the PLCopen OPC UA mapping. One example of these naming conventions are the PackTags and the state machine as defined in the OMAC for Packaging specification called PackML, as part of the ISA 88 Technical Report on Machine and Unit States. By using these conventions consistently, one can connect a controller “out –of-the-box” via the OPC UA Client mapping on the PLCopen environment.

With the client included in the controller one can initiate the communication at the lower level, making complete new hierarchies and architectures possible, and getting the controller back in control. And even Controller-¬to-Controller communication can be realized easily, independent of the used communication architecture (like the communication bus). This gives the possibility of a new control architecture, where the communication is following the different phases of the completion of the product, as shown in fig. 3.

Figure 3: a modern production line

For instance, if one controller sets a specific velocity to a transportation system (like a belt) on which a product is moving which has to be picked up by a robot arm. The controller can do a method call to the robot controller for picking up the product while transferring the speed of the belt. The robot in turn can do a method call to the intelligent camera in order to get the rotation and translation values of the product. With these values the robot can calculate the trajectory to pick up the product smoothly and correctly. Also, communication with the ERP/MES system is possible initiated by the controller for retrieving recipe information as well as product tracing.

Figure 4: Advanced Client Server Communication

This also provides new possibilities, like the initiation of the communication as low as possible in the organization as the basis for production in Industry 4.0, as shown in fig. 5. This means that a product can have an RFID containing all the relevant information for its creation. This information can be read by the controller and the different working stations can do the appropriate actions, like adding 98 grams of yoghurt in the first station. In the end the inspection station can write back the actions that have been checked, as well initiate a method call to the ERP system to deliver the results of the processing done to the track-and-trace system. Such a system can even be in the cloud. And this is even possible today!

Figure 5: an Industry 4.0 based scenario

Future developments at OPC Foundation

And this is not the end of the story. Enhancements to OPC UA, like real-time extensions via TSN (Time Sensitive Network, making the Ethernet deterministic) will make real-time data communication possible, creating the basis to transport safety related information and allowing synchronization between the different intelligent devices, like robots. The latter esp. combined with the Publisher / Subscribe functionalities, making different communication philosophies possible. This again shows that further enhancements and improvements in programing, installation, and maintenance of communication based architectures are possible.

No matter what new initiatives like Industry 4.0, Smart Factories, industrial Internet of Things, or others will demand, the current solutions can fulfill already most demands, and with the extensions even the most demanding requirements will be able to be fulfilled with standard specifications, tools, and implementations. Communication has never been so easy as long as one is on the right track: PLCopen and OPC UA.


OPC Foundation see:
OMAC PackML see:


Technical specifications available for downloading:

OPC UA Information Model for IEC 61131-3, version 1.01.09 Release for Comments till March 30, 2018
OPC UA Information Model for IEC 61131-3, version 1.00
PLCopen_OPC-UA Client for IEC 61131.3, version 1.1


Read more about the cooperation between PLCopen and OPC Foundation:

PLCopen on OPC (Presentation February 2015)
PLCopen OPC UA Client for IEC 61131-3
Introduction in the PLCopen and OPC UA Communicationsmodel (German and English)
Explanation of the combined technologies of PLCopen and OPC Foundation
PLCopen - OPC UA - Use Cases
Information from OPC Foundation - Using OPC UA and PLCopen to Create Better Automation Solutions