autosar exp layeredsoftwarearchitecture

8/17/2019 AUTOSAR EXP LayeredSoftwareArchitecture

1/143

- AUTOSAR Confidential -

Layered Software Architecture


2/143


Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture2

Document Title Layered Software Architecture

Document Owner AUTOSAR

Document Responsibility AUTOSAR

Document Identif ication No 053

Document Classification Auxiliary

Document Version 3.2.0

Document Status Final

Part of Release 4.0

Revision 3


3/143



Document Change History

Date Version Changed by Change Description

06.10.2011 3.2.0 AUTOSAR Administration

added a note for the R3-compatibility FlexRay Transport Layer FrArTp on slide "ki890".

added an overview chapter for energy management and partial networking

corrected examples regarding DEM symbol generation

fixed minor typography issues

clarification of term AUTOSAR-ECU on slide "94jt1"

corrected CDD access description for EcuM on slide "11123“


added a note regarding support for System Basis Chips on slide "94juq“

clarification of DBG and DLT text on slide "3edfg"

corrected DBG description on slide "11231"

30.11.2009 3.0.0 AUTOSAR

Administration

The document has been newly structured. There are now 3 main parts:

Architecture Configuration

Integration and Runtime aspects

The whole content has been updated to reflect the content of the R 4.0 specifications.

Topics which have bee newly introduced or heavily extended in release 4.0 have beenadded. E.g.,. Multi Core systems, Partitioning, Mode Management, Error Handling,Reporting and Diagnostic, Debugging, Measurement and Calibration, Functional Safety etc

Legal disclaimer revised23.06.2008 2.2.1 AUTOSAR

Administration

Legal disclaimer revised


4/143



Document Change History

Date Version Changed by Change Description


Updates based on new wakeup/startup concepts

Detailed explanation for post-build time configuration

"Slimming" of LIN stack description

ICC2 figure

Document meta information extended

Small layout adaptations made


ICC clustering added.

Document contents harmonized

Legal disclaimer revised

Release Notes added

“Advice for users” revised

“Revision Information” added


Rework Of:

Error Handling

Scheduling Mechanisms

More updates according to architectural decisions in R2.0

31.05.2005 1.0.1 AUTOSAR

Administration

Correct version released


Initial release


5/143



Disclaimer

Disclaimer

This specification and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the

companies that have contributed to it shall not be liable for any use of the specification.

The material contained in this specification is protected by copyright and other types of Intellectual Property Rights. The commercial

exploitation of the material contained in this specification requires a license to such Intellectual Property Rights.This specification may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only.

For any other purpose, no part of the specification may be utilized or reproduced, in any form or by any means, without permission in

writing from the publisher.

The AUTOSAR specifications have been developed for automotive applications only. They have neither been developed, nor tested for

non-automotive applications.

The word AUTOSAR and the AUTOSAR logo are registered trademarks.

Advice for users

AUTOSAR specifications may contain exemplary items (exemplary reference models, "use cases", and/or references to exemplary

technical solutions, devices, processes or software).

Any such exemplary items are contained in the specifications for illustration purposes only, and they themselves are not part of the

AUTOSAR Standard. Neither their presence in such specifications, nor any later documentation of AUTOSAR conformance of productsactually implementing such exemplary items, imply that intellectual property rights covering such exemplary items are licensed under

the same rules as applicable to the AUTOSAR Standard.


6/143


Table of contents

1. Architecture1. Overview of Software Layers

2. Content of Software Layers

3. Content of Software Layers in Multi Core systems

4. Overview of Modules5. Interfaces

1. General

2. Interaction of Layers (Examples)

2. Configuration

3. Integration and Runtime aspects


p a g e i d : 9 4 j t 4


7/143



Introduction

Purpose and Inputs

Purpose of this documentThe Layered Software Architecture describes the software architecture of AUTOSAR:

it describes in an top-down approach the hierarchical structure of AUTOSAR software and

maps the Basic Software Modules to software layers and

shows their relationship.

This document does not contain requirements and is informative only. The examples given are

not meant to be complete in all respects.

This document focuses on static views of a conceptual layered software architecture:

it does not specify a structural software architecture (design) with detailed static and dynamic

interface descriptions,

these information are included in the specifications of the basic software modules

themselves.

Inputs

This document is based on specification and requirement documents of AUTOSAR.

p a g e i d : 9 4 j t 2


8/143



Introduction

Scope and Extensibility

Application scope of AUTOSAR AUTOSAR is dedicated for Automotive ECUs. Such ECUs have the following properties:

strong interaction with hardware (sensors and actuators),

connection to vehicle networks like CAN, LIN, FlexRay or Ethernet,

microcontrollers (typically 16 or 32 bit) with limited resources of computing power and memory (compared

with enterprise solutions),

Real Time System and

program execution from internal or external flash memory.

NOTE: In the AUTOSAR sense an ECU means one microcontroller plus peripherals and the according

software/configuration. The mechanical design is not in the scope of AUTOSAR. This means that if morethan one microcontroller in arranged in a housing, then each microcontroller requires its own description of

an AUTOSAR-ECU instance.

AUTOSAR extensibility

The AUTOSAR Software Architecture is a generic approach:

standard modules can be extended in functionality, while still being compliant,

still, their configuration has to be considered in the automatic Basic SW configuration process!

non-standard modules can be integrated into AUTOSAR-based systems as Complex Drivers and

further layers cannot be added.

p a g e i d : 9 4 j t 1

9


9/143



Architecture – Overview of Software Layers

Top view

Microcontroller

Application Layer

Runtime Environment (RTE)

p a g e i d : 9 4 q u 9

Basic Software (BSW)

The AUTOSAR Architecture distinguishes on the highest abstraction level between threesoftware layers: Application, Runtime Environment and Basic Software which run on a

Microcontroller.

3


10/143




Coarse view

Complex

Drivers

Microcontroller

Microcontroller Abstraction Layer

