Trend interview: Software engineering in drive technology

We have been working hard for many years to make engineering easier for our customers in every phase of a machine's life cycle. EASY, our end-to-end engineering tool chain, plays a significant part in this, because it allows parameterisation instead of programming in all phases of operation. The individual tools in the chain are tailored to the individual phases in the life cycle of the machine. Using one interface, we create a continuity in the operator interfaces so that they always look and work the same way in all the tools. They also contain a skill level, so they can support the user in a way that suits his abilities. This means that even users with little training can easily do their jobs without any machine know-how at all.

Our FAST application software toolbox is based on this EASY tool chain, and it provides frequently required machine functions in the form of standardised technology modules. The framework consists of a template and intelligent standardised software modules, in which we have, so to speak, encapsulated our knowledge of machines. Our customers can use them to integrate even complex machine functions into their machines easily and reliably - just with parameterisation. We believe that these ready-made, reusable solutions can cover up to 80 per cent of the motion software engineering that is needed. This results in a much more streamlined engineering process and reduces engineering times, and it also opens up new ways of using data and generating information for process optimisation. We offer ready-made applications for the typical applications in the following industries: packaging technology, automotive, intralogistics, printing & converting, and textile. Our next move is to continue developing our third pillar: our SMART mobile apps, which will also provide support in all phases of the life cycle.

How effective are tools of this kind? Are they any good when a customer's complex requirements for user-specific solutions have to be very precisely met? Are there any limits to the way they can be used - where, for example, does the division into sub-functions reach its limits because the system has to be seen as a whole (comparable with the discussion on the subject of energy efficiency)?

There are two other questions in the same context:

1. At what point is it better to do programming, so as to avoid using the parameterisation tool for the wrong purpose?

2. Which specific extensions make sense from a parameterisation point of view, without parameterising to the point of absurdity? In other words: when does a parameterising tool become a programming tool?

If we take the machine environment into account, we can definitely allow for up to 80 per cent parameterisation in a solution. The rest is the customer's special knowledge, and we are neither able nor willing to include that in the design of our tools. If we did, the tools would no longer be useful for everyone, and - much more importantly - that extra 20 per cent is what makes the machine special and gives the customer his competitive advantage. So this is where the programming begins. And because we believe in using established standards, we also make the programmer's work as easy as possible: we use IEC 61131, and we provide our customers with our PLC Designer, a tool that is based on market leader Codesys 3.0. So, to sum up: the machine manufacturer can cover the basic functions with standard modules and then focus on programming the special aspects of his machine. By the way: we also offer our customers the option of making a reusable parameterisable software component retrospectively from a piece of special programming.

What role does the "digital twin" play in all of this? Does it exist as a kind of "master" template before the parameterising and programming are done, or is it more a result of that? What are the benefits of the digital twin for the user?

I am sure that in most cases today the digital twin (DT) is still created afterwards, as a copy of the real system. But in the future, it will definitely be created as a master template: first there will be the digital machine, then the real one. By creating the DT with modern simulation tools, we can work out the machine's behaviour and then implement it later in the real machine. Our aim is to support the customer by first of all creating the machine digitally and enhancing it with information. The machine is then "commissioned" on a desktop, so to speak. By loading the program into the controller, we can check the machine's motions, and then right at the end - when he is sure that the setup is working correctly and everything is running smoothly - the machine manufacturer can focus on the real hardware. We call this iterative virtual engineering. The advantage is that it reduces commissioning times, and the customer only has to deal with the hardware at the very end. The best thing about it, though, is that the machine manufacturer can relatively quickly make a reliable promise to his own customer to deliver a specific level of performance. We see two areas of application for digital twins: firstly in logistics and sales, and secondly in commissioning, diagnosis and service.

To what extent can such tools be used without a detailed knowledge of the product or technology?

The machine manufacturer no longer needs any product knowledge at all to be able to use our tools. He can concentrate completely on his machine, and he only has to describe the process he needs. Our tools then support him so much that at the end he only has to press a button, as it were, to know whether he needs a system with a centralised or a decentralised control and which software he requires. Of course, if he wants it, the customer also has the option of bringing in his own special knowledge at this stage, and then he just has to dip deeper into the tools.

In the medium to long term, do you see any need to integrate your tools into higher-level engineering systems? The key phrase here is end-to-end engineering. From the automation point of view, how do you support the exchange with other disciplines such as machinery development and/or IT development?

Yes, I do, definitely! We must be able to integrate tools into higher-level engineering. It is the only way to operate the machine efficiently and with a reasonable amount of effort. Lenze is already equipping its products with high-performance standard interfaces that are widely used in the market. There are new requirements emerging from the world of Industrie 4.0, for example from the use of digital twins or the connection to different clouds. Here, too, we are very much on the ball, supporting standards such as Automation ML, Open AAS, MQTT or OPC UA.

Learn more at www.lenze.com.