AUTOSAR Layered Software Architecture

Layered Software Architecture

- AUTOSAR Confidential -

Document Title

Layered Software Architecture

Document Owner

AUTOSAR

Document Responsibility

AUTOSAR

Document Identification No

053

Document Classification

Auxiliary

Document Status

Final

Part of AUTOSAR Release

4.2.2

- AUTOSAR Confidential 2

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Document Change History Release

Changed by

Change Description

4.2.2

AUTOSAR Release  Editorial changes Management

4.2.1

AUTOSAR Release  Incorporated new 4.2 concepts for: Switch Configuration; Sender-Receiver-Serialization; CAN-FD; Management Large-Data-COM; E2E-Extension; Global Time Synchronization; Support for Post-build ECUConfiguration; Secure-Onboard-Communication; ASIL/QM-Protection  Introduction of new error classification  Editorial changes

4.1.3

AUTOSAR Release  Editorial changes Management




Changed by

Change Description

4.1.1

AUTOSAR Administration

       

Clarification of partial network support for CAN/LIN slave. New Ethernet stack extensions Added Crypto Service Manager to System Services Revised presentation of J1939 and added new J1939 modules Added new energy management concepts: “Pretended Networking”, “ECU Degradation” Added new modules: “Output Compare Unit Driver” and “Time Service” Changed handling of Production Errors Fixed various typography and layout issues

4.0.3


     

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“

4.0.1


3.1.4


   

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" 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 been added. E.g.,. Multi-Core Systems, Partitioning, Mode Management, Error Handling, Reporting and Diagnostic, Debugging, Measurement and Calibration, Functional Safety etc  Legal disclaimer revised - AUTOSAR Confidential -

4



Changed by

3.1.1


3.0.1


2.1.15


2.1.1


1.0.1


1.0.0


Change Description  Legal disclaimer revised  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  Correct version released  Initial release



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 products actually 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.



page id: 94jt4

Table of contents 1. Architecture 1. Overview of Software Layers 2. Content of Software Layers 3. Content of Software Layers in Multi-Core Systems 4. Content of Software Layers in Mixed-Critical Systems 5. Overview of Modules 6. Interfaces 1. General 2. Interaction of Layers (Examples)

2. Configuration 3. Integration and Runtime Aspects



page id: 94jt2

Introduction Purpose and Inputs Purpose of this document The 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. - AUTOSAR Confidential 18


page id: 94jt1

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 more than 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. - AUTOSAR Confidential 19


page id: 94qu9

Architecture – Overview of Software Layers Top view The AUTOSAR Architecture distinguishes on the highest abstraction level between three software layers: Application, Runtime Environment and Basic Software which run on a Microcontroller.

Application Layer

Runtime Environment (RTE) Basic Software (BSW)

Microcontroller - AUTOSAR Confidential 20


page id: 94ju3

Architecture – Overview of Software Layers Coarse view The AUTOSAR Basic Software is further divided in the layers: Services, ECU Abstraction, Microcontroller Abstraction and Complex Drivers.

Application Layer

Runtime Environment

Services Layer

ECU Abstraction Layer

Microcontroller Abstraction Layer



Complex Drivers

page id: 94ju4

Architecture – Overview of Software Layers Detailed view The Basic Software Layers are further divided into functional groups. Examples of Services are System, Memory and Communication Services.

Application Layer

Runtime Environment System Services

Memory Services

Communication Services

Onboard Device Abstraction

Memory Hardware Abstraction

Communication Hardware Abstraction

Microcontroller Drivers

Memory Drivers

Communication Drivers



I/O Hardware Abstraction

I/O Drivers

Complex Drivers

page id: 94ju6

Architecture – Overview of Software Layers Microcontroller Abstraction Layer 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 and internal peripherals. Task Make higher software layers independent of µC

Application Layer

RTE

ECU Abstraction Layer Microcontroller Abstraction Layer Microcontroller

Properties Implementation: µC dependent Upper Interface: standardized and µC independent



Co mpl ex Driv ers

page id: 94ju7

Architecture – Overview of Software Layers ECU Abstraction Layer The ECU Abstraction Layer interfaces the drivers 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 (µC internal/external) and their connection to the µC (port pins, type of interface)

Application Layer

RTE

ECU Abstraction Layer ECU Abstraction Layer Microcontroller Abstraction Layer Microcontroller

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 ex Driv ers

page id: 94jwe

Architecture – Overview of Software Layers Complex Drivers The Complex Drivers Layer spans from the hardware to the RTE.

Application Layer

RTE

Properties Implementation: might be application, µC and ECU hardware dependent Upper Interface: might be application, µC and ECU hardware dependent



Services Layer Abstraction Layer ECUECU Abstraction Layer Microcontroller Abstraction Layer Microcontroller

Complex Drivers

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.

page id: 94ju8

Architecture – Overview of Software Layers Services Layer The Services Layer is the highest layer of the Basic Software which also applies for its relevance for the application software: while access to I/O signals is covered by the ECU Abstraction Layer, the Services Layer offers:

Task Provide basic services for applications, RTE and basic software modules. Properties Implementation: mostly µC and ECU hardware independent Upper Interface: µC and ECU hardware independent - AUTOSAR Confidential 26


RTE Services Layer Abstraction Layer ECUECU Abstraction Layer Microcontroller Abstraction Layer Microcontroller

Complex Drivers

 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)  Cryptographic Services (Crypto Service Manager)

Application Layer

page id: 94ju9

Architecture – Overview of Software Layers 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).

Application Layer

AUTOSAR Runtime Environment (RTE)

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



Services Layer Abstraction Layer ECUECU Abstraction Layer Microcontroller Abstraction Layer Microcontroller

Complex Drivers

Above the RTE the software architecture style changes from “layered“ to “component style“.

page id: 94j33

Architecture – Overview of Software Layers 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 and ECU internal SW  System Provision of standardizeable (operating system, timers, error memory) and ECU specific (ECU state management, watchdog manager) services and library functions



page id: 94jui

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.



page id: 94juq

Architecture – Introduction to Basic Software Module Types Driver (external) External devices are located on the ECU hardware outside the microcontroller. Examples for external 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. - AUTOSAR Confidential 30


page id:94jwx

Architecture – Introduction to Basic Software Module Types Interface An Interface (interface module) contains the functionality to abstract from modules which are architecturally 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).



page id: 94jww

Architecture – Introduction to Basic Software Module Types Handler A handler is a specific interface which controls the concurrent, multiple and asynchronous access 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).



page id: 94j22

Architecture – Introduction to Basic Software Module Types Manager A manager offers specific services for multiple clients. It is needed in all cases where pure handler 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 reliable data storage, data checking, provision of default values etc.



Libraries are a collection of functions for related 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

AUTOSAR Libraries

page id: 99j22

Architecture – Overview of Software Layers Introduction to Libraries

Application Layer Runtime Environment (RTE) Basic Software

ECU Hardware

The following libraries are specified within AUTOSAR:  Fixed point mathematical,  Floating point mathematical,  Interpolation for fixed point data,

 Interpolation for floating point data,  Bit handling,  E2E communication, - AUTOSAR Confidential -

34


 CRC calculation,  Extended functions (e.g. 64bits calculation, filtering, etc.) and  Crypto

page id: 94jt4





Application Layer

RTE Memory Services


Memory HW Abstr.

COM HW Abstr.

System Services

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

Onboard Dev. Abstr.

I/O HW Abstraction

 Communication Drivers CommuniMicroI/O Memory Drivers for ECU onboard (e.g. SPI) and vehicle communication (e.g. CAN). cation controller Drivers Drivers OSI-Layer: Part of Data Link Layer Drivers Drivers  I/O Drivers Microcontroller (µC) Drivers for analog and digital I/O (e.g. ADC, PWM, DIO)  Memory Drivers Drivers for on-chip memory devices (e.g. internal Flash, internal EEPROM) and memory mapped external memory devices (e.g. external Flash)  Microcontroller Drivers Drivers for internal peripherals (e.g. Watchdog, General Purpose Timer) Group of Functions with direct µC access (e.g. Core test) Microcontroller Drivers

Memory Drivers

I/O Drivers

PORT Driver

DIO Driver DIO

ADC


ADC Driver

36

PWM

CCU

OCU

CAN

LIN or SCI

SPI

EEPROM

FLASH

MCU Power & Clock Unit

WDT

GPT


PWM Driver

ICU Driver

OCU Driver

Ethernet Driver

FlexRay Driver

CAN Driver

LIN Driver

SPI Handler Driver

internal EEPROM Driver

internal Flash Driver

RAM Test

Flash Test

Core Test

MCU Driver

Watchdog Driver

GPT Driver

Microcontroller


Software modules of similar type

Software module

internal peripheral device

Complex Drivers

page id: oiu42

Architecture – Content of Software Layers Microcontroller Abstraction Layer

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

The SPIHandlerDriver allows concurrent access of several clients to one or more SPI busses.

I/O HW Abstraction

I/O Drivers

Microcontroller (µC)

To abstract all features of a SPI microcontroller pins dedicated to Chip Select, those shall directly be handled by the SPIHandlerDriver. That means those pins shall not be available in DIO Driver. Example: Onboard Device Abstraction


External Watchdog Driver

External EEPROM Driver


Driver for ext. ADC ASIC

Communication Drivers SPIHandlerDriver

µC



SPI

Driver for ext. I/O ASIC

Complex Drivers

page id: swr42

Architecture – Content of Software Layers Microcontroller Abstraction Layer: SPIHandlerDriver

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

A Complex Driver is a module which implements nonstandardized functionality within the basic software stack.

Injection Control e.g. CCU


µC

e.g. PCP

38

Electric Valve Control


Complex Drivers

Incremental Position Detection

Properties: Implementation: highly µC, ECU and application dependent Upper Interface to SW-Cs: specified and implemented according to AUTOSAR (AUTOSAR interface) Lower interface: restricted access to Standardized Interfaces

Example:

e.g. TPU

Task: Fulfill the special functional and timing requirements for handling complex sensors and actuators


Complex Driver XY

An example is to implement 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.  Injection control  Electric valve control  Incremental position detection

I/O HW Abstraction

I/O Drivers

Complex Drivers

page id: 21112

Architecture – Content of Software Layers Complex Drivers

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

The I/O Hardware Abstraction is a group of modules which abstracts from the location of peripheral I/O devices (on-chip or on-board) and the ECU hardware layout (e.g. µC pin connections and signal level inversions). The I/O Hardware Abstraction does not abstract from the sensors/actuators! The different I/O devices might be accessed via an I/O signal interface.

I/O HW Abstraction

I/O Drivers


Example: I/O Hardware Abstraction

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.

I/O Signal Interface



COM Drivers

ADC Driver

DIO

ADC


µC

DIO Driver

39

SPI


SPIHandler Driver

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)

I/O Drivers

Complex Drivers

page id: ddeaq

Architecture – Content of Software Layers ECU Abstraction: I/O Hardware Abstraction

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

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 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).

CAN Transceiver Driver

Driver for ext. CAN ASIC

I/O Drivers


CAN

µC

CAN Driver


CAN Interface

SPI

40


SPIHandler Driver


Example:

DIO

Properties: Implementation: µC independent, ECU hardware dependent and external device dependent Upper Interface: bus dependent, µC and ECU hardware independent

I/O Drivers


DIO Driver

Task: Provide equal mechanisms to access a bus channel regardless of it‘s location (on-chip / on-board)

I/O HW Abstraction

Complex Drivers

page id: zzttz

Architecture – Content of Software Layers ECU Abstraction: Communication Hardware Abstraction

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

The Memory Hardware Abstraction is a group of modules which abstracts from the location of peripheral memory devices (on-chip or on-board) and the ECU hardware layout. Example: on-chip EEPROM and external EEPROM devices are accessible via the same mechanism. The memory drivers are accessed via memory specific abstraction/emulation modules (e.g. EEPROM Abstraction). By emulating an EEPROM abstraction on top of Flash hardware units a common access via Memory Abstraction Interface to both types of hardware is enabled.

Flash EEPROM Emulation

EEPROM Abstraction


External Flash Driver

COM Drivers

Memory Drivers

Flash

µC

Internal Flash Driver


Memory Abstraction Interface

EEPROM

41


EEPROM Driver


Example:

SPI

Properties: Implementation: µC independent, external device dependent Upper Interface: µC, ECU hardware and memory device independent

I/O Drivers


SPIHandler Driver

Task: Provide equal mechanisms to access internal (on-chip) and external (on-board) memory devices and type of memory hardware (EEPROM, Flash).

I/O HW Abstraction

Complex Drivers

page id: wwwaa

Architecture – Content of Software Layers Scope: Memory Hardware Abstraction

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

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.

I/O HW Abstraction

I/O Drivers


Example: Onboard Device Abstraction Watchdog Interface


COM Drivers


µC

Wdg

42

internal watchdog driver

SPI



SPIHandler Driver

Properties: Implementation: µC independent, external device dependent Upper Interface: µC independent, partly ECU hardware dependent

Complex Drivers

page id: xxdxx

Architecture – Content of Software Layers Onboard Device Abstraction

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