Services Layer

Application Layer

Runtime Environment

ECU Abstraction Layer

p a g e i d : 9 4 j u 3

The AUTOSAR Basic Software is further divided in the layers: Services, ECU Abstraction,Microcontroller Abstraction and Complex Drivers.

4


11/143




Detailed view

Complex

Drivers

Microcontroller

Runtime Environment

Microcontroller Drivers Memory Drivers I/O Drivers

I/O Hardware Abstraction

Memory Hardware

Abstraction

Memory ServicesSystem Services

Onboard Device

Abstraction

Communication Drivers

Communication

Hardware Abstraction

Communication Services

Application Layer

p a g e i d : 9 4 j u 4

The Basic Software Layers are further div ided into functional groups. Examples of Servicesare System, Memory and Communication Services.

u 6


12/143





The Microcontroller Abstraction Layer is thelowest software layer of the Basic Software.

It contains internal drivers, which are software

modules with direct access to the µC and

internal peripherals.

Task

Make higher software layers independent of µC

PropertiesImplementation: µC dependent

Upper Interface: standardized and µC

independent

Co

mplex

Dri

ver

s

Microcontroller


Appl ication Layer

RTE


p a g e i d : 9 4 j u

u 7


13/143





The ECU Abstraction Layer interfaces thedrivers of the Microcontroller Abstraction

Layer. It also contains drivers for external

devices.

It offers an API for access to peripherals and

devices regardless of their location (µCinternal/external) and their connection to the

µC (port pins, type of interface)

Task

Make higher software layers independent of

ECU hardware layout

Properties

Implementation: µC independent, ECU hardware

dependent

Upper Interface: µC and ECU hardware

independent

Co

mpl

exDri

ver

s

Microcontroller


Appl ication Layer

RTE

ECU Abstraction Layer ECU Abstraction Layer

p a g e i d : 9 4 j u

w e


14/143




Complex Drivers

The Complex Drivers Layer spans from thehardware to the RTE.

Task

Provide the possibility to integrate special purpose

functionality, e.g. drivers for devices:

which are not specified within AUTOSAR,

with very high timing constrains or

for migration purposes etc.

Properties

Implementation: might be application, µC and ECU

hardware dependent

Upper Interface: might be application, µC and ECUhardware dependent

Microcontroller


Appl ication Layer

RTE


Services Layer


p a g e i d : 9 4 j w

C

om pl ex

Dr i v er s

A hit t O i f S ft L

j u 8


15/143




Services Layer

The Services Layer is the highest layer of the BasicSoftware which also applies for its relevance forthe application software: while access to I/Osignals is covered by the ECU Abstraction Layer,the Services Layer offers:

Operating system functionality

Vehicle network communication and managementservices

Memory services (NVRAM management)

Diagnostic Services (including UDS communication, errormemory and fault treatment)

ECU state management, mode management

Logical and temporal program flow monitoring (Wdgmanager)

Task

Provide basic services for applications and basic

software modules.Properties

Implementation: mostly µC and ECU hardwareindependent

Upper Interface: µC and ECU hardware independent

C

om pl ex

Dr i v er s

Microcontroller


Appl ication Layer

RTE


Services Layer


p a g e i d : 9 4 j

A hit t O i f S ft L

4 j u 9


16/143




AUTOSAR Runtime Environment (RTE)

The RTE is a layer providing communication services

to the application software (AUTOSAR Software

Components and/or AUTOSAR Sensor/Actuator

components).

Above the RTE the software architecture style

changes from “layered“ to “component style“.

The AUTOSAR Software Components communicate

with other components (inter and/or intra ECU)

and/or services via the RTE.

Task

Make AUTOSAR Software Components independent

from the mapping to a specific ECU.

Properties

Implementation: ECU and application specific

(generated individually for each ECU)

Upper Interface: completely ECU independent

Microcontroller


Appl ication Layer



Services Layer


p a g e i d : 9 4j

C

om pl ex

Dr i v er s

Architecture Overview of Software Layers4 j 3 3


17/143




Introduction to types of services

The Basic Software can be subdivided into the following types of services:

Input/Output (I/O)

Standardized access to sensors, actuators and ECU onboard peripherals

Memory

Standardized access to internal/external memory (non volatile memory)

Communication

Standardized access to: vehicle network systems, ECU onboard communication systems andECU internal SW

System

Provision of standardizeable (operating system, timers, error memory) and ECU specific

(ECU state management, watchdog manager) services and library functions

p a g e i d : 9 4

Architecture Introduction to Basic Software Module Types 4 j u i


18/143



Architecture – Introduction to Basic Software Module Types

Driver (internal)

A driver contains the functionality to control and access an internal or an external device.

Internal devices are located inside the microcontroller. Examples for internal devices are:

Internal EEPROM

Internal CAN controller

Internal ADC

A driver for an internal device is called internal driver and is located in the Microcontroller

Abstraction Layer.

p a g e i d : 9

Architecture Introduction to Basic Software Module Types

4 j u q


19/143




Driver (external)

External devices are located on the ECU hardware outside the microcontroller. Examples forexternal devices are:

External EEPROM

External watchdog

External flash

A driver for an external device is called external driver and is located in the ECU Abstraction

Layer. It accesses the external device via drivers of the Microcontroller Abstraction Layer.

This way also components integrated in System Basis Chips (SBCs) like transceivers and

watchdogs are supported by AUTOSAR.

Example: a driver for an external EEPROM with SPI interface accesses the external

EEPROM via the handler/driver for the SPI bus.

Exception:

The drivers for memory mapped external devices (e.g. external flash memory) may access the

microcontroller directly. Those external drivers are located in the Microcontroller Abstraction

Layer because they are microcontroller dependent.

p a g e i d : 9


4 j w x


20/143




Interface

An Interface (interface module) contains the functionality to abstract from modules which arearchitecturally placed below them. E.g., an interface module which abstracts from the

