Research project IMES

Posted on by
Reply

We have been able to get funding for the IMES research project, together with our project partners:

Goal of IMES is the exploitation of the full potential of model based development (MBD) by both applying MDB for application function oriented requirements engineering and the architecture centric design of software intensive systems and by using MBD for quality assurance and integration. One focal point of the project is the formalization of in-use approaches that are less formal (e.g. structured modeling of application functions), as well as the extension of the models in use to cover essential characteristics (e.g. definition of dynamic interface characteristic in AUTOSAR).

Another focal point is the transfer of the model based development process to industrial application, both by defining reference documents and models (i.e. application function oriented model for the specification documents) and reference solutions (e.g. standard architectures) as well as providing methods for analysis and synthesis.

An essential part is the distributed development process for automotive systems, i.e. the collaboration of OEMs and 1-tiers. Illustration one shows the intended modular structure for that collaboration. In current practice, the OEM basically defines the function to be provided by the software and uses that definition for the functional verification. The ECU and its software is developed for the most part by the 1-tier. This separation introduces an extensive effort during integration and quality assurance of the function into the full system: The OEM does not have knowledge in the software architecture and the 1-tier lacks the view on the full system to be able to design a feasible software architecture.

The system architecture is driven by the integration of monolithic single application functions. The architecture is not design for quality characteristics (e.g. ISO 9126). The reuse of application functions and software components for new models and product lines is restricted, since both function and software are designed for one product line. The adaptation of existing functions to new technical platforms requires huge effort, that should better be invested to develop new, innovative functions.

IMES aims to increase the modularization of the development. Specification of requirements, functional elements and functional software components is in the hands of the OEM. 1-tiers focus on the implementation of software and middle ware as well as the production of the ECUs. Functions do not have any implications on the competitive advantage could still be developed by the supplier. In a modular development process, development steps can be addressed by different entities. To industrialize the transition from one step to the next, a precise specification is required.

To address these issues, IMES addresses four major topics as well as the cross-cutting topic “model repository”.

  • Function oriented requirements definition
  • Architecture-centric system development
  • Quality assurance of models
  • Model based quality Assurance
  • Model repository

For itemis, this is another step into bringing our technologies “up the left leg of the V” in development. Within VERDE, we are designing and implementing a solution for the traceability of requirements with Eclipse. IMES is a perfect match for that activity, since requirements specification and application function modeling are critical steps that are not yet supported enough by Eclipse based tooling.

Samson G-Track, static noise and Windows 7

Posted on by
4

For producing the screencasts and podcasts I needed a mic with better quality than the built-in mic of my laptop. After checking the reviews on Amazon I ordered a Samson G-Track. Much to my disappointment, after plugin in there was a lot of static noise when recording. How could that be with that much good reviews? Most of the great reviews, it turns out, where from people still using XP. Windows 7 changed the sound architecture / drivers so that a USB mic that works great on XP does not necessarily work on W7.

I could not find any solution on any of the forums where this problem was discussed. After some googling I decided to give a ASIO driver a try and downloaded the demo from www.usb-audio.de: Success! No static noise anymore. So if you want to get your G-Track running on Windows 7, try to find some USB ASIO drivers. It even gets the mic to work with software that does not support ASIO. I am using Audacity with MME to record – no static,  but the input level might be a bit low. Unfortunately, the driver I found costs EUR 60,-, which is basically half of what the mic costs.Be sure to get an evaluation version of your driver first to see what Windows 7 makes of your combination of HW/SW.

Xtext 1.0.0 and UML (Xpand on top)

Posted on by
8

Several projects combine textual DSLs with Xtext with UML models and there have been some postings (by Sven, Holger and others) on how to achieve this with earlier versions of Xtext. This is a short sketch on how to do it with the latest version. If you do not now what this is about, have a look at the screenshot on the left: The Xtext grammar references a UML model with an Activity and two classes. This is fully integrated you see that content assist suggest the elements from the UML model.

The biggest difference is the need for IResourceProviders for UML. Xtext comes with a IResourceProvider for EMF models, and this can be used for writing an UML version. I added three new files to the Xtext project: UmlResourceDescriptionManager.java and UMLResourceServiceProviderImpl.java UMLResourceDescription.java . The former two are very simple: UMLResourceServiceProviderImpl.java only binds the .uml extension.

