CHAPTER 2 :AUTOSAR layered Architecture

Topics Covered:

 AUTOSAR Basic software

 Virtual Function Bus
 AUTOSAR Methodology
 Software Component
 Run Time Environment
 Partial Networking, Multicore
 J1939 Overview, AUTOSAR Ethernet,
 AUTOSAR E2E Overview , AUTOSAR XCP
ECU SW Architecture

ECU Architecture - Layered Software

Architecture
A layered architecture has been developed within AUTOSAR to enable a clear and structured interface definition
and a well defined abstraction of the hardware. The architecture is structured in 5 layers plus the Complex Drivers.
AUTOSAR Software
This layer consists of AUTOSAR Software Components that are mapped on the ECUs. All interaction between
AUTOSAR Software Components is routed through the AUTOSAR Runtime Environment. The AUTOSAR Interface
specification assures the connectivity.

AUTOSAR SW-C
The AUTOSAR Software Components encapsulate an application which runs on the AUTOSAR
infrastructure. The AUTOSAR SW-C have well-defined interfaces, which are described and standardized.

– SW-C Description
For the interfaces as well as other aspects needed for the integration of the AUTOSAR Software
Components, AUTOSAR provides a standard description format (SW-C Description).
• Virtual Functional Bus (VFB)
The VFB is the sum of all communication mechanisms (and interfaces to the basic software) provided by
AUTOSAR on an abstract (technology independent) level. When the connections for a concrete system
are defined, the VFB allows a virtual integration in an early development phase.
In order to fulfill the goal of transferability, AUTOSAR Software Components are implemented independently from
the underlying hardware. The independence is achieved by providing the virtual functional bus as a means for a
virtual hardware and mapping independent system integration. This enables a virtual integration of AUTOSAR
Software Components so that parts of the integration process of automotive software can be done in much earlier
design phases compared to today's development processes.

The virtual functional bus is the abstraction of the AUTOSAR Software Components interconnections of the entire
vehicle. The communication between different software components and between software components and its
environment (e.g. hardware driver, OS, services, etc.) can be specified independently of any underlying hardware.
The functionality of the VFB is provided by well-defined communication patterns.

From the VFB view ports of AUTOSAR Software Components, Complex Device Drivers, the ECU Abstraction
and AUTOSAR Services can be connected. Complex Device Drivers, the ECU Abstraction and AUTOSAR
Services are part of the Basic Software.
Services and communication protocols are implemented as part of the Basic Software. An AUTOSAR Service offers
extended functionality to the users of the VFB just as a standard library adds extended functionality for the users
of a programming language. In order to reuse this extended functionality for all AUTOSAR Software Components, it
is essential that the interfaces to AUTOSAR Services are standardized. From the VFB view, ports of AUTOSAR
Software Components, Complex Drivers, the ECU Abstraction and AUTOSAR Services can be connected. Complex
Drivers, the ECU Abstraction and AUTOSAR Services are part of the Basic Software. Whereas the AUTOSAR Service
Interfaces are standardized, the Complex Drivers and the ECU Abstraction are ECU specific.

AUTOSAR Runtime Environment

• Runtime Environment (RTE)

From the viewpoint of the AUTOSAR Software Component, the RTE implements the VFB functionality on
a specific ECU.
AUTOSAR Runtime Environment

At system design level, (i.e. when drafting a logical view of the entire system irrespective of hardware) the
AUTOSAR Runtime Environment (RTE) acts as a communication center for inter- and intra-ECU
information exchange. The RTE provides a communication abstraction to AUTOSAR Software
Components attached to it by providing the same interface and services whether inter-ECU
communication channels are used (such as CAN, LIN, FlexRay, MOST, etc.) or communication stays
intra-ECU. As the communication requirements of the software components running on top of the RTE
are application dependent, the RTE needs to be tailored, partly by ECU-specific generation and partly by
configuration. Thus, the resulting RTE will differ between one ECU and another

2.3.3 RTE

2.3.3.1 Features of RTE

There are basically two separate parts in the AUTOSAR architecture, the one above the RTE and the one

below(Figure below). In the part below