hardware realization of a specific device. It provides a generic API to access a specific type of

device independent on the number of existing devices of that type and independent on the

hardware realization of the different devices.

The interface does not change the content of the data.

In general, interfaces are located in the ECU Abstraction Layer.

Example: an interface for a CAN communication system provides a generic API to access CAN

communication networks independent on the number of CAN Controllers within an ECU and

independent of the hardware realization (on chip, off chip).

p a g e i d : 9 4

Architecture – Introduction to Basic Software Module Types9 4 j w w


21/143




Handler

A handler is a specific interface which controls the concurrent, multiple and asynchronousaccess of one or multiple clients to one or more drivers. I.e. it performs buffering, queuing,

arbitration, multiplexing.

The handler does not change the content of the data.

Handler functionality is often incorporated in the driver or interface (e.g. SPIHandlerDriver, ADC

Driver).

p a g e i d : 9


9 4 j 2 2


22/143




Manager

A manager offers specific services for multiple clients. It is needed in all cases where purehandler functionality is not enough to abstract from multiple clients.

Besides handler functionality, a manager can evaluate and change or adapt the content of the

data.

In general, managers are located in the Services Layer

Example: The NVRAM manager manages the concurrent access to internal and/or external

memory devices like flash and EEPROM memory. It also performs distributed and reliabledata storage, data checking, provision of default values etc.

p a g e i d :

Architecture – Overview of Software Layers 9 9 j 2 2


23/143



y

Introduction to Libraries

Libraries are a collection of functions forrelated purposes

Libraries:

can be called by BSW modules (that

including the RTE), SW-Cs, libraries

or integration code

run in the context of the caller in the

same protection environment

can only call libraries

are re-entrant

do not have internal states

do not require any initialization

are synchronous, i.e. they do not have

wait points

p a g e i d :

A U T O S A R

L i b r a r i e s

Basic Software

Runtime Environment (RTE)

Application Layer

ECU Hardware

The fol lowing l ibraries are

specified within AUTOSAR:

Fixed point mathematical,

Floating point mathematical,

Interpolation for fixed point data,

Interpolation for floating point data,

Bit handling,

E2E communication,

CRC calculation,

Extended functions (e.g. 64bits

calculation, filtering, etc.) and

Crypto

: 9 5 j t 4


24/143



Table of contents

1. Architecture1. Overview of Software Layers



4. Overview of Modules

5. Interfaces

1. General


2. Configuration


p a g e i d :

Architecture – Content of Software Layers Application Layer : o i u 4 2


25/143



y


The µC Abstraction Layer consists of the following module groups:

Communication DriversDrivers for ECU onboard (e.g. SPI) and vehicle communication (e.g. CAN).OSI-Layer: Part of Data Link Layer

I/O DriversDrivers for analog and digital I/O (e.g. ADC, PWM, DIO)

Memory DriversDrivers for on-chip memory devices (e.g. internal Flash, internal EEPROM) and memory mapped external memory devices

(e.g. external Flash)

Microcontroller DriversDrivers for internal peripherals (e.g. Watchdog, General Purpose Timer)Functions with direct µC access (e.g. Core test)

Microcontroller

A D C

C C U

I/O Drivers

A D C Dr i v er

DI ODr i v er

P WMDr i v er

I C UDr i v er

P WM

L I N or

S C I

C A N

S P I

E E P R OM

F L A S H

WDT

GP T

Microcontroller Drivers Communication DriversMemory Drivers

RA MT e s t

i n t er n al E E P R OMD

r i v er

i n t er n al F l a s h Dr i v er

W a t c h d o gDr i v e

r

M C UDr i v er

C or eT e s t

GP T Dr i v er

Software

module

internal

peripheral

device

Group of

Software

modules of

similar type

M C U

P ow er &

C l o c k Un

i t

C o m p l e x D r i v e r s

Microcont roller (µC)

Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory

ServicesSystem Services

Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

pp y

p a g e i d :

C A NDr i v er

L I NDr i v er

F l ex R a y Dr i v er

S P I H an d l er Dr i v

er

E t h er n e t Dr i v er

F l a s h T e s t

P ORT Dr i v er

DI O

Architecture – Content of Software Layers Application Layer

: s w r 4 2


26/143



Microcontroller Abstraction Layer: SPIHandlerDriver

The SPIHandlerDriver allows concurrent

access of several clients to one or more SPI

busses.

To abstract all features of a SPI microcontroller

pins dedicated to Chip Select, those shalldirectly be handled by the SPIHandlerDriver.

That means those pins shall not be available

in DIO Driver.Example:



Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

Memory Hardware Abstraction


µC SPI


SPIHandlerDriver

Driver for ext.

I/O ASIC

Driver for ext.

ADC ASIC

Onboard Device Abstraction

External

Watchdog Driver

External

EEPROM

Driver

p a g e i d

Architecture – Content of Software Layers Application Layer d : 2 1 1 1 2


27/143



Complex Drivers

A Complex Driver is a module which implements non-

standardized functionality within the basic softwarestack.

An example is to implement complex sensorevaluation and actuator control with direct accessto the µC using specific interrupts and/or complexµC peripherals (like PCP, TPU), e.g.

Injection control

Electric valve control

Incremental position detection

Task:Fulfill the special functional and timing requirements

for handling complex sensors and actuators

Properties:

Implementation: highly µC, ECU and applicationdependent

Upper Interface to SW-Cs: specified and implementedaccording to AUTOSAR (AUTOSAR interface)

Lower interface: restricted access to StandardizedInterfaces

Complex Drivers

E

l e c t r i c V al v e C on t r ol

I n j e c t i on C on t r ol

I n c r em en t al P o s i t i onD e t e c t i on

C om pl ex D ev i c eDr i v er X

Y

µC

e. g. C C

U

e. g.P C

P

e. g.T P U

Example:



Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

p a g e i d

Architecture – Content of Software Layers Application Layer d : d d e a q


28/143



