AUTOSAR Basics

AUTOSAR RTE (Run Time Environment)

AUTOSAR Run Time Environment (RTE)

Translate in your language

What Is Run Time Environment In General?

Run Time Environment (RTE) also called as run time system is a execution environment which helps a specific language or software to run and get accesses to hardware. For example, JAVA language uses JVM (JAVA Virtual Machine) or Python uses Python Interpreter. RTE helps the program to run correctly on hardware by abstracting different low level allocations like function, variables to memory mapping, etc. RTE also have software libraries, environment variables which are used by running processes. RTE is mostly used by high level languages. 

We being a Embedded system programmer, don’t work with RTE and C language don’t require any RTE for running on embedded systems hardware so we are not unaware of it, but AUTOSAR uses a RTE not in the sense of RTE for high level languages but in a different way, lets see it.   

Run Time Environment (RTE) in AUTOSAR

The Run time Environment is at the heart of AUTOSAR ECU architecture. The RTE along with AUTOSAR COM, OS and other BSW modules is the implementation of VFB Concept for a ECU. All the ports and interfaces are implemented in RTE which thereby realize the communication between SWCs and also act as a means by which SWC can access BSW modules like OS and Communication services. As described above, RTE has interfaces using which the Runnable in SWC communicates with other SWC or BSW module. RTE maps the Runnables to OS tasks as configured during RTE configuration and executes runnables either in same task or differently, RTE also handles the work of triggering runnables (if conditions are met) using RTE events as configured in SWC configuration. RTE is strongly linked with BSW scheduler due to same OS task may be used for both scheduling of SWCs and schedulable entities (also called main processing functions) of BSW module. Logically RTE is divided in two parts:

  • communication between SWCs
  • scheduling of SWCs

RTE and BSW scheduler is generated for each ECU to ensure optimal operation and customization at ECU level. In this article we will focus on RTE for SWC.

Simplified block diagram of AUTOSAR architecture
Fig. Simplified AUTOSAR layered architecture

AUTOSAR is developed with a vision to create a architecture to have hardware independent application which is relocatable and reusable, without RTE this cannot be achieved because RTE acts a glue layer to connect SWCs in application layer with BSW layers, to achieve this RTE is separately generated for each ECU. RTE is not reusable, because it is generated to match the application requirements and if application is changed the RTE also needs to be changed. All SWCs are portable and reusable except the sensor/actuator type of SWC which is highly dependent on ECU hardware. RTE is generated after integration of SWC, so RTE is responsible to make sure that system is working as expected by ensuring the communication of SWCs (between themselves as well as with BSW modules) is smooth irrespective of where the SWCs are deployed. RTE supports both SWCs with source code as well as SWCs with only object codes. RTE don’t support any runtime reconfiguration, i.e. every communication between SWCs and BSW modules must be configured before RTE is generated.

Uses or Application of RTE

RTE is one of the most important element of AUTOSAR because it performs vital operations useful for application. 

Some uses of RTE:

  • RTE Implements virtual function bus which helps in connection of SWCs within ECU and SWCs outside ECU (via physical network connection between ECUs)
  • RTE Implement communication paths using ports and interfaces which are used to connect between SWCs and BSW modules of lower layers as per configuration.
  • Invoke and support multiple Runnables of SWC based on different RTE events as per configuration.
  • Include any SWCs from any project during configuration and perform the operation as expected to accomplish the SWC reuse ability and portability feature of AUTOSAR. 
  • Enable instantiation of SWCs and support single as well as multiple instantiation of SWC
  • As RTE handles the execution of runnables in OS task, it implements a activation offset which is used to optimize CPU load,memory,etc in case of time triggered runnables mapped in same OS task. Because time triggered variables need to be executed on configured time and avoid conflicting of runnables by overlapping, RTE uses activation offset. RTE handles this by calculating the maximum period of task which is the Greatest Common Divisor(GCD) of all runnables and it assumes that any runnable maximum execution period would be lower than GCD.
  • RTE also notifies runnables of any interrupt (if configured) occurred at lower layers, but this doesn’t mean runnables will be executed in ISR! 😀 Runnables are subset of SWC and SWC is completely independent of lower layers.
  • RTE has to ensure data consistency when sharing variables among runnables of same SWC, or inter partition SWC or intra partition SWC or even in communication between SWC of different ECUs.
  • Communication between SWCs (in Sender-receiver communication) is not restricted to only peer to peer communication but also in 1:N (communication of a SWC with many SWCs) or N:1 (communication of many SWCs with one SWC) combination. RTE takes care to prevent any conflict if senders transmit at same time to one receiver or vice versa.
  • RTE notifies the sender of successful signal transmission if TransmissionAcknowledgementRequest is requested by sender. This notification doesn’t guarantee that receiver has received the signal successfully.

