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
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
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
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
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
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
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
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
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
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
Figure 10. AUTOSAR Internal Behavior 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
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.
- Review the AUTOSAR technical overview V2.1 at www.autosar.org
- Read the article Explore model-driven development (MDD) and related approaches: Applying domain-specific modeling to Model-Driven Architecture by Peter Kovari.
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
- Subscribe to the developerWorks Rational zone newsletter. Keep up with developerWorks Rational content. Every other week, you'll receive updates on the latest technical resources and best practices for the Rational Software Delivery Platform.
- Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
- Download a trial version of IBM Rational Systems Developer.
- Download trial versions of IBM Rational software.
- Download these IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.
- Join the developerWorks Community in forums, blogs, podcasts, wikis, and more.
- Rational Software Architect, Systems Developer, Data Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Systems Developer
Dig deeper into Rational software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.