AUTOSAR Classic Runtime Environment (RTE)

The Runtime Environment (RTE) module cluster implements the AUTOSAR Virtual Functional Bus on the ECU and provides standardized APIs for typed sender-receiver and client-server communication of software components [SWS_Rte_01091], [SWS_Rte_01102]. It integrates the Basic Software Scheduler (SchM) for cyclic scheduling of the Basic Software modules and interfaces with OS/IOC and the communication stack (COM, LdCom) [SWS_Rte_01376], [SWS_Rte_04546]. In doing so, the RTE guarantees data consistency and deterministic mode transitions through configurable protection areas, buffering, and defined 10-step transition sequences [SWS_Rte_02665], [SWS_Rte_03504].

more ›

The Runtime Environment (RTE) module cluster forms the implementation of the Virtual Functional Bus (VFB) at ECU level. It completely decouples AUTOSAR software components (SWCs) from the underlying Basic Software and coordinates the scheduling of BSW modules via the Basic Software Scheduler (SchM) [SWS_Rte_04546], [SWS_Rte_05165]. The cluster handles both intra-partition accesses and cross-partition data flows via the OS-IOC as well as the ECU bus via the COM and LdCom modules [SWS_Rte_01376], [SWS_Rte_02736], SWS_RTE p. 106.

Context diagram: Embedding of the RTE and SchM cluster between application layer (SWCs), OS/IOC, and Basic Software services. Sources: [SWS_Rte_05165], [SWS_Rte_02736], [SWS_Rte_01376], SWS_RTE p. 106.

Communication relies on sender-receiver and client-server patterns: S/R data is transmitted implicitly consistently via buffer copies (`Rte_IRead`/`Rte_IWrite`) or explicitly directly and buffered (`Rte_Read`/`Rte_Write`/`Rte_Receive`) [SWS_Rte_01091], [SWS_Rte_02521], [SWS_Rte_06000]. In the event of failure or invalid signals, mechanisms such as `initValue` substitution or `handleInvalid` strategies take effect [SWS_Rte_05030], [SWS_Rte_06009]. In the case of asynchronous execution, client-server calls (`Rte_Call`, `Rte_Result`) are synchronized via FIFO queues on server and client sides and uniquely assigned using transaction handles [SWS_Rte_01102], [SWS_Rte_02527], [SWS_Rte_02649].

In task and lifecycle management, the RTE ensures reentrancy through code sharing and protects critical sections via configurable locking mechanisms such as interrupt locks, OS resources, or OS spinlocks [SWS_Rte_03015], [SWS_Rte_03504]. Mode switches undergo a strict 10-step sequence from OnExit, OnTransition to OnEntry activations and are completed in an orderly fashion via acknowledgment events [SWS_Rte_02665], [SWS_Rte_02679].

more ›

System Architecture & Role of the Module Cluster

The Runtime Environment (RTE) module cluster forms the functional and communicative backbone of the AUTOSAR Classic Platform. It represents the concrete implementation of the Virtual Functional Bus (VFB) on an ECU and completely decouples software components (SWCs) from the underlying Basic Software (BSW) as well as the microcontroller hardware SWS_RTE p. 106. Within the cluster, the actual RTE handles the mediation of application-related inter- and intra-ECU communication, while the integrated Basic Software Scheduler (SchM) controls execution control, consistency assurance, and cyclic scheduling of the BSW modules [SWS_Rte_04546], [SWS_Rte_05165].

The architecture establishes standardized interfaces between application SWCs, sensor/actuator components, and the BSW layers. For vehicle-wide networking, the RTE cluster relies directly on the communication stack: signal-oriented messages are passed to the COM module, while large volumes of data are handled via the LdCom module (Large Data COM) [SWS_Rte_01376], [SWS_Rte_04527]. Process and memory isolation across partition and core boundaries is provided by the AUTOSAR operating system (OS) and its Inter-OS-Application-Communication mechanism (IOC) [SWS_Rte_02736]. Calibration data and memory blocks interface with the NVRAM Manager (NvM) and calibration tools via standardized descriptors [SWS_Rte_03961], [SWS_Rte_05118].

Context diagram: Embedding of the RTE and SchM cluster between application layer (SWCs), OS/IOC, and Basic Software services. Sources: [SWS_Rte_05165], [SWS_Rte_02736], [SWS_Rte_01376], SWS_RTE p. 106.

