Skip to content

OPC UA Unleashes a Whole New Dynamic

    Machine tool builder exeron is convinced that OPC UA is the way forward. The specialist in electrical discharge machining (EDM) has started down that path by developing a communication solution based on the open IEC standard. The solution eliminates the proprietary interface between the HMI systems and CNC controllers of the company’s EDM line. We sat down with exeron software specialists Michael Lamparth and Paulus Kolb to find out more about their OPC UA project and what plans and expectations they have for the future.

    What do you hope to gain from implementing OPC UA?

    Paulus Kolb: We’re looking to cut down on the number of interfaces we have to support. Our first step was to focus on communication within the machines themselves, but the potential for OPC UA in our industry is much bigger than that. In the mid- to long-term, our goal is to play an active role in developing and promoting standard OPC UA-based interfaces for both M2M communication as well as for integrating with shop floor data collection and ERP systems.

    So, you’re hoping to cut back on the expense of implementing and maintaining interfaces?

    Kolb: That’s right. Standardizing the interfaces frees up our internal resources and allows us to redirect that energy toward features that differentiate our EDM and milling solutions. We’re not alone in this approach either – a uniform interface really is a win-win situation for everyone involved. With OPC UA, the right solution for implementing them is already available.

    Where’s the first place you’ll be using OPC UA in your machines?

    Kolb: The first application will be to connect the HMI system to the CNC controller on our EDM line. Certain requirements unique to EDM processing prevent us from using universal controllers like the ones you typically find in machine tools. Instead, we developed special CNC controllers and – for lack of a better alternative – created a proprietary interface to connect with our HMI systems. Over the course of 20 years, this approach has resulted in a whole range of interfaces that exeron has had to develop and support with our own resources. Not only that, but we had to develop the necessary diagnostics and maintenance tools as well. If we use OPC UA, then other, larger organizations will handle all of that.

    How far along is exeron’s transition to OPC UA?

    Michael Lamparth: Our first step was to analyze our proprietary interface and define the necessary data objects. Based on that, we evaluated how these objects and the required functionality could be implemented with OPC UA. We gained valuable insight by evaluating similar technologies and approaches, such as OMG’s CORBA standard and the HMI OPC UA project conducted by the ISW (Institute for Control Engineering of Machine Tools and Manufacturing Units) at the University of Stuttgart. Then we looked into how the whole thing could be done with B&R solutions. Through our discussions with the company’s well-versed OPC UA specialists, however, it became clear that we had gotten ahead of ourselves. At the same time, that allowed us to provide some input into the process, which B&R welcomed. The result of our collaboration was a functioning prototype.

    Kolb: Unfortunately, the stack that was available at the time didn’t yet support the complex data structures and function calls we needed, so we couldn’t begin migration right away. This obstacle has since been cleared, and we’re now ready to start the actual transition.

    What other potential is there for OPC UA in your field?

    Kolb: The increasing level of automation we’re seeing from our customers means the number of interfaces that we’ll potentially need to support – throughout the line and beyond – is growing as well. One example is the scanner module we developed to equip our tool/workpiece magazines for 24-hour operation. Over the years, we’ve defined numerous interfaces to accommodate different scanner units and magazine types in the machine control and DCS systems. We’d now like to unify those with OPC UA as well.

    Lamparth: The other thing is that we’re not the only ones who offer these types of magazines. And since the other machines also use proprietary interfaces, manufacturers of cell control systems are forced to deal with a huge variety of scanner units and their respective interfaces. It stands to reason that all parties involved will benefit from an interface that provides information, such as tool position, in a uniform way. An OPC UA profile would lend itself to this.

    Does such a profile exist?

    Lamparth: We’ve taken on a pioneering role in this, and have developed a scanner interface based on OPC UA that we use internally. It could serve as a blueprint for a profile, which ideally would then be standardized by the OPC Foundation. We’re convinced that this would be met with great interest on the part of control system manufacturers. Existing systems can of course be connected via a gateway, but going forward our devices’ internal communication will all be OPC UA. We realize, of course, that machine operators aren’t going to start listing this kind of interface in their specifications until it’s been around and has established itself. But then they’ll start asking for it.

    How do you view OPC UA’s prospects in general?

    Kolb: Excellent. Current trends like Industrie 4.0 and IIoT and the ongoing OPC UA developments – like open sourcing the stack – are dialing up the pressure to develop and implement standardized interfaces at every level of the automation pyramid. Prior to OPC UA there was no standard that was simultaneously open, secure, hardware independent, cross-platform, and scalable. So, for the first time, OPC UA makes it possible to have uniform interfaces from the ERP level down to the fieldbus level. That unleashes a whole new dynamic.

    Speaking of the fieldbus level – what do you think about the real-time TSN extension for OPC UA?

    Lamparth: It’s still too early to make a final assessment, since the standard is still evolving, but we certainly welcome the determinism it brings to the fieldbus level. Of course, we’d hope to see standardized interfaces for drives to go with it. Then we’d be able to switch effortlessly between drives from different manufacturers. That’s something users have been dreaming about for ages. Still, we will continue to rely on protocols like POWERLINK that are able to transmit 150 bytes of cyclic process data highly deterministically and synchronously within 400-microsecond cycle times. OPC UA can’t do that yet, but we’ll see where the ongoing developments take us.