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
time of the
runnable as
executed are

of the virtual function bus (i.e. during design

application), the integration context of the
well as the environment in which it will be
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
Implements notification
mechanisms
to support
independent
values
the distribution of commands, responses and
information to different processes

Input required for implementation of MCAL

AUTOSAR Software Specification (SWS)

Datasheet of Microcontroller (User Manual)

Module Groups In MCAL

The C Abstraction Layer consists of the following module groups:

Communication Drivers

 Drivers for ECU onboard

communication (e.g. CAN)

(e.g.

SPI)

and

vehicle

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
continuous timer notifications

one-shot

or

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
customer specific requirements

specific,

usually

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

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 ECUinternal 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
as

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

follows:
Agricultural and Forestry Off-Road Machinery Control and
Communication Network .
Marine Stern Drive and Inboard Spark-Ignition Engine OnBoard 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:

 TX Rate: 100 ms

Bytes 1-2:

Front axle speed

Byte 3:
905

Byte 4:

Byte 5:
907

Relative, rear axle #1, left

Byte 6:
908

Relative, rear axle #1, right

Byte 7:
909

Relative, rear axle #2, left

Byte 8:
910

Relative, rear axle #2, right

Benefits of Autosar:

SPN
904

Relative, front axle #1, left

Relative, front axle #1, right

906

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 AUTOSARs requirements.