Introduce the basis for exchanging data between AUTOSAR components

What is the VFB and what does it do?

In AUTOSAR, applications are designed as a combination of interconnected SWCs. The virtual function bus is the communication mechanism for these SWCs to interact with each other. During the system configuration phase, SWCs are mapped to specific ECUs. Therefore, the virtual connections between SWCs are mapped to local connections (on the same ECU) or communication mechanisms based on the vehicle network, such as CAN, Flexray, etc. The interface between SWCs and between SWCs and BSWs is called RTE.

The following figure shows the system configuration process: map each SWC to the corresponding ECU. Depending on the system requirements, different SWCs may be mapped to the same ECU (communicating through the local RTE interface) or to different ECUs (the communication RTE interface must be based on CAN, Flexray and other vehicle networks).

A SWC contains some or all of the functional modules. A SWC consists of code implementation and formal description files associated with it. The concept of virtual functional bus realizes the strict isolation of application software and basic software. The SWC that implements the application software is largely independent of the communication mechanism through which the SWC can interact with other SWCs or hardware (such as sensors and actuators).

The VFB can be used to specify the complete communication of the system, including all providers (Provider or Server) and users (Receiver or Client). Therefore, the VFB can be used to check the credibility of software component communication. The communication connection and the connected SWC are saved in the same description file, which will be used in the next few stages (mapping, software configuration, etc.).

VFB needs to provide all basic services to SWC that implements vehicle functions:

• Communicate with other SWCs in the system

• Communicate with sensors or actuators in the system

• Access standard services such as reading and writing NVM

• Respond to changes in operating modes, such as changes in the power state of the ECU

• Interaction with calibration and measurement systems in the system

Port and Interface

The central element used when building a system at the VFB level is the SWC. A SWC has well-defined Ports through which the SWC can interact with other SWCs. A Port always belongs to only one SWC and acts as an interaction point between that SWC and other SWCs that communicate with it.

The following figure shows an example of a SWC definition. The SWC is called SeatHeatControl, which controls the heating unit in the seat based on several inputs. In this example, the SWC requires the following information as input:

• Whether the seat is occupied (via port "SeatSwitch")

• Seat heating temperature setting (via port "Setting")

• Power status (via port "PowerManagement"), which can disable seat heating in certain situations

The SWC controls:

• DialLED related to seat temperature control (via port "DialLED")

• Seat heating element (via port "HeatingElement")

Furthermore, the SWC has calibration capabilities (via port "Calibration"), requires the state of the ECU (via port "ecuMode"), and requires access to the NVM (via port "nv").

Port is mentioned many times in the above examples. What is a port? What is its function?

As mentioned above, port is the interaction point between SWCs. Port and interface always form the bridge for communication between SWCs. Port can be simply understood as port, and interface can be understood as the cable connecting the port.

A port can be a PPort, RPort, or PRPort. A PPort or PRPort provides data defined in a port-interface, while an RPort or PRPort retrieves data defined in a port-interface.

The following table lists some of the port and interface types:

The above only lists some of the commonly used Port-Interface types in AUTOSAR. For more types, you can refer to the AUTOSAR manual.

When a SWC's PPort provides a client-server interface, the component is responsible for implementing the operations defined in the interface.

In the example below, the SWC "SeatHeating" implements the operation "SetPower", which can be called by other SWCs through the port "Setting". The SWC "SeatHeatingControl" calls the operation "SetPower" through the port "HeatingElement".

When a SWC provides a sender-receiver interface, the component is responsible for providing the values ​​defined in the interface.

In the following example, the SWC "SeatSwitch" provides the Boolean value for "PassengerDetected" through port "Switch". Similarly, the SWC "SeatHeatingControl" can read the state of "PassengerDetected" through port "SeatSwitch".