"No digitalization without standard interfaces"

The biggest obstacle facing Industry 4.0 is the absence of a uniform interface. This is the only way machines and devices from different manufacturers can be connected company-wide.  But how does this connectivity benefit the processing companies themselves? And why is it so difficult to develop an interface standard that lets you connect any peripheral device to a machine the way USB does for PCs? To find out, we sat down with Dr. Harald Weber, responsible for interface standardization at the German Engineering Association VDMA; Patrick Bruder, B&R's global technology manager for the plastics industry; and Sebastian Sachse, B&R's marketing manager for open automation technology, which includes interfaces and protocols.

Patrick Bruder, B&R: The requirement comes from our customers: the machine builders. They face the challenge of having to join together multiple machines and components, so a standardized interface would naturally be a great help. They are likely to have been encouraged in this respect by their customers, the users, who have difficulty connecting a dosing device to both Machine A and Machine B when each uses a different control system.

Sebastian Sachse, B&R: True, and now their factory floors are a hodgepodge of disparate system solutions. In the age of digitalization, we talk about seamless communication between systems.  That's hard to do when each system speaks a different language. Together with VDMA and EUROMAP, we're trying to find an effective solution to harmonize these languages.

Sachse: I can give you a good example. Imagine we have a massive production hall, and from the very start of a production cycle, one CNC machine is producing nothing but waste.  Unfortunately, the user doesn't notice this until final inspection. He's left wondering "How do I figure out which machine is to blame and what went wrong?" At present, his only option is to test his way through, one machine at a time. Meanwhile, the unusable product ends up in the bin and the entire value is lost. If it were possible, however, to localize the fault in the CNC mill right away – maybe the cutter is going too deep and damaging the outer casing – then all you throw out is one small piece of metal. The rest of the investment in value creation that goes into the final product has not yet taken place and is therefore saved. This is the efficiency boost that so many are looking for, and it's something that can only be achieved with a connected system.

Dr. Harald Weber, VDMA: That's not the only way that increased connectivity can improve efficiency. For example, it gives machines the ability to share additional data that is useful for subsequent units. If the drying unit, for example, passes on information about how much it has preheated the material, what the moisture content is and so on, then the next unit can make adjustments to optimize energy consumption without even requiring its own sensors. The potential savings extend to maintenance work as well. If the drying unit knows that an instrument will be changed on the injection molding machine in half an hour, it can adjust itself accordingly. It can ease off a bit to conserve material and then heat back up after 20 minutes so it is ready right on time.

Sachse: OPC UA has its roots in the IT world and has evolved into an open, cross-industry standard over the years. Its information models enable a large volume of data to be represented in a structured manner and transferred in a standardized form between widely varying systems. Today, OPC UA enjoys widespread industrial use, for example transferring data from control systems to IT systems. If we want to exchange process-critical data between machines, however, we need consistent timing – we need deterministic system behavior. If we send a signal from Machine A, it must be guaranteed to arrive at Machine B after exactly 10 milliseconds.  If it arrives after 20 milliseconds, the robot arm may still be inserted in the machine when the mold closes.

Sachse: OPC UA has its roots in the IT world and has evolved into an open, cross-industry standard over the years. Its information models enable a large volume of data to be represented in a structured manner and transferred in a standardized form between widely varying systems. Today, OPC UA enjoys widespread industrial use, for example transferring data from control systems to IT systems. If you wish to exchange process-critical data between machines, however, you need consistent timing – you need deterministic system behavior. If we send a signal from Machine A, it must be guaranteed to arrive at Machine B after exactly 10 milliseconds. If it arrives after 20 milliseconds, the robot arm may still be inserted in the machine when the mold closes.

Bruder: If we stick with the example of injection molding machines: these had EUROMAP 63 relatively early on. This may not allow for quite as much data to be transferred as the new EUROMAP 77, but it was a very good start. So, based on that, you can consider whether a modification or upgrade is necessary. If it is, the user has the option of replacing their old control system.  Making it OPC UA capable, however, is likely to be somewhat more difficult. It would also be possible to work instead with gateways, which have the EUROMAP 77 interface in their top layer. Then it becomes a question of cost versus benefit, but a retrofit is definitely feasible.

Bruder: Whereas there was nothing at all in the past, individual industries are now starting to come up with their own solutions. I expect the next ten years to bring a lot of changes in this arena. In my opinion, the a more generic approach is the way to go – where you start by representing a machine with the typical data and then gradually expand it with additional functions.