ECU Abstraction : I/O Hardware Abstraction

The I/O Hardware Abstraction is a group of modules

which abstracts from the location of peripheral I/Odevices (on-chip or on-board) and the ECUhardware layout (e.g. µC pin connections andsignal level inversions). The I/O Hardware

Abstraction does not abstract from thesensors/actuators!

The different I/O devices might be accessed via an I/Osignal interface.

Task:

Represent I/O signals as they are connected to theECU hardware (e.g. current, voltage, frequency).

Hide ECU hardware and layout properties from highersoftware layers.

Properties:

Implementation: µC independent, ECU hardwaredependent

Upper Interface: µC and ECU hardware independent,dependent on signal type specified andimplemented according to AUTOSAR (AUTOSARinterface)

Example:



Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

COM Drivers


I/O Signal Interface

Driver for ext.

I/O ASIC

µC

I/O Drivers

DI O

Dr i v er

S P I H an d l er

D

r i v er

S P I

DI O

Driver for ext.

ADC ASIC

A D C Dr i v er

A D C

p a g e i d

Architecture – Content of Software Layers

ECU Ab t ti C i ti H d Ab t ti

Application Layer i d : z z t t z


29/143



ECU Abstraction : Communication Hardware Abstraction

The Communication Hardware Abstraction is a

group of modules which abstracts from the

location of communication controllers and the ECU

hardware layout. For all communication systems a

specific Communication Hardware Abstraction is

required (e.g. for LIN, CAN, FlexRay).

Example: An ECU has a microcontroller with 2 internalCAN channels and an additional on-board ASIC

with 4 CAN controllers. The CAN-ASIC is

connected to the microcontroller via SPI.

The communication drivers are accessed via bus

specific interfaces (e.g. CAN Interface).

Task:

Provide equal mechanisms to access a bus channel

regardless of it‘s location (on-chip / on-board)

Properties:

Implementation: µC independent, ECU hardware

dependent and external device dependent

Upper Interface: bus dependent, µC and ECU

hardware independent

Example:

C o m p l e

x D r i v e r s


Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

Communication Hardware Abstraction

Driver for ext.

CAN ASIC

µC

C A N

S P I


C A NDr i v er

S P I H a

n d l er

Dr i v er

I/O Drivers

DI OD

r i v er

DI O

CANTrans-

ceiver

Driver

p a g e

CAN Interface


S M H d Ab t ti

Application Layer d : w w w a a


30/143



Scope: Memory Hardware Abstraction

The Memory Hardware Abstraction is a group of

modules which abstracts from the location ofperipheral memory devices (on-chip or on-board)and the ECU hardware layout.

Example: on-chip EEPROM and external EEPROMdevices are accessible via the samemechanism.

The memory drivers are accessed via memory specificabstraction/emulation modules (e.g. EEPROM

Abstraction).

By emulating an EEPROM abstraction on top of Flashhardware units a common access via Memory

Abstraction Interface to both types of hardware is

enabled.

Task:

Provide equal mechanisms to access internal (on-chip)and external (on-board)memory devices and type of memory hardware

(EEPROM, Flash).

Properties:

Implementation: µC independent, external devicedependent

Upper Interface: µC, ECU hardware and memory

device independent

Example:

C o m p l e

x D r i v e r s


Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

COM Drivers

Memory Hardware Abstraction

µC

Memory Drivers

E E P R OM

Dr i v er

S

P I H an d l er

Dr i v er

S P I

E E P R OM

F l a s h

I n t er n al

F l a s h Dr i v er

Memory Abstraction Interface

External

EEPROM Driver

p a g e i d

EEPROM Abstraction

External

Flash Driver

Flash EEPROM

Emulation


Onboard Device Abstraction Application Layer

i d : x x d x x


31/143




The Onboard Device Abstraction contains

drivers for ECU onboard devices which

cannot be seen as sensors or actuators like

internal or external watchdogs. Those

drivers access the ECU onboard devices via

the µC Abstraction Layer.

Task:

Abstract from ECU specific onboard devices.

Properties :

Implementation: µC independent, external

device dependent

Upper Interface: µC independent, partly ECUhardware dependent

Example:

C o m p l e

x D r i v e r s


Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

COM Drivers


µC

Microcontroller

Drivers S P I H an d l er

Dr i v e

r

S P I

i n t er n al

w a t c h

d o g

d r i v

er

W d g

External

Watchdog Driver

Watchdog Interface

p a g e


Communication Services General Application Layer

i d : y y x y y


32/143



Communication Services – General

The Communication Services are a group of

modules for vehicle network communication (CAN,LIN and FlexRay). They interface with thecommunication drivers via the communicationhardware abstraction.

Task:

Provide a uniform interface to the vehicle network forcommunication.

Provide uniform services for network management

Provide uniform interface to the vehicle network fordiagnostic communication

Hide protocol and message properties from theapplication.

Properties:

Implementation: µC and ECU HW independent, partlydependent on bus type

Upper Interface: µC, ECU hardware and bus typeindependent

The communication services will be detailed for eachrelevant vehicle network system on the following

pages.

Example:

C o m p l e

x D r i v e r s


Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction


Transport Protocol

DCM

Diagnostic

Com.

Manager

AUTOSAR

COM

NMIPDUMultiplexer

Generic NM

Interface

State

Manager

p a g e

PDU Router

Debugging

Bus specific modules


Communication Stack CAN RTE

Application Layer

e i d : p p o p p


33/143



Communication Stack – CAN

The CAN Communication Services are a group of modulesfor vehicle network communication with the communication

system CAN.

Task:

Provide a uniform interface to the CAN network. Hide

protocol and message properties from the application.

Please Note:

There are two transport protocol modules in the CAN stack

which can be used alternatively or in parallel: CanTp and

J1939Tp. They are used as follows:

CanTp: ISO Diagnostics (DCM), large PDU transport

on standard CAN bus

- J1939Tp: J1939 Diagnostics, large PDU transport on

