Embedded: vector/AUTOSAR

The AUTOSAR Classic Platform architecture distinguishes on the highest abstraction level between three software layers that run on a microcontroller: Application, Runtime environment (RTE) and Basic software (BSW). The application software layer is mostly hardware independent. Communication between software components and access to BSW happens via RTE, which represents the full interface for applications.
Standardization of interfacess between the application and basic software enables abstraction of the application from the hardware and smooth integration of functional modules.(abstraction make development more flexible)

Layers:

-Application Layer: application software components (SWC) that interact with the runtime environment and is an atomic software code fragment (independent, cannot be subdivided) and cam be mappe to any ECU. (composition - logical encapsulation of software components )
-Runtime environment (RTE): Middleware which abstracts from the network topology for the inter- and intra-ECU information exchange between the application software components and between the Basic Software and the applications. A configurable "middleware is needed for abstraction of the basic software. The RTE is scalable and is generated statically for each ECU.
-Basic Software(BSW): standardized software modules (mostly) without any functional job itself that offers services necessary to run the functional part of the upper software layer.
The BSW is divided in three major layers and complex drivers:
-Services,
-ECU (Electronic Control Unit) abstraction and
-Microcontroller abstraction.

det:

VFB
One essential concept of the Classic Platform is the virtual functional bus (VFB). This virtual bus is an abstract set of RTEs that are not yet deployed to specific ECUs and decouples the applications from the infrastructure. It communicates via dedicated ports, which means that the communication interfaces of the application software must be mapped to these ports. The VFB handles communication within the individual ECU and between ECUs. From an application point of view, no detailed knowledge of lower-level technologies or dependencies is required
Virtual Function Bus
From a general perspective, the virtual function bus can be described as a system modeling and communication concept. It is logical entity that facilitates the
concept of relocatability within the AUTOSAR software architecture by providing a virtual infrastructure that is independent from any actual underlying
infrastructure and provides all services required for a virtual interaction between
AUTOSAR components.
The virtual function bus is a component interconnection concept that strictly separates the domain of application development and modeling from the infrastructure.
It provides generic communication services that can be consumed by any existing AUTOSAR software component. Although any of these services are virtual, they will then in a later development phase be mapped to actual implemented methods, that are specific for the underlying hardware infrastructure.

Runtime Environment
In contrast to the purely virtual specification of the communication topology and interaction between components which is done via the virtual function bus, the runtime environment provides an actual implementation for these artifacts. It could also be said that 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 deployed on which ECU, is part of the input of this configuration process

AUTOSAR Runtime Environment and Virtual Function Bus LINK

Application Layer issues

Type of Ports (joined by connectors)

SWC has Ports:
-Interfaces to other components for communication
-Contents: -data elements assigned to network signals (S/R - Sender/Receiver)
-operations with arguments (C/S - Client/Server)

