EB Tresos Classic AUTOSAR Training - Concepts

EB tresos classic
AUTOSAR training
- Concepts
Concepts
Chapter overview
 Basic AUTOSAR Concepts and Terminology
 Relationship between Virtual Functional Bus (VFB) and Runtime Environment

(RTE)
 Overview of the AUTOSAR Basic Software Architecture and Tooling
 Configuration Variants & Classes
 Memory Mapping
© Elektrobit (EB) 2018 | Confidential 2

Concepts
Basic AUTOSAR Glossary
• AUTOSAR defines four key concepts:

‒ Software components (SW-C)
– A piece of software to be run in an AUTOSAR system
‒ Virtual Functional Bus (VFB)
– High level communication abstraction
‒ Run Time Environment (RTE)
– Implements the VFB on one ECU
‒ Basic Software (BSW)
– Standard software for standard ECU functionality (OS, communication, memory, hardware
drivers, diagnostics etc)
“Learn these, and you can

begin to speak AUTOSAR”…

Software Components
and
Virtual Function Bus
Concepts - Basic AUTOSAR Approach
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

 An AUTOSAR application consists of one or more (interconnected) Software

components (SW-C)
 Virtual Functional Bus (VFB) is a concept that allows for strict separation
between software components and infrastructure.
 Run Time Environment (RTE) is a communication centre for inter- and intra-
ECU information exchange.
 The Basic Software (BSW) is a standardized software layer that provides

standard ECU functionality (OS, low level drivers, bus-communication,
diagnostics, memory management etc.)

• SW-C communicates through well defined Ports and Interfaces

• Ports and Interfaces are specified in Software Component
• Descriptions
Software
Component SW-C SW-C SW-C
SW-C
Description A B C n
Ports and
Interfaces
Assembly
connectors
Virtual Functional Bus

• The Software Component Description (SWCD) is an XML file that completely

defines properties of the SW-C (e.g. ports, interfaces and behavior)
• The SW-C contains an SWCD and the SW-C implementation

