RTE - Runtime Environment Deep Dive - AUTOSAR Classic BSW

RTE Generation: ARXML → C Code

RTE Generation Pipeline

  SWC ARXML + System Description ARXML + OS Config ARXML
              │
              ▼ RTE Generator (DaVinci / tresos)
  ┌──────────────────────────────────────┐
  │  Rte_WheelSpeed.h / Rte_WheelSpeed.c │  ← per SWC
  │  Rte_EngineCtrl.h / Rte_EngineCtrl.c │
  │  SchM_Com.h / SchM_Can.h              │  ← BSW schedule manager stubs
  └──────────────────────────────────────┘

Sender/Receiver API

CRte_WheelSpeed.h

/* Generated — do NOT edit manually */
FUNC(Std_ReturnType, RTE_CODE)
Rte_Write_SpeedOut_VehicleSpeed(
    P2CONST(float32, AUTOMATIC, RTE_APPL_DATA) data);

FUNC(Std_ReturnType, RTE_CODE)
Rte_Read_SpeedIn_PulseCount(
    P2VAR(uint16, AUTOMATIC, RTE_APPL_VAR) data);

💡 Return Values

RTE_E_OK (0x00) — value valid.
RTE_E_NEVER_RECEIVED (0x04) — no data written since startup.
RTE_E_MAX_AGE_EXCEEDED (0x10) — data is stale. Always check in safety-relevant runnables.

Client/Server API

CNvM_Client_Call.c

Std_ReturnType ret;
NvM_RequestResultType result;
ret = Rte_Call_NvMService_WriteBlock(BLOCK_ID_ODOMETER, &odometerData);
if (ret == RTE_E_OK) {
    (void)Rte_Result_NvMService_GetErrorStatus(&result);
}

⚠️ Blocking CS Calls

Synchronous Rte_Call on a server runnable in a lower-priority task can cause priority inversion. Use OSEK resource protocol or prefer asynchronous fire-and-forget CS calls for non-critical services.

Data Consistency: Implicit vs Explicit

Mode	Mechanism	Pros	Cons
Implicit	RTE copies port data at task activation; runnable uses copy	No data race; simple SWC code	Extra RAM; stale data risk
Explicit	Runnable calls Rte_Read/Write during execution	Fresh data; less RAM	Must protect against pre-emption in multi-runnable tasks

Runnable-to-Task Mapping

Task	Period	Runnables	BSW Main Functions
Task_1ms	1 ms	—	Com_MainFunctionRx/Tx
Task_10ms	10 ms	WheelSpeed_Calculate, EngineCtrl_Run	Dem_MainFunction
Task_100ms	100 ms	BatteryMonitor_Run	NvM_MainFunction, Fee_MainFunction
Task_Init	Once	All InitEvent runnables	All Xxx_Init() calls

Summary

The RTE is entirely generated C code. Its quality is determined by port/interface/connector definitions in the ARXML. Data consistency mode and runnable-to-task mapping directly impact RAM footprint, CPU load, and safety analysis.

🔬 How the RTE Generation Pipeline Works — Step by Step

The RTE generator is not a simple code formatter — it is a formal model compiler. It takes three sets of ARXML inputs (SWC descriptions, System Description, and OS/Schedule configuration) and produces type-safe, MISRA-C compliant C code that acts as the middleware glue between your application software and the Basic Software layer.

The key transformations it performs:

Port connector resolution: Every P-Port/R-Port pair in the ARXML is verified for interface compatibility, then mapped to a concrete memory buffer or function call stub.
Buffer allocation: For Implicit mode, the generator allocates per-task snapshot buffers. The size of your ARXML data elements directly determines RAM consumption — a 64-bit signal on a 100 ms task period adds 8 bytes of buffer RAM per runnable using it.
SchM integration: The generator creates SchM_Enter_<Module>_<ExclusiveArea>() / SchM_Exit_... calls that map to OS GetResource/ReleaseResource. Missing ExclusiveArea configuration is a common source of data corruption in multi-runnable tasks.
Version binding: The generated header embeds an RTE_GENERATOR_VERSION. If you regenerate after an ARXML schema update without regenerating all SWC stubs, you get linker errors or silent ABI mismatches.

