EN 
DE Variants, possibilities and limitations
Authors: Horatiu O. Pilsan, Robert Amann, FH Vorarlberg
Contribution – Embedded Software Engineering Congress 2015
Code generation is an essential part of a model-based development process. This presentation provides key information about what to expect and what not to expect from code generation in embedded systems. Starting with the foundation—the (structural, process, or controller) model—the presentation examines the differences between various approaches (signal flow and control flow, time-based and event-based). The necessary runtime systems are analyzed, and their potential interactions within a complete system are considered.
The purpose of modeling, simulation, and code generation
Modeling is an inherent element of human thinking. It is a method that each of us uses to handle complexity. Lt. Bran Selic says, „“A human defense mechanism for coping with overwhelming complexity” (see [1]). We all model, often without being aware of it. Explicit modeling means a formalized representation that enables a shared understanding. This means that conventions are followed that are familiar to those using the model. An example of this is the legend (convention) of a city map (model). This results in the well-known advantages for communication, documentation, handover, training, etc.
Furthermore, modeling is the basis for simulation, which is why the terms are often used together. Despite its importance and widespread use, simulation will not be discussed in detail here.
But models are also the starting point for code generation. Their usefulness can be essentially illustrated by the following three points:
- The effort and time required for implementation can be reduced.
- The model and code can be kept (more easily) synchronized.
- The number of errors in the code can be reduced.
This article refers only to those models and their code generation where the generated code runs on the embedded system. For example, it does not address the generation of code necessary for hardware-in-the-loop execution, which is required to run the models simulating the environment of an embedded system quasi-continuously on a computer. For details, see, for example, [2].
The great importance of verifying and validating the models is also not addressed. Some principles regarding this can be found, for example, in [3] and [4].
The following three subsections describe the types of models relevant for code generation, the generated code and any runtime systems, before outlining similarities, differences and limitations.
Structural models
Structural models are very well suited to representing the division (logical, physical, etc.) of a software system into elements and the relationships between them. These models are static because they do not describe behavior. Therefore, they are not created for simulation purposes but primarily serve to represent a software system. For such models, for example, some diagrams from the Unified Modeling Language (UML) can be used, with the class diagram being the most widely used.
Numerous modeling software packages offer the ability to generate code from structural models. The most well-known example is the UML class diagram. The result is a code framework with constructors/destructors and methods/operations in the chosen programming language, e.g., C++. The part of the code that implements the behavior can then be inserted either in the model or directly into the code. The major advantage of this approach lies in the simplified synchronization between model and code. Many tools support round-trip engineering, which ensures this synchronization. A runtime system is not required in this case.
Time-based behavioral models
Time-based behavioral models originate from the term "System Dynamics," coined by Professor Jay Forrester of the Massachusetts Institute of Technology in the mid-1950s (see [5], p. 38). Feedback loops, which form the "heart" of every system, are crucial. The model is essentially a representation of the resulting differential-algebraic systems of equations. Thus, simulation also involves the numerical solution of these systems of equations. Time is modeled both continuously to describe the behavior of the systems (e.g., a controlled system) and discretely for the behavior of the computer-based control (e.g., a controller). Since the connections between the elements in such models are represented as signals, as in Fig. 1 (see PDFTo illustrate this point, one can also speak of signal-based systems.
In signal-based systems, code generation means converting the algorithms (e.g., controllers) into a programming language, usually C. Before code generation, these components must be time-discretized. For correct execution, it is essential to adhere to the correct timing. This typically requires cyclically repeating behavior based on a time-based runtime system. A common example is a real-time operating system that uses preemptive priority-based scheduling. Thread priorities are assigned using the rate-monotonic method. This means that a thread has a higher priority the shorter its period, thus favoring faster processes. In most cases, the period also serves as the deadline by which the thread must be completed.
Event-based behavioral models
In contrast, event-based behavioral models describe processes, sequences, or workflows in which events serve as triggers for actions. The term "Discrete Event Modeling/Simulation" is often used in this context. A good example of this is state machine models, which can be represented using UML state diagrams, as shown in Figure 2 (see Figure 2). PDFThis is illustrated by an example. The behavior of an automaton is determined by the fact that a transition is triggered as a consequence of an event, which on the one hand changes the state of the system and on the other hand executes actions. The term control-flow-based systems is equally valid for such models. In this case, simulation means replicating the behavior of the system after the occurrence of an event.
In the case of event-driven systems, the runtime system plays a crucial role. An example of this is a state machine, which enables the execution of the behavior modeled with a UML state diagram. This is illustrated in Figure 3 (see...). PDFThe principle shown in Figure 3 uses an event dispatcher and an event queue and follows the run-to-completion paradigm, as recommended in the UML specification (see [3], pp. 314f): The dispatcher only regains control of the system after all actions of the triggered transition have been fully processed. In this case, time is defined as cyclic events or delays. These are also modeled as events and implemented using operating system timers. The run-to-completion paradigm has the advantage that the behavior of the automaton is clearly defined and can be implemented relatively easily. To avoid real-time problems, it may be necessary for multiple automata to be active in parallel threads, as shown in Figure 3 (see Figure 3). PDF) shown as an example.
For code generation
Code generation has certain characteristics and limitations that must be considered, and there are common misunderstandings that need to be addressed. There are hardly any models from which code has been generated that are executable without requiring the user to insert additional code. The behavior of the system must be described in some way, and the connection to the hardware must be defined. Signal-based systems can function without additional code because the behavior is defined, for example, in the controller. If the inputs and outputs are also directly available as blocks in the modeling tool, the hardware connection is also established. However, with event-based systems, the actions to be performed must be specified. This is usually done in a high-level language. The connection to the hardware is also established there. Furthermore, users will inevitably have to connect the model or the generated code to other components, such as communication modules. These are almost always present and cannot be represented in the modeling tools.
The quality of the generated code is crucial for its usability. Efficiency is paramount. Questions such as:„How resource-intensive are code generators?„, „Can the generated code be used in a production environment?„, „Are fixed-point types supported instead of floating-point types?“These questions are becoming increasingly easier to answer in terms of using code generators. However, it's important to consider the overall picture, including not only the code itself but also the runtime systems.
The readability of the generated code is also an important quality criterion, especially when the result needs to interact with other code or when code snippets need to be inserted (which is not necessarily recommended). Tool support is inconsistent. It is crucial that the tools support the simulation of the relevant behavior, as only then can code generation be used productively in the development process.
UML tools support structure- and event-based models, while time- and event-based models are supported by tools such as MATLAB. The description of the runtime systems reveals that their interaction within an embedded system is not straightforward due to their differing operating principles. Although the tools often provide blocks for this purpose, and the real-time operating system used is the same, it's important to note that the coupling will result in timing behavior that depends on the implementation of the runtime systems.
Conclusion
Code generation is useful and makes sense, though not without limitations. The purpose of this article is not to discourage anyone from using it, but to highlight characteristics that should be considered.
Because of the differences between the variants, it is absolutely necessary to analyze the application precisely in order to determine the optimal use of code generation.
Bibliography and list of sources
[2] Michael Glöckler „Simulation of mechatronic systems. Fundamentals and technical application“, Springer Vieweg, 2014
[3] https://www.informs-sim.org/wsc11papers/016.pdf
[4] https://www.ltas-vis.ulg.ac.be/cmsms/uploads/File/LosAlamos_VerificationValidation.pdf
[5] Andrei Borshchev “The Big Book of Simulation Modeling: Multimethod Modeling with Anylogic 6” Anylogic North America, 2013
[6] https://www.omg.org/spec/UML/2.5/PDF/
Modeling – MicroConsult Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of modeling/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Modeling – Expertise
Valuable expertise in modeling/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