Interplay & Interaction Paths Between the Modules

The interaction within the RTE cluster strictly distinguishes between sender-receiver (S/R) and client-server (C/S) communication. For S/R communication, the RTE supports both implicit and explicit read and write semantics: With implicit access (`Rte_IRead`, `Rte_IWrite`), the RTE creates a local copy at the start of runnable execution that is kept consistent throughout the entire runtime [SWS_Rte_06000], [SWS_Rte_03744]. With explicit access (`Rte_Read`, `Rte_Write`, `Rte_Send`, `Rte_Receive`), data exchange takes place directly synchronously or via queues [SWS_Rte_01091], [SWS_Rte_01092]. For queued events (`swImplPolicy = queued`), the RTE sets up FIFO queues on the receiver side; if such a buffer overflows, the element is discarded and an error state is set [SWS_Rte_02521], [SWS_Rte_02523].

If the data path crosses ECU boundaries (inter-ECU), the RTE transforms and serializes composite data structures and calls `Com_SendSignal` or `Com_SendSignalGroup` to ensure atomic PDU transmission in the COM module [SWS_Rte_04527]. For large data arrays, the RTE alternatively resorts to `LdCom_Transmit` and, in the case of transport protocols (TP), locks the associated buffer until confirmation via callbacks [SWS_Rte_01377], [SWS_Rte_01379]. On the receiver side, the RTE receives data asynchronously via COM callbacks and derives activation events for application runnables from them [SWS_Rte_03530], [SWS_Rte_03531]. If no bus data has arrived yet, the RTE provides configured initial values [SWS_Rte_06009], [SWS_Rte_06010].

Sequence diagram: Explicit sender-receiver data flow across ECU boundaries with buffering and initial value output. Sources: [SWS_Rte_06010], [SWS_Rte_04527], [SWS_Rte_03530], AUTOSAR_SWS_RTE p. 148.

For client-server communication, the RTE generates `Rte_Call` for synchronous calls and separate invocation and query APIs (`Rte_Call`, `Rte_Result`) for asynchronous calls [SWS_Rte_01102], [SWS_Rte_01111]. If calls cannot be resolved directly as a C function in the same context, the RTE buffers requests at the server level in FIFO queues and responses at the client level in a queue of depth 1 [SWS_Rte_02527], [SWS_Rte_02528]. For cross-partition or cross-ECU C/S calls, the RTE uses transaction handles composed of a client ID and sequence counter to precisely correlate responses to the original caller [SWS_Rte_02649], [SWS_Rte_03885].

Synchronization, reentrancy and task contexts

The execution of program code in the RTE cluster takes place within OS tasks or ISR contexts. The RTE distinguishes between basic runnables (category 1 without blocking OS calls) and extended runnables (category 2 with wait points) that are woken up from the `WaitPoint` state by events such as `DataReceivedEvent` or COM callbacks [SWS_Rte_03532], SWS_RTE p. 304. Concurrent activation of the same instance of a runnable entity is strictly prohibited unless the attribute `canBeInvokedConcurrently` is explicitly set to `TRUE` [SWS_Rte_03523]. For multi-instantiated SWCs, AUTOSAR consistently relies on code sharing: Multiple instances share the same executable code, but access separate data and per-instance memory (PIM) via instance-specific descriptors [SWS_Rte_02002], [SWS_Rte_03015], [SWS_Rte_02301].

To protect critical sections, the RTE generates so-called exclusive areas (`Rte_Enter`, `Rte_Exit`). The underlying synchronization mechanism is configured via the parameter `RteExclusiveAreaImplMechanism` [SWS_Rte_03504]. Five defined strategies are available here:

• ALL_INTERRUPT_BLOCKING: Global disabling of all hardware interrupts [SWS_Rte_03504].
• OS_INTERRUPT_BLOCKING: Selective disabling of OS-specific interrupts (category 2) [SWS_Rte_03504].
• OS_RESOURCE: Use of OSEK/AUTOSAR operating system resources with priority ceiling protocol [SWS_Rte_03504].
• OS_SPINLOCK: Multi-core synchronization via OS spinlocks for coordination between tasks and ISRs of different cores [SWS_Rte_03504].
• NONE: Omission of internal locks, provided that data consistency is already ensured by strict task prioritization or scheduling [SWS_Rte_03504].

