Hello Readers,
My name is Aravind B. N., and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunities to work on various projects, these experiences have inspired me to involved in learning of Autosar is developing vehicle software with a clear explanation of functional software development Part-2.
"Functional Software Development"
In the stages the vehicles functional software is described as a system. This system is further divided into sub functionalities known as SWCs(Software Components). These Software Components exchange information (Data Elements), with SWCs through predefined interfaces (Ports).
In a sense the entire communication between the Software Components is managed by the VFB. Since it hasn't been determined yet which software component is assigned to which Electronic Control Unit this perspective is purely logical. The VFB represents communication within and, between ECUs without any knowledge of the underlying technologies. This allows for development and utilization of application software regardless of the hardware.
Once all SWCs and interfaces are established and defined they are distributed to their ECUs.
First the ECU specific RTE implements the Virtual Functional Bus(VFB). The Run-Time Environment is responsible, for managing communication between software components and with the assistance of the operating system handles the execution of these components.
A Runnable Entity serves as the execution unit. Is ultimately implemented as a C function. The developer configures function calls to these entities, which are later executed by the RTE. For instance this could occur periodically or spontaneously in response, to receiving a data element.
For communication interfaces AUTOSAR provides ports. There are two methods distinguished in this context;
In SR(Sender Receiver) communication data elements are sent from one software component to another. This form of communication is widely utilized among application software components.
Syntax example; When it comes to CS (Client Server) communication the Client can initiate a call, to a Servers operation either asynchronously or synchronously. This can be likened to a function call. Is commonly used between applications and Basic Software services such as diagnostics and memory management.
Syntax example; In order to perform an operation the SWC interfaces with its runnables, which are detailed in a created SWC Description. However AUTOSAR does not provide any capabilities, for describing the behavior.
This image demonstrates how logical system components are mapped to hardware components, within the software architecture specifically in the AUTOSAR framework.
On the side of the image there are two boxes labeled "logical" representing logical software components. One box is labeled "Door". The other is labeled "Light." These boxes represent the software functionality for controlling a door and a light. Below these components there is a dashed outline labeled "VFB," which stands for Virtual Functional Bus. The VFB serves as a layer within AUTOSAR that enables software components to communicate with each other in a hardware manner. The icons, below the components depict sensors or actuators associated with the door and light functions.
On the side of the image you'll see two gray boxes labeled "physical." These represent the hardware units, in a vehicle; one is for the Door Electronic Control Unit (ECU). The other is for the Roof ECU. An ECU is responsible for running software components in a vehicle. Within each ECU box there are boxes that correspond to the components mentioned on the left side. For example "Door" is within the "Door ECU" box and "Light" is, within the "Roof ECU" box. This demonstrates how logical software components are allocated to ECUs.
Underneath the software components, within the ECUs there is a designated area called "RTE" which stands for Runtime Environment. The RTE plays a role in the AUTOSAR architecture by implementing the Virtual Function Bus (VFB) on an ECU. Its main function is to establish communication interfaces between software components and the underlying hardware as facilitating communication between different software components within the same ECU or, across multiple ECUs.
The arrow connecting the physical sides represents the process of linking the components to the physical ECUs. This step plays a role, in software development as it determines how software functions are distributed among different ECUs in a vehicle. The mapping process takes into account factors like ECU resources, communication bandwidth and system latency to ensure performance and efficiency of software functions, in the vehicle.
In this image two different approaches, to software development for a Door Electronic Control Unit (ECU) are compared. On the side we see a method without AUTOSAR while on the right side we have an approach that incorporates AUTOSAR.
The left portion of the image represents the software development approach for a Door ECU. It includes a block called "Main Function" which represents the functionality of the software. Below this block there are three interfaces; DIO (Direct Input/Output) μC (Microcontroller) and CAN (Controller Area Network).
On the side of the image there is a code snippet written in C language (fct_Door_Left). This function is called cyclically by the program loop. It interacts directly with the hardware. It reads the state of the door from an I/O port (ReadIOport). Sends a message, over the CAN network (SendCANmessage).
When it comes to AUTOSAR there's an approach shown on the side of the image for the Door ECU. In this approach the software component (SWC) is identified as "Left Door." The block labeled "Runnable; Door Left" represents a piece of code that runs periodically specifically every 100 milliseconds as indicated in the code snippet. The RTE (Runtime Environment) block serves as the AUTOSAR layer that separates hardware details, from software components enabling hardware software development. Below the RTE you'll find layers such, as IoHWAb (I/O Hardware Abstraction) PDU (Protocol Data Unit) COM (Communication) and DIO DRV (Direct Input/Output Driver). These layers abstract the hardware interfaces.
The code snippet, on the right demonstrates a function called "Door_Left" that follows AUTOSAR standards. This function utilizes RTE calls like "Rte_Call_DoorIOState_Op_Get" and "Rte_Write_DoorState_Door" to interact with the door state. These RTE calls provide an abstraction layer allowing for portable software development by abstracting direct hardware manipulation.
The image illustrates the contrast, between embedded software development, where software is closely tied to hardware and AUTOSAR based development. In AUTOSAR based development software components are decoupled from the hardware through interfaces and abstraction layers. This approach enables reusability, maintainability and scalability of applications.
Top comments (0)