Articles
AUTOSAR Interview Questions: RTE Boundaries, Runnables, and Communication Paths
Prepare for AUTOSAR interview questions with Classic RTE boundaries, runnable-to-task mapping, implicit reads, freshness, and communication-path debugging.
A software component writes a new sensor value, but another ECU still shows the old reading. The RTE call succeeds. Does that prove the receiving runnable executed, the bus transmitted a frame, or the remote application consumed it? A strong AUTOSAR interview answer explains which boundary each observation proves.
Begin with Model-Based Engineering Rollout. Use the configuration and integration problem to describe how a component contract becomes generated code, scheduled execution, and a communication path.
Which AUTOSAR platform and release are you discussing?
Official facts: AUTOSAR's Classic Platform overview identifies the application, Runtime Environment, and Basic Software layers and lists R25-11 as its current Classic release when checked on October 6, 2026. The layered architecture explanation places application-component communication through the RTE.
Evidence boundary: This article concerns Classic Platform R25-11, not Adaptive Platform APIs. Official specification facts are linked at first use. Timing traces, diagnostic recommendations, and the local model are original preparation material.
Ask which release, generator, ECU configuration, and integration stack the supplied code uses. The existence of a standard API concept does not identify the exact generated function name or prove that two suppliers generate identical implementation details.
A useful architecture answer names the application behavior first: what data or operation is exchanged, who owns it, and when it must be usable. Then describe the configured path that implements that contract. Starting with a long list of Basic Software modules can hide the boundary the interviewer actually wants you to debug.
What belongs on each side of the RTE boundary?
Official fact: The RTE software specification, section 2.2, describes software-component communication through ports. Sender-receiver interfaces exchange data; client-server interfaces expose operations. Application components do not simply call arbitrary Basic Software services directly.
Original design exercise: A temperature component produces a reading, and a controller consumes it. Define the provided and required ports, interface, data element, type, unit, and validity expectations. A matching C integer type is insufficient if one side uses degrees Celsius and the other interprets a scaled raw sensor value.
If the controller needs a service operation rather than a periodically refreshed value, evaluate a client-server contract. State what completion means and whether the chosen configuration permits blocking or asynchronous interaction. Do not turn every interaction into a shared global variable merely because both components run on one ECU.
The RTE boundary also helps explain relocation. Two components can share an ECU now and be distributed later, but placement changes timing and failure assumptions. A local call's apparent speed is not a portable latency guarantee. Keep component behavior separate from deployment-specific communication and scheduling details.
For review, distinguish application intent, configured interface, generated entry points, and underlying implementation. Seeing a generated function compile proves that the build found a declaration; it does not prove that the intended peer or signal mapping is configured correctly.
How does a runnable differ from an operating-system task?
Official facts: RTE specification section 4.2 describes runnable-to-task or ISR mapping supplied by ECU configuration; the generator does not choose that mapping independently. The AUTOSAR OS specification defines the task and scheduling mechanisms underneath that integration.
Preparation explanation: A runnable is an execution unit of a software component. An OS task provides an execution context. A configured event and mapping determine when a runnable can be invoked within that context. Several runnables can belong to one task; one runnable declaration is not automatically one independently scheduled thread.
Original scheduling case: A 10 ms task invokes a sensor runnable and then a controller runnable. The controller's nominal period does not establish that it starts at the exact tick. Earlier work, preemption, resource contention, and execution time affect its observed start and completion.
Request the event configuration, mapping, runnable order, task priority, activation limits, and a timestamped trace. Separate “the trigger became due,” “the task was activated,” “the task began running,” and “the runnable started.” A missing output can arise before the application code ever executes.
If a task overruns, increasing a runnable's trigger rate may worsen the backlog. Diagnose execution cost and scheduling interference before changing periods. Explain the intended response to missed deadlines or activation errors; hiding an error status does not recover the timing contract.
What changes between implicit and explicit data access?
Official facts: RTE specification section 4.3.1.5 describes implicit reads with copy semantics that preserve the runnable's view during execution, and implicit writes made available no earlier than termination. Explicit access uses API calls, with behavior governed by runnable category and port configuration. Copy semantics do not require every implementation to allocate a separate physical copy.
Original timing model: The producer updates an unqueued value every 10 ms. At time 10 ms it publishes 100; at 20 ms it publishes 200. A consumer begins at 15 ms and reads at 16 ms and 21 ms before finishing at 22 ms. Assume the producer can execute between those reads.
| Access choice in the stated model | Values observed and implication |
|---|---|
| Implicit view established for the consumer | Reads return 100 and 100; the invocation has a consistent view |
| Explicit reads of the updated value | Reads return 100 and 200; the producer update occurs between calls |
| Implicit second read at 21 ms | Snapshot's source timestamp remains 10 ms; age is 11 ms |
| Explicit second read at 21 ms | New value's source timestamp is 20 ms; age is 1 ms |
Consistency and freshness are different properties. The implicit view avoids changing this input halfway through a calculation, but it does not guarantee the freshest source timestamp at every instruction. Explicit access can observe an update, but several separate reads need a contract if the calculation requires related values from one sample.
This exercise assumes the stated data-access configuration and schedule. It does not model every coherent or incoherent buffer optimization, preemption area, runnable category, or generated implementation. Inspect those settings before generalizing a trace to a real ECU.
Does a latest-value interface preserve every measurement?
Original follow-up: A producer emits 100, 200, and 300 while the consumer is delayed. If the contract is an unqueued latest value, the consumer may observe 300 without processing the intermediate values. That can be correct for a continuously updated state, yet lose a command that the consumer must process.
For an event-oriented requirement, define queuing, capacity, overflow behavior, and consumption rules explicitly. A queue is not unlimited; a producer faster than the consumer needs backpressure, loss handling, or a bounded operational policy. A port connection alone does not establish those choices.
Use timestamps, sequence information, and status where the application contract requires them. If a value has not changed, determine whether it is a repeated valid measurement, an initialized value, a stopped producer, or a communication timeout. Use freshness and status evidence to distinguish those explanations; an unchanged numeric value cannot do that alone.
In the timing model, suppose maximum accepted age is 10 ms. The implicit second read is consistent but exceeds that age at 21 ms. The controller needs an explicit stale-data response. Whether that response is a fallback, hold, or fault indication depends on requirements; an interview exercise should not invent a vehicle safety policy.
How does a value cross an ECU communication path?
Official facts: The Communication specification describes packing signals into I-PDUs and configured transmission behavior. The layered architecture document describes the communication services and abstraction layers involved below application components.
Original Classic CAN path: For a configured signal-based path, trace the sender runnable through RTE, COM, PduR, CanIf, and the CAN driver toward the controller and bus. On reception, trace the corresponding configured path toward the receiving RTE and runnable. This is a specified exercise path, not a universal route for every AUTOSAR bus or communication mode.
At each boundary, name the signal, PDU, channel, configuration, and evidence available there. A successful application write, interpreted against its generated API contract, can establish that the local call accepted the value under its contract. It does not by itself prove physical transmission, remote reception, or remote application consumption.
A cyclic COM transmission policy can send the latest packed value on a configured schedule. An application write immediately before or after that schedule can change which frame carries it. Do not infer one physical frame per write unless the selected transmission configuration supports that claim.
Check signal bit position, length, byte order, scaling, invalid-value handling, and the sender/receiver configuration versions. A bus trace showing the expected CAN identifier is useful, but the receiver can still decode the wrong field or route it to a different consumer.
How would you debug a receiver that keeps an old value?
Original evidence ladder: Start with a single source sample and a known timestamp or sequence. Capture the sender's produced value, the local RTE write result, COM's configured data and transmission state, the observed frame, the receiving data, and the consumer invocation. Use one sample so unrelated repetitions do not masquerade as progress.
If no frame carries the update, investigate the local configured path and communication state. If the frame contains the intended update but the receiving application does not see it, investigate decoding, routing, RTE buffering, runnable activation, and the read contract.
If the receiver reads the new value but its output is old, inspect the application calculation and output publication. An implicit write made inside a still-running invocation may not yet be available outside that invocation. Distinguish a pending publication boundary from a missing bus packet.
Keep the observed configuration with the trace. Comparing a waveform from one build with generated mappings from another can produce a persuasive but irrelevant diagnosis. Record ECU software versions, generator inputs, communication configuration, and the exact tested signal path.
Avoid repairing the symptom by bypassing the RTE with shared memory or a direct driver call. First explain which intended contract failed and how the proposed change restores it. A workaround can create timing, ownership, or deployment dependencies that the original component interface was meant to control.
What can a small timing exercise prove?
Original executed model: The accompanying Python model evaluated the 15–22 ms consumer interval and checked the implicit and explicit read pairs, their source timestamps and ages, and the 10 ms freshness decision. All eight assertions passed in the saved local Python run.
The model proves the arithmetic and outcomes under its explicit assumptions. It does not run an AUTOSAR RTE, schedule an OS task, generate ARXML-derived code, transmit CAN traffic, or validate a safety requirement. A real integration test must establish those separate behaviors with the configured stack.
In a live coding or review interview, first show this small deterministic example. Then identify the evidence needed to connect it to deployment: generated API declarations, event-to-task mapping, task traces, buffer behavior, and communication observations. This lets the reviewer challenge one assumption without discarding the entire explanation.