J1939 driven CAN bus

Example:

C o m p l e

x D r i v e r s


Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

I/O Drivers




CAN Driver

Driver for ext.

CAN ASIC

SPIHandler

Driver

Di a gn o s t i c

C om.

M an a g er

AUTOSAR

COM

CAN NM

µC SPI CAN

External

CAN Controller

CAN Transceiver

Driver

DIO Driver

Generic NM

Interface

CAN

State

Manager

p a g e

PDU Router

CAN Interface

D e b u g gi n g

I P D U

M ul t i pl ex er J1939 Transport

Protocol

CAN Transport

Protocol


Communication Stack – CAN RTE

Application Layer

e i d : b b n n h


34/143



Communication Stack – CAN

Properties:

Implementation: µC and ECU HW independent, partlydependent on CAN.

AUTOSAR COM, Generic NM (Network Management)Interface and Diagnostic Communication Manager are thesame for all vehicle network systems and exist as oneinstance per ECU.

Generic NM Interface contains only a dispatcher. Nofurther functionality is included. In case of gateway ECUs itcan also include the NM coordinator functionality whichallows to synchronize multiple different networks (of the

same or different types) to synchronously wake them up orshut them down.

CAN Generic NM is specific for CAN networks and will beinstantiated per CAN vehicle network system. CANGeneric NM interfaces with CAN via underlying network

adapter (CAN NM).

The communication system specific Can State Managerhandles the communication system dependent Start-upand Shutdown features. Furthermore it controls thedifferent options of COM to send PDUs and to monitor

signal timeouts.

C o m p l e

x D r i v e r s


Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

p a g e


Communication Stack Extension – TTCAN RTE

Application Layer

e i d : q w w w e


35/143



Communication Stack Extension TTCAN

The TTCAN Communication Services are the optionalextensions of the plain CAN Interface and CAN Driver module

for vehicle

network communication with the communication system

TTCAN.

Task:

Provide a uniform interface to the TTCAN network. Hide

protocol and message properties from the application.

Please Note:

The CAN Interface with TTCAN can serve both aplain CAN Driver and a CAN Driver TTCAN.

Example:

C o m p l e

x D r i v e r s


Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

I/O Drivers




CAN Driver

Driver for ext.

CAN ASIC

SPIHandler

Driver

CAN Transport

Protocol

CAN NM

µC SPI TTCAN

External

TTCAN Controller

CAN Transceiver

Driver

DIO Driver

Generic NM

Interface

CAN

State

Manager

p a g e

CAN Interface

Di a gn o s t i c

C om.

M an a g er

AUTOSAR

COM

PDU Router

D e b u g gi n g

I P D U

m ul t i pl ex er

TTCAN

TTCAN


Communication Stack Extension – TTCAN RTE

Application Layer

e i d : g g g h h


36/143



Communication Stack Extension TTCAN

Properties:

TTCAN is an absolute superset to CAN, i.e. a CAN stack

which supports TTCAN can serve both a CAN and a

TTCAN bus.

CanIf and CanDrv are the only modules which need

extensions to serve TTCAN communication.

The properties of the communication stack CAN are also

true for CAN with TTCAN functionality.

C o m p l e

x D r i v e r s


Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

p a g


Communication Stack – LIN (LIN Master) RTE

Application Layer

g e i d : 8 7 z 6 6


37/143



( )

The LIN Communication Services are a group of modules for vehiclenetwork communication with the communication system LIN.

Task:

Provide a uniform interface to the LIN network. Hide protocol andmessage properties from the application.

Properties:

The LIN Communication Services contain:

A LIN 2.1 compliant communication stack with

Schedule table manager for transmitting LIN frames and tohandle requests to switch to other schedule tables.

Transport protocol, used for diagnostics

A WakeUp and Sleep Interface

An underlying LIN Driver:

implementing the LIN protocol and adaptation the specifichardware

Supporting both simple UART and complex frame based LINhardware

Example:

C o m p l e

x D r i v e r s


Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction



µC SCI

LIN Driver


PDU Router

AUTOSAR

COM

LIN State

Manager

p a g

Di a gn o s t i c

C om.

M an a g er

Driver for ext.

LIN ASIC

LIN Transceiver

Driver

LIN Interface

LIN NM

Generic

NM

Interface


Communication Stack – LIN RTE

Application Layer

g e i d : 6 6 7 6 6


38/143



Note: Integration of LIN into AUTOSAR:

Lin Interface controls the WakeUp/Sleep API

and allows the slaves to keep the bus awake

(decentralized approach).

The communication system specific LIN State

Manager handles the communicationdependent Start-up and Shutdown features.

Furthermore it controls the communication

mode requests from the Communication

Manager. The LIN state manager also

controls the I-PDU groups by interfacingCOM.

When sending a LIN frame, the LIN Interface

requests the data for the frame (I-PDU) from

the PDU Router at the point in time when it

requires the data (i.e. right before sending

the LIN frame).

C o m p l e

x D r i v e r s


Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

RTE

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

p a g


Communication Services – LIN Slave RTE

Application Layer

g e i d : 1 1 2 2 d


39/143



LIN Slaves usually are „intelligent“ actuators and

slaves that are seen as black boxes. As theyprovide very little hardware capabilities and

resources, it is not intended to shift AUTOSAR SW-

Components onto such systems. Therefore it is not

necessary to have an AUTOSAR system on LIN

Slaves.

LIN Slave ECUs can be integrated into the AUTOSAR

VFB using their Node Capability Descriptions. They

are seen as non-AUTOSAR ECUs. Please refer to

the VFB specification.

That means: LIN Slaves can be connected as

complete ECUs. But they are not forced to use the

AUTOSAR SW Architecture. Perhaps they can use

some standard AUTOSAR modules (like EEPROM,

DIO).

Reason: LIN slaves usually have very limited memoryresources or are ASICs with „hard-coded“ logic.

