Model-driven software development for embedded systems with Eclipse
Zusammenfassung
This article shows how, starting today, you can use model- driven software development (MDSD) with Eclipse to improve design methods and tools continuously. MDSD focuses on the systematic use of models throughout the whole engineering life-cycle, as a source for the generation of code, configuration of data, documentation and tests.
The embedded system developers of today face new challenges as the amount of software in embedded systems increases. Time tomarket is becoming shorter, complexity is increasing and component standards as well as design and architecture patterns are also becoming more important. In parallel, quality should be improving. No one is in any doubt that to meet these challenges, development methods and tools must be improved. The European Union for example initiated ARTEMIS exactly for that purpose. ARTEMIS is the embedded systems R&D programme in Europe.One focal point is on design methods and tools.
ARTEMIS research into design methods and tools for embedded systems is motivated and guided by the following targets for embedded systems development: reduce the cost of system design by 50%; achieve 50% reduction in development cycles;manage a complexity increase of 100% with 20% effort reduction; reduce by 50% the effort and time required for re-validation and re-certification; achieve cross-industry reusability of embedded systems devices. So the question is, do we have to wait for the results? The answer is clearly no. You can start today and improve methods and tools continuously. This article shows how you can use model-driven software development (MDSD) with Eclipse for that purpose. MDSD focuses on the systematic use of models throughout the whole engineering lifecycle.Models are used as a source for the generation of code, configuration of data, documentation and tests. They also allow for the early identification of mistakes through validation, formal verification or simulation.
Many developers know Eclipse as an integrated development environment for C/C++ or Java, however Eclipse is much more than that. If you look at http://www.eclipse.org Eclipse, you will find that “Eclipse is an open source community whose projects are focused on building an open development platform comprised of extensible frameworks, tools and run-times for building, deploying andmanaging software across the lifecycle.A large and vibrant ecosystem of major technology vendors, innovative start-ups, universities, research institutions and individuals extend, complement and support the Eclipse platform”. Additionally, the Eclipse modelling project with its subprojects gives you a strong support forMDSD. Surely, you cannot throw away all your existing tools and radically change your development methods, especially while existing modelling tools have to be integrated. MDSD should therefore integrate with the existing design methods too.
Basically, two approaches are possible for the integration of different tool models: a collective model for all tools, or the synchronization of all individualmodels.With a collectivemodel, the specialized toolmodel is extracted by amodelto- 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 individualmodels, the changes undertaken in two respective models are directly propagated into the othermodel. 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 often need special solutions, although they 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 fromthe project openArchitectureWare or by the ATLAS transformation language.
In the past, block diagrams, the architecture analysis and design language (AADL),message sequence charts (MSC) or the specification and description language (SDL) were predominant. Today though, domain specific languages (DSL) as well as UML-based languages such as SysML for holistic systems engineering are becoming more important. By the use of respective UML profiles, the general-purpose language UML can be specialized to a certain extent. In other profiles that derive fromthis, it is possible to perpetuate this tomeet one’s end. If you require evenmore specializedmodelling languages then DSLs come into place. They can be expressed with graphical or textual notation. Textual DSLs are commonly used, since many models for embedded systems are currently described on a low abstraction level close to the platform. This inevitably increases the level of detail and therefore the complexity. Textual DSLs are especially suited for gathering a lot of details. Graphical DSLs however are better suited for the visualization of structures, relations or flows.As a result of this, the optimal solution would combine existing DSLs and their respectivemetamodels and editors with its own DSLs, therefore providing every stakeholder with themost suitable view (textual/graphical).
For this purpose, Eclipse offers the necessary basic tools in line with the Eclipse modelling project. The Eclipse modelling framework (EMF) has become a standard for meta modelling and models and is supported by a large variety of existing editors.With the help of the graphicalmodelling framework (GMF), special graphical DSLs can be implemented. Xtext fromopenArchitectureWare allows for the easy creation of textual DSLs with corresponding editors and parsers on the basis of grammars. Xtend, which is also part of the openArchitectureWare project, helps to extendmetamodels in a non-invasive way and to describe model transformations. This is particularly helpful when combining graphical and textual DSLs. Eclipse therefore helps to establish an appropriatemix of modelling languages and editors, ideally supporting its own domain. However, integration work is still necessary. The highly detailed and comprehensive embedded system models require an early automated control of their correctness in order to be able to trace influences and to avoid unnecessary build, deploy or test cycles. The underlying meta model can only partly secure the syntactical correctness of themodel.Constraints in terms of the liberty of the model editor are only feasible to a certain extent. 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.
Themore complex and detailed themodels are, the more comprehensive the rule kits have to be. The size of the rule kits crucially influences the performance of the validation. If the developer changes amodel, 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 many cases it is not even necessary to check the entire rule kit.On one hand, youmight only want to check the rules linked to the changes and on the other 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 kitsmight be necessary for different products.A validation framework shouldmeet the demands.
In the field of Eclipse, EMF offers a validation component. The validation algorithmis 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 any knowledge in Java programming. Yet another alternative in Eclipse is Check fromthe openArchitectureWare project . Check allows for the validation of any model and does not – as it is the case with the EMF validation framework – depend onMOF compatible meta models. The integration of meta models fromdifferent existent tools, which has already been described, 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 consistency by means of integration. The laborious and very errorprone manual consistence examination of the different models or the indemnification of the consistence through conventions is therefore superfluous. Thismeans 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 originate from university research, but have also been used in practice before. Spin has already been successfully used in several space missions, such as Deep Space 1, Cassini or the Mars Exploration Rover. It also allows for the use of C code in themodels to be verified.However, there is a hitch: even if themodel 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.
Another way to verify and reflect modelled behaviour is simulation. By using simulation the behaviour described by the model is performed within the scope of scenarios. Themore comprehensive a test on the target platform in the target environment is, themore important is the simulation. In extreme cases this may even be impossible; an example of this is the control of a satellite.With simulation, one has to distinguish between the simulation engine and the simulation front end.While the engine preserves the scenario and the model, and calculates the individual steps, the front end 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 effectual in either a model view or in a view adjusted to the target environment. In both cases, it is necessary for the engine and the front end to communicate through a defined interface. This becomes very challenging once the simulation stretches across different diagramtypes. In the research projectMDA4E we have implemented this for the connection of block circuit diagrams and state charts. In doing so, it became apparent that editors for UML state charts do not provide a simulation interface. This is why the decision was taken to initially make an own editor available with the help of GMF, to be able to gain experience 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 front ends and to tie them to simulation engines. However, the Eclipse strategy regarding what simulation interfaces should generally look like is still missing today. This hinders the use of existing editors, which abundantly exist for standardized diagram types.
Code generation in the field of embedded systems and classical code generation in application development can only just be distinguished fromeach other. The necessary artifacts are generated frommodels,which are based on component standards such as e.g. Autosar or MSR in the automotive industry or SMP2 and SMP in the area of simulation. These are usually C or C++ code, header or configuration files, but certain requirements have to be met: a correctmodel is not sufficient if the code generation is defective. Therefore, certification is an important topic when dealing with securitycritical systems. It is possible to either certify the actual generated code or the code generation itself. 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. 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 themodel fromwhich 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 also reduce the effort. The ability tomakemodifications 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. 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 speeds 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 evenmore 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. In order to be able to use these optimizations formanual programming, the developers have to be trained comprehensively. However, this still does not guarantee that the developers actually use all means of optimization. Tools and code generation are widely spread. In the field of Eclipse, openArchitectureWare Xpand gives you the best support.
The Author
Wolfgang Neuhaus, Vorstand
Wolfgang Neuhaus verantwortet als Vorstand den Bereich Finanzen und Controlling.
