Andreas Graf¹,Markus Völter²

1: itemis GmbH, Blücherstr. 32, 75177 Pforzheim, Germany

2: independent/itemis GmbH, Hohnerstr. 25, 70469 Stuttgart, Germany

This paper has been presented and published at ERTS2 2010

Extended Abstract for Application:

Keywords: AUTOSAR, Eclipse, Open Source, model transformation, Artop, Model Driven Engineering, AUTOSAR tool chain, software development process, AUTOSAR migration, automotive software, standardization, Engineering tools integration and interoperability, Open source, open systems.

1. Introduction

AUTOSAR is establishing itself as a prominent standard in automotive systems and is expected to significantly improve software architecture and the software development processes. However, the introduction of AUTOSAR also poses some challenges.

AUTOSAR only defines part of the development process, it does not specify how to interface tools in preceding process steps (such as functional design or requirements engineering) and to subsequent steps (such as testing or the actual implementation of the software).

In addition, AUTOSAR currently does not cover all aspects of automotive software. AUTOSAR software needs to communicate with non-AUTOSAR software, for example in the infotainment domain or even with off-board software.

In addition to these conceptual challenges, the availability of tools can be a challenge, too. Similar to the early phase of UML, AUTOSAR tools are rather new and immature, and experience with those tools is not widespread. Tool features might be lacking and the integration of AUTOSAR tools into a company’s overall tool chain will definitely not be provided out of the box by an off-the-shelf tool. It needs customization.

The different steps in the AUTOSAR methodology might be addressed by different AUTOSAR tools from different vendors. Those tools need to interact with each other, increasing increases the need for an open approach that allows for customization and extension.

2. Scope of the paper

In this paper, we discuss a number of examples of the challenges above. The paper shows how these challenges can be alleviated by Eclipse based tools.

Eclipse has established itself as an industrial strength development tool in industries that develop complex systems, such as aerospace and automotive. OEMs, first-tiers and suppliers already successfully use it for software development and as a rich and mature tooling platform. It can be seen as a platform for domain specific extensions that can be used out-of-the box (e.g. the C programming IDE “CDT”) as well as a platform for additional tools.

The open nature of the Eclipse platform allows for the integration of applications and project specific extensions.

With Eclipse’s latest Galileo release, several mature tools for model-driven software development (MDSD) have become available. These provide a flexible and low-cost set of tools for bridging the gaps in existing AUTOSAR tool chains.

The paper is structured as follows: We first introduce the AUTOSAR tool platform Artop and a number of open source Eclipse Modeling tools and explain their role in model driven development. We then show example challenges in the integration of an AUTOSAR tool chain and sketch solutions for these challenges based on the Eclipse based tools introduced.

3. Tools

In this paper, we look at Eclipse-based tools for model-driven software development. Eclipse is an open source project started by IBM a couple of years ago. Initially Eclipse was a Java development environment. However, from the start, Eclipse has been architected to be extendable in significant ways. Over time, a number of additional projects have been initiated as part of the Eclipse platform; among them the Eclipse Modeling project.

The Eclipse Modeling project is a collection of frameworks and tools for model driven development. In sum, they provide a wide range of solutions for various aspects of model driven development, from language definition to editor construction to code generation as well as model verification and validation.

This section introduces some of the tools from Eclipse Modeling. Specifically, we suggest those tools as a basis for integrating an AUTOSAR tool chain.

EMF

EMF, the Eclipse Modeling Framework, forms the basis for all Eclipse Modeling tools. At its core, it provides the Ecore meta meta  model, a formalism for defining the abstract syntax of modeling languages. EMF comes with a set of related frameworks and tools for validation, query, persistence, and model transactions.

Xpand

Xpand is a framework for code generation (in fact, you can generate any kind of textual artifact such as configuration files or documentation as well). It processes models based on languages defined with EMF. The Xpand language itself is quite sophisticated in the sense that it contains a powerful expression language for querying and traversing models. It also supports polymorphism and aspects for code generation templates, making sure that nontrivial code generators remain maintainable.

Xtend

