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 exchange formats.

Formats for AUTOSAR Exchange

The AUTOSAR framework defines exchange formats.

SWC Description; The supplier or OEM is responsible, for defining the SWCs. This involves creating an XML file for each SWC, known as the SWC Description. It provides details about the interfaces and resource requirements of the SWC. Afterwards the supplier or OEM generates the C files to implement it.

System Description; The OEM begins by defining the content, for the vehicle independent of individual ECUs based on the SWCs. Subsequently they design communication networks. Distribute the SWCs to existing ECUs. The outcomes are then recorded in the system description.

According to AUTOSAR 4.0 the OEM simplifies the system description, for each ECU into a condensed version called the System Extract of System Description. This condensed file can be shared with the suppliers of the ECU replacing the used.dbc, FIBEX or.ldf files for BSW module configuration.

To generate an ECU Extract of System Description (ECUEX) a process known as "Flattening" is employed. This process aligns with the System Extract. Only includes the software components (SWCs), in a straightforward manner. The Tier1 supplier has the option to expand the ECU Extract by adding their SWCs that were developed in house.

AUTOSAR 3; ECU Extract of System Description;
For each ECU the OEM condenses the System Description into an ECU Extract of System Description. This condensed file is then provided to the ECU suppliers of using.dbc, FIBEX or.ldf files, for BSW module configuration.

Complete Electronic Control Unit(ECU) Extract of System Description;
beginning with the system description provided by the provider for the ECU extract incorporates their SWCs. The outcome is an updated ECU(Electronic Control Unit) Extract of System Description that includes descriptions for all SWCs on an ECU, from both the OEM(Original Equipment Manufacturer) and the supplier.

The BSW(Basic Software) Module Description files serve as a requirement, for ECU configuration. They contain the definitions of data structures and all configurable parameters of a Basic Software module. These files are implementation specific and along with the generators form part of the code content, in the BSW modules provided by the AUTOSAR stack supplier.

The initial creation of the ECU Configuration Description (ECUC) is done by the supplier, who relies on both the ECU Extract of System Description & the BSW(Basic Software) Module Description files. The supplier then proceeds to configure the ECU using this ECUC for documentation purposes. This involves utilizing tools to set and verify the parameters of the Basic Software modules and RTE. The ECUC serves as a foundation, for generating RTE & BSW modules specific to the ECU accomplished through associated generators.

The flexibility of the AUTOSAR method ensures its suitability for meeting requirements across projects and OEMs. For instance, in the System Description the use of software components is not mandatory.

The image appears to show a flowchart or diagram that explains how software components, for electronic control units (ECUs) are developed using the AUTOSAR (AUTomotive Open System ARchitecture) methodology. AUTOSAR is an architecture for software that enables the interchangeability and compatibility of software components within vehicle ECUs.

Here's a step-by-step breakdown of the diagram

Step 1; Defining Software Components (SWC); The process starts by defining software components using development tools. These components are described in.c/.h files (source and header files, in C programming language) and.xml files, which may contain configuration or definition data.

AUTOSAR System Development Tools

Step 2.1; Model and Code Generation; A model based development tool is used to create models of the software components and generate the corresponding code.
Step 2.2; Validating the code; Next we proceed to implement and validate the generated code to ensure that it meets all the required specifications. This step also involves using templates. May require working with files that were coded by hand.

Step 3; Distributing software components; After the implementation and validation process we distribute the software components. This means making them available, for integration into the system.

Step 4; Defining the network; We define the network in which these software components will operate. This includes specifying how different Electronic Control Units (ECUs) and components will communicate with each other.

Step 5; Involvement of OEM (Original Equipment Manufacturer); The OEM plays a role, in generating the system description, which provides a high level overview of both system requirements and architecture.

Step 6; Extracting ECU Requirements; We extract the requirements of an Electronic Control Unit from the overall system description outlining its responsibilities within the vehicles network.

Step 7; Configuring. Bsw; We configure the RTE (Runtime Environment) and BSW (Basic Software). The RTE acts as a middleware that enables communication, between software components while the BSW provides services like diagnostics, communication and memory management.

Step 8; Generating. Bsw; Based on the configurations we generate the RTE and BSW. These components are crucial for ensuring functionality of software within the ECU.

Step 9; Tier 1 Supplier; This term likely refers to a supplier in the industry. A Tier 1 supplier directly supplies, to OEMs (Original Equipment Manufacturers). The responsibility of a supplier is to deliver BSW module descriptions and configuration files.

⁤The diagram also illustrates how information flows between these steps with arrows indicating the direction of the workflow. ⁤⁤The presence of .xml/.c/.h and.a2l files implies that the process combines configuration, programming and potentially calibration or parameter definition activities. ⁤