Wolfram Computation Meets Knowledge

Communication in Industry 4.0 with Wolfram SystemModeler and OPC UA

SystemModeler OPCUA Industry 4.0

Background

Explore the contents of this article with a free Wolfram SystemModeler trial. Industry 4.0, the fourth industrial revolution of cyber-physical systems, is on the way! With it come sensors and boards that are much cheaper than they used to be. All of these components are connected through some kind of network or cloud so that they are able to talk to each other. This is where the OPC Unified Architecture (OPC UA) comes in. OPC UA is a machine-to-machine communication protocol for industrial automation. It is designed to be the successor to the older OPC Classic protocol that is bound to the Microsoft-only process exchange COM/DCOM (if you are interested in the OPCClassic library for Wolfram SystemModeler, you can find it here).

Having a standard for communication in the upcoming Industry 4.0 is important for every new connected device. With a carefully considered protocol, all of the following aspects can be included in a smart way:

  • Platform independence
  • Security
  • Extensibility
  • Information modeling

More information can be found on the OPC Foundation website. As you can see, a lot of focus is on the secure communication between all devices in the OPC UA network. Some of the companies that are extensively using OPC UA include Siemens, SAP, Honeywell and Yokogawa.

Wolfram SystemModeler and OPC UA

While the OPC Classic (also known as OPC Data Access) has had widespread adoption within many industries, including everything from paper and pulp to automotive manufacturing, it relies on traditional elements such as programmable logic controllers (PLCs) and SCADA (supervisory control and data acquisition) control systems.

With the advent of the Internet of Things and Industry 4.0, this traditional hierarchy is quickly being replaced with more flexible solutions. Computing power is becoming cheaper, and making smart sensors with built-in logic is no longer prohibitively pricy.

Since OPC UA is cross-platform compatible, it can be run on almost any device. This can, for example, be great for prototyping where you want to use the existing IT infrastructure but use inexpensive equipment for the trials. OPC UA can be configured on devices such as a Raspberry Pi, and even on your smartphone.

As in all networks and systems, some complex behavior might need to be calculated or modeled, and this is where Wolfram SystemModeler comes in. To easily be able to set up a control system that can connect to the machines using the OPC UA protocol will both provide easy integration and work as an efficient and cost-effective testing platform.

Here’s an example of creating an easy-to-understand test model in SystemModeler using the OPCUA library. As you can see in the model diagram below, a tank is set up (top left) with some input controlling the inflow to the tank. The tank model then communicates its value (current liquid level) through OPC UA to an OPC UA server. This value is then read from the server and fed as an input to a control loop that changes the liquid level of the second tank (bottom right).

SystemModeler OPCUA tank model

We have created the entire system in this model, i.e. in this test model we are not connecting to any hardware and can communicate through the OPC UA protocol and test the control system and its response on the system.

Now we are ready to connect with hardware and run this model in real time, communicating with some real-world tanks. We could just modify the model slightly by replacing the tank models with components that connect to the real tanks through an OPC server, and use the measured values of the tanks as inputs to the SystemModeler model. That model would look like this:

SystemModeler OPCUA tank model 2

Connecting to your OPC system with SystemModeler is actually this easy! In the system without the tanks, we get the measurements from the OPC server by reading the nodes “tank1” and “tank2” that are connected to sensors measuring the values of the real-world tanks. In the same way, we set the desired flow to tank 2 by writing a signal to the OPC server on node “tank2”. The node that we write this value to is then connected to a valve that adjusts accordingly.

The result of having an OPCUA Modelica Library is that we have all the power of Modelica, SystemModeler and Mathematica in our communications network. That means that all analysis tools, control systems and computational power can be integrated directly in the OPC UA industrial system network.

OPC UA with Other Libraries in SystemModeler

Imagine a scenario where you would like to connect the SystemModeler simulation to external hardware; for example, if you would like to send a control signal from an OPC UA server to a simple Arduino or Raspberry Pi, then combining OPC UA with the ModelPlug library would make a lot of sense. The ModelPlug library allows you to connect via the Firmata standard to devices such as Arduino boards.

SystemModeler OPCUA ModelPlug

Let’s use this in an example. In our server room, we have a Raspberry Pi that monitors and logs the temperature in the room. An OPC UA server was installed on the Raspberry Pi that allows any other OPC-configured client on the network to poll the server for the current temperature data. The OPCUA library is one such client. Using only two blocks, we can get the real-time temperature from the sensor into our simulation models.

With two additional blocks from the ModelPlug library, we can feed that data into an Arduino board, where it can be used to move, for example, an actuator. For now, let us construct a very simple prototype whereby the onboard light on the Arduino blinks at different intervals depending on the room temperature.

SystemModeler OPCUA Arduino map

With just a few blocks (and no lines of code), we can thus create a simple prototype of a logic control system that is ready to run without any of the pain that usually accompanies network programming. The light will always blink for 0.1 seconds, but the time when it blinks again will change depending on the temperature. If we press the play button, our Arduino will start blinking right away:

SystemModeler OPCUA Arduino temperature and timing

The higher the temperature, the shorter the blink interval, and vice versa.

This can also be great for testing out code and programs that you want to run in a production environment without risking damaging sensitive equipment. In Modelica, code and compiled executables can be imported, connected and used as a block in your model.

SystemModeler OPCUA Arduino custom mode map

Summary

Wolfram SystemModeler can be utilized very effectively when combining different Modelica libraries, such as ModelPlug and OPCUA, to either create virtual prototypes of systems or test them in the real world using cheap devices like Arduinos or Raspberry Pis. The tested code for the system can then easily be exported to another system, or used directly in a HIL (hardware-in-the-loop) simulation.

Comments

Join the discussion

!Please enter your comment (at least 5 characters).

!Please enter your name.

!Please enter a valid email address.

2 comments

  1. Hi!, You are giving the example where you connect a raspberry with an arduino using OPC UA. Could you please describe how you conncted those two? Cable/ports/protocol?
    Thank you

    Reply
    • The raspberryPi is connected to the OPC UA server through TCP/IP with a simple ethernet cable. The model is then run on a laptop, that is also connected to the OPC UA server through TCP/IP. The Arduino is then connected to the laptop (and the SystemModeler model) through a USB cable enabled by the ModelPlug library in SystemModeler (that uses USB Serial communication and the Firmata protocol to communicate with the Arduino).

      Reply