Hello Readers,

My name is Rajesh M, and I work at Luxoft India as a Junior Software Developer. Luxoft has given me several opportunities to work on various projects, which has inspired me to learn the essential processes involved in developing AUTOSAR Modulеs and Add-Ons in AUTOSAR RTE.

INTRODUCTION

The Run-Time Environment (RTE) is the heart of the AUTOSAR ECU architecture. RTE is an implementation of the AUTOSAR Virtual Function Bus (VFB) bus interfaces (for a specific ECU). The RTE provides infrastructure services that enable communication between the AUTOSAR software components and act as the core software modules for the AUTOSAR software components to access. including the OS and communication service.

RTE includes both variable elements of the system infrastructure resulting from different alignment of components to EKUs, as well as standardized RTE services.

Key Functions of AUTOSAR RTE:

1.Communication Management:
RTE plays a key role in enabling seamless communication between different software components using common interfaces. It can efficiently handle various tasks such as inter-task communication, event processing and data exchange, which promotes seamless cooperation between the various functions of the vehicle.

2.Basic Software Interaction:
RTE acts as an important link between application software and BSW modules, facilitating seamless communication between software components and hardware services. This critical role includes core functions such as memory management, scheduling, and I/O functions.

3.Mode Management:
The automotive industry is constantly evolving and vehicles operate in several different states such as normal, stationary and sleep. In this environment, RTE plays an important role in the effective management of these facilities. Its role is crucial to ensure a smooth transition between modes and to ensure that the system performs as intended under different conditions.

4.Error Handling:
Effective error handling is a critical factor in automotive systems. RTE uses methods to detect, communicate and correct errors in software components that increase vehicle and overall safety and reliability.

Basically, RTE can be logically divided into two parts:

• The communication between software components.
• The scheduling of the software components.

Basic Software Scheduler must also be considered to fully describe the concept of RTE. The kernel software scheduler schedules the scheduled entities of the kernel software modules.

RTE Generartion phase:

In Rte Generation, there are two phases,

1. RTE Contract Phase.
   At this stage, only limited information is available about the component. Here the AUTOSAR interface definitions are used to create the application header for the component type. The application header file defines the contract between the component and RTE.

2. RTE Generation Phase.
   In this step, all important information about components, ECU commission, ECU communication connections are defined and this information is used to form the RTE. One RTE is created for each system ECU.

RTE Contract Phase:

In the contract phase, the type of application software is defined, including ports, interfaces, connection between ports through interfaces. All of these are defined at the VFB level and the internal behavior description of the SW component is also defined. Based on this information, the component API (application header file) is created.

The created 'Component API' (application header file) allows the software developer to make the source code of software available without having to worry about communication afterwards. be local or using some network(s).

It should be noted that the development process of the SW component is iterative, and the description of the SW component may change during the development of the SW component. This requires the application header file to be recreated to match the changes made to the SW component description.

Therefore, when the SW component is delivered at the RTE contract stage, it consists of the following parts:

• Component Type Description

• Component Internal Behavior Description

• The actual source and/or object code

• Component Implementation Description


RTE generation Phase:

The RTE generation phase can be divided into two parts

• RTE Configuration editing

• RTE Generation Phase

RTE Configuration Editing

The "RTE Configuration Editor" is a tool used to gather all the information from the ECU to create a working RTE. This collection contains information about SW component instances and their relationships, executable units and associated RTE events, etc.The main source for all this information is the ’ECU Configuration Description’.

Once the RTE configuration editor has gathered all the necessary information and built its internal structure, it can start configuring configuration requirements for other modules such as COM and OS.

ECU configuration editors run iteratively through the ECU configuration description until all configuration issues are resolved. Multiple configuration editors are required, each specializing in a specific part of the ECU configuration. Thus, one editor can define the COM stack (not the communication matrix, but the interaction of individual modules), while another editor is used to define the RTE.

Only after the configuration issues are resolved, the RTE generator is used to generate the actual RTE code, which is then compiled and linked with the other code., which is then compiled and linked with the other code. Basic-SW modules and the SW-Components code.

RTE Generation Phase:

Once the ECU is fully configured, the actual RTE can be generated. Since all the relationships to and from the other Basic-SW modules have been already resolved during the ECU Configuration phase, the generation can be performed in parallel for all modules.

Thanks for reading to be continued

Hello all in this article i have talked about the Rte significance in Autosar. I will be continuing more about RTE in the upcoming article Thank you .