Xtend is used for transforming models into other models, for modifying existing models before they are fed into a code generator, as well as for implementing simple helper functions that are used as part of code generation templates.

Check

Check is used for validating models. Constraints are expressed in the constraints Check language (which embeds the same OCL-like expression language used in Xpand and Xtend). The constraints are then evaluated either in real time in the editors when creating models or as part of model transformation and code generation workflows.

Xtext

Xtext is a framework for defining textual domain specific languages. Based on a grammar definition, the Xtext tooling generates a parser, an EMF meta-model, as well as an editor for the language defined by the grammar. The editor provides all the features known from current IDE’s: code completion, syntax highlighting, folding, customizable outline views, go-to definition and find references, etc. Using Xtext, the effort of defining languages and providing editor support on a level that makes using that language productive and comfortable becomes significantly simpler.

GMF

GMF supports the construction of graphical editors (box and line style) for existing EMF meta-models. Using this framework, you can define graphical notations for your own languages.

Integration of the tools

Using the above mentioned tools together results in a complete toolset for model driven development. You define your meta-models using EMF, then you add a graphical or textual notation using GMF or Xtext, you use check for validating models, and finally, you can use Xtend and Xpand to transform the models created with your graphical or textual editors into other models or text.

An additional project, the modeling workflow engine, is used to orchestrate the processing of models. It provides facilities for loading models from files and supplying them to validation, transformation, and code generation components.

Artop

One of the fundamental motivations of AUTOSAR is to increase the reuse of software within the car. Transferring this motivation to the AUTOSAR authoring tools is a logical step. This motivation drives the Artop initiative.

The AUTOSAR Tool Platform (Artop) is an implementation of common base functionality for AUTOSAR development tools. Artop uses many of the above mentioned frameworks to provide specific base functionalities for creating AUTOSAR tools. This includes a complete implementation of the AUTOSAR meta-model in the form of an Ecore model, an extensible validation engine for checking AUTOSAR specific and even project-specific constraints, a sophisticated workspace management that takes into account AUTOSAR’s way of storing models and lots more.

Artop is developed by the Artop User Group, a group of AUTOSAR members and partners and uses Eclipse not only as its technical platform but also uses a similar community approach to develop the software. Artop is open to any AUTOSAR member or partner.

Sphinx

The Sphinx project proposal [Sph2010] is a proposal for a new Eclipse Model Development Tools (MDT) subproject.

While developing Artop a lot of functionalities were developed, that had their origins in the use of AUTOSAR, but were not specific to AUTOSAR at all. Similar functionalities were also required in other industries than the automotive domain, like avionics.

The goal of the Sphinx proposal is to remove these features from the Artop platform and rather develop them in a larger community within the Sphinx project.

4. Bridging the gaps

Based on these tools, there are two basic types of tool integration: A tight integration on the Eclipse platform and a looser coupling through data exchange formats.

The tight integration allows tools that conform to the Eclipse architecture to be integrated within one application. The user does not have to switch between different applications, because he sees an integrated development environment.

However, existing tools used by projects might not be based on Eclipse. By making use of the Eclipse modeling tools, a loose integration is still possible through data import and export.

5. Challenges and Solutions

In this section we show how to use the aforementioned tools to address a number of challenges in the integration of an AUTOSAR tool chain.

To describe the relevant AUTOSAR models, we will introduce a textual description of AUTOSAR models called ARText. ARText is based on Xtext and an early implementation is available through the Artop distribution. This language is used to illustrate AUTOSAR models used in the examples, since it is much more concise than a graphical notation. Here is an example of a definition of a sensor component with an interface in ARText format:

interface senderReceiver cardata {

data int32 speed

}

component atomic Sensor {

ports {

sender X provides cardata

}

}

Model-to-Model-Transformations and Model-to-Text-Transformations are shown as examples in the solutions to the challenges. The code fragments of the transformation are for illustration only. Real transformations might include additional code.

Adding AUTOSAR Import / Export to existing tools