the RTE, BSW modules are free to call any API function of other modules or to use, for example, certain
OS services directly. In the part above the RTE, ASW components communicate with each other via
ports. There is no other way of communication (e.g., via shared global variables) allowed. An ASW
component is also not allowed to use any BSW module directly. Furthermore, the dynamic behavior of an
ASW component is described and implemented by means of “runnable entities.” A runnable entity is a
Schedulable unit of an ASW component.
Basically, it is a sequence of instructions that can be started by the RTE, as a result of an event initiated
by the RTE. Such an RTE event is triggered, for example, when new data arrives at a port, when a timer
expires, or when a server call returns.
The task of the RTE is to glue these two parts together. The word “glue” is really important in this context.
It should be made clear that the RTE is not just an abstraction layer between ASW and BSW. In a non-
AUTOSAR application, the ASW typically employs OS services (like activating a task) directly or it directly
sends out or receives a CAN message. This is not possible in AUTOSAR. An ASW component simply
does not know the concept of an OS task or a CAN message. Also, there is no one-to-one mapping
between these concepts and AUTOSAR. Therefore, it would not be sufficient to just create a wrapper
around an existing proprietary application in order to make it AUTOSAR-conform. Instead, the entire
internal behaviour has to be adapted to the AUTOSAR paradigm.

Thus, the RTE employs the BSW in order to implement the behaviour of the ASW components specified
by means of ports and runnable entities. This includes two main tasks: implementing the communication
and implementing the activation of runnable entities.
For the communication task, the RTE provides a set of APIs for sending or receiving data elements and
for remote server calls in the case of client/server communication.
Runnable entities are mapped to OS tasks .Therefore, in order to activate a runnable entity (e.g., because
data that the runnable entity was for has arrived), the RTE would typically activate the corresponding OS
task that the runnable entity is mapped to. But it is also possible, in the case of a client/server operation,
to call a runnable entity in the form of a direct function call.
The RTE is furthermore responsible for ensuring the consistency of data during communication, that is, to
ensure that data are not changed while being received or sent.

2.3.3.2 Generation of RTE

The RTE is generated in order to ensure that it fits a given ECU and system configuration.
This means that an RTE implementation always provides only the functionality that is needed for a given
configuration, and nothing more. The generation process is divided into two phases

•Contract phase:
This phase is ECU-independent. It provides the contract between a given ASW component and the RTE,
that is, the API that the ASW component can be coded against. The input for this phase is the description
of an ASW component with all its ports and runnable entities.
The result is an ASW component-specific header file that can be included by the corresponding source
code file. In this header file, all RTE API functions that may be used by the ASW component are declared.
It also declares the necessary data types and structures needed by the ASW component. The set of
allowed API functions depends on the ports of the given ASW component. For example, if an ASW
component has a send-port p with a data element d, the contract phase will generate the API function
Rte_Send_p_d. The ASW component uses this function to send data element d via port p.

•Generation phase: In this phase the concrete code generation for a given ECU is performed. Input for
this phase is the ECU configuration description, which includes especially the mapping of runnable
entities to OS tasks or the communication matrix. Together with the ASW component header files created
during the contract phase and all necessary BSWcode, the generated code can then be compiled to an
executable file for the given ECU.

Note that it is also possible to deliver an ASW component only in the form of object code, for example, in
order to protect intellectual property. All necessary information is ECU-independent and already available
in the contract phase. With the ASW component-specific header file it is possible to compile the source
code of a given ASW component. The resulting object code together with the header file can then be
delivered as a bundle to the customer.
However, the object code leaves less potential for optimizations, for example, certain functions cannot be
implemented as C-macros, which would be possible if the source code of the ASW component is

available.

The AUTOSAR Runtime Environment (RTE) acts as a system level communication center for inter- and intra-ECU
information exchange.
The RTE is the runtime representation of the Virtual Function Bus for a specific ECU. The RTE provides a
communication abstraction to AUTOSAR Software Components providing the same interface and services for inter-
ECU (using CAN, LIN, Flexray, MOST, etc.) or intra-ECU communication.

As the communication requirements of the software components are application dependent, the RTE needs to be
tailored. It is therefore very likely, that the main parts of RTE will be generated and tailored to provide desired
communication services while still being resource-efficient. Thus, the RTE will likely differ between one ECU and
another.
– The RTE is typically tool-generated and statically configured