Generation of RTE

Generation of RTE is the most important and tricky step in any AUTOSAR based project. The result of generation of RTE is various files but we will consider only two files which are important: 1. Rte.c file, 2. Rte.h file. This is the most common RTE generation result but some integrator also prefer to generate separate RTE files (.c and .h) for each SWC which is further included in main RTE files just for ease of managing the RTE files of project, such generation options may vary based on AUTOSAR GUI tools. RTE generator can be a separate tool or a integrated tool which completely depends on the tool vendor you use. For example, in case of Vector DaVinci, the DaVinci developer is used for SWC,Runnables,IDT creation, etc. whereas DaVinci configurator is used to configure the BSW and generate RTE. In any AUTOSAR based system, RTE is generated separately for each ECU because SWCs of each ECU may have their own unique requirements and hence RTE is customized to cater such requirements.  

RTE generation process
Fig: RTE generation methodology

Above figure gives RTE generation steps with respect to SWC and RTE generator software. Lets see each step in detail:

  1. Collection of available SWC implementations: This step includes collecting of SWC description files (if intend to reuse old SWCs) and their respective Composition SWCs and use them further. Or we can also create new SWC implementation and use it for further step.
  2. Configure System: This steps combines the SWCs from old step and System (whole vehicle ECU network) is configured which has different Composition SWCs of different ECUs and other system constraints. In this step all SWCs are mapped to their respective ECUs. 
  3. System Configuration Description: This is arxml file which contains the details of ECUs of whole System (Vehicle) which is generated after System Configuration. For more information on System Configuration description check out this link
  4. Extract ECU specific information:This step extracts SWC description and other details of a single ECU unlike System configuration description file which contains information of all ECUs in a vehicle. The output of this step is called ECU Extract arxml which is next step. For more information on ECU Extract check out this link.
  5. Generate ECU Configuration: This step involves configuration of AUTOSAR lower layers (below RTE) of BSW modules like Com Services,etc. The output of this step is again a arxml file which contains the total information of a ECU like BSW configuration, SWC configuration, etc which happens to be next step of RTE generation process.
  6. Generate RTE: This is important step in RTE generation. In this step, all runnables are mapped to OS tasks, all delegation connectors are mapped to actual signals, etc. The output of this step is Rte.c and Rte.h files which can be roughly called RTE layer of AUTOSAR. I am calling roughly because there are some other files associated with RTE layer too.This step also generates BSWMD (Basic Software module description) file which contains information of different features of RTE. 
  7. Compile RTE: As the name suggests, in this step the RTE files are compiled (considering Runnable code is written) and object files are generated which are then linked with other compiled BSW and SWC files to generate a executable which can be flashed to MCU. 

Above steps are repeated for each ECU of system. Along with RTE files, SWC files (<swc_name>.h and <swc_name>.c) are also generated for each SWC, some software also generates skeleton of runnable in the SWC .c file and a function prototype in SWC .h file. SWC files will have #included with necessary header files (but this depends on the Configurator software you are using). All RTE files are generated in adherence to MISRA-C standard, although some MISRA violations are allowed 😀 but such instances are documented in comments. RTE source file has RTE calls required by application and other layers and RTE header files have prototypes for those calls.

As the main aim of AUTOSAR is the reuse ability of SWC, hence RTE supports compatibility of SWC for different AUTOSAR versions, provided that SWCs are available in their source file and not object code. The compatibility and reuse ability of SWC is not limited to only AUTOSAR version, but also tool vendor independence i.e. SWC from different tool vendors can be used provided their source code are available.

Some information on RTE API

