Code-Generation for the Control of Medical Devices — Part 1

The code generation promises a lot: The development engineer graphically specifies the system behavior and generates programs for different target platforms from it without programming. In addition, documentation is generated and the program is statically analyzed in compliance with standards and tested at the model level. We have many years of experience with this approach, as well as with programming supported by other tools, and have found that the effort required to achieve the same quality does not necessarily decrease. In order to avoid software errors, to create complete documents and to perform all required tests, the entire processing chain must be traced, adapted and extended despite the support. In three parts we would like to give you an overview of code generation:

1. In this first part, we will present the goals of code generation and an overview of our experience.
2. In the second part we will discuss the advantages and disadvantages concretely using examples with C code and Simulink models and evaluate them with criteria.
3. In the last part we will give an overview of alternatives such as synchronous languages and discuss their use in medical engineering.

The focus of all parts is the question if and when code generation should be used in medical engineering.

The goal of model-based development and the associated generation of program texts is to relieve the engineer of repetitive work. Above all, he should be spared programming. Other examples of recurring tasks that directly affect code generation are:

• simulation of physical systems with integrators, transfer functions and similar subsystems,
• use of logical operations, bit operations and mathematical functions,
• creation of table lookup programs,
• integration of control structures and state machines and
• fixed-point arithmetic.

In addition, the following tasks should also be supported:

• display of signals and variables during development,
• generation of documentation (with traceability),
• porting to different target platforms and
• performing static checks and tests at the unit level and for the overall system.

We have used Simulink for code generation in various projects. In addition to software for medical devices, we developed control software for test benches. The development tool can be roughly understood as a graphical editor of the call tree of a program. In the main view, blocks are stored whose parameters can be changed via input masks. Between them arrows specify the signal flow. Blocks can either be taken from a library or defined by a graphical interconnection of partial functions. The second view of the resulting hierarchy is a text-based tree view with a table editor that can be used to edit variables and parameters of all subsystems. In addition, a programming interface for model manipulation is available. If mainly common functions from the supplied or the own library are used, an executable program can be specified quickly, which can be tested in the simulation environment. In addition, the Embedded Coder can be used to generate C code for embedded systems. This means that the program can be integrated into medical devices and test benches, among other things. In order to obtain a safe medical product, the following steps were required during the development of the control software for a cardiac support system:

1. Requirements, architecture and design were documented without the supplied report generator.
2. The control core function was modeled and tested in simulations.
3. Development-accompanying tests with the hardware were carried out.
4. Interfaces, program logic and state machines were added.
5. The data types were converted for fixed point arithmetic.
6. A separate tool was programmed for unit and integration tests, which generates the models for different tests and the necessary documents. Review results are also managed and logged with this tool.
7. An equivalence test on the target hardware was performed.
8. Static model analysis has been performed.
9. We went through the Matlab bug list to eliminate or work around dangerous constructs.
10. An additional module was implemented in C for testing the requirements with the cardiac assist system drive. Variables can be read with it, manipulated and sent to a Python program via the CAN bus.

The following figure illustrates the relationship between the resulting specification documents, the created software and the verification documents.

This brief overview already shows that not all the advantages of automation can be exploited in many places. It is therefore worth discussing the advantages and disadvantages using concrete examples and then evaluating them on the basis of criteria relevant to medical devices. We will present both steps in the second part of this three-part article. The third part will deal with other alternatives such as synchronous languages.