<pre lang="java5" line="1" escaped="true">/*******************************************************************************
 * Copyright (c) 2009 itemis AG (http://www.itemis.eu) and others.
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 *******************************************************************************/
package de.itemis.graf;
 
import org.eclipse.emf.common.util.URI;
import org.eclipse.xtext.parser.IEncodingProvider;
import org.eclipse.xtext.resource.IContainer;
import org.eclipse.xtext.resource.IResourceServiceProvider;
import org.eclipse.xtext.validation.IResourceValidator;
import org.eclipse.xtext.ecore.EcoreResourceDescriptionManager;;
 
/**
 * @author Andreas Graf - Initial contribution and API
 */
public class UmlResourceServiceProviderImpl implements IResourceServiceProvider {
 
 public IContainer.Manager getContainerManager() {
 return null;
 }
 
 private UmlResourceDescriptionManager umlResourceDescriptionManager = new UmlResourceDescriptionManager();
 
 public org.eclipse.xtext.resource.IResourceDescription.Manager getResourceDescriptionManager() {
 return umlResourceDescriptionManager;
 }
 
 public IResourceValidator getResourceValidator() {
 return IResourceValidator.NULL;
 }
 
 public boolean canHandle(URI uri) {
 return "uml".equals(uri.fileExtension());
 }
 
//    private IEncodingProvider encodingProvider = new XMLEncodingProvider();
 
 public IEncodingProvider getEncodingProvider() {
//        return encodingProvider;
 return null;
 }
}
/*******************************************************************************
 * Copyright (c) 2009 itemis AG (http://www.itemis.eu) and others.
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 *******************************************************************************/
package de.itemis.graf;
 
import java.util.Collection;
 
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.xtext.resource.IResourceDescription;
import org.eclipse.xtext.resource.IResourceDescriptions;
import org.eclipse.xtext.resource.IResourceDescription.Delta;
import org.eclipse.xtext.resource.IResourceDescription.Manager;
 
/**
 * @author Andreas Graf - Initial contribution and API
 */
public class UmlResourceDescriptionManager implements Manager {
 
 public IResourceDescription getResourceDescription(Resource resource) {
 return new UmlResourceDescription(resource);
 }
 
 public boolean isAffected(Delta delta, IResourceDescription candidate) throws IllegalArgumentException {
 return false;
 }
 
 public boolean isAffected(Collection<Delta> deltas, IResourceDescription candidate,
 IResourceDescriptions descriptions) throws IllegalArgumentException {
 return false;
 }
 
}

This is a very basic implemenation of a UML Resource Description: It returns all "NamedElements" from the UML model.  The functionality could be extended to different purposes, but this does the job right now.

 
/*******************************************************************************
 * Copyright (c) 2009 itemis AG (http://www.itemis.eu) and others.
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 *******************************************************************************/
package de.itemis.graf;
 
import java.util.Iterator;
import java.util.List;
 
import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.EClass;
import org.eclipse.emf.ecore.ENamedElement;
import org.eclipse.emf.ecore.EObject;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.emf.ecore.util.EcoreSwitch;
import org.eclipse.xtext.resource.EObjectDescription;
import org.eclipse.xtext.resource.IEObjectDescription;
import org.eclipse.xtext.resource.IReferenceDescription;
import org.eclipse.xtext.resource.impl.AbstractResourceDescription;
 
import com.google.common.collect.Iterables;
import com.google.common.collect.Lists;
import org.eclipse.uml2.uml.*;
/**
 * @author Andreas Graf - Initial contribution and API
 */
public class UmlResourceDescription extends AbstractResourceDescription {
 
 /**
 * @author Andreas Graf - Initial contribution and API
 * 
 
 *
 */
 private static final class Switch extends EcoreSwitch<IEObjectDescription> {
 @Override
 public IEObjectDescription caseENamedElement(ENamedElement object) {
 return new EObjectDescription(object.getName(), object, null);
 }
 }
 
 private Resource resource;
 
 private URI uri;
 
 public UmlResourceDescription(Resource resource) {
 this.resource = resource;
 this.uri = getNormalizedURI(resource);
 }
 
