Device-independent code with model-based design

In model-based design, developers usually work with a simulated model using visual tools. They model software functions instead of writing code and create a visual model of both the software and the environments in which the software works. At this stage of development the software is in a kind of bubble – separated from the outside reality.

It also means that when software is developed using model-based design, it is device-independent, and this independence creates all kinds of possibilities for developing new products.

Model-based design enables you, in principle, to work on a model without a defined system, so it is not dependant on the device it will eventually be put into. The model can be prepared to the point where it is almost completely ready and has already been tested several times before going anywhere near the device and environment in which it will eventually be used.

Combining the software with the device requires a separate process of integration. And this can – at least in theory – be done in any suitable environment. For example a drive transmission control unit for one machine could be integrated in another similar machine regardless of the manufacturer.

Device-independent code can of course be generated when working in the traditional way too. It is not exclusive to model-based design, but in model-based design the software-specific functions are tested virtually as their own entities and without the device. This means that the functions are principally device-independent in model-based design code.

There are usually many unknown factors when developing something new, be it the control unit of an electronic engine, a mobile machine, a factory production line, or something completely new and amazing. These unknown factors are often related to mechanical functions, actuators, and sensors in the final environment, which are directly reflected in the requirements set for the software. For example, the frequency and amplitude of a machine’s mechanical vibration will significantly affect the position sensor’s signal and the requirements set for filtering.

With model-based design the functions in the system being developed can be brought very close to their final state in a virtual context before the precise properties of its components are even known. This means that the requirements for the measurements and functions of components can be set according to the model. The software will also tend more towards device independency when the design is based more on the functions than the components of the system.

Let’s say that the assignment is to develop a new kind of forestry machine that has significantly different functions to previous models. If its control unit is developed through model-based design, the components needed can be defined at the same time as creating the new features – e.g., the size of the diesel engine for the machine. In this kind of situation the development can be happening simultaneously on many different levels: the mechanics, hydraulics, and electronics of the machine can be developed simultaneously with the control unit functions. In this way, simulations can be run to see whether the control unit can optimise the use of power in a certain situation, or what it would be like, for instance, if the diesel engine was downsized, or a hybrid energy solution used instead.

Being able to perform more than one task at the same time naturally means the final completion date for the product will come sooner than it would traditionally – and the model-based design usually allows for development methods to be iterative as well as agile.

In a traditional product development model, one part of a design usually has to be finished – or nearly finished – before going on to the next. Model-based design allows these phases to be started earlier, as often just a crude model will provide enough information to initiate the next stage. 

As we mentioned in our earlier blog article, model-based design combines coding and design in the same phase and – bearing in mind it also offers simultaneous feedback for the requirements of the device itself – it seems pretty clear which is the quickest way to a finished product.

The good thing about device-independent code is there is more room for effective choices to be made at the product development stage. The design can be made at a more abstract level because it is not limited by the hardware. When the software is device-independent, and only integrated to the chosen device environment at the end, the software will usually function as required.

In this way the functions are developed with the desired features in mind, and not according to the device’s limitations.

• When software is developed through model-based design, the software is device-independent.
• At the same time the model-based design or simulations related to can provide valuable feedback for designing the final device that the software is to be integrated with. Above all, it ensures that the device’s engine will be the correct size for its  intended uses.

The simulations mentioned above mean that, when it comes to testing in the final environment, they are less stressful and this is a good thing.

At its worst, testing in the final device environment can be extremely slow and expensive, because a testing machine is not always easy to come by; and if there is only one available, the tests can only be run one at a time. Also, if there are any shortcomings detected in the software at this stage, it can set the product development timetable back significantly.

In model-based design, the usability of the software will have already been through thousands of simulations, in thousands of different ways – all long before the software comes anywhere near the  environment of the destination device.

This will:

• Lessen the likelihood of surprising setbacks
• Reduce the costs of design or execution mistakes
• Allow product development to focus on functionality rather than interfaces or components
• Shorten the overall time to completion

Model-based design and device-independency enable effective product development even in

• Situations where it is not yet clear how the desired product can be built
• Situations where someone says that it just cannot be done

These are the kinds of situation where we are at our strongest.

Miika Ahopelto graduated from Tampere University with a degree in software technology and machine automation. Miika has had several years experience in the demanding field of designing software for mobile machines and non-road equipment. Miika can be reached at miika.ahopelto@devecto.com.