RTE provides various APIs using which SWC can access data from other SWCs or lower layers.RTE APIs are easily distinguished in source by seeing the Rte_ prefix of any function call. RTE APIs are classified into two types:

  1. Direct API: It is a type of RTE API which is used when efficient (zero runtime overhead) invocation is needed. These APIs are generated for each port and application can directly use it by invoking the API name in runnable. Such APIs can be optimized for SWC while mapping APIs. Typically direct APIs are implemented as macros hence its not possible to get the address of the RTE API to use with function pointer in C, there are some hard ways however by which we can use function pointer if we want in our application.
  2. Indirect API: It is a type of RTE API where a API is invoked indirectly using a port handle. Such type of API is useful when there are multiple ports of single port interface so we can have an array of port handles of that interface and the same RTE API can be used for accessing multiple ports by just passing the respective port handle while invoking.

Both direct and indirect API calls will generate same result just the invocation way differs. Within SWC we can have both indirect or direct API implementation.

Relationship between files after RTE generation

After RTE generation, RTE generator tool generates many files of which the header files has relationship with other files i.e. those files are #included in different files. Lets see the files and their relationship with other files. Files generated :

  1. Rte.h: This file defines fixed elements that do not need to be generated for each ECU, because of this RTE generator software don’t generate this file again and again. However we can tailor this file to meet our application if needed. This file includes Std_Types.h file. 
  2. Std_Types.h: This file is the standard AUTOSAR file that defines basic data types like platform specific implementations of unsigned and signed integers and provides ways to access compiler abstraction.
  3. Rte_Main.h: This is Life cycle header file which has function prototypes of RTE life cycle API like Rte_Start and Rte_Stop . Some software also adds more life cycle APIs for initialization of RTE memory, etc. This file includes Rte.h file.
  4.  Rte_<swc_name>.h: This is application specific RTE header file, as the name explains the prefix of file name is always Rte_ and the suffix is the SWC name for which this RTE application file is associated. This file contains the function prototypes of RTE APIs, data structures and function prototypes of Runnable used in SWC associated with the SWC. This file includes Rte_Type.h and Rte_DataHandle.h file.
  5. Rte_Type.h: This file contains RTE specific type declarations derived from Implementation Data Type which is configured during SWC configuration. This file also contains AUTOSAR data types useful for RTE APIs. This file includes Rte.h file.
  6. Rte_DataHandle.h: This file contains Data Handle type declarations necessary for the SWC data structures. This file don’t contain any symbols which will use memory. 
  7.  Rte_<swc_name>_Type.h: This is also called Application types header file, it contains the application related constants like range values or enum values used in SWC. Again the file name will include the SWC name in spacer. This file includes Rte_Type.h file.

I hope I have explained RTE in simple language, although this is not enough but atleast it will give you a overview of RTE, its generation process and relationship between different files associated with RTE.

If you find any mistake I request you to please report me. If you have any doubt please ask it in comments section.

Thanks for reading 🙂

Like us on Facebook!

Subscribe for newsletters!

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. 

signal-in-CAN-frame
Our signal in data field of CAN 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.

PDUSDUPCI_pack
Figure indicates the packing of SDU and PCI in a PDU while transmitting PDU from Higher layers to lower layers

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

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 BMWRobert Bosch GmbHDaimlerChryslerOpelSiemens, 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:

  1. Application SWC: This is normal SWC which has only application or part of it.  
  2. SensorActuator SWC: It is a special type of SWC which handles sensors or actuators. 
  3. 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.
  4. Composition SWC: discussed above
  5. 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.
  6. Service SWC: It provides services specified by AUTOSAR of BSW module.
  7. 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.
  8. 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.
  9. 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*/
}
Composition with SWC and Runnable
Figure depicts the hierarchy of Composition, SWCs, Runnables

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:

  1. Init Runnable: This runnable is called on init of ECU
  2. Periodic Runnable: This runnable is used when we need to trigger this runnable periodically to execute some operation periodically.
  3. 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:

  1. 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.
  2. Data received event: As the name suggests, such event will trigger a runnable whenever data is received by ports.
  3. Operation Invoked Event: This event is called by client when invoking a server runnable using Client/server port interface. 
  4. 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.
  5. 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.
  6. 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 typeSyntax of memory allocation keywordDescription
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:

  1. 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.
  2. 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.
  3. 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: 

  1. 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. 
  2. 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:

  1. Hardware Transmit Handle (HTH): This HOH is used during transmission of CAN frame.
  2. 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. 

