AUTOSAR NOTES

AUTOSAR VFB & RTE

Introduction

• In order to achieve a high degree of transparency against the underlying hardware infrastructure, the AUTOSAR standard introduces two architectural concepts that facilitate infrastructure independent software development:

– The Virtual Function Bus (VFB)

– The Runtime Infrastructure (RTE)

• The AUTOSAR software architecture follows several abstraction principles for obtaining flexibility against the underlying infrastructure.

• Any piece of software within an AUTOSAR infrastructure can be seen as an independent component while each AUTOSAR application is a set of interconnected AUTOSAR components

• The different layers of abstraction allow the application designer to disregard several aspects of the physical system on which the application will later be deployed on, like:

– Type of microcontroller

– Type of ECU hardware

– Physical location of interconnected components

– Networking technology / buses

– Instantiation of components / Number of instances

Virtual Function Bus (VFB)

• The virtual function bus can be described as a system modeling and communication concept

• Logical entity that facilitates the concept of relocatability within the AUTOSAR software architecture

• Provides a virtual infrastructure that is independent from any actual underlying infrastructure

• Provides all services required for a virtual interaction between AUTOSAR components

• Separates the domain of application development and modeling from the infrastructure

Runtime Environment (RTE)

• The runtime environment provides an actual representation of the virtual concepts of the VFB for one specific ECU

• Each ECU has its own customized RTE implementation which is generated during the ECU Configuration process of the AUTOSAR methodology

• The ECU mapping, i.e. the information about which component will be deployed on which ECU, is part of the input of this configuration process

RTE

• Depending on the location of each component, the formerly virtual interaction can then be mapped to real interaction implementation

• Components that are mapped onto one ECU will communicate through Intra ECU-Mechanisms, like function calls while Inter-ECU communication will be realized using, e.g. a communication bus infrastructure

• Since the RTE source code is usually generated, it can be tailored by the generator to implement exactly the communication paths required by its connected AUTOSAR components

• RTE can be seen as a static implementation of specialized communication topologies

VFB to RTE Mapping where the Virtual Communication Topology is mapped to Three Different ECUs

Comparison of VFB and RTE with Focus on Selected Common Concepts

Generation of RTE Generation of RTE

• The RTE is generated in order to ensure that it fits a given ECU and system configuration.

• This means that an RTE implementation always provides only the functionality that is needed for a given configuration, and nothing more.

• The generation process is divided into two phases

- Contract phase

- Generation phase

Contract phase:

• This phase is ECU-independent. It provides the contract between a given ASW component and the RTE, that is, the API that the ASW component can be coded against.

• The input for this phase is the description of an ASW component with all its ports and runnable entities.

• The result is an ASW component-specific header file that can be included by the corresponding source code file.

• The set of allowed API functions depends on the ports of the given ASW component. For example, if an ASW component has a send-port p with a data element d, the contract phase will generate the API function Rte_Send_p_d.

Generation phase:

• In this phase the concrete code generation for a given ECU is performed.

• Input for this phase is the ECU configuration description, which includes especially the mapping of runnable entities to OS tasks or the communication matrix.

• Together with the ASW component header files created during the contract phase and all necessary BSWcode, the generated code can then be compiled to an executable file for the given ECU.

Runnables

• Since AUTOSAR software components have no direct access to the underlying hardware or the operating system, the implementation of the atomic software components cannot reflect artifacts like Threads or Processes

• Instead, each piece of functionality that has to be executed during runtime of the software component is wrapped into a so-called Runnable

• The VFB-Specification defines a runnable as a Sequence of instructions that can be started by the Run-Time Environment

• Each runnable that a component provides can be invoked by the RTE and is executed within the context of the underlying operating system

• An atomic software component can consist of an arbitrary number of runnables of which each might have its own execution semantics

• During the process of ECU configuration, a mapping between operating system tasks and existing runnables is created that is later used by the RTE to define and perform scheduling and execution of the runnables according to their specification

Categories of Runnables

• Type 1 Runnables

– Consists of a set of instructions that can be determined to terminate within a finite time

– Blocking RTE calls that contain WaitPoints cannot be contained in a type 1 runnable

– Runnables that fulfil these constraints are usually mapped to basic operating system tasks

• Type 2 Runnables

– Contains at least one wait point that causes the runnable to terminate only upon the appearance of an external event (e.g. the receive of a data value)

– Such runnables are mapped by the RTE to extended operating system tasks that support the state Waiting

Pseudo-code Implementation of a Runnable Body

void SeatHeating_Runnable_run1 ()

{

...

RTE_Read_InPort_Value (...);

// do something

RTE_Write_OutPort_Value (...);

...

}

Integration- Relationship between OS,RTE and VFB

• The concept of runnables affects several aspects of AUTOSAR, like the operating system, the runtime environment as well as the virtual function bus

• Each of them deals with runnables differently, depending on their view on the overall system

OS View

• An AUTOSAR-Compliant Operating System (e.g. OSEK OS) does not know about the concepts of runnables at all

• Instead, the operating system usually maintains a list of schedulable entities that are under management of a scheduling algorithm

• Since runnable entities will be integrated by the RTE into operating system tasks, they will be executed anytime the corresponding OS task is scheduled

RTE View

• The runtime environment maps runnables that can be executed together into one OS task

• This task is then structured and controlled using RTE glue code that will control the correct execution of the runnables within the OS task

• The boxes colored in red denote single runnables

• The corresponding control flow that triggers the execution of such a runnable as well as the glue code (yellow box) is under control of the RTE

VFB View

