Code generation put to the test: What are the most common pitfalls?

A code generator generates the source code of a programming language from an abstract description language (i.e.  a model). IMT has been using automatic code generation for many years. Since IMT is increasingly active in developing medical technology, many of the projects must meet high safety-critical requirements. The process of building high-integrity systems with automatic code generation has been optimized and brought to completion over the years. However, code generation and modeling activities are not excluded from making mistakes. That’s why we summarized the top 10 pitfalls that you should be aware of.

If the description language (or modeling language) is kept universal, it can tempt you to want to solve every conceivable problem with it. As an example, it’s not recommended to implement state-oriented logic with a flow-based approach or vice versa. Therefore, it is important that the options and strengths of the description language are taken into account for the software architecture and that code generation is only used where it really makes sense.

2. Architecture

Especially for large generated applications, it’s mandatory to have an appropriate and well-structured model architecture that is designed for future changes. This is not an easy task and it is often underestimated because a comprehensive model architecture including thousands of elements requires many years of experience. The challenge is that trained software architects must be familiar with the modeling language, or the modeling experts should learn the art of designing a software architecture.

3. Ignoring software engineering principles

It is doubtful that modeling including software code generation does not require any knowledge of software engineering. The creation of models requires the knowledge and application of certain basic principles. Principles such as strictness, structuring, abstraction, locality/privacy, and assumption of the need for change. However, the good news is, that these skills can be learned. But watch out, being too infatuated with software engineering can lead to another pitfall: excessive scripting.

4. Excessive scripting

Some modeling languages allow the use of scripts. For example, Simulink allows the integration of m-script or, as part of Stateflow®, the use of C syntax. Depending on personal preferences, this can lead to excessive use of the scripting language, even where a description in the modeling language would be useful. The problem with this is that you lose some benefits of code generation: Readability, maintainability, and inherent safety, which is given by the syntax of the modeling language.

5. Too big will fail

Due to the graphic representation of some modeling languages, hierarchically deep structures and dependencies are easily manageable. Hence, the pain caused by cyclomatic complexity is much lower compared to handwritten code which could lead to large and complex models. However, models that are too complex have disadvantages regarding testability, reusability, and traceability. Furthermore, such models also result in longer simulation, code generation, and compilation time of the generated code. From this point of view, thinking in terms of “functional units” is crucial for modeling (as it is important for handwritten code).

6. Interface to hand-written code

In the best case, changes are made within the model and not in the generated code. If the code generator does not support feeding back changes, it is not the best case but a must. You must ensure that the interfaces between the generated and the handwritten code are clearly defined to treat the generated code as a separate unit or section. Some of the code generators include comments like /*Do not change this section*/ in the generated code. Please respect them.

7. Missing guidelines

It seems to be obvious to have guidelines for handwritten code. However, for some individuals who switch to a code generator, this seems like a good opportunity to forego this nonsense. But almost everyone knows that guidelines are not there to make your life harder. Mostly they make sense and help to make your models more readable, maintainable, and in some cases also more reliable. If your teammates resist guidelines: just call them best practices. Anyway, it is best to develop guidelines in a team as joint work. And please don’t overdo it because guidelines (especially modeling style guidelines) should not be laws that can lead to consequences if they are not followed. So be patient and not too cautious.

8. Mnemic neglect of regulatory requirements

If code generation is used in a regulated environment, you should ensure that the corresponding requirements are considered at an early stage and not just after implementation. In the field of medical devices, ISO13485 requires that a code generator, which is involved in the development process, must be validated. Especially for large and complex code generators, that sounds like a lot of work. However if the quality of the generated code is assured (e.g., by testing the generated code), an extensive validation of the code generator is not necessarily required because the ISO13485 standard allows a risk-based assessment.

Furthermore, if the generated code is used in a medical device, it is also subject to IEC 62304. A successful strategy to be IEC 62304-compliant is to treat the generated code almost in the same way as handwritten code. However, some of the following measures may be unnecessary:

• Review of the generated Code because the models are already reviewed (hopefully).
• Checking against coding guidelines.
• Doing a detailed design of the generated code because it’s already done in the model.
• Depending on the code generator and its settings, a static code analysis may be not required. However, if no static code analysis is done, the code generator should be validated accordingly.

9. Datatypes

There are code generators that do not want to bother the user with the choice of explicit data types. What is meant well turns out to be unpleasant automatisms in practice, which can lead to losing control of the code. So, it makes sense that if the data types are specified explicitly in the model and they are unwanted, respectively automatically chosen data types, they are checked in the model or in the generated code. This avoids:

• Inefficient code
• Unexpected behavior of the application
• Compiler errors

However, a certain knowledge of data types is required (see 3. Ignoring software engineering principles)

10. Prejudice towards code generators

If code generators are used correctly, this is a wonderful thing. So, it would be the most serious mistake to forego the use of code generators due to prejudice. If you refuse to use code generators, you may miss out on many advantages:

• Faster time to market especially for control and signal processing applications. The combination of simulation and code generation allows a highly efficient development process called Model-Based Design. The controllers are designed mainly based on “Digital Twins” and therefore prevent multiple iterations with hardware prototypes in the development process.
• The maintenance of the product is more efficient because the models are easier to maintain due to their graphical representation and clarity. The training of new employees is usually limited to only a few days.
• It is easier to meet regulatory requirements because the models can be seen as a detailed software architecture and can be validated easily. Both, designing an architecture and the verification of the architecture, are explicitly required by IEC 62304.
• Increased independence from the runtime environment as the interface to peripheral systems is abstracted by the code generator. This allows quick and painless porting to different computing systems. Therefore, you are ready for the future and don’t have to be afraid of technological changes.

Code generators can bring devices faster to the market, simplify maintenance, support the fulfillment of regulatory requirements, and are considered to be future-proof. Nevertheless, there are some pitfalls when using code generators. An adoption must be carefully planned, and development processes should possibly be refined or changed.