Note: LIN slaves cannot fulfill the requirements to a

Debugging Host, since LIN is not a multi-master

bus.

Example:

C o m p l e

x D r i v e r s


Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

LIN Slave Application


LIN Communication

Stack

µC SCI

p a g


Communication Stack – FlexRay RTE

Application Layer

a g e i d : k i 8 9 0


40/143



The FlexRay Communication Services are a group

of modules for vehicle network communication withthe communication system FlexRay.

Task:

Provide a uniform interface to the FlexRay network.

Hide protocol and message properties from theapplication.

Please Note:

There are two transport protocol modules in the

FlexRay stack which can be used alternatively

FrTp: FlexRay ISO Transport Layer

FrArTp: FlexRay AUTOSAR Transport Layer,

provides bus compatibility to AUTOSAR R3.x

Example:

C o m p l e

x D r i v e r s


Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

I/O Drivers




FlexRay

NM

FlexRay Transport

Protocol

Host µC Internal FlexRay Controller

Data linesExternal

FlexRay Controller (e.g. MFR 4200)

External

FlexRay Transceiver (e.g. TJA 1080)

Driver for internal

FlexRay Controller

Driver for external

FlexRay Controller

Driver for FlexRay

Transceiver

SPIHandlerDriver DIO Driver

Generic

NM

Interface

FlexRay

State

Manager

p a

FlexRay Interface

Control/status lines

Di a gn o s t i c

C om.

M an a g er

AUTOSAR

COM

PDU Router

D e b u g gi n g

I P D U

m

ul t i pl ex er


Communication Stack – FlexRay RTE

Application Layer

a g e i d : 4 2 4 3 2


41/143



Properties:

Implementation: µC and ECU HW independent,

partly dependent on FlexRay.

AUTOSAR COM, Generic NM Interface and

Diagnostic Communication Manager are the same

for all vehicle network systems and exist as one

instance per ECU.

Generic NM Interface contains only a dispatcher.

No further functionality is included. In case of

gateway ECUs, it is replaced by the NM

Coordinator which in addition provides the

functionality to synchronize multiple differentnetworks (of the same or different types) to

synchronously wake them up or shut them down.

FlexRay NM is specific for FlexRay networks and is

instantiated per FlexRay vehicle network system.

The communication system specific FlexRay State

Manager handles the communication system

dependent Start-up and Shutdown features.

Furthermore it controls the different options of COM

to send PDUs and to monitor signal timeouts.



Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

p a


Communication Stack – TCP/IP RTE

Application Layer

a g e i d : 4 4 5 6 6


42/143


Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture51 Layered Software Architecture - Document ID 053 - V 2.3 - R 4.0 Rev 000110 November 201151

The TCP/IP Communication Services are a

group of modules for vehicle networkcommunication with the communication

system TCP/IP.

Task:

Provide a uniform interface to the TCP/IP

network. Hide protocol and message

properties from the application.



Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

p a

Example:

I/O Drivers




Ethernet Driver Handler / Driver

Socket Adaptor

UDP NM

µC MII Ethernet

External

Ethernet Controller

Ethernet Transceiver Driver

DIO Driver

Generic NM

Interface

Ethernet

State

Manager

Ethernet Interface

Di a gn o s t i c

C om.

M an a g er

AUTOSAR

COM

PDU Router

D e b u g gi n g

I P D U

m ul t i pl ex er DoIP


Communication Stack – TCP/IP – Socket Adaptor RTE

Application Layer

p a g e i d : q q e e t


43/143


Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture52 Layered Software Architecture - Document ID 053 - V 2.3 - R 4.0 Rev 000110 November 201152

Properties:

The SoAd Module fully contains the DoIP

protocol handler.

The SoAd provides two APIs towards the

TCP/IP stack.

The TCP/IP Stack may contain a multitudeof protocol handlers including, but not limited

to UDP, TCP, DHCP, ARP, ICMP, and

others.

The TCP/IP stack is not intended as an

AUTOSAR Module, but is defined by the

interfaces only.



Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

p


Communication Stack – General RTEC i

Application Layer

p a g e i d : b b n n q


44/143



General communication stack properties:

A signal gateway is part of AUTOSAR COM to route

signals.

PDU based Gateway is part of PDU router.

IPDU multiplexing provides the possibility to add

information to enable the multiplexing of I-PDUs (different

contents but same IDs on the bus).

Upper Interface: µC, ECU hardware and network type

independent.

For refinement of GW architecture please refer to

“Example Communication”



Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

p


Services: Memory Services RTEC i

Application Layer

p a g e i d : 9 d d f f


45/143



The Memory Services consist of one module,

the NVRAM Manager. It is responsible forthe management of non volatile data

(read/write from different memory drivers).

Task: Provide non volatile data to theapplication in a uniform way. Abstract from

memory locations and properties. Provide

mechanisms for non volatile data

management like saving, loading, checksum

protection and verification, reliable storageetc.

Properties :

Implementation: µC and ECU hardware

independent, highly configurable


independent specified and implemented

according to AUTOSAR

(AUTOSAR interface)

Example:



Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

Memory Services

NVRAM Manager


Services: System Services RTECommuni

Application Layer

p a g e i d : q w e h g


46/143



The System Services are a group of modules

and functions which can be used by modulesof all layers. Examples are Real Time

Operating System (which includes timer

services) and Error Manager.

Some of these services are µC dependent (likeOS), partly ECU hardware and application

dependent (like ECU State Manager) or

hardware and µC independent.

Task:Provide basic services for application and

basic software modules.

Properties:Implementation: partly µC, ECU hardware and

application specific


independent

Example:



Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi-

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

System Services

F un c t i onI nh i b i t i on

M an a g er ( F I M )

W a t c h d o gM an a g er

( W d gM )

D ev el o pm en t E r r or

T r a c er ( D e t )

Di a gn o s t i c E v en t

M an a g er ( D em )

C omm uni c a t i on

M an a g er ( C omM )

