AUTOSAR System Modeling in IBM Rational Systems Developer

AUTOSAR integration with IBM® Rational® Systems Developer enables you to model automotive systems. It supports both UML-based modeling and domain-specific modeling of AUTOSAR-compliant automotive software. The tool also supports bi-directional model-to-model transformation from UML to a domain-specific language (DSL), giving you the flexibility to author in either environment.

Share:

Manoj Paul (manojpaul@in.ibm.com), Systems Software Engineer, IBM

Manoj Paul is a Systems Software Engineer at the IBM Rational Software Bangalore Lab. He works for the Rational Systems Developer team. He is presently involved in the development of the AUTOSAR Modeling tool in Rational Systems Developer.



Steve Rooks (Stephen.Rooks@uk.ibm.com), Technical Specialist, IBM

Steve Rooks is a Technical Specialist at IBM Rational Software, with a long history of model driven systems development whilst working at AT&T Bell Labs, ObjecTime, and IBM Rational. He represented IBM in AUTOSAR phase one.



12 August 2008

Also available in Chinese

Introduction

This article gives you a brief introduction to the AUTomotive Open Systems ARchitecture (AUTOSAR) standard for automotive system development. It discusses the Model Driven Development (MDD) of automotive systems, and domain-specific modeling support provided through a set of plug-ins in IBM® Rational® Systems Developer. The article covers the following features:

  • UML-based AUTOSAR system development
  • Domain-specific modeling support for AUTOSAR
  • Visualization of AUTOSAR domain elements using the MMI (Meta-Model Integration) framework
  • Bi-directional transformation of AUTOSAR UML and DSL models

Automotive Open Systems Architecture

The advent of innovative vehicle applications and the increasing demand for sophisticated features in today’s vehicles has led to the development of complex software and electronic systems for vehicular systems. The lack of standards in developing them gives rise to several problems. Proprietary software applications become hardware specific, restricting their use in other hardware platforms, which makes managing the software application complex. The development cost also increases.

AUTOSAR is open and standardized automotive software architecture, jointly developed by automobile manufacturers, suppliers, and tool developers. The objective of this consortium is to create a de-facto standard for vehicle-internal software infrastructure and architecture, allowing:

  • Transferability of software components over different hardware platforms
  • Re-use of basic software components
  • Easier software updates and upgrades over vehicle lifetime
  • New business and collaborations models for OEMs and suppliers

The standard will serve as a platform upon which future vehicle applications will be implemented, and will also serve to minimize the current barriers of re-using and maintaining them. It will, therefore, be possible to map vehicle functions and functional networks to different hardware environments.


Modeling AUTOSAR systems

AUTOSAR has specified its own DSL, which allows automotive engineers to model a vehicle's electrical and electronic systems in a familiar way. The language has four major sections, which are called templates. These are:

  • Software Component (SW-C) incorporating Virtual Functional Bus (VFB) concepts and behavior
  • Electronic control unit (ECU) for hardware description
  • Systems for ECU topology, and for mapping logical components onto physical components
    • Dependent on SW-C and ECU templates
  • ECU Configuration for describing basic software configuration

In addition a methodology has been specified that describes the process of using the templates to describe, build, and configure an ECU.

This section explores the usability of Unified Modeling Language (UML) for modeling AUTOSAR systems, and possible challenges that are being faced.

UML-based modeling of AUTOSAR systems

AUTOSAR modeling support in Rational Systems Developer explores the possible mapping from AUTOSAR meta-model 2.1 to UML 2.1. There is good overlap between the two domains for some templates, so a UML profile can be defined. AUTOSAR system development using UML and a profile has been implemented in Rational Systems Developer. This provides several advantages, because you can readily use the diagram and analysis support provided by IBM® Rational® Software Modeler.

Figure 1 shows a VFB view using a UML structure diagram with the AUTOSAR profile.

Figure 1. AUTOSAR system modeling with UML
tree view on left, model on right

The AUTOSAR modeling support with Rational Systems Developer allows you to create custom menus (like those shown in Figure 2) for creating model elements, which means that you can create AUTOSAR stereotyped UML elements directly. You can use UML class or structure diagrams for modeling AUTOSAR software components, as well as modeling ECU (to some extent). You can capture the VFB structure for software components nicely using UML structure diagrams.

Figure 2. Creating an AUTOSAR stereotyped UML object
menu command

Limitations of UML

Although you can use UML to capture some aspects of AUTOSAR modeling (like software component templates), other AUTOSAR templates (like the ECU or System templates) cannot be modeled entirely using UML, as shown in Figure 3. This creates a requirement for domain-specific modeling for AUTOSAR. The next section discusses the DSL tool designed for modeling domain-specific issues for AUTOSAR.

Figure 3. How UML 2.1 overlaps with AUTOSAR 2.1 templates
diagram with partially overlapping ovals

AUTOSAR domain-specific language tool

As discussed in the previous section, UML alone is not sufficient to capture every aspect of AUTOSAR modeling. This gives rise to the requirement for domain-specific modeling (DSM) support within the modeling tool. The DSL is the underlying model for a domain to perform DSM, and it is generally captured in the form of a meta-model. The AUTOSAR meta-model can be implemented using the Eclipse Modeling Framework (EMF). The DSL tool designed on Rational Systems Developer provides domain-specific modeling support using an ecore model, which is directly created from the master AUTOSAR meta-model.

