Code Generation: The Magic Formula for Faster and Better Code?

b) Where are code generators used?

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.

Database access

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.

Stubs and skeletons

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.

Signal processing

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.

c) What benefits does code generation promise?

A lot of the advantages of code generation are obvious, some are less obvious, and others are never really achieved in practice:

• Faster (further) development of software
  Code generators can generate hundreds of thousands of lines of code every day, which is vastly more than any developer can manage. However, these generators shift the development from programming to modeling.
  Maintaining models is often easier than maintaining source code, as models allow for a quicker overview and are more independent of individuals’ “programming style.”
  Particularly in the case of hardware-related code, for example, in measuring and control technology, the linking of modeling and simulation significantly speeds up development. Most of the design is done using “digital twins”, which makes the costly and time-consuming development of numerous hardware prototypes unnecessary.
   
• Better code
  Models allow formal checks, e.g., of their consistency and compliance with constraints. 
  Code generators do not make careless mistakes either. They can automatically generate code that meets standard coding guidelines.
  Therefore, the generated code and its architecture are consistent and, ideally, already quality checked by the code generator.
   
• Simplified regulatory compliance
  One regulatory requirement (e.g., in the MDR Annex II, IEC 62304 section 5.3) requires manufacturers to describe and verify the software architecture. The models already comply with this documentation requirement. 
  They can also be better formally verified than is possible with text-based or document-based architecture descriptions. IEC 62304 requires verification of the software architecture.
  In addition, section 5.5 of IEC 62304 requires manufacturers to check whether the software code implements the architecture. This is automatically the case with generated code.
   
• Increased future viability
  Programming languages are constantly evolving. This means regular maintenance projects are required to ensure the software is compatible with new and “deprecated” APIs and language constructs and is, therefore, still state of the art.
  Generated code "only” requires the code generator to be adjusted, rather than whole software applications.
  In the long-term, manufacturers who use models have the option of not using code generators and running the models in appropriate runtime environments.

2. Regulatory requirements for code generation

a) Requirements of ISO 13485

ISO 13485 requires manufacturers to:

• Validate “the application of computer software used in the quality management system” (computerized systems validation)
• Validate “processes for production and service provision”, including “equipment qualification" and validation of the software used

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.

b) Requirements of IEC 62304

IEC 62304 offers manufacturers two options for handling the generated code:

1. The generated code is subject to the same quality assurance process as handwritten code. Some activities, such as static code analysis or code reviews, can be omitted under certain circumstances.
2. The generated code is classified as SOUP (software of unknown provenance). Therefore, manufacturers have to comply with the SOUP requirements (in section 5.3 among other places).

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.

3. Challenges of code generation

Manufacturers who want to generate software using code generators have to overcome some challenges. This section explains how to do this.

a) Regulatory requirements

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:

• Decide whether the generated code is considered SOUP
• Specify the verification of the model in the medical device development plan
• Specify the verification of the generated code in the medical device development plan
• Specify the requirements of the code generator before it is developed
• Describe the architecture of the code generator
• Verify the code generator software, e.g., through code reviews, static code analysis, or unit, integration and system tests
• Define these quality assurance measures before (!) developing the code generator

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.

b) Cost of creation and quality assurance

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.

c) Make or buy?

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:

• How well do the functional requirements fit? E.g., with regard to application area, modeling language, and target language (programming language) 
• The quality of the generated code (e.g., conformity with coding guidelines)
• The resulting dependence on the manufacturer of the code generator
• Price of the code generator
• Quality of the user documentation
• Ability to evaluate the quality of the code generator and the associated development processes, e.g., using development documents or supplier audits
• Availability and quality of support for the code generator
• Compliance with non-functional requirements, such as speed, stability, hardware requirements, operating system

d) Development of a code generator

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.

Choosing the description language

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.

Validation of models

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.

Balance between complexity and performance

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.

Synchronization of model and generated code

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.

e) Overcomplex models

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:

• Maintainability
• Reusability
• Testability and
• Replaceability of software components

4. Conclusion

a) There is no way around model-based development ...

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.

• The speed of development continues to increase thanks to the use of “digital twins.” Code generation is the ideal complement.
• The shortage of skilled workers is also becoming increasingly apparent in the world of software development. Therefore, it is important to support their work through automation.
• Device development cycles are becoming shorter and shorter. The drivers are the new technical possibilities, higher customer requirements, and agile process models. If a lot of iterative changes are going to be made to a product, automation and thus code generation make a lot of financial sense.

It can be assumed that, in the future, directly executable models will overtake code generators in many areas. 

b) … but "a fool with a tool is still a fool”

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.

c) A balance is necessary

Companies have to make vital decisions:

1. Do they want to use code generators?
2. For which products, projects, and components?
3. Should they develop or license a code generator?

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.