A UT O S A R O S

B a s i c S of t w ar eM o d e

M an a g er ( B s wM )

E C U S t a t eM an a g er

( E c uM )

p

S y n c h r oni z e d T i m e-

b a s eM an a g er

( S t b M )

Di a gn o s t i c L o g an d

T r a c e ( Dl t )


Error Handling, Report ing and Diagnostic p a g e i d : 3 e d f g

RTE

Communi-

Application Layer


47/143



There are dedicated modules for different aspectsof error handling in AUTOSAR. E.g.:

The Debugging module supports debugging of

the AUTOSAR BSW. It interfaces to ECU

internal modules and to an external host system

via communication .

The Diagnostic Event Manager is responsible

for processing and storing diagnostic events

(errors) and associated FreezeFrame data.

The module Diagnostic Log and Trace

supports logging and tracing of applications. Itcollects user defined log messages and converts

them into a standardized format.



Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

S y s t em

S er v i c e s

Microcontroller


Microcontroller Drivers

Onboard Device

Abst raction

Communication

Drivers

Communication

Hardware

Abst raction

Communication

Services

Application Layer

Function Inhibition

Manager

Watchdog Manager

Development Error

Tracer

Diagnostic Event

Manager

Watchdog Interface

Watchdog Driver

Diagnostic Communi-

cation Manager

DebuggingDiagnostic Log

and Trace

XCP

All detected development errors in the Basic Software are reported to Development Error Tracer .

The Diagnostic Communication Manager provides a common API for diagnostic services

etc.


Application Layer: Sensor/Actuator Software Components

RTE

MCommuni-

Application Layer

p a g e i d : x s j i 8


48/143



The Sensor/Actuator AUTOSAR Software

Component is a specific type of AUTOSARSoftware Component for sensor evaluationand actuator control. Though not belongingto the AUTOSAR Basic Software, it isdescribed here due to its strong relationship

to local signals. It has been decided to locatethe Sensor/Actuator SW Components abovethe RTE for integration reasons(standardized interface implementation andinterface description). Because of theirstrong interaction with raw local signals,

relocatability is restricted.

Task:

Provide an abstraction from the specificphysical properties of hardware sensors andactuators, which are connected to an ECU.

Properties :

Implementation: µC and ECU HW independent,

sensor and actuator dependent

Example:



Micro-

controller

Drivers

Memory

Drivers

Memory

HW Abstr.

Onboard

Dev. Abstr.

Memory


Communi-

cation

Drivers

Communi

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

Appl ication Layer

Actuator SoftwareComponent

Sensor SoftwareComponent

RTE

Basic Software

Interfaces to (e.g.)

• I/O HW Abstraction (access to I/O signals)

• Memory Services (access to calibration data)

• System Services (access to Error Manager)

Table of contents

p a g e i d : 9 6 j t 4


49/143



1. Architecture

1. Overview of Software Layers




5. Interfaces

1. General


2. Configuration



Example of a Layered Software Architecture for Multi-Core Microcontroller p a g e i d : w 1 1 1 b


50/143



ECU

core 1:core 0:

C om pl ex Dr i v er s

Micro-controller

Drivers

Memory

Drivers

Memory HW

Abstraction

Onboard Dev.

Abstraction

Memory

Services

System Services

Communi-

cation Drivers

Communi-

cation

Services

COM HW

Abstraction

I/O

Drivers

I/O HW

Abstraction C om pl ex Dr i v er s


Core Test

Application Layer

RTE

E x am pl e: anE C U

wi t

h a t w o c or emi c

r o c on t r ol l er

Operating

System

ECU State

Manager


Scope: Multi-Core System Services

r s

RTE

Memory

S iSystem Services

Communi-

cation

Application Layer

p a g e i d : w 1 1 1 c


51/143



Microcontroller core 0:

C o m

p l e x D r i v e r


Micro-controller

Drivers

Memory

Drivers

Memory

HW Abstr.

Onboard

Dev. Abstr.


Communi-cation

Drivers

cation

Services

COM HW

Abstr.

I/O

Drivers

I/O HW

Abstraction

System Services

F

un c t i onI nh i b i t i on

M an a g er

…

D

ev el o pm en t E r r or

T r a c er

Di a gn o s t i c E v en t

M an a g er

C omm uni c a t i on

M an a g er

E C

U S t a t eM an a g er

C or e 0

core 1:

System Services

A UT O S A R O S

E C U s t a t e

m an a g em en t C or e1

A UT O S A R O S

i O C

I n t er O s A p pl i c a t i on

c omm uni c a t i on

i O C

I n t er O s A p pl i c a t i on

c omm uni c a t i on

The IOC, as shown in the figure, provides communication

services which can be accessed by clients which needto communicate across OS-Application boundaries on

the same ECU. The IOC is part of the OS

Every Core runs a kind of ECU state management

B a

s i c S of t w ar eM o d e

M an a g er

E x am pl e: anE

C U

wi t h a t w o c or emi c r o c on t r ol l er

Table of contents p a g e i d : 9 7 j t 4


52/143



1. Architecture





5. Interfaces

1. General


2. Configuration


Architecture

Overview of Modules – Implementation Conformance Class 3 - ICC3 p a g e i d : 9 d f c 8

This figure shows the mapping of basic software modules to AUTOSAR layers


53/143



Not all modules are shown here

Complex

Drivers

Microcontroller


Microcontroller Drivers Memory Drivers I/O Drivers


Memory Hardware

Abstraction

Memory ServicesSystem Services

Onboard Device

Abstraction


Communication

Hardware Abstraction


Application Layer

P or t

A d c

Di o

P wm

I c u

R amT s t

C an

F l s

W d g

L i n

M C U

F r

G p t

S pi

MemIf

Driver forext.

I/O ASIC

Driver forext.

ADC ASIC

WdgIf

Tp

C om

Nm

I p d uM

Nm

If

ext. DrvTrcv.