Challenge: All tools within the AUTOSAR tool chain have to be able to read / write data in the AUTOSAR XML format. The AUTOSAR XML-format is a complex data exchange format. Adding reading / writing functionality to an existing application requires significant effort. If every tool re-implements the XML functionality, the end user basically pays several times for the development of a non-differentiating feature. The cost and time can be significantly reused by making use of Artop and the Eclipse modeling tools.

Figure 1 – XML Readers and Writers are a redundant functionality in the tool chain.

Solution: Artop provides capabilities to read and write the AUTOSAR XML formats to and from the Eclipse EMF. Using model transformations, AUTOSAR models can be converted to the native format of existing tools.

Figure 2 – Integrating non-AUTOSAR tools by model transformation

For the example, a transformation of the AUTOSAR model into a CSV (Comma-Separated-Value)-file is given. CSV is a common file format that can be read by various spread sheet and database tools. Each line of the output should contain a software component name and information about the ports of that software component. A Xpand template could be similar to the template shown in Fragment 1.

Code Fragment 1 – M2T of AUTOSAR into .csv

Code Fragment 2 – CSV Result

The first line of the output file contains the component of the short example given in the introduction with the specification of the provided part. The second line shows an additional software component to illustrate the structure of the output file. Any output file in a textual format can be generated by Xpand.

Integration of Behavioral Models

Challenge: AUTOSAR explicitly provides no means for the specification of the behavior (program logic) of software. In model bases software development, a number of modeling approaches are well established (such as state machines or dataflow modeling). However, AUTOSAR does not specify a mapping to behavioral modeling paradigms. The linking and synchronization between with artifacts in other modeling tools is not defined.

Solution: Use model transformations to synchronize the AUTOSAR model with a behavioral model. This helps to avoid redundant modeling of elements in more than one tool and manual synchronization. The exemplary solution links AUTOSAR models with UML state machines.

The meta-model elements of AUTOSAR and the state machine have to be mapped. A state machine needs to react to data being received. For this solution, we map AUTOSAR data elements to state machine triggers. Based on this mapping, a model-to-model-transformation generates the skeleton of a state machine and infers the required events / triggers from the AUTOSAR specification.

Code Fragment 3 – M2M of AUTOSAR into UML state machines

The code fragment generates a state machine for every software component and to keep the models synchronized, adds a trigger for each data element of required interfaces (i.e. incoming data).

Figure 3 – AUTOSAR Data Element as triggers in state machines

Comfortable Editing of Large models

Challenge: Creating complex models with graphical modeling tools often is a time-consuming task, since the creation of new model elements involve a lot of mouse movements and switching between keyboard and mouse.

Solution: Textual domain specific languages are an established approach to create a user-friendly modeling environment. A comfortable environment with syntax highlighting, code completion and navigation functionality allows the user to quickly create models without the need for time-consuming context switches between mouse and keyboard  [ARText2009]. Additionally, textual formats successfully scale to large projects and are also suited to distributed development environments. This is due to the format taking advantage of the well established textual tools and infrastructure supporting this environment. For example, configuration, source, change and version control. Support for these functions is integral for an effective distributed development environment.

With ARText the Artop community provides an environment for textual languages based on AUTOSAR. It defines and implements a textual language to describe AUTOSAR models. The framework is based upon Xtext which gives access to rich features for textual languages like syntax-highlighting and code-completion. The textual notation used in this document is the ARText notation.

Developers who are more inclined to textual formats will benefit from a less steep learning curve when developing AUTOSAR models with ARText.

Project Specific Code generation

Challenge: Existing tools might not be prepared for AUTOSAR-conforming code generation. Manual post processing of the code is necessary.

Solution: Create AUTOSAR conforming code by using customized generation templates based on Xpand.

For the exemplary integration of open-source state machine modeling / simulation, the Yakindu tool generation has been made AUTOSAR conforming.

The state machine for terminal control

Figure 4 – State Machine as input to the generation.

can be transformed into AUTOSAR compliant code that uses the RTE as an interface to get notified of incoming transition triggers and reacts by sending data through the RTE.

Migrating Legacy Models to AUTOSAR

