AUTOSAR basics

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!

Simplified block diagram of AUTOSAR architecture

What is AUTOSAR?

What is AUTOSAR?

Translate in your language


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.


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!