Supporting Model-To-Transformation in Java with AspectJ

There are a number of Model-To-Model-Transformation Frameworks provided under the Eclipse umbrelle (e.g. QVTO). Some of these provide a lot of support. However, in some scenarios, you need to either adapt them or implement your own M2M with Java. For us, some of the cases are:

  • Framework does not support model loading saving with Sphinx
  • Framework does not support EMF unsettable attributes (eIsSet)
  • Framework performance.

However, one of the most annoying problems in writing transformations is caching already created elements. Consider the following abstract example:

  • Our source model has an element of type Package ‘p’
  • In the package, there are sub elements ‘a’ and ‘b’
  • ‘a’ is a typed element, it’s type is ‘b’

Usually when mapping the contents of p, we would iterate over its contents and transform each element. However, when transforming ‘a’, the transformed element’s ‘A’ type should be set to the transformed ‘b’ (‘B’). But we have not transformed it yet. If we transform it at this point in time, it will be transformed again when iterating further through the package, resulting at two different ‘B’ in the target model.

Obviously we should keep a Cache of mapping results and not create a new target instance if a source element has been transformed before. However, managing those caches will clutter our transformation rules.

But it is quite easy do factor this out by using AspectJ. First, we define an annotation for methods that should be cached:

 

Then we define an aspect that intercepts all calls to methods annotated with @Cached:

  •  In line 14, we build a cache key out of the current object, the method called and its arguments
  • If this combination is already cached, we return the key entry
  • otherwise we proceed to the original method and cache its result

The transformator then looks like this:

(OK, so this is Xtend2 rather than Java, because the polymorphic dispatch comes handy).

Note that we are transforming EAST-ADL models here. The package contains Units and Quantities. Units refer to Quantitites. Quantity transformations are called twice: From the package transformation and from the Unit transformation. However, by using the caching, we get the correct structure.

In addition, we also solve a little annonying problem: Elements have to be put in the containment hierarchy as well. But that would require additional code in the transformators and passing around the containers.

In line 25 in the aspect, we check if the target object implements the AutoAdd interface and call the method in that case. So the transformation can take care of the addition to the containment hierarchy at a defined place.

The code above is an implementation prototype to show initial feasability.

 

 

Travel Tips for EclipseCon France