 @Override
 protected List<IEObjectDescription> computeExportedObjects() {
 Iterator<EObject> contents = resource.getAllContents();
 List<IEObjectDescription> result = Lists.newArrayList();
 
 while (contents.hasNext()) {
 EObject eObject = contents.next();
 IEObjectDescription desc = null;
 
 if(eObject instanceof org.eclipse.uml2.uml.NamedElement)
 {
 
 org.eclipse.uml2.uml.NamedElement ne = (org.eclipse.uml2.uml.NamedElement) eObject;
 // We have to check that the name is non-null, otherwise some code calling us will fail
 if(ne.getName()!=null)
 {
 desc = new EObjectDescription(ne.getName(), eObject, null);
 }
 
 }
 
 if (desc!=null)
 result.add(desc);
 }
 return result;
 }
 
 public Iterable<String> getImportedNames() {
 return Iterables.emptyIterable();
 }
 
 public Iterable<IReferenceDescription> getReferenceDescriptions() {
 return Iterables.emptyIterable();
 }
 
 public URI getURI() {
 return uri;
 }
 
}

The grammar of our languages is pretty ssimple. Nothing new compared to earlier releases:

grammar de.itemis.graf.Xuml with org.eclipse.xtext.common.Terminals
 
generate xuml "http://www.itemis.de/graf/Xuml"
 
import 'http://www.eclipse.org/uml2/3.0.0/UML' as umlMM
 
// name attribute is extremely important.
 //Elements without a name attribute will not be exported!
 //
 XModel : name=STRING
 (imports+=Import)*
 (rules+=Rule)*
 (names+=Name)*;
 
Import :
 'import' importURI=STRING;
 
Rule:
 'references' umlClass=[umlMM::Class];
 
Name: 'name' name=STRING;

As in the other tutorials, you should copy the relevant-meta-models into your project. However, there's a lot of changes in the work flow. Have a look at this work flow to see how to adapt it to UML:

module de.itemis.graf.Xuml
 
import org.eclipse.emf.mwe.utils.*
 import org.eclipse.xtext.generator.*
 import org.eclipse.xtext.ui.generator.*
 
var grammarURI = "classpath:/de/itemis/graf/Xuml.xtext"
 var file.extensions = "xuml"
 var projectName = "de.itemis.graf.xuml"
 var runtimeProject = "../${projectName}"
 
Workflow {
 
bean = StandaloneSetup {
 platformUri = "${runtimeProject}/.."
 //        UML:important
 registerGeneratedEPackage = "org.eclipse.uml2.uml.UMLPackage"
 registerGeneratedEPackage = "org.eclipse.uml2.codegen.ecore.genmodel.GenModelPackage"
 
uriMap = { from = "platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore"
 to = "platform:/resource/de.itemis.graf.xuml/model/Ecore.ecore"
 }
 
uriMap = { from = "platform:/plugin/org.eclipse.emf.ecore/model/Ecore.genmodel"
 to = "platform:/resource/de.itemis.graf.xuml/model/Ecore.genmodel"
 }
 }
 
component = DirectoryCleaner {
 directory = "${runtimeProject}/src-gen"
 }
 
component = DirectoryCleaner {
 directory = "${runtimeProject}.ui/src-gen"
 }
 
component = Generator {
 pathRtProject = runtimeProject
 pathUiProject = "${runtimeProject}.ui"
 projectNameRt = projectName
 projectNameUi = "${projectName}.ui"
 language = {
 uri = grammarURI
 fileExtensions = file.extensions
 
// Java API to access grammar elements (required by several other fragments)
 fragment = grammarAccess.GrammarAccessFragment {}
 
// generates Java API for the generated EPackages
 fragment = ecore.EcoreGeneratorFragment {
 referencedGenModels = "platform:/resource/de.itemis.graf.xuml/model/UML.genmodel"
 // referencedGenModels = "uri to genmodel, uri to next genmodel"
 }
 
// the serialization component
 fragment = parseTreeConstructor.ParseTreeConstructorFragment {}
 
// a custom ResourceFactory for use with EMF
 fragment = resourceFactory.ResourceFactoryFragment {
 fileExtensions = file.extensions
 }
 
// The antlr parser generator fragment.
 fragment = parser.antlr.XtextAntlrGeneratorFragment {
 //  options = {
 //        backtrack = true
 //    }
 }
 
// java-based API for validation
 fragment = validation.JavaValidatorFragment {
 //                UML: Important
 //                composedCheck = "org.eclipse.xtext.validation.ImportUriValidator"
 //                composedCheck = "org.eclipse.xtext.validation.NamesAreUniqueValidator"
 registerForImportedPackages = true
 }
 
// scoping and exporting API
 fragment = scoping.ImportURIScopingFragment {}
 fragment = exporting.SimpleNamesFragment {}
 
// scoping and exporting API
 //            fragment = scoping.ImportNamespacesScopingFragment {}
 //            fragment = exporting.QualifiedNamesFragment {}
 //            fragment = builder.BuilderIntegrationFragment {}
 
// formatter API
 fragment = formatting.FormatterFragment {}
 
// labeling API
 fragment = labeling.LabelProviderFragment {}
 
// outline API
 fragment = outline.TransformerFragment {}
 fragment = outline.OutlineNodeAdapterFactoryFragment {}
 fragment = outline.QuickOutlineFragment {}
 
// quickfix API
 fragment = quickfix.QuickfixProviderFragment {}
 
// content assist API
 fragment = contentAssist.JavaBasedContentAssistFragment {}
 
// generates a more lightweight Antlr parser and lexer tailored for content assist
 fragment = parser.antlr.XtextAntlrUiGeneratorFragment {}
 
// project wizard (optional)
 // fragment = projectWizard.SimpleProjectWizardFragment {
 //         generatorProjectName = "${projectName}.generator"
 //        modelFileExtension = file.extensions
 // }
 }
 }
 }