The Communication Services are a group of modules for vehicle network communication (CAN, LIN, FlexRay and Ethernet). They interface with the communication drivers via the communication hardware abstraction.

Example: Communication Services

43


Generic NM Interface

Debugging


Diagnostic Com. Manager

The communication services will be detailed for each relevant vehicle network system on the following pages.

AUTOSAR COM

IPDU Multiplexer

Secure Onboard Communication

E2E Transformer

Large Data COM

Com Based Transformer

Properties: Implementation: µC and ECU HW independent, partly dependent on bus type Upper Interface: µC, ECU hardware and bus type independent

I/O Drivers


SOME/IP Transformer

Task: Provide a uniform interface to the vehicle network for communication. Provide uniform services for network management Provide uniform interface to the vehicle network for diagnostic communication Hide protocol and message properties from the application.

I/O HW Abstraction

Complex Drivers

page id: yyxyy

Architecture – Content of Software Layers Communication Services – General

PDU Router

State Manager

NM

Transport Protocol

Bus specific modules

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

Example: Communication Services Debugging


AUTOSAR COM

Large Data COM


IPDU Multiplexer


CAN State Manager

PDU Router

CAN NM

CAN Transport Protocol

CAN Interface Driver for ext. CAN ASIC

I/O Drivers DIO Driver

µC

Communication Drivers SPIHandler Driver

SPI

CAN Driver

The CAN Communication Services are a group of modules for 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. The CAN Communication Stack supports:  Classic CAN communication (CAN 2.0)  CAN FD communication, if supported by hardware

CAN

External CAN Controller


I/O Drivers




I/O HW Abstraction

Complex Drivers

page id: ppopp

Architecture – Content of Software Layers Communication Stack – CAN


Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

Properties:  Implementation: µC and ECU HW independent, partly dependent on CAN.  AUTOSAR COM, Generic NM (Network Management) 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 can also include the NM coordinator functionality which allows to synchronize multiple different networks (of the same or different types) to synchronously wake them up or shut them down.  CAN NM is specific for CAN networks and will be instantiated per CAN vehicle network system.  The communication system specific Can 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.




I/O HW Abstraction

I/O Drivers

Complex Drivers

page id: bbnnh

Architecture – Content of Software Layers Communication Stack – CAN

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services



AUTOSAR COM

Large Data COM


IPDU Multiplexer


CAN State Manager CAN NM


Communication Hardware Abstraction CAN Interface

DIO Driver

µC

TTCAN


I/O Drivers

The TTCAN Communication Services are the optional extensions 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.


SPI

CAN Driver

TTCAN

TTCAN

Please Note:  The CAN Interface with TTCAN can serve both a plain CAN Driver and a CAN Driver TTCAN.

External TTCAN Controller


I/O Drivers


PDU Router


I/O HW Abstraction


Complex Drivers

page id: qwwwe

Architecture – Content of Software Layers Communication Stack Extension – TTCAN

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

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.




I/O HW Abstraction

I/O Drivers

Complex Drivers

page id: ggghh

Architecture – Content of Software Layers Communication Stack Extension – TTCAN

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

Example: Communication Services

J1939 Transport Protocol

Communication Hardware Abstraction CAN Interface


µC


SPI

External CAN Controller


The J1939 Communication Services extend the plain CAN communication stack for vehicle network communication in heavy duty vehicles. Task:  Provide the protocol services required by J1939. Hide protocol and message properties from the application where not required.

CAN Driver

CAN

Please Note:  There are two transport protocol modules in the CAN stack (CanTp and J1939Tp) which can be used alternatively or in parallel on different channels:. 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 - AUTOSAR Confidential -

48

I/O Drivers


I/O Drivers DIO Driver

J1939 NM

CAN State Manager


J1939 Request Manager

J1939 Diagnostic Com. Manager

Debugging


AUTOSAR COM

Large Data COM IPDU Multiplexer


PDU Router


I/O HW Abstraction

Complex Drivers

page id: ppjfb

Architecture – Content of Software Layers Communication Stack Extension – J1939


Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

Properties:  Implementation: µC and ECU HW independent, based on CAN.  AUTOSAR COM, Generic NM (Network Management) Interface and Diagnostic Communication Manager are the same for all vehicle network systems and exist as one instance per ECU.  Supports dynamic frame identifiers that are not known at configuration time.  J1939 network management handles assignment of unique addresses to each ECU but does not support sleep/wakeup handling and related concepts like partial networking.  Provides J1939 diagnostics and request handling.




I/O HW Abstraction

I/O Drivers

Complex Drivers

page id: bbjfb

Architecture – Content of Software Layers Communication Stack Extension – J1939

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

Example: Communication Services Diagnostic Com. Manager

AUTOSAR COM

Generic NM Interface LIN State Manager

LIN NM PDU Router

I/O HW Abstraction

I/O Drivers


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

Task: Provide a uniform interface to the LIN network. Hide protocol and message properties from the application.

Communication Hardware Abstraction LIN Interface LIN Transceiver Driver

Driver for ext. LIN ASIC

Communication Drivers LIN Driver

µC

SCI

Properties: The LIN Communication Services contain:  A LIN 2.1 compliant communication stack with  Schedule table manager for transmitting LIN frames and to handle 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 specific hardware  Supporting both simple UART and complex frame based LIN hardware - AUTOSAR Confidential -

50

Complex Drivers

page id: 87z66

Architecture – Content of Software Layers Communication Stack – LIN (LIN Master)


Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

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 communication dependent 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 interfacing COM.  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).




I/O HW Abstraction

I/O Drivers

Complex Drivers

page id: 66766

Architecture – Content of Software Layers Communication Stack – LIN

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

LIN Slaves usually are „intelligent“ actuators and slaves that are seen as black boxes. As they provide very little hardware capabilities and resources, it is not intended to shift AUTOSAR SWComponents 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 memory resources or are ASICs with „hard-coded“ logic.

I/O Drivers


Example:

Note: LIN slaves cannot fulfill the requirements to a Debugging Host, since LIN is not a multi-master bus. - AUTOSAR Confidential 52

I/O HW Abstraction


LIN Slave Application

Communication Drivers LIN Communication Stack

µC

SCI

Complex Drivers

page id: 1122d

Architecture – Content of Software Layers Communication Services – LIN Slave

Application Layer

RTE



AUTOSAR COM

Large Data COM



Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


I/O HW Abstraction

I/O Drivers


IPDU Multiplexer


FlexRay State Manager

PDU Router

The FlexRay Communication Services are a group of modules for vehicle network communication with the communication system FlexRay.

FlexRay NM

FlexRay Transport Protocol

Task:  Provide a uniform interface to the FlexRay network. Hide protocol and message properties from the application.

Communication Hardware Abstraction FlexRay Interface

Driver for FlexRay Transceiver

I/O Drivers

DIO Driver

Host µC

Driver for external FlexRay Controller

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


SPIHandlerDriver

Driver for internal FlexRay Controller

Internal FlexRay Controller

Data lines External FlexRay Controller (e.g. MFR 4200)

External FlexRay Transceiver (e.g. TJA 1080)

Control/status lines


Memory Services

System Services

Complex Drivers

page id: ki890

Architecture – Content of Software Layers Communication Stack – FlexRay


Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

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 different networks (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.




I/O HW Abstraction

I/O Drivers

Complex Drivers

page id: 42432

Architecture – Content of Software Layers Communication Stack – FlexRay

Application Layer

RTE



AUTOSAR COM

Large Data COM


IPDU Multiplexer


Ethernet State Manager

UDP NM PDU Router

Socket Adaptor TCP/IP Communication Services

Ethernet Switch Driver Ethernet Transceiver Driver

I/O Drivers

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


I/O Drivers

The TCP/IP Communication Services are a group of modules for vehicle network communication with the communication system TCP/IP.

Communication Drivers Handler / Driver

MII

Ethernet Driver

Ethernet

External Ethernet Controller


Onboard Dev. Abstr.

I/O HW Abstraction

Task:  Provide a uniform interface to the TCP/IP network. Hide protocol and message properties from the application.

Ethernet Interface

µC




DIO Driver

Memory Services

System Services


Complex Drivers

page id: 44566

Architecture – Content of Software Layers Communication Stack – TCP/IP

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

Properties:  The TcpIp module implements the main protocols of the TCP/IP protocol family (TCP, UDP, IPv4, IPv6, ARP, ICMP, DHCP) and provides dynamic, socket based communication via Ethernet.  The Socket Adaptor module (SoAd) is the sole upper layer module of the TcpIp module.




I/O HW Abstraction

I/O Drivers

Complex Drivers

page id: qqeet

Architecture – Content of Software Layers Communication Stack – TCP/IP

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

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).  Multi I-PDU to container mapping provides the possibility to combine several I-PDUs into one larger (container-)I-PDU to be transmitted in one (bus specific) frame.  Upper Interface: µC, ECU hardware and network type independent.  For refinement of GW architecture please refer to “Example Communication”




I/O HW Abstraction

I/O Drivers

Complex Drivers

page id: bbnnq

Architecture – Content of Software Layers Communication Stack – General

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

The Memory Services consist of one module, the NVRAM Manager. It is responsible for the management of non volatile data (read/write from different memory drivers).

Task: 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.


Example: Memory Services

NVRAM Manager

Properties: Implementation: µC and ECU hardware independent, highly configurable Upper Interface: µC and ECU hardware independent specified and implemented according to AUTOSAR (AUTOSAR interface) - AUTOSAR Confidential 58


I/O HW Abstraction

I/O Drivers

Complex Drivers

page id: 9ddff

Architecture – Content of Software Layers Services: Memory Services

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

The System Services are a group of modules and functions which can be used by modules of all layers. Examples are Real Time Operating System (which includes timer services) and Error Manager. Some of these services are:


System Services Basic Software Mode Manager (BswM)

Communication Manager (ComM)

Watchdog Manager (WdgM)

Time Service (Tm)

Synchronized Timebase Manager (StbM)

Crypto Service Manager (Csm)

Diagnostic Log and Trace (Dlt)

ECU State Manager (EcuM)


Default Error Tracer (Det)

Function Inhibition Manager (FiM)

Diagnostic Event Manager (Dem)

AUTOSAR OS

Properties: Implementation: partly µC, ECU hardware and application specific Upper Interface: µC and ECU hardware independent - AUTOSAR Confidential 59

I/O Drivers

Example:

 µC dependent (like OS), and may support special µC capabilities (like Crypto Service Manager),  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.

I/O HW Abstraction

Complex Drivers

page id: qwehg

Architecture – Content of Software Layers Services: System Services

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

Application Layer AUTOSAR Runtime Environment (RTE) Watchdog Manager

System Services

Function Inhibition Manager

Communication Services Diagnostic Communication Manager

I/O HW Abstraction

I/O Drivers

Complex Drivers

page id: 3edfg

Architecture – Content of Software Layers Error Handling, Reporting and Diagnostic


There are dedicated modules for different aspects Diagnostic Log of error handling in AUTOSAR. E.g.: and Trace XCP  The Debugging module supports debugging of Diagnostic Event Manager the AUTOSAR BSW. It interfaces to ECU Communication Onboard Device internal modules and to an external host system Hardware Abstraction via communication . Abstraction Watchdog Interface  The Diagnostic Event Manager is responsible for processing and storing diagnostic events Microcontroller Drivers Communication (errors) and associated FreezeFrame data. Drivers Watchdog Driver  The module Diagnostic Log and Trace supports logging and tracing of applications. It Microcontroller collects user defined log messages and converts them into a standardized format.  All detected development errors in the Basic Software are reported to Default Error Tracer.  The Diagnostic Communication Manager provides a common API for diagnostic services  etc. Default Error Tracer

Debugging



Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

The Sensor/Actuator AUTOSAR Software Component is a specific type of AUTOSAR Software Component for sensor evaluation and actuator control. Though not belonging to the AUTOSAR Basic Software, it is described here due to its strong relationship to local signals. It has been decided to locate the Sensor/Actuator SW Components above the RTE for integration reasons (standardized interface implementation and interface description). Because of their strong interaction with raw local signals, relocatability is restricted.

Example:

Application Layer Actuator Software Component

Sensor Software 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)


I/O Drivers


Task: Provide an abstraction from the specific physical properties of hardware sensors and actuators, which are connected to an ECU. Properties: Implementation: µC and ECU HW independent, sensor and actuator dependent

I/O HW Abstraction


Complex Drivers

page id: xsji8

Architecture – Content of Software Layers Application Layer: Sensor/Actuator Software Components

page id: 94jt4





page id: w111b

Architecture – Content of Software Layers Example of a Layered Software Architecture for Multi-Core Microcontroller

Example: an ECU with a two core microcontroller

ECU core 1:

core 0: partition 0:

partition 1:

Application Layer RTE

System Services

Memory Services

Operating System

Communication Services (Master)

Memory HW Abstraction

COM HW Abstraction


Memory Drivers


BSW Mode Manager

I/O Drivers

Core Test



I/O HW Abstraction


I/O Drivers

Complex Drivers

Onboard Dev. Abstraction

ECU State Manager

Complex Drivers

I/O HW Abstraction

Communication Services (Satellite)

page id: w111e

