MDSD for Embedded Systems with Eclipse – the challenges

01/16/2008, Lünen

There is a diversified choice of tools for the development process of embedded systems, ranging from special solutions to universally applicable development environments. One of these very widespread development environments is MatLab/Simulink [1]. This environment offers model-based design and simulation of dynamic application flows and control systems. For the modeling of entire systems, development environments on the basis of UML and SysML such as Telelogic Rhapsody [2] are used. Special development environments such as ASCET tools [3] are applied in the development of control units in automotive engineering. If different tools need to be used in combination within the same development process, the models have to be easily exchangeable between the tools. In this case, the tool that suites the task most may be applied, so that the development process can be optimized. Otherwise the models of different tools might be inconsistent with each other, which can result in high costs and high risks in the field of security critical systems. Here, model-based software development can help to optimize the development process and to reduce costs and risks. The methods of model-based development help with the integration of different tool models and also with the simplification and automation of processing steps in development. In the field of Eclipse, a lot of tools exist which may be applied.

Tool Integration

Basically, two approaches are possible for the integration of different tool models: a collective model for all tools or the synchronization of all individual models. With a collective model, the specialized tool model is extracted by a model-to-model-transformation. After being processed with the tool, the changes in the specialized models are transformed back into the collective model. However, with the synchronization of individual models the changes undertaken in two respective models are directly propagated into the other model. Potential transformations are carried out during the propagation. Open programming interfaces are required for the integration, allowing access to the different tool models. Such integrations are often special solutions though, which are not offered by the tool producers and have to be tailor-made by third party providers. In the scope of Eclipse, model-to-model transformation can for example be carried out by Xtend from the project openArchitectureWare [4] or by the ATLAS Transformation Language [5].
Meta Modeling, DSLs and Editors
You can clearly see the “impending convergence of the worlds” when looking at the development of the modeling languages used by embedded systems. In the past, block circuit diagrams, the architecture analysis and design language (AADL), message sequence charts (MSC) or the specification and description language (SDL) were predominant. Today though, UML-based domain specific languages (DSL) and specialized languages as well as specialized languages such as SysML [6] for holistic systems engineering are being used. By the use of respective UML profiles, similar to the ones for SysML, AUTOSA or MARTE, the generally applicable UML2 can be specialized to a certain extend. In other profiles, which are derived from this, it is possible to perpetuate this to gain one’s end. However, textual DSLs are often used, since at the moment a lot of models for embedded systems are described on a low abstraction level close to the platform. This inevitably increases the level of detail and therefore complexity. On the other hand, textual DSLs are especially suited for gathering a lot of details. Graphical DSLs however are better suited for the visualization of structures, relations or application flows. As a result of this, it would bet the optimal solution to combine existing DSLs and the respective meta models and editors with own DSLs and to provide every stakeholder with the most suitable view (textual/graphical). For this, Eclipse offers the necessary basic tools in line with the Eclipse Modeling Project [7]. The Eclipse Modeling Framework (EMF) [8] has become a standard for meta modeling and models and is supported by existing editors. With the help of the Graphical Modeling Framework (GMF) [9], special graphical DSLs can be implemented. The alternative Topcased MF for graphical DSL originates from the TOPCASED project [10]. Xtext from the project openArchitectureWare [11] allows an easy creation of textual DSLs with corresponding editors and parser on the basis of grammars. Xtend, which is also part of the openArchitectureWare project, helps to extend meta models in a non-invasive way and to describe model transformations. This is particularly helpful when combining graphical and textual DSLs. Therefore, Eclipse helps to establish an appropriate mix of modeling languages and editors, ideally supporting the own domain. However, integration work is still necessary.

Validation and Verification

The very detailed and comprehensive embedded system models require an early automated control of their correctness, to be able to trace influences and to avoid unnecessary build, deploy or text cycles. The model’s underlying meta model can only partly secure the syntactical correctness of the model. Constraints in terms of the model editor’s liberty are only feasible to a certain extend. Some syntactical and especially semantical requirements to the model can neither be ensured by the meta model nor by special editors. This is why an explicit validation of the model via rules is required. In embedded system development, the rule kits necessary for a comprehensive review of the model are often very large. In practice, rule kits of up to 1,000 rules are not uncommon. The more complex and detailed the models are, the more comprehensive the rule kits are. The size of the rule kits crucially influences the performance of the validation. If the developer changes a model, he also quickly wants to know about their influence on the rest of the model. It is possible to save a lot of time by adjusting the rule kits to the respective situation. In a lot of cases it is not even necessary to check the entire rule kit. On the one hand, you might only want to check the rules linked to the changes, on the other hand you might want to carry out only specific rules showing effects on the model view you are looking at. Even for the development of product lines, which are very common in the field of embedded systems, different rule kits might be necessary for different products. A validation framework should meet the demands. In the field of Eclipse, EMF offers a validation component. The validation algorithm is already determined. The necessary rules can pretty easily be implemented in Java and the framework, so that a validation of the model is quickly available. Individual rules or entire groups of rules can be turned on and off by the user, which has advantageous effects on the performance. Besides the implementation of the rules in Java, the rules can also be expressed by the object constraint language (OCL), which is a part of the UML. Another possibility is an own, domain specific language, which helps the model user to define the rules independently and without knowledge in Java programming. Yet another alternative in Eclipse is Check from the openArchitectureWare project [4]. Check allows the validation of any model and does not – as it is the case with the EMF validation framework – depend on MOF compatible (or ECORE compatible) meta models. The integration of meta models from different existent tools, which was already described above, is advantageous especially in terms of the validation of the models. Relations between different models such as block circuit diagrams and state charts can automatically be tested for consistence by means of integration. The laborious and very error-prone manual consistence examination of the different models or the indemnification of the consistence through conventions is therefore superfluous. This means that the existing tools could be used much more efficiently. Especially for embedded systems the proof of security critical characteristics is often necessary for the admission of the systems. A formal proof of such characteristics is hardly possible on the code level of C or Assembler. However, a formal verification of models via model checking is gaining ground today. Tools such as Spin [11] or Uppaal originate from university research, but have also been used in practice before. Spin was already successfully used in several space missions, such as Deep Space 1, Cassini or the Mars Exploration Rover. It also allows the use of C code in the models to be verified. The newer tool Uppaal however supports the modeling, validation and verification of real-time systems on the basis of Timed Automata. However, there is a hitch: even if the model has been verified, the code generation still has to be checked for correctness. On top of this, the size of the models, which are today automatically verified with tools, is still quite restricted.

