Common terms used in AUTOSAR

Common Terms used in AUTOSAR

Translate in your language

AUTOSAR is built for standardizing the software development of ECU. Hence it has many terms which we may have never heard of. This article discusses some common terms used in AUTOSAR and explains them.

Directly Jump to:

Integrator

In AUTOSAR context, a integrator is a person who configures and generate AUTOSAR project using a GUI software like Vector DaVinci. We are used to call ourselves developer because we develop software, but in AUTOSAR project, developer is the one who implements a behavior of SWC by writing code in Runnable.

Signal

AUTOSAR implements signal based communication. A signal is the smallest amount of information that a CAN message can have. A signal can be of any size from 1- bit to all 64 bits of CAN message (considering the CAN message is 8-Bytes), in other words the CAN message is divided in bits called signals. Signals can be also there for FlexRay or other bus, the only change is maximum amount of signals it can hold.

To relate this, lets consider a real life example. Suppose a ECU needs to know the state of doors (locked/unlocked). In normal C program we would implement a flag which will indicate the state of the doors. But in AUTOSAR, a 1-bit signal is used to indicate this. Below image shows our signal in a CAN Data field of frame.

From above figure, we can see that our information requires only 1-bit of size. A signal can be of any size dependent on the requirements. Suppose your application needs to transmit numeric information in having a range of 0 – 7 so a 3 bit signal is enough. In this way, signal implementation helps in saving the space required by information in the CAN data field by using only the space required for information.

SWCs use signal to communicate with each other by using VFB via RTE. Signal is implemented and only understood by layers from COM to application Layer.

Signals can be grouped when signals needs to be kept tightly with each other or signal groups can be used to support complex data structure like structs. In code, a structure will be implemented having members as signals which is nothing but signal group.

PDU or message

In AUTOSAR, roughly a message is called PDU (Protocol Data Unit). I am saying roughly because, PDU contains information other than our data which is used or extracted by below or upper layers in transmission or reception respectively. There can be n number of PDUs with varying size. The PDU is basically group of packed signals along with lower layer information. AUTOSAR COM performs the packing or unpacking of signals in or from PDU while transmission or reception respectively. Every PDU has a unique identifier associated with it.

PDU contains SDU and PCI. SDU is the abbreviation of Service Data Unit and PCI is the Protocol Control Information.

SDU is the data which needs to be transmitted. While transmission, SDU is passed from upper layers to lower layers along with PCI. During reception, SDU is the data extracted from below layers and passed on to upper layers.

PCI contains the information which indicates the next destination of the SDU. Basically, it contains the source and destination of the SDU. The source and destination in this case is the next layer to which the PDU needs to be passed.

In simple words, the PDU is transferred from upper layers to lowers and vice versa which contains SDU and PCI. Below figure will help in understanding this.

While transferring PDU from layer to layer its called by relevant names based on layer it is in. The PDUs are named as: I-PDU (Interaction Layer PDU), N-PDU (Network Layer PDU), L-PDU (Data Link Layer PDU).

Whenever the PDU is in layers above Communication Hardware Abstraction layer then its called I-PDU. Whenever the PDU is in layers below PDUR and above Communication Drivers layer then its called N-PDU. Whenever the PDU is below Communication Hardware Abstraction then its called L-PDU.

Computation method

Computation method or compu method in short is used to transform the fixed point values in software into physical values which can be floating point values.

Compu method defines the relationship of converting internal values of SWC to real/physical values. Compu method is defined for a signal.

There are mainly three categories of compu methods:

Linear: This type of Compu method is used when value to be converted is of linear type. During configuration, we have to give ranges of raw values. Like minimum this value can be, maximum this value can go,Factor (which is the multiplication factor or its also called gain),Offset value.
Text Table: It is most simple type of compu method. It is a table of numerical values which represent some text which has some meaning.
Scale-Linear: It is a table of linear compu methods.

.cdd file

.cdd file is a Vector specific file which has information of Diagnostics configuration related information. Though it is vector specific but many tools are using it as standard. This file is used in CandelaStudio application which is by Vector. This should not be confused with Complex Device Drivers (CDD) 😀 , I was confused when I heard this term first time!

SIP

