DEV Community


Posted on

Introduction to AUTOSAR and its Impact on Automotive Software Architecture(part-2)

Dear readers,
My name is Sadashiv Balawad and I am working as Junior Software Engineer at Luxoft India. Luxoft gave me many opportunities to work on various projects, which inspired me to talk about the importance of Autosar and its impact on automotive software development (Part 2).

Client server Communication:
The above-mentioned client/ server The feature of the interface is that the client can cause the job to be executed by the server supporting the job. The server runs and instantly delivers the final result to the client (name of synchronous transaction), otherwise the client will check all transactions itself (asynchronous transaction call).

Sender-Receiver Communication:
The sender-receiver interface allows the content of an asynchronous message exchange instance in which the sender provides the statistics needed by one or additional recipients. The sender-receiver interface defines the type of data sent and returned.

Run-Time Environment (RTE): The RTE layer provides interface services for application software such as AUTOSAR software components and/or AUTOSAR sensor/actuator additives.
The RTE layer provides an indirect connection to the ECU via software. The software system contains many SWCs that do not follow a hierarchical structure but go to the component. The software component communicates with other components (in and/or in the ECU) via RTE.

The SWC interface is not ECU biased in any way. AUTOSAR makes software components independent of the ECU map. Communication between SWCs occurs, among others, through various ports.

Client/server port; where the server is the media provider and the client is the service provider.
The sender/receiver port through which the sender sends a message to at least one or more recipients.
During the development process, SWC can be integrated with its environment (hardware, driver, operating, etc.).

Base software AUTOSAR Base software (BSW) is divided into three layers:
Service Layer,
ECU Abstraction Layer,
Microcontroller Abstraction and Complex Device Driver (CDD)

Image description


Each of the three layers, various commercially useful compositions. All of these features also have their own unique modes. Drift to create a channelized software control - in the execution process all functions are delivered by a specific software.

Image description


Microcontroller Abstraction Layer (MCAL)
The Microcontroller Abstraction Layer is the bottom layer of the underlying software; This means that the MCAL module comes voluntarily. Voluntary direct storage AI hardware. MCAL has internal drivers, which are software modules that provide direct access to the µC and internal devices.

According to the instructions, the MCAL layer enables the higher order processing unit (MCU) environment.

ECU Abstraction Layer
The ECU abstraction layer connects drivers via the Microcontroller Abstraction Layer (MCAL). It also includes drivers for internal and external ECU components and provides troubleshooting information for various internal components.

Provides a connection to access all functions of the ECU (such as communications, memory or I/O), regardless of whether these functions are part of the microcontroller or services received from peripheral devices.

Complex Device Driver Layer
The Complex Device Driver (CDD) layer extends from the hardware layer to the RTE. CDD refers to the specific operation and operating time that sensors and actuators must operate.

Gives the opportunity to combine unique strengths. This set includes driving vehicles that are not unique in AUTOSAR and have a fairly advanced duration.

Service Layer
Service layer is the top layer of the Base Software (BSW) and also implements its dependencies towards the application software. It provides independent interfaces for the microcontroller (MCU) and ECU hardware and application software.

Services provided:

Operating system functions
Vehicle network communication and management services
Memory services (NVRAM management)
Diagnostic services (UDS, error handling, Memory)) . All Autosar systems are certified software systems. Each module provides an interface between adjacent modules.
More explanation about AUTOSAR COM Module
This lists all the features of other modes used by AUTOSAR COM Module and features provided with the help of AUTOSAR COM Module for different modes. Please refer to the figure below to understand the location of the AUTOSAR COM module in the communication group

Image description

Figure e: Component view

Image description

fig f: Autosar COM submodules

Image description

fig g: Autosar COM file structure

AUTOSAR COM module uses a combination of each unit of the PDU Router's parent module API; The parent module of the TP API and the API of the parent layer that does not use TP. This is important because the AUTOSAR COM module sends I-PDUs without corrupting simple L-PDUs or corrupting I-PDUs in the TP.

Below are the functions required by the AUTOSAR COM module from the central PDU router.

Incoming I-PDU indicator
Sending interface for outgoing I-PDU, e.g. To verify that the I-PDU is sent by the session controller
Trigger the interface to allow the PDU router to start from the AUTOSAR COM Module transfer.
I still don't know about TP communication
This topic will be try to explain more in the next part

Thank you

Top comments (0)