In the Manifest, the Resource Provider has to be made known through an extension. If you add org.eclipse.uml2.codegen.ecore, org.eclipse.uml2.uml and org.eclipse.xtext.ecore you are ready to go and create and run a grammar references to UML. However, if you want to also use code generation, this is a good time to modify the StandaloneSetup.java class:
package de.itemis.graf;

import com.google.inject.Injector;
 
/**
 * Initialization support for running Xtext languages
 * without equinox extension registry
 */
 public class XumlStandaloneSetup extends XumlStandaloneSetupGenerated{
 
public static void doSetup() {
 new XumlStandaloneSetup().createInjectorAndDoEMFRegistration();
 }
 
// Change AG
 @Override
 public void register(Injector injector) {
 super.register(injector);
 org.eclipse.xtext.resource.IResourceServiceProvider serviceProvider = injector.getInstance(de.itemis.graf.UmlResourceServiceProviderImpl.class);
 org.eclipse.xtext.resource.IResourceServiceProvider.Registry.INSTANCE.getExtensionToFactoryMap().put("uml", serviceProvider);
 }
 
}

At this point, you can run the editor, create a UML model and reference the model elements from within your Xtext model.

On top, if you want to process this with Xpand, here is the work flow:

module workflow.XumlGenerator
 
import org.eclipse.emf.mwe.utils.*
 
import org.eclipse.xtend.typesystem.uml2.UML2MetaModel
import org.eclipse.xtend.typesystem.emf.XmiReader
import org.eclipse.xtend.typesystem.uml2.profile.ProfilingExtensions.XmiReader
var targetDir = "src-gen"
var fileEncoding = "Cp1252"
var modelPath = "src/model"
 
Workflow  {
 bean = org.eclipse.emf.mwe.utils.StandaloneSetup {
 platformUri=".."
 }
 bean = org.eclipse.xtend.typesystem.uml2.Setup {
 standardUML2Setup = true
 
 }
 
 bean = org.eclipse.xtend.typesystem.uml2.UML2MetaModel : umlMM {
 
 }
 
 bean = org.eclipse.xtend.typesystem.emf.EmfRegistryMetaModel : emfMM { }
 
 component = org.eclipse.xtext.mwe.Reader {
 // lookup all resources on the classpath
 useJavaClassPath = false
 
 // or define search scope explicitly
 path = modelPath
 
 // this class will be generated by the xtext generator
 register = de.itemis.graf.XumlStandaloneSetup {}
 
 load = {
 
 slot = "greetings"
 type = "XModel"
 
 }
 }
 
 component = org.eclipse.emf.mwe.utils.Reader  {
 
 uri = "platform:/resource/de.itemis.graf.xuml.generator/src/othermodel/My.uml"
 modelSlot = "umlmodel"
 }
 
 component = org.eclipse.xpand2.Generator {
 metaModel = umlMM
 metaModel = emfMM
 expand = "templates::Template::main FOREACH greetings"
 outlet = {
 path = targetDir
 }
 fileEncoding = fileEncoding
 }
}