EMF persistence layer

As part of the AUTOSAR standard, a model file format has been defined based around a set of persistence rules linked to the meta-model. EMF does not natively support this AUTOSAR-specific format or schema; therefore, a custom EMF ResourceManager is required. Many organizations working with eclipse are having to build the same persistence function, so there is ongoing work trying to standardize this piece. One example of this ongoing work is the Open Tool Framework (OTF). Figure 4 shows the integration of Rational System Developer’s project explorer for creating AUTOSAR DSL models.

Figure 4. AUTOSAR DSL tool
tool in tree view

The menu support for creating AUTOSAR domain elements (shown in Figure 5) gives you a domain-specific modeling experience, which helps you avoid the clutter of UML stereotypes and the complexity involved in that. You can carry out detailed design of any AUTOSAR template here, which is otherwise not possible using UML-based modeling support only.

Figure 5. Creating an AUTOSAR domain model
menu command

Customized views

You can exploit the domain-specific modeling support for AUTOSAR in Rational System Developer to create detailed and complex models. Sometimes, navigating through a large model and finding relationships between one object and another becomes a challenge.

One such issue for AUTOSAR is software components that contain other software components. It is possible in AUTOSAR to define composite software that composes several software components. The composite software object can be used as a component software object, which can be further composed to form other composite types. This sort of hierarchical relationship is difficult to trace by just navigating through the model. Therefore, the Hierarchical View shown in Figure 6 has been designed to capture the hierarchical structure of software components. It allows you to navigate through the hierarchy of software components, thus giving you a better perspective for software to ECU mapping.

Figure 6. Hierarchical View
model information in tree view

It is also useful to see the model objects grouped together by their types. This helps to identify and locate a model object if you know the category or type of the object. The Category View (shown in Figure 7) serves that purpose. These customized views have been extended to support the AUTOSAR UML model. You can categorize he elements by the stereotypes, and also show the containment structure for the software components.

Figure 7. Category View
model information in tree view

AUTOSAR DSL object visualization

AUTOSAR does not provide any diagram support for modeling, which is unlike UML standards. The domain-specific modeling support for AUTOSAR systems in Rational Systems Developer overcomes this deficiency by utilizing the visualization concept of IBM Rational’s MMI framework, which helps to visualize the elements of one domain using notational elements of some other domain. The source domain of AUTOSAR needs to be mapped to the target domain of UML, depending on how you need to visualize the domain-specific objects.

The UML class diagram has been exploited partly to visualize some AUTOSAR elements (software components, client/server and sender/receiver interfaces, and so on) as classes. Figure 8 shows elements being visualized as classes in the class diagram. For some AUTOSAR elements, although they can be visualized as a class, the operation compartment or attribute compartment (or both) does not convey anything. UML notational elements have been customized to make them suit the domain-specific needs.

Figure 8. AUTOSAR class diagram
diagram type on left, interface on right

The VFB for AUTOSAR Software Component (ASC) -- where the interaction between the ASCs through ports is defined at an abstract level -- can be captured diagrammatically with a UML 2.1 structure diagram. Figure 9 shows the structure diagram for an ASC (RainSensing). The interaction of software components through ports has been captured as an assembly and delegate connector.

Figure 9. AUTOSAR Structure Diagram
tab with diagram

The behavior modeling for ASC requires the scheduling of RunnableEntities (it is the component of the system that can be directly converted to code). The scheduling of RunnableEntities for execution can’t be captured properly with existing UML diagrams. A domain-specific diagram using the Graphical Modeling Framework (GMF) has been designed to provide diagram-based support for behavioral modeling of ASCs. The diagram (shown in Figure 10) helps to specify data elements that the RunnableEntity reads from or writes to. The Properties view support helps to schedule events for the execution of a RunnableEntity.

Figure 10. AUTOSAR Internal Behavior diagram
tab with diagram

Bi-directional transformation of DSL models to UML models

As discussed earlier, you can use UML for modeling some AUTOSAR templates, but more detailed design is required to be carried out in the DSL tool. With UML modeling support in Rational Systems Developer, you (as a system engineer) can start with very high-level design using UML. However, when it comes to detailed design, you need to transform the model into a DSL model.

The DSL tool on Rational Systems Developer provides support for model-to-model transformation that enables you to transform the UML model (with a Profile) to the DSL model. The transformation supports a subset of elements from AUTOSAR. The reverse transform from DSL to UML is also supported (with fuse capabilities) so that at any stage you can transform the DSL model to a UML model. Figure 11 shows the transformation configuration, where a UML model is set as the source, and an AUTOSAR model has been set as target. This methodology is expected to bring about several advantages:

  • Offers flexibility to model in the domain of choice
  • Leverage the benefits of both the domains
Figure 11. TC for UML to AUTOSAR Transformation
source on left, target on right

What you have learned

This article gave you an overview of AUTOSAR system modeling and Rational Systems Developer's support for it. It talked about the limitations of UML and the related requirement for a DSL for detailed modeling of different AUTOSAR templates. In addition, it discussed the support for visualization of domain-specific objects in UML diagrams and domain-specific diagrams. The article also talked about model-to-model transformation support, which provides you the option to work in UML or in DSL.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=328701
ArticleTitle=AUTOSAR System Modeling in IBM Rational Systems Developer
publish-date=08122008