EclipseCon France is one of my favourite conferences. If you are going, here are some tips:

  • I prefer to book a hotel in the city centre, e.g. near Jean Jaures (https://goo.gl/maps/RKkQJ). A lot of the restaurants are within walking distance and there a lot of locations that you can use to meet with other participants.
  • There is a bus shuttle between the airport and the city centre (Jean Jaures) that also stops right in front of the EclipseCon venue. And it is reasonably priced.
  • Toulouse has a dense network of public bicycle rental stations. So instead of using the metro, you might want to choose to pedal your way to EclipseCon – it is within reasonable distance and there are bike stations in front of the venue and in near vicinity.
  • Although you will find Wifi at the venue and at hotels, I prefer the prepaid internet SIM by SFR or Orange. If you have a mobile wlan hotspot or you can use SIM cards in your notebook, that is my preferred option. Orange and SFR are both right at the city center. You can get a prepaid SIM easily – but bring a passport / ID card for registration.

Enjoy an interesting conference in a beautiful city in early summer!

 

Open Collaborations for Automotive Software – and Eclipse

On June 4th itemis is hosting a conference on Open Collaborations for Automotive Software (in German) in Esslingen near Stuttgart. There are a lot of interesting talks and – while not immediately obvious – all of them do have some relation to Eclipse.

  • Open Source OSEK: Erika Enterprise is the first certified Open Source OSEK. And it uses Eclipse based tooling for the configuration / development of OSEK based software
  • COMASSO is a community based AUTOSAR BSW implementation. It comes with BSWDT, an Eclipse-based AUTOSAR configuration tool that leverages technologies like EMF and Xpand
  • SAFE RTP Open Source Platform for Safety-Modeling and -Analysis: This tooling is completely based on Eclipse and features the EAST-ADL implementation EATOP, that is published within the Eclipse Automotive Industry Working Group
  • openMDM: Open Measured Data Management: Again, a community based tooling for the management of measured data, based on Eclipse.
  • Strategic Relevance of Open Source at ETAS GmbH: ETAS GmbH builds a lot of automotive tools on Eclipse and they will talk about the business relevance of open source / Eclipse.
  • Advanced Technology for SW Sharing – Steps towards an open source platform for automotive SW Build Systems: A new build system framework for automotive ECU framework – based on Eclipse

Eclipse is a key technology in automotive software engineering and the conference will introduce many interesting aspects.

AUTOSAR reports with Artop and BIRT

Even in times of model-based development, artefacts like pdf and Word are still important for documentation. With Eclipse based technologies, it is easy to produce documents in various formats from your AUTOSAR xml.

One approach would be to use Eclipse M2T (model-to-text) technologies to generate your own reports. Technologies for that would be Xtend2 or Xpand. An article can be found here.

However, with the Eclipse BIRT project, there is also a more WYSIWYG approach. Taking a very simple AUTOSAR model as an input, we can easily create reports in most formats.

2013-12-17_11h34_27

After creating a BIRT project, we have to configure a so called “Data Source”, that simply takes our ARXML as input:

2013-12-17_11h35_30We then configure one or more “Data Sets” that actually pull the data from the data source:

2013-12-17_11h36_48From there it is mostly drag and drop and maybe a little scripting to create the report in the WYSYWIG editor – it also supports a lot of styling and templating. Including images, custom headers etc:

2013-12-17_11h38_04As you can see, we do create a table with a row for each SWC-Type with the shortname and a subtable for all the ports of that SWC-Type. The BIRT Report Viewer shows the report in HTML.

2013-12-17_11h39_54

By clicking on “Export Report” we can export to a number of formats:

2013-12-17_11h41_39

PDF:

2013-12-17_11h43_12

Excel:

2013-12-17_11h44_27BIRT and ARTOP provide powerful reporting functionality.

 

 

Support for vendor specific parameter / module definitions in COMASSO basic software configuration tool

During the 6th AUTOSAR Open Conference one of the presenters pointed out, that integration of vendor specific / custom parameter definitions into the tool chain can be problematic because of insufficient tool support. Some tools seem to have hard coded user interface for the configuration or proprietary formats for customization.

The COMASSO basic software tooling chose a different approach: User interface and code generator framework are dynamically derived from the .arxml in the workspace and all the configuration data is directly stored in .arxml (so no Import/Export of models is required, just drag and drop).

NVRAM Example

In one minimal example that we use for training purposes, we have a parameter definition for a NvRam module (stripped from the official AUTOSAR definition). In the “file system” view, the param def can bee seen in the workspace.2013-11-15_14h14_09

This results in the “Model view”:2013-11-15_14h14_30Introducing a vendor specific module

Now, assume the construed scenario, that we would like to provide a BSW/MCAL module for a Graphical Processor Unit (GPU). For the configuration tool to work, all what we need is a param definition for that.

Although COMASSO does not require a specific project structure, for convenience, we copy the NvM file structure and create an new param def callsed GpU_ParamDef.arxml. In XML, we define a new module:

After saving the new param def .arxml, the tool scans the workspace and rebuilds the user interface.

2013-11-15_14h26_25Without a single line of additional code, the tool knows about the vendor specific parameter definition. The icon in front of the GPU is grey, because we do not have configured any data yet. Opening the editor shows that it knows about the VSMD now as well:

2013-11-15_14h29_42Any configuration here will be directly stored as values in a .arxml file.

 Code generation

But not only the user interface knows immediately about the vendor specific modules – so does the generation and validation framework. As you can see below, we can now directly access the GPU module configuration from the AUTOSAR root (line 11) and then loop through the new GPU descriptors (line 12).

And the content assist system is working with the information as well. No need to remember what we defined. In line 16 we invoke content assist on “d” (which is a GPUBlockDescriptor) and get suggestions on all the attributes.

2013-11-15_14h34_47Open Language

The code generation and validation framework is Eclipse Xtend/Xpand. It is publically available and not a proprietary solution.

Parameter Description

In addition, when clicking on an element in the configuration editor, there is a documentation view that shows the important information from the .arxml in a nicer view. Any documentation that is stored in the .arxml will be easily accessible.

2013-11-15_14h38_30

 

 

 

 

 

 

 

Functional Architectures (EAST-ADL) and Managing Behavior Models

In the early phases of systems engineering, functional architectures are used to create a functional description of the system without specifying details about the implementation (e.g. the decision of implementation in HW or SW). In EAST-ADL, the building blocks of functional architectures (Function Types) can be associated with so-called Function Behaviors that support the addition of formal notations for the specification of the behavior of a logical function.

In the research project IMES, we are using the EAST-ADL functional architecture and combine it with block diagrams. Let’s consider the following simplified functional model of a Start-Stop system:

2013-11-10_12h53_32In EAST-ADL, you can add any number of behaviors to a function. We already have a behavior activationControlBehavior1 attached to the function type activationControl and we are adding another behavior called newBehavior.2013-11-10_12h54_06

A behavior itself does not specifiy anything yet in EAST-ADL. It is more like a container that allows to refer to other artefacts actually containing the behavior specification. You can refer to any specification (like ML/SL or other tools). For our example, we are using the block diagram design and simulation tool DAMOS, which is available as open source at www.eclipse.org.

We can now invoke the “Create Block Diagram” on the behavior. 2013-11-10_12h55_34

The tool will then create a block diagram with in- und output ports that are taken from the function type (you can see in the diagram that we have two input ports and one output ports).2013-11-10_12h56_20 Add this point, the architects and developers can specify the actual logic. Of course it is also possible to use existing models and derive the function type from that (“reverse from existing”). That would work on a variety of existing specifications, like state machines, ML/SL etc.

A DAMOS model could look like this:2013-11-10_12h56_48

At this point of the engineering process, we would have:

  • A functional architecture
  • one or more function behaviors with behavior models attached to the function types

Obviously, the next thing that comes to mind is  to combine all the single behavior models and to create a simulation model for a (sub-) system. Since we might have more than one model attached to a function, we have to pick a specific model for each of the function types.

This is done by creating a system configuration.2013-11-10_13h02_52That will create a configuration file that associates a function type (on the left side) with a behavior model (right side). Of course, using Eclipse Xtext, this is not only a text file, but a full model with validation (are the associated models correct) and full type aware content assist:2013-11-10_13h16_52After the configuration has been defined, a simulation model is generated that can then be run to combine the set of function models.

 

 

 

 

 

COMASSO BSW generation and validation

The COMASSO initiative provides a community-sourced AUTOSAR 4.x basic software stack and tooling to work with that. One of the tools is the BSWDT, which uses the Eclipse projects Xpand and Xtend for model checking and code generation. It provides not only the BSW in readable form, but also the code generators and validators are there for you to inspect, learn from and modify. This blog article shows how to find your way around those files.

First of all, we need to create a simple Eclipse project (File->New Project…) and then make it a BSW configuration project by invoking the context menu on the project and setting the project configuration:

2013-11-04_15h50_35

After that, we import the BSW and BSW code generators into the project:

2013-11-04_15h52_46You will notice that there is a directory for each of the BSW modules. You will find the Xpand/Xtend files under each modules sub-path scripts/templates/

2013-11-04_15h54_09The relevant file types are:

  • .chk: These contain model validations and checks
  • .xpt: The actual code generators
  • .ext: Model-to-Model transformations and utility functions
  • .oaw: Workflow files (not discussed here)
  • .bamf: Build action manifests.

All files except the .bamf come from the Eclipse Project xpand/mwe. The .bamf files are an implementation of the AUTOSAR build action manifest. In short, the bamf files invoke the oaw-files which in turn invoke .chk, x.pt and .ext. The details will not be discussed here.

Checks

However, we will have a look at the .chk files. A .chk files consists of a number of context statements. A context statement of a specific type will be invoked for all occurances of that type in your model. This is a very simple check for the ComMChannel. No need to loop through the model yourself, everything is done by the framework:

2013-11-04_15h58_00More complex checks can be factored into dedicated subroutines:

2013-11-04_15h59_58Depending on the .bamf-Configuration a failed check can result in a stop of the build process.

Code

Code generation is done with Xpand. Xpand is a template based language that allows you to easily specifiy the generators. The big advantage is the flexible type system, that derives the available types from the param-defs in your workspace. So if you have vendor-specific param defs, all the types will be immediately available in the language as first-class types.

2013-11-04_16h02_24Note that everything highlighted blue in the example above will be printed 1:1 in the output and the statements between ‘<<’ and ‘>>’ will be evaluated on the model. Note in line 124 that complex queries are possible. Of course, Xpand provides a comfortable set of additional statements for outputing code.

Transformation

The files under “generateid” are used for automatically setting information prior to generation – e.g. by generating ids. An example from LIN could be:

2013-11-04_16h08_26Note that Xtend/Xpand offer full content assist – no need to refer to the AUTOSAR spec to find out which elements are supported.

Profiling

The system comes with a profiling component that supports analysis of the time spent in checks and generation. Profiling will be introduced in another blog post.

 

 

 

 

Generating AUTOSAR basic software with Xpand and Artop

AUTOSAR basic software can be configured by a lot of different parameters. Both for AUTOSAR standard modules and vendor specific basic software modules, the parameters that can be configured are defined in parameter definitions and the actual values are configured as parameter values.
In Artop, both reside in .arxml files in the workspace.

Note: The following code generation mechanism is also used in the COMASSO BCT configuration tool, altough the UI and some technical aspects are different.

The developer of a basic software module needs to develop a tool that transform a module configuration into something that can be used for the final software, often C-Code or other artefacts. For AUTOSAR code generation, we need two features in code generation:

  • A comfortable mechanism for code generation. Printing out code with print-Statements is cumbersome. State of the art code generators are template-based.
  • A powerful type system. We would like to see the modules and attributes that are defined in the parameter definitions as first-class citizens in our transformation language – this is a prerequisite for readable and maintainable code.

The first feature is provided by Xtend/Xpand out-of-the-box. Xpand is a template-based code-generator. It also comes with hooks for a flexible type-system, which Artop uses to provide the second feature: The .arxml parameter definitions in the workspace are dynamically scanned and the defined modules, attributes etc. are usable in template development without any compilation steps.

So to print out a list of CanIfInitConfigurations for a given CanIf, we can just have

2013-10-09_12h05_38This will brint the shortName of the CanIf and a list of all CanIfInitConfiguration’s shortNames. This will work for custom param defs as well.

2013-10-09_12h05_46Of course, a real generator will be more complex. Artop also brings a GUI integration. A dialog-box for choosing a generator template can be directly invoked from the user interface:

2013-10-09_12h06_10

 

 

 

 

 

A common component model for communication matrixes and architecture metrics for EAST-ADL, AUTOSAR and others.

In the engineering process, it is often of interest to see communication matrixes or metrics for your architecture. Depending on the meta-model (EAST-ADL, AUTOSAR, SysML)  and the tool, that kind of information might or might not be available. In the IMES research project, we are using the Eclipse-Adapter mechanism to provide a lightwight common component model that adapts to the different models on the fly.

The Eclipse Adapter Mechanism is used to provide a common model for different meta-models

The Eclipse Adapter Mechanism is used to provide a common model for different meta-models

The tool implements different views / editors and metrics, that work on the common component model, providing the mechanism for EAST-ADL analysis and design functions, error models and AUTOSAR software architectures.

The following EAST-ADL model

A small EAST-ADL analysis function model.

A small EAST-ADL analysis function model.

can be shown in the communication matrix editor, which uses the same code for EAST-ADL and AUTOSAR.

2013-08-08_09h33_19

 

 

 

AUTOSAR splittables and Artop

AUTOSAR splittables are a powerful modelling mechanism. In short, they allow you to split the contents of packages and other model elements over more than one .arxml (you can find more in my old post on this topic). However, it also poses a challenge to tool providers, since models have to be merged. There are several approaches, from shadowed merge models to using Java proxies. Most of these approaches have limitations with respect to modifications of the model or that the editor needs to be aware of the specific API used to merge the model.

Recently, we have been experimenting with some of the more advanced features of the Eclipse platform to start a AUTOSAR model merge that could be completely transparent to any client accessing the Artop model (be it an interactive editor, a code generator, or a M2M model transformation). As an example, we use the standard WP 10 .arxml as devlivered by AUTOSAR: Below, you see that a number of ARXML are in the workspace and that the package AUTOSAR/AISpecification is split over more than one .arxml file.

2013-08-07_17h38_04With activation of our plugin, the Artop model navigator now sees merged models – no modification of any code in Artop core or the navigator is necessary. The view now looks like this:

2013-08-07_17h41_47

The navigator sees only one package AISpecification with merged sub-packages now. Editing is a little more difficult and a proof of concept for that is up next.