Architecture – Content of Software Layers Detailed View of Distributed BSW Modules


 BSW modules can be distributed across several partitions and cores. All partitions share the same code.  Modules can either be completely identical on each partition, as shown for the I/O stack in the figure.  As an alternative, they can use coredependent branching to realize different behavior. The Com service in core 1 uses master-satellite communication for processing a call to the service on core 0.  The communication between master and satellite is not standardized. For example, it can be based on functions provided by the BSW scheduler or on shared memory.  The arrows indicate which components are involved in the handling of a service call, depending on the approach to distribution and on the origin of the call.

ECU core 0:

core 1: partition 0: Application Layer RTE Communication Services (Master)

Communication Services (Satellite)

I/O HW Abstraction

I/O HW Abstraction

COM HW Abstraction

I/O Drivers




partition 1:


I/O Drivers

page id: w111f

Architecture – Content of Software Layers Overview of BSW Modules, OS, BswM and EcuM on Multiple Partitions

ECU core 0: partition 0:

core 1: partition 1:

partition 2:

partition 3:

partition 4:

Application Layer RTE BswM

BswM

BswM

EcuM

EcuM

OS

OS Other BSW modules

Other BSW modules

BswM

Other BSW modules


 Basic Software Mode Manager (BswM) in every partition that runs BSW modules  all these partitions are trusted  One EcuM per core (each in a trusted partition)  EcuM on that core that gets started via the boot-loader is the master EcuM  Master EcuM starts all Satellite EcuMs - AUTOSAR Confidential 65


Other BSW modules

BswM

Other BSW modules

Application Layer RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

 The IOC, as shown in the figure, provides communication services which can be accessed by clients which need to communicate across OS-Application boundaries on the same ECU. The IOC is part of the OS.  BSW modules can be executable on several cores, such as the ComM in the figure. The core responsible for executing a service is determined at runtime.  Every core runs a kind of ECU state management.


core 0:

core 1: System Services

System Services

Communication Manager


ECU state management Core 1

AUTOSAR OS

AUTOSAR OS


iOC Inter OsApplication communication

Basic Software Mode Manager

Communication Manager

…

Diagnostic Event Manager

Function Inhibition Manager

Default Error Tracer

ECU State Manager Core 0

iOC Inter OsApplication communication


Microcontroller

I/O HW Abstraction

I/O Drivers

Complex Drivers

page id: w111c

Architecture – Content of Software Layers Scope: Multi-Core System Services

page id: 94jt4





page id: wxy8f

Architecture – Content of Software Layers Overview of AUTOSAR safety handling  AUTOSAR offers a flexible approach to support safety relevant ECUs. Two methods can be used: 1. All BSW modules are developed according to the required ASIL 2. Selected modules are developed according to ASIL. ASIL and non-ASIL modules are separated into different partitions (BSW distribution)

MCU QM Application SW-C

QM Application

SW-C

SW-C

BSW partition – all modules ASIL

OS

BSW modules

Other BSW module BSW modules s

BSW modules

Example for usage of method (1)


SW-C

RTE

Hardware

Note: The partitions are based on OSApplications. The TRUSTED attribute of the OS-Application is not related to ASIL/non-ASIL.

ASIL Application


BSW modules

BSW modules

page id: wxy9f

Architecture – Content of Software Layers AUTOSAR BSW distribution for safety systems  Example of using different BSW partitions  Watchdog stack is placed in a own partition  ASIL and non-ASIL SW-Cs can access WdgM via RTE  Rest of BSW is placed in own partition

MCU QM Application SW-C

QM Application

SW-C

SW-C

ASIL Application SW-C

RTE QM BSW partition

OS

Other Other BSW Other BSW modules BSW modules Other BSW modules modules

ASIL BSW partition Other BSW modul es

WdgM

Other BSW modules WdgIf

Wdg

Hardware



page id: 94jt4





page id: 9dfc8

Architecture Overview of Modules – Implementation Conformance Class 3 - ICC3 This figure shows the mapping of basic software modules to AUTOSAR layers

Application Layer

AUTOSAR Runtime Environment (RTE) System Services

Memory Services

Communication Services Dbg

Dcm

Com

BswM

PduR


I/O Signal Interface

Tp




xxx Interface Fee

Ea

Complex Drivers

Nm

MemIf

WdgIf

SM

IpduM

Xf

EcuM

AUTOSAR OS


SecOC

ComM

WdgM

Tm

StbM

Csm

Dlt

Det

FiM

Dem

Nm If

NvM



Memory Drivers

Trcv.

ext. Drv


I/O Drivers Port

Dio

Adc

Pwm

Icu

Ocu

Eth

Fr

Can

Lin

Spi

Eep

Fls

RamTst

FlsTst

CorTst

Mcu

Wdg

Gpt

Microcontroller Not all modules are shown here - AUTOSAR Confidential 71


page id: 92jc9

Architecture Overview of Modules – Implementation Conformance Classes – ICC2 The clustering shown in this document is the one defined by the project so far. AUTOSAR is currently not restricting the clustering on ICC2 level to dedicated clusters as many different constraint and optimization criteria might lead to different ICC2 clusterings. There might be different AUTOSAR ICC2 clusterings against which compliancy can be stated based on a to be defined approach for ICC2 compliance.

Application Layer

AUTOSAR Runtime Environment …

Com Services

*

COM PDU Router

O S

CAN

…

CAN St Mgr

…

CAN TP

CAN NM

…

..

CAN Interface

CAN Driver

ECU Hardware

…



ICC3 module

ICC2 clusters

page id: 94t21

Architecture Overview of Modules – Implementation Conformance Classes – ICC1 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.

Application Layer

AUTOSAR Runtime Environment Proprietary software

ECU Hardware



page id: 94p21

Architecture Overview of Modules – Implementation Conformance Classes – behavior to the outside Basic software (including the RTE) which is AUTOSAR compliant (ICC1-3) has to behave to the outside as specified by the ICC3 module specification. For example the behavior towards:  buses,  boot loaders and  Applications Additionally, the ICC1/2 configuration shall be compatible regarding the system description as in ICC3.

Application Layer

AUTOSAR Runtime Environment Basic Software

ECU Hardware

ICC 3 compliant behavior - AUTOSAR Confidential 74


page id: 94jt4





page id: tz76a

Interfaces Type of Interfaces in AUTOSAR

AUTOSAR Interface

