Open Tool Platform:

Is a common meta model sufficient?

Mark Brörkens, Robert Mitschke

OpenSynergy GmbH, Rotherstraße 9, 10245 Berlin

{mark.broerkens, robert.mitschke}@opensynergy.com

Abstract. The standardization organizations AUTOSAR and Automotive HIS

have defined formal UML models for specifying data exchange formats. These

models can be used as an input for automatically generating Eclipse EMF based

tool platforms. This paper discusses some aspects that might become important

if the platform is used by multiple plug-ins simultaneously.

Introduction

Automotive system development demands frequent exchange of data between

different parties and tools. In order to improve the interoperability between tools,

standardization organizations have put high effort into defining data exchange

formats. Many data exchange formats have been created by manually writing XML

DTDs or XML Schema. UML was only used for documentation purposes.

Due to the increasing complexity of data that is to be exchanged, the standardization

organizations AUTOSAR and Automotive HIS switched to a model based approach.

The data structures of the AUTOSAR data exchange format and the HIS

Requirements Interchange Format (RIF) are formally defined using annotated UML

class diagrams. These UML models were used as a source for automatically

generating the XML Schemas and huge parts of their documentation. This model

based approach increased the maintainability, consistency and quality of

documentation of the data exchange formats.

In addition to the benefits within the standardization activities, this approach allows

for automatically generating tool platforms for the exchange formats. At

OpenSynergy we use the Eclipse Modeling Framework (EMF) to generate an internal

tool platform for AUTOSAR. The adaptation to the AUTOSAR specific XML

representation is implemented using QVT Operational transformations which are also

generated out of the input UML model.

Since all tool vendors that provide support for AUTOSAR or RIF have to implement

access to the standardized data exchange format, we think that it is very beneficial if

they jointly develop and share the same tool platform. However, the generated EMF

model, edit and editor classes extended by a custom resource for AUTOSAR do not

2 Mark Brörkens, Robert Mitschke

seem to be sufficient, in particular if plug-ins from different vendors are bundled

together in one application and share the same internal model.

The following chapter shortly describes the AUTOSAR system development

methodology which will be referenced in later chapters which sketch up possible

issues and how they could be handled.

AUTOSAR methodology

Figure 1 depicts the AUTOSAR methodology: The blue boxes describe data that is

represented in the AUTOSAR data exchange format. The grey arrows represent

complex generation steps which require tooling with complex algorithms or

engineering work.

Fig. 1. AUTOSAR Methodology: from high level system description to code

generation.

Authoring Tools (not shown in the figure) are required to create the high-level inputs

of the AUTOSAR methodology.

The System Configuration Generator step includes the mapping of Software

Components onto ECUs and the calculation of information that must be agreed

between different ECUs.

The ECU Configuration Generator step includes deriving and refining configuration

values for each ECU in the system.

For each Basic Software Module that is to be integrated on the ECU a Generator step

is required which generates configuration specific code.

per System per ECU

Generator for Module B

SW Component

Description

System Constraint

Description

System Configuration

Description

Extrac t of System

Configuration for

ECUn

Extrac t of System

Configuration for

ECU1ECU Resource

Description (HW

only)

ECU Configuration Description

COM Extrac t of

ECU Configuration

Basic Software

Module B Extract

of ECU

Configuration

System Configuration

Generator

ECU Configuration

Generator

RTE Extrac t of

ECU Configuration

Basic Software

Module A Extract

of ECU

Configuration

Generator for RTE

Generator for COM

Generator for Module A

System Level Data ECU Speci fic Data Module Spe cific Datacomplex generation step:

complex algorithm or

engineering work

Open Tool Platform:

Is a common meta model sufficient? 3

Open Issues

Data Consistency

When bundling up several plug-ins that interact with a common model, data

consistency becomes more and more. E.g.: There might be a generic ECU

configuration editor and several module generators. In order to avoid inconsistent

results, it is not allowed to change the model while a generator is running.

Additionally, it is not allowed that a module generator makes changes to the model.

This could result in non-deterministic behavior if multiple generators are applied in

different sequences.

Discussion:

• An intermediate layer between the model and the plug-ins is required that

controls the read and write access to the model.

• Eclipse Model Transaction Framework looks promising.

Access Control

Artifacts created during the system lifecycle typically go through a restrictive

approval process. Approved document or model fragments shall not be changed in

later steps of the lifecycle. Another example for the need of access control is part of

the RIF standard which provides AccessPolicies for define access rights for each

model element.

Discussion:

• The tool platform should be able to provide information about the access

rights for each model element. This information can be used by interactive

editor to guide the user. Additionally, the platform should ensure that e.g.

read-only elements are not changed by any plug-in.

• This issue could be handled by the Model Transaction Framework. A post

validation rule that checks for modifications on read-only elements might

help. If a not allowed modification is performed then the Transaction

Framework could roll back to the previous values.

Model validation

The AUTOSAR data exchange format supports several phases during the

development process. If several plug-ins that are designed for different phases are

bundled together in one application then the validation algorithms implemented in the

different plug-ins might conflict. A model that is perfectly consistent and complete for

one plug-in might be invalid and incomplete for another plug-in.

4 Mark Brörkens, Robert Mitschke

Discussion:

• Applying the validation algorithm of all installed plug-ins at the same

time doesn’t seem to be suitable. A more fine-grained selection of to be

applied validations is required. As a minimum it should be possible to

switch off the validation algorithms and plug-ins that an engineer doesn’t

need for his use-case.

Integration of plug-ins from different vendors

Although Eclipse supports a powerful mechanism for integrating plug-ins from

different vendors, it often turns out that each vendor integrates himself at different

locations into the Eclipse application. Although this might be ok for a small amount

of plug-ins, this might clutter up the application if many plug-ins are integrated.

Discussion:

• It might be useful to categorize the plug-ins that be built on top of the tool

framework. Examples of categories could be “editors”, “code generators”,

“validators”. For each category a dedicated extension point could be

provided that takes care of the integration into the system and the

invocation of the typical functions.

Furthermore, Java and Eclipse provide numerous alternatives for solving the same

problem. For example logging: openArchitectureWare uses apache.common.logging,

the Eclipse QVT Operational implementation makes use of JDK logging, other plug-

ins make use of Eclipse build-in logging. It is difficult or in some cases even

impossible to change the log behavior without modifying the plug-ins themselves.

Discussion:

• The tool platform should provide a central logging mechanism that should

be used by all plug-ins.

Summary

The generated Eclipse EMF model, edit and editor classes in combination with a

custom resource for access to AUTOSAR or RIF XML representations are a good

starting point for a common tool platform. However, additional aspects such as data

consistency, access control, model validation, and common implementation rules for

plug-ins should be considered if the tool platform is intended to be used by several

plug-ins of different vendors at the same time.

Open Tool Platform:

Is a common meta model sufficient? 5

References

1. AUTOSAR GbR. AUTOSAR Homepage. http://www.autosar.org.

2. Automotive HIS. Specification Requirements Interchange Format (RIF),

http://www.automotive-his.de/rif.

3. Michael Rudorfer, Tilman Ochs, Paul Hoser, Martin Thiede, Martin Mîssmer,

Oliver Scheickl and Prof. Harald Heinecke. Realtime System Design Utilizing

AUTOSAR Methodology. elektroniknet.

http://www.elektroniknet.de/home/automotive/autosar/english/being-on-time/