Mr. Munz, how long have you been fighting for mainstream and openness in industrial automation?
Munz: It all started back in 1982 during my studies: I brought together the then market-leading operating systems of the office world 'CP/M' in Germany and the real-time operating system 'OS-9' on a common backplane with Zilog Z80 and Motorola 68000 processors. I couldn't understand why the tools for OS-9 were so miserable and wickedly expensive, while CP/M had inexpensive, powerful and widely used tools such as the WYSIWYG editor 'Wordstar'. This development was also the impetus for my founding of LP Elektronik and the resulting product VxWin - the combination of VxWorks and initially Windows 95. Kuka Roboter bought this solution and ultimately the whole company in 1995. Since then, VxWin has been installed in every Kuka robot, which of course has since migrated to 32-bit Windows.

In the 1990s, there were a number of openness efforts in the context of the fieldbus war in which you were involved.
Munz: After equipping all Kuka robots with Windows, the next obvious step for me was to network the robot controllers via the Windows network. I was therefore full of enthusiasm at the time when a number of initiatives were founded - IAONA, IDA, EPSG, to name a few - in order to establish an open communication world. But in many ways we were more than 15 years ahead of our time. Only the EPSG and the standardization of a time synchronization technology for Ethernet - now known as IEEE 1588 - initiated in 2001 were successful.

You are currently working to establish the OPC UA and TSN standards. What is your motivation here?
Munz: Kuka is tired of having to support around 15 different proprietary fieldbuses on one and the same automation device. Only to then use a few bits and bytes to solve increasingly complex, synchronous control tasks with other devices. Compared to today's information technology, our operation technology is around 30 years behind. - The industry can no longer afford this.

We therefore need powerful and sustainable technologies such as OPC UA and TSN for Industry 4.0. OPC UA is not just another fieldbus. The decisive factors are the object and service orientation of OPC UA and, above all, the possibility, or even the necessity, of semantic self-description of the device equipped with OPC UA. These self-descriptions of automation devices are the key to flexible automation solutions with Self-X - i.e. self-configuration, self-diagnosis, self-healing - and even the use of artificial intelligence.

What makes you optimistic that these two technologies will now prevail against proprietary systems?
Munz: The Industry 4.0 community now agrees that only OPC UA can be considered as a common M2M standard. However, conventional Ethernet lacks deterministic real-time capability in the sub-millisecond range. It therefore makes sense to extend OPC UA with TSN as a transport layer, which is already happening through many activities, such as the Pub/Sub and TSN working groups of the OPC Foundation and some testbeds. The ZVEI and VDMA have also actively spoken out in favor of OPC UA and are working in many working groups to make it usable for Industry 4.0.

Will you give up once OPC UA and TSN are established? Or are there more standardization battles ahead?
Munz: There is still work to be done: TSN as a real-time-capable OPC UA transport layer replaces deterministic communication 'downwards'. What is still missing is OPC UA-based communication 'upwards' into the MES/ERP/cloud worlds, usually through firewalls. The valuable semantic OPC UA self-descriptions of the devices and machines should ultimately also be able to be used for their communication 'upwards'. For this to be possible in a modern, flexible and efficient way, a firewall, cloud and routing-capable transport protocol for OPC UA is required, and AMQP provides the ideal prerequisites for this. And then, once runtime communication across all levels has been completed with OPC UA, the topic of standardized engineering is on the to-do list. In my opinion, using Automation Markup Language - AML for short.