🏭 Real-World Usage at Tier-1 Suppliers

Continental, Bosch, ZF: Typically use DaVinci Developer for SWC ARXML and DaVinci Configurator Pro for BSW. The RTE is regenerated as part of a nightly CI build — any ARXML change automatically triggers RTE + BSW regen.
OEM integration: BMW and Volkswagen supply an ECU Extract ARXML to Tier-1s. The Tier-1 must not modify the system-level signal routing — they add SWC ports only on their side. Violations cause RTE generation failures during OEM system integration checks.
Implicit vs Explicit in production: Safety-critical runnables (e.g. ABS torque control at 1 ms) almost always use Explicit mode to get fresh sensor data every activation. Non-safety body-control functions use Implicit mode to simplify MISRA compliance analysis.

⚠️ Top 5 RTE Integration Pitfalls

Editing generated files: Rte_<SwcName>.c/.h are fully overwritten on every regen. Any manual edits are silently lost. Keep all custom code in the SWC implementation files, never in the generated stubs.
Missing ExclusiveArea on shared IRVs: If two runnables in the same task write the same Inter-Runnable Variable without an ExclusiveArea, the RTE generator may not add a critical section. This causes intermittent data corruption that is nearly impossible to reproduce in HIL.
RTE_E_MAX_AGE_EXCEEDED ignored: Developers often write Rte_Read_...(&val) and use val without checking the return code. In a ASIL-B+ context this is an ISO 26262 Part 6 violation — stale sensor data must be handled explicitly.
Async CS result collection timing: Fire-and-forget Rte_Call returns RTE_E_OK immediately. Collecting the result via Rte_Result must happen in a separate runnable activation after the server has run. Getting the timing wrong gives RTE_E_NO_DATA on the first call, which is easy to miss in testing.
Runnable activation offset mismatch: When a Periodic Event runnable has an ActivationOffset configured in the ARXML, it must align with the OS alarm offset. A mismatch doesn't cause a build error — it causes CPU scheduling jitter that only shows up under full bus load in HIL testing.

📊 Industry Note

In a typical AUTOSAR Classic ECU at a German OEM, the generated RTE code accounts for 15–25% of total ROM on the microcontroller. Optimising it requires careful attention to buffer modes, ComSpec definitions, and runnable periods — not just the SWC application logic itself.

🧠 Knowledge Check — Click each question to reveal the answer

❓ What ARXML inputs does the RTE generator require, and why are all three necessary?

✅ The RTE generator needs (1) SWC ARXML — defines ports, interfaces, runnables; (2) System Description ARXML — defines signal connectors and port connections across components; (3) OS/Schedule ARXML — maps runnables to OS tasks. Without the OS config the generator cannot produce the SchM exclusive area calls or runnable activation code.

❓ What is the difference between Implicit and Explicit data access, and when should each be used?

✅ Implicit: RTE snapshots all input port values at task start; runnable reads the snapshot (no race condition but possibly stale). Explicit: runnable calls Rte_Read/Write during execution (fresh data but requires ExclusiveArea protection in multi-runnable tasks). Use Implicit for safety-critical runnables where MISRA and ASIL analysis must be simple. Use Explicit when RAM is constrained or data freshness is mandatory (e.g., 1 ms control loops).

❓ A runnable calls Rte_Read and gets RTE_E_MAX_AGE_EXCEEDED. What does this mean and what should the code do?

✅ It means the sender has not written a new value within the ComSpec deadline (DataReceivedErrorEvent / AliveTimeout period). The returned data value is the last valid value — it may be very old. The correct handling is to treat this as a signal error: apply a default/safe value, increment a DEM event counter, and — if ASIL-relevant — transition to a degraded operating mode.