When people think of code generation, they often think of the automated and therefore quick generation of code that is already implicitly quality assured.
However, these hopes are not always met. Nevertheless, code generators offer advantages, particularly for manufacturers in regulated industries like the medical device industry.
A code generator is a software program that generates source code in a chosen programming language from:
The following example shows a model and the source code generated from it.
Code generators are used above all when boilerplate code has to be created, or the functionality of the code can be described well in a model.
A lot of development frameworks offer code generators, e.g., Ruby on Rails.
Code generators that, for a given database schema, generate the access classes for the standard CRUD operations or, for given business classes, write the data storage (persistence) code and the corresponding DDL commands, have proven to be useful, particularly when accessing databases.
In distributed systems, data must be serialized and deserialized, e.g., converted from objects to JSON, XML or proprietary binary formats and vice versa. The code for this can also be generated in full in many cases.
With regard to electronic signal processing, a lot of companies first develop the components using simulation tools, such as MATLAB/Simulink. After successful verification, the next development step is to create these solutions in hardware or/and software.
In the case of software, the obvious idea is to generate the source code directly from the model in the simulation tool. In fact, their manufacturers often offer corresponding options.
If these options are not good enough, the developers still have the option of developing their own (better) code generator. This code generator then either uses a simulation tool API or reads the model files created by the simulation tool.
A lot of the advantages of code generation are obvious, some are less obvious, and others are never really achieved in practice:
ISO 13485 requires manufacturers to:
Therefore, code generators are subject to validation requirements.
Read how these obligations can be met efficiently and in compliance with the standards in the article on computerized systems validation. Note that software validation is not limited to testing the developed software (as a black box). Learn more about the different definitions of the term validation in our video on verification and validation.
IEC 62304 offers manufacturers two options for handling the generated code:
Careful! The SOUP approach cannot be transferred directly to medical devices marketed in the USA, because the FDA employs the concept of OTS (off-the-shelf software). However, this does not cover self-developed or self-generated code. Read more about the similarities and differences between SOUP and OTS here to avoid problems during audits and inspections.
Manufacturers who want to generate software using code generators have to overcome some challenges. This section explains how to do this.
The fact that manufacturers have to comply with regulatory requirements detailed above should be obvious. Therefore, it is important to define a strategy for ensuring and demonstrating the quality of the code generator and the generated code at an early stage.
When defining this strategy, manufacturers should:
Important: It is often unclear which medical device projects the code generator will be used for when it is being developed. Therefore, risk-based development is difficult. Development should, therefore, satisfy at least the same requirements as the development of (critical) medical devices.
It is not just the regulatory requirements that lead to significant time and money being spent on developing code generators. They usually only make financial sense if the same generator can be used in several projects (several devices, several versions of a device).
Sometimes, license costs also have to be paid in addition to the labor costs.
Therefore, manufacturers should always also consider purchasing existing solutions. The following criteria can help when it comes to deciding whether to make or buy and when deciding between several (commercial) products:
If a manufacturer decides to develop a code generator itself, it must be able to pay for the expenses involved. The manufacturer must also be able to meet the challenges of software development and implement the software.
It is vital that you choose a description language (e.g., UML) suitable for modeling the domain in question. The notations differ for flow-based and state-based software development. Generating software for batch processing is different from generating software for continuous processing.
It would be helpful if the code generator could automatically detect inconsistencies and failures to comply with specifications and constraints and, therefore, validate the models. This requires these specifications and constraints to be formally described.
The more complex the models that the code generator creates, the more difficult it becomes to develop and also use them.
Some companies allow models to be supplemented by scripts and try to find a balance in this way. However, this starts a shift from software development in the target environment to software development in the modeling environment. This then brings with it all the regulatory challenges and requirements for quality assurance of models and scripts.
If the model does not allow the code to be generated in full, the developers must make additions to the “target software.” These areas must be protected against overwriting when the model is revised.
Changes to the model can, in the worst case, still result in the supplemented code not even compiling. This means that the target software – the generated and manually supplemented software – must be subject to a full quality assurance process.
In all cases, manufacturers should also use a version control system for the generated code.
Most graphical modeling tools use a hierarchical representation. This makes the models or sections of models appear less complex than they actually are. In contrast, the generated code is often so complex that meaningful quality assurance through code reviews and software unit tests is difficult.
Hierarchical structures are not necessarily modular structures. However, a component-oriented design is the prerequisite for the:
Code generation from models, just like artificial intelligence (AI), has already been through several summers of enthusiasm and winters of discontent. However, there is no doubt that a lot of companies will lose out in the long run if they completely refuse to embrace code generation.
It can be assumed that, in the future, directly executable models will overtake code generators in many areas.
The development and use of code generators require highly qualified experts. The requirements for abstraction capability are often higher than in other software projects.
A code generator, no matter how powerful, does not replace the ability to create models or the ability to develop product strategies. If you don't systematically collate customer requirements, code generation will only let you realize this a bit faster at best.
Companies have to make vital decisions:
There are no universal answers. You should seek advice from people who have experience in your specific application case. The team at the Johner Institut will be happy to arrange appropriate contacts.