Product developers are constantly facing pressure to solve significant, often first-of-type problems, that can soak up large amounts of your time and budget. This situation can be even more challenging when developing safety-critical devices, such as those used on medical projects in mechanical circulatory support (MCS).
When pushing beyond the boundaries of what has been done previously, you potentially need to fail quickly. This allows you to learn what works and what doesn’t while there is still time (and money) to try again.
Even if it has been done before, code generation – in which a tool converts the representation of a system such as block diagram or state machine, into source code that implements the modelled behaviour, – is an ideal tool for enabling faster de-risking and progression of your project.
How code generation differs to traditional models of control systems development
To understand where code generation best fits in control systems development, it helps to compare it with typical approaches.
Software-based control systems and algorithms have often been developed in one of the following ways:
A subject matter expert develops a model of the control system and the system to be controlled. This could be via MATLAB (or equivalent), Simulink, a set of equations, or a spreadsheet. This is handed to a developer who then writes some code for an embedded device which hopefully matches that model.
After some discussion and perhaps writing some requirements, a software developer develops some software which then grows organically with the control system.
Extensive time is spent translating the control system into requirements and design. Software is written, integrated, and verified against requirements. When it comes to validation at the end, it may or may not solve the original problem.
Code generation from toolsets such as Simulink (MathWorks) has been an alternative for some time. Using code generation allows the control system to be modeled, simulated, and tuned in an environment much more fitting than embedded C code. C code can then be generated and deployed on the device of your choice.
Perceived barriers to code generation’s use
Despite these advantages, take up has been patchy. I think a large part of the resistance is due to three factors:
Software developers are most comfortable writing software, and many don’t have time to learn something new in their already busy schedules.
The perceived barrier to entry in terms of ramp up time and effort and the costs involved in software licenses.
Bad experiences with monolithic code generation models that purportedly replace all your development tools and promise to cut development time by half but turn out to be a nightmare because they are so big and unwieldy.
Advantages of code generation: the rapid prototyping example
Rapid prototyping, however, is one area where we can see three immediate benefits from code generation.
When used by the right person, the right tools with the right toolboxes allow for great speed of development. Unlike hand-writing code to assess results of various inputs, code generation offers the ‘drag and drop’ speed and simplicity normally associated with applications such as PowerPoint slides.
Need an FFT? It’s as simple as ‘Click-drag-done’.
BPSK modulation? Again, simply ‘Click-drag-done’.
The ability to simulate the system under control (known as the ‘plant’) allows multiple iterations of the control system before writing a single line of code. Developing, testing, and tuning your control system in parallel to the firmware and electronics (hardware) can greatly reduce the overall length of your program.
Code generation bridges the language gap between team members from different disciplines.
For most people, a graphical model of a control system and the system response (such as that featured in Hydrix’s LUDO product shown below) is much easier to understand and communicate across software, electronics, mechanical and scientific disciplines than either software code or mathematical formulas.
Image: A graphical model is typically much easier to understand and communicate than software code or mathematical formulas
4. Separation of Concerns
The separation of concerns (SoC) concept dates back to the 1970s but is even more relevant today. In the context of software architecture, everything should do one thing well and completely and fit in the context of the overall solution.
While you could generate the entire application, including drivers, interfaces, and business logic, code generation often works best when limited to the one thing it is most suited to – in this case, the control system.
This separation leads to a clear decomposition of your firmware between the algorithm (with a defined interface) and the rest of the infrastructure, state machine, and firmware drivers. With a good framework and BSP (board support package), you can quickly build a prototype from reusable parts, allowing multiple iterations of the control system to be easily integrated and tested.
The control system can then be developed with the right tools by the right person – not necessarily someone with the skills to write real-time embedded software.
The danger of prototypes
Prototypes are a double-edged sword. They help prove out an idea, identify and reduce key risks, provide a basis for user testing, and much more – before you sink all your time and money into a project.
This is particularly valuable in regulated and safety-critical industries such as medical, mining, and transport. Proceeding without appropriate prototypes can lead to major issues down the long road of product development. But how many times does a more-or-less working prototype then become “just tidy that up and ship-it!” to well-meaning management or investors?
Garbage in, garbage out certainly applies in the case where a bad model is not improved by code generation. However, it is often easier, faster and more cost-effective to refactor a model through code generation than via an organically grown C code implementation.
Modern code generation actively supports taking generated code through the full device life cycle and certification with tool qualification, reference workflows, and support for traceability and verification, making it a viable path to achieving a quality final product as well. This includes safety-critical projects required to adhere to standards including IEC 61508, IEC 62304 (Medical), and EN 50128 (Rail).
Code generation for rapid prototyping of pump control systems
Hydrix’s LUDO platform is an example of how code generation can work in practice for safety critical applications. LUDO is a customisable plug-and-play platform that is used by customers to design and develop new MCS pump systems.
The use of code generation through Simulink enables LUDO to run complex pump control system prototype algorithms quickly and efficiently. Testing different algorithms would normally take weeks using hand-written code. By generating code to replace various specific logic inputs, it is possible to run the same tests within a few days.
The flexibility of a model based approach to code generation has allowed the same platform to be applied by several MCS developers across widely differing pump technologies and control algorithms (including rotary and reciprocating devices driven via electric motors, pneumatics or hydraulics), in an accelerated timeframe. Moreover, the use of proven model elements means that the control system generated is both consistent and safe.
From research programs and refinement right through to operational system development, code generation techniques can simplify the process, enabling developers to remain focused on their core technology challenges.