Challenge: Migrate existing component models to AUTOSAR. Before the introduction of AUTOSAR, projects often modeled the software architecture with other notations (e.g. UML). These models have to be migrated to AUTOSAR.

Solution: Load the models into Eclipse and transform them to AUTOSAR. Most UML2 should have a XMI-conforming export. These models are loaded into a UML2-EMF model and subsequently transformed to Artop models directly by Xtend or to textual representations like ARText.

Suppose that every class in a UML model should be transformed into an AUTOSAR software component. The following Xtend transformation will perform this transformation.

Code Fragment 4 – M2M of UML to AUTOSAR

The second create function will create an AUTOSAR package in the destination model and call the transformation for every class in the UML model. The semantics of the class to component transformation is specified in the third create statement. Here it is a simply copying of the name.

Generating RTE for non-AUTOSAR Basic SW

Challenge: Implement an AUTOSAR RTE on platforms that have no AUTOSAR Basic Software available. One of the suggested migration strategies to AUTOSAR ECUs is the use of legacy BSW with AUTOSAR conforming application layer as a first step [AR2010]. However, COTS RTE generators cannot be used, since they usually do not support project specific legacy basic software.

Solution: Use Xpand to generate a RTE that conforms the API for the application software and interfaces to the platform specific basic software. Supposing, that a communication call in the legacy software would have the signature “void Legacy_SendCall(…)”, a RTE that makes use of this generation can be generated by a code fragment like:

Code Fragment 5 – M2M of UML to AUTOSAR

6. Conclusion

In the paper we showed some of today’s recurrent challenges in tools and described the need for more integrated tool chains. Challenges in the integration of an AUTOSAR tool chain can be solved by the use of inexpensive Eclipse based tooling. An open platform is the precondition for an integrated tool chain. The solutions shown in this paper have been applied in various projects.

4. References:

[Sph2010] Sphinx project proposal, http://www.eclipse.org/proposals/sphinx/

[ARText2009] S. Benz, D. Wong. “ARText – Driving Developments with Xtext“, http://www.slideshare.net/sebastianbenz/artext-driving-developments-with-xtext

[AR2010] S. Fürst et al., “AUTOSAR – Migration and Advantages of an Industry-Wide Standard“. Proceedings of the VDA technical Congress 2010

I happen to come back to look at the DSL, if only for inspiration on how you can find notations that seem natural and yet are formal.  Inform 7

• wants describe a “world” in an executable way
• expects its users to be literary inclined, not programming geeks.

These goals are obviously similar to the use of DSLs. An example of how a description of a physical system could look like can be found in the examples:

1
2
3
4
5
6
7
8
9
10
11
12

"Lead Cuts Paper"
 
A weight is a kind of value. 10kg specifies a weight. Everything has a weight. A thing usually has weight 1kg.
 
A container has a weight called breaking strain. The breaking strain of a container is usually 50kg. Definition: A container is bursting if the total weight of things in it is greater than its breaking strain.
 
A lead pig, a feather, a silver coin and a paper bag are in a room called the Metallurgy Workshop. The paper bag is a container with breaking strain 2kg.  The lead pig has weight 50kg.
 
Every turn when a container (called the sack) held by someone visible (called the chump) is bursting:
 say "[The sack] splits and breaks under the weight! [if the player is the chump]You discard[otherwise][The chump] discards[end if] its ruined remains, looking miserably down at [the list of things in the sack] on the floor.";
 now all of the things in the sack are in the location;
 remove the sack from play.

Especially the first three lines show how a physical system with rules can be described in (almost) natural language. And it can actually be executed. This is a transcript of the session:

Lead Cuts Paper
An Interactive Fiction
Release 1 / Serial number 100707 / Inform 7 build 6E72 (I6/v6.31 lib 6/12N) SD
 
Metallurgy Workshop
You can see a lead pig, a feather, a silver coin and a paper bag (empty) here.
 
>get pig
Taken.
 
>get bag
Taken.
 
>put pig into bag
You put the lead pig into the paper bag.
 