HOH_explaination
Fig: Hardware Object Handle references in different modules

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.

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 MultiplicityUpper MultiplicityMeaning
01Only one container/sub container can be added.
This is optional.
11Only one container/sub container can be added.
This is mandatory.
05Five containers/sub containers can be added.
This is optional.
15Five 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 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! 🙂

Like us on Facebook!

Subscribe for newsletters!

Virtual Function Bus (VFB) Concept

What is Virtual Function Bus (VFB)?

Translate in your language

This will be very small article as VFB is easy and there is nothing much to be explained in it. But as I am categorizing small parts of AUTOSAR (which is like ocean! 😀 ) I thought VFB to cover in separate post for ease of my readers. This concept would be very helpful while learning about RTE layer.   

AUTOSAR is based on layered architecture in which SWCs laying in application layer communicate with each other. The communication can be possible not only in same ECU but also SWCs of other ECUs in a system (vehicle).  The communication mechanism to achieve this functionality is basically called as Virtual Function Bus or VFB in short, it is implemented in RTE layer of AUTOSAR.  Its called “virtual” because there is no physical connection between SWCs, instead the SWCs of a ECU communicate with SWCs of other ECUs in a system(vehicle) using low level communication bus like CAN or FlexRay. AUTOSAR handles all the low level matters to let the ECUs talk with each other as if there is a virtual link between them. Because of this SWC is independent of actual underlying hardware and hence relocate ability of SWCs is possible i.e. the same SWCs can be used on any ECU with any hardware platform.

AUTOSAR communication between SWCs due to VFB
Fig.1: Communication between SWCs across different ECUs with the help of VFB

Figure 1 depicts the VFB concept in simplified way. As can be seen from above figure, the SWCs in same ECU can communicate with each other and also with SWCs in other ECUs of a system. Technically, communication between the SWCs of same ECU is called Intra-ECU Communication whereas the communication between SWCs of different ECUs is called Inter-ECU Communication. Intra-ECU communication is realized virtually by defined function calls in RTE on the other hand the Inter-ECU communication is realized by using the underlying communication bus like CAN or FlexRay through COM Stack along with RTE. If the ECUs use different communication bus, then a Gateway is required for translating data from one bus type to another bus type.

As AUTOSAR provides a standardized way of ECU software development, the System Configuration Description has all the information of the SWCs of all ECUs in a system. Each ECU has customized RTE layer which implements the VFB for its respective SWCs. VFB helps in separating the SWCs and the underlying infrastructure thus making SWCs completely hardware independent.

VFB provides mechanisms for following services which are used by SWCs :

  1. Communication to other SWCs in the system.
  2. Communication with Sensors or actuators in the system.
  3. Providing access to standard services such as reading/ writing to memory.
  4. Responding to mode changes.
  5. Communication with external calibration and measurement instruments.
I guess I explained VFB, if you have any questions comment them in comment box below.

Thanks for reading 🙂

if you find any incorrectness in the information of this post or you want to give general feedback then please report me.

Like us on Facebook!

Subscribe for newsletters!

AUTOSAR Basic Software (BSW)

AUTOSAR Basic Software (BSW) Tutorial

Translate in your language

In this article we will see the AUTOSAR BSW (Basic Software) layer ( the layer below RTE). it is one of the important layers which helps application layer to use, communicate with different peripherals of MCU. If you are new to AUTOSAR then I recommend you to check out introductory article. The BSW configuration which we do in Configurator software like Vector DaVinci Configurator is actually configuration of this layer which is below RTE layer. We have already seen the AUTOSAR layered architecture in brief, today we will see it in detail. 

Fig: AUTOSAR detailed layered architecture

Above figure shows detailed AUTOSAR Layered architecture. Lets summarize it.

  • The mild black layer is the microcontroller on which the AUTOSAR would work.
  • The blocks in red color lies under MCAL (Microcontroller Abstraction Layer) which has drivers for accessing peripherals. MCAL is the lowest layer of BSW, this layer is highly MCU dependent which means, this blocks in this layer will change on change in the MCU.
  • The layers in Green color (except CDD) lies under ECU Abstraction Layer. Abstraction in this case means to hide lower level details of the module and just expose APIs to upper layers for implementing functionality. This layer abstracts the MCAL layer from upper layer and provides APIs for accessing external as well as internal drivers. ECU abstraction layer is useful for making upper layers ECU hardware independent.
  • Next layer is the CDD (Complex Device Drivers) which connects SWC from application layer directly with the MCU via RTE. It is useful for writing functions/drivers of peripherals/external devices not defined in AUTOSAR or functions which requires very high timing constraints beyond OS timer minimum tick resolution. But this layer is highly hardware dependent and hence there is very less scope of reuse ability or portability.
  • The next layer is the Services Layer (all blocks in blue) which is the top most layer of the BSW. This layer provides basic services for application, RTE, BSW modules. Services like: Operating system functionality, Communication services, Memory Services (for NVRAM), ECU state management, etc.

