TN-18 · 2026-09-12 · XiL Domain Series · Part 4

Talking and Listening on the Bus: RX/TX, Restbus Simulation, and XCP

Three basic questions in bus communication are all too easy to take for granted: does this frame count as “received” or “sent”? What happens when the SUT’s “colleagues” aren’t present? And can you see what it’s thinking inside? This article covers all three at once: the direction discipline of RX/TX, restbus simulation, and XCP.

1. RX/TX: First Ask “From Whose Point of View?”

The basic definitions fit in one sentence each:

• TX = Transmit: data flows out of the device;
• RX = Receive: data flows into the device from outside.

The naming origin is direct — an MCU’s UART/CAN controller pins are literally called TXD/RXD, and transceiver chips have the same two words printed on them.

The trap is this: direction is always “relative to someone.” On a phone call, your mouth (TX) faces the other person’s ear (RX) — the same sentence is “sent” on your side and “received” on theirs. A bus is exactly the same:

Test rig                               SUT (domain controller)
────────                               ───────────────────────
rig TX ──────── one radar frame ────────▶ SUT RX
rig RX ◀──────── one brake request ────── SUT TX

When the rig emits a radar-target frame: from the rig’s view it’s TX, from the SUT’s view it’s RX. One frame, two names, both correct. So before talking about direction, you must ask: “from whose point of view?”

2. Unify the Reference: The SUT

Industry convention (HIL rig documentation labels it this way too) is to name directions from the SUT’s point of view:

Why is TX-direction injection valuable? Because in the real world the SUT itself can go bad (RAM bit flips, software bugs), and the bad frames it emits flow to actuators like braking and steering. ISO 26262 requires E2E protection on communication links — and the way to verify “the protection actually works” is to deliberately corrupt frames in the TX direction and see whether downstream catches it.

3. Mixing Viewpoints Is the Most Common Log Trap

Mark the directions on the data path:

RX direction (feeding the SUT):
  replay/fault rules → fault-injection pipe → bus adapter → SUT
                       ↑ drop or corrupt here, and the SUT gets abnormal input

TX direction (SUT emitting):
  SUT → bus adapter → fault-injection pipe → bus log/downstream nodes
                      ↑ tamper here, and downstream sees a "rogue SUT"

Note that the rig’s view is exactly the mirror: the adapter’s sendToSut() is the rig’s TX and the SUT’s RX; receiveFromSut() is the rig’s RX and the SUT’s TX. That is why naming must stick to the SUT viewpoint — mixing viewpoints is one of the most common bug sources in log analysis and code review.

Three engineering disciplines:

1. Put the viewpoint in the name: not bare rxPipe/txPipe, but sutRxPipe/sutTxPipe, or the even plainer intoSutPipe/fromSutPipe — three months later you won’t be confused reading your own code;
2. Tag every frame’s direction in the log: add a direction field (SUT_RX/SUT_TX) to each frame record, so offline analysis doesn’t rely on guessing;
3. Declare direction explicitly in injection rules: direction: rx or tx — never let the injection point be inferred implicitly. The same drop rule on RX means “the SUT went blind,” on TX it means “the SUT went mute” — completely different safety mechanisms under test.

One sentence: RX and TX describe the direction data crosses a boundary, and the reference is usually the SUT — RX is “feeding in” (testing the SUT’s ability to take a hit), TX is “sending out” (testing whether others can defend against a rogue SUT).

4. Restbus Simulation: Completing the Environment’s Other Half

Direction settled — the next question: what happens when the SUT’s “colleagues” aren’t there?

Once an ECU goes into a car, a dozen-plus “colleagues” on the bus send it messages on their own cycles: ESP sends vehicle speed, BCM sends light states, the gateway forwards signals from other segments… It is born assuming these messages are all there.

On a HIL rig, only this one real ECU exists; the others are absent. Restbus simulation is this: the rig plays every absent ECU and sends the frames they owe, frame for frame — correct periods, plausible signal values, rolling counter and checksum advancing per algorithm.

The meaning of “restbus”: the whole car = the complete bus; once the SUT is removed, the remaining part of the bus is filled in by simulation.

5. Without It, a Chain Reaction Starts Immediately

The ECU under test is not an orphan; its behavior depends on bus inputs. Without restbus simulation:

1. Communication-loss faults: expected cyclic frames don’t arrive (timeouts from a few hundred ms to a few seconds), the ECU concludes “some ECU is dead,” logs a DTC, and lights the warning lamp;
2. Functional degradation: many ECUs enter a limp-home degraded mode when they detect communication loss — what you’re testing is no longer normal function but fault handling;
3. Test cases all void: you want to test “AEB triggers at 50 kph,” but nobody sends ESP’s speed frame, so the SUT thinks the car is standing still — the stimulus never even gets in.

One sentence: HIL tests “the ECU’s behavior in a normal vehicle environment,” and restbus simulation is the bus half of that environment (the other half is electrical I/O, handled by the I/O cards). It is the bulk of the work in rig setup.

6. The Three Genuinely Hard Points in Configuration

• Rolling counter / checksum: modern messages carry an anti-replay rolling counter and a CRC (AUTOSAR E2E protection); the simulation must update them per frame with the correct algorithm — sending fixed values gets judged “data not trustworthy”;
• Signal values must be “plausible”: gear, RPM, and vehicle speed are physically consistent with each other; random combinations trip the SUT’s plausibility checks;
• Multiple bus segments: FD segments, classic segments, Ethernet segments — the gateway routing has to be simulated correctly too.

7. XCP: From “Listening to the Bus” to “Reading the Memory”

Restbus simulation solves “the environment half.” One question remains: can you see what the SUT is thinking inside? Plain bus listening can’t; XCP can. The two are entirely different postures:

8. Three Capabilities Listening Can Never Have

1. Seeing internal intermediates: the bus carries only input frames and output frames; everything between is a black box. Is the integrator saturated? Which step is the state machine stuck on? What TTC was computed? — only XCP can read these directly;
2. DAQ high-speed synchronized acquisition: have the ECU actively push out specified variables inside its own task cycle, strictly synchronized with the control loop and timestamped — every point of a 100 µs control loop can be captured;
3. Online calibration: change a threshold without recompiling and reflashing — XCP writes the ECU’s RAM directly (page switching), effective the next cycle. This is the foundation CANape/INCA are built on.

One step further is bypass: an entire algorithm inside the ECU is bypassed, with an external model computing the result and injecting it back — the rapid control prototyping (RCP) play.

9. Observability Depth Has a Price

• The depth of what a verdict can observe differs: listening can only judge “is the output right,” while XCP can judge “is the internal process right” — and functional-safety audits often want the latter as evidence;
• The price: XCP needs the ECU’s cooperation (integrated driver, consumed resources), and production units may disable it; listening is always available.

Looking back, these three concepts answer three questions on the same chain: RX/TX sets direction — pin down the reference before talking about “speaking and listening”; restbus simulation completes the environment — make the SUT believe it’s in a real car; XCP opens depth — let the test see what the SUT is thinking. Get the reference wrong and every log is twisted; miss half the environment and the stimulus never gets in; lack observability depth and verdicts stall at “is the output right.” With all three in place, the bus layer is finally under control.

Appendix: Glossary (in order of appearance)