The paper bag splits and breaks under the weight! You discard its ruined remains, looking miserably down at the lead pig on the floor.

Of course, we’d probably not describe lead pigs put components of cars and satellites ….

Another interesting feature is the specification of tabular data. Again from the docs:

Table 2.1 – Selected Elements

And the access to the table:

symbol in row 3 of the Table of Selected Elements

It will be interesting to see, if notations like this will establish themselves more and more.

<value-specification> ::= <literal> | <enum-specification> | <interval> |
<collection> | <tuple> | <choice> | <expression> |
<time-expression> | <obs-call-expression>

Creating a Xtext grammar is very easy, but re-typing and manually transforming from BNF to Xtext is boring. Obviously, with a Xtext grammar for BNF, we could easily transform the MARTE BNF into a MARTE Xtext grammar and work with that. The first shot is a grammar like

grammar de.itemis.verde.Bnf with org.eclipse.xtext.common.Terminals

generate bnf “http://www.itemis.de/verde/Bnf”

Model:
(rules+=Rule)*;

Rule : “<”name=RULENAME”>” “::=” e=Expression ;

Expression :
el+=OredElement (“|” el+=OredElement)*;

OredElement:
(terms+=Term)+;

//LineEnd: EOL+;

//List: Term | (t=Term l=List);

Term: o=OptionalExp | l=ListExp | k=KeyConstr | r=RuleCall;

OptionalExp:    “[" x=Expression "]” (mult?=”*”)?;
ListExp:  “(” x=Expression “)” (plus?=”+”)? (mult?=”*”)? ;
KeyConstr:  k+=Keyword (“..” k+=Keyword)? ;

Keyword:
text=STRING;

RuleCall:
“<”ref=[Rule|RULENAME]“>”;

terminal RULENAME : (‘a’..’z'|’A’..’Z'|’-') (‘a’..’z'|’A’..’Z'|’-'|’0′..’9′)* ;

An additional Xpand templates generates a nice Xtext grammar. Now we just have to get rid of the left recursion. As there is an algorithm for that too, we are thinking of putting that algorithm in the generator.

Another application could be the generation of a parser for the textual format for message sequence charts, as this definition is also available in BNF.

So the example grammar of new Xtext Projects in Chinese could look like this:

Of course, content assist and outline are fully supported:

All you have to do is to set Eclipse to use UTF-8 for the workspace through Window->Preferences->General->Workspace.

And, with a little overloading of the ID terminal, like this:

terminal ID :
‘^’?(‘a’..’z'|’A’..’Z'|’_'|’一’..’é¾¥’) (‘a’..’z'|’A’..’Z'|’_'|’0′..’9′|’一’..’é¾¥’)* ;

You can even use chinese characters as IDs:

Still, UML has become complex and clumsy. For 80% of all software only 20% of UML is needed. However, it is not easy to find the subset of UML which we would call the “Essential” UML. We must make UML smarter to use.

There is a strong point in UML being too big. I have been following UML since its inception, having worked 10 years on one of the first UML tools, Software Through Pictures. Over the time, I have more and more been favouring (textual) DSLs. One of the reasons are the intrinsic problems of graphical  modelling, so one of the quotes I cannot really agree to:

There are a number of good and easy to use tools.

The situation has gotten much better, but graphical modeling tools are very complex to get right and I’d support the statement on one of the speakers on the german Architektour podcast that there are few tools that I really like, only tools that I dislike less. However, in project settings, there might be some influencing factors that make  UML and UML tooling is the best solution. If you understand german, most of the arguments pro and con UML that I’d use are mentioned on the Architektour podcast.

I like Pedro J. Molina’s article in his post “Using the 20% of UML”.

So I don’t think an “Essential UML” would be the right way to go. Time is better invested to find the right DSL for your domain.

EvaluationException : Couldn't find operation 'setName(String)' for uml::Class.
    torcssim::common::m2uml.ext[438,20] on line 23 'this.setName(c.name)'
    torcssim::common::m2uml.ext[315,16] on line 13 'x.components.c()'   
    nofile[0,23] on line 1 'toModel(model,umlmodel)'