We will see each block of each layer in detail in my future articles.

Internal and External Drivers in AUTOSAR:

In AUTOSAR context, there are two types of driver based on peripheral used they are: internal and external drivers. Internal drivers are used to access internal peripherals located in microcontroller peripherals like Internal EEPROM, ADC,etc. External drivers are used to access external peripherals located outside the micrcontroller like external Flash, EEPROM, Watchdog, etc. The internal driver lies in MCAL layer whereas the external driver lies in the ECU abstraction layer. There are exceptions for some external devices like memory mapped memories, which can be accessed by microcontroller directly and hence drivers for such devices lies in MCAL.

Concept of Interfaces, Handlers and Manager:

AUTOSAR also implements the concept of Interfaces, Handlers and Managers. Please don’t confuse this with Port Interfaces 😀 ! The interfaces lies in the ECU abstraction layer whereas the managers lies in the Services layer. The interfaces provides a functionality to abstract the lower level modules and exposes a generic API access which can be used by upper layers. Interfaces provides access to specific type of device irrespective of number of devices existing of same type and independent of hardware. The handlers control the concurrent, multiple and asynchronous access of one or multiple clients, handlers also performs buffering,queuing etc.The handler functionality is often implemented in the driver or interface. A manager offers specific services to multiple clients. It is required in all cases where only handler is not sufficient. For example NVRAM manager controls the accesses to internal/external Flash memory.

Lets start learning about all layers in detail.  

1. MCAL (Microcontroller Abstraction Layer): 

This layer consists of following module/blocks:

  • Microcontroller Drivers: This module has internal drivers for accessing the internal peripherals of the MCU like Watchdog, General purpose Timers, or have functions for direct access to MCU like CoreTest.
  • Memory Drivers: This module has drivers for accessing on chip memories like internal Flash, internal EEPROM, or memory mapped devices like external flash.
  • Crypto Drivers: This module has drivers for on chip Crypto devices like SHE, HSM.
  • Wireless Communication Drivers: This module has drivers for wireless network systems (in – vehicle or off board communication).
  • Communication Drivers: This module has drivers for on board communication like SPII2C, etc and also has the drivers for Vehicle communication like CANFlexRay.
  • I/O Drivers: This module has drivers for accessing and using the I/O pins of MCU including digital and Analog, PWM.

2. Complex Device Drivers Or CDD: 

This module useful in implementing non standard functionality within BSW stack. There can be many cases when we need to implement some functionality which is not supported by AUTOSAR, so CDD is used for such cases.  Or if a functionality requires strict timing constraints which may be lesser than the minimum timing of AUTOSAR OS resolution then Complex Device Drivers module is useful, as it directly helps connecting the MCU with the application. 
But complex drivers functionality is highly MCU and application dependent and the code may not be easy to port.

3. ECU Abstraction Layer:

ECU abstraction layer helps in achieving ECU hardware independence (hardware independence not only of MCU chip but different external peripherals of ECU board also). Lets look at the blocks in this layer:
  • I/O Hardware Abstraction: In real life ECUs, the I/O peripherals can be on chip or on board and the ECU hardware layout like MCU pin connections or pin inversions may be complex. In conventional software writing, we would have to consider such low level details also, but in AUTOSAR its not. This module abstracts such low level details from Application and only provides APIs for using the I/Os. This is MCU independent(because it just points to lower level drivers) but is ECU hardware dependent because it uses external drivers for on-board peripherals, which if changed then I/O hardware abstraction for it will also change.
  • Communication Hardware Abstraction: This module abstracts the location of communication controllers and the ECU hardware layout. The application don’t know about which communication controller(in case of CAN) is used or which pin is used or even which type of communication bus is used whether it is CAN, FlexRay, or other it just “understands” the data which will be transmitted and received irrespective of communication controllers selected is on chip or on board. This module is used for achieving such level of hardware independence. It gives APIs which will be called by respective modules and perform data transmission or reception.
  • Crypto Hardware Abstraction: This module abstracts the crypto functionality by hiding the information of the Crypto used (internal , external device or software based). Again upper layers are unknown of the type of Crypto used or even which Crypto is used like whether it is on-chip or on-board or coded in software. This module provides mechanism for accessing the Crypto devices. 
  • Memory Hardware Abstraction: This module also abstracts the location of the memory device used. The memory can be on-chip or on-board and the on-board memory may have different ECU hardware layout(like the memory chip differences) but all this information is abstracted from application as it only knows about data and has no control over the type of memory device to be selected.
  • Onboard Device Abstraction: This module provides abstraction from ECU specific on board devices. This module contains drivers for on board devices which cannot be called as sensors or actuators or timers like internal or external watchdog timers.     

Till here did you had a WOW moment? if not, then please read again all the things above 😀 . I had a WOW moment when I first understood this, because it is so intelligently designed and the level of hardware independence ECU abstraction layer offers is amazing.

4. Services:

  • Communication Services:  This is a group of modules for vehicle network communication which aims at providing uniform services for network management, providing uniform interface to vehicle network for communication and diagnostic communication, also to hide protocol and message properties from the application. Communication Services interfaces with the communication drivers(in MCAL) with the help of Communication Hardware Abstraction (as discussed above). This is MCU and ECU hardware independent but dependent on bus type. So, some part of these services may change if the bus type (CAN, FlexRay, etc) is changed. For more information on communication services you can check out this page.
  • Off board Communication Services: This is a group of modules for vehicle to outer clients communication via an adhoc wireless network. It has three blocks used for implementing different functionalities. This module provides a uniform interface for Wireless Ethernet network by hiding protocol and message properties.
  • Memory Services: This service consists of one module, the NVRAM manager. It is responsible for the management of non volatile data (read/write from different memory drivers). Generally, application requires storing data in memory for future use, so this module is used to implement this in a uniform way and provide abstraction from memory locations and lower level properties. Memory Services provides mechanism for non volatile data management saving, loading, checksum, etc. This is MCU and ECU hardware independent and is highly configurable.
  • System Services: This is a group of modules which can be used by modules of all layers. Examples are Real Time Operating System, Error messenger. These services can be some MCU dependent or may support special MCU capabilities (like Time Service), partly ECU Hardware and application dependent.

In this way the moderately detailed discussion on BSW ends, I hope I explained it in easy language. Don’t worry If you don’t understand some terms you will understand it soon by reading future articles 🙂 .

 If you have any doubts please comment it below.

Like us on Facebook!

Subscribe for newsletters!

AUTOSAR process

Getting started with AUTOSAR based project

Getting Started With AUTOSAR Based Project

Translate in your language

AUTOSAR seems daunting for new developers 😀 I got a comment on my last article asking for information on getting started with AUTOSAR project, so I thought of covering it in this article first.
AUTOSAR has developed a layered architecture having standard specifications and software for AUTOSAR based ECU is developed is by adhering to those specifications. The software can be developed by software developers or the code can be generated by using different ECU configuration softwares like Vector’s DaVinci Configurator and Developer, K-SAR, etc. The former is for very advanced developers who understand whole AUTOSAR specifications in detail and latter is used by majority of developers (like me 🙂 ) because it decreases the time for development and there is no need to reinvent the wheel 😀 . In this option, you can generate code by configuring the application requirements in a software having GUI and then application code can be integrated in that generated code. This article will help in understanding the process of configuration of ECU based on AUTOSAR.

Please note that this article won’t provide detailed steps, but a abstract view of the process helpful for beginners.

The group of all ECUs and whole network in a car is called System and firstly the System is configured and then each ECU of that system is configured.

AUTOSAR process
Fig: AUTOSAR project process methodology (courtesy: autosar.org)

Above figure shows the process flow of ECU code generation from System configuration to ECU executable. Although above figure shows executable as .exe but it should not be confused with .exe file of Windows PC 😀 . Here .exe file means a general executable file which can be .elf, .bin, etc. AUTOSAR uses a specific file format for information exchange between different steps in the process. That file format is similar to XML but in AUTOSAR context its called .arxml ( AUTOSAR Extensible Markup Language ) file. The configuration software will interpret this file and generate code according to the information contained in this file.

