Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Open Tool Platform:
                Is a common meta model sufficient?

                             Mark Brörkens, Robert...
2   Mark Brörkens, Robert Mitschke

seem to be sufficient, in particular if plug-ins from different vendors are bundled
Open Tool Platform:
                                                  Is a common meta model sufficient?  3

Open Issues

4   Mark Brörkens, Robert Mitschke

       • Applying the validation algorithm of all installed plug-ins at ...
Open Tool Platform:
                                            Is a common meta model sufficient?  5


1. A...
Upcoming SlideShare
Loading in …5

ESE2008 Automotive Symposium Broerkens


Published on

Published in: Automotive, Technology
  • Be the first to comment

  • Be the first to like this

ESE2008 Automotive Symposium Broerkens

  1. 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} 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. 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. 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. 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. 5. Open Tool Platform: Is a common meta model sufficient? 5 References 1. AUTOSAR GbR. AUTOSAR Homepage. 2. Automotive HIS. Specification Requirements Interchange Format (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.