It could not cast from an Xtend String to an UML String. The solution is in adding the meta-model to the component:

 <component class="org.eclipse.xtend.XtendComponent">
     <metaModel id="mm" class="org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel"/>
     <metaModel class="org.eclipse.xtend.typesystem.uml2.UML2MetaModel"/>
     <invoke value="torcssim::common::m2uml::toModel(model,umlmodel)"/>
     <outputSlot value="transformedUMLModel"/>
    </component>

Which is quite obvious when you have done it once, but if you try to set it up the first time, it can cost you quite some time. Especially, when everything looks good in the editor.

Textuelle domänenspezifische Sprachen sind ein starker Trend in der Software-Entwicklung.  Welche Lessons-Learned macht ein mittelständisches Unternehmen bei der Einführung von modellbasierter Software-Entwicklung für  Embedded Systems? In diesem Talk werden an Hand eines realen Projekts die Lessons Learned und die Vorteile des Einsatzes von textuellen domänenspezifischen Modellen auf Basis von Open Source-Tools erörtert.

Gerade im Embedded Bereich wird Modellierung noch mit ineffizienter Implementierung in Verbindung gebracht.  Mit neuen Modellierungstechniken ist dies jedoch nicht der Fall.

Die Referenten werden darüber sprechen, wie sich die Einführung auf Anforderungsmanagement,  Projektplanung, Design und Implementierung auswirken. Somit wird modellgetriebene Software-Entwicklung nicht nur vom technischen Standpunkt
der Werkzeuge betrachtet, sondern aus einer gesamthaften Projektsicht.

Die Teilnehmer erhalten Informationen über den praktischen Einsatz von textuellen DSLs, die sie in die Bewertung ihres eigenen Entwicklungsprozesses einbringen können. Da es sich um ein typisches Embedded-System handelt, zeigen wir, dass sich der Einsatz auch in kleineren Projekten und Systemen mit beschränkten Ressourcen lohnt.

Component :
    "component" name = ID "{"
    (ports+=Port)*
    "}";

Port :
    "port" dir=Direction name=ID ":"  ref=[Interface|ID] ";"
    ;

enum Direction :
    IN="in" | OUT="out";

Instance:
    "instance" name=ID ":" type=[Component|ID] ";"
    ;

Connection:
    "connect" in=[Instance|ID]"."p=[Port|ID] "->" in2=[Instance|ID]"."p2=[Port|ID] ";"
    ;

The default code completion will traverse all defined Ports for the references p and p2 in the Connection rule. A better behaviour would be:

• Show only the ports in the instances (in, in2)
• For p, show only “OUT”-Ports, for p2, show only “IN”-ports.

To do this, we need to define methods in a class derived from AbstractDeclarativeScopeProvider. The method names follow the signature scope_<rule>_<element>, so the code fragment for p2 is:

IScope scope_Connection_p2(Connection ctx, EReference ref)
    {
        if(ctx.getIn2() == null )
            return IScope.NULLSCOPE;
        else
            return new SimpleScope(IScope.NULLSCOPE, getRPorts(ctx.getIn2().getType()));

    }

With some additional code the full Provider for p and p2 looks like this:

public class AutomotiveDSLScopeProvider extends AbstractDeclarativeScopeProvider {

    IScope scope_Connection_p2(Connection ctx, EReference ref)

    {

        if(ctx.getIn2() == null )

            return IScope.NULLSCOPE;

        else

            return new SimpleScope(IScope.NULLSCOPE, getRPorts(ctx.getIn2().getType()));

    }

    IScope scope_Connection_p(Connection ctx, EReference ref)

    {

        if(ctx.getIn() == null )

            return IScope.NULLSCOPE;

        else

            return new SimpleScope(IScope.NULLSCOPE, getPPorts(ctx.getIn().getType()));

    }

    private Iterable<IScopedElement> getPPorts(Component clazz) {

        List<IScopedElement> result = new ArrayList<IScopedElement>();

        for (Port f : clazz.getPorts())

            if (f instanceof Port && f.getDir() == Direction.OUT)

                result.add(ScopedElement.create(f.getName(), f,"("));

        return result;

    }

