Dec 2015 | KUKA joined the OPC Foundation to actively initiate the expansion of OPC UA by the Ethernet-based real-time standard TSN
Meinrad Happacher, Computer & AUTOMATION spoke with Heinrich Munz, Senior Developer System Engineering at KUKA about the motives and next steps of this commitment
Mr. Munz, exactly what is Kuka’s motivation in relying on the real-time standard TSN?
Munz: Deterministic real-time computing is very important for machine builders. We have to deterministically control and regulate our machines synchronously to their movements sometimes in the sub-millisecond range from the controlling software. Through Industry 4.0 we have two new requirements that cannot be solved using conventional methods:
Firstly: Due to the laws according to Moore and Nielsen – according to which computer power or network bandwidth doubles every 18 to 24 months – in the future it will no longer be practical to accumulate individual tasks in complex, central control systems with several operating systems and hypervisors. Instead, we have to distribute the tasks to small, easily manageable, networked nodes and form so-called holonic production systems. Decentralization “below” on the plant floor and centralisation through Web services “up” in the cloud is the name of the game with Industry 4.0. Secondly: Some of these nodes will no longer be stationary in the future, instead they will be mobile and enter into real-time communication with the immobile stations at the holding stations. Example: A mobile robot conveys the half-finished product to a processing station where a stationary robot bears a polishing machine. By means of synchronised movements they polish the product together.
Up to now the necessary real-time communication for these described requirements has only been possible via fieldbuses. However, these were – as the name already indicates – developed for communication of I/O in the field and with their primitive bit and byte data are not up to the modern requirements of service-oriented –SOA for short – controller to controller communication – code word: peer to peer. In addition, they require a tremendous engineering expenditure for static configuration of the communications subscribers. Modern, IT-based networks show us that even in complex ad hoc networks – such as Ethernet or WiFi in offices or hotels – no manual configuration whatsoever is required to facilitate communication from mobile subscribers to any other subscribers. Self-X is the higher level Industry 4.0 keyword for this, whereby the X in this case is to be replaced with configuration, thus self-configuration.
Are other machine builders also confronted with these increased requirements?
Munz: The overwhelming approval of our OPC initiative from more than 20 companies and counting demonstrates that we’re not just talking about special requirements of robot manufacturers, but that other automation devices have similar requirements. Since Industry 4.0 dictates that the devices of all manufacturers must work together interoperably, this requires a single cross-company international standard with more than just a single company with the support of all of its associations as the driving force, as has been the case in the past. Don’t get me wrong: There has to be competition! But please, not when it comes to communications technologies, rather just with devices themselves – as the wireless communications industry has demonstrated for us. As a result, the target markets for all of the hitherto proprietary providers become larger and the support costs for a multitude of communication types are drastically reduced for the device manufacturers. In this way, all involved parties are better able to concentrate on the actual challenges: designing efficient and flexible automation solutions.
How long will it take until the real-time solution TSN is implemented together with OPC UA?
Munz: It’s hard to say. OPC UA today is based on a pure client/server architecture which, due to the use of TCP or HTTP over TCP with its integrated data link layer, is not real-time capable. To make OPC UA real-time capable it would therefore need to be expanded first by publisher/subscriber mechanisms which set up on the real-time capable UDP or directly on the MAC-layer.
At the same time TSN must likewise be developed, standardised and incorporated into the infrastructure components. This applies above all to the switches and their internal switch chips. Once that is all complete, the automation manufacturers still have to implement the necessary software in their devices. This will all take a few more years. However, the longest journey begins with a single step …
TSN is a rather complex construct with six sub-technologies. And IEEE hasn‘t still finished the standardisation. Can the OPC community get started anyhow?
Munz: Yes, both activities can take place in parallel. However, the TSN work will definitely proceed more rapidly than the work at the OPC Foundation. The reason is: TSN – which represents an expansion of the Audio/Video-Bridging (AVB) initiative – not only has the audio/video fans, but recently also the in-car lobbyists. And the in-car lobbyists are forcing Ethernet not only for entertainment in cars, but also for controlling various driving functions in cars, including functions relevant to functional safety. For these things they need real-time. And we all know how very large quantity requirements from the consumer world affect the implementation speed and prices of technical innovations.
Which steps must come first regarding automation?
Munz: First the switch-chip manufacturers such as Broadcom and Marvell have to convert the new TSN standards into silicon. Then the switch manufacturers have to put products with these new chips on the market. It is no coincidence that six manufacturers of industrial switches already support our initiative.
The OPC Foundation stresses that it is not the objective of the real-time expansion of OPC UA by TSN to replace conventional fieldbuses. Is the idea of replacing them so wrong?
Munz: No, of course not. In principle, there is nothing wrong with this idea of controlling conventional fieldbus I/Os by means of OPC UA over TSN. It remains to be seen if and when the first terminal manufacturer implements the OPC UA TSN stack in the head station of his terminal strips instead of or in addition to a conventional Ethernet-based fieldbus stack. From a technical standpoint this would be relatively easy to achieve, since TSN hardly has any hardware requirements for end devices, but rather has requirements on infrastructure devices such as switches. Only the time stamping of the IEEE 1588 PTP standard, which was adopted as IEEE 802.1AS, has to be supported by the Ethernet controller. This is already the case with lots of newer chips. If the head station already has such an Ethernet controller, it doesn’t need another new hardware development, but only a firmware update.
However, the following is also clear: Although the I/O control can be adopted by the new OPC UA, completely replacing the fieldbuses is not in the interest of those involved. Along with the generally agreeable migration of peer to peer communication of existing fieldbus-based to TSN systems taking place in homeopathic doses, special fieldbuses will still be needed for special tasks. EtherCAT, Sercos, Profinet IRT, Powerlink and Varan cannot be practically replaced as drive buses by TSN. The choice of which technology mix to use is left up to plant and machine installers. It’s like the PC world: “Upward” and to peer to peer – communication all PCs speak Ethernet, TCP/IP and the protocols based upon it. “Downward” there are local, sometimes proprietary communications technologies like USB, Firewire, Bluetooth, Thunderbolt, Sata and PS/2.