An "AUTOSAR Interface" defines the information exchanged between software components and/or BSW modules. This description is independent 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 SoftwareComponents 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 Basic Software 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 programming language (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. - AUTOSAR Confidential -

76


page id: 94ju5

Interfaces Components and interfaces view (simplified)

AUTOSAR Software Component

Application Software Component

Actuator Software Component

Sensor Software Component

AUTOSAR Interface

AUTOSAR Interface

AUTOSAR Interface

Interface

AUTOSAR Software

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

Application Software Component AUTOSAR Interface

AUTOSAR Runtime Environment (RTE) Standard Software

Interfaces:


VFB & RTE relevant

BSW relevant Possible interfaces inside Basic Software (which are not specified within AUTOSAR)

Operating System


RTE relevant

Standardized AUTOSAR Interface


AUTOSAR Interface

Services

Communication

ECU Abstraction




Complex Drivers

Basic Software ECU-Hardware

Note: This figure is incomplete with respect to the possible interactions between the layers. - AUTOSAR Confidential 77

AUTOSAR Interface



Microcontroller Abstraction

page id: a6ztr

Interfaces: General Rules General Interfacing Rules Horizontal Interfaces

Vertical Interfaces

Services Layer: horizontal interfaces are allowed Example: Error Manager saves fault data using the NVRAM manager

One Layer may access all interfaces of the SW layer below

ECU Abstraction Layer: horizontal interfaces are allowed

Bypassing of one software layer should be avoided

A complex driver may use selected other BSW modules

Bypassing of two or more software layers is not allowed

µC Abstraction Layer: horizontal interfaces are not allowed. Exception: configurable notifications are allowed due to performance reasons.

Bypassing of the µC Abstraction Layer is not allowed

AUTOSAR

AUTOSAR

AUTOSAR

AUTOSAR

SW Comp 1

SW Comp 3

SW Comp 4

SW Comp 5

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.




(gray background indicates “nonBasic Software” layers)

                            restricted access -> see the                            

            following two            

Microcontroller Drivers Memory Drivers Communication Drivers

  

  

  

  

  

  

  

  

 

I/O Drivers


















I/O Drivers


Memory Drivers






AUTOSAR SW Components / RTE System Services Memory Services Communication Services Complex Drivers I/O Hardware Abstraction Onboard Device Abstraction Memory Hardware Abstraction Communication Hardware Abstraction


Complex Drivers

The matrix is read rowwise: Example: “I/O Drivers are allowed to use System Services and Hardware, but no other layers”.

uses


 “is allowed to use”  ”is not allowed to use”  “restricted use (callback only)”

Memory Services

This matrix shows the possible interactions between AUTOSAR Basic Software layers

System Services

page id: 1xdfr

Interfaces: General Rules Layer Interaction Matrix

        slides        



 

  

 

 





 

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

Complex Drivers may need to interface to other modules in the layered software architecture, or modules in the layered software architecture may need to interface to a Complex Driver. If this is the case, the following rules apply:

I/O HW Abstraction

I/O Drivers


1. Interfacing from modules of the layered software architecture to Complex Drivers This is only allowed if the Complex Driver offers an interface which can be generically configured by the accessing AUTOSAR module. A typical example is the PDU Router: a Complex Driver may implement the interface module of a new bus system. This is already taken care of within the configuration of the PDU Router. 2. Interfacing from a Complex Driver to modules of the layered software architecture Again, this is only allowed if the respective modules of the layered software architecture offer the interfaces, and are prepared to be accessed by a Complex Driver. Usually this means that  The respective interfaces are defined to be re-entrant.  If call back routines are used, the names are configurable  No upper module exists which does a management of states of the module (parallel access would change states without being noticed by the upper module) - AUTOSAR Confidential 80


Complex Drivers

page id: 11122

Interfaces Interfacing with Complex Drivers (1)

Application Layer

RTE System Services

Memory Services


I/O HW Abstraction

In general, it is possible to access the following modules: Onboard Memory COM HW Dev. Abstr. HW Abstr. Abstr.  The SPI driver CommuniMicroI/O Memory cation controller  The GPT driver Drivers Drivers Drivers Drivers  The I/O drivers with the restriction that re-entrancy often only exists for Microcontroller (µC) separate groups/channels/etc. Parallel access to the same group/channel/etc. is mostly not allowed. This has to be taken care of during configuration.  The NVRAM Manager as exclusive access point to the memory stack  The Watchdog Manager as exclusive access point to the watchdog stack  The PDU Router as exclusive bus and protocol independent access point to the communication stack  The bus specific interface modules as exclusive bus specific access point to the communication stack  The NM Interface Module as exclusive access point to the network management stack  The Communication Manager (only from upper layer) and the Basic Software Mode Manager as exclusive access points to state management  Det, Dem and Dlt  The OS as long as the used OS objects are not used by a module of the layered software architecture Still, for each module it is necessary to check if the respective function is marked as being re-entrant. For example, ‘init’ functions are usually not re-entrant and should only be called by the ECU State Manager.



Complex Drivers

page id: 11123


Application Layer

RTE System Services

Memory Services


I/O HW Abstraction

Complex Drivers

page id: q1123


In case of multi-core architectures, there are additional rules: Onboard Memory COM HW Dev. Abstr. HW Abstr. Abstr.  The BSW can be distributed across several cores. The core CommuniMicroI/O Memory responsible for executing a call to a BSW service is determined cation controller Drivers Drivers Drivers Drivers by the task mapping of its BswOperationInvokedEvent. Microcontroller (µC)  Crossing partition and core boundaries is permitted for module internal communication only, using a master/satellite implementation.  Consequently, if the CDD needs to access standardized interfaces of the BSW, it needs to reside on the same core.  In case a CDD resides on a different core, it can use the normal port mechanism to access AUTOSAR interfaces and standardized AUTOSAR interfaces. This invokes the RTE, which uses the IOC mechanism of the operating system to transfer requests to the other core.  However, if the CDD needs to access standardized interfaces of the BSW and does not reside on the same core,  either a satellite providing the standardized interface can run on the core where the CDD resides and forward the call to the other core  or a stub part of the CDD needs to be implemented on the other core, and communication needs to be organized CDD-local using the IOC mechanism of the operating system similar to what the RTE does.  Additionally, in the latter case the initialization part of the CDD also needs to reside in the stub part on the different core.



page id: 94jt4





page id: 2wfr5

Interfaces: Interaction of Layers – Example “Memory” Introduction The following pages explain using the example „memory“:  How do the software layers interact?

 How do the software interfaces look like?  What is inside the ECU Abstraction Layer?  How can abstraction layers be implemented efficiently?



page id: 99876

Interfaces: Interaction of Layers – Example “Memory” Example and First Look This example shows how the NVRAM Manager and the Watchdog Manager interact with drivers on an assumed hardware configuration: The ECU hardware includes an external EEPROM and an external watchdog connected to the microcontroller via the same SPI. The SPIHandlerDriver controls the concurrent access to the SPI hardware and has to give the watchdog access a higher priority than the EEPROM access.

System Services

Memory Services

Watchdog Manager

NVRAM Manager


Memory Hardware Abstraction Memory Abstraction Interface

Watchdog Interface




The Memory Abstraction Interface can be realized in the following ways:  routing during runtime based on device index (int/ext)  routing during runtime based on the block index (e.g. > 0x01FF = external EEPROM)  routing during configuration time via ROM tables with function pointers inside the NVRAM Manager (in this case the Memory Abstraction Interface only exists „virtually“)

COM Drivers

Memory Drivers

SPIHandlerDriver

Internal Flash Driver

SPI

Flash

µC

External Watchdog

- AUTOSAR Confidential Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

Fls_Read() Fls_Write()

Spi_ReadIB() Spi_WriteIB()

CS

85

Fee_Read() Fee_Write()

EEPROM Abstraction

Wdg_Trigger()

The microcontroller includes also an internal flash which is used in parallel to the external EEPROM. The EEPROM Abstraction and the Flash EEPROM Emulation have an API that is semantically identical.

MemIf_Read() MemIf_Write()

WdgIf_Trigger()

SPI

CS External EEPROM

SPI

page id: 1ase4

Interfaces: Interaction of Layers – Example “Memory” Closer Look at Memory Hardware Abstraction Architecture Description The NVRAM Manager accesses drivers via the Memory Abstraction Interface. It addresses different memory devices using a device index.

Nvm_Write(BlockIndex) Memory Services

Interface Description The Memory Abstraction Interface could have the following interface (e.g. for the write function):

NVRAM Manager

MemIf_Write( DeviceIndex, BlockNumber, DataBufferPtr)

Std_ReturnType MemIf_Write ( uint8 DeviceIndex, uint16 BlockNumber, uint8 *DataBufferPtr )

Memory Hardware Abstraction Memory Abstraction Interface

Ea_Write( BlockNumber, DataBufferPtr)

The EEPROM Abstraction as well as the Flash EEPROM Emulation could have the following interface (e.g. for the write function):

EEPROM Abstaction

Std_ReturnType Ea_Write ( uint16 BlockNumber, uint8 *DataBufferPtr )



Fee_Write( BlockNumber, DataBufferPtr)


page id: wfgz7

Interfaces: Interaction of Layers – Example “Memory” Implementation of Memory Abstraction Interface Situation 1: only one NV device type used This is the usual use case. In this situation, the Memory Abstraction can, in case of source code availability, be implemented as a simple macro which neglects the DeviceIndex parameter. The following example shows the write function only:

File MemIf.h: #include “Ea.h“ /* for providing access to the EEPROM Abstraction */ ... #define MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr) \ Ea_Write(BlockNumber, DataBufferPtr)

File MemIf.c: Does not exist

Result: No additional code at runtime, the NVRAM Manager virtually accesses the EEPROM Abstraction or the Flash Emulation directly. - AUTOSAR Confidential 87


page id: 12345

Interfaces: Interaction of Layers – Example “Memory” Implementation of Memory Abstraction Interface Situation 2: two or more different types of NV devices used In this case the DeviceIndex has to be used for selecting the correct NV device. The implementation can also be very efficient by using an array of pointers to function. The following example shows the write function only: File MemIf.h: extern const WriteFctPtrType WriteFctPtr[2]; #define MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr) \ WriteFctPtr[DeviceIndex](BlockNumber, DataBufferPtr)

File MemIf.c: #include “Ea.h“ #include “Fee.h“ #include “MemIf.h“

/* for getting the API function addresses */ /* for getting the API function addresses */ /* for getting the WriteFctPtrType */

const WriteFctPtrType WriteFctPtr[2] = {Ea_Write, Fee_Write};

Result: The same code and runtime is needed as if the function pointer tables would be inside the NVRAM Manager. The Memory Abstraction Interface causes no overhead. - AUTOSAR Confidential 88


page id: wwwee

Interfaces: Interaction of Layers – Example “Memory” Conclusion Conclusions:  Abstraction Layers can be implemented very efficiently

 Abstraction Layers can be scaled  The Memory Abstraction Interface eases the access of the NVRAM Manager to one or more EEPROM and Flash devices



page id: 10zow

Interfaces: Interaction of Layers – Example “Communication” PDU Flow through the Layered Architecture Layer N+1

 Explanation of terms:

data structure

 SDU SDU is the abbreviation of “Service Data Unit”. It is the data passed by an upper layer, with the request to transmit the data. It is as well the data which is extracted after reception by the lower layer and passed to the upper layer. A SDU is part of a PDU.

PDU

LayerN_Tx(*PDU);

void LayerN_Tx(*SDU); Layer N PCI

data structure

PCI

data structure

SDU PDU

LayerN+1_Tx(*PDU);

 PCI PCI is the abbreviation of “Protocol Control Information”. This Information is needed to pass a SDU from one instance of a specific protocol layer to another instance. E.g. it contains source and target information. The PCI is added by a protocol layer on the transmission side and is removed again on the receiving side.

void LayerN+1_Tx(*SDU); Layer N-1 PCI

data structure

TP PCI

 PDU PDU is the abbreviation of “Protocol Data Unit”. The PDU contains SDU and PCI. On the transmission side the PDU is passed from the upper layer to the lower layer, which interprets this PDU as its SDU.

PCI

data structure

CAN IF PCI


data structure


data structure

SDU

SDU PDU

Application Layer RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

SDU and PDU Naming Conventions The naming of PDUs and SDUs respects the following rules: For PDU: - PDU For SDU: - SDU The bus prefix and layer prefix are described in the following table: ISO Layer

91

I/O Drivers


Layer Prefix

AUTOSAR Modules

PDU Name

Layer 6: Presentation (Interaction)

I

COM, DCM

I-PDU

N/A

I

PDU router, PDU multiplexer

I-PDU

N/A

Layer 3: Network Layer

N

TP Layer

N-PDU

CAN SF CAN FF CAN CF CAN FC

LIN SF LIN FF LIN CF LIN FC

FR SF FR FF FR CF FR FC

Layer 2: Data Link Layer

L

Driver, Interface

L-PDU

CAN

LIN

FR

Examples: I-PDU or I-SDU CAN FF N-PDU or FR CF N-SDU LIN L-PDU or FR L-SDU

CAN / TTCAN prefix

I/O HW Abstraction

Complex Drivers

page id: 94j42

Interfaces: Interaction of Layers Example “Communication” (1)

LIN prefix

FlexRay prefix

SF: Single Frame FF: First Frame CF: Consecutive Frame FC: Flow Control

For details on the frame types, please refer to the AUTOSAR Transport Protocol specifications for CAN,TTCAN, LIN and FlexRay. - AUTOSAR Confidential Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: 5udw1

Interfaces: Interaction of Layers Example “Communication” (2) Components  PDU Router:  Provides routing of PDUs between different abstract communication controllers and upper layers  Scale of the Router is ECU specific (down to no size if e.g. only one communication controller exists)  Provides TP routing on-the-fly. Transfer of TP data is started before full TP data is buffered  COM:  Provides routing of individual signals or groups of signals between different I-PDUs  NM Coordinator:  Synchronization of Network States of different communication channels connected to an ECU via the network managements handled by the NM Coordinator  Communication State Managers:  Start and Shutdown the hardware units of the communication systems via the interfaces  Control PDU groups



page id: 3hd8w

Interfaces: Interaction of Layers Example “Communication” (3) RTE Communication Manager

Signals


IPDU Multiplexer

I-PDU

I-PDU

AUTOSAR COM

Diagnostic Communication Manager

I-PDU

I-PDU

Debugging

Eth State Manager

FlexRay State Manager

TTCAN State Manager

CAN State Manager

LIN State Manager

Generic NM interface NM Coordinator

I-PDU

XCP

PDU Router Ethernet Protocol I-PDU

See description on next slide

I-PDU1

I-PDU

I-PDU1

I-PDU1

NM NM Module NM Module NM Module Module

I-PDU

CAN Tp FlexRay Tp N-PDU

Eth Interface

FlexRay Interface

L-PDU

L-PDU

J1939Tp N-PDU

CAN Interface2 L-PDU

N-PDU

Communication HW Abstraction

LIN Interface (incl. LIN TP) L-PDU

Communication Drivers Eth Driver

Note: This image is not complete with respect to all internal communication paths.

FlexRay Driver

CAN Driver2

1 The

Interface between PduR and Tp differs significantly compared to the interface between PduR and the Ifs. In case of TP involvement a handshake mechanism is implemented allowing the transmission of I-Pdus > Frame size. 2 CanIf with TTCAN serves both CanDrv with or without TTCAN. CanIf without TTCAN cannot serve CanDrv with TTCAN.


LIN Low Level Driver


 This figure shows the interaction of and inside the Ethernet protocol stack.

BswM

PDU Router I-PDUs

Sd

DoIP I-PDUs

I-PDUs

UDP NM

Socket Adaptor Messages

Streams

DHCP TCP

UDP Packet

Segment

IPv4/v6 ARP/ND

ICMP Datagram

Eth Interface

TCP/IP Communication Services

page id: eed8w

Interfaces: Interaction of Layers Example “Communication” (4) – Ethernet Protocol

Communication HW Abstraction

Eth. Frame

Communication Drivers Eth Driver



page id: srs11

Interfaces: Interaction of Layers Example “Data Transformation” (1) – Introduction The following pages explain communication with Data Transformation:  How do the software layers interact?

 How do the software interfaces look like?



page id: srs12

Interfaces: Interaction of Layers Example “Data Transformation” (2) – Example and First Look This example shows the data flow if data transformation is used for inter-ECU communication. SW-C

Application Layer

A SW-C sends data configured to be transmitted to a remote ECU and subject to data transformation. This data transformation doesn’t use in-place buffer handling.

Functionality  The RTE calls the SOME/IP transformer as the first transformer in the chain and transfers the data from the SW-C.  The SOME/IP transformer executes the transformation and writes the output (byte array) to a buffer provided by the RTE.  Afterwards, the RTE executes the Safety transformer which is second in the transformer chain. The Safety transformer’s input is the output of the SOME/IP transformer.  The Safety transformer protects the data and writes the output into another buffer provided by the RTE. A new buffer is required because in-place buffer handling is not used.  The RTE transfers the final output data as a byte array to the COM module.

Transformer Coordination Buffer 1

SOME/IP Transformer



E2E Transformer

RTE

Buffer 2

AUTOSAR COM

page id: srs13

Interfaces: Interaction of Layers Example “Data Transformation” (3) – Closer Look at Interfaces Architecture Description The RTE uses the transformer which are located in the System Service Layer.

SW-C

Rte_Write(data)

Interface Description The transformers in this example have the following interfaces:


Buffer 1

SomeIpXf_SOMEIP_Signal1 ( uint8 *buffer1, uint16 *buffer1Length, data )

SomeIpXf_SOMEIP_Signal1 ( buffer1, &buffer1Length, data )

SafetyXf_Safety_Signal1 ( uint8 *buffer2, uint16 *buffer2Length, uint8 *buffer1, uint16 buffer1Length )

SOME/IP Transformer



SafetyXf_Safety_Signal1 ( buffer2, &buffer2Length, buffer1, buffer1Length )

E2E Transformer

RTE

Com_SendDynSignal ( Signal1, buffer2, buffer2Length )

AUTOSAR COM

page id: srs14

Interfaces: Interaction of Layers Example “Data Transformation” (4) – COM Based Transformation Goal The COM Based Transformer provides serialization functionality to the transformer chain based on a fixed communication matrix. The fixed communication matrix allows an optimized placement of signals into PDUs (e.g. a boolean data can be configured to only occupy one bit in the PDU). This enables the usage of transformer chains in low payload networks like Can or Lin. Functionality  The COM Based Transformer is the first transformer (serializer) and gets the data from the application via the RTE.  Based on the COM configuration (communication matrix) the data is serialized exactly in the same way as the COM module would have done it (endianess, sign extension).  Other transformers may enhance the payload to have CRCs and sequence counters (SC).  The transformer payload is passed to the COM module as one array of byte via the Com_SendSignalGroupArray API.  The COM module can be configured to perform transmission mode selection based on the communication matrix definition.

SW-C


Com Based Transformer

CRC

SC

Signal Pdu - AUTOSAR Confidential 98

Application Layer


RTE

Buffer 2

Other Transformer

D 1

AUTOSAR COM

D D 2 3

D 4

page id: 94kt4





page id: 9000a

Configuration Overview The AUTOSAR Basic Software supports the following configuration classes: 1. Pre-compile time  Preprocessor instructions  Code generation (selection or synthetization) 2. Link time  Constant data outside the module; the data can be configured after the module has been compiled 3. Post-build time  Loadable constant data outside the module. Very similar to [2], but the data is located in a specific memory segment that allows reloading (e.g. reflashing in ECU production line) Independent of the configuration class, single or multiple configuration sets can be provided by means of variation points. In case that multiple configuration sets are provided, the actually used configuration set is to be chosen at runtime in case the variation points are bound at run-time.

In many cases, the configuration parameters of one module will be of different configuration classes. Example: a module providing Post-build time configuration parameters will still have some parameters that are Pre-compile time configurable. Note: Multiple configuration sets were modeled as a sub class of the Post-build time configuration class up to AUTOSAR 4.1.x. - AUTOSAR Confidential 100


page id: 9000b

Configuration Pre-compile time (1) Use cases Pre-compile time configuration would be chosen for  Enabling/disabling optional functionality This allows to exclude parts of the source code that are not needed  Optimization of performance and code size Using #defines results in most cases in more efficient code than access to constants or even access to constants via pointers. Generated code avoids code and runtime overhead. Restrictions  The module must be available as source code  The configuration is static and it may consist of one or more configuration sets identified by means of variation points. To update any configuration set (e.g. change the value of certain parameters), the module has to be recompiled. Nm_Cfg.c

Required implementation Pre-compile time configuration shall be done via the module‘s two configuration files (*_Cfg.h, *_Cfg.c) and/or by code generation:  *_Cfg.h stores e.g. macros and/or #defines  *_Cfg.c stores e.g. constants - AUTOSAR Confidential 101


Nm_Cfg.h

uses (optional)

includes Nm.c

page id: 9000c

Configuration Pre-compile time (2) Example 1: Enabling/disabling functionality File Spi_Cfg.h: #define SPI_DEV_ERROR_DETECT ON File Spi_Cfg.c: const uint8 myconstant = 1U;

File Spi.c (available as source code): #include "Spi_Cfg.h" /* for importing the configuration parameters */ extern const uint8 myconstant; #if (SPI_DEV_ERROR_DETECT == ON) Det_ReportError(Spi_ModuleId, 0U, 3U, SPI_E_PARAM_LENGTH); #endif

/* only one instance available */

Note: The Compiler Abstraction and Memory Abstraction (as specified by AUTOSAR) are not used to keep the example simple.



page id: 9000d

Configuration Pre-compile time (3) Example 2: Event IDs reported to the Dem XML configuration file of the NVRAM Manager: Specifies that it needs the event symbol NVM_E_REQ_FAILED for production error reporting. File Dem_Cfg.h (generated by Dem configuration tool): typedef uint8 Dem_EventIdType; /* total number of events = 46 => uint8 sufficient */ #define #define #define #define #define #define ...

DemConf_DemEventParameter_FLS_E_ERASE_FAILED_0 DemConf_DemEventParameter_FLS_E_ERASE_FAILED_1 DemConf_DemEventParameter_FLS_E_WRITE_FAILED_0 DemConf_DemEventParameter_FLS_E_WRITE_FAILED_1 DemConf_DemEventParameter_NVM_E_REQ_FAILED DemConf_DemEventParameter_CANSM_E_BUS_OFF

1U 2U 3U 4U 5U 6U

Example for a multiple instance driver (e.g. internal and external flash module)

File Dem.h: #include "Dem_Cfg.h" /* for providing access to event symbols */ File NvM.c (available as source code): #include "Dem.h" /* for reporting production errors

*/

Dem_ReportErrorStatus(DemConf_DemEventParameter_NVM_E_REQ_FAILED, DEM_EVENT_STATUS_PASSED);



page id: 9000e

Configuration Link time (1) Use cases Link time configuration would be chosen for  Configuration of modules that are only available as object code (e.g. IP protection or warranty reasons)  Creation of configuration after compilation but before linking.

Required implementation 1. 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. 2. 2..n configuration sets, runtime selection possible Configuration data shall be captured within external constant structs. The module gets a pointer to one of those structs at initialization time. The struct can be selected at each initialization.



page id: 9000f

Configuration Link time (2) Example 1: Event IDs reported to the Dem by a multiple instantiated module (Flash Driver) only available as object code XML configuration file of the Flash Driver: Specifies that it needs the event symbol FLS_E_WRITE_FAILED for production error reporting. File Dem_Cfg.h (generated by Dem configuration tool): typedef uint16 Dem_EventIdType; /* total number of events = 380 => uint16 required */ #define #define #define #define #define #define ...

DemConf_DemEventParameter_FLS_E_ERASE_FAILED_0 DemConf_DemEventParameter_FLS_E_ERASE_FAILED_1 DemConf_DemEventParameter_FLS_E_WRITE_FAILED_0 DemConf_DemEventParameter_FLS_E_WRITE_FAILED_1 DemConf_DemEventParameter_NVM_E_REQ_FAILED DemConf_DemEventParameter_CANSM_E_BUS_OFF

File Fls_Lcfg.c: #include "Dem_Cfg.h"

1U 2U 3U 4U 5U 6U

/* for providing access to event symbols */

const Dem_EventIdType Fls_WriteFailed[2] = {DemConf_DemEventParameter_FLS_E_WRITE_FAILED_1, DemConf_DemEventParameter_FLS_E_WRITE_FAILED_2};

File Fls.c (available as object code): #include "Dem.h" /* for reporting production errors extern const Dem_EventIdType Fls_WriteFailed[];

*/

Dem_ReportErrorStatus(Fls_WriteFailed[instance], DEM_EVENT_STATUS_FAILED); Note: the complete include file structure with all forward declarations is not shown here to keep the example simple. - AUTOSAR Confidential 105


page id: y000g

Configuration Link time (3) Example 2: Event IDs reported to the Dem by a module (Flash Driver) that is available as object code only Problem Dem_EventIdType is also generated depending of the total number of event IDs on this ECU. In this example it is represented as uint16. The Flash Driver uses this type, but is only available as object code. Solution In the contract phase of the ECU development, a bunch of variable types (including Dem_EventIdType) have to be fixed and distributed for each ECU. The object code suppliers have to use those types for their compilation and deliver the object code using the correct types.



page id: y000h

Configuration Post-build time (1) Use cases Post-build time configuration would be chosen for  Configuration of data where only the 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 (e.g. end of line, during test & calibration)  Reusability of ECUs across different car versions (same application, different configuration), e.g. ECU in a low-cost car version may transmit less signals on the bus than the same ECU in a luxury car version. Restrictions  Implementation requires storing all possibly relevant configuration items in a flashable area and requires pointer dereferencing upon config access. Implementation precludes generation of code, which has impact on performance, code and data size. Required implementation 1. One configuration set, no runtime selection Configuration data shall be captured in external constant structs. These external structs are located in a separate memory segment that can be individually reloaded. The module gets a pointer to a base struct at initialization time. 2. 2..n configuration sets, runtime selection possible Configuration data shall be captured within external constant structs. These external structs are located in a separate memory segment that can be individually reloaded. The module gets a pointer to one of several base structs at initialization time. The struct can be selected at each initialization.



page id: y000i

Configuration Post-build time (2) Example 1 If the configuration data is fix in memory size and position, the module has direct access to these external structs.

PduR.c

Compiler

Linker

PduR.o Direct access (via reference as given by the pointer parameter of PduR’s initialization function)

Linker control file

PduR_PBcfg.c

Compiler

Linker

PduR_PBcfg.o



page id: y000k

Configuration Post-build time (3) Required implementation 2: Configuration of CAN Driver that is available as object code only; a configuration set can be selected out of multiple configuration sets during initialization time. File Can_PBcfg.c: #include “Can.h” /* for getting Can_ConfigType const Can_ConfigType MySimpleCanConfig [2] = { { Can_BitTiming = 0xDF, Can_AcceptanceMask1 = 0xFFFFFFFF, Can_AcceptanceMask2 = 0xFFFFFFFF, Can_AcceptanceMask3 = 0x00034DFF, Can_AcceptanceMask4 = 0x00FF0000 }, { … } };

*/

Compiler

File EcuM.c: #include “Can.h“ /* for initializing the CAN Driver */ Can_Init(&MySimpleCanConfig[0]);

File Can.c (available as object code): #include “Can.h“ /* for getting Can_ConfigType

*/

void Can_Init(Can_ConfigType* Config) { /* write the init data to the CAN HW */ };

Binary file


Linker


page id: y000m

Configuration Variants Different use cases require different kinds of configurability. Therefore the following configuration variants are provided:  VARIANT-PRE-COMPILE Only parameters with "Pre-compile time" configuration are allowed in this variant.  VARIANT-LINK-TIME Only parameters with "Pre-compile time" and "Link time" are allowed in this variant.  VARIANT-POST-BUILD Parameters with "Pre-compile time", "Link time" and "Post-build time" are allowed in this variant. Example use cases:  Reprogrammable PDU routing tables in gateway (Post-build time configurable PDU Router required)  Statically configured PDU routing with no overhead (Pre-compile time configuration of PDU Router required) To allow the implementation of such different use cases in each BSW module, up to 3 variants can be specified:  A variant is a dedicated assignment of the configuration parameters of a module to configuration classes  Within a variant a configuration parameter can be assigned to only ONE configuration class  Within a variant a configuration class for different configuration parameters can be different (e.g. PreCompile for development error detection and post-build for reprogrammable PDU routing tables  It is possible and intended that specific configuration parameters are assigned to the same configuration class for all variants (e.g. development error detection is in general Pre-compile time configurable). - AUTOSAR Confidential 110


page id: y000n

Configuration Memory Layout Example: Post-build configuration EcuM defines the index: 0x8000

&index (=0x8000)

0x8000

&xx_configuration = 0x4710

0x8002

&yy_configuration = 0x4720

0x8004

&zz_configuration = 0x4730

Description where to find what is an overall agreement: 1. EcuM needs to know all addresses including index 2. The modules (xx, yy, zz) need to know their own start address: in this case: 0x4710, 0x4720 … 3. The start addresses might be dynamic i.e. changes with new configuration 4. When initializing a module (e.g. xx, yy, zz), EcuM passes the base address of the configuration data (e.g. 0x4710, 0x4720, 0x4730) to the module to allow for variable sizes of the configuration data.

…

Xx defines the modules configuration data: 0x4710

&the_real_xx_configuration

0x4710

lower = 2

0x4712

upper =7

0x4714

more_data

…

Yy defines the modules configuration data: 0x4720

&the_real_yy_configuration

0x4720

Xx_data1=0815

0x4722

Yy_data2=4711

0x4724

more_data

The module data is agreed locally (in the module) only 1. The module (xx, yy) knows its own start address (to enable the implementer to allocate data section) 2. Only the module (xx, yy) knows the internals of its own configuration

…



page id: axcvb

Configuration Memory Layout Example: Multiple configuration sets 0x8000 FL

&index[] (=0x8000)

0x8000


0x8002


0x8004


… FR

0x8008


0x800a


0x800c


…

RL

0x8010

&xx_configuration = …

0x8012

&yy_configuration = …

0x8014

&zz_configuration = …

As before, the description where to find what is an overall agreement 1. The index contains more than one description (FL, FR,..) in an array (here the size of an array element is agreed to be 8) 2. There is an agreed variable containing the position of one description selector = CheckPinCombination() 3. Instead of passing the pointer directly there is one indirection: (struct EcuM_ConfigType *) &index[selector]; 4. Everything else works as in conventional single configuration case.

…



page id: 94mt4

Table of contents 1. Architecture 2. Configuration 3. Integration and Runtime Aspects 1. Mapping of Runnables 2. Partitioning 3. Scheduling 4. Mode Management 5. Error Handling, Reporting and Diagnostic 6. Debugging 7. Measurement and Calibration 8. Functional Safety 9. Security 10. Energy Management 11. Global Time Synchronization



page id: 11eer

Integration and Runtime Aspects Mapping of Runnables

VFBview

SW-C

1

Runnable

0..*

0..* 1

Task 0..* 1

1

Partition

1

1

OS-Application 0..*

1 0..* BSW-Ressource (E.g., NV-block)


0..*


1 µC-Core

Implementation/ECU-view

 Runnables are the active parts of Software Components  They can be executed concurrently, by mapping them to different Tasks.  The figure shows further entities like OSapplications, Partitions, µC-Cores and BSWResources which have to be considered for this mapping.

page id: 94lt4




page id: wweev

Integration and Runtime Aspects - Partitioning Introduction  Partitioning is implemented by using OS-Applications within the OS  OS-Applications are used as error containment regions:  Permit logical grouping of SW-Cs and resources  Recovery policies defined individually for each OS-Application  OS-Application consistency is ensured by the system/platform, for instance for:  Memory access violation  Time budget violation  OS-Applications can be terminated or restarted during run-time as a result of a detected error:  Further actions required: see example on following slides  All BSW modules are placed in privileged OS-Applications  These OS-Applications should not be restarted or terminated  OS-Applications are configured in the ECU configuration:  SW-Cs are mapped to OS-Applications (Consequence: restricts runnable to task mapping)  An OS-Application can be configured as restartable or not  Communication across OS-Application boundaries is realized by the IOC - AUTOSAR Confidential 116


page id: wweeu

Integration and Runtime Aspects - Partitioning Example of restarting OS-Application SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

A violation (error) has occurred in the system (e.g., memory or timing violation) Decision (by integrator code) to restart the OS-Application Other OS-Applications remain unaffected

RTE

The OS-Application is terminated by the OS, cleanup possible SW-C

SW-C

SW-C

Communication to the OS-Application is stopped SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

Communication from the OS-Application is stopped (e.g., default values for ports used)

RTE

SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

SW-C

Communication to the OS-Application is stopped Communication from the OS-Application is stopped

RTE

SW-C

The OS-Application is restarting (integrator code), initial environment for OS-Application setup (init runnables, port values etc)

SW-C

SW-C

SW-C

The OS-Application is restarted and up and running

Communication is restored OS-Application internally handles state consistency

RTE 117

- AUTOSAR Confidential Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture

page id: wweet

Integration and Runtime Aspects - Partitioning Involved components  Protection Hook  Executed on protection violation (memory or timing)  Decides what the action is (Terminate, Restart, Shutdown, Nothing)  Provided by integrator  OS acts on decision by inspecting return value  OsRestartTask  Started by OS in case Protection Hook returns Restart  Provided by integrator  Runs in the OS-Application’s context and initiates necessary cleanup and restart activities, such as:  Stopping communication (ComM)  Updating NvM  Informing Watchdog, CDDs etc.

 RTE Functions for performing cleanup and restart of RTE in OS-Application  Triggers init runnables for restarted OS-Application  Handles communication consistency for restarting/terminated OS-Applications  Operating System  OS-Applications have states (APPLICATION_ACCESSIBLE, APPLICATION_RESTART, APPLICATION_TERMINATED)  OS provides API to terminate other OS-Applications (for other errors than memory/timing) 



page id: wwees

Integration and Runtime Aspects - Partitioning restart example

sd TerminateRestartPartition

Os-Application state for the considered Partition.

OS

ProtectionHook

OSRestartTask

RTE

APPLICATION_ACTIVE ProtectionHook inform the RTE

APPLICATION_RESTARTING

ActivateTask Trigger cleanup in the BSW partition

Polling end of asynchronous cleanups request a restart of the partition to the RTE AllowAccess APPLICATION_ACTIVE

TerminateTask



BSW modules

page id: wweer

Integration and Runtime Aspects - Partitioning Other examples  Termination  An OS-Application can be terminated directly  Also for termination, some cleanup may be needed, and this shall be performed in the same way as when restarting an OS-Application  Error detection in applications  SW-Cs may require restart for other reasons than memory or timing violation  A termination/restart can be triggered from a SW-C using the OS service TerminateApplication()  Example: a distributed application requires restart on multiple ECUs



page id: 94nt4




page id: y331a

Integration and Runtime Aspects - Scheduling General Architectural Aspects  Basic Software Scheduler and the RTE are generated together.  This enables  that the same OS Task schedules BSW Main Functions and Runnable Entities of Software Components  to optimize the resource consumption  to configure interlaced execution sequences of Runnable Entities and BSW Main functions. 

a coordinated switching of a Mode affecting BSW Modules and Application Software Components



the synchronized triggering of both, Runnable Entities and BSW Main Functions by the same External Trigger Occurred Event.



page id: y331b

Integration and Runtime Aspects - Scheduling Basic Scheduling Concepts of the BSW BSW Scheduling shall  Assure correct timing behavior of the BSW, i.e., correct interaction of all BSW modules with respect to time Data consistency mechanisms  Applied data consistency mechanisms shall be configured by the ECU/BSW integrator dependent from the configured scheduling.

Single BSW modules do not know about  ECU wide timing dependencies  Scheduling implications  Most efficient way to implement data consistency Centralize the BSW schedule in the BSW Scheduler configured by the ECU/BSW integrator and generated by the RTE generator together with the RTE  Eases the integration task  Enables applying different scheduling strategies to schedulable objects  Preemptive, non-preemptive, ...  Enables applying different data consistency mechanisms  Enables reducing resources (e.g., minimize the number of tasks)  Enables interlaced execution sequences of Runnable Entities and BSW Main functions Restrict the usage of OS functionality  Only the BSW Scheduler and the RTE shall use OS objects or OS services (exceptions: EcuM, Complex Drivers and services: GetCounterValue and GetElapsedCounterValue of OS; MCAL modules may enable/disable interrupts )  Rationale:  Scheduling of the BSW shall be transparent to the system (integrator)  Enables reducing the usage of OS resources (Tasks, Resources,...)  Enables re-using modules in different environments - AUTOSAR Confidential 123


page id: y331c

Integration and Runtime Aspects - Scheduling Scheduling Objects, Triggers and Mode Disabling Dependencies BSW Scheduling objects  Main functions  n per module  located in all layers

RTE

Zzz_MainFunction_Aaa

BSW Events  BswTimingEvent  BswBackgroundEvent  BswModeSwitchEvent  BswModeSwitchedAckEvent  BswInternalTriggerOccuredEvent  BswExternalTriggerOccuredEvent  BswOperationInvokedEvent

Yyy_MainFunction_Aaa

Triggers  Main functions can be triggered in all layers by the listed BSW Events Mode Disabling Dependencies  The scheduling of Main functions can be disabled in particular modes.

Microcontroller - AUTOSAR Confidential -

124

Xxx_Isr_Yyy


page id: y331d

Integration and Runtime Aspects - Scheduling Transformation Process

Logical Architecture (Model)

Technical Architecture (Implementation)

 Ideal concurrency  Unrestricted resources  Only real data dependencies

   

 Scheduling objects  Trigger  BSW Events  Sequences of scheduling objects  Scheduling Conditions  ...

 OS objects  Tasks  ISRs  Alarms  Resources  OS services  Sequences of scheduling objects within tasks  Sequences of tasks  ...

Restricted concurrency Restricted resources Real data dependencies Dependencies given by restrictions

Transformation  Mapping of scheduling objects to OS Tasks  Specification of sequences of scheduling objects within tasks  Specification of task sequences  Specification of a scheduling strategy  ... - AUTOSAR Confidential 125


page id: yqqq1

Integration and Runtime Aspects - Scheduling Transformation Process – Example 1


Technical Architecture (Schedule Module)

Task1 { Zzz_MainFunction_Bbb(); Zzz_MainFunction_Bbb();

Yyy_MainFunction_Aaa();

Yyy_MainFunction_Aaa();

glue code

Xxx_MainFunction_Aaa();

Xxx_MainFunction_Aaa(); glue code ...

}

Transformation  Mapping of scheduling objects to OS Tasks  Specification of sequences of scheduling objects within tasks



page id: yqqq2

Integration and Runtime Aspects - Scheduling Transformation Process – Example 2


Technical Architecture (Schedule Module) Task2 { ... Xxx_MainFunction_Bbb(); ...

Xxx_MainFunction_Bbb();

}

Yyy_MainFunction_Bbb();

Task3 {

... Yyy_MainFunction_Bbb(); ... }

Transformation  Mapping of scheduling objects to OS Tasks



page id: yqqq3

Integration and Runtime Aspects - Scheduling Data Consistency – Motivation


Technical Architecture (Schedule Module)

 Access to resources by different and concurrent entities of the implemented technical architecture (e.g., main functions and/or other functions of the same module out of different task contexts) Xxx_Module Xxx_MainFunction();

?

Yyy_ AccessResource();

XYZ resource Yyy_MainFunction(); Yyy_Module Transformation Data consistency strategy to be used:  Sequence, Interrupt blocking, Cooperative Behavior, Semaphores (OSEK Resources), Copies of ...



page id: yqqq4

Integration and Runtime Aspects - Scheduling Data Consistency – Example 1 – “Critical Sections” Approach

Logical Architecture (Model)/ Technical Architecture (Schedule Module) Task1

Xxx_Module

Xxx_MainFunction();


Implementation of Schedule Module #define SchM_Enter__ \ DisableAllInterrupts #define SchM_Exit__ \ EnableAllInterrupts Yyy_AccessResource() { ... SchM_Enter_Xxx_XYZ(); SchM_Exit_Xxx_XYZ(); ... } Yyy_MainFunction() { ... SchM_Enter_Yyy_XYZ(); SchM_Exit_Yyy_XYZ(); ... }

XYZ resource Yyy_MainFunction();

Task2

Transformation Data consistency is ensured by:  Interrupt blocking



page id: yqqq5

Integration and Runtime Aspects - Scheduling Data Consistency – Example 1 – “Critical Sections” Approach

Logical Architecture (Model)/ Technical Architecture (Schedule Module) Task1

Xxx_Module

Xxx_MainFunction();


Implementation of Schedule Module #define SchM_Enter__ \ /* nothing required */ #define SchM_Exit__ \ /* nothing required */ Yyy_AccessResource() { ... SchM_Enter_Xxx_XYZ(); SchM_Exit_Xxx_XYZ(); ... } Yyy_MainFunction() { ... SchM_Enter_Yyy_XYZ(); SchM_Exit_Yyy_XYZ(); ... }

XYZ resource Yyy_MainFunction();

Task2

Transformation Data consistency is ensured by:  Sequence



page id: y331e

Integration and Runtime Aspects Mode Communication / Mode Dependent Scheduling  The mode dependent scheduling of BSW Modules is identical to the mode dependent scheduling of runnables of software components.  A mode manager defines a Provide ModeDeclarationGroupPrototype in its Basic Software Module Description, and the BSW Scheduler provides an API to communicate mode switch requests to the BSW Scheduler  A mode user defines a Required ModeDeclarationGroupPrototype in its Basic Software Module Description. On demand the BSW Scheduler provides an API to read the current active mode  If the Basic Software Module Description defines Mode Disabling Dependencies, the BSW Scheduler suppresses the scheduling of BSW Main functions in particular modes.



page id: 94ot4




page id: q222b

Integration and Runtime Aspects Vehicle and application mode management (1) Relation of Modes:  Every system contains Modes at different levels of granularity. As shown in the figure, there are vehicle modes and several applications with modes and ECUs with local BSW modes.  Modes at all this levels influence each other.

1 3

Influence each other

1

Application Modes

1


2


1


2 1 3 3


BSW Modes

2

3

1 3

Therefore:  Depending on vehicle modes, applications may be active or inactive and thus be in different application modes.  Vice versa, the operational state of certain applications may cause vehicle mode changes.  Depending on vehicle and application modes, the BSW modes may change, e.g. the communication needs of an application may cause a change in the BSW mode of a communication network.  Vice versa, BSW modes may influence the modes of applications and even the whole vehicle, e.g. when a communication network is unavailable, applications that depend on it may change into a limp-home mode.

133

2

Vehicle Modes

2

2 1

2

3 3

page id: q222e

Integration and Runtime Aspects Vehicle and application mode management (2) Processing of Mode Requests The basic idea of vehicle mode management is to distribute and arbitrate mode requests and to control the BSW locally based on the results. This implies that in each OS-Application, there has to be a mode manager that switches the modes for its local mode users and controls the BSW. Of course there can also be multiple mode managers that switch different Modes. The mode request is a “normal” sender/receiver communication (system wide) while the mode switch always a local service. Mode Requester

Mode Request

Mode Manager

Mode Manager



Mode Switch

Mode Switch

Mode User

Mode User

Application Layer

RTE Memory Services


Onboard Dev. Abstr.

Memory HW Abstr.

COM HW Abstr.


Memory Drivers


System Services

Layer App

Functionality per module Mode Arbitration SW-C

I/O HW Abstraction

I/O Drivers


RTE

Mode Request Distribution + Mode Handling BswM

BSW

Mode Arbitration

Mode Control

 The major part of the needed functionality is placed in the Basic Software Mode Manager (BswM for short). Since the BswM is located in the BSW, it is present in every OSApplication and local to the mode users as well as the controlled BSW modules.

 The distribution of mode requests is performed by the RTE and the RTE also implements the handling of mode switches.  E.g. for vehicle modes, a mode request originates from one central mode requestor SW-C and has to be received by the BswMs in many ECUs. This is an exception of the rule that SW-Cs may only communicate to local BSW.  BswMs running in different OS-Applications can propagate mode requests by SenderReceiver communication (SchMWrite, SchMRead). - AUTOSAR Confidential 135


Complex Drivers

page id: q222c

Integration and Runtime Aspects Vehicle and application mode management (3)

page id: q222d

Integration and Runtime Aspects Vehicle and application mode management (4)

Applications

Mode Processing Cycle Mode requesting Mode using  The mode requester SW-C requests mode SW-C SW-C A through its sender port. The RTE distributes the request and the BswM 3: switch 1: request receives it through its receiver port. mode A´ mode A  The BswM evaluates its rules and if a rule triggers, it executes the corresponding RTE action list. Mode request Local mode  When executing the action list, the BswM distribution handling may issue a (configurable optional) RTE call to the mode switch API as a last action to inform the mode users about the arbitration result, e.g. the resulting mode A’. BswM Mode Mode  Any SW-C, especially the mode Control 2: execute Arbitration requester can register to receive the associated mode switch indication. Action list action list  The mode requests can originate from Action 1 Mode arbitration local and remote ECUs or OS-Applications. overrides the Action 2  Note that the mode requestor can only request for mode … receive the mode switch indications from A with mode A´. RteSwitch(mode A´) the local BswM, even if the requests are sent out to multiple OS-Applications. - AUTOSAR Confidential 136


page id: 94pt4




page id: 09op0

Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Error Classification (1) Types of errors Hardware errors / failures  Root cause: Damage, failure or ‚value out of range‘, detected by software  Example 1: EEPROM cell is not writable any more  Example 2: Output voltage of sensor out of specified range Software errors  Root cause: Wrong software or system design, because software itself can never fail.  Example 1: wrong API parameter (EEPROM target address out of range)  Example 2: Using not initialized data System errors  Example 1: CAN receive buffer overflow  Example 2: time-out for receive messages



page id: nji99

Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Error Classification (2) Error Classes  Development Errors Development errors are software errors. They shall be detected like assertions and fixed during development phase. The detection of errors that shall only occur during development can be switched off per module for production code (by static configuration namely preprocessor switches). The according API is specified within AUTOSAR, but the functionality can be chosen/implemented by the developer according to specific needs.  Runtime Errors Runtime errors are systematic software errors. They indicate severe exceptions that hinder correct execution of the code. The monitors may stay in code even for a deployed systems. Synchronous handling of these errors can be done optionally in integrator code.  Transient Faults Transient faults occur in hardware e. g. by passage of particles or thermal noise. Synchronous handling of these faults can be done optionally in integrator code. The detecting module may offer behavioral alternatives selectable by this integrator code.  Production Errors / Extended Production Errors Those errors are stored in fault memory for repair actions in garages. Their occurrence can be anticipated and cannot be avoided in production code. Production errors have a detection and a healing condition.



page id: g7zre

Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Error Reporting – Alternatives There are several alternatives to report an error (detailed on the following slides): Via API Inform the caller about success/failure of an operation.

Via statically definable callback function (notification) Inform the caller about failure of an operation Via central Error Hooks (Default Error Tracer, Det) For logging and tracing errors during product development. Can be switched off for production code. Via central Callouts (Default Error Tracer, Det) For handling errors during product life time. Via central Error Function (AUTOSAR Diagnostic Event Manager) For error reaction and logging in series (production code) Each application software component (SW-C) can report errors to Diagnostic Event Manager (Dem).



page id: tegz7

Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Mechanism in relation to AUTOSAR layers and system life time Default Error Tracer (Det) Diagnostic Log and Trace (Dlt)

End to End Communication (E2E)

Application Layer AUTOSAR Runtime Environment (RTE)

Basic Software Diagnostic Event Manger (Dem) and Function Inhibition Manager (FiM)

Debugging (Dbg)

Watchdog (Wdg)

Life cycle:

ECU Hardware

development

production - AUTOSAR Confidential -

141


After production

page id: yaq12

Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Error Reporting via API Error reporting via API Informs the caller about failure of an operation by returning an error status. Basic return type Success: E_OK (value: 0) Failure: E_NOT_OK (value: 1) Specific return type If different errors have to be distinguished for production code, own return types have to be defined. Different errors shall only be used if the caller can really handle these. Specific development errors shall not be returned via the API. They can be reported to the Default Error Tracer (Det). Example: services of EEPROM driver Success: EEP_E_OK General error (service not accepted): EEP_E_NOT_OK Write Operation to EEPROM was not successful: EEP_E_WRITE_FAILED



page id: oiuzt

Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Error Reporting – Introduction Error reporting via Diagnostic Event Manager (Dem) For reporting production / series errors. Those errors have a defined reaction depending on the configuration of this ECU, e.g.:  Writing to error memory  Disabling of ECU functions (e.g. via Function Inhibition Manager)  Notification of SW-Cs The Diagnostic Event Manager is a standard AUTOSAR module which is always available in production code and whose functionality is specified within AUTOSAR. Error reporting via Default Error Tracer (Det) For reporting development/runtime errors. The Default Error Tracer is mainly intended for handling errors during development time but also for handling systematic errors in production code. Within the Default Error Tracer many mechanisms are possible, e.g.:  Count errors  Write error information to ring buffer in RAM  Send error information via serial interface to external logger  Infinite Loop, Breakpoint

The detection and reporting of development errors and runtime errors to the Default Error Tracer can be statically switched on/off per module (preprocessor switch or different object code builds of the module).



page id: fghjk

Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Diagnostic Event Manager – Diagnostic Error Reporting API The Diagnostic Event Manager has the following API: Dem_ReportErrorStatus(EventId, EventStatus)

Problem: the error IDs passed with this API have to be ECU wide defined, have to be statically defined and have to occupy a compact range of values for efficiency reasons. Reason: The Diagnostic Event Manager uses this ID as index for accessing ROM arrays. Error numbering concept: XML based error number generation Properties:  Source and object code compatible  Single name space for all production relevant errors  Tool support required  Consecutive error numbers  Error manager can easily access ROM arrays where handling and reaction of errors is defined Process: Each BSW Module declares all production code relevant error variables it needs as “extern”  Each BSW Module stores all error variables that it needs in the ECU configuration description (e.g. CANSM_E_BUS_OFF)  The configuration tool of the Diagnostic Event Manager parses the ECU configuration description and generates a single file with global constant variables that are expected by the SW modules (e.g. const Dem_EventIdType DemConf_DemEventParameter_CANSM_E_BUS_OFF=7U; or #define DemConf_DemEventParameter_CANSM_E_BUS_OFF ((Dem_EventIdType)7))  The reaction to the errors is also defined in the Error Manager configuration tool. This configuration is project specific. 



page id: ki87z

Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Default Error Tracer – Example: Development Error Reporting API The Default Error Tracer has the following API for reporting development errors (runtime errors and transient faults use identical APIs with different names): Det_ReportError(uint16 ModuleId, uint8 InstanceId, uint8 ApiId, uint8 ErrorId)

Error numbering concept ModuleId (uint16) The Module ID contains the AUTOSAR module ID from the Basic Software Module List. As the range is 16 Bit, future extensions for development error reporting of application SW-C are possible. The Basic SW uses only the range from 0..255. InstanceId (uint8) The Instance ID represents the identifier of an indexed based module starting from 0. If the module is a single instance module it shall pass 0 as an instance ID. ApiId (uint8) The API-IDs are specified within the software specifications of the BSW modules. They can be #defines or constants defined in the module starting with 0.

ErrorId (uint8) The Error IDs are specified within the software specifications of the BSW modules. They can be #defines defined in the module‘s header file. If there are more errors detected by a particular software module which are not specified within the AUTOSAR module software specification, they have to be documented in the module documentation. All Error-IDs have to be specified in the BSW description. - AUTOSAR Confidential 145


page id: yecvb

Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Diagnostic Log and Trace (1) The module Diagnostic Log and Trace (Dlt) collects log messages and converts them into a standardized format. The Dlt forwards the data to the Dcm or a CDD which uses a serial interface for example. Therefore the Dlt provides the following functionalities:  Logging  logging of errors, warnings and info messages from AUTOSAR SW-Cs, providing a standardized AUTOSAR interface,  gathering all log and trace messages from all AUTOSAR SW-Cs in a centralized AUTOSAR service component (Dlt) in the BSW,  logging of messages from Det and  logging of messages from Dem.  Tracing  of RTE activities  Control  individual log and trace messages can be enabled/disabled and  Log levels can be controlled individually by back channel.  Generic  Dlt is available during development and production phase,  access over standard diagnosis or platform specific test interface is possible and  security mechanisms to prevent misuse in production phase are provided. - AUTOSAR Confidential 146


page id:dxcvb

Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Diagnostic Log and Trace (2) The Dlt communication module is enabled by an external client. The external client has to set up a diagnostic session in a defined security level and sending control Dcnm Call Dlt_WriteData() message to Dlt for enabling the Dlt communication module. A SW-C is generating a log message. Dcm The log message is sent to Dlt by calling the API provided by Dlt. Over UDS an External Client Dlt sends the log message enables the Dlt to the implemented Dlt communication module communication module (WriteDataByIdendifer) interface. 1 At the end, the log message is stored on an external client and can be analyzed later on.

SW-C sends a log message via Dlt_SendLogMessage()

SW-C

1 Rte Dlt collects messages

2

2 Dlt Dlt comunication module

3 CAN / Flexray / Ethernt / Serial

external client collects stores log messages

4



Log message is send over network

page id: k387z

Integration and Runtime Aspects - Error Handling, Reporting and Diagnostic Diagnostic Log and Trace (3) API The Diagnostic Log and Trace has syntactically the following API: Dlt_SendLogMessage(Dlt_SessionIDType session_id, Dlt_MessageLogInfoType log_info, uint8 *log_data, uint16 log_data_length) Log message identification : session_id Session ID is the identification number of a log or trace session. A session is the logical entity of the source of log or trace messages. If a SW-C is instantiated several times or opens several ports to Dlt, a new session with a new Session ID for every instance is used. A SW-C additionally can have several log or trace sessions if it has several ports opened to Dlt. log_info contains: Application ID / Context ID Application ID is a short name of the SW-C. It identifies the SW-C in the log and trace message. Context ID is a user defined ID to group log and trace messages produced by a SW-C to distinguish functionality. Each Application ID can own several Context IDs. Context ID’s are grouped by Application ID’s. Both are composed by four 8 bit ASCII characters. Message ID Messaged ID is the ID to characterize the information, which is transported by the message itself. It can be used for identifying the source (in source code) of a message and shall be used for characterizing the payload of a message. A message ID is statically fixed at development or configuration time. log_data Contain the log or trace data it self. The content and the structure of this provided buffer is specified by the Dlt transmission protocol. Description File Normally the log_data contains only contents of not fixed variables or information (e.g. no static strings are transmitted). Additionally a description file shall be provided. Within this file the same information for a log messages associated with the Message ID are posted. These are information how to interpret the log_data buffer and what fixed entries belonging to a log message. - AUTOSAR Confidential 148


page id: 94qt4




page id: 11231

Integration and Runtime Aspects - Debugging Debugging Module - functional overview The goal of the Debugging Module is to support a user (system integrator or BSW developer) during development, in case the basic software does not behave as expected. To do so, it collects as much information as possible about the runtime behavior of the systems without halting the processor. This data is transmitted to an external host system via communication, to enable the user to identify the source of a problem. An internal buffer is provided to decouple data collection from data transmission. Main tasks of the Debugging Module are to  Collect and store data for tracing purposes  Collect and immediately transmit data to host  Modify data in target memory on host request  Transmit stored data to host  Accept commands to change the behavior of the Debugging Module



page id: 1123a

Integration and Runtime Aspects - Debugging Debugging Module - architectural overview The Debugging Module can:  interface to ECU internal modules and to an external host system via communication. With respect to the host system:  the Debugging Module is also described as being ‘target’. Internally, the Debugging Module consists of:  a core part, which handles data sampling, and  a communication part, which is responsible for transmission and reception of data. The Debugging Module is designed to be:  hardware independent and  interfaces to the PDU router. It can be used by:  the BSW and  RTE. There is no interface to software components. - AUTOSAR Confidential 151


page id: 1123b

Integration and Runtime Aspects - Debugging External architectural view - Data flow host  target Example:

Host

Debugging Com Module

Debugging Core Module

host command

call debug core command confirmation

collection of data

processing of host commands



BSW

page id: 1123c

Integration and Runtime Aspects - Debugging External architectural view - Data flow target  host Example:

Host

Debugging Com Module

Debugging Core Module

TX request

message fragment 1 message fragment 2 collection of data message fragment n

debugging communication module contains implementation of simplified TP



BSW

page id: 94rt4




XCP is an ASAM standard for calibration purpose of an ECU. RTE

XCP within AUTOSAR provides the following basic features:

Signals

 Synchronous data acquisition  Synchronous data stimulation  Online memory calibration (read / write access)  Calibration data page initialization and switching  Flash Programming for ECU development purposes

IPDU Multiplexer

XCP Protocol

AUTOSAR COM

I-PDU

XCPonFr / XCPonCAN / XCPonTCP/IP / Interfaces


I-PDU

I-PDU

Debugging

I-PDU

PDU Router

I-PDU1

AUTOSAR Tp N-PDU

NM Module I-PDU

page id: y0099

Integration and Runtime Aspects - Measurement and Calibration XCP

N-PDU

Communication HW Abstraction Bus Interface(s) (or Socket Adaptor on ethernet) L-PDU


Bus Driver(s)



page id: 94st4




page id: yxcvb

Integration and Runtime Aspects – Safety End to End (E2E) Communication Protection Overview

Libraries

OS-Application 2

Typical sources of interferences, causing errors detected by E2E protection:

OS-Application 1

Receiver 1

Sender

E2E protection wrapper


Direct function call

SW-related sources: S1. Error in mostly generated RTE, S2. Error in partially generated and partially hand-coded COM S3. Error in network stack S4. Error in generated IOC or OS

Direct function call

S1

H3

E2E Lib

RTE System Services

Memory Services

Communication Services S2



S4


CDD

HW-related sources: H1. Failure of HW network H2. Network electromagnetic interference H3. Microcontroller failure during context switch or on the communication between cores

IOC Direct function call Onboard Device Abstraction

RTE int. wrapper

S3


Memory Drivers


Receiver 2 I/O Drivers

H1

Microcontroller 1 / ECU 1



H2

Microcontroller 2 / ECU 2

page id: yx3vb

Integration and Runtime Aspects – Safety End to End (E2E) Communication Protection Logic Libraries

OS-Application 2

OS-Application 1

Receiver 1

Sender 1

Application logic

Application logic


9. Consume safe data elements

1. Produce safe data elements

6. Invoke safe read do get the data element E2EWRP_Read_
_()

2. Invoke safe transmission request E2EWRP_Write_
_()


8. Call E2E check on array - E2E_P0xCheck()

3. Call E2E protect on array – E2E_P0x_Protect()

E2E Lib

7. Invoke RTE read - RTE_Read_
_() to get the data element AUTOSAR Runtime Environment (RTE)

4. Invoke RTE - RTE_Write_
_() to transmit the data element

5. RTE communication (intra or inter ECU), either through COM, IOC, or local in RTE

Notes:  For each RTE Write or Read function that transmits safety-related data (like Rte_Write_
_()), there is the corresponding E2E protection wrapper function.  The wrapper function invokes AUTOSAR E2E Library.  The wrapper function is a part of Software Component and is preferably generated.  The wrapper function has the same signature as the corresponding RTE function, just instead of Rte_ there is E2EPW_.  The E2EPW_ function is called by Application logic of SW-Cs, and the wrapper does the protection/checks and calls internally the RTE function.  For inter-ECU communication, the data elements sent through E2E Protection wrapper are be byte arrays. The byte arrays are put without any alterations in COM I-PDUs. - AUTOSAR Confidential 158


page id: 94st5




page id: soc72

Integration and Runtime Aspects – Secure Onboard Communication Overview - Message Authentication and Freshness Verification

Application Layer

Application Layer

RTE

RTE

Sender

Secret key K

Receiver

Secret key K Input data (arbitrary length)

MAC verification

NOK

MAC generation Last rcv counter

full MAC (128 Bit)

Monotonic counter

FV

FV

MAC

Monotonic counter sync

Truncation

MAC

Secured I-PDU

Authentic I-PDU

FV

MAC

Authentic I-PDU

FV

Authentic I-PDU

Secured I-PDU

MAC: Message Authentication Code FV: Freshness Counter Value


OK


Authentic I-PDU

page id: soc73

Integration and Runtime Aspects – Secure Onboard Communication Integration as communication service Communication Services AUTOSAR COM

PDU Router

Routing Table

SecOC BSW

SecOC BSW:  adds/verifies authentication information (for/from lower layer)  realizes interface of upper and lower layer modules  is addressed by PduR routing configuration  maintains buffers to store and modify secured I-PDUs Upper Layer SW Module (e.g. COM)

TP

FrTp

CanTp Authentic I-PDU

SecOC (Secure Onboard Communication)

PDUR

FrIf

CanIf Secured I-PDU Authentic I-PDU

Lower Layer Communication Modules (e.g. CanIf, CanTp)



Authentication Information

page id: soc74

Integration and Runtime Aspects – Secure Onboard Communication Integration with other services PDU-Routing

SW-C

Key & Counter Management SW-C Cryptographic Services

RTE System Services


Crypto Service Manager

AUTOSAR COM

PDU Router

Routing Table

TP

FrIf

FrTp

CanTp

SecOC BSW Crypto Abstraction Library

CanIf



Diagnostic Event Manager

Key & Counter Management Services Key Management (optional) Error Reporting

page id: 94st6




page id: eep2q

Energy Management Introduction The goal of efficient energy management in AUTOSAR is to provide mechanisms for power saving, especially while bus communication is active (e.g. charging or clamp 15 active). AUTOSAR R3.2 and R4.0.3 support only Partial Networking. Partial Networking  Allows for turning off network communication across multiple ECUs in case their provided functions are not required under certain conditions. Other ECUs can continue to communicate on the same bus channel.  Uses NM messages to communicate the request/release information of a partial network cluster between the participating ECUs. Pretended Networking (currently only for CAN)  Allows turning off an ECU in an existing network while communication is on the bus. The ECU can reduce runtime power consumption by increasing the idle time of the MCU.  Uses an ECU local approach (node can decide by itself to switch into a power saving mode) and therefore allows for easy integration into existing networks. ECU Degradation  Allows to switch of peripherals.



page id: eep3e

Energy Management – Partial Networking Example scenario of a partial network going to sleep

1

ECU A

1

ECU B 2

ECU C 2

ECU D 2

Physical CAN Bus Partial Network Cluster 1 Partial Network Cluster 2

Initial situation:  ECUs “A” and “B” are members of Partial Network Cluster (PNC) 1. ECUs “B”, “C” and “D” are members of PNC 2.  All functions of the ECUs are organized either in PNC 1 or PNC 2.  Both PNCs are active.  PNC 2 is only requested by ECU “C”.  The function requiring PNC 2 on ECU “C” is terminated, therefore ECU “C” can release PNC 2. This is what happens:  ECU “C” stops requesting PNC 2 to be active.  ECUs “C” and “D” are no longer participating in any PNC and can be shutdown.  ECU “B” ceases transmission and reception of all signals associated with PNC 2.  ECU “B” still participates in PNC 1. That means it remains awake and continues to transmit and receive all signals associated with PNC 1.  ECU “A” is not affected at all. - AUTOSAR Confidential -

165


page id: eep3c

Energy Management – Partial Networking Conceptual terms  A significant part of energy management is about mode handling. For the terms  Vehicle Mode,  Application Mode and  Basic Software Mode see chapter 3.4 of this document.  Virtual Function Cluster (VFC): groups the communication on port level between SWcomponents that are required to realize one or more vehicle functions. This is the logical view and allows for a reusable bus/ECU independent design.  VFC-Controller: Special SW-component that decides if the functions of a VFC are required at a given time and requests or releases communication accordingly.  Partial Network Cluster (PNC): is a group of system signals necessary to support one or more vehicle functions that are distributed across multiple ECUs in the vehicle network. This represents the system view of mapping a group of buses to one ore more VFCs.



page id: eep3r

Energy Management – Partial Networking Restrictions  Partial Networking (PN) is currently supported on CAN and FlexRay buses.  LIN and CAN slave buses (i.e. CAN buses without network management) can be activated* using PN but no wake-up or communication of PN information are supported on those buses  To wake-up a PN ECU, a special transceiver HW is required as specified in ISO 11898-5.  The standard wake-up without special transceiver HW known from previous AUTOSAR releases is still supported.  A VFC can be mapped to any number of PNCs (including zero)  The concept of PN considers a VFC with only ECU-internal communication by mapping it to the internal channel type in ComM as there is no bus communication and no physical PNC  Restrictions for CAN  J1939 and PN exclude each other, due to address claiming and J1939 start-up behaviour  J1939 need to register first their address in the network before they are allowed to start communication after a wake-up.  A J1939 bus not using address claiming can however be activated using PN as a CAN slave bus as described above  Restrictions on FlexRay  FlexRay is only supported for requesting and releasing PNCs.  FlexRay nodes cannot be shut down since there is no HW available which supports PN. * All nodes connected to the slave buses are always activated. It is not possible only to activate a subset of the nodes. - AUTOSAR Confidential 167


page id: eep3m

Energy Management – Partial Networking Mapping of Virtual Function Cluster to Partial Network Cluster

SW-C 4

SW-C 2

SW-Component of VFC1

SW-C 6


SW-C 1

SW-C 5

SW-C 3


SW-C 7

CompositionType

Communication Port

VFC1

VFC2

VFC3

Mapping of VFC on PNC PNC1

ECU A SW-C 1

ECU B

SW-C 2

SW-C 3

SW-C 4

ECU C SW-C 5

SW-C 6

SW-C 7

RTE

RTE

Basic Software

Basic Software

Basic Software

ECU Hardware

ECU Hardware

ECU Hardware

CAN Bus

PNC2 - AUTOSAR Confidential -

168

• Here both Partial Networks map to one CAN bus.

• One Partial Network can also span more than one bus.

RTE

PNC1

PNC2


PNC1

PNC2

CAN

page id: eep3b

Energy Management – Partial Networking Involved modules – Solution for CAN

Application Layer

RTE

SW-C

• Coordination of I-PDU group switching • Start / stop I-PDU-groups

SW-C

Mode request

System Services Communication Services

or

• VFC to PNC to channel translation • PNC management (request / release of PNCs) • Indication of PN states

ComM_User Request

ComM_UserRequest

BswM

ComM PNC states

I-PDU GroupSwitch • Exchange PNC request / release information between NM and ComM via NM user data • Enable / disable I-PDU-groups

COM

PduR

PNC request/release information

Trigger Transmit

Network Request

NmIf

CanNm

Communication Hardware Abstraction • • • •

Filter incoming NM messages Collect internal and external PNC requests Send out PNC request infocmation in NM user data Spontaneous sending of NM messages on PNC startup



CanIf

CanTrcv

Request ComMode

CanSM

page id: eep4b

Energy Management – Pretended Networking Involved modules – Solution for CAN

Application Layer

SW-C

SW-C

Mode request

RTE

System Services Communication Services

ComM_UserRequest

BswM I-PDU GroupSwitch

COM

ComM

Activate or deactivate ICOM

CanSM Activate or deactivate ICOM Communication Hardware Abstraction

CanIf

CanTrcv

Activate or deactivate ICOM Communication Drivers

Can

• Enable, disable interrupts



page id: eep4r

Energy Management – Pretended Networking Restrictions  Pretended Networking is currently supported on CAN buses only. Future releases will also support FlexRay.  Pretended Networking in gateway ECUs is not supported.  For level 1, the functionality of the BSW is reduced while the MCU is in Pretended Networking mode. This increases the idle time of the software, which increases the time the MCU can be put in an energy efficient state. Only when the payload of received message has to be filtered for wakeup reasons, or messages have to be sent, the software needs to be active.  Level 1 can, therefore, reuse existing communication controllers. It does, however, require a hardware timer to issue a cyclic wakeup, even when the MCU is paused.  For level 2, a new type of Intelligent Communication Controllers (ICOMs) will be required. ICOMs are able to send, receive and filter frames, even if the MCU is not running. Dedicated hardware will be necessary especially for high-speed busses such as FlexRay, because the activation time for the software based approach would decrease the saving potential of Pretended Networking due to the much higher data rate. In Release 4.1 only Level 1 is available.



page id: eep5b

Energy Management – ECU Degradation Involved modules – Solution for I/O Drivers

Application Layer

SW-C

SW-C

Mode request

RTE

System Services

Complex Drivers

BswM

OS Control core HALT

Prepare / Enter power state

Notify power state ready


IOHwA Switch power state I/O Drivers

Adc

Pwm



page id: eep5r

Energy Management – ECU Degradation Restrictions  ECU Degradation is currently supported only on MCAL drivers Pwm and Adc.  Core HALT and ECU sleep are considered mutually exclusive modes.  Clock modifications as a means of reducing power consumption are not in the scope of the concept (but still remain available as specific MCU driver configurations).



page id: 94st9




Global Time Synchronization provides synchronized time base(s) over multiple in-vehicle networks. RTE

StbM provides the following features:  Time provision  Time base status  Time gateway

Signals

StbM

SoAd

I-PDU


I-PDU

TcpIp

I-PDU

PDU Router

OS I-PDU1

CanTSyn

Use-case examples:  Sensor data fusion  Cross-ECU logging

AUTOSAR COM

FrTSyn

EthTSyn

AUTOSAR Tp N-PDU

GeneralPurposePDU

GeneralPurposePDU

I-PDU

CanTSyn / FrTSyn / EthTSyn provides the network-specific time synchronization protocol. EthTSyn provides additionally a ratecorrection and latency calculation.

IPDU Multiplexer

Datagram

page id: gtsc5

Integration and Runtime Aspects – Global Time Synchronization

NM Module N-PDU

Communication HW Abstraction CanIf

FrIf

EthIf L-PDU

Communication Drivers Can Driver

Fr Driver



Eth Driver

GPT Driver

AUTOSAR Layered Software Architecture

AUTOSAR Layered Software Architecture

Suggest Documents

AUTOSAR Software Architecture - Hasso-Plattner-Institut

From EAST-ADL to AUTOSAR Software Architecture

AUTOSAR Software Overview

A Layered Software Specification Architecture - Merode

Evolving hypermedia systems: a layered software architecture

From EAST-ADL to AUTOSAR Software Architecture - Semantic Scholar

AUTOSAR Software Component Development with

A multi-layered software architecture model for building software ...

SilentBSW â Silent AUTOSAR Basic Software for

AUTOSAR Software Component Development with ... - MathWorks

CAD/CAE Integration Framework with Layered Software Architecture

A Layered Software Architecture for Quantum ... - EECS @ Michigan

Autosar ppt.ppt

Software Architecture

Software Architecture

Software Architecture

Timing Modeling and Analysis for AUTOSAR-Based Software ...

software architecture: architecture constraints - Lirmm

Model-based Development of Autosar Application Software - ETAS

Model-based Development of Autosar Application Software - ETAS

A new trend in automotive software: AUTOSAR concept

Enhanced Semantic Web Layered Architecture ... - Semantic Scholar

Layered Architecture Consistency for manets - Semantic Scholar

Refactoring Towards a Layered Architecture - CyberLeninka

AUTOSAR Layered Software Architecture