    private Iterable<IScopedElement> getRPorts(Component clazz) {

        List<IScopedElement> result = new ArrayList<IScopedElement>();

        for (Port f : clazz.getPorts())

            if (f instanceof Port && f.getDir() == Direction.IN)

                result.add(ScopedElement.create(f.getName(), f));

        return result;

    }

}

This is a transcript of the first itemis screencast introducing model based design and implementation for embedded systems. It is intended for those readers that cannot access the screencast. The screencast is on Youtube.

Introduction

Welcome to the itemis introduction screencast for Model Driven Software-Design for On- and Off-board software.

This is the first in a series of screencasts where we explain various aspects of Model Driven Software Design for complex systems comprised of embedded processors, mobile applications and enterprise infrastructure. We will show how to use open source tools for the engineering process. This screencast will explain the motivation and methodology for model driven software design and introduce the showcase that is used to explain various aspects in the following screencasts.

Software in embedded systems is getting increasingly complex. It is now a major part of electronics development. In addition, embedded systems are more and more connected. Modern cars consist of nearly 100 embedded control units and a complex network. And those systems are connected to off-board systems, as for example in remote diagnosis systems. This is an engineering challenge. We need flexible, reliable systems that comply with various safety standards. Those standards define process and methodologies for safety-critical systems. Manual engineering of software often leads to errors and increased cost in complex systems. We need a methodology and tools that can handle those systems.

We at itemis meet those challenges with model based design. Models help to manage complexity by increasing the level of abstraction. That allows us to discuss the relevant aspects for a problem and not getting confused by all the other aspects. A good model will separate the domain knowledge from the underlying infrastructure. It will also have different views for dynamic and static aspects of the system.

By raising the level of abstraction, a good model will provide a better understanding of the problem at hand. It will improve communication in the project team. And a good model will always be up to date and represent the actual system. However, that is not enough.

To reduce the error-prone manual coding, a good model has to support code generation. It will also support generation of a test framework and generation of the documentation. So, the model has to be at the core of the development process.

So does it this approach really work? Yes it does. We have set up a showcase to show how model driven software design works in embedded and enterprise systems.

Showcase

The showcase system that we built is an example from the automotive domain.

It consists of three major parts. The sensor, the embedded devices and the enterprise applications.

To simulate a real sensor, we patched the open source racing simulation “Torcs” to send out information about the car state. Telemetric data from the sensor is sent throughout the system. It is generated by a virtual sensor on a PC and sent through an UDP link to a Gateway. This gateway is a blackfin board running Embedded Linux. The telemetric data is then sent over two channels. On the embedded side, it is broadcast on a CAN bus, where it is received by a display 3000 board. This is an atmel processor without operating system, but with a small display.

On the enterprise side, the data is sent over a serial link to a PC running a JBOSS application server. It can then remotely be accessed from iphones and android phones by means of standard web services.

With a manual approach, code for all these plattforms would have to be manually written. This is a source for errors and problems.

With model driven software design, we use an abstract unified model to represent the system. We generate code for all those platforms automatically and increasing the speed of the engineering process.

The power of model-based engineering is easily visible if we introduce a second item of sensor data, for example the rotations per minutes of the motor. All the software in the system would have to be changed manually, to handle the additional information.

However, with model based design, we just add the new piece of information to the model and then regenerate the code for the entire system.

More Information

We will explain methods and tools in several screencasts. You have just seen a summary of the introduction screencast.

• Screencast 2 will explain the use of domain specific languages for architecture modeling and code generation.
  
• Screencast 3 will show how to use an eclipse-based open source toolchain for developing software for embedded systems.
• In Screencast 4 we will bridge the gap from embedded systems to enterprise application and generate the infrastructure and mobile applications.
  
• Screencast 5 explains the handling of variants and product lines. Screencast 6 will deal with model based diagnosis of embedded systems.
  

All screencasts use the same showcase system.