The AUTOSAR Runtime Environment has the responsibility to provide a uniform environment to AUTOSAR
Software Components to make the implementation of the software components independent from
communication mechanisms and channels.
The RTE achieves this by mapping the communication relationships between components, that are specified in the
different templates, to a specific intra-ECU communication mechanism, such as a function call, or an inter-ECU
communication mechanism, such as a COM message which leads to CAN communication.

Access to ports from a software component

implementation
The implementation of an AUTOSAR Software Component is not allowed to use the communication layer, for
example OSEKCOM, directly. To communicate with other software components it uses ports and client-server
communication or sender-receiver communication. The RTE generator is responsible for creating the appropriate
language-dependant APIs based on the definition of the interface of the component in the Software Component
Template. The API has to be the same independent from the mapping of the components, i.e. the component's
code must not be changed when the mapping is changed. The API names are derived from the XML files and
conform to a naming convention.
Implementation of connectors
The RTE generator is also responsible for generating code, which implements the connectors between the ports.
This generated code is dependent on the mapping of the software components to ECUs. If the connector connects
two components on the same ECU a local communication stub can be generated.
Otherwise, a stub that uses network communication must be generated.

The mapping from a connector to a communication stub must conserve the semantics of this connector
independent from the used communication medium.
The communication stub is also responsible for parameter marshalling. This includes serializing complex data to a
byte stream. But endian conversion (if any is necessary) is delegated to the communication module of the Basic
Software.

Lifecycle management
The RTE is responsible for the lifecycle management of AUTOSAR Software Components. It has to invoke startup
and shutdown functions of the software component.

Access to Basic Software

An AUTOSAR Software Component is not allowed to accessBasic Software directly.
Firstly, the access to services, to the ECU abstraction, or to Complex Device Drivers is abstracted via ports and
AUTOSARinterfaces.
With respect to the component implementation, the RTEprovides appropriately generated APIs for Basic Software
access.

Multiple Instantiations of software components

The RTE shall support multiple instantiations of software components. The basic intention of multiple instantiation
is to avoid code duplication if possible. Furthermore different private states of multiple instances shall be
supported.
– but in AUTOSAR R2.0 this feature is cancelled !

AUTOSAR Basic Software

Basic Software is the standardized software layer, which provides services to the AUTOSAR Software
Components and is necessary to run the functional part of the software. It does not fulfill any functional
job itself and is situated below the AUTOSAR Runtime Environment. The Basic Software contains
standardized and ECU specific components. The earlier include:

 Services System services such as diagnostic protocols; NVRAM, flash and memory management

 Communication Communication Framework (e.g. CAN, LIN, FlexRay...), I/O management, Network
management

 Operating System As AUTOSAR aims at an architecture that is common for all vehicle domains it will
specify the requirements for an AUTOSAR Operating System.

The following requirements shall be seen as examples of such: the OS

ois configured and scaled statically

ois amenable to reasoning of real-time performance

oprovides a priority-based scheduling

oprovides protective functions at run-time

oruns on low-end controllers and without external resources

AUTOSAR allows the inclusion of proprietary OSs in Basic Software components. To make the interfaces
of these components AUTOSAR compliant, the proprietary OS must be abstracted to an AUTOSAR OS.
The standard OSEK OS (ISO 17356-3) is used as the basis for the AUTOSAR OS.

 Microcontroller Abstraction : Access to the hardware is routed through the Microcontroller Abstraction
layer (MCAL) to avoid direct access to microcontroller registers from higher-level software. MCAL is a
hardware specific layer that ensures a standard interface to the components of the Basic Software. It
manages the microcontroller peripherals and provides the components of the Basic Software with
microcontroller independent values. MCAL implements notification mechanisms to support the distribution
of commands, responses and information to different processes. Among others it can include:

oDigital I/O (DIO)

oAnalog/Digital Converter (ADC)

oPulse Width (De)Modulator (PWM, PWD)

oEEPROM (EEP)

oFlash (FLS)

oCapture Compare Unit (CCU)

oWatchdog Timer (WDT)

oSerial Peripheral Interface (SPI)

oI2C Bus (IIC)