Relation Modeling, Simulation and Visualization

Relation modeling is of eminent importance for the development of embedded systems. Block circuit diagrams, state charts or message sequence charts are made use of [13] for example. Contrary to the development of application systems, real-time requirements have to be considered for embedded systems. To check the correctness it is possible to apply validations and delimited formal validations. Another way to verify and reflect is simulation. By using simulation the behavior described by the model is performed within the scope of scenarios. The more comprehensive a test on the target platform in the target environment is, the more important is the simulation. In extreme cases this may even be impossible, an example for this is the control of a satellite. With simulation, one has to distinguish between the simulation engine and the simulation frontend. While the engine preserves the scenario and the model and calculates the individual steps, the frontend provides a basis for visualization and interaction with the user, for example to change the scenario values or the simulation parameters or to inspect intermediate statuses. The visualization can be effectuated either in a model view or in a view adjusted to the target environment. In both cases, it is necessary for the engine and the frontend to communicate through a defined interface. This becomes very challenging once the simulation stretches across different diagram types. In the research project MDA4E [14] we have implemented this for the connection of block circuit diagrams and state charts. In doing so it became apparent that today’s editors for UML state charts do not provide a simulation interface. This is why the decision was taken to firstly make an own editor available with the help of GMF, to be able to gain experiences with the necessary simulation interface. As a result, controls can now be simulated, which are defined in block circuit diagrams. Individual blocks can be improved through state charts. The simulation can be made visible in the model editors or in a specially adjusted visualization. Consequently, it can be established that Eclipse already provides the necessary basic tools to create simulation frontends and to tie them to simulation engines. However, the Eclipse strategy regarding the way simulation interfaces should generally look like is still missing today. This cumbers the use of existing editors, which abundantly exist for standardized diagram types.

Code Generation

Code generation in the field of embedded systems and classical code generation in application development can only hardly be distinguished from each other. The necessary artifacts are generated from models, which are based on component standards such as e.g. Autosar [15] or MSR [16] in the automotive industry or SMP2 [17] and SMP [18] in the area of simulation. These are usually C or C++ code, header or configuration files. But certain requirements have to be met: as we have already seen in the chapter above, a correct model is not sufficient if the code generation is defective. Therefore, certification is an important topic when dealing with security critical systems. It is possible to either certificate the actually generated code or the code generation as such. For the certification of the generated code, processes for the measurement of code coverage through tests are used. The certification of the code generation itself is more complex, however it has only to be done once. As of today, processes for the verification of code generators are subject to research. Since there are a variety of target environments, product line development is an important topic. The code for the products differs in the target language used or in the hardware of the platform, in the libraries used or in pieces of the model, from which the code is generated. The code generation should support this without implying the obligation to develop specific code generators for each platform. For this, a modular template set-up used for code generation is helpful. As a result of this, the templates needed for the target platform can easily be chosen and put together. Modified templates reduce the effort also. Modifiability can be reached through aspect-oriented programming (AOP) for example, which integrates additional information in the templates in accordance with the respective target platform. Good approaches for the support of product line aspects are provided by Xpand from the project openArchitectureWare [19]. The hardware used in embedded systems is usually pretty restricted in terms of performance because of the necessity to lower the costs and the consumption of energy. Disk space and high processing speed are missing and for this reason the efficiency of the generated code is very important. The current belief that manually programmed code is efficient, is not true anymore. Sometimes generated code is even more efficient than programmed code. Code patterns for recurring constructs or specific adjustments of code generation to the target platform are helpful to optimize the code. To be able to use these optimizations for manual programming, the developers have to be trained comprehensively. However, this does still not guarantee that the developers actually use all means of optimization. Tools and code generation are widely spread. In the field of Eclipse, the all-purpose code generators JET [20] and openArchitectureWare Xpand [21] are used among others.

Conclusion

We already know many challenges of model driven development for embedded systems from the model driven development of application systems. Consequently, well-established methods and tools used in model driven development of application systems may be used successfully for this area. Especially Eclipse and the manifold commercial and non-commercial offers in the fields of editing, code generation, verification, validation as well as simulation allow a quick start with an integrated tool environment. However, there are still areas where special integration and adaptation is necessary. Notable examples for this are the integrated use of different meta models, DSLs and editors as well as the integration of simulation and verification engines.