<?xml version="1.0" encoding="UTF-8"?> #include ”MySWC.h”
<AUTOSAR xmlns="http://autosar.org/3.1.2">
<TOP-LEVEL-PACKAGES> Std_ReturnType fun1()
<AR-PACKAGE> {
<SHORT-NAME>MySwcDescription</SHORT-NAME> /* Implementation */
<ELEMENTS>
return E_OK;
.... }
</ELEMENTS> Std_ReturnType fun2()
</AR-PACKAGE> SW-C {
</TOP-LEVEL-PACKAGES> /* Implementation */
</AUTOSAR> …

Concepts - Ports
• An SW-C uses Ports to communicate with other components or with the ECU
hardware
• Two types of ports depending on signal direction or semantics

‒ Require Port (R-Port)
‒ Provide Port (P-Port)
Software component
P-Port1
R-Port1 P-Port2
R-Port2

Concepts - Interfaces
• An Interface is a contract between a P-port and an R-port
• The Interface defines the data or operations that can be handled by the Port
• There are different kind of Interfaces

• Sender-Receiver (S/R)
• Client-Server (C/S) Software component
P-Port1:Interface1
S/R
R-Port1:Interface2
P-Port2:Interface3
R-Port2:Interface4 C/S

Concepts – Sender/Receiver Communication
• Broadcast of signals S/R
• An S/R interface may contain one or more DataElements (signals)
• A DataElement always has a data type

‒ Primitive data types (Integer, Enumeration, Boolean…)
‒ Complex data types (Arrays and Record)

Concepts - Client-Server Communication
• A C/S interface may contain one or more Operations C/S

(functions)
• Each operation contains zero or more Arguments

(type “IN”, “OUT” or “IN/OUT”)
• Each operation contains zero or more Error Return Codes
• A Server provides a service via a P-Port

Concepts - Client-Server Communication
• The clients may invoke the server by connecting their C/S

R-Ports to the server port (the client requires a service)
• Synchronous call
• Rte_Call will not return until result is available (blocking)
• Asynchronous call
• Rte_Call will initiate operation but will return immediately (non-blocking)
• Rte_Result will provide the result (non-blocking or blocking)

Virtual Function Bus
and
Runtime Environment (RTE)
Concepts - VIRTUAL FUNCTIONAL BUS (VFB)
 A Software Component (SW-C) is an application module that implements an

AUTOSAR application
 An SW-C is a high level abstraction which is unaware of where in the system (in
which ECU) it is situated
 The Virtual Functional Bus (VFB) is a high level abstraction of the available
communication paths between the SW-Cs
SW-C SW-C SW-C . . . SW-C

1 2 3 m
VFB

Concepts - VIRTUAL FUNCTIONAL BUS (VFB)
 During system design, the SW-Cs are partitioned onto ECUs

 There are two different types of communication paths in the VFB
‒ Intra-ECU (inside one ECU)
‒ Inter-ECU (between different ECUs)
ECU 1 ECU 2 ECU N

1 2 3 m
VFB

Concepts - RUNTIME ENVIRONMENT (RTE)
 The Runtime Environment (RTE) is the only interface to the SW-Cs

 The RTE implements the VFB
 The RTE uses CAN/Ethernet/FlexRay/LIN buses for inter-ECU communication via
the Basic Software Layer (BSW)
ECU 1 ECU 2 ECU N

1 2 3 m
VFB
RTE RTE RTE
BSW BSW BSW
CAN/Ethernet/FlexRay/
LIN

Concepts - AUTOSAR BENEFITS
Yesterday AUTOSAR
App 2
App 1
SWC 1 SWC 2 SWC 3 SWC n
…
App 5
App 3 App 4
RTE
Diagnostics Custom
Comm stack
manager service
 AUTOSAR is a standardized platform

 Well defined APIs for communication
 No difference between internal communication and bus communication
•  Relocatability and reuse!

Basic Software
Concepts - BASIC SOFTWARE MODULES
SERVICE LAYER
ECU ABSTRACTION LAYER
MICROCONTROLLER ABSTRACTION LAYER
Hardware

Concepts - BASIC SOFTWARE MODULES
CAN
COM DCM SM
NM
WDG MGR
COMM
ECU MANAGER
NVRAM
DEM
DET
FIM
LIN
MANAGER PDUR SM FR CAN I/O
IPDUM HARDWARE
FR CAN LIN FR NM NM
TP TP TP SM ABSTRACTION
MEMORY ABSTRACTION IF
BSW SHEDULER
WDGIF CANIF LINIF FRIF

EEPROM FLASH EEPROM
OS
EXT ABSTRACTION EMULATION EXT EXT EXT

CRC LIB
CAN LIN FR
WDG EXT EXT CAN LIN FR
TRCV TRCV TRCV
DRV EEPROM DRV FLASH DRV DRV DRV DRV
FLASH CHECK
EEPROM DRV
FLASH DRV
RAM TEST
MCU DRV
PORT DRV
WDG DRV
GPT DRV
PWM DRV
CAN DRV
DIO DRV
LIN DRV
ADC DRV
SPI DRV
ICU DRV
FR DRV
Hardware

Concepts - BASIC AUTOSAR APPROACH
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
RTE RTE RTE

Architecture
BSW BSW BSW

Concepts - RTE/BSW CONFIGURATION
ECU I
 The implementations of the RTE and BSW
modules are specified by AUTOSAR SW-C SW-C
A B
 Their behavior must be configured by RTE

the integrator
BSW
 Examples:
‒ Number of CAN channels
95% configuration and 5% implementation
‒ CAN frames
‒ ECU power states
‒ Flash memory blocks
‒ OS tick time
 Exception: The HW I/O abstraction module is project specific and has to be

implemented from scratch (more about this later)

Concepts - RTE/BSW CONFIGURATION
 To edit the BSW configuration a Generic Configuration Editor (GCE) may be used
 The GCE loads BSW module description

(BSW-MD) files which contain rules for
creating the BSW configurations
 The user can browse the BSW module

configurations and edit their contents
 Example of GCEs:
‒ EB tresos Studio
‒ Mecel Picea Workbench
‒ Geensoft GCE
‒ Vector DaVinci Configurator Pro
‒ …

Concepts - SW-C CONFIGURATION
ECU I
 SW-Cs are also “configured” to some extent
SW-C SW-C
A B
 Examples:
RTE
‒ Data Types
BSW
‒ Communication signals
‒ Scheduling
‒ Inter task communication
 Based on this configuration, the RTE will provide the necessary APIs
 The source code in the SW-Cs can either be implemented manually (coding C or C++) or
modeled using e.g. Simulink or Targetlink

Concepts - SW-C CONFIGURATION
 To edit the SW-C configurations an AUTOSAR Authoring Tool (AAT) is used
 The authoring tool allows you to specify SW-Cs, connect them and integrate them with
the BSW layer
 Example of AATs:
‒ dSpace SystemDesk
‒ Dassault Systemes AUTOSAR Builder
‒ Vector DaVinci Developer
‒ Mecel Picea Workbench

Concepts - ECU CONFIGURATION DESCRIPTION
 The entire configuration (SW-C + RTE + BSW) for one

ECU is called the ECU Configuration Description
ECU I
SW-C SW-C
 The ECU configuration description can be stored and A B
exchanged in a standardized XML format called
AUTOSAR XML (ARXML) RTE
BSW
<?xml version="1.0" encoding="UTF-8"?>

<AUTOSAR xmlns="http://autosar.org/3.1.2">
<TOP-LEVEL-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>MyAutosarSystem</SHORT-NAME>
<ELEMENTS>
ECU Configuration Description.arxml
....
</ELEMENTS>
</AR-PACKAGE>
</TOP-LEVEL-PACKAGES>
</AUTOSAR>

Concepts - BASIC SOFTWARE CONFIGURATION
 The ECU configuration description is translated into compliable C source code using
Source Code Generators (SCG)
OS SCG
OS Configuration .h/.c
CAN SCG
ECU Configuration Description.arxml CAN Configuration .h/.c

. .
. .
. .
RTE SCG
RTE .h/.c
 Typically there is one SCG per module in the BSW layer. The RTE is also generated
using an SCG.

Concepts - BASIC SOFTWARE CONFIGURATION
 The generated configuration files will together with the static BSW module implementation files
form a complete compilable module
BSW Module C Compiler

source code .h/.c
BSW Module.o
BSW Module
Configuration .h/.c

Configuration
Variants & Classes
Concepts - Configuration Variants & Classes
Configuration Classes
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 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

Configuration Variant
• Attribute that defines the variant(s) that an AUTOSAR module may support
(specification)
Configuration Variant Allowed Parameter Config classes
VARIANT-PRE-COMPILE Pre-compile time
VARIANT-LINK-TIME Pre-compile time
Link time
VARIANT-POST-BUILD Pre-compile time
Link time
Post-build time
• Example:
Source: Specification of CAN Driver, Chapter 10

Actual configuration class for a parameter

• The AUTOSAR SWS defines for each supported configuration variant the
configuration class of each configuration parameter.
• Example: The module (CAN) with config variant VARIANT-POST-BUILD will still
have some parameters that are only Pre-compile time configurable (e.g.
CanIfTxPduId)
Source: Specification of CAN Interface, Chapter 10

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.

Example for configuration class Pre-compile time

• Spi_Cfg.h:
#define SPI_DEV_ERROR_DETECT ON
• Spi.c (available as source code):

#include “Spi_Cfg.h“
…
#if (SPI_DEV_ERROR_DETECT == ON)
Det_ReportError(Spi_ModuleId, 0, 3, SPI_E_PARAM_LENGTH);
#endif

Example for configuration class Link time

• CanIf_Lcfg.c:
#include “Dem_Cfg.h”
…
const Dem_EventIdType CanIf_PduId = CANIF_E_PDUID;
• CanIf.c (available as object code):

#include “Dem.h“
…
Dem_ReportErrorStatus(CanIf_PduId,
DEM_EVENT_STATUS_FAILED);

Overview Post Build concepts
Post-build time loadable concept Post-build time selectable concept

 Now: Post-build Variants

Workflow Post-build loadable
Step1: Configuration of all ECU parameters
..
.
CanIf.o Direct access

Generator Compiler
(via reference as
CanIf.c CanIf.o given by
Linker .. the pointer
.
Configuration
parameter of
.xml CanIf’s
CanIf_PBcfg.o initialization
Generator Compiler function
CanIf_PBcfg.c CanIf_PBcfg.o ..
.
Memory Map
Workflow Post-build loadable
Step2: Change of post-build time configuration parameters

Note: No modification of pre-compile / link-time parameters allowed
..
.
Compiler CanIf.o Direct access

Toolchain or
Tool (via reference as
supported given by
direct binary .. the pointer
generation .
Configuration
parameter of
.xml CanIf’s
CanIf_PBcfg.o initialization
Generator Compiler function
CanIf_PBcfg.c CanIf_PBcfg.o ..
.
Memory Map
Memory Mapping
Concepts – Memory Mapping
Principle of Memory Mapping

• Objectives:
‒ Avoidance of waste of RAM
‒ Usage of specific RAM/ROM properties
‒ Usage of the same source code of a module for boot loader and application
‒ Support of Memory Protection
‒ Support of partitioning

Principle of Memory Mapping

• Inclusion of MemMap.h

General issues
• Memory mapping can be achieved with compiler and linker
specific keywords like near, far, or #pragma
‒ See AUTOSAR_SWS_MemoryMapping.pdf  chapter 7 or user
manual of compiler and linker
• AUTOSAR Solution:
‒ Usage of memory mapping files MemMap.h
‒ Supports configuration and compiler abstraction

Usage of MemMap.h
• Usage in BSW modules:
#define EEP_START_SEC_VAR_INIT_16
#include “MemMap.h”
static uint16 EepTimer = 100;
static uint16 EepRemainingBytes = 16;
#define EEP_STOP_SEC_VAR_INIT_16
#include “MemMap.h”
• Usage in SWCs:
#define Abc_START_SEC_CODE
#include “Abc_MemMap.h”
/* --- Write a Code here */
#define Abc_STOP_SEC_CODE
#include “Abc_MemMap.h”

Concepts - Summary
 Basic AUTOSAR Concepts and Terminology
 Relationship between Virtual Functional Bus (VFB) and Runtime Environment

(RTE)
 Overview of the AUTOSAR Basic Software Architecture and Tooling
 Configuration Variants & Classes
 Memory Mapping

Contact us! automotive.elektrobit.com

EB Tresos Classic AUTOSAR Training - Concepts

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EB Tresos Classic AUTOSAR Training - Concepts

Uploaded by

Copyright:

Available Formats

EB tresos classic

 Relationship between Virtual Functional Bus (VFB) and Runtime Environment

 Overview of the AUTOSAR Basic Software Architecture and Tooling

 Configuration Variants & Classes

© Elektrobit (EB) 2018 | Confidential 2

Basic AUTOSAR Glossary

• AUTOSAR defines four key concepts:

“Learn these, and you can

© Elektrobit (EB) 2018 | Confidential 3

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

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

Architecture RTE RTE RTE

BSW BSW BSW

© Elektrobit (EB) 2018 | Confidential 5

 An AUTOSAR application consists of one or more (interconnected) Software

 The Basic Software (BSW) is a standardized software layer that provides

© Elektrobit (EB) 2018 | Confidential 6

• SW-C communicates through well defined Ports and Interfaces

© Elektrobit (EB) 2018 | Confidential 7

• The Software Component Description (SWCD) is an XML file that completely

• The SW-C contains an SWCD and the SW-C implementation

© Elektrobit (EB) 2018 | Confidential 8

• Two types of ports depending on signal direction or semantics

© Elektrobit (EB) 2018 | Confidential 9

• An Interface is a contract between a P-port and an R-port

• There are different kind of Interfaces

© Elektrobit (EB) 2018 | Confidential 10

• Broadcast of signals S/R

• An S/R interface may contain one or more DataElements (signals)

• A DataElement always has a data type

© Elektrobit (EB) 2018 | Confidential 11

• A C/S interface may contain one or more Operations C/S

• Each operation contains zero or more Arguments

• Each operation contains zero or more Error Return Codes

• A Server provides a service via a P-Port

© Elektrobit (EB) 2018 | Confidential 12

• The clients may invoke the server by connecting their C/S

© Elektrobit (EB) 2018 | Confidential 13

 A Software Component (SW-C) is an application module that implements an

SW-C SW-C SW-C . . . SW-C

© Elektrobit (EB) 2018 | Confidential 15

 During system design, the SW-Cs are partitioned onto ECUs

ECU 1 ECU 2 ECU N

SW-C SW-C SW-C . . . SW-C

© Elektrobit (EB) 2018 | Confidential 16

 The Runtime Environment (RTE) is the only interface to the SW-Cs

ECU 1 ECU 2 ECU N

SW-C SW-C SW-C . . . SW-C

BSW BSW BSW

© Elektrobit (EB) 2018 | Confidential 17

SWC 1 SWC 2 SWC 3 SWC n

 AUTOSAR is a standardized platform

© Elektrobit (EB) 2018 | Confidential 18

ECU ABSTRACTION LAYER

MICROCONTROLLER ABSTRACTION LAYER

© Elektrobit (EB) 2018 | Confidential 20

WDGIF CANIF LINIF FRIF

EXT ABSTRACTION EMULATION EXT EXT EXT

© Elektrobit (EB) 2018 | Confidential 21

SW-C SW-C SW-C … SW-C

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

RTE RTE RTE

© Elektrobit (EB) 2018 | Confidential 22