AUTOSAR Layered Software

Architecture
 Agenda

 Introduction
 Overview of Software Architecture
 Microcontroller Abstraction Layer
 ECU Abstraction Layer
 Communication Hardware, Memory Hardware, I/O Hardware and
Onboard device Abstraction
 Services Layer
 Communication, Memory and System Services
 Complex Drivers
 RTE (Run Time Environment)
 Application Software Component and Interfaces
 BSW Scheduler
 Configuration Classes
 Implementation Conformance Classes

2
 Introduction

 Introduction to AUTOSAR SW Architecture

 Provides a conceptual layered software architecture
 Provides mapping of the identified BSW modules to software layers

 Automotive ECUs having the following properties can adapt to AUTOSAR

 Strong interaction with hardware (sensors and actuators)
 Connection to vehicle network via CAN, LIN or FlexRay
 Microcontrollers from 16 to 32 bit
 Real Time Operating System
 Program execution from internal or external flash memory

 Extensibility
 Modules can be added or the functionality of existing ones can be extended,
but their configuration has to be considered in the Basic SW configuration
process
 Complex drivers can easily be added

3
 Simplified Component View

Application Actuator Sensor Application

Software Software Software AUTOSAR Software
Component Component Component Software Component
AUTOSAR AUTOSAR AUTOSAR AUTOSAR
Interface Interface Interface .............. Interface

AUTOSAR Runtime Environment (RTE)

Complex
Standardized
Standardized Standardized AUTOSAR AUTOSAR
Drivers
AUTOSAR Services Layer
Interface Interface Interface Interface
Interface
Basic Software

ECU
Services Communication
Abstraction
Standardized Standardized Standardized
Standardized

InterfaceECU Abstraction Layer

Interface Interface Complex
Inteface

Operating
Device
System
Standardized Drivers
Interface
Basic Software
Microcontroller Abstraction Layer Microcontroller
Abstraction
ECU-Hardware

4
 Layered View: Detailed

Application Layer

AUTOSAR Runtime Environment (RTE)

System Services Memory Services Communication I/O Hardware Complex

Services Abstraction Drivers

Onboard Device Memory Hardware Communication

Abstraction Abstraction Hardware
Abstraction

Microcontroller Memory Drivers Communication I/O Drivers

Drivers Drivers

Microcontroller

5
Overall Basic Software Architecture

6
 Microcontroller Abstraction Layer

 The Microcontroller Abstraction Layer is the lowest software layer of the

Basic Software
 It contains drivers, which are software modules with direct access to the µC
internal peripherals and memory mapped µC external devices
 Communication Drivers
 I/O Drivers
 Memory Drivers
 Microcontroller Drivers Group of
Microcontroller Drivers Memory Drivers Communication Drivers I/O Drivers Similar type
Software
modules
internal Flash Driver

SPI Handler Driver

internal EEPROM
Watchdog Driver

FlexRay Driver

PORT Driver
PWM Driver
MCU Driver

CAN Driver
GPT Driver

ADC Driver

DIO Driver
ICU Driver
LIN Driver
Core Test

RAM Test

Driver

Software
module

Internal
peripheral
Power

Clock

EEPR
FLAS

PWM
WDT

CCU
MCU
GPT

CAN
Unit

ADC

DIO
LIN

SCI
OM

SPI

Microcontroller
or

device
H
&

7
 Communication Hardware Abstraction

 A group of modules which abstract from the location of communication controllers

and the ECU hardware layout.
 For all communication systems a specific Communication Hardware Abstraction is
required
 An ECU has a microcontroller with 2 internal CAN 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)
 Provides equal mechanisms to access a bus channel regardless of its location (on-chip / on-board)
Communication Hardware Abstraction
CAN Interface

CAN Transceiver Driver for ext.

Driver CAN ASIC

I/O Drivers Communication Drivers

Handler
Driver
Driver

Driver
CAN
DIO

SPI

CAN
DIO

SPI

µC

8
 SPI Handler

 SPI Handler module allows concurrent access of several clients to one or more SPI
buses

 In many ECUs, a lot of onboard hardware devices like external EEPROM, external I/O
ASICs, external watchdogs, System Basis Chip, etc. are connected to the
microcontroller via SPI

Example:

Onboard Device Memory Hardware Communication Hardware I/O Hardware Abstraction

Abstraction Abstraction Abstraction

