If software in a mechatronic project wants to settle with the other disciplines immediately, it must be able to communicate with them. For these co-disciplines – mechanics, electronics and control engineering – software code is one black box, so it will have to be done at a higher level of abstraction. Model-driven software development or MDD (model-driven development), offers a solution. Sioux Technologies has built its own tools for this and continues to develop them in customer projects, as recently with Masevon. “We’ve never built a machine so fast.”
– It started with Supermodels, a platform where users can use development languages to create a model of the system.
– Different development disciplines can communicate with each other about that model in abstract terms.
– And there is Holodeck to visualize the mechanics in 3D and represent what is happening physically.
– ‘You converge much faster to a correct design’
Supermodels bring peace, speed and security
The collaboration with the high-tech system supplier Masévon resulted for the technology company Sioux in the largest project to date with MDD in mechanical engineering. It is a revolutionary design for the pharmaceutical industry, says leading engineering software Valentine Scheifes from Masevon. ‘The first machine has now been delivered. In four weeks, we were able to build it up and test the whole process. I thought it could have been faster, but Masévon had never had a new machine on the floor in such a short time. ‘
Because existing tools in mechanical engineering projects were not sufficient, Sioux itself developed MDD tools, says software architect Robert Hendriksen. ‘In recent years, we have gained experience with this in projects that led to expansions that have made the tools better.’ It started with supermodels, a platform where users can use different development languages to create a model of the system to be designed. Different development disciplines can communicate with each other about that model in abstract terms, for example for reviews. Simulators have been integrated into the platform to study model behaviors and improve design accordingly. Finally, the software code for the system control can be generated from the model. It reminds me of digital twin, but Hendriksen has a comment on that. ‘The simulator helps software development to become more independent of integration (with the hardware, ed.). Some see this as a digital twin, but I try to avoid the term because for others it means the digital representation of a machine (in the cloud). And that’s something other than the simulation. ‘
A key MDD concept is state machine: a model description in the form of states, transitions between these states and inputs that trigger such a transition. Think of a door that can be opened or closed and a press of an interface button that signals the door to be opened or closed. Or take one pick & placerobot that has three states: pick up, put down and the movement of the robot arm between these two states. The physics of that state of motion are not easy to describe and have a complex motion profile. This requires an advanced model. supermodels can add it to the state machine. But the basis remains the ‘simple’ state model. Scheifes: ‘Everyone understands the behavior of the state: something is on or off, you have to press a button to go to another state – we can review this with stakeholders from other disciplines. For the medicinal machine, for example, we all have pipes and instrumentation drawn, with valves, pressure vessels and so on. We reviewed its behavior in the model along with our process technologists. By their agreement, this also became the behavior we now see on the physical machine, after fine-tuning. ‘
Insightful, especially for software people
The strength of Sioux’s approach to MDD lies in the visualization, says Hendriksen. ‘Everyone understands the state machine by looking at the pictures you make of the model in Supermodels. However, the model simulations mainly yielded numbers. We can visualize the simulation of flow and pressure with colors, but with motion we did not yet have a solution for the moving mechanics. For this we have developed Holodeck, to visualize the mechanics in 3D and to represent what is happening physically. Many people see the whole 3D as a gimmick, but it is very insightful, especially for software people. Until now, mechanics have only given them static images: they had to do their best to understand them. Seeing the machine design in 3D already and not having to wait for the physical machine to see it move is hugely valuable for software development. ‘ But also for the development of mechanics, Scheifes adds. “It allows you to detect defects in the mechanical model before the relevant parts are ordered.” Hendriksen: ‘This way you can save a lot of time and money. Visualization gives you the interdisciplinary feedback loop very early in the process. ‘
‘In the past, the main mechanical focus was the electrical, and oh yes, a piece of software also needed’
Bad weather behavior
The advantage of MDD is that ‘bad weather behavior’ can also be modeled, Hendriksen continues. ‘On the one hand, you can use the state machine to give a good insight into what happens if the design does not work properly, and on the other hand, you can properly test bad weather behavior because you have a simulator. It is always much cheaper to break things in a simulator than in a real machine. Bad weather behavior is often underexposed; the customer tells what a machine should do, but not how it may fail. The development process must be adapted to this, eg by using an FMEA (fault condition and power analysis, ed.) and test the results. Supermodels offer the simulator for this. ‘ If it is so good that the control software no longer sees the difference between simulated and physical hardware, the software is no longer dependent on the physical hardware, Hendriksen explains. ‘You used to sit next to the machine and press the software to test it. So you had to wait for the hardware to come. This is no longer necessary and it provides all sorts of benefits. In this way, you have already solved the software integration issues before going to the hardware. ‘ Scheifes: ‘Masévon used to work very conventionally: mechanical was the main part, electric had to be added and oh yes, a piece of software also had to be used. We are now turning to a process where we are developing in parallel, and software is involved from the start. ‘
The advantage is that the first machine is on the floor at Masévon in a shorter time, because thanks to MDD, there are fewer software problems when building the machine. It ticks because in Masévon’s build to spec-branches many machines one of a kind is, or at least customer-specific, and is therefore still under development on the floor. Hendriksen: »In the past, the machine sometimes went to the customer within the contract period, while the software was not yet finished. Then it had to be tested after the machine had already been shipped. With MDD, it is no longer necessary, because then you can test earlier. ‘ MDD, including simulation, also provides benefits in the development phase, according to Scheifes. ‘Especially because you design more first time right due to the fact that you can continuously involve other disciplines. For example, if you notice that a sensor still needs to be placed somewhere, you can discuss this with electric. Or if a particular ratio is not good mechanically, you give it back immediately. It provides more peace of mind in the development department. You converge much faster to a proper design. ‘ Hendriksen: ‘The quality of your software is higher when you integrate it with the hardware. You can very quickly get to the real problem, which is getting the physics to work. On paper, you have come up with something, and the first time you put it together, you do not want to have to struggle with software errors. Of course they are still there, but thanks to reviews and simulations much less than before. ‘ By combining the logging with the visual models, they can also be tracked faster, Scheifes adds.
Culture change needed
Implementing MDD tools requires interdisciplinary work, and this still requires a culture change at Masévon, says Scheifes. Hendriksen thinks this is a little too modest. “You have already taken mega steps.” Scheifes: ‘But I always look at what else Masévon wants. Not only get the machine up and running with MDD, but also provide added value. For example, extracting data from the machine for analysis, to be able to tell when maintenance is required. Or play this data in your model when there is a problem in the field, to track the cause. ‘ Hendriksen: ‘Of course it affects the digital twin. Logging of all signals and state changes is now standard in our machine architecture. ‘
Not only data is now coming out of the machine, but also – so to speak – the documentation, Scheifes mentions as an advantage. ‘With MDD you generate documentation for the code as it really is in the machine. You used to use screenshots to paste the documentation together in Word, but it could be outdated if your colleague had changed the state’s behavior in the meantime. ‘
Slightly less uncertain
Hendriksen hopes to collaborate a lot with Masévon in the coming years. “They are now our biggest Supermodels ambassador. What they have done well is to involve domain specialists in the software development process.” Scheifes: ‘We are still in the start-up phase with MDD and we are still encountering things, but due to our good relationship with Sioux, these are being picked up quickly. You can develop a tool as well, the collaboration makes it strong. ‘people are working enthusiastically on it, and we still have lots of ideas that MDD can take up. In the long run, we as Masévon want to offer added value by adding things to the tool that also benefit Sioux.’
An important MDD feature that Sioux still wants to add is model controlHendriksen reports. ‘Not only to detect simple things such as stalemate in the software, but also to control the operation of complex components with their interfaces. In this way we can find even more errors at the higher level of abstraction in the software. ‘ That possibility appeals to Scheifes. ‘If you have the opportunity to also check software that has already been delivered, you no longer have to be afraid of making changes as before because you did not know what would happen then. It makes the lives of software engineers a little less uncertain. ‘