Sender/Receiver - asynchronous data transmission (no expects response, does not know the number of receivers (between ECUs). simple data types (int,float) and complex (array,record). Port may contain multiple data elements. Data element is "mapped" to a signal if its goes over the bus.
Communication 1:n or n:1

Client/Server - server offers services which are requested by the client. Swc may be as client, as server as both. Serving of operations with arguments. Synch or Asynch. Inter and Intra Ecu communication. Communication 1:1 or n:1(n clients : 1 serwer )

Synchronous vs Asynchronous:
synch - client is blocked throughout the duration of the call and retains the result in the returning call.
asynch - client does not block during the call and can execute other operations, while the server executes the requested operation in parallel

Inter ECU communications: RPC remote procedure calls / RMI remote method invication

Runnables
Runnable entity is the executable unit of a software component (corresponds to a C function)
SWC contain one or more runnables
Runnabes might be executed when RTE Events occur(data are received or periodic activation is due)

RTE Layer issues

RTE is the implementation of the VFB and acts as a switchboard between the application, basic software and hardware.

As middleware integrates individual applications with the basic software. Its organizes the communication and data exchange between them and handles execution of software functions (runnables). The applications no longer needs to know layers below, they using interfaces of rte.
Communication involves sending only certain parameters by passing them to the defined interfaces (described in the model by ports).

RTE offers abstractions of: OperatingSystem, communication services, hardware interfaces.
RTE is a runtime invironment for runnables (enables applications, triggering runnables via RTE events)
RTE must be regenerated for each ECU after SWC have been mapped to this ECU.

syntax (trigered event expet C/S):
void <RunnableName>( Rte_Instance instance)

syntax (trigered by C/S):
void/Std_ReturnType <RunableName>( Rte_Instance instance, {paramlist})

example:
void Lightserver(Rte_Instance self, UInt8 keyValue,Boolean active, ResultTypeRef result )

RTE events (triggering of runnables or wakeup from waitpoints(eg. client waits for server response)
-init
-timingevent
-datareceivedevent (S/R)
-datareceivederrorevent (S/R)
-datasendcompletedevent (S/R)
-operationInvokedEvent(C/S)
-asynchronousServerCallReturnsEvent(C/S)
-modeSwitchevent
-modeswitchackevent
Autosar 4.
-externalTriggerOccuredEvent
-InternalTriggerOccuredEvent
-BackgroundEvent

RTE as communication mechanism among SWC and BSW
-rte acts as implementation of the VFB
-S/R
-C/S
-Intra ECU and Inter ECU (via COM)
-RTE implements callbacks of AR-COM

Sender/Receiver Direct vs Buffered & Queued

Direct - Data is written immediately during execution of the runnable:

Buffered - rte generates copy

Queued:

Client/Server
-n:1
-client calls server operations
-operation is implemented as runnable of the Server-SWC
-synchronous vs asynchronous calls
-Server runnables run in the:
- Task context (task switch is made when the runnable is assigned to antoher task,rte saving of data)
- context of the Client (direct function call - not assigned to any task)

syntax:
Std_ReturnType RteCall_ ( IN | IN/OUT | OUT <param_1> , ... )

Client/Server communication makes a new type of protocol necessary, the mapping of the operation is to the protocol ( in S/R mapping is made of a ports data elements to a network signal)

C/S synchronous vs asynchronous

synchronous:

-wait for response of Server (client is blocked)
-result of server via "OUT" parameter of Rte_Call_<p>_<o>

Server runnable:
Std_ReturnType GetTime ( arg...)

RTE Client API:
Std_ReturnType Rte_Call<Port>_GetTime (arg... )

asynchronous

-client is not blocked
-client gets Server result by call of Rte_Result (polling or waiting, timeout handling )

RTE Client API:
Std_ReturnType Rte_Result_<p>_<o> ( [IN/OUT | OUT <param_1>], ... [IN/OUT | OUT <param_2>],... )

Intra SWC communication

Problem: communication between runnables within one SWC, which runs potentialy on different tasks.
(there are no problem in Intra and Inter communication of different SWC (handled by RTE)

atomic acces on task level

Solution:
-Exclusive Areas (EAs)- allows to specify atomic sections for your implementation

Rte_Enter <name> ();
/* protected statements */
Rte_Exit <name> ();

-Inter-runnable variables (IRVs) - variable that allows the communication between two runnables

Rte_IrvWritte_<re>_<name>
Rte_IrvRead_<re>_<name>

Interfaces

Interfaces types are described in diagram above:
- Autosar interface

- Standarized interface

- Standarized Autosar interface

Basic software components:
- Services (diagnostics,nvram),flash
- Comunication (CAN,LIN)
- Operating system (based od OSEK OS)
- Micronoctroler abstraction (Digital I/O, AC, EEPROM

ECU specific basic software
- ECU abstraction
- Complex device driver

BSW Layer issues

Basic Software(BSW): standardized software modules (mostly) without any functional job itself that offers services necessary to run the functional part of the upper software layer.

The BSW is divided in three major layers and complex drivers:
-Services,
-ECU (Electronic Control Unit) abstraction and
-Microcontroller abstraction
-Complex Device Drivers

Tasks:
Services: Services for aplication (diagnost, NVram management, Comunication, Schedule Manager)

ECU: Make higher levels independent of ECU hardware (driver for devices, interfaces for periphery)

Microcontroller: Make layers independent of microcontroller (drivers direct acces to periphery)

Complex Device Drivers: Offer functionality for complex sensors and actuators (Direc access to resources for critical aplications, ex: injection control, baterry management )