External External
Driver for ext. Driver for ext.
Watchdog EEPROM
ADC ASIC I/O ASIC
Driver Driver

SPI Handler

Communication Drivers

SPI Driver

SPI
µC

9
 Memory Hardware Abstraction

 A group of modules which abstract from the location of memory devices (on-chip or
on-board) and the ECU hardware layout
 on-chip EEPROM and external EEPROM devices should be accessible via
an equal mechanism
 The memory drivers are accessed via memory specific abstraction (EEPROM
Abstraction/Flash EEPROM Emulation) modules
 Provides equal mechanisms to access internal (on-chip) and external (on-
board) memory devices and type of memory hardware (EEPROM, Flash)

Memory Hardware Abstraction

Memory Abstraction Interface

EEPROM Abstraction Flash EEPROM Emulation

External

ern
Ext

ver
Fla

Dri
al

sh
EEPROM Driver

COM Drivers Memory Drivers

EEPRO

Driver

Intern

Driver
Flash
Drive
Hand

al
M
SPI

ler

EEP

Fla
SPI

RO

µC

sh
M

10
 I/O Hardware Abstraction

 Group of modules which abstract from the location of I/O devices (on-chip or on-
board) and the ECU hardware layout (e.g. µC pin connections and signal level
inversions)
 The different I/O devices are accessed via an I/O signal interface
 Represent I/O signals (e.g. current, voltage, frequency) as they are connected to
the ECU hardware
 Hide ECU hardware and layout properties from higher software layers

I/O Hardware Abstraction

I/O Signal Interface
Driver for Driver for
ext. ext.
ADC ASIC I/O ASIC

COM Drivers I/O Drivers

Handler

Driver
Driver

Driver
ADC
DIO
SPI

ADC
DIO
SPI

µC

11
 Onboard Device Abstraction

 Contains drivers for ECU onboard devices (which cannot be seen as sensors or actuators)

like system basic chip, external watchdog, etc. Those drivers access the ECU onboard
devices via the Microcontroller Abstraction Layer
 Abstracts from ECU specific onboard devices

12
Communication Services

13
 Communication Services
 Group of modules for vehicle network communication (CAN, LIN and FlexRay)
 Provide uniform interface to the vehicle network for communication between different
applications
 Provide uniform services for network management
 Provide uniform interface to the vehicle network for diagnostic communication
 Hide protocol and message properties from the application
Communication Services
DCM Generic NM
AUTOSAR COM Diagnostic Com. Interface
Manager
Bus Specific
PDU Router Manager
<Bus specific>
IPDU Multiplexer NM
<Bus specific>
Transport Protocol

Communication Hardware Abstraction

Bus Specific
Interface

Communication Drivers
Bus Specific Driver

SCI µC

14
Communication Stack - CAN

 AUTOSAR COM, PDU Router, IPDUM,

Generic NM Interface and
Diagnostic Communication Manager
are the same for all vehicle
network systems
 A signal gateway is part of
AUTOSAR COM to route signals
 PDU (frame) based Gateway is part
of PDU Router
 IPDU multiplexing provides the
possibility to add information to
enable multiplexing of I-PDUs
(different contents but same IDs)
 Generic NM Interface contains only
a dispatcher
 CAN NM is specific for CAN networks
& will be instantiated per CAN
vehicle network system
 CAN State Manager handles the
Start and Stop communication on
CAN bus
15
Communication Stack - LIN

A LIN compliant communication stack

contains
 Schedule table manager for
transmitting LIN frames and to
handle requests to switch to
other schedule tables

 Transport protocol, used for

diagnostics

 Signal packing and unpacking

with a signal based API

 A Wakeup and Sleep Interface

 Underlying LIN Driver

Implementing the LIN protocol
and adapting the specific
hardware

16
 Communication Stack - FlexRay

 Uniform interface to the FlexRay network. Hide protocol and message properties
from the application.
 FlexRay NM is specific for FlexRay networks and will be instantiated per FlexRay
vehicle network system
System Services Communication Services
DCM Generic NM
Synchronization

Interface
Time Service

AUTOSAR COM Diagnostic Com.

Manager FlexRay State
and

PDU Router Manager

IPDU FlexRay NM
multiplexer FlexRay Transport
Protocol

FlexRay Interface Communication Hardware Abstraction

Driver for FlexRay Driver for external

Transceiver FlexRay Controller
I/O Drivers Communication Drivers
DIO Driver SPI Handler Driver Driver for internal FlexRay Controller

