• itemis is providing services to companies for MDSD in several domains. One domain is “complex technical systems”, which includes automotive / embedded. Several of our customers here in the south of Germany are obviously based in Stuttgart.
• itemis is growing. We find it easier to find new talent for our Stuttgart office.
• itemis is member of several consortia (AUTOSAR, Genivi) and research projects (VERDE, Q-Impress,etc.). Hosting meetings in Stuttgart will be more convenient for our project partners, that come from all over Europe.
• itemis has its main office in Lünen near Dortmund. There is a great train connection from Stuttgart to Dortmund (3,5 hours).

All of this factors brought us to the decision to fuse our small Stuttgart office with the Pforzheim office in a new location in Stuttgart. Further factors where:

• the location should be easily accessible from both the main station and the airport for guests, colleagues and commuters (basically no changing trains from those stops, more than one public transports stopping near the office)
• the location should be easily accessible for our commuters from Pforzheim (i.e. a highway exit in the south west of Stuttgart)
• the location should allow for growth
• the location should have a bright atmosphere
• food, good food. Good lunch is a prerequisite for a good afternoon.

We found all that in the Stuttgart Engineering Park STEP and I am looking forward to us opening the new office and growing further in January.

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

There are some approaches to this in Eclipse already. The EDONA project imports requirements into a UML/SysML model profile in Topcased and does some tracing in the model. However, we are going for a more generic solution, since we want to trace elements from models that may not provide extension mechanisms like UML/SysML.

Our traceability information has to be stored outside of the models that we want to trace. In addition, we would like to be able to trace non-EMF “items” like source code, too.

So the approach is to introduce a generic traceability models that stores URI of the source and target “items” together with some metadata. The exact format of the URI can depend on the semantics of the “items”, but a generic implementation for EMF is provided. We plan to use this to trace requirements to AUTOSAR elements, UML elements etc.

A generic EMF based traceability solution, not only for requirements but for any artefact.

The generic implementation of the User Interface allows you to select EMF model elements and to trace these. It is then possible to add specific plugins to improve usability (e.g. add drag-and-drop requirements assignment to UML).

Ah, yes, it will be open source.

Generic UI for traceability, integrated in Artop (AUTOSAR).

It has several rules that intend to reduce ambiguities (it requires {} around the if/else-clauses), to avoid memory-related problems (no use of recursive function calls, no malloc) and things that make code hard to maintain (no more than two level of pointer indirection – **x is OK, ***x is not).

Obviously, this needs to be checked, and there is a number of commercial tools available that do this, most often as a command-line tool. However, Eclipse provides the CODAN framework, which makes structured analysis (and writing e.g. a Misra checker) much easier. It also has the advantage, that the analysis is done in the IDE, during coding and no build cycle is necessary. In a short time, I have implemented the following Misra-checks:

M2.2, M2.3

M12.9,M12.10

M14.8,M14.9,M14.10

M7.1

(sorry for the numbers, Misra has a copyright that does not allow you to freely reproduce their check descriptions). Some of these checks took only minutes to write, once you get to know the framework. Here is a screenshot of M14.8 (if, while, etc… have to be followed by {} )

Note the error markers.

I will add more checks when I have time. However, from the Miscra-licensing, it seems not possible to release it as open source. However, if you are interested, contact me and we could discuss.

Standardized platforms are the solutions to increased development costs and quality problems in many areas of software development. In the automotive industry, platforms for the ECU Software have been defined within AUTOSAR and Genivi. OEMs and suppliers are thereby assured of reduced costs and improved quality by virtue of the standardized interfaces. Standardized platforms improve the quality of infrastructure components of software and pave way for more focus on the differentiating features. These factors are also advantageous during the application of a platform strategy in tool development.

Cost reduction using platforms

When considering the development tools in a  product development process, many similar features are developed anew by the tool manufacturers independently and with different technologies: data storage, user interfaces, connection to architecture tools and graphical editors are just some aspects of infrastructure. To illustrate the AUTOSAR tool chain is considered. AUTOSAR defines an XML interchange format in order to process the AUTOSAR descriptions beyond the tool boundaries. Each tool in the development chain can use the XML format for interchange and stores the AUTOSAR models in a specific representation in the memory. The processing steps of these sections of the development process are thus:

• Importing the existing models from the XML format into the internal format of the architecture tool and processing of the model
• Exporting the internal representation from the architecture tool into XML format
• Importing the XML format into the internal representation of the RTE generator and generation of the header files.
• Importing the XML format into the internal representation of the modelling tool in the internal format of the modelling tool and
• Generation of the code

Altogether three tools implement the functionality of importing the XML and at least one tool to save in XML format. Since these tools are developed by different companies, this functionality is implemented three times and paid for by the customer. The complexity of XML makes implementing different versions of AUTOSAR complex as well. However, this is not differentiated by the tools. Therefore, it can be predicted that there is also demand for re-use of the tool chain. Open source platforms offer this possibility. At this point, Eclipse can be of use in different scenarios:

• “Out of the box”: Eclipse provides many applications that can be used directly. This includes development environments for C and Java, but also for modelling according to UML, data mining and others.
• As basis for applications: Frameworks for data management, user interfaces, graphical editors, forms, web access etc. are part of the Eclipse platform. Projects can set up their development on these frameworks and reduce cost. There are additional platforms for certain industries (partly independent of Eclipse).  For example, in the automotive sector this is Artop, which is being driven by some AUTOSAR partners and provides reading, writing, and the management of AUTOSAR models.
• As integration platform: The common data model and  infrastructure enables a tool design in such a way that they are more closely meshed and tool gaps avoided.
• For project-specific functions:  Development departments can build specific features on this platform that are not provided by the tools.

Artop