ECU specific components are:

 ECU Abstraction: The ECU Abstraction provides a software interface to the electrical values of any
specific ECU in order to decouple higher-level software from all underlying hardware dependencies.

 Complex Device Driver (CDD) The CDD allows a direct access to the hardware in particular for
resource critical application

Basic Software is the standardized software layer, which provides services to the SW Components. It does not fulfill
any functional job and is situated below the AUTOSAR Runtime Environment. It contains

Standardized components
– Services including diagnostic protocols; NVRAM, flash andmemory management.
– Communication the communication framework (e.g. CAN,LIN, FlexRay...), the I/O management, and the network
management.

ECU specific components.

– Operating system
– Microcontroller abstraction
– Complex Device Drivers

MCAL(Microcontroller abstraction)
Access to the microcontroller registers is routed through the Microcontroller Abstraction layer (MCAL).
MCAL is a hardware specific layer that ensures a standard interface to the Basic Software. It manages the
microcontroller peripherals and provides the components of the Basic Software with microcontroller independent
values. MCAL implements notification mechanisms to support the distribution of commands, responses and
information to processes. It can include
– Digital I/O (DIO),
– Analog/Digital Converter (ADC),
– Pulse Width (De)Modulator (PWM, PWD),
– EEPROM (EEP),
– Flash (FLS),
– Capture Compare Unit (CCU),
– Watchdog Timer (WDT),
– Serial Peripheral Interface (SPI), and
– I2C Bus (IIC).

The Microcontroller Abstraction Layer is the lowest layer of the Basic Software. It contains drivers, with direct
access to the Μc internal peripherals and memory mapped μC external devices.
Microcontroller Abstraction Layer
The Microcontroller abstraction layer is subdivided into 4 parts:
– I/O Drivers
Drivers for analog and digital I/O (e.g. ADC, PWM, DIO).
– Communication Drivers
Drivers for ECU onboard (e.g. SPI, I2C) and vehicle communication (e.g. CAN). OSI-Layer: Part of Data Link Layer.
– Memory Drivers
Drivers for on-chip memory devices (e.g. internal Flash, internal EEPROM) and memory mapped external memory
devices(e.g. external Flash).
– Microcontroller Drivers
Drivers for internal peripherals (e.g. Watchdog, Clock Unit) and functions with direct μC access (e.g. RAM test, Core
test).

ECU Abstraction layer

The ECU Abstraction Layer provides a software interface to the electrical values of any specific ECU in order to
decouple higher level software from all underlying hardware dependencies.
I/O Hardware Abstraction:
A group of modules which abstracts from the location of peripheral I/O devices (on-chip or on-board) and the ECU
hardware layout (e.g. μC pin connections and signal level inversions).
The I/O hardware abstraction does not abstract from the sensors/actuators! I/O devices are accessed via an I/O
signal interface.
The task of this group of modules is
– to represent I/O signals as they are connected to the ECU hardware (e.g. current, voltage, frequency), and
– to hide ECU hardware and layout properties from higher software layers.
An example:I/O Hardware Abstraction
The AUTOSAR Methodology /AUTOSAR SOFTWARE DEVELOPMENT PROCESS
Objectives of the Methodology
AUTOSAR is pursuing precise technical goals to manage future software architectures.
Some of these goals are
• Transferability of functions from one ECU to another ECU within the Network
• Integration of functional modules from multiple suppliers
• Reuse of proven solutions (hardware and software)
In order to reach these goals, AUTOSAR has introduced a standardized architecture defined by a
metamodel. This will be the basis for the interoperability of products developed using the AUTOSAR
standard and a methodology approach for developing according to and complying with the AUTOSAR
standard.
2.4.2 Description of the Methodology
The AUTOSAR methodology describes the dependencies of activities on work products in software
process engineering metamodel (SPEM) notation. It focuses on workflow rather than specifying a full
process or business interactions. It allows for consistency with a full integration into the AUTOSAR
metamodel. The AUTOSAR metamodel defines how something is described, the AUTOSAR methodology
defines when these descriptions are used in specific activities (Figure 2.6).

2.4.3 AUTOSAR Models, Templates, and Exchange Formats

AUTOSAR is based on models. Everything in an AUTOSAR system needs to be described in terms of

