1. No category

AUTOSAR
How to deal with non-functional
properties
Andreas L¨oscher
Chemnitz University of Technology
loesa@hrz.tu-chemnitz.de
February 26, 2009
product lines and the possibility to detect
errors in early design phases. The AUTOSAR is a partnership of main actors of
the automotive manufacture industry.
Non-functional properties are those
that do not affect the result of an application in terms of the calculated data or
the value of a signal. Non-functional properties describe the constraints for the applications. In automotive systems, especially cars, timing is one of the most important properties to ensure the correctness of the system. An example are X-ByWire applications. Other properties are
resource consumption and real-time capa1 Introduction
bility. This work wants to determine how
AUTOSAR handles these requirements.
The AUTOSAR1 consortium developed a
In section 2 an overview of AUTOSAR
standard for software components in au- is given and how a defined software comtomotive systems. This was done because ponent (SWC) is realized on an ECU2
of the growth of complexity in the devel- in the development process. The timing
opment of electronic systems. Other goals model of AUTOSAR is shown in section
are an improved flexibility for modifica- 3. In section 4 the definition of SWCs is
tions, better scalability between different discussed and how non-functional properThe AUTOSAR consortium developed a
standard for software components in automotive systems. The goals of this standard is, to enable reusability, scaleability of software components and with this
lower costs for the development. Important aspects are non-functional properties
such as timing, resource consumption and
real-time capability, that must take place
in automotive applications. In this paper it is discussed how such properties are
defined and how these definitions can be
complied.
1 Automotive
2 Electronic
Open System Architecture
1
Controll Unit
Figure 1: AUTOSAR Architecture (from [1])
ties are described.
tive system is build and everything that
is needed to integrate different software
components in a system of networked
2 Overview of AUTOSAR ECUs. It does not provide information
on how the software architecture or the
AUTOSAR is both a standard for soft- software components are created. The
ware architecture in automotive systems software architecture contains an abstract
and the partnership of the participat- communication layer, the methodology
ing companies. The AUTOSAR consor- and templates to describe every part of
tium was founded in 2003 by the first the system such as the used ECUs, the
core members BMW, Bosch, Continental, software components, the communication,
DaimlerChrysler, Siemens VDO and Volk- etc.
swagen. Till 2004 Citro¨en Automobiles
S.A., Ford Motor, General Motors, Peugeot Citro¨en Automobiles S.A. and Toy- 2.1 Virtual Functional Bus
ota Motor joined the group as core partners. The current version of the standard All components of a system communicate
is 3.1 and was released in 2008. The next over the virtual functional bus (VFB).
version is expectet to be realeased in 2009. This is an abstract communication enviIn the current schedule for the introduc- ronment that encapsules the real undertion of AUTOSAR it is announced that lying structure. This means that AUfirst modules will be used in 2010. The TOSAR can be used transparent on diffirst compatible ECUs will be installed in ferent platforms such as FLEXRAY and
vehicles in 2011 and the introduction of CAN. The SWCs using the VFB are inAUTOSAR in vehicles will take place in dependent from the used hardware archi2012.
tecture which results in more flexibility.
The given standard includes a method- It provides the software components with
ology that describes how an automo- sender-receiver, server-client communica-
2
tion and error handling.
The sender-receiver pattern enables
a simple information distribution where
data from one sender can be received from
several receivers or one receiver can receive information from several senders.
The transfer of data is logically atomic.
The data-type of each sender-receiver interface is known at configuration time.
There are two semantics for this pattern.
The ”last-is-best” semantic provides only
the newest data. In addition to this, an
invalidate service is available. A queued
semantic is also available, which delivers
all sent data in the correct order (FIFO).
In the client-server pattern, the server
provides a service and the client uses this
service. The client starts the communication by requesting a service. The server
waits for incoming requests and provides
the service or returns an error if it cannot.
ponents on specific ECUs in regards of
timing and resources. The output of this
process is the System Configuration Description. It contains all system information including bus mapping and topology.
With this information, executables for every ECUs are created. Such an executable
is the whole software that runs on a specific ECU including the Runtime Environment (RTE), Schedule and the software
components. The RTE is the implementation of the VFB on a specific ECU. An
illustration of the RTE on an ECU is given
in figure 1.
There are tools that support the whole
process of defining software components
and creating an appropriate system. Examples of such tools are ASCET [14] and
TargetLink [13].
3 Timing model
2.2 Methodology
The timing model of AUTOSAR is called
Generic Timing Framework. This framework is based on events. To define a constraint behaviour like a communication,
you have to describe the real behaviour of
your system and a model which describes
the desired behaviour. The model specifies a guarantee or a requirement. If all
requirements are fulfilled, the described
components should satisfy the model.
The integration process of an AUTOSAR
system is described in [5]. This methodology shows how the development process from templates to build system takes
place. While this is not a complete description or does define responsibilities or
roles, it describes a work-product flow and
the dependencies of activities inside of it.
An overview of the methodology is shown
in figure 2.
AUTOSAR provides templates as an information exchange format. Defining a
system or a component means filling out
these templates. To build a system you
must define its hardware and software. In
addition to that it is needed that you define all constraints that apply. The idea
of AUTOSAR is that powerful tools can
create a system that fulfills the defined requirements. This process is called Configure System. It maps the Software Com-
3.1 Events
An event occurs at a defined time. In normal case, the event is not directly defined
by its occurrence time but by a modeled
behaviour of its nature. Let us consider
that there is an event OpenDoor. The
event can occur multiple times with a distinct occurrence time. AUTOSAR defines
two event models which are used to model
the occurrence time of events.
3
Figure 2: AUTOSAR Methodology (from [1])
RecurringEvent Model The RecurringEventModel is used to model sporadic
events. Its attributes are the highest and
lowest inter occurrence time. If tlast
is the last time an event occurs, its
next occurrence is in the interval of
[tlast + tlowestIOT , tlast + thighestIOT ]. If
thighestIOT is infinite, you can describe
a minimal delay for two events and if
tlowestIOT is infinite, you can describe a
maximal delay.
Figure 3: MaxAge Timing Chain Model
provides the possibility to describe more
complex behaviour in a construct which
PeriodicEvent Model To define periodic
is called Timing Chains. Timing Chains
events, you have to define a period and a
consist of many segments from which evjitter. Periodic events do not have to ocery is associated to an event. There also
cur exactly after every period. The jitter
exists two models for timing chains. The
describes this behaviour. AUTOSAR dedifference between timing chain and model
fines it as follows. The period describes
is the same as for events.
intervals. The time between the beginning
of an interval and the occurrence of the related event is called delay. It is required
that the difference between the maximal MinMaxOneToOne Model The Timing
and the minimal delay has to be smaller Chain satisfies this model if its response
time (time between activation of the first
than the jitter.
and last event in the chain) is between the
specified minimum and maximum. The
3.2 Timing Chains
timing chain has to be activated once for
If you were able to use only single events, each occurrence of the stimulus. This
you would be very restricted in the de- model is used to describe event driven sysscription of your component. AUTOSAR tems.
4
MaxAge Model This model has one parameter, the maxage. It is used to describe systems, in which events define
changes in the state. In many cases it is
not necessary that the system reacts to
every event, but that the information provided by a component is new enough. If
for each activation of the timing chain, the
response time is smaller than maxage, the
model is satisfied. Additional to this it is
required, that every stimulus leads to an
activation, or that a later activation of the
timing chain can give a response that is
within the deadline (maxage) of the stimulus. For an example see Figure 3.
system perspective, an AUTOSAR software component can be mapped on an
ECU. The description of the interface of
the component can be validated against
different models. From an ECU perspective it is necessary to know the resource
consumption and the execution time of
a component, so that a schedule can be
build and the resources like memory can
be provided. The full description of software components is described in [3]. This
work shows only how resources are described and how the execution time of a
component can be specified. The templates provide the possibility to define requirements on other components, functionality, compiler, etc.
3.3 Communication
The timing parts of communication on the
VFB can now be modeled with the timing framework by using Timing Chains.
The sender-receiver communication defines two elements for this. The DataElementAvailableonPPort and the DataElementAvailableonRPort event. The difference between these events describes the
duration of the communication.
The
AUTOSAR provides in its templates attributes to specify requirements on the
response time. Other attributes, which
are considered as further extension of the
VFB communication attributes are guarantees as well as requirements for period,
jitter and inter occurrence time. The
server-client communication pattern can
be described in a similar way.
4.1 Resource Consumption
The resources of a software component
are represented in memory. This can
be divided into static allocated memory on implementation and dynamic allocated memory on runtime. The description of statically allocated memory
is simple. AUTOSAR allows this for every implementation of a software component and chooses the right one for the
mapping. The description of dynamic allocated memory is more difficult. AUTOSAR divides stack and heap memory
usage. The stack is used to store temporary data like parameters or local variables. This means that the stack usage is
dependent on the depth of the calling hierarchy. AUTOSAR provides some methods to describe the used stack. These
methods are WorstCaseStackUsage, MeasuredStackUsage and RoughEstimatedStackUsage. The first is determined analytically. The second one interferes from
measures with test patterns. A maximum
and a minimum amount of used stack can
be defined. The last one is a rough es-
4 Software Components
Description
Of prime importance is the definition of
the behaviour of the software components.
This must be done by describing the internal and external specifications. From a
5
Figure 4: AUTOSAR ECU software architecture (from [1])
time, simulated execution time, measured
execution time and rough estimated execution time, which work like definitions for
the memory usage. Because of the dependency from other specifications, you can
describe the context, in which the execution time was achieved.
timation. The second type of dynamic
allocated memory is heap memory. This
describes memory which is explicitly allocated. AUTOSAR provides the same
methods to describe the used memory.
One problem of heap memory is, that the
available memory could be segmented unpropitiously. This means, that even if
enough memory is available, it is not accessible. Heap memory as well as stack
memory should be used with caution.
5 System Description
AUTOSAR provides a template for the
system description. Describing the system
means filling out the template. The template contains information components of
the system and the relations amongst
them. This includes hardware and software. Constraints related to communication and mapping can also be described.
AUTOSAR supports redundancy at this
point. There can be made many con-
4.2 Execution Time
The execution time of a software component depends on many different properties of the system. For example the used
ECU, the chosen implementation of the
software components and the context the
component is used. The execution time
can be defined as worst case execution
6
straints for redundant components.
the system description. The possibilities
given here are similar to that of the mapping constraints.
Mapping Constraints A fundamental
It is possible to define permissible and
concept of AUTOSAR is, that SWCs can
forbidden communication paths. In adbe developed independently from the used
dition to this you can define common
ECU hardware. The assignment of comand separate signalpath. These definiponents to ECUs is called mapping. Nevtions describe two or more communicaerless, there may be some SWCs that are
tions. Common signalpaths describe sigalready mapped in an earlier phase of the
nals that must use the same physical path.
system generation process, or other conThe opposite is the separate signalpath. It
straints, that must be respected.
defines that two or more signals must not
AUTOSAR allows to force the mapping
take the same physical way. This should
of SWCs on ECUs. This can be described
be used for redundant communication.
in the System Mapping description which
is part of the System description. If a specific implementation should be used, it can RTE Resource Estimation An AUbe forced at the same place. A SWC can TOSAR SWC uses the services of the RTE
be mapped manually with these specifica- which must be mapped on the ECUs additions. In addition to this it is possible to tionally to the SWCs. Therefor it is necdefine a set of ECUs a SWC must or must essary to describe the resources the RTE
needs on every ECU. This is done like it is
not be mapped on.
A more dynamic definition of con- described in here 4. These specifications
straints is the possibility to define clus- are also part of the system description.
tered or separated components. Separated
components are such, that must not be
mapped on the same ECU. This is im- 6 Review and Evaluation
portant do ensure that redundant comAUTOSAR provides the possibility to deponents do not fail if the hardware fails.
scribe software components and timing
The opposite of separated components are
behaviour. The discussed question is,
clustered components. These must be
if the capabilities of description provides
mapped on the same ECU. Sometimes it
enough information for the design process
is important that two or more components
of an automotive system in respect to nonare mapped on one ECU to ensure correct
functional properties. AUTOSAR gains
behaviour. This could be the case if these
flexibility and abstraction for the design
two components need a fast communicaprocess of software components. It protion.
vides a standardized API and interface
descriptions so that software components
Communication Constraints While the can be exchanged in ways programmers
system configuration process, the actual know from Java or C++. The key goals
signals between ECUs are calculated. At while developing the standard where not
this point it happens that different com- to solve timing problems or other critical
munication paths are possible.
AU- requirements. The goal was to support inTOSAR allows to specify constraints ac- tegration of software-engineering perspeccording to the communication as part of tive.
7
7 Conclusion
The timing model does provide only basic features. There is no possibility to
model the timing behaviour of the communication together with the scheduling behaviour. AUTOSAR provides no support
for a systematical timing analysis procedure. Not being able doing so, its hard
to prove that a built system will work
in practise. The templates for describing
software components do not provide the
possibility to define shared resources. The
ussage of shared resources can result in
longer execution times which means, that
the build schedule may not been correct.
AUTOSAR provides a powerful methodology to develop software components for
automotive systems. It describe the integration process of software components
with respect to scalability, complexity and
reliability. It does not provide information
about how it should be done in detail, but
how the components of a system have to
be described so that an successful build
process on a specific platform is possible
following the methodology.
AUTOSAR at the current stage do
not provide a proper timing framework.
The existing timing framework which is
described in [1] is not yet part of the
standard and lacks many features which
are crucial for the system build process.
There are solutions available to this problem. The first would be to define a proper
timing framework for AUTOSAR. The
need of such a framework has been recognized by the consortium and the standard will be extended further releases. [9]
describes a way to extend the given standard with an additional timing framework
which is not part of the standard but that
provides the missed features.
A model for extending AUTOSAR with
a more proper timing framework is described in [9].
The TIMMO project
is an industry driven complement of
AUTOSAR which contains MARTE as
Timing Augmented Description Language
(TADL). The timing behaviour is described by MARTE which provides many
of the features missed in AUTOSAR including a systematical timing analysis
procedure on model level. There is also
the possibility to describe shared resources
and timing behaviour of communications
in respect to the schedule of the software
components.
References
In [6] the AUTOSAR consortium
pointed high reliability and other safety
parameters as one main objective of the
standard. The usage of redundancy to
reach this objectives are also described in
this document. AUTOSAR fullfills this
objectives by providing support for redundant components. Various constraints related to this can be specified in the system
definition like separated mapping or separated communication paths. This however
must be done manually. AUTOSAR itself
do not provide an automatism for this.
[1] Technical overview 2.2.2. Technical
report, AUTOSAR GbR, 2008.
[2] Specification of the virtual functional
bus 1.0.2. Technical report, AUTOSAR GbR, 2008.
[3] Software component template 3.1.0.
Technical report, AUTOSAR GbR,
2008.
[4] Specification of bsw module description template 1.1.0. Technical report,
AUTOSAR GbR, 2008.
8
[5] Autosar methodology 1.2.2. Technical report, AUTOSAR GbR, 2008.
2006. Second International Symposium on, pages 9–10, Nov. 2006.
Targetlink product in[6] Autosar main requirements 2.0.5. [13] dSPACE.
formation, January 2009. http://
Technical report, AUTOSAR GbR,
www.dspace.de/ww/de/gmb/home/
2008.
products/sw/pcgs/targetli.cfm.
[7] Specification of the system template
Ascet product infor3.0.4. Technical report, AUTOSAR [14] ETAS.
mation, January 2009.
http:
GbR, 2008.
//www.etas.com/de/products/
[8] H.
Heinecke,
W.
Damm,
ascet_software_products.php.
B. Josko, A. Metzner, H. Kopetz,
A. Sangiovanni-Vincentelli,
and
M. Di Natale. Software components
for reliable automotive systems.
Design, Automation and Test in
Europe, 2008. DATE ’08, pages
549–554, March 2008.
[9] S. G´erard. H. Espinoza, K. Richter.
Evaluating marte in an industrydriven environment: Timmo’s challenges for autosar timing modeling.
Design, Automation and Test in Europe, 2008. DATE ’08, March 2008.
[10] Marco Di Natale. Virtual platforms
and timing analysis: status, challenges and future directions. In DAC
’07: Proceedings of the 44th annual conference on Design automation, pages 551–555, New York, NY,
USA, 2007. ACM.
[11] P.-E. Hladik, A.-M. Deplanche,
S. Faucou, and Y. Trinquet. Adequacy between autosar os specification and real-time scheduling theory.
Industrial Embedded Systems, 2007.
SIES ’07. International Symposium
on, pages 225–233, July 2007.
[12] K. Richter. The autosar timing model
– status and challenges –. Leveraging
Applications of Formal Methods, Verification and Validation, 2006. ISoLA
9