Some Steps in configuration are:

  1. System Configuration: In this step, overall ECUs required in car(System) and their hardware is configured along with SWCs and the Compostion SWCs are mapped to respective ECUs. 
  2. Generate System Configuration Description: After configuration from first step, the output of the first step is called System Configuration Description file which is in .arxml file format. 
  3. ECU Extract generation: By using the System Configuration description arxml file from step 2 as input, a new file is generated which is called ECU Extract arxml file. It has information for single ECUs only unlike the System Configuration description file which has information of all the ECUs in a Car.
  4. ECU Configuration: In this step, the ECU Extract is used as input and respective ECU is configured according to application requirements. Configurations like BSW configuration, OS configuration etc.
  5. Generate ECU Configuration Description: This step will be used to generate the output of step 4 i.e. generate ECU Configuration Description arxml file which will be used further to generate Executable.

You can note file nomenclature, the files with suffix “Description” is the output of the respective step or process. For example System Configuration Description arxml is the output of System Configuration step.

What Information System Configuration Description File Has?

The System Configuration Description file (generated after System Configuration) have all the system configuration information such as :

  • ECUs present in the system
  • Communication systems interconnecting those ECUs and their configuration
  • Communication matrices which will indicate the data which will be sent and received for those communication systems. As AUTOSAR aims to standardize whole development, all the data, size,etc that will be transmitted or received needs to be configured at the configuration time.  
  • Definition of SWCs with their ports and interfaces and connections.
  • Mapping of SWCs(Software Components) to ECUs.
If you don’t understand some points above, don’t worry it will be cleared in future articles. This file serves as a input to ECU configuration. The ECU Extract file is the same as the System Configuration Description but having information related to relevant ECU only.

What Information ECU Configuration Description File Has?

The ECU Extract only defines the configuration elements that needs to be agreed by all ECUs in the system, but this is not sufficient to generate a code that can run on hardware. As this file don’t have any low level configuration information which can be used for configuring lower layers of the AUTOSAR architecture. So ECU Configuration description has that information which the configuration software utilizes and generates the .c and .h files which are further compiled and run on hardware.
 
I hope I explained the process in easy language. It was not easy to prepare process in such abstract way as AUTOSAR configuration is much deep and needs in detailed understanding. Stay tuned for future articles. 
 
Thanks for reading! 🙂

Like us on Facebook!

Subscribe for newsletters!

Simplified block diagram of AUTOSAR architecture

What is AUTOSAR?

What is AUTOSAR?

Translate in your language

Prerequisites:

Reader reading this and using AUTOSAR must have knowledge of Embedded Systems, C programming, layered Architecture, knowledge of communication protocols like CAN, I2C, etc. AUTOSAR is advanced stage of Embedded Systems so reader is expected to have knowledge of terms given above.


AUTOSAR stands for AUTomotive Open System ARchitecture which is a layered architecture with standard specifications founded by consortium of companies like BMW Group, BOSCH,Continental,Daimler,Ford,General Motors,PSA Group,Toyota, and VOLKSWAGEN.These are the core members of the AUTOSAR partnership who founded AUTOSAR. There are different types of memberships by which a entity can contribute to AUTOSAR development those are Core members, Premium Members, Development Members. I have listed above the Core members but there are many premium members who are engaged in tool development, service providers,etc. AUTOSAR aims to standardize the software development of the ECUs used in automotive applications.

AUTOSAR has implemented a layered architecture similar to OSI model. It has different layers to handle and abstract different operations of code. AUTOSAR is used for micro controllers which targets applications mostly in automotive space which utilizes CAN, Flex Ray, Ethernet etc. Being used in applications based on micro controllers, it is developed with a view to use least memory possible as micro controllers have resource constraints.

Simplified block diagram of AUTOSAR architecture
Fig: Simplified AUTOSAR Layered Architecture

