Embed Size (px)
Citation preview
Autonomic Mechanisms for the Automotive Industry
MSc Dissertation
Josu Martinez
A thesis submitted in part fulfilment of the degree of MSc in Advanced Software Engineering supervised by Dr. Simon Dobson and moderated by Professor
Paddy Nixon
Department of Computer Science
University College Dublin
28 September 2007
Abstract
Automotive systems are continuously facing an increase of complex and evolving
software requirements. AUTOSAR appeared as a standard solution that allows
seamless integration and provides better performance than the current proprietary
infrastructures. However, it still requires significant efforts in manual configuration
and management of software deployments.
Autonomic computing is considered a feasible solution to handle all the technical
issues arisen by the emerging challenges of the automotive industry. This document
shows some of the insufficiencies that AUTOSAR suffers to cope with this novel
challenges and proposes the use of some techniques and methods that could help in
purpose of creating a vehicle self-managed system.
Special thanks for all the people that helped in the process of writing this thesis:
To Jeffrey O. Kephart and David. M. Chess from the IBM Thomas J. Watson
Research Centre for helping on increasing my knowledge about Unity.
To the people related to AUTOSAR that very kindly answered all my doubts related to
this application.
To Dr. Cecilia Ekelin from Volvo for all the useful information provided about
DySCAS.
This work is partially supported by Science Foundation Ireland under grant
number 03/CE2/I303-1, “Lero: the Irish Software Engineering Research
Centre.”
Table of Contents
1 Introduction...............................................................................................5
2 AUTOSAR ................................................................................................9
2.1 Basic AUTOSAR Approach .........................................................................10
2.2 Challenges and Goals ..................................................................................11
2.3 ECU Software Architecture..........................................................................13
2.3.1 Software Layer................................................................................. 14
2.3.2 Runtime Environment (RTE) Layer................................................... 15
2.3.3 Basic Software Layer ....................................................................... 15
2.3.3.1 Services Sub-layer ............................................................16
2.3.3.2 ECU Abstraction Sub-layer ...............................................17
2.3.3.3 Microcontroller Abstraction Sub-layer................................18
2.3.4 Deeper View of Basic Software Components: Memory Example...... 18
2.4 Classification of Interfaces...........................................................................20
2.4.1 AUTOSAR Interface......................................................................... 20
2.4.2 Standardised AUTOSAR Interface ................................................... 20
2.4.3 Standardised Interface ..................................................................... 20
2.5 Communication Mechanisms ......................................................................21
2.5.1 Client-Server Communication Pattern .............................................. 21
2.5.2 Sender-Receiver Communication Pattern ........................................ 22
2.6 AUTOSAR Methodology Overview ............................................................22
3 Emerging Challenges in the Automotive Sector .....................................26
3.1 Overall AUTOSAR Problems ......................................................................28
4 Autonomic Enhancements......................................................................31
4.1 Actual Autonomic Level of AUTOSAR.......................................................31
4.1.1 Quick Overview of Autonomic Computing ........................................ 31
4.1.2 How Autonomic Properties could Enhance AUTOSAR..................... 32
4.1.3 The Autonomic Contribution of AUTOSAR: Self-Description ............ 34
4.2 Holistic Approach for Autonomic Computing ............................................35
4.2.1 Control Theoretic Approach ............................................................. 35
4.2.2 The Need for Agency ....................................................................... 37
4.2.3 Adaptive Middleware Approaches .................................................... 39
4.2.4 Real-Time Configuration .................................................................. 43
5 Enhancements Based on Other Autonomic Solutions ............................46
5.1 Unity ................................................................................................................46
5.1.1 Self-Optimization.............................................................................. 48
5.1.2 Self-Configuration ............................................................................ 49
5.1.3 Self-Healing ..................................................................................... 50
5.1.4 Self-Protection ................................................................................. 51
5.1.5 Self-Description................................................................................ 51
5.2 DySCAS..........................................................................................................51
5.2.1 Policy-based computing ................................................................... 52
5.2.2 Middleware services......................................................................... 53
5.3 ArchWare........................................................................................................55
6 Conclusion and Future Work ..................................................................58
7 References .............................................................................................60
APPENDIX – Interpretations from AUTOSAR Expert Knowledge .................64
1. Component Development ............................................................................64
2. Built-in Functionalities...................................................................................64
3. Component Integration and Responsibilities ............................................65
4. Component Communication ........................................................................66
1 Introduction
Some short-term expectations [1] suggest that electronics systems, which account for
more than 20% of the cost of a car today, will increase to 30% by 2008 (Strategy
Analytics), and also that more than 40% of the total value of automotive electronics
will be in the software by 2010 (Mercer Management Consulting). This increase is
produced both by the insertion of new components in the Electronic Control Units
(ECUs) and the inclusion of Consumer Electronic (CE) devices, which represent the
next step in the evolution of the automotive electronic systems.
As in many sectors of the industry, the different vehicle manufacturers (OEMs) and
suppliers that compose the automotive sector have been developing their proprietary
solutions to try to cope with every new challenge generated by novel functionalities
expected by the end consumers. These functionalities, which are translated into
software components and later embedded into ECUs, enhance the operation of certain
parts of the vehicle, such as driving assistance, car dynamics or the airbag control
system. So far top manufacturers decide how the automotive system is designed,
enforcing hardware and software suppliers to follow their imposed rules when
implementing new software products.
However, the automotive sector is experiencing a tremendous increase in the
functional scope of electronic devices, not only to handle all the new functionalities
demanded by the market but also to contribute in the vehicle management complexity
reduction. This huge hardware and software heterogeneity arising in the automotive
sector is raising the cost and risks of development and integration of new and often
more complex components in proprietary products, as they typically offer non-
transferable specialised and fixed functionality, constituting a closed environment.
Consequently, the inclusion and upgrades of software modules are difficult and
expensive, making the traditional models and development processes became
obsolete.
AUTOSAR (AUTomotive Open System ARchitecture) deals with the heterogeneity
of the automotive components provided by OEMs and the different suppliers,
establishing a de facto open industry standard for automotive architectures [3]. The
scope of the actual version of this application is mainly the control systems for
mechanics (powertrain, chassis, active and passive safety, and body and comfort). It
provides a layered infrastructure that abstracts the business logic from the hardware,
in which all the different components (differentiated in application software
components and basic software components) can interact by implementing standard
interfaces and data exchange formats. The anthem of AUTOSAR is to cooperate on
standards and complete on implementation.
Standardization enhances the system’s scalability and integration of components,
which reduces the susceptibility to failure. It allows portability between the different
vehicle and platform variants, transferability of functions between components, and
reusability and updates of code. Moreover, it decreases the development cost, and
boosts the system reliability satisfying the availability and safety requirements.
Guaranteeing car driver and passengers’ safety is in fact the key requirement that at
last defines the rest of the requirements.
Unfortunately, the versatility of AUTOSAR just resides at design-time, when the
application users can dynamically define and describe the components that the end
product i.e. a concrete model of car will support, as well as the relationships between
them. Once the final infrastructure of the car is designed some steps defined in the
AUTOSAR methodology [3] are automatically executed using certain tools, which
result is a static vehicle infrastructure that cannot be modified at run-time.
On the other hand, all the efforts being done in the actual version of AUTOSAR are
not enough to cope with future challenges and the open trends also established in
other software and hardware domains1. These new challenges are basically divided
into two classes of applications being demanded in the market: the safety critical and
hard real-time control software for engine management and consumer entertainment
modules. Some examples of these two types of challenges are preventing accidents
allowing cars to communicate their location through an automatic brake system
activation in the case of collision risk (safety) or permitting the corresponding driver
of the car to add as many devices as he wants, which may interact between them and
also with other software or hardware components of the car (comfort).
To make the integration and combination of the heterogeneous components possible a
paradigm shift from hardware-driven to software-driven and network-centric
1 More information can be found in the IBM manifesto released in 2001 referenced in [6].
development is needed. The DySCAS team determines the goal of establishing a
three-way dynamic and automatic cooperation between the implanted computing
devices of the vehicle, the CE devices brought by any end user and the external
networks that some modules of the vehicle may be interested on getting access to [2].
This means that from now on more and more components will need to share both
hardware and software resources, and therefore in this new scenario the resources
cannot be bound to specific hardware or software components located in a concrete
ECU any more. Hence, resource reallocation to different units of the vehicle at run-
time should be allowed. In other words, even if an architectural hardware and
software standardization effort has already been performed, new techniques are
needed to improve the interoperability between the diverse components, their
dynamic management, portability and reusability, and at last the system efficiency.
The AUTOSAR partnership is already aware of this reality and are working on what
they call the Multimedia and Telematic module to be released as part of the second
phase of the project in 2009 [17].
The main purpose of this thesis is to point out some of the problems that the actual
version of AUTOSAR has due to its static run-time nature and offer a survey of
certain techniques and mechanisms that could help in the achievement of a solid
Multimedia and Telematic module. Autonomic computing represents a valuable
discipline that could be applied to achieve this goal, not from a business logic
perspective, but from a system self-maintenance and self-management point of view
(i.e. the ability of the system to cope with healing, optimization, configuration and
protection issues by its own, without the intervention of human administrators). The
holistic approach of autonomic computing could provide AUTOSAR with certain
tools to make it adaptive, flexible and scalable enough to allow dynamic changes of
the infrastructure and component behaviours at run-time, as well as to recover from
failures, prevent malicious attacks and optimise its operation so that the non-
functional requirements of the vehicle system (e.g. performance, response time, QoS
or security) are achieved while reducing the overall cost of ownership of the
increasingly complex vehicle software systems.
The structure of this document is as follows. Chapter 2 reviews the existing literature
of AUTOSAR, providing a comprehensive knowledge background of the application
architecture. After showing the emerging challenges of the automotive industry,
chapter 3 also exposes the major deficiencies of AUTOSAR in its aim to represent an
efficient evolving infrastructure. Chapter 4 provides briefly explains the philosophy
behind autonomic computing and provides a detailed analysis the autonomous level
and nature of AUTOSAR, highlighting the infrastructure self-description property.
Then, some of the autonomic concepts that could be applied to the framework are
introduced. They represent the core aspects of some already existing self-managed
applications described in chapter 5, which implemented mechanisms could be helpful
in the definition of a self-adaptive AUTOSAR version. The conclusion and future
work resulting from the analysis developed in this document is reflected in chapter 6,
and finally the interpretations of two interviews made to two people involved in the
AUTOSAR project are collected in the document appendix.
2 AUTOSAR
The complexity of the electronic devices included in any car has been increased over
the last decades in order to provide a better service to drivers. The functionalities are
nowadays defined by software modules created by a broad range of automotive
companies (car manufacturers or OEMs and hardware and software suppliers). These
software modules, which are embedded in the hardware environment, have to interact
with each other in order to achieve local and global system goals.
The architecture of these systems is composed by sub-systems and software
components that belong to a particular domain inside the car such as power train,
chassis, active and passive safety or body and comfort [17]. Each sub-system,
represented in an ECU, is responsible for fulfilling a concrete overall function in a
vehicle, and contains a number of components that need a data network to
communicate service demands and serve other components to achieve the ECU’s
main objectives. Components, typically developed by different companies, implement
high and low level functionalities and are responsible for controlling drivers and
hardware devices such as micro-controllers, memories or communication resources.
Traditional and proprietary solutions are not flexible enough in order to handle new
automotive expectations. These new expectations are provoking an increase of novel
networked components and innovative functions, as well as a need to reuse some of
the already existing software and hardware components between the different vehicle
platforms, OEMs and suppliers.
AUTOSAR (AUTomotive Open System ARchitecture) was founded in 2003 by major
OEMs and suppliers. It attempts to resolve all the issues related to the evolution of
automotive applications. For that purpose, a requirement and function driven
development process substitutes the typically adopted hardware and component
driven one. Furthermore, the data exchange formats and the interfaces to the different
components located in the infrastructure elements are standardised in order to enhance
the compatibility and ensure the integration of these components in the system.
To assist both the standardization of the interfaces of the components and their
seamless integration within the system the AUTOSAR methodology was created.
This methodology explains the major steps of the development of a system [3]. In
short, once the system as a whole (ECUs included) has been defined following some
meta-model description rules, manufacturers and suppliers delineate their components
in another meta-model description files. These two first tasks are performed in the
design step of the particular vehicle software infrastructure. Then, executable ECUs
are automatically generated just taking the meta-model description sources and
following some steps defined in the methodology, as well as making use of certain
software tools. Thus, AUTOSAR automates the whole ECU generation process,
except from the description of the proprietary components and their implementation,
which have to be provided by OEMs and suppliers.
2.1 Basic AUTOSAR Approach
Figure 1 shows the process of integration of the different software components into
the AUTOSAR framework from a very high level of abstraction:
Figure 1: Basic AUTOSAR approach (from [3])
There are three main parts differentiated on it. In the top the AUTOSAR components
represent the application software modules belonging to the OEMs and suppliers.
Note that “AUTOSAR components” does not mean that at that stage they are already
AUTOSAR compatible. They all have an associated Software Component (SW-C)
description which contains all the information related to the corresponding component
and constitutes part of the input data needed in the process identified by the
AUTOSAR methodology. All the information needed to describe a software
component can be found in section 2.6.
The middle part of Figure 1 represents all the steps followed by the AUTOSAR
standardization methodology. All the SW-C descriptions pointed before together with
the system description (constraints and ECU descriptions) are taken as input by this
process in order to obtain the executable ECUs mapping, represented in the third part
of Figure 1. This process is also showed in section 2.6
The different components illustrated in this last section, represent the AUTOSAR
abstract run-time architecture any final infrastructure of a particular vehicle looks like,
whatever modules each specific vehicle needs. As it can be seen in Figure 1, every
ECU is compounded by some software components. There are two different
categories of components: On one hand, the application software components perform
the concrete functionality of the ECU, and on the other hand the basic software
components offer low level services to assist the operation of the former. Basic
software components are responsible for controlling drivers and hardware devices
such as micro-controllers or memories, and also for providing communication
resources so that the application software components can obtain services from other
internal or external application software components, or any internal basic software
component. The RTE layer decouples the application software components from the
low level architecture behind. A more detailed explanation of all these concepts is
provided in section 2.3.
2.2 Challenges and Goals
AUTOSAR tries to provide a solution to the following issues observed in proprietary
infrastructures [3]:
• Lack of compatible format and content specifications so that processes meet the
overall functional requirements of the system (see these requirements in [27]).
• Each OEM and supplier uses its own tools to produce software.
• High proliferation of software components and modules that perform the same
operations. Furthermore, some of these components and modules have no value
recognised by their customers.
• Changes and functionality extension of hardware devices such as memories or
micro-controllers cause a big re-design effort.
• Complexity of inter- and intra- ECU function relocation and reuse.
• Non-competitive functions have to be adapted to OEM specific environments.
• Little innovations cannot be implemented at reasonable effort as provision of
interfaces from other components requires a lot of effort.
• Missing clear interfaces between basic software and code generated from models.
Hence, AUTOSAR constitutes a de facto open industry standard for automotive
Electric and Electronic (E/E) architectures which main objective is managing the
increasing E/E complexity associated with the growth in functional scope in order to
make the expression cooperate on standards, complete on implementation successful.
For that purpose, AUTOSAR will [3, 17]:
• Improve the flexibility for product modification, upgrade and update over the
vehicle lifetime.
• Make the transferability of functions throughout the network possible.
• Improve scalability of solutions within and across product lines so that all the
availability and safety requirements can be considered.
• Implement and standardise basic functions and modules for Commercial off-the-
shelf hardware as a standard core solution within and across product lines, making
reusability of components and redundancy activation possible.
• Integrate functional modules from multiple OEMs and suppliers in the same ECU.
• Improve quality and reliability of E/E systems. Ensure the maintainability
throughout the whole Product Life Cycle.
• Enable detection of errors in early design phases.
Consequently, the members participating in AUTOSAR can enjoy of certain benefits
listed below [28]:
• OEMs: The design flexibility obtained from the possibility of reusing software
modules, the simplification of the integration task and the reduction of total
software development costs allows OEMs to maintain the ability to compete on
innovative functions.
• Suppliers: With AUTOSAR new business models an increase of efficiency in
functional development is possible. The development can be partitioned among
some suppliers while ensuring a reduction of version proliferation.
• Tool providers: The common interfaces provided by AUTOSAR can perfectly fit
in the development processes, and they also allow a seamless, manageable and task
optimised tool landscape.
• New market entrant: Transparent and defined interfaces enable new business
models.
2.3 ECU Software Architecture
As seen before in Figure 1, the different application software components
implemented by OEMs and suppliers are mapped into ECUs that compose the
AUTOSAR framework, which improves their communication skills and facilitates
resources when they are performing their internal operation.
This section first explains the main layers (AUTOSAR Software, RTE and Basic
Software) that comprise the ECU infrastructure, and within each layer the contained
components are detailed. Then, the interfaces defined in AUTOSAR will be stated.
Figure 2 exposes a deeper view of the components located in each ECU:
Figure 2: AUTOSAR ECU software architecture (from [3])
The reviewed literature distinguishes different generic types of components. First of
all, each component encapsulates a complete (automotive) functionality or a part of it.
Components are described on the basis of a formal specification and have well
defined ports (interfaces) to interact with other components [31].
AUTOSAR software components, some components contained in the ECU
abstraction, complex device drivers and AUTOSAR services elements of the basic
software layer are known as atomic software components. These components are
defined as smallest non-dividable software entity connected to the AUTOSAR Virtual
Functional Bus, and some of them can be relocated in any ECU [31] at design-time.
On the other hand, the literature also makes a special mention to the composition of
components. Components can be packed as a composition component and can be
distributed over several ECUs [31].
2.3.1 Software Layer
This layer pretends to separate the design and development of application and
infrastructure components for software relocation and reuse purposes. It contains all
the AUTOSAR software components of the ECU, i.e. the software modules
implemented by OEMs and suppliers to perform their own defined functionalities.
The application software components develop some vehicle specific logic and are
ECU and hardware independent. Sensors and actuators encapsulate the dependencies
of the application on specific hardware sensors or actuators, so even if they are ECU
software independent they are hardware dependent, and consequently they are
typically located in the same ECU where the physical devices they are related to are.
2.3.2 Runtime Environment (RTE) Layer
RTE is the middleware that acts as a communication centre for inter- and intra-ECU
information exchange [3]. It is the layer that abstracts the AUTOSAR software
components defined above from the hardware and other software functionalities,
allowing them to communicate their demands transparently and provide service to
some other internal and external components through certain interfaces no matter their
exact location in the system. As showed in Figure 1, the Virtual Functional Bus
(VFB) represents this middleware from an abstract point of view, and includes all the
AUTOSAR communication mechanisms. However, RTE implements the VFB
functionality on a specific ECU at run-time [3], and therefore RTE is ECU and
application dependent. The implementation of the RTE is automatically generated
depending on the description of the system, the ECU and the functionalities to be
offered by that infrastructure element.
2.3.3 Basic Software Layer
The basic software provides the infrastructural services to both application and other
basic software modules contained on an ECU, abstracting them from the hardware. It
contains standardised (generic) and ECU specific components, and therefore its
implementation is partly hardware and application specific. This section explains all
the sub-layers that compose the basic software layer, as well as every component that
belongs to each sub-layer.
Figure 3 offers a more appropriate view of the ECU architecture to explain the
different components located in the basic software layer. Note that the main elements
contained in the basic software layer illustrated in Figure 2 are identified as sub-layers
or components incorporated in the sub-layers shown in Figure 3:
Figure 3: AUTOSAR ECU layered software architecture (from [28])
2.3.3.1 Services Sub-layer
The services sub-layer consists out of three different parts:
• System Services
The objective of this group of modules is to provide basic services for application and
basic software modules. Examples are the operating system, the error manager and
some library functions (like CRC, interpolation, etc.) [3]. Some of these services are
hardware and/or application dependent and some others are hardware independent.
These modules are contained in the services component illustrated in Figure 2.
• Communication Services
This group of modules is responsible for managing all the inter- and intra-ECU
communication services so that different applications can exchange data, demand
utilities or functionalities, as well as perform diagnostic and network management
operations. Communication services correspond to the communication element
represented in Figure 2 (this element also considers I/O management as part of its
responsibilities) and provide a uniform interface to vehicle network communications
while encapsulating protocol and message properties for the RTE and applications.
These services make the software components location independent.
There are two different types of communication relationships existing between the
components: Inter- and intra-ECU communication, each with some particular
mechanisms associated. The former mechanism could be e.g. a COM message and the
latter e.g. a simple function call. AUTOSAR offers four inter-ECU communication
protocols2 (CAN, LIN, FlexRay and MOST), and allows the addition of others
through the Complex Drivers element, which will be explained later. More
information about component communication can be found in section 4 of the
appendix at the end of this document.
• Memory Services
These services are responsible for the management of non volatile data3. A uniform
interface allows components to perform functions such as saving, loading, checksum
protection and verification, reliable storage, etc. independently from the real location
and properties of the physical memory devices. For example, the NVRAM manager
provides a RAM mirror as data interface to the application [3]. Memory services are
considered to be part of the Services component shown in Figure 2.
2.3.3.2 ECU Abstraction Sub-layer
This sub-layer abstracts the basic services from the concrete drivers, allowing each
service to get access to all the different drivers included in the ECU using the same
mechanism. The ECU abstraction sub-layer is subdivided into five parts:
• Onboard Device Abstraction
These software modules provide equal mechanisms to access ECU specific on-board
devices (such as system basic chip, external watchdog, etc.) not seen as sensors or
actuators.
• Communication Hardware Abstraction
This group of modules provides equal mechanisms to access a bus channel regardless
of whether it is located inside the microcontroller (on-chip), externally to it (on-
board).
• Memory Hardware Abstraction
The task of this group of software elements is to provide equal mechanisms to access
internal (on-chip) and external (on-board) memory devices such as EEPROM.
2 These communication protocols are out of the scope of this document. For further information see [29]. 3 For more detail about the different memories considered by AUTOSAR see [30].
• I/O Hardware Abstraction
The modules contained in this group represent I/O signals coming from some ECU
hardware such as current, voltage and frequency. They provide equal mechanisms to
access peripheral I/O devices not seen as sensors or actuators.
• Complex Drivers
This sub-layer allows applications to get direct access to OEMs and suppliers
proprietary hardware devices (i.e. sensors, actuators and AUTOSAR non supported
devices). OEMs and suppliers can extend their implementations just adjusting to
AUTOSAR Interface standards.
2.3.3.3 Microcontroller Abstraction Sub-layer
This sub-layer contains all the drivers needed to manage and control the hardware
devices being used in the ECU. There are four types of drivers [3]:
• Microcontroller Drivers
Drivers for internal peripherals (e.g. watchdog, clock unit) and functions with direct
microcontroller access (e.g. RAM test, core test).
• Communication Drivers
Drivers for ECU on-board (e.g. SPI, I2C) and vehicle communication (e.g. CAN).
• Memory Drivers
Drivers for on-chip memory devices (e.g. internal Flash, internal EEPROM) and
memory mapped external memory devices (e.g. external Flash).
• I/O Drivers
Drivers for analog and digital I/O (e.g. ADC, PWM, DIO).
2.3.4 Deeper View of Basic Software Components: Mem ory
Example
Figure 4 shows how the NVRAM Manager and the Watchdog Manager interact with
some drivers on an assumed hardware configuration [8]. As it can be seen each sub-
layer contains many components, each with a particular responsibility to fulfil:
Figure 4: Interaction of the basic software sub-layers example (from [8])
AUTOSAR managers offer specific services for multiple clients (in this case
NVRAM and Watchdog management operations to other application and basic
software components), and they can evaluate, change and adapt the content of the data
[8].
In the example, NVRAM Manager manages the concurrent access the internal and/or
external Flash and EEPROM memory devices. Furthermore, it manages RAM
mirrors, redundant, distributed and reliable data storage, data checking, provision of
default values, etc. [8]. The Memory Abstraction Interface eases the access to various
memory devices, improving the scalability and implementation efficiency.
2.4 Classification of Interfaces
Interfaces constitute the glue between the different entities that compose the
AUTOSAR Infrastructure. They describe the services that each AUTOSAR software
component and basic software element publishes as well as the data they exchange.
There are three different types of interfaces:
2.4.1 AUTOSAR Interface
This type of interfaces is specified and implemented according to the AUTOSAR
Interface Definition Language, which is completely independent of any specific
programming language, ECU or network technology. Therefore, apart from being
used in order to describe services and exchanged data this interface also allows
software components to be distributed among the different ECUs that compose the
network at design-time.
All the AUTOSAR software components have to publish an AUTOSAR interface to
communicate with other AUTOSAR and basic software components. Also, the ECU
abstraction layer and the complex drivers’ layer have also to offer this type of
interface, as certain AUTOSAR software components that belong to other ECUs
might need to get access to their contained resources.
Because some of these modules are developed by suppliers and OEMs certain
proprietary aspects might be included in interfaces of this type. Therefore they are
considered to be partially standardised within AUTOSAR.
2.4.2 Standardised AUTOSAR Interface
Standardised AUTOSAR interfaces are special AUTOSAR interfaces provided by the
basic software services layer. Their syntax and semantics are fully standardised in
AUTOSAR.
2.4.3 Standardised Interface
Similarly to the standardised AUTOSAR interfaces, this type of interface also carries
out the AUTOSAR standard, but it is programming language dependent, and therefore
they are used to communicate modules contained in the same ECU. The interface has
to contain any concrete standardised API (e.g. the OSEK COM interface) in order to
be considered standardised.
The communication services layer publishes an interface to allow the AUTOSAR
software components of the ECU to communicate via the communication drivers with
the corresponding external components. The communication requirements of the
components are application dependent, which explains why RTEs contained in
distinct ECUs are different between them.
2.5 Communication Mechanisms
The interfaces just explained in the previous section are used to define the services or
data provided on or required by a port of a component [3]. Every component has well-
defined ports to interact with other components. There are two types of ports in
AUTOSAR: PPorts provide an interface, and RPorts requires an interface.
AUTOSAR offers two different communication patterns, as exposed next.
2.5.1 Client-Server Communication Pattern
In this case a component acts as a client of any server requested to another component
that acts as a server. Any single component can be both a client and a server,
depending on the software realization [3]. This pattern supports both synchronous and
asynchronous communication.
Figure 5 enhances the previous explanation:
Figure 5: Client-Server communication pattern (from [3])
2.5.2 Sender-Receiver Communication Pattern
This type of communication pattern is used whenever the sender ignores the identity
or the number of receivers (e.g. distribution of events). It sends the information
though the communication infrastructure, which has the responsibility of distributing
the information in an asynchronous way, and then the receivers decide autonomously
when and how to use this information. This pattern is an implementation of the
publisher-subscriber approach, which is also commonly known as the event-oriented
communication pattern.
Figure 6 illustrates the previous explanation:
Figure 6: Sender-Receiver communication pattern (from [3])
2.6 AUTOSAR Methodology Overview
As it was explained in section 2.1, the AUTOSAR methodology defines the main
steps to be followed in order to generate executable ECUs from some system and
components description documents. As it was shown in Figure 1, depending on the
content of these descriptions AUTOSAR automatically creates ECUs, generates and
adjusts the corresponding RTE as well as the basic software components needed by
each ECU, and also allocates the application components in the suitable ECU.
Furthermore, AUTOSAR allows the seamless integration of new application
components into the system at design-time, also using component description
documents.
AUTOSAR intends to ease the formal description of the initial system design
decisions defining an information exchange format and using some templates [3].
Therefore, the standard interfaces exposed above are part of the information that has
to be captured in each AUTOSAR component description meta-model, which is
provided by the owner of the corresponding atomic software component.
This meta-model divided into the next templates [32]:
• Generic structure.
• Software components template.
• ECU resources template.
• System template.
Focusing in software components, they are described by the software components
template, which has to provide [32]:
• The description of the component at VFB level:
o The software component itself.
o Its compositions with other software components.
o Its interfaces (to allow interactions with other software components) i.e. the
operations and data elements that the software component provides and
requires [3].
• The description of the component at RTE level (internal behaviour of the
component):
o Interaction with the RTE, i.e. the requirements which the software component
has on the infrastructure (e.g. tell RTE what units have to be activated
whenever a concrete operation is invoked) and the resources needed by the
software component (memory, CPU-time, etc.) [3].
• The description of the component at implementation level:
o Component implementation.
o Resource consumption of AUTOSAR software components.
Following the methodology to define templates in AUTOSAR, for each component a
concrete XML schema (mapped from the every component meta-model defined
before) and the corresponding XML descriptions are automatically generated. The
descriptions will be completed with the ECU and the system specific information so
that the system configuration input XML file can be created.
The content of the system configuration input document is inferred from all the
models included in the meta-model, which templates have to be filled out or edited by
the different teams that integrate the AUTOSAR organization.
Finally, the AUTOSAR methodology uses this document to create the executable
ECUs, assign the components to the pertinent ones and integrate them all. Figure 7
illustrates the main steps taken in this process:
Figure 7: Process to create an ECU executable (from [3])
As it can be seen in Figure 7, this methodology is a mere work-product flow, as it
defines the dependencies of activities on work-products. Here work-product describes
a piece of information or physical entity produced or used by an activity, which
represents a piece of work performed by one or a group of people [3].
In order to integrate the software components into the system the components API
and their implementation have to be generated. The latter is more or less independent
from the ECU configuration, so AUTOSAR is just responsible of creating the
component API from the component internal behaviour description work-product
(part of the software component template that has to be provided by the owner of the
component) using the AUTOSAR component API generator tool. The component
integration steps are shown in Figure 8:
Figure 8: Process to implement and integrate a component in AUTOSAR (from [3])
More steps of the methodology are explained in the AUTOSAR documents
downloadable from [26].
3 Emerging Challenges in the Automotive Sector
IBM released a manifesto in 2001 revealing a software complexity crisis produced by
exponentially raising number of novel systems and devices, which generate a vast
flow of data transmitted between them on the network. This complexity is also
increasing due to the need of integrating heterogeneous environments that extend
beyond company boundaries into the Internet [6]. Actually, some market analysis
referenced in [19] appraise that nowadays 25%-50% of IT resources are spent on
problem determination, and more than 40% of all the software investments across all
the industries are destined to try to get the different existing technologies to work
together.
Figure 9: New boundaries for vehicle intra- and inter-communication (from [11])
As pointed at introduction, this software crisis also affects the automotive sector, and
therefore some of the mechanisms and techniques implemented to cope with the
emerging challenges of the traditional software development need to be applied to
vehicle infrastructures. The list showed below has been obtained from [9], and
summarises these new challenges:
• Interaction with strangers: A dynamic environment is a priory composed by some
unpredictable and unknown heterogeneous components that interact with each
other requesting and providing certain services in order to satisfy their own goals.
Therefore there should be some mechanisms to manage both trust (i.e. each
component should be able to identify their clients4 and know their exact motives)
and the privacy of users and services end-to-end.
• Information reflection and collection: All the components included in the system
should be able to understand the circulating data so that they can process it and
deliver certain service to other components while satisfying their own goals.
Hence, a lingua franca that allows them to decide between competing demands is
needed.
Some common language has to be defined so that the components know the
contents and the uses of the data is being transported over the network, as well as
to determine the behaviour of the network itself e.g. to predict, recover and avoid
certain events such as routing failures.
Every component that belongs to the system has to describe the services it offers,
its restrictions (e.g. parameters to be provided by clients), and even the results so
that its clients can interpret them correctly. The existence of a contract between the
component and its clients that imposes certain levels of agreement is fundamental
to ensure that together they meet the goals of the system. Consequently, to achieve
an effective interoperation between components belonging to an autonomic
solution they have to adopt standard interfaces and semantics.
• Lack of centralised goals and control: Decentralisation is a very important
characteristic that the system must accomplish. It provides robustness in the
operation of the system, allowing the incorporation of new components and
services as well as the disappearance of the existing ones in a completely seamless
way.
• Context awareness and meaningful adaptation: Every component has to be context
aware and be able to adapt itself to any context changes so that it can keep on
providing the requested and expected Quality of Service (QoS) to its clients. The
inclusion, exclusion and optimization of services make the environment to be
highly dynamic, but mechanisms to protect the good operation of the system have
to be developed. Some of these services might change the environment, so
4 The term client refers to any software component or device that precise some service from some other software
component in this document. Human clients are referred as such.
maintaining certain key behaviours and avoid deleterious ones as well as
undesirable interactions becomes a must.
• Cooperative behaviour in the face of competition: The lack of centralisation
exposed previously could allow some components to impose their own goals over
others’ goals. Because of this reason, some cooperation and negotiation techniques
have to be defined in order to ensure a social equilibrium in the environment.
• Component task coordination and complex interdependencies conflict solving [18]:
Most components are able to perform various tasks simultaneously within
themselves and in collaboration with some other components. Consequently each
element has to manage multiple threads so that the correctness of local and global
concurrent and asynchronous operations is ensured. Tasks coordination conflicts
must be detected and resolved at once.
• Minimise the human intervention: Decreasing the human intervention on the
system becomes a must to deal with these complexities. New ways to allow system
administrators to express their goals and let the system to take care of the details
have to be implemented, e.g. using policies or rules to express their objectives in a
natural manner. These policies have to be suited to human psychology and
cognition to avoid specification errors. Yet on the other hand they must be
sufficiently structured so that the components can understand them.
3.1 Overall AUTOSAR Problems
As it was pointed in the introduction, even if AUTOSAR supposes a fundamental step
towards achieving more performing and reliable automotive architectures it does not
sufficiently cope with the trends and challenges arisen by the evolution of the market
(i.e. advanced security measures such as the inter-vehicle communication and
consumer entertainment functions such as multiple device connection and inter-
operation are not supported).
AUTOSAR offers some standard templates to define components and their
relationships between them so that the different OEMs and suppliers can integrate
their products into the vehicle infrastructure seamlessly at design-time, but as it is
explained in sections 2, 3 and 4 of the appendix, once assembled the resulting
AUTOSAR infrastructure is static at run-time and consequently no configuration
changes or resource allocation are allowed. Hence, AUTOSAR cannot cope with the
complexities arisen by the increasing amount of novel functionalities that the market
is starting to demand, such as the ability of detect and integrate new and maybe a
priori unknown devices at run-time.
Furthermore, the implementation of a wide range of novel hardware and software
components needed to cover the demanded new functionalities puts two new
complexity factors in place that should also be considered in AUTOSAR. First, the
amount of interactions between components is rising exponentially, and second,
components have to interact also with their environment, reacting and evolving
consequently. Hence, the latest requirements could make the limits of human
capability to be approached, as nobody could be responsible of installing and
maintaining the potential myriad of required software modules.
The framework has been designed following current distributed but structured
computing techniques, and consequently AUTOSAR shares the next four aspects with
some other traditional solutions [6]:
• The more manufacturers, suppliers and tool providers join the partnership the more
time consuming and error prone the tasks of installing, configuring and integrating
systems will be.
• Tuning the increasing number of software components and hardware devices
parameters at run-time is difficult, if not impossible.
• Problem determination can take weeks to a team of programmers.
• Detection of and recovery from attacks and cascading failures is manual.
Moreover, it does not yet sufficiently address time and platform modelling and
specification. Racu et al. argue in [4] that the system is suffering a time and
performance degradation due to certain tasks related to dynamic inter- and intra-ECU
component interactions such as scheduling, arbitration, blocking and buffering.
Remote interactions, showed in Figure 10, lead to some causality chains, which define
the flow of calls that components have to execute to get the service they need from
other components located in different ECUs. The time invested in these causality
chains is a priori uncertain. Therefore, AUTOSAR does not behave as a proper real-
time system.
Figure 10: Communication mechanism defined in AUTOSAR (from [4])
As suggested in section 4 of the appendix, application software components do not
usually have “direct” access to the hardware resources located in any other ECU, even
if e.g. some communication hardware abstraction mechanisms have been designed for
that purpose, as exposed in chapter 2. They normally contact an application software
component of the external ECU so that it provides the requested service. This means
that no hardware component is considered shared per se, complicating the real-time
resource (function) reallocation at run-time.
Finally, some automotive industry and software and hardware constraints in actual
ECUs represent another problem to succeed in the improvement of AUTOSAR. First
of all, the automotive sector behaves in a conservative way: while decreasing (or at
least keeping increase as small as possible) the cost is crucial, increasing the
flexibility of the system is not important, even if the ability to create variants is a
must. Secondly, limited processing and memory, communication bus data rates
restriction or difficulties in changing embedded code also affect in the system
incapacity of coping with the new challenges [5]. Even if the existing platforms are
considered unalterable at the moment, software and hardware enhancements might
have to be performed in an immediate future, which might increase the vehicle
production costs.
Because of all these reasons, autonomic computing represents a potential solution to
sort these problems out.
4 Autonomic Enhancements
4.1 Actual Autonomic Level of AUTOSAR
4.1.1 Quick Overview of Autonomic Computing
As part of the IBM manifesto presented at 2001 by Paul Horn, IBM Senior Vice
President and Director of Research, gave the following message to the audience [35]:
The information technology industry loves to prove the impossible possible. We
obliterate barriers and set records with astonishing regularity. But now we face a
problem springing from the very core of our success—and too few of us are focused
on solving it. More than any other I/T problem, this one—if it remains unsolved—will
actually prevent us from moving to the next era of computing. The obstacle is
complexity . . . Dealing with it is the single most important challenge facing the I/T
industry.
Autonomic computing aims to create systems that can manage themselves given high-
level objectives from administrators [6] so that they can handle the increasing
complexity Paul Horn was talking about as part of his speech. Even if there is no
common accepted definition of autonomic computing yet [33], most of the authors
focused in this field agree that it represents a holistic approach that gathers many
technologies, mechanisms and methodologies5 that already exist in order to both
handle the increasing complexity from a system management and maintenance point
of view and cope with the challenges mentioned in chapter 3 and lower the total cost
of ownership [34].
Most of the authors also agree that concepts from diverse and apparently unrelated
disciplines such as e.g. biology, psychology, philosophy and economics could be
beneficial to make the systems behave in an autonomous way. Furthermore, the first
of the mentioned disciplines suggests the metaphoric comparison of this type of
systems with the human nervous system. A comprehensive example of how the
Ashby's Ultrastable System, which defines the human behaviour adaptability to
dynamically created disturbances in the essential variables of the body (e.g.
concentration of glucose in the blood), could be applied in autonomic systems can be
5 Some of these mechanisms are presented in section 4.2.
found in [37]. As pointed at [36], this system is able to effectively monitor, control
and regulate the human body without external intervention. This means that a system
can be considered be self-managed all its components have to control their own
behaviour and adapt themselves to the changes produced in their environment i.e.
self- and context-awareness is a must in autonomic systems.
To achieve self-management6 every autonomic system has to satisfy some so-called
self-* properties. The next section provides a list with all these properties, and offers
an analysis of how well does AUTOSAR satisfy each of them:
4.1.2 How Autonomic Properties could Enhance AUTOSA R
• Self-Configuration: The system has to adjust itself to environmental changes such
as the incorporation of newly discovered components. In AUTOSAR application
software components just need to be described in some templates at design-time,
along with the relationships that they have with other components. Then, a self-
assembly process defined by the AUTOSAR methodology takes these descriptions
and their corresponding implementations (the business logic of each component)
and creates the whole vehicle infrastructure of executable ECUs automatically. No
dynamic reconfiguration is supported at run-time, as the relationships between
components are hard-coded, which denies the components context-awareness skill.
Hence, AUTOSAR cannot be considered self-configured.
• Self-Description: Each component of the system has to interact with others so that
they can exchange information and understand the service demands that some of
them have over others. Therefore, each element has to express and publish its
needs, capabilities (services they offer) and properties following a common format
so they all understand each other. AUTOSAR aims to create a lingua franca
between components standardizing both their interfaces and the exchanged data
formats as a measurement for easing the complexities caused by the arising
heterogeneous relationships. AUTOSAR is a self-described system.
• Self-Optimization: The system should be able to adjust its behaviour in order to
improve its performance and efficiency. Once the run-time infrastructure is created
in AUTOSAR it remains static and therefore no changes are allowed in its
6 Even if the present version of AUTOSAR satisfies all the functional and non-functional requirements it is not
able to cope with the emerging challenges and trends, and therefore self-management is required.
configuration. Function allocation [3] is only tolerated in design-time, no load
balancing mechanism is supported by AUTOSAR, and as it was exposed
previously, the actual version of AUTOSAR leads to timing problems in
processing the information, which may endanger real-time response ability needed
so much in the automotive products.
• Self-Healing: Appropriate adjustments to recover from possible component failures
are a must in self-managed systems. AUTOSAR handles errors both at design- and
run-time for component integration support by some in-field diagnosis and
recovery techniques respectively, both provided by the AUTOSAR Basic Software
[7]. Unfortunately these mechanisms are more error reporters rather than error
solvers, as they escalate the problems to upper software layers until a component
knows how to resolve the problem. This process might consume more time than
the expected in certain situations where the issue is difficult to resolve and critical
in the operation of the application. The ID-prioritised message technique approach
that AUTOSAR uses, in which messages that contain a higher ID are processed
before messages with a lower ID is not good enough to ensure that whenever there
is any problem in any module the system will operate correctly. More sophisticated
and secure fault-tolerance mechanisms are needed in the vehicle, e.g. service
redundancy, which even if it is supported by AUTOSAR it is only applied to the
very critical areas of the vehicle (e.g. the break system has its software components
duplicated just in case one fails) and only at design-time.
• Self-Protection: The protection is achieved in two ways: On one hand, defending
itself against problems arising from malicious attacks or cascading failures (which
consequences are corrected by self-healing measures), and on the other hand
anticipating possible problems before they occur. AUTOSAR provides some
reliability mechanisms among communication fundamentally based on traditional
networking data integrity, message loss and sender failure detection, and
acknowledgement techniques [8]. However smarter mechanisms are needed in a
highly device populated environment, where components cannot trust on other
newly incorporated devices and/or software downloads as they may affect
negatively the operation of the system.
• Self-Updating: The software has to be upgraded so that the latest innovations can
be added to the vehicle post-manufacture. AUTOSAR contemplates the possibility
of improving and enhancing its infrastructure while securing the achieved level of
standardization through some standard maintenance (release management of new
versions), conformance testing and validation mechanisms [7], which always are
executed offline. Hence, novel techniques are needed so that AUTOSAR achieves
this property.
4.1.3 The Autonomic Contribution of AUTOSAR: Self-D escription
One of the most important design steps of every large-scale software application
developed by many different parties consists of consenting some common syntax and
semantics for the exchanging data, so that the various components included in the
system can interpret correctly the needs that some others have and serve them
appropriately. This exchanging data has traditionally been represented in informal
documents, but the complexities arising in nowadays automotive systems requires a
more formal machine readable exchange of information [24].
XML turned out to be a fantastic technology to standardise common domain-specific
languages, as the contents to be exchanged can be structured nicely in a human and
machine readable way and the produced documents can be processed and validated by
high quality off-the-shelf XML libraries and tools. However, XML is not good
enough to achieve the ambitious main goal of AUTOSAR: let any hardware and/or
software suppliers completely describe its components at system design-time so that a
code generation process can automatically implement the final run-time infrastructure,
reducing all the integration efforts and costs.
AUTOSAR partnership consists of more than 100 companies (status July 2006) [17],
and the aim of the project is allow any new market entrant to integrate their products
in the resulting infrastructures. Therefore, it is paramount to ensure that the next
conditions are satisfied:
• The complex interlinked relationships that components have between them have to
be understandable and easy to maintain by humans.
• The technology chosen to represent concepts in AUTOSAR has to be able to
describe any aspect of the architecture, even fine-level constraint details.
The AUTOSAR meta-model language supposes a XML abstraction that satisfies the
two previous conditions. A graphical representation and a UML designing tools allow
the different parties to work together and to get the big picture of the system at any
step of design. Thus, experts can concentrate on their domain knowledge without
caring about the best way of representing concepts and constraints in XML.
XML is still considered the best machine readable language however, and
consequently the meta-model is mapped to XML documents and schemas. XML
schemas cannot represent component constraints, so the use of a specific Object
Constraint Language is also a must.
4.2 Holistic Approach for Autonomic Computing
Even if AUTOSAR self-description property smoothes the path of creating self-
adaptive automotive infrastructures, there are still certain aspects to be applied in
order to achieve autonomy. These aspects are control theory, agency, adaptive
middleware and real-time configuration.
4.2.1 Control Theoretic Approach
An autonomic system has to get feedback on its own ongoing behaviour in order to be
able to react to evolving situations and pre-empt expected future demands. It offers an
open environment for rapid and dynamic resource integration where federations of
heterogeneous sub-systems are formed with no central authority or unified
infrastructure [9]. Hence, these sub-systems need to be self-managed themselves
while the system as a whole must behave as expected. Each former system
constituent, also called autonomic element, manages certain resources or managed
elements through an autonomic manager, which controls the internal behaviour of the
whole element and the relationships it has with other elements, in order to satisfy the
main goal of the system. The manager element forms a control loop consisting on
getting feedback of its managed elements and the external environment, analyses it,
makes the decision of what to do to meet its own objectives and reacts consequently
affecting the managed elements, changing the environment and/or reporting an
administrator or a higher level autonomic element.
Figure 11: Autonomic elements interaction and autonomic control loop diagram (from [6])
ECUs could be seen as autonomic elements in AUTOSAR, and the different memory
devices, communication channels and the micro-controller managed elements.
AUTOSAR development partnership exposes in [8] that AUTOSAR managers (e.g.
NVRAM manager) located in the service layer offer specific services for multiple
clients while evaluating and changing or adapting the content of the data. However, in
reality they just turn to be simple ECU brokers for resource concurrent access
showing no autonomous behaviours. They just serve all the requests they receive with
very static manners, prioritizing them by message ID without:
• Collecting environment information and user context.
• Analysing the input data or the intentions that the requesters have over the
resources, as well as the consequences that the execution of the requesters wills
might have over the element and its environment.
• Making the decision of whether the requester deserves to be served or not.
• Retaining any knowledge that could help improving their operation.
These basic layer managers do not perform an autonomic control loop in their own. It
is expected that in a near future a broad amount of novel and more sophisticated
resources will be demanded to be included in a vehicle, which has to show an
intelligent behaviour. Therefore, some critical redesign and development which could
involve changing some basic and application software components is needed in the
system architecture to support an appropriate control theory approach.
4.2.2 The Need for Agency
AUTOSAR provides a structural function-oriented infrastructure, and therefore its
flexibility and scalability are limited just to design-time. However, emerging
challenges such as the ability of integrating a heterogeneous and a priori unknown set
of components and devices as well as enlarging the environment scope to the Internet,
as proposed by [11], require that each component to be specialised in achieving some
concrete responsibilities as well as to provide certain services to others. Therefore
components need to have their functional boundaries defined. Furthermore, some
techniques are required to support self-management (e.g. self-healing can be achieved
through component redundancy7, which may require multiple instantiation of
components, and function allocation8 is needed for self-optimization) and to improve
the interoperability between components through language-neutral interfaces and
communication independent protocols.
The function-oriented infrastructure defined in AUTOSAR is based on the Service-
Oriented Architectures (SOA) paradigm [10], which enables components to offer
coarse-grained so that they can perform actions on behalf of their clients, and
consequently, provide better inter- and intra-ECU services. SOA generates significant
advantages such as:
• Perform some operations in fewer interactions, as individual components have not
as much importance as functional entities, reducing therefore the system
throughput.
7 Even if redundancy is collected in [3] as built-in service declines it in practice. 8 Even if function allocation is collected in [3] as built-in service declines it in practice.
• Improve the robustness of components interactions and the understanding of the
whole set of services provided by each component. Clients should not be aware of
their service provider component changes and decomposition, because it could
complicate their implementation.
SOA needs standardization of both component interfaces (for operation orchestration
purposes) and data structures, which are typically document-centric. AUTOSAR
already provides a standard approach for these two communication elements. The
combination of standards and the SOA paradigm sub-interfaces makes AUTOSAR
robust enough to differentiate service providers without compromising
interoperability.
In spite of all the advantages just mentioned about SOA, autonomic computing
requires more [6]. First, as service providers components should only accept requests
if attending them is consistent with their goals. Second, as consumers they should
proactively ask others to perform certain tasks so that they can achieve their
objectives, and finally all components should be self- and context-aware to be able to
adapt to a priori unknown situations. Components could be seen as autonomous
software agents that satisfy the previous three requirements. Each agent is equivalent
to an autonomic element that manages certain resources through its own control loop.
Hence, AUTOSAR should ideally operate as a multi-agent system.
Agency supposes a practical solution to achieve control theory. The creation of a
number of agents responsible for managing ECUs and/or some application software
components (depending on how complex the latter are) which receive service requests
and context information from other agents and the environment respectively, analyse
the data, organise an execution plan and react consequently could make their managed
elements evolve in order to meet altogether the corresponding non-functional
requirements of the automotive system. Hence, a deeper research on more
sophisticated embedded programming models should be done, as system architecture
and software evolution is not easy to achieve with the structural languages used to
program components in vehicle systems, such as C (e.g. it is difficult to emulate
software techniques such as the implementation of the Inversion of Control pattern
[38] or reflection [39] in these types of languages). However, it is also fundamental to
suggest these novel programming models could involve a change on the actual
automotive industry and hardware and software constraints.
4.2.3 Adaptive Middleware Approaches
Middleware can suitably be defined as a software layer between applications, the
operating system and the network communications layers, the purpose of which is to
facilitate and coordinate some aspect of cooperative processing [12]. Traditional
middleware approaches were created to tackle the integration complexities existing in
proprietary platforms using a commonly-agreed object model or messaging
framework, while trying to increase the system robustness, scalability, adaptability
and reliability, as well as routing the pertinent information transparently between the
applications.
Figure 12: Generic middleware architecture (from [12])
The Virtual Functional Bus (VFB) in AUTOSAR is a software layer between the
application software and basic software layers. VFB is just a logical entity during
design time. It aims to fulfil the goals of communication transparency and function
reallocation.
The greatest success in terms of automation accomplished by AUTOSAR consists of
the ability of automatically generate a set of executable ECUs and integrate them
conforming a final system infrastructure, following some instructions defined in
certain XML documents (so-called templates) that describe the application software
components needed in the vehicle and the relationships between them. At build-time a
collection of language-dependant APIs, connector and stub code are automatically
generated in each ECU composing the AUTOSAR Run-Time Environment (RTE),
which publishes a number of functions from the components included locally and in
remote ECUs. Any application component get service from the others no matter
where they are located and what technology characteristics and constraints they have.
The RTE makes the application software components independent from the hardware
underneath, the ECU, the location of other application software components and the
type of service request (intra- or inter-ECU).
The intra- and inter-ECU communication mechanisms existing in AUTOSAR are:
• Normal function calls for intra-ECU communication, which follow the
synchronous client-server pattern defined in [3]. The RTE publishes functions that
follow the conventions RTE_READ_XYZ and RTE_WRITE_XYZ, where XYZ
corresponds to a method name provided by other local and remote components.
• Message and event mechanisms for inter-ECU communication, which follow the
asynchronous client-server pattern and the asynchronous sender-receiver pattern
respectively, both defined in [3]. Analogously to the case of the client-server
pattern, in the case of the sender-receiver pattern the RTE publishes functions that
follow the conventions RTE_SEND_XYZ and RTE_RECEIVE_XYZ.
As it can be noticed in the previous paragraph and also in the figures exposed in [4],
the RTE is a message- and event-oriented middleware for inter-ECU communication.
Both middleware approaches aim to maintain portability, flexibility and
interoperability of communication services in a heterogeneous environment over the
time as the system evolves, which is achieved by decoupling the senders from the
receivers.
Reliability is paramount in vehicle infrastructures. In point-to-point information
exchange, Message-Oriented Middleware (MOM), this property is guaranteed by
some message queues in which messages are stored until they can be processed by the
corresponding consumer. Event-Oriented Middleware (EOM) sets up some channels
for event multicasting (small packages of information that typically indicates a change
in the state of a component are sent over the network) among a concrete amount of
components, which are subscribed to one or more channels depending on the event
types they are interested on.
These middleware approaches plus message and event content standardization to
ensure that the pertinent receiver components included in the system understand them
make AUTOSAR reliable. However, and because of the timing degradation pointed in
section 3.1, it does not represent a real-time system, which is mandatory in the
automotive context.
The RTE layer in AUTOSAR has to be enhanced to satisfy the next properties so that
it becomes an appropriate adaptive middleware layer:
• Predictability and Stability: The standardization of interfaces and exchange data
already defined by AUTOSAR favours the generation of an open set of self-
described components. Open-adaptability to post-deployment changes and the
anticipation of the possible consequences of component interactions are two
desired effects9 vital to ensure the stability of the system operation.
• Reliability: Even if the actual MOM-based solution implemented by AUTOSAR
ensures reliability from the message delivery point of view, better mechanisms that
support fault tolerance are needed, such as replication, stable storage, concurrency
control and failure handling.
• Naming and Binding: New techniques for naming, service location and discovery,
transparent transport and binding are required so that new components and devices
can be added seamlessly into the infrastructure at run-time and they can
communicate with other local or remote components (the latter could be inter-ECU
or located on the Internet). Relationships between components are hard-coded in
the RTE layer at run-time, making the structure in the final system to be immutable
and therefore preventing its dynamic reconfiguration.
• Security and Authentication: These new and a priori unknown components and
devices cause the need of new instruments to ensure the overall trustworthiness in
the system while trying not to impact too much on its performance. Policy-based
computing could be useful for this purpose.
Traditional object broker systems like CORBA represents good platforms on which to
build adaptive services. A container of components sitting on each node (nodes can be
seen as ECUs in automotive) of the system provides core management and
communication services, not only providing a single-point of control over the
corresponding node but also a non-centralised control mechanism over the system as a
whole, making the latter more scalable, flexible and robust. Core management offers
9 Standardization has to be combined with some other techniques such as a policy-based system to get the expected
effects.
services such as component lifecycle management and concurrency control, whereas
communication services include between others naming, service location and
discovery, asynchronous event-based services dynamic rebinding and some security
services such as secure channel creation, authorization, access control or policy
protection and trust. An appropriate object request broker could handle all the
information distribution and system heterogeneity issues.
This means that a complete decoupling between entities could be fulfilled and
therefore that components could change their location at run-time. On the other hand,
components are fully documented, marked-up and registered, and therefore clients
could locate them and activate their services based on their meta-model descriptions,
which also improves reusability of components.
The component registry element is typically centralised somewhere in the system, and
therefore its location is usually hard-coded in every component that needs to join the
system. The Peer to Peer (P2P) approach could be a fantastic solution to avoid
centralization, as it could strategically replicate the registry in a certain number of
nodes (ECUs of the vehicle) to ensure the correct system operation in node failure
situations. The International Naming System initiative mentioned in [12] represents
the best example, as it aims to create a service announcement mechanism that allows
clients to discover which components could provide the service they need in order to
satisfy their particular interests. Hence, a P2P system could be built in the top of the
suggested adaptive object broker system to improve the robustness and reliability on
the system while decentralizing its service location and discovery mechanisms.
However, as suggested in section 1 of the appendix, the use of an object-oriented
paradigm in embedded systems could also have some unwanted side effects such as
the uncertain time that garbage collection tasks could take and the high resource
consumption that these types of programming models have. Similarly to the
technology problems presented in the previous section, both issues are not compatible
with the automotive industry and software and hardware constraints mentioned in
section 3.1, and therefore while these constraints do not change some other
approaches should be found. The emerging challenges and trends demand the design
and development of an advanced self-managing middleware solution.
4.2.4 Real-Time Configuration
Safety must be guaranteed in any automotive infrastructure, while decreasing the cost
of its construction is paramount. Furthermore, the automotive market is highly
competitive, where a continuous increase on software quality and productivity is
needed. Hence, a real-time approach is needed to ensure that the values of some end-
to-end QoS requirements of the embedded system such as bandwidth, latency, jitter
and dependability are maintained within a reasonable range. On the other hand, this
approach could ideal to reduce development costs while increasing quality, as it
encourages software reusability and decreases cycle-time and implementation efforts.
As pointed before CORBA interfaces are widely-accepted by different service
providers and consumers, and allow the integration and inter-communication of
proprietary components regardless the language they are built, the platform they are
running in and their exact location in the system. However, like some other ORBs
such as DCOM or RMI, it is unsuitable for real-time applications because it does not
address issues of timeliness and predictability of service. A study exposed in [20]
show four historical limitations that traditional Distributed Object Computing (DOC)
middleware has when in terms of QoS specification and enforcement:
• Lack of QoS specification and enforcement: End-to-end QoS requirements are
neither specified by any API that should be offered by the application components
nor enforced by any mechanism across the network in conventional ORBs. Some
standard techniques are needed to e.g. allow clients to dynamically schedule their
requests depending on deadlines, or inform servers about the priority of the
requests they receive.
• Lack of real-time features: It results very difficult to predict how the system will
behave in high network traffic congestion scenarios. Consequently, certain key
features that support time-constrained real-time programming have to be provided
so that e.g. application components do not block whenever ORB end-systems and
network resources are unavailable, or exceptions are properly propagated if servers
miss the deadlines they have agreed with their clients.
• Lack of performance optimizations: Big throughput and latency overhead is
unaffordable in any time-critical environment, which stems from reasons such as
excessive data copying, non-optimised presentation layer conversions or a lack of
integration with underlying real-time OS and network QoS mechanisms, among
other causes10.
• Lack of memory footprint optimizations: Embedded systems have tight constraints
on memory footprint due to cost, power consumption, or weight restrictions.
TAO [20, 21, 22] is an open-source and standards-compliant implementation of the
real-time CORBA specification defined by the OMG. It attempts to satisfy the end-to-
end QoS requirements in an efficient, predictable and scalable way through the
application of some design techniques and optimization patterns. This approach
guarantee that calls across components preserve priority levels and that the overhead
in servicing a call request is statically predictable [23].
Figure 13: TAO implementation of the Real-Time CORBA specification (from [20])
The real-time component-based approach exposed in [23] suggests a more autonomic
solution. Every component has a real-time service specification assigned to it and a
resource overlay isolates application components from resource management so that
the communication can be transparent and reusability ensured. The application control
module decides if components are allowed to execute certain tasks over the
corresponding resources of the system. A policing module, which also belongs to the
10 See [20] for a complete list of causes that increase the throughput and latency overhead.
system as a whole, contains all the policies needed to protect the resources against
“illegal” invocation sources. Furthermore, each component has a utilization allocation
and scheduling module assigned to preserve the utilization of the resources allocated
to it, which schedules the execution of its methods.
Figure 14: Real-time component-based system architecture (from [23])
5 Enhancements Based on Other Autonomic
Solutions
Two of the already existing autonomic system solutions are briefly discussed in this
section, the Unity autonomic system, the DySCAS self-managing middleware and the
ArchWare evolution-oriented framework. Furthermore, how AUTOSAR could benefit
from these designs to satisfy the self-* properties of the overall system is explained.
It is important to underline that the document does not treat any of these frameworks
as the definitive solution to the lack of autonomy that AUTOSAR endures. The goal
of this section is to describe some self-management mechanisms that these
applications implement for their own purposes, which could be useful in the
achievement of an autonomic solution for AUTOSAR, and illustrate some automotive
focused scenarios where they could be applicable.
5.1 Unity
Unity is a research project which development started in 2003 by IBM. It is intended
to cope with certain actual computing problems that are arising due to an
exponentially increment of the software complexity in distributed scenarios. Unity
implements some specific design patterns in its aim of satisfying the ultimate goal of
autonomic computing –build self- and context-aware systems. Being more an
evolution rather than a revolution [13], it makes use of some actual algorithms,
mechanisms and technologies to implement a self-managed multi-agent based
architecture.
Policy-based computing and service agreements assist in the task of conceding the
self-management ability in both system and component architectural levels. A policy
is a representation, in a standard external form, of desired behaviours or constraints of
behaviour [13]. Unity uses utility functions so that components can specify their
relative desirability of reaching a concrete state through a numerical value, e.g. the
utility value of maintaining the response time of the component “A” when serving the
component “B” below 2msecs is 1000, which are translated into action policies that
are typically of the form (based on the previous example) IF (RT > 2msec) THEN
(Increase CPU share by 5%).
Some agreements between components are established to constrain their behaviour
and dynamically compound larger entities for cooperation. An agreement represents
the expectations that a component has on another in terms of e.g. availability,
performance or QoS. Unity supports a protocol to negotiate these agreements, and the
consequences of not satisfying them could be to demand again the other component to
provide the agreed-upon service or to terminate the relationship with it and try to find
another component that after negotiating a new agreement will provide the required
service.
Unity principles establish that the autonomic system is composed by a collection of
self-managing components that implement the desired functions and some additional
self-managing infrastructure components that enable the required behaviours at the
system level.
Figure 15: The different infrastructure components included in Unity (from [15])
Self-management at system level is achieved through the implementation of some
design patterns in these infrastructure components. The design patterns instituted in
Unity are self-optimization, self-configuration, self-healing, self-protection and self-
description.
5.1.1 Self-Optimization
Some infrastructure components11 are briefly introduced in this section to understand
how self-optimization is achieved. The system is divided in different application
environments, each providing a distinct application service. Every environment is
governed by an application manager, which responsibilities are obtaining the
resources that the environment needs to meet its goals (defined by some utility
functions), and communicating with other elements on matters relevant to the
management of the environment. Hence, an application manager objective is to
maximise the performance of its environment with regard to the governing Service
Level Agreements (SLAs), which describe the rewards or penalties associated with
various possible behaviours of the system. Utility functions share a common scale of
numeric valuation defined by human administrators, and being located in policy
repositories, which are independently assigned to the corresponding autonomic
elements.
Unity tries to optimise the resource allocation between in the different application
environments existing on the system. The performance of each application depends on
the demand placed on it and the amount of resources allocated to it [15]. Application
managers have to predict how the performance of their application environment could
change over the time. Furthermore, as the real demand varies on each application
environment, its application manager has to adjust the configuration of the resources
or divert their control to the appropriate element in order to meet the optimum service
level in terms of e.g. response time or throughput of the application environment.
The different environment managers cooperate through a resource arbiter to optimise
the overall system performance. The resource arbiter obtains from each environment
manager a numeric estimation of how well every environment would behave for each
0 to N possible number of units of a concrete resource that could be allocated to it,
and then decides and assigns the ideal number of units to each environment. This
resource arbiter is completely unaware of the internal operations of the environment
managers, as well as the services they provide. Consequently the selected architecture
is highly scalable allowing dynamic reconfiguration. Chess et al. provide in [14] a
detailed example of how the resource allocation is performed by the prototype system.
11 Infrastructure components are out of the scope of this document. Further details are provided in [14] and [15].
Each ECU included in AUTOSAR contains some amount of resources that rarely will
share with any other component located in a different ECU (i.e. typically the
resources are just used by the components that belong to the same ECU). However,
with the introduction of new functionalities some of the software and hardware
resources could be intensively shared with other application and basic software
components placed in other ECUs e.g. different elements such as an accident
avoidance system or some alternative routes calculation system could be interested in
the lectures of the vehicle location sensor. Therefore, the principles behind the utility
functions implemented in Unity could be useful to achieve a successful dynamic
resource allocation optimization. Furthermore, it is also important to highlight that in
the automotive sector some urgency factors to make the correct allocation decision
have to be studied to resolve any resource sharing conflict. In the example shown
above the accident avoidance system would usually have a higher urgency than the
alternative routes calculation system.
5.1.2 Self-Configuration
Another infrastructure component, the registry, is a key role for achieving self-
configuration in Unity, not only because it enables autonomic elements to locate and
discover services in other elements at run-time but also because it actively participates
in the goal-driven self-assembly process. This process consists of an automatic (no
human intervened) system bootstrapping procedure12. The only information that an
autonomic element has when it is initiated is a high-level instructions of what to do
and the contact information for the registry. Hence, it has to contact the registry to
locate other elements it requires services from for its own operation, and then
establish relationships with them to obtain these services. Finally the element registers
itself in the registry so that it can serve other elements in the future. On the other
hand, elements have also to get deeper information of the role they play in the system,
which is contained in the form of policies in the policy repository.
However, like in every traditional distributed system management Unity also has to
deal with circular dependencies when initiating the autonomic elements. This issue is
addressed through retry loops: if the elements (registry included) another element
needs in its initialization does not exist in the system yet there will be a delay before
12 The bootstrapping procedure is fully described in [14] and [15].
the next attempt. Moreover, it could happen that the policy repository has not been
initiated yet and another element needs to be initiated. Therefore each element needs
to contain some default policies. At last but not least, the registry supposes an
undesirable single point of failure in Unity.
This technique could be applicable to give practical solutions to some case bases of
the automotive domain. For instance, consider the case in which more than one person
drives a concrete car. It should be possible to let each user of the car to define the
comfort-oriented functionalities he wants to enjoy while driving. Thus, the
architecture of the car should not only be ready to dynamically accept all the devices
that each driver wants to add, but also free him from manually configuring them each
time he is driving. Policies to define these configurations are also needed in this case.
5.1.3 Self-Healing
The present version of Unity supports clusters of policy repositories to achieve this
property. However, this pattern should also be implemented for more elements such
as the registry to resolve the single point of failure problem related to it.
Policy repositories13 that share the same role in the system compose a cluster of
synchronised policy repositories. Each policy repository has a concrete number of
autonomic elements subscribed to it, so that whenever any policy changes they get
notified and updated. The policies and the subscriptions to the policy repositories are
replicated in other repositories in order to ensure that the system keeps on notifying
all the subscribers of any faulty repository. To maximise the success of the
implementation two repositories in the same cluster should not be hosted in the same
machine, and elements in a cluster should not be instantiated on machines that have
previously hosted failed elements in that same cluster [14]. Policy repositories, seen
as resources in Unity, are managed by the resource arbiter and monitored by another
infrastructure element so-called sentinel. When a policy repository fails it informs the
resource arbiter about this event so that the latter can replace it with a new one.
The sentinel also has the problem of representing a single point of failure, which can
be resolved with a cluster of sentinels. However a smarter solution is needed to
resolve network partition issues; the chosen implementation is not robust enough.
13 Self-healing cluster operation is fully described in [14] and [15].
Policy and service replication is paramount in vehicle systems to guarantee the
achievement of the safety requirement when the car is being driven. This mechanism
could help to ensure that certain behaviours, such as slow down the speed of the car in
the case that the system detects that an accident has happened close by, are kept.
5.1.4 Self-Protection
Unity is considered enough self-protected because it is able to maintain the system
QoS when the service demand changes (self-optimization) and avoiding the system
degradation whenever any element fails (self-healing), ensuring that the system
always behaves as expected. However, some standardised security controls such as an
authorised access control have to be defined in order to achieve external intrusion
defence. Therefore, some common security policies should be deployed into the
policy repositories to assist in the self-protection tasks.
Every device or external component that wants to get access to any core component of
the car should be authenticated and authorised first. Confidentiality is a core principle
in the society, as all its members expect every system to ensure it. Its preservation is
what it makes an infrastructure to be considered trustworthy. Hence, some discussions
about how car location information is used should be performed. Thus, some
mechanisms that ensure the fulfilment of these security properties should also be
developed, such as e.g. using digital certificates issued by external certification
authorities.
5.1.5 Self-Description
The standardization and automatic generation of autonomic element interfaces are
also goals of Unity, so that developers just need to describe their elements and their
relationships through a meta-data language, as in AUTOSAR. However, web
standards are not mature enough at the moment to affront these purposes, and
consequently a big manual effort has still to be performed to implement these
interfaces.
5.2 DySCAS
The main objective of the first phase of the Dynamically Self-Configuring
Automotive Systems (DySCAS) European Commission funded research project,
which started in 2006 and it is supposed to end in 2008, is to identify the use cases
relative to the emerging requirements to be satisfied by the vehicle infrastructure, and
then propose some architectural guidelines as well as a set of software technologies
and mechanisms to develop these use cases. A secondary goal is the development of
some tools and modelling techniques to support the main goal. AUTOSAR
methodology involves some analogous tools for e.g. the creation of executable ECUs.
While these tools are out of the scope of the present document, this section discusses
the autonomic properties that DySCAS aims to achieve from a more superficial point
of view compared to Unity due to the big gap in terms of development maturity
existing between them.
The selected DySCAS architecture approach can be described as a specialised real-
time middleware that enables run-time configuration of its component services [5].
Hence, system component self behaviour and context-awareness are handled through
the inclusion of certain middleware services and the use of a dynamically
reconfigurable policy-based computing method. AUTOSAR also plays an important
role in DySCAS, as the latter is built on the standards proposed by the former.
5.2.1 Policy-based computing
Policies specify high-level behaviours in a standard and platform independent way in
DySCAS. The policy logic is stored separately from the reasoning mechanism in
order to support dynamic reload at run-time. One of the most important requirements
in the automotive sector, safety, commands the continuous operation of the system
without stopping any of its components or services for policies reloading. This is
mandatory for guaranteeing real-time responses to any ECU internal or external event.
On the other hand, some components of the system will also have some embedded
rule templates that contain some static and fixed configuration data related to a
specific device or user. These templates are simply changed passing in some
configuration parameters at run-time. Finally, this context-dependent decision making
is performed by utility functions, which enable the various contextual factors to be
weighted and therefore choose one template. The demonstration application exposed
in [5] provides an example of how these two types of policy logic work.
Some other good reasons for choosing policy-based computing for self-management
are the facts that policy evaluation has low run-time resource requirements, that the
policy configuration is generally applicable to all the identified use-cases and that
there is no need to be an expert in autonomics to write policies. A graphically-based
policy development tool based on AGILE [5] allows any user to change policies or
even to create new templates at run-time. Furthermore, it allows the construction of
hierarchies of policies in order to define high level context-based policies and reduce
the complexity of specific policies.
5.2.2 Middleware services
The DySCAS team separates all the requirements identified so far in four groups
referred as Generic Use Cases (GUCs) based on the combination of the type of
behaviour exhibited and the type of functionality required of the middleware [5].
These generic use cases are mapped into some middleware services, which are
obtained following a methodology14 and describe all the self-* properties involved on
DySCAS. The different groups and the corresponding services are shown next:
• GUC1: A new device is attached to the vehicle. This device can be a physical
object such as a mobile phone or a wireless network hotspot. Self-configuration
services that include new device location and dynamic functionalities discovery are
needed. Also, some other services such as identification and authentication of the
device owner, negotiation of the service provision and acceptance or refusal of the
device (security service) ensure that the self-protection property is satisfied.
14 This methodology is out of the scope of this document. For further details see [2] and [6].
Figure 16: Middleware services executed when attaching a new device (from [5])
• GUC2: Integrating new software functionality. This process can involve
integrating new components or applications as well as upgrading the existing ones.
Seamless and reliable software downloading mechanisms to self-update to the
latest innovations are required. Furthermore, some self-protection services to check
that downloads will not cause any system integrity violations and to determine if
the system has sufficient resources to support a new device or service (resource
management service) are needed. Self-healing functionalities that keep track of
software versions (storage management service) and downgrades it in failure
situations (roll-back management service) are also essential.
• GUC3: Close reconfiguration. Self-healing techniques are developed so that any
internal and unexpected event can be detected, diagnosed and resolved, ensuring
the stability and reliability of the system. Graceful degradation in the presence of
component failures or power shortages is mandatory (dynamic prioritization
service). In any failure situation, it should automatically reallocate high priority
functions (migration of service) even if it probably would have to dynamically
select low priority services and ideally temporally shut them down.
• GUC4: Resource optimization. The system is context-aware and self-optimises its
operation reallocating resources wherever they are needed based on utility
functions. Some other policies allow load balancing mechanisms to ensure that all
the devices are used efficiently. Dynamic selection amongst redundant ECUs and
sensors is made for reliability and quality reasons.
5.3 ArchWare
Alterations in the environment produced by events such as e.g. DySCAS GUC1 and
GUC2 may require that the system evolutes as a whole. ArchWare [25] presents an
alternative to make the system self-updating through the establishment of some
dynamic component feedback and change mechanisms. The structure of each
component is separated in the producer and evolver sub-components. The former
takes care of the functionality of the entity and the latter changes the component
operation depending on how the feedback obtained from the environment and its own
internal execution affects its goals. The evolver of each component could manage
more than one component, but at the highest level of the compositional hierarchy
evolution is defined externally by humans. Thus, this separation of concerns reduces
the overall complexity of creating and maintaining an autonomic system.
Figure 17: Structure of a plain component (from [25])
An Architecture Description Language (ADL) was created as part of the ArchWare
project in order to model the structure and behaviours of the components as well as
the interactions that they have with the others. Furthermore, it also allows the
specification of their constraints (goals defined through policies), and determines the
mechanisms for feedback and change. Both feedback and change mechanisms make
use of the hyper-code technology, which e.g. permits evolvers locate the units of
functionality (typically behaviours) to be changed within their corresponding
producer.
Evolvers are defined as feedback sinks. They monitor their producers, so-called
feedback sources, and prepare the changes to be performed to guarantee the correct
operation of the components they belong to. The monitoring action of each evolver is
achieved by the definition of certain probes which are sent through a probe
connection to the respective producer in order to check that its behaviour matches the
expectations defined by the component constraints. These probes are represented by
if-do clauses, where if the condition is satisfied a concrete feedback is sent back to the
evolver through a feedback connection. These feedback connections act as the event
distribution network. Then, the evolver defines a change function for any necessary
corrections and sends it to the producer through the change connection. Ultimately,
the producer receives the change function and invokes it at the appropriate time.
ArchWare supports three different types of change mechanisms:
• Replacement of a statically defined component assigning a new one to its location.
• Static and dynamic generation of new components.
• Dynamic evolution of the system. When part of the system has to be replaced by a
more evolved version all the components that belong to that division are
decomposed and set to a partially suspended state. Then, the specification of each
component may be edited in a reification phase so that it meets the new constraints,
and the evolved specification is brought into the execution domain (reflection
phase). Finally the evolved set of components is recomposed to form a new
system. ArchWare ADL contains some operators15 to fulfil the execution of these
four phases.
As it can be noticed, apart from being self-updated ArchWare also satisfies self-
configuration when adding new components dynamically and self-optimization when
changing the behaviour of the producer sub-components to match the evolved system
constraints. On the other hand, the behaviour of the components and their interactions
are self-described thanks to the expressive power of the designed ADL. Taking the
15 Definitions and the ADL operators and ArchWare components can be found in [25].
accomplishment of these properties into account, it could also be considered self-
protected in the same way that Unity is. Evolvers can be seen as autonomic manager
elements and producers as managed elements, represented not only by resources such
as databases or any other type of servers, but also complete software applications.
ArchWare is another autonomic framework that needs to get high level constraints
from human administrators, but it offers a fantastic architecture base for the
construction of a novel self-managed and evolutionary version of AUTOSAR.
6 Conclusion and Future Work
AUTOSAR appeared in the automotive industry as a solution to make the integration
of the existing stiff and heterogeneous proprietary applications possible, suggesting
standard interfaces and exchanging data that could make the resulting vehicle systems
more flexible, scalable and reliable. However, all its power resides at the final system
design-time because once its infrastructure has been generated it remains static,
making it incapable of coping with some challenges emerging in the industry, such as
e.g. the inter-vehicle interaction or the driver-based system customization.
Furthermore, certain AUTOSAR goals such as multiple instantiation or function
reallocation are not feasible at run-time as they were expected in [3], which insinuates
that AUTOSAR was more ambitious in its origins rather than in its actual reality.
The concepts and mechanisms of autonomic computing, as well as the
implementation of certain architectural patterns designed for some already existing
autonomic systems (Unity and DySCAS) represent a fantastic way of resolving all the
issues that AUTOSAR cannot handle. Moreover, applying the ArchWare self-update
technique could aid the substitution of human administrators by automatic processes
of software upgrades and the addition of new components within the system in a
complete seamless way. Also, a real-time CORBA implementation is feasible in
embedded systems as exposed in [20], which could resolve all the timing issues that
the actual version of AUTOSAR suffers.
Hence, AUTOSAR could be enhanced, without forgetting the automotive industry
constraints (cost) and requirements (e.g. safety and comfort), to become an agent-
oriented intelligent real-time middleware which components are self-adaptive to
environmental changes.
DySCAS is still in development, and therefore there is no much detail about how it
really implements the generic use cases identified and already published. Other
scenarios studied in other automotive projects such as the Car 2 Car Communication
Consortium [40] or the Consumer Electronics for Automotive [41] initiatives16 should
be also considered during the next development phase of AUTOSAR. These bunch of
concepts, use cases, scenarios and design patterns illustrated in the present document
16 Despite the exclusion of any deeper explanation about these initiatives from this document due to length
reasons, some of the ideas they deal with have been considered.
could result beneficial in the accomplishment of a more scalable, flexible and
adaptive infrastructure.
7 References
[1] VaST Systems Technology. 2004. Automotive Electronics: Model-Based
Development with Virtual Prototypes.
http://www.vastsystems.com/notes/automotive_electronics040727.pdf
[2] Anthony, R., Rettberg, A., Redell, O., Qureshi, T., Torngren, M., Ekelin, C. and
de Boer, G. 2007. Dynamically Reconfigurable Automotive Control Systems.
Advanced Automotive Electronics conference, Gaydon, UK (Jan. 2007).
[3] AUTOSAR Development Partnership. 2006. Technical Overview V2.0.1.
http://autosar.org.
[4] Racu, R., Hamann, A., Ernst, R. and Richter, K. 2007. Automotive Software
Integration. ACM, Design Automation Conference (Jun. 2007).
[5] Anthony, R. J. and Ekelin, C. 2007. Policy-driven self-management for an
automotive middleware. First International Workshop on Policy-Based
Autonomic Computing (PBAC 2007) at the Fourth IEEE International
Conference on Autonomic Computing, Jacksonville, Florida, USA (Jun. 2007).
[6] Kephart, J. O. and Chess, D .M. 2003. The Vision of Autonomic Computing.
IEEE Computer 36(1), pages 41-50 (Jan. 2003).
[7] AUTOSAR Development Partnership. 2006. Current results and preparations for
exploitation. 7th Euroforum conference ‘Software in the vehicle’, Stuttgart,
Germany (May 2006).
[8] AUTOSAR Development Partnership. 2006. Layered Software Architecture
V2.0.0. http://autosar.org.
[9] Dobson, S., Denazis, S., Fernández, A., Gaïti, D., Gelenbe, E., Massacci, F.,
Nixon, P., Saffre, F., Schmidt, N. and Zambonelli, F. 2006. A survey of
autonomic communications. ACM Transactions on Autonomous and Adaptive
Systems Vol. 1, No. 2, pages 223–259 (Dec. 2006).
[10] Baker, S. and Dobson, S. 2005. Comparing Service-Oriented and Distributed
Object Architectures. In Proceedings of the International Symposium on
Distributed Objects and Applications, pages 631–645. Robert Meersman and
Zahir Tari et al (ed). Volume 3760 of LNCS. Springer Verlag.
[11] Anthony, R., Leonhardi, A., Ekelin, C., Chen, D., Torngren M., de Boer, G.,
Jahnich, I., Burton, S., Redell, O., Weber, A. and Vollmer, V. 2006. A Future
Dynamically Reconfigurable Automotive Software System.
[12] Neely, S., Dobson, S. and Nixon, P. Adaptive Middleware for Autonomic
Systems. 2006. Annals of Telecommunications 61(9–10), pages 1099-1118
(Sep.–Oct. 2006).
[13] White, S. R., Hanson, J. E., Whalley, I., Chess, D. M., Segal, A. and Kephart, J.
O. 2006. Autonomic Computing: Architectural Approach and Prototype. Vol.
13, Issue 2 (Apr. 2006).
[14] Tesauro, G., Chess, D. M., Walsh, W. E., Das, R., Segal, A., Whalley, I.,
Kephart, J.O. and White, S. R. 2004. A Multi-Agent Systems Approach to
Autonomic Computing. ACM, AAMAS’04, pages 464-471, New York, USA
(Jul. 2004).
[15] Chess, D. M., White, S. R., Whalley, I. and Segal, A. Designing and
Implementing a Prototype Autonomic Computing System. Unpublished.
[16] Scarlett, K. 2006. Toward autonomous automotives.
http://www.ibm.com/developerworks/autonomic/library/ac-autos.html
[17] Heinecke, H et al. 2006. Achievements and exploitation of the AUTOSAR
development partnership. http://autosar.org.
[18] Kephart, J. O.2005. Research Challenges of Autonomic Computing. International
Conference on Software Engineering at the Proceedings of the 27th international
conference on Software engineering, St. Louis, Missouri, USA, pages 15-22
(May 2005).
[19] Salehie, M. and Tahvildari, L. 2005. Autonomic Computing: Emerging Trends
and Open Problems. International Conference on Software Engineering at the
Proceedings of the 2005 workshop on Design and evolution of autonomic
application software, St. Louis, Missouri, USA, pages 1-7 (May 2005).
[20] Schmidt, D.C. 1999. Middleware Techniques and Optimizations for Real-time,
Embedded Systems. 12th International Symposium on System Synthesis
Proceedings. San Jose, CA, USA, pages 12-16 (Nov. 1999).
[21] TAO web page. http://www.cs.wustl.edu/~schmidt/TAO.html.
[22] TAO Wikipedia Description. http://en.wikipedia.org/wiki/TAO_(software).
[23] Wang, S., Rho, S., Mai, Z., Bettati, R. and Zhao, W. 2005. Real-Time
Component-based Systems. IEEE Real-Time and Embedded Technology and
Applications Symposium 2005. San Francisco, California, USA (Mar. 2005).
[24] Brörkens, M. and Köster, M. 2007. Improving the Interoperability of Automotive
Tools by Raising the Abstraction from Legacy XML Formats to Standardised
Metamodels. Third European Conference on Model Driven Architecture
Foundations and Applications. Haifa, Israel, pages 59-67 (Jun. 2007).
[25] Balasubramaniam, D., Morrison, R., Kirby, G. NC., Mickan K., Warboys, B. C.,
Robertson, I., Snowdon, B., Greenwood, R. M. and Seet, W. 2005. A Software
Architecture Approach for Structuring Autonomic Systems. ICSE 2005
Workshop on the Design and Evolution of Autonomic Application Software. St.
Louis, Missouri, USA, pages 59-65 (May 2005).
[26] AUTOSAR web page. http://autosar.org
[27] AUTOSAR Development Partnership. 2006. Main Requirements V2.0.1.
http://autosar.org.
[28] Bunsel, S. 2006. AUTOSAR Validation Experiences. International Automotive
Electronics congress, Paris, France (Oct. 2006).
[29] AUTOSAR Development Partnership. 2007. Communication Stack Standard
Specifications. http://autosar.org.
[30] AUTOSAR Development Partnership. 2007. Memory Stack Standard
Specifications. http://autosar.org.
[31] AUTOSAR Development Partnership. 2006. AUTOSAR Glossary V2.0.1.
http://autosar.org.
[32] AUTOSAR Development Partnership. 2006. Software Component Template
V2.0.1. http://autosar.org.
[33] Lin, P., MacArthur, A. and Leaney, J. 2005. Defining Autonomic Computing: A
Software Engineering Perspective. Australian Software Engineering Conference,
ASWEC 2005, pages 88-97 (Mar.-Apr. 2005).
[34] Sterritt, R. 2005. Autonomic Computing. ISSE Vol. 1, No. 1, pages 79-88 (Mar.
2005).
[35] Ganek, A. G. and Corbi, T. A. 2003. The dawning of the autonomic computing
era. IBM Systems Journal Vol. 42, Issue 1, pages 5-18 (Jan. 2003).
[36] Nami, M. R. and Sharifi, M. 2007. A Survey of Autonomic Computing Systems.
Intelligent Information Processing III, Springer Boston, pages 101-110 (Nov.
2007).
[37] Parashar, M. and Hariri, S. 2004. Autonomic Computing: An Overview.
Unconventional Programming Paradigms, UPP 2004. Mont Saint Michele,
France, Vol. 3566, pages 247-259 (Sep. 2005).
[38] Fowler, M. 2004. Inversion of Control Containers and the Dependency Injection
pattern. http://www.martinfowler.com/articles/injection.html
[39] Wikipedia. Reflection (computer science).
http://en.wikipedia.org/wiki/Reflection_(computer_science)
[40] Car 2 Car Communication Consortium. 2007. http://www.car-to-car.org
[41] Consumer Electronics for Automotive (CE4A). 2007. http://www.ce4a.de
APPENDIX – Interpretations from AUTOSAR Expert
Knowledge
This section resumes all the conclusions obtained from two interviews that were made
off the record to two people involved in the AUTOSAR project between August and
September 2007. Comparing these interpretations with the actual documentation
written by the AUTOSAR development partnership, it can be concluded that even if
this new automotive framework definitely aimed high and it even generated a kind of
hype, it can neither deny its origin (traditional, conservative automotive industry,
lagging partly behind) nor can it ignore the severe constraints (costs) and
requirements (safety).
1. Component Development
AUTOSAR is a structural function-oriented system which architectural component-
based design reminds to the object-oriented paradigm, but which components are
typically programmed in C. Even the component pre-processing is implicitly built
with C tools. The development of components using other languages such as Java or
C++ would require the use of wrappers so that their implementations can be
successfully integrated within the run-time infrastructure. However, this is too
expensive in terms of money, as automotive industry is extremely cost sensitive.
Hence, neither the application software components nor the basic software
components are object-oriented, even if it would be possible in C to follow an object-
oriented programming style or to adhere to an object oriented design.
2. Built-in Functionalities
Most of the built-in functionalities, such as functional redundancy, function
reallocation, fault-tolerance, network load balancing, software upgrade or multiple
instantiation expected in [3] are not feasible at run-time. There are certain parts of a
vehicle, such as the brakes sub-system, that offer many different inputs to the system
just in case one of them stops working for passenger safety and security reasons.
However, given the sense of cost in automotive industry where fractions of euros
count and determine decisions, these important functionalities needed by an
autonomous approach are considered too luxurious to be ever included by default.
Hence, the DIY term explicitly appears to be the only way to implement them at the
moment. The AUTOSAR development partnership also contemplates multimedia and
telematic devices integration, which will be addressed in the next phase of the project.
The reusability of software modules is just applied to the AUTOSAR software
components layer, where there might be some application software components that
are used by many other application software components.
For example, the company interested on implementing redundancy in AUTOSAR
should write a C source code MySWC.c with a void function MyRunnableName
inside. Then, the source code is compiled for that component, the proper function
calls are generated (based on the relationships that the component has with others,
defined in the component meta-data) and eventually linked. The final steps are the
creation of both a different MyRedundantSWC and some code to monitor MySWC.
All the code is statically provided and flashed into the memory of the ECU at system
creation time. Thus if anything goes wrong MyRedunadantSWC will substitute
MySWC in the operation of its responsibilities.
3. Component Integration and Responsibilities
AUTOSAR is a static system, and therefore every component provided by any OEM,
supplier or tool provider has to implement some standard interfaces to be able to
collaborate with others and provide a concrete functionality to the overall system.
Components (and at last, the modules they are built in, ECUs) just serve services
demanded by others which might belong to the same or different ECUs. This is what
is understood by reusability in AUTOSAR. Every application software component of
any ECUs has unique duties and responsibilities in the system except from some
redundant modules developed for vehicle safety and security reasons. This way the
overall goal of the system is satisfied.
All the component relationships are hard-coded. This means that once they are
implemented and integrated into AUTOSAR they will only communicate to certain
components. The relationships that a component has with other components are
described in the software component description. Hence, dynamic integration of new
components is not possible at run-time.
4. Component Communication
The network is implemented using communication protocols (e.g. CAN or FlexRay).
Therefore, the network simply constitutes a channel which is also validated within the
system offline. However, there is also some low level management mechanisms
included in the communication protocols.
The RTE generator automatically creates both a component language-dependant API
and some connector code needed by the component to obtain the required service
from other components. Within these connectors the RTE generator also
automatically implements some stub code, which is the actual responsible of
executing the corresponding call after deciding whether the service call is local (intra-
ECU) or remote (inter-ECU). Hence, every instance of RTE is automatically
generated for a specific topology/description, after its creation it remains immutable.
Smarter middleware approaches (such as CORBA, which simplifies and enhances the
communication skills of the system e.g. introducing service location and discovery
mechanisms) combined with real-time techniques are not feasible as it is thought that
they could increase the cost of development.
When the executable ECU is generated following the steps defined by the AUTOSAR
methodology, which are based on the ECU description and the hardware
configuration, a concrete RTE is implemented and certain basic software components
are assigned to the ECU. This means that all the application components that belong
to a concrete ECU have all the basic services that they need to perform their operation
and access all the hardware devices located in the ECU. Furthermore, thanks to the
communication services defined in each ECU every application software component
can demand any service provided by any component located in the same or in a
different ECU. However, no application software component is allowed to access
external devices located in other ECUs in the practice, even if the documentation
ensures the opposite. Therefore some basic software components may be located in
more than one ECU.
Components communicate their needs to other based on a message ID priority
method. Every component can issue and broadcast messages requesting services to
certain components without caring about other components located along the network.
Whenever two components want to get access to the same resource the corresponding
resource manager will select the component that is sending its resource request
message with the highest priority level (message ID 1 is the highest, then message ID
2, and so forth). However, there are some decision conflicts in certain kind of
scenarios. For example, taking into account that there are two different networks in a
vehicle, one based in the CAN protocol and another in the MOST protocol, two
components that belong to ECUs integrated each in a different network might be
interested on being served with high priority by a third software component located in
any of the two ECUs or even in a third ECU. The component has to decide which
component should first get attended, but as the communication protocols are different
it can be hard to make this decision. In this case the selection criteria are more
complicated than it seems. On the other hand, if two components that belong to ECUs
integrated in a CAN network require the same resource with high priority the first-
arrived-first-served rule is applied.
