Wir halten am 10.Dezember 2009 um 16:00 Uhr einen Vortrag über die Einführung von MDSD in einem Projekt auf dem Embedded Software Engineering Kongress 2009 in Sindelfingen:

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.

The new Xtext version in Galileo changed a few things. To do scoping, a little bit of Java development is necessary. Documentation is very brief, but with a little research it is quite easy. Consider the following grammar, that allows us to define components, instances of those components and – the interesting part here – connect ports of instances:

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.