Above image is a simplified AUTOSAR layered architecture. Its called simplified because there are also deep layers in each block which are hidden as this post discusses about AUTOSAR introduction. I will brief below about layers: 

  • Application Layer: This layer has the application code which resides in top. It can have different application blocks called as Software Components(SWCs) for each feature which the ECU needs to support according to application. For example, the functions like power window and temperature measurement will have separate SWC. This is not a norm, but it depends on the Designer. 
  • AUTOSAR RTE: This is one of the important layers of AUTOSAR, it provides communication between different SWCs and also between ECUs. Application layer uses this layer while communicating with other layers below using ports. For more information on RTE, I request you to read this article.
  • Services Layer: This layer provides different services for application to use. Services like: System Services, Memory Services, Crypto Services, Off board communication services, Communication services.
  • ECU Abstraction Layer: This layer provides ECU related abstractions. It contains different abstracted layers like I/O Hardware Abstraction layer, On board device abstraction, Memory hardware Abstraction, Crypto hardware abstraction, etc. to make applications hardware independent.
  • MCAL: This is Micro Controller Abstraction Layer it has drivers using which the above layers communicates with Micro controller hardware peripherals.

What Is The Need Of AUTOSAR?

Listed below are the problems faced in conventional ways of writing software for ECUs:
  • Embedded systems is a vast field having n number of semiconductor manufacturers, hardware and software platforms which can be selected based on application requirements. Due to such varieties, the development effort is tough and the portability of code is hard which further increases the development cost. 
  • A automotive is a complex machine which consists of n number of small embedded systems called Electronic control Unit(ECUs) so maintenance and development of code for such controllers is not easy. Further complexity is increased if different ECUs use different MCUs for meeting cost requirements, then each ECU will have different software as hardware platforms will be different. 
  • To partially standardize things, sometimes there is also a need to develop and follow custom created standard ( Custom standard means to develop a protocol for communication which is agreed by all ECUs in network ) to communicate with other ECUs. This is the conventional way of writing software which is very hard to maintain and has very less chance of code portability or reuse ability. 
  • A automobile has n number of parts which are manufactured by different companies called Tier 1 companies which supplies the parts to OEMs like BMW, Volkswagen, etc. Today almost all mechanical parts are becoming intelligent by adding ECU in them to increase control and efficiency. So those ECUs also need to have a common way of communication to communicate with the ECUs of OEM for this again a custom standard needs to be implemented and maintained. 

Hence a standardized software development infrastructure was needed to solve these problems and AUTOSAR solves this very well.

AUTOSAR uses a layered architecture which has different layers dedicated to perform different operations and abstraction. The application code is fully portable as AUTOSAR is designed in such a way that the application code is written independent of the hardware so the same application code can run on different hardware platforms. AUTOSAR has a layer dedicated to support hardware functionalities called MCAL (Micro controller abstraction) layer which has drivers for accessing the underlying hardware peripherals of MCU. As AUTOSAR provides standard way of communication, ECUs can communicate with each other irrespective of ECU developer (whether OEM or Tier1) and hence there is no need to maintain custom standard of communication. ECUs utilizing AUTOSAR can communicate with each other irrespective of underlying differences in hardware. Mostly chip manufacturers provides MCAL layer of AUTOSAR, but if they don’t then the developer needs to write his own MCAL layer or outsource to companies providing such services. 


Isn’t this a limitation as AUTOSAR has all drivers and layers implemented already?

Actually its not a limitation because, in today’s fast paced world, there are strict deadlines to be met for project completion. But considering above shared problems in conventional software design, its not possible to rapidly develop software to meet demand, so AUTOSAR is useful. Although AUTOSAR seems to have everything already implemented, but we have to manually write code for functionality of SWC in a Runnable of SWC.  

What if I am using a external peripheral device which AUTOSAR don’t support?

If you are using a device which is not supported by AUTOSAR, then you can use the Complex Device Drivers SWC for it. This layer gives you direct access to MCAL layer from application and you can directly interface the device with the ECU, but you need to develop its software by your own and due to its highly hardware dependency, its not reusable or portable like SWC.

Types Of AUTOSAR:

There are two types of AUTOSAR architectures named as Classic and Adaptive. The classic have all the modules which are generally needed for a application whereas the Adaptive can be configured and adapted according to application by removing unnecessary modules. Current Classic release version is 4.4.0 and current adaptive version is 19.03
 
I guess introduction of AUTOSAR is done till now. If you have any doubts or suggestions please let me know in comments.

Like us on Facebook!

Subscribe for newsletters!