Merging mechatronic systems engineering and software engineering

Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13

Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13

Author:

Reading time: 5 minutes

Model-based design is a powerful method for developing high-tech products and systems. Traditionally at Demcon, the mechatronic systems engineer took the lead in developing the model, but the software engineer turned out to be indispensable in defining a software architecture that resulted in efficient and maintainable control code generated by that model. Therefore, over the years, both disciplines have come together.

Broadly, the multidisciplinary interpretation of mechatronics at Demcon has software playing a crucial role across the entire spectrum, from embedded control to the graphical user interface. Software engineering isn’t limited to programming hardware and interface controls and signal processing algorithms but starts with the definition of the system architecture. In close collaboration with the mechatronic systems engineers, our software engineers also work with ‘languages’ such as Matlab/Simulink, for model-based system design and control, and Labview, for data acquisition and signal processing.

In the early years of model-based design at Demcon, it was mainly the mechatronic systems engineers who ‘programmed’ in Simulink. The advantages of this are that all the engineers involved in a project can ‘read the model’ and it allows for reusing architecture blocks. The mechatronic systems engineers used to focus on functionality, but they had no insight into state flows and interaction with the hardware. Nor did they have a good eye for the efficiency of software engineering in a broader sense, including testability and maintainability, as well as performance in the case of time-critical processes.

The generalized software architecture that has emerged from the experience with model-based design in a number of projects in which the degree of automatic code generation varied between 0 and 100 percent. The resulting architecture reflects the balance between simplicity, control of the required behavior and the benefits of model-based design.

Demcon’s version of the V model for model-based design, as applied to the development of a medical ventilator.

That’s why we decided to merge the disciplines of mechatronic systems engineering and software engineering and to grow model-based design into model-based engineering. Thus, design, implementation and testing now form a continuous model-based chain following the V model. In mechatronic systems engineering, we’ve already been using this model (requirements, concept, design, realization, integration, testing, verification and validation) for a long time. Depending on the nature of a development project (proof-of-principle, prototype or pre-production), we go through this model once, twice or three times, each time with a broader scope.

In software engineering, we use the Agile/Scrum approach for software-only projects, but in combination with hardware development, the continuous delivery strategy of Agile doesn’t work. A design, especially for a life-critical medical application, should be fixed for longer periods of time to protect safety and reliability (which of course are also paramount in other applications). We do, however, draw on the Agile/Scrum toolkit – for example, the daily stand-ups – and we can divide the software development within a ‘leg’ of the V into sprints.

Healthy curiosity

“I studied biomedical engineering and then focused on model-based design for the development of various equipment, including a 3D printer,” says Irene Kaashoek, a software engineer at Demcon. “Five years ago, I joined Demcon Macawi Respiratory Systems, returning to a biomedical application. As a mechatronic systems engineer, I became responsible for generating the ventilation algorithms for the controller, based on requirements that the customer and I defined together: to set the pressure and flow profile for ventilation, respond to what the patient is doing and monitor their safety. I translated that into a model with sensor inputs, user settings and desired actuator outputs. I generated the code with Simulink and after initial testing on a model of the hardware – ventilation system and patient – I could then test it with rapid prototyping on the physical hardware. The biggest challenge was and is to create a safe situation for the patient while using a limited number of sensors.”

Kaashoek discovered that the quality of the software generated isn’t only determined by the requirements for the controller and the logic in the state machines, but also by the architecture of the software. “If you, for example, don’t think carefully about where responsibilities should be placed in the software, you can create ‘spaghetti’ in Simulink. The code then becomes inefficient, unclear and difficult to maintain. Therefore, I started to learn more about software architecture and also about programming in C/C++. That’s how I turned into a software engineer. Now I consider the architecture of the software, ensuring a clear structure and predictable and efficient performance. The mechatronic systems engineer is ultimately responsible for testing the controller, but as a software engineer, I can provide good support by drawing on my system background.”

A typical Demcon Macawi Respiratory Systems product: an OEM respiratory module. The majority of the development effort is in the software, for patient safety among other things.

“The biggest challenges today are in the software,” adds Pieter Bijleveld, a software architect at Demcon. “Demcon Macawi uses embedded chips because it gives us access to the hardware layer and allows bare-metal programming of the interface so that we can also test and understand what’s happening. The alternative is an application chip, but there’s much more needed for that, such as an operating system, and therefore you have to test a lot more, especially for life-critical medical applications such as those at Macawi. We prefer to avoid that extra effort, hence the choice of an embedded chip. However, it’s relatively small, so you have to manage memory usage well and also safeguard the timing.”

“As a software architect, I’m in close contact with the mechatronic systems engineer and I always invite them into our ‘kitchen’,” Bijleveld explains. “They don’t need to be able to write C/C++ code themselves, but if they learn to use Python and make scripts with it, the leap to C/C++ is easy and they can read that code. Then they can see for themselves how we have to adjust the software to make it more efficient. A healthy curiosity about each other’s discipline helps to understand what the other person is doing. I’m not especially interested in the software itself, but more in what it should ultimately do, ie run a machine. That interaction between software and system makes testing so much fun; you see something moving and then something happens.”

Functional FPGA programming

Regarding the platform on which the software will run, FPGAs are an excellent option for mission-critical software, because they’re deterministic and they don’t work with dependencies. A fresh impulse for us comes from Qbaylogic, a University of Twente spin-off in which Demcon has recently acquired a share. Qbaylogic has developed a new hardware description language for FPGAs, called Clash, as an alternative/supplement to the low-level languages VHDL and (System) Verilog.
Clash is intended for functionally programming FPGAs at a higher level of abstraction, describing the structure or architecture of an application in terms of the desired functionality. It automatically translates the functional design into the actual hardware programming in VHDL or (System) Verilog. Thus, for example, computational operations can be programmed in parallel, while the classical languages work sequentially, and therefore only extract half the maximum performance from an FPGA. With Clash, you can squeeze the most out of it, which makes the resulting architecture cheaper, faster and more energy-efficient. In addition, a program can be tested more quickly and easily than with, for example, VHDL.

Healthy curiosity

Latest News