SIP or Software In Package is a term used by AUTOSAR engineers using Vector DaVinci Tool. It is a package of all the libraries and files useful for developing AUTOSAR software using Vector tools.

OSEK/VDX

This term is also common to hear from AUTOSAR engineers. OSEK is abbreviation of Offene Systeme und deren Schnittstellen für die Elektronik in Kraftfahrzeugen in german but in English it is : Open Systems and their Interfaces for the Electronics in Motor Vehicles. It is also a specification of operating system, communications stack and network management protocol used in Automotive applications developed by a consortium of german automotive companies like BMW, Robert Bosch GmbH, DaimlerChrysler, Opel, Siemens, and Volkswagen Group and the University of Karlsruhe. This project was later joined by French automotive companies like Renault and PSA Peugeot Citroën which had similar project called VDX (Vehicle Distributed Executive). Therefore, the name OSEK/VDX is used in combination.

Composition SWC

Composition is nothing but a group of SWCs which is assigned to a single ECU during System Configuration. Such grouping helps in abstracting the SWCs and standardizing software development that is what AUTOSAR aims for. This grouping is logical, it means there is no memory used in such grouping.

SWC

In AUTOSAR, the application is distributed in different SWCs. A SWC or software component is a component which has application logic. In AUTOSAR a functionality is encapsulated by a SWC. For example, power window operation in a car, for this a dedicated SWC will perform this functionality. SWCs communicate with each other or use lower layers by using ports with the help of RTE.

AUTOSAR has categorized SWCs based on its use into following types:

Application SWC: This is normal SWC which has only application or part of it.
SensorActuator SWC: It is a special type of SWC which handles sensors or actuators.
Parameter SWC: This SWC is used for sharing the calibration parameters of (ECU on which it is situated) to external devices. These SWC don’t have any internal behavior unlike Application SWC or SensorActuator SWC.
Composition SWC: discussed above.
Service Proxy SWC: It acts as a proxy to provide internal services to one or more remote ECUs. Its main use is to distribute the mode information of vehicle throughout the system.
Service SWC: It provides services specified by AUTOSAR of BSW module.
ECU Abstraction SWC: This type of SWC provides access to I/O by directly interacting with specific BSW modules. Other SWCs cannot be used for accessing the I/O, only this can be used.
Complex Device Driver SWC: This SWC is used to develop complex device drivers (CDD) for external devices which AUTOSAR don’t support or have some time critical operations.
Nvblock SWC: This SWC is used when interacting with NVRAM or memory.

Runnable Entity

Runnable entity is a part of SWC where the application behavior logic is written. Runnable is analogous to functions in C. In AUTOSAR, we create Runnable in a SWC during configuration and that runnable or function skeleton is generated in respective source files of SWCs. The name of skeleton function is the same that we give to the Runnable at the time of configuration. We need to write our code in this function/Runnable which will be then executed by AUTOSAR OS, this code is the application which the SWC should perform. Runnables also have variables and some Runnables also have trigger points which “calls” or triggers our runnable when a specific condition is met. Such conditions can be defined during configuration, conditions can be: Init Runnable which will be called on initialization,periodic call of runnable which can be used to send some periodic data, different RTE events based triggering, etc. Below is the example of runnable skeleton generated after configuration, this runnable is of Indicator SWC named Runnable1. Such runnable skeletons are generated in SWC .c files.

/*Indicator.c*/
void Runnable1(){
   /*runnable logic code here*/
}

Above figure shows how Runnables are encapsulated in SWC and how further SWCs are encapsulated by Composition. By looking at this figure we can understand that, how well the AUTOSAR abstracts and groups things for standardization. As we know that for every functionality in a ECU a SWC can be dedicated, but its behavior or implementation of the functionality is done using Runnable. There are generally three types of runnables:

Init Runnable: This runnable is called on init of ECU
Periodic Runnable: This runnable is used when we need to trigger this runnable periodically to execute some operation periodically.
Server Runnable: This runnable is used to implement server of Client/Server port interface.

Runnables can be configured to be activated on RTE events like:

Timing Event: As explained above, whenever a set time is reached this event will trigger/call dedicated runnable and it will perform the logic written in it. This is relatable to timer interrupt we use in general Embedded systems programming, where ISR is called on each timer overflow.
Data received event: As the name suggests, such event will trigger a runnable whenever data is received by ports.
Operation Invoked Event: This event is called by client when invoking a server runnable using Client/server port interface.
Mode Switch Event: Whenever ECU mode is changed, runnable can be triggered to perform some work. For example ECU shutdown mode, if ECU needs to perform some work before shutdown, then such event shall be hooked with that runnable which will perform the work before shutdown.
Data Received Error Event: Again this is self explanatory, whenever any error occurs in data receiving, a runnable can be called to take action on such event.
Data Send Completed Event: This event will trigger a runnable if data is sent successfully to take action further on data transmission completion.

MemMap File

MemMap file is a header file (MemMap.h) used to map functions or variables to specific memory locations in Flash memory or RAM to avoid wastage of RAM and organize variables or function blocks as desired.

Wastage of memory and way to resolve it

In general embedded systems programming, when we don’t use any ways to place variables or functions to desired memory addresses, then compiler uses default logic to place the variables in RAM. But such default logic can create unnecessary spaces in memory when different size of variables are placed nearby, which wastes RAM memory. So experienced developers use #pragma directive to place their variables or code block to desired location in memory which helps in reducing wastage of memory and organizing code and variables. Below is small code snippet to indicate normal ways of storing variable to specific memory address.

//General way of placing variable to 0x2000 address
#pragma location = 0x2000
int A;

Above method of placing variables or function blocks to desired address is most common method but this cannot be used in AUTOSAR. Because AUTOSAR aims in standardizing code and hence such “modifications” is not allowed in it. So to maintain standard and a way to implement above method, AUTOSAR uses MemMap File. It has macros which facilitates the placing of variables or code blocks at desired places. This file also uses #pragma directives enclosed by #define macros. Below is the example of MemMap header file:

#ifdef CAN_START_SEC_VAR_8BIT
         #undef CAN_START_SEC_VAR_8BIT
         #define START_SECTION_DATA_8BIT
#elif
/*Some more macros for different sections*/
#endif

#ifdef START_SECTION_DATA_8BIT
     #pragma section data "sect_8bit"
     #undef START_SECTION_DATA_8BIT
     #undef MEMMAP_ERROR

#elif CAN_STOP_SEC_VAR_8BIT
     #undef CAN_STOP_SEC_VAR_8BIT
     #define STOP_SECTION_DATA_8BIT 
#endif

#ifdef STOP_SECTION_DATA_8BIT 
     #pragma section code restore
    #undef STOP_SECTION_DATA_8BIT 
     #undef MEMMAP_ERROR
#endif

Above code snippet activates the section to be used for some variable which is 8 bit and used for CAN module. AUTOSAR implements and enforces a standard way of naming a macro in MemMap file. Below table shows syntax to be followed while editing or adding macros in MemMap file.

Memory type	Syntax of memory allocation keyword	Description
Code	[MSN]_START_SEC_CODE [MSN]_STOP_SEC_CODE	Should be used when mapping code to application block, boot block, etc.
Variables	[MSN]_START_SEC_VAR_NOINIT_[SIZE] [MSN]_STOP_SEC_VAR_NOINIT_[SIZE]	Should be used for all global or static variables that are never initialized
Variables	[MSN]_START_SEC_POWER_ON_INIT_[SIZE] [MSN]_STOP_SEC_POWER_ON_INIT_[SIZE]	Should be used for all global and static variables which are only initialized on Power on reset.
Variables	[MSN]_START_SEC_VAR_FAST_[SIZE] [MSN]_STOP_SEC_VAR_FAST_[SIZE]	Should be used for all global and static variables that can be accessed bit wise or frequently used or high number of accesses in source code.
Variables	[MSN]_START_SEC_VAR_[SIZE] [MSN]_STOP_SEC_VAR_[SIZE]	Should be used for all global and static variables which are initialized after every reset (normal use case)
Constants	[MSN]_START_SEC_CONST_[SIZE] [MSN]_STOP_SEC_CONST_[SIZE]	Should be used for global or static constants.

Above table shows MemMap file syntax, all the syntax starting and ending with “[ ]” are place holders where we should fill information from our side. For example [MSN] indicates the module name with which the variable will be used, like in above MemMap file example, we used “CAN” module and [SIZE] indicates the size of variable which again has standard names for corresponding variable size:

