EB tresos Classic AUTOSAR Training

Architecture & Methodology

Architecture & Methodology

Chapter overview
Architecture:
• Introduce the Layered Software Architecture and Basic software (BSW) Modules

Methodology
▪ Introduction to the AUTOSAR Configuration Concept
▪ Understand the Difference between System- and ECU-Configuration
▪ Understand the Complete Chain from System Description to Executable

Migration & Integration Strategies:

▪ Implementation Classes
▪ Configuration Variants & Classes

© Elektrobit (EB) 2022 | Confidential 2

Layered Software
Architecture

In cooperation with
Architecture and Methodology - Layered Software Architecture

Basic Software – Layers

Application Layer

Runtime Environment

Services Layer

Complex
ECU Abstraction Layer Drivers

Microcontroller Abstraction Layer

Microcontroller

© Elektrobit (EB) 2022 | Confidential 4

Architecture & Methodology - Basic AUTOSAR Approach

Microcontroller Abstraction Layer (MCAL)

• The Microcontroller Abstraction Layer is the lowest software layer of the Basic Software. It
contains internal drivers, which are software modules with direct access to the µC internal
peripherals and memory mapped µC external devices.

▪ Task:
– Make higher software layers independent of µC

▪ Properties:
– Implementation: µC dependent
– Upper Interface: Standardized and µC independent

• MCAL functional groups

Microcontroller Memory Drivers Crypto Drivers Wireless Communication I/O Drivers
Drivers Communication Drivers
Drivers

© Elektrobit (EB) 2022 | Confidential 5

Architecture and Methodology - Layered Software Architecture

ECU Abstraction Layer

• The ECU Abstraction Layer
– interfaces the drivers of the Microcontroller Abstraction Layer.
– contains drivers for external devices.
– offers an API for access to peripherals and devices regardless of their location (μC
internal/external) and their connection to the μC (port pins, type of interface)

▪ Task:
– Make higher software layers independent of ECU hardware layout, e.g. bus
types, memory devices

▪ Properties:
– Implementation: μC independent, ECU hardware dependent
– Upper Interface: μC and ECU hardware independent, dependent on signal type
Onboard Device Memory Crypto Hardware Wireless Communication
Abstraction Hardware Abstraction Communication Hardware
• ECU abstraction layer functional groups: Abstraction HW Abstraction Abstraction

© Elektrobit (EB) 2022 | Confidential 6

Architecture and Methodology - Layered Software Architecture

Complex Drivers
▪ The Complex Drivers Layer spans from the hardware 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: ECU specific modeling of AUTOSAR interface description

© Elektrobit (EB) 2022 | Confidential 7

Architecture & Methodology – I/O Hardware Abstraction

I/O Hardware Abstraction

• The I/O Hardware Abstraction belongs to the ECU Abstraction Layer
• It 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)
• Its upper layer is the RTE but there are no standardized AUTOSAR interfaces
(i.e. no Service Layer modules which could provide these interfaces to the RTE)
– Details are project specific - AUTOSAR provides only high-level requirements and
guidelines

Task:
• Represent I/O signals as they are connected to the ECU hardware (e.g. current,
voltage, frequency).
• Hide ECU hardware and layout properties from higher software layers.
Properties:
• Implementation: µC independent, ECU hardware dependent
• Upper Interface: µC and ECU hardware independent, dependent on signal type
specified and implemented according to AUTOSAR (AUTOSAR interface)

© Elektrobit (EB) 2022 | Confidential 8

Architecture & Methodology – I/O Hardware Abstraction

I/O Hardware Abstraction - Example

Air temperature = 302 K
SW-C
(Signal value)

RTE

SIGNAL
INTERFACE

ADC BOARD
HANDLER

SPI
CH0
HANDLER

CH1

CH2
SPI DRV T
CH3 Air temperature = 302 K
SPI (Physical value)
CH5
V V

SPI ADC Board Temperature sensor

© Elektrobit (EB) 2022 | Confidential 9
Architecture and Methodology - Layered Software Architecture

Services Layer
• The Service Layer is the highest layer of the Basic Software
• While access to I/O signals is covered by the ECU Abstraction Layer, the Services
Layer offers:
– Operating system functionality
– Vehicle network communication and management services
– Memory services (NVRAM management)
– Diagnostic Services (including UDS communication, error memory and fault treatment)
– ECU state management, mode management
– Logical and temporal program flow monitoring (Wdg manager)
▪ Task:
– Provide basic services for application, RTE and basic software modules.

▪ Properties:
– Implementation: Mostly μC, ECU hardware independent (Exception: Os)
– Upper Interface: μC and ECU hardware independent

© Elektrobit (EB) 2022 | Confidential 10

Architecture and Methodology - Layered Software Architecture

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