NvMF i MW d gM

D e t

D em

C omM

A UT O S A R O S

PduR

This figure shows the mapping of basic software modules to AUTOSAR layers

I/O Signal Interface

Ea Fee

Dl t

S t b M

E c uM

E e p

E t h

B s wM

D c m

D e b u g

gi n g

X C P

xxx Interface

C s m

F l s T s t

C or eT s t

Architecture

Overview of Modules – Implementation Conformance Classes – ICC2 p a g e i d : 9 2 j c 9

The clustering shown in this document is the one defined by the project so far. AUTOSAR is currently not restricting the clustering


54/143



AUTOSAR Runtime Environment

Applicat ion Layer

CAN

Com

Services

… …O

S

*

ECU Hardware

CAN Driver

COM

CAN Interface

..CAN

TP

CAN

NM

…

CAN St Mgr …

PDU Router

… ICC3 module ICC2 clusters

The clustering shown in this document is the one defined by the project so far. AUTOSAR is currently not restricting the clusteringon ICC2 level to dedicated clusters as many different constraint and optimization criteria might lead to different ICC2clusterings. There might be different AUTOSAR ICC2 clusterings against which compliancy can be stated based on a to be

defined approach for ICC2 compliance.

Architecture

Overview of Modules – Implementation Conformance Classes – ICC1 p a g e i d : 9 4 t 2 1

In a basic software which is compliant to ICC1 no modules or clusters are required.


55/143



Proprietary software


Applicat ion Layer

ECU Hardware

In a basic software which is compliant to ICC1 no modules or clusters are required.

The inner structure of this proprietary basic software is not specified.

Architecture

Overview of Modules – Implementation Conformance Classes – behavior to the outside p a g e i d : 9 4 p 2 1

Basic software (including the RTE) which is AUTOSAR compliant (ICC1-3) has to behave to the outside as specified by ICC3.


56/143



Basic Software


Application Layer

ECU Hardware

( g ) p ( ) p y

For example the behavior towards:

buses,

boot loaders and

applications.

ICC 3 compliantbehavior

Table of contents p a g e i d : 9 8 j t 4


57/143



1. Architecture





5. Interfaces1. General


2. Configuration


Interfaces

Type of Interfaces in AUTOSAR p a g e i d : t z 7 6 a


58/143



AUTOSAR Interface

An "AUTOSAR Interface" defines the information exchanged between

software components and/or BSW modules. This description isindependent of a specific programming language, ECU or network

technology. AUTOSAR Interfaces are used in defining the ports of

software-components and/or BSW modules. Through these ports

software-components and/or BSW modules can communicate with each

other (send or receive information or invoke services). AUTOSAR makes

it possible to implement this communication between Software-Components and/or BSW modules either locally or via a network.

Standardized AUTOSAR

Interface

A "Standardized AUTOSAR Interface" is an "AUTOSAR Interface" whose

syntax and semantics are standardized in AUTOSAR. The "Standardized

AUTOSAR Interfaces" are typically used to define AUTOSAR Services,

which are standardized services provided by the AUTOSAR BasicSoftware to the application Software-Components.

Standardized Interface

A "Standardized Interface" is an API which is standardized within

AUTOSAR without using the "AUTOSAR Interface" technique. These

"Standardized Interfaces" are typically defined for a specific programminglanguage (like "C"). Because of this, "standardized interfaces" are

typically used between software-modules which are always on the same

ECU. When software modules communicate through a "standardized

interface", it is NOT possible any more to route the communication

between the software-modules through a network.

Interfaces

Components and interfaces view (simpli fied) p a g e i d : 9 4 j u 5


59/143



ECU-Hardware


Actuator

SoftwareComponent

AUTOSARInterface

Applicat ionSoftware

Component

Sensor

SoftwareComponent

Applicat ionSoftware

Component

..............

AUTOSARSoftware

Basic Software

StandardizedInterface

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

Microcontroller Abstraction

AUTOSARSoftware

Component

StandardSoftware

Standardized AUTOSAR

Interface

Services


ECU

Abstraction

AUTOSARInterface


ComplexDrivers

AUTOSARInterface

VFB & RTErelevant


Communication



OperatingSystem

RTErelevant

BSWrelevant

S t an d ar d i z

e d

I n t er f a c e

Possible interfacesinside

Basic Software(which are

not specifiedwith in AUTOSAR)

Note: This figure is incomplete with respect to the possible interactions between the layers.

Interfaces:

Interface

Interfaces: General Rules

General Interfacing Rules

Horizontal Interfaces Vertical Interfaces

p a g e i d : a 6 z t

r


60/143



Services Layer: horizontal interfaces are allowedExample: Error Manager saves fault data using the

NVRAM manager

ECU Abstraction Layer: horizontal interfaces are

allowed

A complex driver may use selected other BSWmodules

µC Abstraction Layer: horizontal interfaces are not

allowed. Exception: configurable notifications are

allowed due to performance reasons.

Microcontroller (µC)

Vertical Interfaces

One Layer may access all interfaces of the SW layerbelow

Bypassing of one software layer should be avoided

Bypassing of two or more software layers is notallowed

Bypassing of the µC Abstraction Layer is not allowed

A module may access a lower layer module of

another layer group (e.g. SPI for external hardware)

All layers may interact with system services.

AUTOSARSW Comp

1

AUTOSARSW Comp

3

AUTOSARSW Comp

4

AUTOSARSW Comp

5

o n

Interfaces: General Rules

Layer Interaction Matrix p a g e i d : 1 x d f r


61/143



S y s t e m

S e r v i c e s

M e m o r y S e r v

i c e s

C o m m u n i c a t i o n S e r v i c e s

C o m p l e x D r i v

e r s

I / O

H a r d w a r e

A b s t r a c t i o n

O n b o a r d D e v i c e A b s t r a c t i o n

M e m o r y H a r d

w a

autosar exp layeredsoftwarearchitecture

Documents