standardized model elements. The models are not fixed. Information is added both in consecutive stages
performed by different roles as well as iteratively by the same role.
The models are serialized to a standardized XML format for exchange and persistence using XML
standard.
The source code is generated directly based on the model (ASW component API, RTE middleware, BSW
configuration) (Figure 2.7). So, AUTOSAR models are not merely the documentation of the
electronic/electric systems but they also drive the software development.

2.4.4 System Configuration

First, the system configuration input has to be defined (Figure 2.8). This is made by selecting ASW
components and hardware, and by identifying the overall system constraints. This requires engineering
decisions at the system level, which means in practice, that the appropriate templates should be filled out.
The next step, the activity configure system, mainly maps the ASW components to the ECUs regarding
resources and timing requirements. This is one of the most important decisions made during the
configure system activity.

The output of the activity configure system is

• The system configuration description including all system information (mapping, topology, etc.)
• The allocation of each ASW component into an ECU
• The system communication matrix, which describes precisely the features of the networks/media used
The system configuration generator supports all these operations. Of course, these different steps are
iterative as the system design can evolve and be improved during the project development (new ASW
components, new networks, new ECUs, etc.).

2.4.5 ECU Configuration

The activity “extract ECU-specific information” simply extracts the information from the system
configuration description needed for a specific ECU into an ECU extract of system configuration file.
The next activity, “configure ECU”, adds all necessary information for implementation like tasks,
scheduling, main BSW modules list, assignments of the runnables to tasks, and configuration of the BSW
modules. This activity is a nontrivial design step as it should fix all configuration parameters based on the
vendor-specific and generic parameters, the BSW module description, and the collection of available
ASW components implemented on the ECU. The result is included in the ECU configuration description.
Due to the high complexity of this step, it has to be supported by different tool-related editors. To
automatically generate parts of the configuration code for the RTE, OS, and COM, certain generators
should be used.
The generate executable activity is mostly done as current executable generation with compile and link
phases from designed code.
The phase “work on ECU” is also iterative depending on new ASW components that will be integrated
into the ECU or new network constraints. There is a strong link between the system and ECU activities,
with numerous exchanges between the different actors. But the AUTOSAR methodology does not define
who is doing what and when in a software development (Figure 2.9).

2.4.6 Implementation to Existing Development Processes and Tooling

AUTOSAR defines a set of standard data types, interfaces, component types, and BSW parameters
specified with models. These models will be exchanged and reused between suppliers and customers
during the life cycle of the software development for implementation. An organization and a sharing of the
different roles and tasks will be identified and contracted between the original equipment manufacturers
(OEM) and their suppliers using interoperable tools to manipulate these models.
In order to benefit from AUTOSAR, the methodology needs to be applied to the development process.
The software architecture needs to be mapped to the AUTOSAR metamodel. Former “paperwork”
specifications are replaced by models,which directly drive software development via code generation. In
order to consistently work on the model, the methodology requires a dedicated AUTOSAR tooling.
The conclusion that can be drawn is that the application of AUTOSAR development requires mapping
and adaptation of the existing development processes to the AUTOSAR methodology.
Figure shows the design steps to build a system with the AUTOSAR technology. Please note that this is
an information flow, not an illustration of files. Terms of descriptions:

 System Configuration Description: includes all system information and the information that must be
agreed between different ECUs

 System Configuration Extractor: extracts the information from the System Configuration Description
needed for a specific ECU

 ECU extract: is the information from the System Configuration Description needed for a specific ECU

 ECU Configuration Description: all information that is local to a specific ECU the runnable software can
be built from this information and the code of the software component
Energy Management-Partial Networking
The goal of efficient energy management in AUTOSAR is to provide mechanisms for power saving, especially
while bus communication is active (e.g. charging or clamp 15 active).

AUTOSAR R3.2 and R4.0.3 support only Partial Networking.

Partial Networking

 Allows for turning off network communication across multiple ECUs in case their provided functions
are not required under certain conditions. Other ECUs can continue to communicate on the same
bus channel.

 Uses NM messages to communicate the request/release information of a partial network cluster

between the participating ECUs

Partial Network Cluster (PNC)

 PNC is a group of system signals necessary to support one or more vehicle functions that are