When data is passed between different memory protection partitions, the RTE checks pointer parameters in order to prevent unauthorized memory accesses from untrusted partitions [SWS_Rte_02752], [SWS_Rte_02753].

Typical lifecycles and operating modes

The system lifecycle is subject to a strict division of phases between initialization, normal operation, and controlled shutdown. During system startup, the SchM part is initialized first: The EcuM calls `SchM_Start` on each processor core before BSW modules such as the BswM are started [SWS_Rte_04546], [SWS_Rte_04548]. Subsequently, `SchM_StartTiming` activates the periodic BSW events and MainFunctions [SWS_Rte_04549], [SWS_Rte_04551]. According to the design constraint, `SchM_Start` and `SchM_StartTiming` may be called exactly once per core SWS_RTE p. 928. After that, `Rte_Start` enables the application RTE; if internal resource allocation fails, initialization aborts with `RTE_E_LIMIT` [SWS_Rte_01261], [SWS_Rte_01262].

Operating modes are represented via mode declaration groups. If a mode manager triggers a mode switch via `Rte_Switch`, it is queued in a FIFO queue [SWS_Rte_02631], [SWS_Rte_02718], [SWS_Rte_02719]. Each mode machine undergoes a mandatory 10-step sequence during the transition [SWS_Rte_02665]: First, mode disabling for the target mode is activated and executing entities are awaited (steps 1–2). This is followed by the sequential execution and termination of OnExit (steps 3–4), OnTransition (steps 5–6), and OnEntry executable entities (steps 7–8). Finally, the disabling of the previous mode is removed and the new mode is activated (step 9) before the mode switch is acknowledged via `ModeSwitchedAckEvent` or `Rte_SwitchAck` (step 10) [SWS_Rte_02665], [SWS_Rte_02679], [SWS_Rte_02725]. Via `RteModeToScheduleTableMapping`, operating modes can also be coupled directly to OS schedule tables [SWS_Rte_05146].

Sequence diagram: Standardized 10-step sequence of an AUTOSAR mode switch with acknowledgement. Sources: [SWS_Rte_02665], [SWS_Rte_02679], EXP_ModeManagementGuide p. 16.

Deinitialization occurs at the beginning of the shutdown phase via `Rte_Stop`. Following this call, the RTE blocks activating, starting, or releasing further runnables on the respective core [SWS_Rte_02538]. Incoming S/R data as well as C/S requests are discarded and ignored while the RTE is in the stopped state [SWS_Rte_02535], [SWS_Rte_02536].

Error Handling, Status Monitoring, and Data Validation

Error states and interface statuses are uniformly returned to the caller in the RTE via the scalar type `Std_ReturnType` [SWS_Rte_01034], SWS_RTE p. 586. The RTE differentiates between application errors (error values 1–63), immediate infrastructure errors (values 128–255), and overlaid status bits such as data loss (`RTE_E_LOST_DATA = 64`) or obsolescence (`RTE_E_MAX_AGE_EXCEEDED = 64`) SWS_RTE p. 586. Typical infrastructure return values include stopped communication (`RTE_E_COM_STOPPED = 128`), communication and response timeouts (`RTE_E_TIMEOUT = 129`), missing data (`RTE_E_NO_DATA = 131`), and resource limits (`RTE_E_LIMIT = 130`) [SWS_Rte_01060], [SWS_Rte_01061], [SWS_Rte_01064]. With active value range checking, the RTE reports range violations with `RTE_E_OUT_OF_RANGE` [SWS_Rte_03845], [SWS_Rte_03846].

To handle implausible or faulty signals, the RTE provides mechanisms for data invalidation. On the sender side, `Rte_Invalidate` marks the signal with a defined replacement value [SWS_Rte_01206], [SWS_Rte_05024]. On the receiver side, the attribute `handleInvalid` controls the replacement strategy: With `keep`, the previous value is retained and a `DataReceiveErrorEvent` is triggered, whereas with `replace`, automatic substitution by `initValue` occurs [SWS_Rte_05030], [SWS_Rte_05049]. Communication failures at the network level are monitored via `aliveTimeout`; if the monitoring time expires, the COM module reports a reception timeout to the RTE via `Rte_COMCbkRxTOut`, whereupon dependent components are notified or fallback values are activated [SWS_Rte_08061].