And here an example of a template:

«IMPORT de::itemis::graf::xuml»
 
«EXTENSION templates::Extensions»
 
«DEFINE main FOR xuml::XModel-»
 
«FILE "dsl.txt"-»
«FOREACH this.rules.umlClass AS class»!«class.name»«ENDFOREACH»
This is an example of a generated file.
 
The input element was "Hello!"
 
All greetings in the same file:
«ENDFILE-»
«ENDDEFINE»
 
«DEFINE main FOR uml::Class-»
«FILE name+"uml.txt"-»
This is an example of a generated file.
 
The input element was "Hello!"
 
All greetings in the same file:
«ENDFILE-»
«ENDDEFINE»

Enjoy combining your DSLs with UML.

 

Installing Trufun UML Plato Free Edition

Posted on by
Reply

Last year I had already mentioned a free chinese UML tool in articles etc. I think it could be worthwhile investigating. However, since the website is all in Chinese, finding and downloading it is a problem for most Western people. Which is a pity, since the tool itself has both a Chinese and an English user interface.

The Home Page of Trufun is www.trufun.net , downloads are at http://www.trufun.net/www1/Ch/Downlist.asp The tools are based on Eclipse 3.5 (Galileo), but I just installed the Update-Version in Helios and it seems to run fine. Download http://download.trufun.net/uml/x/Plato-Free-Plugins-X-V3.0.zip and extract it into your Eclipse installation.

After starting your Eclipse, you are asked to update to the latest version. Don’t do this, this didn’t work on my installation. You can create new models with New->Other->Trufun UML Modeling.

Trufun stores its models as .tmx, which is a variant of uml2tools’ .uml format and can be converted with some tricks, so you can use Xpand etc. to use Xpand, Acceleo and other tools on the model. I will write about that in a later post.

Modeling Tool Usability Checklist – Element Deletion

Posted on by
Reply

Working with modeling tools that provide different views on the same model (like UML with diagrams) can be an interesting experience. The relationship between model and views introduces some challenges for usability, which is addressed differently by tools. These aspects can easily confuse those that do their first steps in modeling and annoy those that work with several tools. I suggest that you might want to have some checklist for your tool for quick reference to navigate these quirks. In a number of blog posts, I will propose and explain this checklist.

For illustration, I am working with Papyrus/MDT. Papyrus at the time of writing is available in version 0.7.0. Usability might change, but Papyrus is only used to illustrate the checklist, not to comment on the tool itself.

Checklist: In your tool, what commands are used for local deletion (in diagram) and from model.

Assume we have a small UML model with three classes, RainSensor, RainSensor Variant and SunRoof in two diagrams A and B.

Diagram A

Diagram A

Diagram B

Diagram B

It is important to remember, that diagrams are only views on the model. The actual model can be seen in the tree view. Obviously we should only find one RainSensor in the model.

Model Viewer

Diagrams are views on the model.  This has a view implications on usability. If we have a look on the context menu of Papyrus, we see two commands for deletion:

Deletion Commands

These two kinds of deletion commands can be found with all kinds of different naming conventions in graphical modeling tools. 2) will remove the symbol from the diagram without modifying the model. 1) will actually remove the model element. If you try 2), the model will not be changed. However, this is how the screenshots change after you choose 1): Since the model element has been deleted, its symbol is removed from Diagram B.

Don’t confuse the two, you might accidentally remove elements. It would be great if your tool had functionality to show you the impact of a deletion (the impact of any change would even be better).

Model elements can also be deleted by using the pop-up from the tree view:

Checklist: Check the semantics of Undo

If you try the above in any of your tools, try the undo function as well and see what your tool does. If you try the steps above and use undo after deleting from within the diagram, you will get the following results:

and, unexpectedly:

This tool does not undo any side effect a change has on other diagrams! Be sure to check the semantics of undo, to make sure you do not loose any data.

Checklist: Changes on closed diagrams

If you close the diagram (i.e. it is not open for editing), changes can have a different semantics. Again, deleting the model element RainSensor from within Diagram A, but having closed Diagram B results in the expected deletion of the model element. This is how B looks after opening it again:

