Dr. Pospiech, how did the idea for the IoT box come about?
Prof. Dr. Pospiech: Another professor approached me with the idea of starting a lecture series on the topic of Industry 4.0. There were lots of colleagues from other departments present, who don't have much to do with automation technology — their backgrounds are in production, forming technology, or injection molding, for example. That is why I asked myself the question: What is the meaning of Industry 4.0 and what is its role here at the
…because it is a fairly abstract topic. But how does somebody make it easy to understand and demonstrate it practically?
Prof. Dr. Pospiech: Exactly. I then decided to focus on the topics of IoT and bus systems in industry practice — with the question in mind: What can I explain to the students directly in the lecture theater? And most importantly: What can I show! IoT literally means "The Internet of Things" and thus, my aim was to bring every electrical "thing" into the Internet, even a simple light bulb. This led to the idea to pack a lot of components together into a small space. If these components can illustrate the IoT in a portable box, then Open Platform Communications Unified Architecture (OPC UA) is unavoidable. So, I looked at it in depth: Which PLC from which manufacturer even functions with OPC UA? But also: How does commissioning work in practice? I do not have the time to spend one and a half hours configuring the system. I must be able to convey to someone within 15 minutes which parameters have to be set up, then it has to work.
Why are both of these functions required and how do they work together in the IoT box?
Prof. Dr. Pospiech: To understand this, we must leave the university setting and turn our attention to industry practice. Current production machines are so flexible and deliver such a high performance that one controller alone is no longer enough. You need multiple CPUs, and for them to be able to communicate with each other, they need OPC UA. It is the one. In addition, there is the networking with the higher-level systems — MES level, ERP level, etc. OPC UA allows you to connect the field level to SAP—or to a cloud—and you can interlink the various controllers.
The functioning and topology of MQTT are completely different than those of OPC UA, for example
Industrial Ethernet already exists with a variety of established standards.
Why then do I also need OPC UA?
Prof. Dr. Pospiech: OPC UA also runs as a communication protocol on the existing Ethernet hardware. However, it is primarily used to connect controllers with each other and with the PC level. Therefore, it is not to be confused with protocols such as Profinet, Powerlink, etc., where it is mainly about controlling actuators in the microsecond range. At this point in time, OPC UA cannot do this. With the upcoming expansion to OPC UA TSN, which will hopefully be available in around a year or two, it will then also be possible to control drives in real-time.
Next, we come to MQTT. What was the reason for the integration here?
Prof. Dr. Pospiech: This is a completely different world. It actually comes from messenger services such as Twitter. The goal is to quickly transfer data or information to somewhere else without a great deal of protocol overhead. OPC UA, for example, has a fairly large overhead with security mechanisms, objects, etc. MQTT is all about the content of the message — that is, the individual values. Therefore, where the message is created, I do not need a powerful CPU. It can, for example, be battery-backed. For instance, a sensor transmits individual values to a broker — a central receiver — who then redistributes the messages to the "interested parties." The functionality and topology of MQTT are completely different than that of OPC UA, for example. The advantage is that if I have a sensor somewhere and I am interested in its values, I do not have to lay cables and I do not need a high performance CPU. Instead, I can simply have the data sent to me using the mobile network. I expect that in a few years' time, sensor manufacturers will integrate MQTT or a similar functionality into the sensor module as standard.
Another component and user interface you have integrated into the box is Alexa, i.e. the EchoDot from Amazon. Please tell us how it all works.
Prof. Dr. Pospiech: Yes, Alexa, my girlfriend. (laughs) It is simply a way to make it easier for students to understand the complexity of the whole thing and to motivate them a little. The advantage is that the voice recognition is extremely good. So, I use Alexa to explain to students how data is generated, how it finds its way from the sensor to the cloud and what can be done with it — Big Data, Predictive Maintenance, etc. The whole thing works like this: A temperature sensor, for example, is linked to the OMRON controller. Using MQTT, I send the current temperature value to the cloud, every second. Now the data is available in an Excel spreadsheet or a database. But for Alexa to answer my question about the current temperature, I must program a skill into the cloud. This skill does not exist as such, it cannot be bought anywhere or downloaded. So I have already motivated students to take a closer look at the data in the cloud and to consider how it can be transmitted to Alexa.
The automation pyramid will become more and more distorted
Industry 4.0 also means marrying automation technology and information technology. First, the OMRON CPU must have access to the data — this is still largely automation. However, for Alexa to be able to interpret the data, I require completely different programming languages and completely different background knowledge. The possibility to program Alexa to take the data either from the cloud or directly from the Omron controller via MQTT allows me to introduce the students to both worlds. It works so well that I wonder if there will be industrial applications with this technology in the future. You just have to be open and cast off the blinders. Of course, the security of data and information must not be ignored. By fusing
automation and information technology and the resulting possibilities, the classic automation pyramid will become more and more distorted.
From your point of view, what does this change mean for manufacturers such as Omron?
Prof. Dr. Pospiech: I have been watching the programmable logic controller market for many years now, since around the turn of the millennium. Almost every year, providers increase the performance of their controllers and this is also reflected in the possibilities of realizing very complex functionalities and applications, year after year. The trick is now for the development environment—that is the automation engineer's tool — to reproduce these complex functionalities transparently and as simply as possible to allow for an efficient (and for the industry economic) implementation. There are systems where I simply cannot understand the procedure for the appropriate implementation, and then I have a problem. If we now imagine that, due to Industry 4.0, new functionalities or those alien to automation technology are added from the IT world, then the situation is unlikely to improve. Industry 4.0 will become very costly, because labor hours for industrial projects are limited and expensive.
How has the IoT box been received by the students? Can you tell us an interesting story from the lecture series?
Prof. Dr. Pospiech: The box hasn't been around for that long yet, just one semester really. But I can tell you about a small success story. After a lecture, eight students approached me on their own initiative and asked me if we could look at the topic in greater depth privately, outside of the university. This is something that rarely happens. They found it so much fun that we set up a working group which is still going now. We meet at least once every fortnight and exchange ideas, build small modules together and so on. For me, this is the greatest evidence that I was able to awaken the students' interest with the IoT box. They can see immediately how something works. It is slightly different to a PowerPoint presentation, because I program and parameterize everything live during the lecture, so that the necessary steps from A–Z can be understood. I show the entire workflow from start to finish.
That's a very nice story! Is there anything else you would like to add on this subject?
Prof. Dr. Pospiech: I just wanted to say something briefly about the Raspberry Pi and the reason for its inclusion in the IoT box. The single-board computer is affordable for students and costs about as much as a textbook. Personally, I am a great believer in the "learning by doing" learning method and support the view of Erich Kästner: "The reward is in the doing." In a figurative sense, this means that for maximum learning success you must be hands-on with the keyboard. I want to provide students with the best possible opportunity for this. That is why I have brought together various existing programs, libraries, and self-programed "things" into one image, meaning students have the same working basis at home as they do with me during the lecture. The approach is roughly the same as that of the Amazon cloud or the Microsoft cloud, in that we are running an Apache server, PHP, a mosquitto broker for MQTT, and much more besides. All this can be done at home with the Raspberry Pi, which in principle is a fully functional private cloud.