© Elektrobit (EB) 2022 | Confidential 11

Architecture and Methodology - Layered Software Architecture

Application Layer
• The Application Layer is a layer consisting of 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:
– Implement applications (runnables) that are executed by the RTE

▪ Properties:
– Applications completely ECU independent.
– Sensor/Actuator SW-Cs are dependent on the specifics of a sensor or
actuator.

© Elektrobit (EB) 2022 | Confidential 12

Methodology

In cooperation with
Architecture & Methodology - Methodology

Methodology: From Virtual Function Bus to ECU level

SW-C SW-C SW-C SW-C
…
A B C n

Application
Interfaces Virtual Functional Bus

Methodology
ECU I ECU II ECU m

SW-C SW-C SW-C SW-C

A B C … n

Architecture RTE RTE RTE

BSW BSW BSW

© Elektrobit (EB) 2022 | Confidential 14

EB tresos Studio - overview

AUTOSAR Methodology Exchange Files Tooling

AUTOSAR Systemdesign,
SYS-D
Software Architecture
.arxml • Define Hardware Topology
• Define SWCs, Runnables, Data
• Mapping of SWCs to ECUs
• Communication Matrix
• Export as AUTOSAR Sys-D

Application
System
Definition of ECU
ECU AUTOSAR Application (SWC)
SWC-D • Model Application Behaviour
• Define ports and data types
.arxml • Create SWC Description
• Export SWC Description
• Generate application code
BSW

AUTOSAR Configuration of
BSW- ECU Basic Software
Config
.epc,
.xdm

OEM TIER1 EB tresos Studio

EB tresos AutoCore

© Elektrobit (EB) 2022 | Confidential 15

Architecture & Methodology - Methodology

Configuration
SYSTEM LEVEL ECU LEVEL (FOR EACH ECU)
CONFIGURE
CONFIGURE ECU
SYSTEM

GENERATE
EXTRACT RTE
ECU EXTRACT
ECU-SPECIFIC
SYSTEM OF SYSTEM
INFORMATION
CONFIGURATION CONFIGURATION
INPUT
.h / .c
ECU
CONFIGURATION GENERATE BSW 1
SYSTEM DESCRIPTION
CONFIGURATION
DESCRIPTION

.h / .c
…
GENERATE BSW m

.h / .c

© Elektrobit (EB) 2022 | Confidential 16

Architecture & Methodology - Methodology

System Description
Map SW-Cs to ECUs

Defines SW-Cs
Defines ECUs
Defines Topology

Contains the complete (all

ECUs) system information,
including bus-mapping,
topology etc.
Extract the information for
each ECU

© Elektrobit (EB) 2022 | Confidential 17

Architecture & Methodology - Methodology

Example: Define SW-Cs and ECUs

A1 A2 A3 E2
E1
A4
A13 A14
A5 E3
E8
E7
A12 A8 A6
A9
E4
A11 A7 E6 E5
A10

Application SW-Cs Available ECUs

© Elektrobit (EB) 2022 | Confidential 18

Architecture & Methodology - Methodology

Example: Topology

E1 E3 E4

CAN2

E2 E5 E8

CAN1
E6

LIN
E7

© Elektrobit (EB) 2022 | Confidential 19

Architecture & Methodology - Methodology

Example: SW-C Mapping

A13
A16 A14 A12 A11 A9 A7

E1 E2 E3 E4

A4
A2 A10 A15
A3 A8 A1 A4 A9 A5 A6

E5 E6 E7 E8

© Elektrobit (EB) 2022 | Confidential 20

Architecture & Methodology - Methodology

Example: ECU Extract

A13
A16 A14 A12 A11 A9 A7

E1 E2 E3 E4

A4
A2 A10 A15
A3 A8 A1 A4 A9 A5 A6

E5 E6 E7 E8

© Elektrobit (EB) 2022 | Confidential 21

Architecture & Methodology - Methodology

Example: ECU Extract

A4

A10 A15

A4 A9 A5

E7

© Elektrobit (EB) 2022 | Confidential 22

Architecture & Methodology - Methodology

ECU Configuration Add ECU specific information, e.g.

task scheduling, basic software and
configuration of basic software
Map SW-Cs to ECUs

Defines SW-Cs
Defines ECUs
Defines Topology

Contains the complete (all

ECUs) system information,
including bus-mapping,
topology etc.
Extract the information for
each ECU

© Elektrobit (EB) 2022 | Confidential 23

Architecture & Methodology - Methodology

ECU Configuration Add ECU specific information, e.g.

task scheduling, basic software and
configuration of basic software
Map SW-Cs to ECUs
Generate the ECU
configuration

Defines SW-Cs
Defines ECUs
Defines Topology