8 bit variables -> 8BIT
16 bit variables -> 16BIT
32 bit variables -> 32BIT
variables with unknown size -> UNSPECIFIED

How to use MemMap File?

There is a mechanism for using MemMap file in AUTOSAR. Below is example of using MemMap File:

#define CAN_START_SEC_VAR_8BIT
#include "MemMap.h"
static uint8 myvar;
#define CAN_STOP_SEC_VAR_8BIT
#include "MemMap.h"

Above code snippet depicts basic usage of MemMap file. The explanation for it is:

Whenever variable/code placing strategy is to be used, we define the macro of the name same as that of macro in MemMap file (in this case CAN_START_SEC_VAR_8BIT) suitable for the variable/code block (in this case size is the criteria) then the MemMap.h file has to be included which invokes the #pragma directive from MemMap file and activates the storage of variable as per the macro is defined in MemMap file and anything after this will be stored to consecutive addresses from given address in MemMap file.
To avoid storing of things other than our variable to consecutive addresses after activation we use another macro to deactivate this placing strategy by using same macro as that in MemMap file to stop strategy (in this case CAN_STOP_SEC_VAR_8BIT) and the default strategy is used to store variables until again other macro is not encountered by preprocessor. The advantage of this is, everything is carried out in preprocessor stage and hence errors are also reported before compilation.

Implementation Data Type

This is again a common term which any AUTOSAR engineer may encounter. This is analogous to typedef of C using which we can create a specific data type for suppose a signal of PDU. Lets say we want to transmit signal named Alive and the range of the signal is expected between 0 to 255 so we will create a Implementation data type in Configuration software like DaVinci Developer from Vector. Implementation Data type is used by Port interfaces which the ports follow while communicating with other entities. The structure of data and its tolerances and limits are all known at configuration time.

Ports and Port Interfaces

In AUTOSAR every communication between SWC and lower layers is accomplished by using ports. Port is a channel or connection using which data can be transferred between SWCs, or BSW modules. As AUTOSAR aims in standardizing, the data which will be transferred between entities needs to be known at configuration time, so Ports are no exception.

Ports belong to exactly one SWC at a time. The port may or may not be connected to other end. There are two types of ports:

Required Ports: This type of port is used when data is to be received or required or is expected from other entities.
Provider Ports: This type of port is used when data is to be transmitted or SWC is provider of some service to other entities.

Port Interfaces are interfaces which define the kind of information transmitted or received between two ports. Port Interfaces are like blue prints of ports which defines a “protocol” to be followed by port of SWC. Port interface is reusable i.e. they can be used by multiple ports. Port interface configuration is done at the time of system configuration and the ports which should adhere by the interface are assigned to those ports.

AUTOSAR differentiates between three types of Port interfaces:

AUTOSAR Interface: This a generic interface which we would create for ports of a SWC. It is used for interacting with other SWCs or SWC and ECU Abstraction Layer.
Standardized AUTOSAR Interface: A standardized AUTOSAR interface is predefined by AUTOSAR which is used by application SWC when interacting with BSW services like ECU Manager, etc.
Standardized Interface: This is also a type of interface predefined by AUTOSAR standard as C API. It used between BSW modules, between RTE and OS, etc.

There are generally 2 types of Port Interfaces:

SenderReceiverInterface: This is most simple type of interface which we can create. This type of interface is used when the data to be transferred between entities is asynchronous type. Asynchronous here means, data will be received by Require ports any time after initiation of request.
ClientServerInterface: This type of interface is used when data to be received is of synchronous type. Here synchronous means, client will request for data from server which will be providing. The server performs its operation and provides the required information to client. In this the server “works” only when client “triggered” it. In this the client waits till the operation is completed. In simple words, ClientServerInterface has a operation to be executed and a callback after completion whereas SenderReceiverInterface has data exchange.

Hardware Objects

Hardware Object term is used in relation to CAN bus. Hardware Object is a space in CAN controller RAM where the PDU will sit. When the PDU is situated in CAN controller’s RAM it is called as Hardware Object.

Hardware Object Handle