Host µC Internal FlexRay Controller

External External
FlexRay Controller FlexRay Transceiver Data lines
(e.g. MFR 4200) (e.g. TJA 1080) Control/status lines
17
 Memory Services

 Memory Services are a group of modules responsbile for the management of non
volatile data (read/write from different memory drivers)
 NVRAM manager expects a RAM mirror as data interface to the application for fast
read access
 Provide non volatile data to the application 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 storage etc

18
 System Services

System Services

Function Inhibition

Watchdog Manager

Development Error
ECU State Manager

Diagnostic Event
Communication

Synchronization
Manager
Manager

Manager

Service
Tracer
DEM
FIM
 Group of modules and functions
AUTOSAR OS

which can be used by modules of

BSW Scheduler

Interpolation Lib
all layers (Examples are AUTOSAR
OS, Error Manager, Library
CRC Lib routines, etc.)
Crypto Lib
 Some of these services are
Bit Lib µC dependent (like OS),
partly ECU hardware and
Other Libs application dependent (like
ECU State Manager) or
Flash Check
hardware and µC independent.

19
 Complex Drivers

 Implements complex sensor evaluation and actuator control with direct

access to the µC using specific interrupts and/or complex µC peripherals (like
PCP, TPU); e.g. fuel injection control, electric valve control

 Should fulfill the special functional and timing requirements for handling
complex sensors and actuators

20
 Application Layer and RTE

 µC and ECU HW independent and sensor and actuator dependent

 Abstract from the specific physical properties of sensors and actuators
 RTE is a layer providing communication services to the application software
 AUTOSAR Software Components communicate with other components (inter
and/or intra ECU) and/or services via the RTE

Application Layer

Actuator Sensor
Software Software
Component Component

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)

21
 BSW Scheduler - Scheduling

 BSW Scheduling assures

 Correct timing behavior of the BSW modules, i.e., correct interaction of all
BSW modules with respect to time
 Data consistency

 Centralize the BSW scheduling in the BSW Scheduler implemented

by the integrator
 Eases the integration task
 Enables to apply different scheduling strategies
preemptive, non-preemptive, ...
 Enables to apply different data consistency mechanisms
 Enables to reduce resources (e.g., minimize the number of tasks)

22
 BSW Scheduler - Scheduling

 Restrict the usage of OS functionality

 Only the Schedule Module uses OS objects or OS services
Rationale:
 Enables to reduce the usage of OS resources (Tasks, Resources,...)
 Enables to re-use modules in different environments

 The BSW Scheduler offers concepts and services for the

integration. Provides means to:
 Embed BSW module implementations into the AUTOSAR OS context
 Trigger main processing functions of the BSW modules
 Apply data consistency mechanisms for the BSW modules

23
 BSW Scheduler - Scheduling

 Technical Architecture (Schedule

 Logical Architecture (Model) Module SchM)

Task1 {
Zzz_MainFunction_Bbb(); Zzz_MainFunction_Bbb();
Yyy_MainFunction_Aaa(); Yyy_MainFunction_Aaa();
Xxx_MainFunction_Aaa(); Xxx_MainFunction_Aaa();

...
}

Transformation

– Mapping of scheduling objects to OS Tasks

– Specification of sequences of scheduling objects within tasks

24
 BSW Scheduler - Scheduling

RTE
BSW Scheduling objects
 Main functions
 n per module
 located in all layers Zzz_MainFunction_Aaa

 BSW Events
 Recurring Event
 Sporadic Event
Yyy_MainFunction_Aaa

Triggers
 Main functions
 Can be triggered in all layers by
 Recurring Events Xxx_Isr_Yyy
 Sporadic Events

Microcontroller

25
 BSW Scheduler - Data consistency

 The access to shared data from concurrent threads of code execution can
potentially cause data inconsistencies

 In general, there are two types of shared resources possible - resources accessed
globally and resources accessed locally

 In case of globally accessible resources, resources are passed via pointer. Thus, the
BSW module that ‘owns’ the resource cannot even apply any locking scheme to
provide data consistency

 For local accessible resources, data consistency can be achieved through exclusive
areas

26
 BSW Scheduler - Data consistency

 The BSW module assures data consistency for the internal shared resources. The
implementation of the BSW module exists as source code.
 Example implementation of the BSW module :
