Conference PaperPDF Available

Model-based Automotive Software Development using Autosar, UML, and Domain-Specific Languages

Authors:

Abstract and Figures

It has taken quite some time, but finally we observe that Autosar as an emerging architectural modeling standard in the automotive domain is increasingly spreading into the broad industrial practice. Although first been regarded with skepticism by many, it is a great chance to establish explicit specifications of software systems' architectures with various benefits such as distributed development and in particular a completely model-based development process, reaching even to the final source code. While Autosar is quite a beneficial approach, establishing an Autosar-based methodology can be cumbersome: Autosar authoring tools are often expensive and sometimes hard to use, Autosar architecture models are lacking information of interest (behavioral aspects), and Autosar does neither address nor guarantee a transition from architecture into detailed design or implementation. We sketch, how Autosar architecture models can be augmented with UML to add currently missing expressiveness w.r.t. interactive behavior. We further outline a seamless completely model-based transition from Autosar/UML architectural models to detailed design and succeeding implementation, using UML (module-based) as well as domain-specific alternatives (statecharts, block diagrams). Last but not least, we demonstrate a seamless Autosar-conformant tool-chain, consisting of Autosar, UML, and open source domain-specific modeling tools, based on Eclipse as the underlying integration platform.
Content may be subject to copyright.
Model-based Automotive Software Development
using Autosar, UML, and Domain-Specific
Languages
Patrick Könemann, Alexander Nyßen
itemis AG, Lünen, Germany
(koenemann|nyssen)@itemis.de
Abstract
It has taken quite some time, but finally we observe that Autosar as an emerging
architectural modeling standard in the automotive domain is increasingly spreading into
the broad industrial practice. Although first been regarded with skepticism by many, it is
a great chance to establish explicit specifications of software systems' architectures with
various benefits such as distributed development and in particular a completely model-
based development process, reaching even to the final source code.
While Autosar is quite a beneficial approach, establishing an Autosar-based
methodology can be cumbersome: Autosar authoring tools are often expensive and
sometimes hard to use, Autosar architecture models are lacking information of interest
(behavioral aspects), and Autosar does neither address nor guarantee a transition from
architecture into detailed design or implementation.
In this paper we will outline, how Autosar architecture models can be augmented with
UML to add currently missing expressiveness (interaction behavior) and how a seamless
transition from Autosar/UML architectural models to detailed design and succeeding
implementation can be achieved, using UML as well as domain-specific alternatives
(state charts, block diagrams). We will further sketch how a seamless Autosar-
conformant tool-chain can be established, consisting of Autosar, UML, and domain-
specific modeling tools, based on Eclipse as the underlying integration platform.
1. Using UML to augment the Documentation of Autosar Architectures
Autosar definitely is a great achievement and chance for both, OEMs as well as
suppliers. Although the Autosar standard may be over-engineered in some parts, the
availability of a common ECU hardware abstraction and a standardized way to structure
application software, is a novelty that has not been achieved in any other industrial
domain to this extend. As such, it will allow the automotive industry to share common
tools or combine separately developed hardware and software components, amongst
others.
Being a reference architecture, Autosar does not only prescribe a certain architectural
style (confer [BCK03]), which imposes how ECU software is to be structured in terms of
layers and components, it also prescribes a related standard decomposition. That is, as
depicted in Figure 1, it defines the existence of the Basic Software, decomposed into
modules and realizing a standardized ECU-hardware abstraction, and the Application
Layer, which structured into software components comprises the application logic of
an automotive software application (confer [AUT11b]). Furthermore, it standardizes a
Runtime Environment (RTE), which is used to establish communication between
software components within the Application Layer, as well as between Application Layer
and Basic Software, also controlling the overall life cycle (scheduling, etc.) of all
components and modules. Autosar further prescribes which modules make up the Basic
Software and which communication patterns are available for software components. For
certain sub-domains, certain software components and their application interfaces are
also predefined.
Figure 1: Autosar ECU Architecture Diagram [AUT11b]
To document modules of the Basic Software, Autosar employs the Unified Modeling
Language (UML, confer [OMG11]). For structural aspects, i.e. to document the modules
and their structural relationships via interfaces, UML class and component diagrams are
used. Figure 2 shows such an example for the LIN module. As depicted in the figure, the
abstraction level that is used to document Basic Software modules is pretty close to the
implementation and thus allows a straight-forward mapping to source code.
Figure 2: UML Component and Class Diagrams for the LIN Module [AUT11c]
The behavioral relationship between Basic Software modules is documented via UML
sequence diagrams based on the structural definitions of the modules. Figure 3 shows
an example for such an interaction between two LIN modules and the OS. Furthermore,
UML state machines are use to document internal states of Basic Software modules,
where appropriate, as also shown in the same figure.
Figure 3: UML Sequence and State Machine Diagrams for the LIN Module [AUT11c]
For documenting and specifying software components, Autosar introduces an own
graphical notation (defined in [AUT11d]). It offers a higher abstraction compared to the
implementation-near UML-based documentation of the Basic Software. Here, concepts
like sender/receiver and client/server interfaces, port prototypes, composite and atomic
software component types, component prototypes (instances of component types),
connectors, runnable entities, etc. are available.
However, this graphical notation is not even used for the specification of standardized
application interfaces within the standard itself. Instead, a spread sheet is provided
containing a brief description of all predefined components and the structural relations
among their interfaces (confer [AUT11e]), together with a document giving a high-level
description of these components (confer [AUT11f]). An example is a group of
components for controlling the wipers and washers of an automotive system as depicted
in Figure 4. We will use the highlighted components and ports as an illustrating example
in the following.
While the Autosar notation offers means to express structural concerns, it does not
support to formalize any behavioral aspects. As a consequence, there is no behavioral
documentation for the standardized software components available, including the wiper
washer components depicted in Figure 4. Without behavior documentation however, it is
hard to understand how different components interact with each other. This problem of
course also applies to non-standardized software components.
Figure 4: Overview of wiper/washer application component interfaces [AUT11f]
As demonstrated by Autosar itself (in terms of the Basic Software), UML could also be
used to document the behavior of components, using sequence diagrams and other
means. As UML defines behavior on top of structure, structural concepts must however
exist in order to achieve this. But even this is possible. Most of the required structural
Autosar concepts are directly representable in UML (components, ports, connectors,
interfaces) whereas others, such as the different kind of interfaces, cannot directly be
mapped to UML. A mapping is possible nevertheless either via an additional UML profile
or via modeling conventions, e.g. to use interface containing properties (instead of
operations) to represent sender/receiver interfaces.
Figure 5: UML Component Diagram representing the wiper/washer architecture
Figure 5 illustrates how such a UML representation could look like for the wiper/washer
components that are highlighted in Figure 4. Please note that the diagram only depicts a
cutout of the overall structural model, showing merely the component prototypes that are
of interest in our illustrating example.
Based on the structural elements that can be directly derived from corresponding
Autosar constructs, behavioral aspects may for instance be modeled by means of
interactions or state machines. Figure 6 illustrates a simple sequence diagram sketching
a possible interaction between the component prototypes 'InterDomains',
'WiprWshrMgr', 'WshrFrnt', and 'WiprFrnt' for the user request to enable and disable the
front washer of an automotive system.
Figure 6: UML Sequence Diagram showing a possible component interaction scenario
Another way of specifying behavior is to use UML Protocol State Machines to outline
legal usage scenarios of software components' interfaces. Having such behavioral
documentation at hand eliminates ambiguity of the meaning and usage of architectural
interfaces and improves the comprehensibility of the components' relationships.
Please note that while we propose to use UML to document Autosar architectures (or
more precisely augment the documentation of an Autosar architecture), this approach is
not comparable to what was intended with the UML profile for Autosar (confer [AUT06]),
which was issued with an early revision of the Autosar standard. It was indeed meant to
offer means to represent the overall architectural information, more or less as a
replacement for the Autosar architectural model itself. Our extension to the Autosar
standard only represents the structural subset that must exist in the UML model in order
to add behavioral aspects.
2. Using UML for Detailed Design
Autosar is an architectural standard and as such, Autosar models are architectural
models. That is, they capture only the information that is relevant to relate components
to other parts of the system (other software components as well as the Basic Software)
and to schedule them at runtime (via runnable entities). Technically speaking, they
contain all the information that is needed to generate application components' header
files as well as the Runtime Environment.
The Autosar standard is thus not concerned about the internal modularization of atomic
software components. And while an RTE generator typically supports to generate a
single source file for each software component, containing corresponding function
definitions for those function prototypes contained in the application header file, the
succeeding implementation of the component is out of its scope.
Nevertheless, the detailed design of software components has to be documented. In a
model-based setting, the consequent idea is to use models to formally specify the
detailed design, which can then in turn be used as a means for documentation, similar to
as it was outlined for the Basic Software modules in the preceding section. However,
there is a major difference between Basic Software modules and software components
with respect to the level of abstraction that is used, which is higher for the latter. As
such, in order to use documentation models for the detailed design of software
components, these models must suit the respective level of abstraction. The relation
between all employed detailed design constructs and those elements that are directly
derived from the Autosar architecture has to remain traceable.
UML can help to achieve this. That is, if the architectural information of a software
component is already available in UML (as outlined in the preceding section), then both,
structural and behavioral diagrams can be used for the specification of its detailed
design. However, this detailed design model will not be able to correspond so closely to
code structures as the Basic Software UML model, because for all architectural level
elements the abstraction level needs to be preserved in order to achieve above
mentioned traceability. That is, while the data elements of a sender/receiver interface
will be ultimately mapped to corresponding macros/functions in the application header of
the software component, using this representation in the detailed design model would
clutter the model and make it hard to read. Performing such a transition manually would
furthermore be an error-prone and tedious task.
Instead, as the mapping of these architectural concepts to the source code constructs is
well defined (confer [AUT11a]), this transition can be left to code generators. Indeed,
dependent on the completeness of the model, large parts or even the entire
implementation may be generated from the detailed design model. In the end, the
concrete modeling conventions therefore depend on what is to be generated and what
code generator is being used.
Figure 7 illustrates a detailed design for a wiper component, which outlines a 'WiprCtrlr'
implementation module that realizes the provided interfaces of the component and
internally makes use of three auxiliary modules to perform data conversions. With an
adequate code generator, header and source file stubs could be generated for each of
the implementation modules. Behavior diagrams could be used in addition to specify the
behavior of the modeled functions, so that a code generator could also generate
function definitions with implementation bodies corresponding to the modeled behavior.
Figure 7: Detailed design of the application software component 'WiprWshrMgr' in UML
3. Using DSLs for Detailed Design
A classical decomposition of an atomic software component into implementation
modules, as outlined in the preceding section, may often be applicable, but it is not
always the most appropriate way. That is, in case an atomic component realizes a
controller, a dynamic system model may be much more adequate to specify the internal
decomposition, or a state machine model in case of a state-based controller.
While UML state machine diagrams may be applicable for the latter, UML does not offer
any concepts to adequately express control engineering related aspects. And even in
case of state machines, the strict event-driven execution semantics of the UML may not
be appropriate in a scenario, where components are not active themselves, but are
provided with control only by an external scheduler. As such, a domain-specific
modeling approach that offers a dedicated notation may be preferable towards a general
purpose modeling language in both cases. What adds to this is that dedicated modeling
tools for domain-specific modeling approaches usually offer more concise solutions with
respect to validation (or even verification), simulation, and code generation than a
general purpose UML tool.
In the control engineering domain, Matlab Simulink has to be named as the predominant
modeling tool that can be used for such a purpose. There is also an Autosar specific
integration at hand (confer [MW08]), which allows that a detailed design may be
specified directly against the interfaces defined in the Autosar model.
However, there are also well-suited open-source alternatives like Eclipse Damos (confer
[DAM13]), for which a block diagram example is depicted in Figure 8. It has the
advantage to be much more customizable.
Figure 8: Block diagram of a dynamic system (rain amount calculation of wiper/washer)
modeled with Eclipse Damos
With respect to modeling state machines, besides all those well-established commercial
tools that are present in the market, the Yakindu Statechart Tools (SCT, confer
[SCT13]), a customizable open source alternative, may be named. It allows to model
state machines with a cycle-based execution semantics that is better aligned with the
scheduling concepts incorporated into Autosar. Since the expression language of
Yakindu SCT can be customized, the tool can also be easily adopted to specify the
internal decomposition of a component in a manner that is well aligned with its Autosar
interfaces. Figure 9 sketches a prototype of an adopted Yakindu SCT, where the state
chart is directly linked to an Autosar model containing the interface definitions of the
'WiprWshrMgr' component, for which the state chart is designed.
Figure 9: State-based detailed design of the 'WiprWshrMgr' of the wiper/washer example
modeled with Yakindu SCT
4. Building up Tool Chains
All general purpose and domain-specific modeling tools presented in this paper provide
profound means for the modeling of automotive software. As for UML, there are many
modeling tools available in the market, both commercial and open source. The
Enterprise Architect (confer [EA13]), for instance, is widely spread in the automotive
domain whereas Eclipse Papyrus (confer [PAP13]) may be named as an open source
alternative. In the control engineering domain and for state-based modeling, the
situation is comparable. Besides well established commercial tools, Eclipse Damos and
Yakindu SCT have already been named as open source modeling solutions, both based
on Eclipse.
To build up a complete engineering tool chain, further tools like code editors, compilers,
analysis and testing tools, and others have to be integrated. Here, the Eclipse
ecosystem offers most of what is compulsory in terms of open-source, while commercial
add-ons that extend Eclipse are available for special purposes as well. Furthermore,
there is a couple of profound base technologies available, such as ATL (confer [ATL13])
or Xtend (confer [XTE13]) for model transformation and code generation. With Artop
([confer ART13]), there is also a fully featured Eclipse-based tooling infrastructure for
Autosar models available. This is why we focus on Eclipse as the integration platform for
automotive tool chains.
Even if some tools and their model formats are not directly integrated with Eclipse,
adapters can be quite easily developed based on the available Eclipse technologies as
well. The commercial Yakindu EA-Bridge (confer [EAB13]) may for instance be named
as an example to make Enterprise Architect UML models accessible within Eclipse.
Thus, seamless automotive tool chains can be built based on Eclipse as the underlying
integration platform. In fact, this role of Eclipse seems to be an emerging trend that we
notice throughout the whole industry.
5. Summary & Conclusion
Autosar as an architectural language only focuses on structural concepts, omitting
behavioral aspects as well as detailed design. This paper sketched how UML and
domain-specific modeling languages can be used to complement Autosar to fill these
gaps. In detail we sketched how UML and domain specific alternatives can be used to
augment Autosar architectures, while not using these languages as a replacement for
Autosar.
We further outlined how seamless automotive tool chains can be built-up on Eclipse as
an underlying integration platform, making use of existing commercial and open-source
solutions, as well as of the rich set of base technologies that is available in its
ecosystem.
References
[AUT11a] AUTOSAR GbR: AUTOSAR Specification of RTE. http://www.autosar.org/download/R4.0/
AUTOSAR_SWS_RTE.pdf. Version 3.2.0, Release 4.0, Revision 3, 2011.
[AUT11b] AUTOSAR GbR: AUTOSAR Layered Software Architecture. http://www.autosar.org/download/
R4.0/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf. Version 3.2.0, Release 4.0, Revision
3, 2011.
[AUT11c] AUTOSAR GbR: AUTOSAR Basic Software UML Model. http://www.autosar.org/download/
R4.0/AUTOSAR_MOD_BSWUMLModel.zip. Version 3.2.0, Release 4.0, Revision 3, 2011.
[AUT11d] AUTOSAR GbR: AUTOSAR Software Component Template. http://www.autosar.org/
download/R4.0/AUTOSAR_TPS_SoftwareComponentTemplate.pdf. Version 4.2.0, Release
4.0, Revision 3, 2011.
[AUT11e] AUTOSAR GbR: AUTOSAR Table of Application Interfaces. http://www.autosar.org/download/
R4.0/AUTOSAR_MOD_AITable.zip. Version 2.2.0, Release 4.0, Revision 3, 2011.
[AUT11f] AUTOSAR GbR: AUTOSAR Explanation of Application Interfaces of the Body and Comfort
Domain. http://www.autosar.org/download/R4.0/AUTOSAR_EXP_AIBodyAndComfort.pdf.
Version 2.0.0, Release 4.0, Revision 3, 2011.
[AUT06] AUTOSAR GbR: UML Profile for AUTOSAR. http://www.autosar.org/download/
AUTOSAR_UML_Profile.pdf. Version 1.0.1, 2006.
[BCK03] Bass, Len; Clements, Paul; Kazman, Rick: Software Architecture in Practice. 2. Edition.
Pearson, 2003.
[OMG11] Object Management Group: Unified Modeling Language (UMG UML), Superstructure.
http://www.omg.org/spec/UML/2.4.1/Superstructure. Version 2.4.1, 2011.
[MW08] MathWorks: Latest Release of Simulink and Real-Time Workshop Embedded Coder Enable
Engineers to Generate AUTOSAR Compliant Production Code with Model-Based Design.
Press Release, 19.03.2008, http://www.mathworks.de/company/newsroom/The-MathWorks-
Announces-Product-Support-for-AUTOSAR-Software-Component-Development.html, retrieved
18.01.2013.
[DAM13] Eclipse Damos. http://eclipse.org/damos/. retrieved 18.01.2013.
[SCT13] Yakindu Statechart Tools. http://statecharts.org/. retrieved 18.01.2013.
[ART13] AUTOSAR Tool Platform. http://www.artop.org/. retrieved 18.01.2013.
[EA13] Sparx Systems: Enterprise Architect. http://www.sparxsystems.com/. retrieved 18.01.2013.
[PAP13] Papyrus. http://eclipse.org/papyrus/. retrieved 18.01.2013.
[ATL13] ATL Transformation Language. http://eclipse.org/atl/. retrieved 18.01.2013.
[XTE13] Xtend. http://xtend-lang.org. retrieved 18.01.2013.
[EAB13] Yakindu EA-Bridge. http://www.yakindu.com/eabridge/. retrieved 18.01.2013.
... Thus the development of applications and BSWs is independent. This allows the possibility to distribute different applications across ECUs due to car variants or integrate software modules from different suppliers [14], [15]. ...
Conference Paper
Full-text available
The aim of this work is to implement 100/1000BASE-T1 Automotive Ethernet packet interpreting system for a common personal computer connected to media converter from Automotive Ethernet device to conventional Ethernet. Especially, methods for Automotive packet capturing, fitering incoming communication, interpreting data with Automotive Open System Architecture Extensible Markup Language (AUTOSAR XML or ARXML), and logging of captured data to various formats are proposed. The designed system is modular, and it can be used from Graphical User Interface (GUI), Windows Command Prompt interface, Tcl console, or another program. The functionality of the system has been tested in several simulations using captured data from the Electronic Control Unit (ECU).
... The usage is based on the fact that the software there is mainly created by domain experts familiar with the hardware to be controlled, and precise engineering design notations (languages) frequently exist there. One such example is DSLs for the Autosar project (Koenemann and Nyssen, 2013) . There several DSLs for building components of automotive software have been created (Graf and Voelter, 2009). ...
Latest Release of Simulink and Real-Time Workshop Embedded Coder Enable Engineers to Generate AUTOSAR Compliant Production Code with Model-Based Design. Press Release
  • Mathworks
MathWorks: Latest Release of Simulink and Real-Time Workshop Embedded Coder Enable Engineers to Generate AUTOSAR Compliant Production Code with Model-Based Design. Press Release, 19.03.2008, http://www.mathworks.de/company/newsroom/The-MathWorks-Announces-Product-Support-for-AUTOSAR-Software-Component-Development.html, retrieved 18.01.2013.