• On the level of the virtual function bus (i.e. during design time of the application), the integration context of the runnable as well as the environment in which it will be executed are not of concern

• Instead, anything except the sequence of single instructions within the function body and the constraints on invocation for the runnable are disregarded

MCAL, Partial Networking and J1939 Overview

Introduction to MCAL

Lowest software layer of AUTOSAR Basic Software

Contains internal drivers

Accesses internal peripherals of microcontroller directly

Accesses memory mapped external devices

Make higher software layers independent of microcontroller

Manages the microcontroller peripherals and provides the upper layer with microcontroller independent values

Implements notification mechanisms to support the distribution of commands, responses and information to

different processes

Input required for implementation of MCAL

Module Groups In MCAL

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

AUTOSAR Software Specification (SWS)

Datasheet of Microcontroller (User Manual)

Communication Drivers

Drivers for ECU onboard (e.g. SPI) and vehicle communication (e.g. CAN)

I/O Drivers

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) Functions with direct μC access (e.g. Core test)

I/O Drivers

The ADC driver module initializes and controls the internal Analog to Digital Converter unit of the microcontroller

The Digital Input and Output driver module provides services for reading from and writing to the DIO Channels, DIO Ports and DIO Channel Groups

The PWM driver module provides functions for initialization and control of the microcontroller internal PWM unit

The ICU Driver controls the input capture unit of the microcontroller

Port Driver initializes the whole port structure of the microcontroller

Communication Drivers

The Communication drivers performs the hardware access and offers a hardware independent API to the upper layer

Memory Drivers

Memory driver module provides the interface for erasing, writing and reading the memory

Microcontroller Drivers

The GPT driver allows generating one-shot or continuous timer notifications

The Watchdog driver module provides services for initialization, changing the operation mode and triggering the watchdog

The MCU driver module provides services for basic microcontroller initialization, power down functionality, reset and microcontroller specific functions required from other Low Level Driver modules

Initialization Order

– The sequence in which the MCAL modules initialization and APIs to be invoked are very important for the proper operation of individual modules.

– The order to be followed is as follows:

– MCU Initialization

– WDG Initialization

– PORT Initialization

– Individual module initialization (ADC, PWM, GPT…)

– How is MCAL different from Complex Drivers?

– Complex Drivers are Application specific, usually customer specific requirements

– MCAL modules will have standard defined functionality by AUTOSAR

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

Partial Network Cluster (PNC)

• 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 or more VFCs.

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

2

1

2

2

1

ECU D

ECU C

ECU B

ECU A

Physical CAN BusPartial Network Cluster 1Partial 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.

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 behavior

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.

Characteristics of J1939

• Higher-layer protocol based on Controller Area Network (CAN)

• Provides serial data communication between Electronic Control Units (ECUs) in any kind of heavy duty vehicle.

• Extended CAN identifier (29 bit)

• Bit rate 250 kbit/s

• Peer-to-peer and broadcast communication

• Transport protocols for up to 1785 data bytes

• Network management

• Definition of parameter groups for commercial vehicles and others

• Manufacturer specific parameter groups are supported

• Diagnostics features

• Maximum 30 nodes (ECUs) in a network

J1939 Applications

J1939 Protocol is used in many applications, few of them are as follows:

• Agricultural and Forestry Off-Road Machinery Control and Communication Network .

• Marine Stern Drive and Inboard Spark-Ignition Engine On-Board Diagnostics

• Off-Board Diagnostic Connector

• Industrial Generator Sets

• Truck and Bus Applications

SAE J1939 - Message Format

SAE J1939 - Message Format

• A Parameter Group Number (PGN) is a part of the 29-bit identifier sent with every message.

• The PGN is a combination of

- the Reserved bit (always 0),

- the data page bit (currently only 0, 1 is reserved for future use),

- the PDU (Protocol Data Unit) Format (PF),

- PDU Specific (PS).

• PDU Format < 0xF0 defines Peer-to-Peer message. PDU Specific will be a Destination Address

• PDU Format => 0xF0 identifies message as broadcast. PDU Specific will be a Group Extension

Example J1939 PGN

J1939 Wheel Speed Information

• PGN: 65215(0xFEBF)

• Priority: 6 (default)

• Length: 8

• TX Rate: 100 ms SPN

• Bytes 1-2: Front axle speed 904

• Byte 3: Relative, front axle #1, left 905

• Byte 4: Relative, front axle #1, right 906

• Byte 5: Relative, rear axle #1, left 907

• Byte 6: Relative, rear axle #1, right 908

• Byte 7: Relative, rear axle #2, left 909

• Byte 8: Relative, rear axle #2, right 910

• Benefits of Autosar:

•

Drawbacks of AUTOSAR: The methodology used for mapping AUTOSAR concepts on existing has serious drawbacks.

 •If both the existing concept and the newly introduced AUTOSAR concept carry the same information, there is a risk of inconsistency. There is also a risk of confusion over which concepts to use, but this is easily resolved by making the old concept abstract thereby forcing the use of the new concept

• Conflicting inheritance. Even if individual concepts map perfectly on each other, they can be parts of inheritance structures violating AUTOSAR. On behalf of multiplied information and the risk of inconsistency the problem can theoretically be resolved with multiple inheritances. In practise the problems cannot be resolved; SystemWeaver does not support multiple inheritances. The final part of the implementation of the prototype meta model in an existing meta model is more of a demonstration piece; the implementation is what usually is called “ugly hack” In order to implement a fully working AUTOSAR meta model the usual

customisation of the SystemWeaver is necessary, not only with respect of the  customers needs but also with respect to AUTOSAR´s requirements.