Contains the complete (all

ECUs) system information,
including bus-mapping,
topology etc.
Extract the information for
each ECU

© Elektrobit (EB) 2022 | Confidential 24

Architecture & Methodology - Methodology

ECU Configuration Add ECU specific information, e.g.

task scheduling, basic software and
configuration of basic software
Map SW-Cs to ECUs
Generate the ECU
configuration

Defines SW-Cs
Defines ECUs
Defines Topology

Contains the complete (all

ECUs) system information,
including bus-mapping,
topology etc.
Extract the information for Generate the
each ECU source files

© Elektrobit (EB) 2022 | Confidential 25

Architecture & Methodology - Methodology

Example: Code Generation for Module CanIf

Generated code

CanIf CODE CanIf_Lcfg.h CanIf_PBcfg.h

CanIf_Cfg.h
GENERATOR CanIf_PBcfg.c
ECU CONFIGURATION CanIf_Cfg.c CanIf_Lcfg.c
compile and link
DESCRIPTION (with the other modules)

Non generated code

CanIf.h CanIf.c

© Elektrobit (EB) 2022 | Confidential 26

Architecture & Methodology - Methodology

Example: Code Generation for the RTE

ECU Configuration SW-C Description SW-C Description SW-C Description

A-R1 B-R1 C-R1

A-R1
S-P1 B-P1 C-R2
A-P1
… …
…
A-P1
B-R1
Service
B-P1 Component
C-R2 RUN TIME ENVIRONMENT Description

C-R1 S-P1
S-P2 S-P2
…
…

RTE
GENERATOR

© Elektrobit (EB) 2022 | Confidential 27

Architecture & Methodology - Methodology

Overview of AUTOSAR schema versions vs. AUTOSAR release

• The AUTOSAR schema version needs to be referenced in all ARXML files

• Note that with the introduction of the Adaptive Platform, the schema version does not equal the Platform release anymore:

© Elektrobit (EB) 2022 | Confidential 28

Migration & Integration Strategies

In cooperation with
Architecture & Methodology - Migration & Integration Strategies

Implementation Conformance Class 1 / ICC1

APPLICATION LAYER

RTE

PROPRIETARY SOFTWARE

MICROCONTROLLER
AUTOSAR conformant bus behaviour

© Elektrobit (EB) 2022 | Confidential 30

Architecture & Methodology - Migration & Integration Strategies

Implementation Conformance Class 2 / ICC2

APPLICATION LAYER

RTE

Ex.1: DIAGNOSTICS

Ex.3: CAN
DCM
DEM
FIM

CanIf CAN TP

PROPRIETARY SOFTWARE
CAN SM

CAN DRV
Ex.2: COM SERVICES
CANNM
COM

PDUR

MICROCONTROLLER
AUTOSAR conformant bus behaviour

© Elektrobit (EB) 2022 | Confidential 31

Architecture & Methodology - Migration & Integration Strategies

Implementation Conformance Class 3 / ICC3

APPLICATION LAYER

RTE

AUTOSAR conformant bus behaviour

© Elektrobit (EB) 2022 | Confidential 32
Architecture & Methodology - Migration & Integration Strategies

Configuration Classes of Parameters

Configuration Attribute / Implementation of Parameter
Class of
Parameter
Pre-compile time ▪ Can be changed at precompile time
▪ Optimization of performance and code size → Usually
#defines
Link time ▪ Can be changed at link time or precompile time
▪ Usually implemented as const qualified variables
▪ Allows for library/object code delivery of module
Post-build time ▪ Can be changed at post-build time or link time or
precompile time
▪ Configuration can be updated separately from the static
module code → post-build loadable
▪ Switch between different configurations based on coding is
possible → post-build selectable

© Elektrobit (EB) 2022 | Confidential 33

Architecture & Methodology - Migration & Integration Strategies

Configuration Files
• Pre-compile time configuration
• Preprocessor instructions
Module.c Module_Cfg.h Module.h

• Link-time configuration
• Constant data outside the module
Module_Lcfg.c Module_Lcfg.h

• Post-build time configuration

• Loadable constant data outside the module

Module_PBcfg.c Module_PBcfg.h

Note! The configuration parameters in one module could belong to different configuration
classes.

© Elektrobit (EB) 2022 | Confidential 34

Introduction & Concepts - Summary

Summary
Architecture
• Introduce the Layered Software Architecture and Basic software (BSW) Modules

Methodology
▪ Understand the Difference between System- and ECU-Configuration
▪ Understand the Complete Chain from System Description to Executable

Migration & Integration Strategies

▪ Implementation Classes
▪ Configuration Classes

© Elektrobit (EB) 2022 | Confidential 35

Get in touch!

[email protected]
www.elektrobit.com