Hardware Object Handle (HOH) represents a abstract reference of CAN mailbox which has all the CAN frame parameters like DLC, CANID, and data. Upper layers cannot directly “create” CAN frame with data and that would contradict the hardware independence objective of AUTOSAR, instead a abstract reference is used which will ensure hardware independence by abstraction.

There are two types of Hardware object handles:

Hardware Transmit Handle (HTH): This HOH is used during transmission of CAN frame.
Hardware Receive Handle (HRH): This HOH is used during reception CAN frame.

HOHs are used by CanIf and are referenced in it based on CAN hardware buffer layout. HOH is used as argument while calling the lower layer CAN driver interface services.

Above figure shows how the references are intertwined within modules like CanIf, CAN Driver and CAN Controller. The arrow lines shown in the figure are references and not connections. Now I guess it is clear what CAN mailbox is and what Hardware Object is and how references are there.

Container concept in AUTOSAR

AUTOSAR aims to standardize software development process of ECU, hence it implements various documents and steps. Preparing such documents manually and maintaining them according to AUTOSAR standard is a tedious task. So to solve this problem, softwares are used where we can configure the AUTOSAR blocks and generate documents and code. In configuration, containers are used in GUI which holds the settings/information of a specific BSW block. For example, Com has list of PDUs and signals so each PDU has a container under Com module. So container is nothing but a place where we configure or store information related to a AUTOSAR block in configurator.

CAPL Script

CAPL script or CAN Access Programming Language is a scripting C like language which is used in interfacing with objects of panels in CANOe. For example a panel has a LED and LIN network, then you can write a CAPL script to simulate (also interface with real world devices) the conditions like what will happen on reception on LIN signal whether to light LED on panel or not.

Multiplicity

Multiplicity is related to container concept explained above. It indicates the number of sub containers/parameters that can be added under a specific container. It also indicates whether the sub container or parameter should be optional or mandatory.

The multiplicity values are of two types:

Upper Multiplicity: Upper multiplicity value indicates the highest number of sub containers that can be added.
Lower Multiplicity: Lower multiplicity value indicates the lowest number of sub containers that can be added under a container.

We can understand whether a sub container or parameter should be optional or unique by interpreting the upper multiplicity and lower multiplicity values. Below are some examples of multiplicity combinations and their meanings:

Lower Multiplicity	Upper Multiplicity	Meaning
0	1	Only one container/sub container can be added. This is optional.
1	1	Only one container/sub container can be added. This is mandatory.
0	5	Five containers/sub containers can be added. This is optional.
1	5	Five containers/sub containers can be added. Atleast one container is mandatory.
1	*	Infinite number of containers/sub containers can be added. But atleast one container is mandatory.

From table we can understand following things:

When both multiplicities are equal, their numbers indicates mandatory sub containers.
And whenever both multiplicities are unequal, then the lowest number of containers that can be added should match the lower multiplicity and the highest number of containers should match the upper multiplicity and it also means that, configuration of this container is optional.
And upper multiplicity with *(asterisk) indicates we can have infinite containers/sub containers. Example of this can be in Com module we can have n number of PDUs.

You will come across multiplicity term during BSW configuration. Multiplicity numbers are not directly generated in code instead the configuration which affects multiplicity is generated in code.

Assembly Connector

Assembly Connectors are used when communication needs to be taken place between SWCs within Composition SWC. These connectors connect the ports of SWCs that needs to be connected. These connectors are next step of ports configuration, all the ports of the SWCs which needs to be connected are connected by assembly connectors. You will use this while System Configuration.

Delegation connector

Delegation Connectors are used when some ports of SWCs need to be exposed to outer world of Composition SWC this exposure can be connection with other SWCs using Assembly connectors or connection with BSW. This is because, AUTOSAR don’t permit SWCs to communicate outside Composition directly, so to communicate outside the Composition and delegate data of inner SWCs to outer world, delegation connectors are used. Again, you will use this term during System Configuration.

I hope I explained above terms by giving simple explanation. The list of terms given here is not exhaustive more will be added and this page will be updated often. So stay tuned 🙂

If you want to understand any term which is not listed here, please do let me know in the comments, I will definitely add a description of it.

If you have any query please ask in comment box below. If you find any information incorrect then please report it to me.

Thank you for reading! 🙂

Port Interfaces in AUTOSAR