Com_cfg.h
#define EXCLUSIVE_AREA_0 ((uint8)0)
Com.c:
#include “Com_cfg.h”
#include “SchM_Com.h”
SchM_Enter_Com (EXCLUSIVE_AREA_0);
<Access to resource 0>
SchM_Exit_Com (EXCLUSIVE_AREA_0);

 The BSW scheduler implements calls to allow critical sections to be entered and
exited and are mapped to appropriate OS calls.
 Example implementation of the BSW Scheduler :
#define SchM_Enter_Com(0) DisableAllInterrupts
#define SchM_Exit_Com(0) EnableAllInterrupts

27
 Interfaces - General Rules

 AUTOSAR Interface

Communication Hardware Abstraction

 Standardized AUTOSAR Interface

Memory Hardware Abstraction

Onboard Device Abstraction
I/OHardware Abstraction
Communication Services

Communication Drivers
Microcontroller Drivers
 Standardized Interface

Memory Services
SystemServices

Complex Drivers

Memory Drivers

I/ODrivers
AUTOSAR SW Components / RTE            
ü “is allowed to use” System Services            
û “is not allowed to use” Memory Services            
D “restricted use (callback only)” Communication Services            
Complex Drivers            
I/O Hardware Abstraction            
The matrix is read row-wise: Onboard Device Abstraction            
Example: “I/O Drivers are allowed Memory Hardware Abstraction            
to use System Services and Communication Hardware Abstraction            
Hardware, but no other layers”. Microcontroller Drivers            
Memory Drivers            
(gray background indicates “non- Communication Drivers            
Basic Software” layers) I/O Drivers            

28
 Interfaces - Error Handling and
Reporting Concept

 Types of errors
 Hardware errors / failures - EEPROM cell is not writable any more
 Software errors – wrong API parameter (out of range)
 System errors – CAN receive buffer overflow, timeout for receive messages

 Time of error occurrence according to product life cycle

 Development (Detection and reporting can be statically switched on/off)
 Production / series – always active

 Alternatives to report an error

 Via API
 Via statically definable callback function (notification)
 Via central Error Hook (Development Error Tracer)
 Via central Error Function (AUTOSAR Diagnostic Event Manager)

29
 Configuration Classes

 Pre compile time

 Preprocessor instructions
 Code generation (selection)

 Link time
 Constant data outside the module; the data can be configured after the module
has been compiled

 Post build time

 Loadable constant data outside the module. Very similar to link time, but the
data is located in a specific memory segment that allows reloading (e.g. re-
flashing in ECU production line)
 Single or multiple configuration sets can be provided. In case multiple
configuration sets are provided, the actually used configuration set is to be
specified at runtime

30
 Configuration Classes - Pre compile
time
 Enabling/disabling optional functionality

 Optimization of performance and code size

 The module must be available as source code

 The configuration is static

Nm_Cfg.c Nm_Cfg.h

uses includes
(optional)

Nm.c

31
 Configuration Classes - Link Time

 Configuration of modules that are only available as object code

(e.g. IP protection or warranty reasons)

 Selection of configuration set after compilation but before linking

 One configuration set, no runtime selection

 Configuration data shall be captured in external constants

 These external constants are located in a separate file

 The module has direct access to these external constants

32
 Configuration Classes - Post build time

 Configuration of data where only the data structure is defined but the contents not
known during ECU build time

 Configuration of data that is likely to change or has to be adapted after ECU build time

 Reusability of ECUs across different product lines

 Implementation requires dereferencing which has impact on performance, code and

data size

PduR.c Compiler Linker PduR.o

Direct access
Linker control file (via reference as given by
the pointer parameter of
PduR’s initialization function)

PduR_PBcfg.c Compiler Linker PduR_PBcfg.o

33
Implementation Conformance Classes -
ICC1

Application Layer

AUTOSAR Runtime Environment (RTE)

Proprietary software

ECU Hardware

AUTOSAR conformant bus behavior

34
Implementation Conformance Classes -
ICC2

35
Implementation Conformance Classes -
ICC3

36
 Compiler Abstraction

Basics of Compiler Abstraction

 Compilers for 16 bit platforms are using special keywords to cope up with
properties of the microcontroller architecture caused by the limited 16 bit
addressing range

 The location of data and code has to be selected explicitly by special keywords (e.g
far, near)

 Using special keywords directly in the code would make it necessary to port the
software to each new microcontroller/ compiler family

 Compiler Abstraction makes software to work independent of compiler

