EB tresos Classic AUTOSAR：
Runtime Environment (RTE) Basic Technology Analysis
Systematic basic teaching, deeply analyzing the key bridge connecting the application layer and the basic software—the Runtime Environment (RTE), to help developers master its core logic and implementation methods.
This article is based on the video content of 'EB tresos Classic AUTOSAR Runtime Environment (RTE) Basic Training' provided by Elektrobit. The video provides an in-depth analysis of the key bridge connecting the application layer and basic software—the Runtime Environment (RTE). The content covers the positioning of RTE in the system architecture, the mapping mechanism of events and tasks, the concept of RTE Partitioning, and actual configuration use cases, helping developers master the core logic and implementation methods of RTE.
1. Description and Positioning of RTE in the AUTOSAR Architecture
In the layered architecture of Classic AUTOSAR, RTE is the core component that concretely implements the 'Virtual Functional Bus (VFB)'.
account_tree Connecting Top and Bottom and Decoupling
RTE is located between the Application Software Components (SWC) and the underlying Basic Software (BSW). It completely frees SWCs from needing to know the details of the underlying Operating System (OS) and hardware communication network, achieving decoupling of software and hardware.
hub Absolute Communication Hub
In the AUTOSAR specification, whether two SWCs within the same ECU are passing data to each other, or different ECUs are communicating via CAN/Ethernet, or even if an SWC needs to call underlying storage or diagnostic services, all information exchange must and can only be must be done through the APIs provided by the RTE.
2. RTE Event and Task Mapping (Event Mapping)
RTE is responsible for managing and scheduling the 'Runnables' in SWCs, translating abstract software behavior into concrete operating systems.
-
bolt
RTE Events： Runnables themselves are just C language functions, which need specific conditions to trigger execution. These conditions are collectively referred to as RTE Events (e.g., periodically triggered Timing Event, Data Received Event triggered when data is received).
-
schema
Map to OS Task: RTE itself has no independent thread scheduling capability; it must rely on AUTOSAR OS. During the development process, engineers must map each RTE Event to a specific OS Task in the EB tresos tool. When the operating system schedules and executes that Task, RTE will sequentially call the corresponding Runnables in the configured order.
3. RTE Partitioning and Memory Protection
In response to the increasing complexity of modern automotive electronics and the requirements of Functional Safety (such as ISO 26262), the video introduces the RTE partitioning mechanism.
layers Logical and Physical Isolation
RTE supports dividing different software modules into different 'Partitions'.
shield Fault Protection
Each RTE Partition usually corresponds to an independent OS Application and is combined with the microcontroller's Memory Protection Unit (MPU). The advantage of this mechanism is that if an abnormality (such as memory out-of-bounds) occurs in a program in a non-critical partition, RTE and OS can limit the error within that partition, avoiding affecting other core partitions crucial for driving safety (such as brake control).
4. Practical Use Cases and EB tresos Development Workflow
When actually using EB tresos for development, the RTE generation process typically has two-phase characteristics:
-
assignment
Contract Phase: When the underlying software has not been completely configured, the RTE tool can first generate C language header files (Application Header Files) for the application layer to use based on the SWC interface definitions. This allows application layer development and underlying configuration to work in parallel without interfering with each other.
-
build_circle
Generation Phase: When the configuration and Mapping of all SWC, BSW modules, and the OS are completed, EB tresos will perform the final generation, outputting the Rte.c and Rte.h files containing all specific logic and communication API implementations, and proceed with the final compilation and integration.
Summary
RTE is the soul of the AUTOSAR architecture, responsible for stitching together modular software components with the underlying operating system and hardware resources. Through the configuration tools of EB tresos, developers can systematically define the trigger mechanisms of software behavior and use partitioning technology to ensure system stability and safety. This is an indispensable key link in developing modern standard automotive ECUs.