Dr. Weber: We've noticed these same trends at the VDMA. In the area of plastic and rubber machines we're working on EUROMAP 79 as an interface between injection molding machines and robots. At the same time, the VDMA professional association of robotics and automation is now also starting to develop interfaces. They say, of course, we're not only connecting robots to injection molding machines, but also to machine tools, wood processing machines and whatever else. Robotics manufacturers then rightly say, of course, that they don't want a separate model for each type of machine. When you have an injection molding machine working together with a robot, you're really dealing with tool position, core position and ejector. That is very specific to injection molding machines, so of course a corresponding model will have to be developed. In terms of the higher-level, generic matters, we had to start by defining a few things ourselves, since we were the first ones and didn't have anything else to build on. Now the robotics manufacturers are very active. We can exchange ideas and look at what they are developing that might be of use to us.

Bruder: We supported EUROMAP interfaces 27 and 63 early on to the extent that they were relevant for us. In these cases, we implemented them as software modules or libraries. The fact that EUROMAP is moving towards OPC UA really helps us, as we have had OPC UA on our control systems for quite some time. So we've already got some great depth in this area and are now in the process of adding real-time capability to OPC UA with TSN. This allows us to assure our customers, the machine builders, relatively early on that they are betting on the right technology.  As soon as the EUROMAP specification is finalized and published, we will also offer software solutions that make implementation easier for our customers.

Sachse: With regard to our portfolio, we already offer a large number of products with both an integrated OPC UA server and client. Our OPC UA bus controller is a good example of an OPC UA device with server functionality. Users can integrate these controllers into their system, connect the sensors they need and access production data directly via an IT network using any OPC UA client. This enables seamless communication of data from the sensor to the cloud.

Dr. Weber: We published the EUROMAP 77 interface in October of last year as a first release candidate. Some adjustments were needed, so a second release candidate will be published soon. It is important that the interface is implemented as a prototype and tested before the final release. Manufacturers are already in the process of doing so, but then we will have to follow up with the corresponding adjustments. So it is simply a question of how long it takes until the manufacturers have tested and approved their products.

Bruder: Once the specification is released, implementation will be possible right away – in part due to the fact that we already have OPC UA on our control systems. We are also working on a solution to make implementing the EUROMAP recommendation easier for machine manufacturers.

Dr. Weber: The first session for extruders took place in mid-June. The purpose of this was to look at the fundamental scope of what we want to focus on. After all, we could be talking about anything from a simple extruder – a cylinder with a worm screw inside – up to a complete processing line. Since we cannot tackle everything at once, we're starting at the center with the extruder and what data it should output. The next step will likely be the blow molding machines. There is no fixed timeline for that yet, but it will of course be addressed in the near future. We will also soon be dealing with peripheral devices. However, the major issue to begin with is the extruder.

Dr. Weber: I think the essential thing now is to build a high-level structure. That doesn't mean we're putting blinders on and saying we only care about injection molding machines and host computers, and what happens outside of that narrow focus is of no concern to us. Instead, we are saying that there is a lot that can be reused for other machine combinations and we are identifying those things. We may have to formulate a few things a bit more generally, but then what remains is only that which is truly specific to EUROMAP 77, and the rest are higher-level object types that can easily be reused elsewhere. So, when it comes time to start with blow molding machines, you find that there are indeed already a lot of general types and we can simply use those. Then we simply have to look at what else needs to be added for blow molding machines – how do they differ from injection molding machines – rather than starting over from scratch.

Sachse: For now, the TSN protocol is still being developed, so we will have to wait until the end of the year to see what kind of performance can be achieved. There will certainly be areas of overlap in applications where the performance of OPC UA TSN and POWERLINK or comparable protocols will be enough. At the moment, TSN is not able to match POWERLINK's performance, for example, in a motion application.

Sachse: The most important thing is uniform standardization. There was an attempt at this back in 2000/2001 with Ethernet. Unfortunately, what emerged was an array of different protocols instead of a universally compatible industrial standard. We now once again have the chance to standardize something uniformly. We have to make the most of this opportunity. Companies have also learned a lot in the meantime, so we are optimistic that this time we will be able to create a uniform communication standard for Industrial IoT applications.

Dr. Weber: From our perspective, the good thing is that we are operating in a pre-competitive environment. Competitors really are coming together and jointly developing a standard interface. They do not all wish to be "Apples" that only have their own proprietary interfaces and woe to anyone wanting to connect to another system. They have realized they have nothing to gain from that. And they are not afraid of becoming interchangeable, because ultimately they differ in terms of performance, cycle times and precision anyway. None of that is affected by the data being shared externally in a standardized way.

Author: David Löh , Editor of trade journal 'Plastverarbeiter', Hüthig Publishing House, Heidelberg. david.loeh@huethig.de