37
 Compiler Abstraction

Function declarations in different Compilers

 Cosmic, S12X @near void MyNearFunction(void);
 Metrowerks, S12X void __near MyNearFunction(void);
 Greenhills, V850 void MyNearFunction (void);

 Cosmic, S12X @far void MyFarFunction(void);

 Metrowerks, S12X void __far MyFarFunction(void);
 Greenhills, V850 void MyFarFunction (void);

Pointer declarations in different Compilers

 Cosmic, S12X const @near uint8* MyNearPointer;
 Metrowerks, S12X const uint8* __near MyNearPointer;
 Greenhills, V850 const uint8* MyNearPointer;

 Cosmic, S12X @near uint8* MyNearPointer;

 Metrowerks, S12X uint8* __near MyNearPointer;
 Greenhills, V850 uint8* MyNearPointer;

38
 Compiler Abstraction

Compiler Abstraction Macros

 #define FUNC(rettype, memclass) memclass rettype
 #define P2VAR(ptrtype, memclass, ptrclass) \
ptrtype memclass * ptrclass
 #define P2CONST(ptrtype, memclass, ptrclass)\
const ptrtype memclass * ptrclass
 #define CONSTP2VAR(ptrtype, memclass, ptrclass)\
ptrtype memclass * const ptrclass
 #define CONSTP2CONST(ptrtype, memclass, ptrclass)\
const ptrtype memclass * const ptrclass
 #define P2FUNC(rettype, ptrclass, fctname)\
rettype (*ptrclass fctname)
 #define CONST(type, memclass) memclass const type
 #define VAR(vartype, memclass) memclass vartype

39
 Compiler Abstraction

Pointer classes and Memory classes

CANTP_PUBLIC_CODE API functions

CANTP_PUBLIC_CONST API constants

CANTP_PRIVATE_CODE Internal functions

CANTP_PRIVATE_DATA Component internal data
CANTP_PRIVATE_CONST Internal ROM Data

CANTP_APPL_CODE Callbacks of the Application

CANTP_APPL_CONST Applications' ROM Data
CANTP_APPL_DATA Applications' RAM Data

CANTP_CONFIG_CONST Configuration dependent constant

CANTP_CONFIG_DATA Configuration dependent data

40
 Compiler Abstraction

Three-step concept
 Macros for the encapsulation of definitions and declarations (Compiler.h)

 Distinguish between the different memory classes and pointer classes (#defines )

 Configure the #defines with the appropriate compiler specific keywords according
to the module’s description and memory set-up of the build scenario
(Compiler_Cfg.h)

41
 AUTOSAR Memory Mapping mechanism

Each AUTOSAR software module should wrap declaration and definition of code,
variables and constants using the following mechanism

Step1: Definition of start symbol for module memory section

Step2: Inclusion of MemMap.h
Step3: Declaration/definition of code, variables or constants belonging to
the specified section
Step4: Definition of stop symbol for module memory section
Step5: Inclusion of MemMap.h

42
AUTOSAR Memory Mapping mechanism

#define CANTP_START_SEC_VAR_16BIT
#include “MemMap.h”

uint16 CanTp_GusNasTimer;
uint16 CanTp_GusNbsTimer;
/* Any other 16 bit variables */

#define CANTP_STOP_SEC_VAR_16BIT
#include “MemMap.h”

43
 AUTOSAR Memory Mapping mechanism

#ifdef CANTP_START_SEC_VAR_16BIT
#undef CANTP_START_SEC_VAR_16BIT
#define START_SECTION_DATA_16BIT
#elif /* additional mappings of modules sections into project sections */
...
#endif

#ifdef START_SECTION_DATA_16BIT
#pragma DATA_SEG RAM_16BIT_SEGMENT
#undef START_SECTION_DATA_16BIT
#elif /* additional statements for switching the project sections */
...
#endif

44
 AUTOSAR Memory Mapping mechanism

#ifdef CANTP_STOP_SEC_VAR_16BIT
#undef CANTP_STOP_SEC_VAR_16BIT
#define STOP_SECTION_DATA
#elif /* additional mappings of modules sections into project sections */
...
#endif

#ifdef STOP_SECTION_DATA
#pragma DATA_SEG DEFAULT_SEGMENT
#undef STOP_SECTION_DATA
#elif /* additional statements for switching the project sections */
...
#endif

45
Questions??