Suddenly, there is an element “model” in there? What happened? Tools that do not actively update closed diagrams when the model changes, have to check the consistency of diagram and model upon opening. This specific tool seems to follow the strategy to replace references to non existing model elements with references to others. Check what your tool does!

Checklist: Collaboration

Several people working on one model at the same time opens another can of worms. Without going into detail: Check how deletions by one person are propagated throughout the system.

Checklist: Find unreferenced elements

You can easily imagine, that you might delete an element from the diagram, actually forgetting about it. But it is still there in the model. Does your tool have functionality to find unreferenced elements? You wouldn’t want to browse through all the diagrams just to find the unused items.

The next post on the topic will be on element renaming.

Modeling AUTOSAR with UML / Papyrus

Posted on by
2

In the early days of AUTOSAR (Release 2.0) there was the idea of using UML tools for AUTOSAR modeling by applying profiles. At this time, an actual profile had been defined as part of the documents provided by AUTOSAR (http://www.autosar.org/download/R2.0/AUTOSAR_UML_Profile.pdf).  This document has not been updated further, partly because the main contributor (an UML tool provider) left AUTOSAR at that time. I was never convinced that the UML profile approach was feasible. Grafting AUTOSAR on top of UML requires mapping a complex meta-model to another. In terms of AUTOSAR ECU configuration, there is no real correspondence in UML and the UI of the UML tool would have to go major changes. Today, with the availability of an AUTOSAR meta-model tooling in the form of Artop, domain specific languages and graphical editing frameworks (GMF/Graphiti), the approach is even less feasible IMHO.

You can easily create AUTOSAR software-component models with textual modeling by using ARText. There is, however, no low-cost tooling available right now for showing graphical models. So if you want to avoid license costs and still be able to graphically software components, for this case, an UML profile could be one approach. Both AUTOSAR and UML provide a component model, so the meta-model structures have more similarities than in other areas of AUTOSAR.

The nice thing is, that you can use open source UML tools for modeling. If you use Papyrus, you can easily define stereotypes for AUTOSAR:

The basic component types of AUTOSAR are easily added. But the great thing is that Papyrus allows you to change the graphical representation of elements depending on the stereotype. AUTOSAR defines a certain notation for sender/receiver ports, so we can bring this notation to Papyrus by first defining a stereotype for sender and receiver ports:

Note the “<Image>” elements in the property sheet. You can set these to any image. To do this, you have to locate them in the model browser and load an image by pressing the “+” button. After that, the “+” button will be replaced by a preview of your icon:

Now go ahead to model in “AUTOSAR”-style (change the appearance of the ports in the corresponding tab to “icon”):

Of course, you now have an UML model. But with Eclipse M2T/M2M technologies you can transform that to an AUTOSAR model.

Relocation

Posted on by
Reply

The itemis south branch has been operating out of Pforzheim (which is 50 kms west of Stuttgart) for several years and we are really having nice offices in a good environment here. However, for a number of reasons, we feel that there are a number of factors that made us re-evaluate the Pforzheim location:

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

Integrating the AUTOSAR tool chain with Eclipse based model transformations

Posted on by
Reply

Integrating the AUTOSAR tool chain with Eclipse based model transformations

Andreas Graf1,Markus Völter2

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

Visual CV

Posted on by
Reply

Just when I was thinking on how to replace the bullet point hell for introducing my CV vor an upcoming talk I came across a TED talk by David McCandless (http://www.ted.com/talks/david_mccandless_the_beauty_of_data_visualization.html). He provides a slide with colored bars for his CV which I consider visually fresh. So I decided to try one with Excel and with a little trick these can be made rather easily:

Obviously the first steps are to fill in your data with numbers reflecting the intensity of topics (I used 1-5). You can then use the “conditional formatting -> color scales” to get the formatting right. However, at this points, the actual data will still be in the cells cluttering the view.

Just use the “cell formatting->numbers” and pick “user defined” and enter a blank in the entry field. The numbers of the cells will disappear from view, but if you select a cell, you will still be able to edit it in the formula entry box of excel.

Requirements Traceability for Eclipse

Posted on by
2

Within the publically funded research project VERDE we are implementing not only an Eclipse-based ReqIF based editor as outline in a previous blog post, but also a traceability solution, since requirements alone would be moot.

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