The document discusses whether a common meta model is sufficient for an open tool platform used by multiple plug-ins from different vendors simultaneously. While a generated Eclipse EMF model provides a good starting point, additional aspects like data consistency when multiple plugins interact with the shared model, access control for read-only elements, selecting appropriate model validations, and common integration and logging mechanisms need to be addressed. The model transaction framework may help handle issues regarding data consistency and access control.

1. 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. 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.
per System per ECU
ECU Configurati on Description
System Configuration
Descri ption
Generator for RTE
SW Component RTE E xtrac t of
Descri ption ECU Confi guration
ECU Configuration
Extrac t of S ystem Generator
System Configuration Generator for COM
Configuration for
ECU Resource Generator
ECU1 COM E xtrac t of
Descri ption (HW
ECU Confi guration
only)
Extrac t of S ystem
Configuration for
System Constraint
ECUn
Descri ption
Generator for Module A
Basic Softw are
Generator for Module B
Module A Extract
Basic Softw are
ModuleCU Extract
of E B
Configuration
of E CU
Configuration
complex generation step:
System Le v el Data ECU Speci fic Data Module Spe cific Data complex algorithm 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.

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

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