distributed across multiple ECUs in the vehicle network. This represents the system view of mapping
a group of buses to one or more VFCs.
Overview of J1939

Characteristics of J1939

• Higher-layer protocol based on Controller Area Network (CAN)

• Provides serial data communication between Electronic Control Units (ECUs) in any kind of heavy
duty vehicle.

• Extended CAN identifier (29 bit)

• Bit rate 250 kbit/s

• Peer-to-peer and broadcast communication

• Transport protocols for up to 1785 data bytes

• Network management

• Definition of parameter groups for commercial vehicles and others

• Manufacturer specific parameter groups are supported

• Diagnostics features

• Maximum 30 nodes (ECUs) in a network

J1939 Applications
J1939 Protocol is used in many applications, few of them are as follows:

• Agricultural and Forestry Off-Road Machinery Control and Communication Network .

• Marine Stern Drive and Inboard Spark-Ignition Engine On-Board Diagnostics

• Off-Board Diagnostic Connector

• Industrial Generator Sets

• Truck and Bus Applications

• A Parameter Group Number (PGN) is a part of the 29-bit identifier sent with
every message.

• The PGN is a combination of

- the Reserved bit (always 0),

- the data page bit (currently only 0, 1 is reserved for future use),

- the PDU (Protocol Data Unit) Format (PF),

- PDU Specific (PS).

• PDU Format < 0xF0 defines Peer-to-Peer message. PDU Specific will be a
Destination Address

• PDU Format => 0xF0 identifies message as broadcast. PDU Specific will be a
Group Extension
J1939 Support In AUTOSAR
AUTOSAR E2E Overview

Among the several enhancements in AUTOSAR Release 4.0 is the addition of an End-to-End (E2E)
Communication Protection Library. This library defines several E2E profiles, each of which implements
a combination of End-to-End protection mechanisms such as sequence counters, data IDs and CRCs.
Two of these profiles, Profiles 1 and 2, are intended to protect inter-ECU communication via databus
systems like FlexRay or CAN, and are designed to address various communication faults.

Although the AUTOSAR specification includes detailed descriptions of the profiles, it provides only
limited insight about the fault coverage that can be obtained when using these profiles to detect
communication faults.

AUTOSAR E2E Concept has 2 methods of implementation

 Com E2E Callout
 E2E Wrappers
AUTOSAR E2E Concept
E2E Wrappers
 Grouping of E2E protection for Wrapper Method

 Conversion Manager: ECU SWC ports are grouped to collect all inter ECU Data Elements.

 E2E Manager: E2E Manager protects or check’s Data Elements

7 © KPIT Technologies Limited © KPIT Cummins Infosystems Ltd.

Multicore Support
As the demand for computing power is rapidly increasing in the automotive domain, OEMs andTier-one suppliers are
gradually introducing multicore ECUs in their electronic architectures.
Additionally, these multicore ECUs offer new features such as higher levels of parallelism which easethe respect of
the safety requirements such as the ISO26262 and the implementation of other morecomplex automotive use-cases.
Main use cases for multicore ECUs can be;

1. Decreasing complexity of architecture

2. Dealing with resource demanding applications
3. Improving the safety
4. Dedicated use of cores

Keeping all this in mind, AUTOSAR version 4.0 has introduced support for multi-core embedded realtimeoperating
systems. New concepts such as locatable entities (LEs), multi-core startup/shutdown,Inter-OS-Application
Communicator (IOC), and Spinlock have been introduced in the AUTOSAR multicoreOS architecture specification to
extend the single-core OS specifications.
The Inter-OS-Application Communicator (IOC) which is part of AUTOSAR OS, providescommunication services
which can be accessed by clients which need to communicate across OSApplicationboundaries on the same ECU.
Every Core runs a kind of ECU state management. Each corewill also have 'Core Test' module running in BSW.

AUTOSAR Metamodel
_ is the backbone of the AUTOSAR architecture definition
_ contains complete specification, how to model AUTOSAR systems
Metamodel defines the contents of the workproducts
_ Formal description of all the information that is produced or consumed in the AUTOSAR
methodology

_ Benefit of using the metamodel:

_ No inconsistencies
_ Easy maintenance
_ Consistent terminology

__________________________________________________