The AUTOSAR Tool Platform (Artop) is an Eclipse-based implementation of basic functionality for AUTOSAR development tools. Artop and its source code are freely available for all AUTOSAR members and partners. itemis perceives Artop as a viable platform for development tools in the automotive sector and provides its technologies in the model-based software development as a contributing member to the project. itemis advises OEMs and tool developers in the development, adaptation and introduction of Eclipse-based and Artop-based tools.

ARText

AUTOSAR models for complete and partial systems can be of considerable sizes. The experience with building and managing such models show that graphical editors often reach their limits here. An efficient alternative is the modern specific textual languages that can be effectively created using comfortable editors. Studies show that the input of large models is much more ergonomic and faster because of the absence of constant switching between mouse and keyboard. Issues such as version control and model comparison, which still has not been satisfactorily resolved by graphical models, are easily resolved by textual models with the established tools from the source code management.  Thus, textual editors are much more cost-effective to implement and they are automatically generated to a large extent.

This concept is pursued and implemented in “ARText”, the sub-project of Artop. ARText is based on the core technology “Xtext” provided by itemis and is a comfortable editor for AUTOSAR models.

itemis supports the operation and adaptation of textual, domain-specific languages like ARText.

Picture: Mark Evens – istockphoto

It reflects the fact that Eclipse has established itself in the development tool chain of automotive software – in a domain that is traditionally rather conservative and cautious of open source software. Despite this cautioness, a lot of OEMs and 1-st tiers are already making use of Eclipse, but the notion of open source, community source and collaboration still raises questions in middle and upper management.

The membership of a major 1-st tier shows that it is feasible to use and contribute open source for tool development.

Information about Bosch’s activities can be found in this talk at OOP and this talk at ESE.

However, there is more activity in print. Having discovered a chinese websearch for magazine research (http://it.alljournals.cn/) I was interested in a little statistics and tracked the number of published articles on “model driven” (模型驱动).

Another keyword that yields a lot of result is MDA.  One of our main points of focus in European business, the use of domain specific languages is not yet a major subject in Chinese magazines. Searches result 2-3 hits in 2008 and 2009. It will be interesting to watch the future trends. The chinese already have produced one of the nicer UML tools based on Eclipse (www.trufun.net).

• Business Software (e.g. SAP, Oracle, Web Servers)
• Development Tools (everything for the product lifecycle, i.e. requirements, design, implementation)
• Basic Software for ECUs (i.e. the “Operating System”)
• Application Software

Obviously, for the Business Software, the automotive industry is not too different from other industries. Open source alternatives exists and are in use (like Apache Web servers etc.) to some degree.

The development tools are experiencing an increase of open source software through the use of Eclipse. A number of OEMs, suppliers and tool vendors are using Eclipse as a platform for standard and company specific tool development. GMF, EMF, Xtext and others are widely accepted. The commercially reliable license of Eclipse is a strong factor for the adoption of the platform. And the commitment to Eclipse starts to pour back to the open source community: The new Sphinx project proposal is based on a code base that was developed by the Artop members.

Basic Software has not played a major role in open source yet. One factor being, that there was not a widely accepted standard before AUTOSAR (yes, there was OSEK, but AUTOSAR might bring more attention). Right now, there is no established open source code base for AUTOSAR, but with everything being standardized, this might start with simple modules.

Application Software (your driving assistance, dynamics, enginge control) etc. will still be considered an important setting and not be easily migrated to an open source model.

However, open sourcing application software would probably have a small effect on quality only. Improving the development tool chain is going to yield better results. And open source offers a lot for the tool chain.

• The business model: The user functions that differentiate one car from another largely depend on software. Especially in the premium segment, introducing new functionality is one of the key factors. If you introduce a new function, like night vision, you do not want to give away your investments. This is one of the core parts of the business. Mr. Whitehurst does not show explain how a new business model for the industry could look like.
• Knowledge: Software functions in automotive are extremely complex and not only require know-how in physics, engineering but also in international requlations. How big is the community that could really understand these systems and contribute?
• Testing: Mr. Whitehurst cites successful examples of open source: Firefox, php, and others. But here’s the catch: Those systems can be build and tested by anyone with a PC. Embedded software is inherently different. ECUs usually have specific hardware (different sensors) etc. To really test a system, you need a lot of hardware (including sensors and actors), you have to go to Norway in winter for cold weather testing and Dubai in summer for hot weather testing.  HIL testing is necessary. This greatly reduces the target audience.
  In addition, no OEM can allow you to reprogram your car and drive it on public streets.
• MBSE: Physical functions are often designed with tools like Mathlab / Simulink or Ascet / SD. Open Sourcing the generated code from those tools is next to useless. So you’d have to  open source the models, which require tools with expensive licenses to work with.
• Safety: Non of the quoted open source software is safety-relevant (how many people die if your Firefox browser crashes and is not available for 3 seconds?).  Safety relevant software has to be carefully designed, for moral and for legal reasons. So where are the references to successful open source projects with SIL (safety-integrity-levels) requirements?
• Supplier: Requesting that “Toyota should open source its software” neglects the situation of IP rights. Software is usually only written in small parts by the car manufacturers (OEM) but largely by suppliers of ECUs (e.g. Bosch, Denso).
• Kaizen and Open Source: Whitehurst implies that Kaizen for software means Open Source and that Toyota should transfer its principles of Kaizen to software. If that is so, where can we download the specifications of Toyota motors, constructions plans etc.? Kaizen obvioulsy does not mean open sourcing anything.

The article quotes “Toyota acknowledged that a software glitch was to blame for braking problems in 2010 Prius vehicles, and the company changed its braking system software in January to address the problem.” However, if you read this article by CNN, you will see that the braking problem relates to the software for hybrid systems, which are considerably different from traditional braking. There is no proof, that this problem could have been avoided by open source.

<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.