Signal-Based Communication

Intermediate10 min read

Assumes: 1.2 ECU Basics & Vehicle Networks

Module Progress0/4 pages mastered

Prerequisites: Module 1 (ECU networks), Module 2 (E/E architecture) What you’ll learn: Signal-based CAN communication, service-oriented architecture, SOME/IP deep dive, gRPC and protobuf for automotive.

TL;DR

Signal-based communication is the original automotive pattern: a named value (e.g. VehicleSpeed) lives inside a CAN frame (e.g. ID 0x123), transmitted periodically on a schedule (e.g. every 10 ms). Every consumer knows the frame ID, byte offset, scaling factor, and cycle time at compile time. Routing is static. In AUTOSAR Classic, PDU routing maps incoming Protocol Data Units to the right software modules. This works beautifully for small, deterministic systems (10–50 ECUs). It breaks down at scale when you have hundreds of signals, dynamic consumers, and zonal architectures where “who needs what” changes per vehicle variant.

If you’ve ever opened a DBC file and wondered why EngineRPM sits at bit 16 of frame 0x0C4 — and who decided that at 3 AM in 2008 — you’re looking at signal-based communication in its purest form. This is still how most body ECUs, powertrain controllers, and legacy gateways talk today. Forty years of “if it ain’t broke, don’t migrate it.”

Signals Are Named Values in Frames

A signal is not a message. It’s a semantic slice of a message.

Concept	What It Is	Example
Frame / PDU	The container on the bus	CAN ID 0x123, 8 bytes, sent every 20 ms
Signal	A named, typed value inside the frame	VehicleSpeed: 16 bits, offset 0, factor 0.01, unit km/h
Cycle time	How often the frame repeats	10 ms = 100 Hz
Sender	The ECU that transmits this frame	Powertrain ECU
Receivers	ECUs that decode this frame	Cluster, ADAS, gateway

When the powertrain ECU sends frame 0x123, every receiver simultaneously gets the same bytes. There is no “request.” The data broadcasts on a schedule, like a heartbeat. Think of it this way: a signal is a slice of a frame. What’s inside the envelope matters, not who sent the letter.

flowchart LR
    subgraph Frame["CAN Frame 0x123 (every 10 ms)"]
        S1["VehicleSpeed<br/>16 bits @ offset 0"]
        S2["EngineRPM<br/>16 bits @ offset 16"]
        S3["GearPosition<br/>4 bits @ offset 32"]
    end

    TX["Powertrain ECU<br/>(sender)"] -->|"broadcast"| Frame
    Frame -->|"decode"| RX1["Instrument Cluster"]
    Frame -->|"decode"| RX2["ADAS ECU"]
    Frame -->|"decode"| RX3["Gateway → Ethernet"]

Periodic Transmission: The Heartbeat Model

Signal-based buses are event-scheduled, not event-driven. The sender transmits whether or not anyone cares this cycle.

Property	Implication
Fixed cycle time	Predictable bus load; easy WCET analysis
Broadcast	One transmission serves all receivers
No handshake	Receiver can’t ask “send me speed now”
Stale data detection	Timeout if frame missing for N cycles

This is why CAN timing is so rigid. A classic CAN bus at 500 kbit/s (or 1 Mbit/s on some powertrain/chassis networks) with 50 frames at 10 ms each has a calculated bandwidth budget. Add one frame without re-analysis and you risk bus overload. CAN signals are a metronome (tick, tick, tick), not a doorbell that rings when needed.

Mental Model

Signal-based communication is a radio station. The powertrain ECU is the DJ who broadcasts VehicleSpeed on channel 0x123 every 10 ms. The cluster, ADAS, and gateway are listeners who tune in, decode the signal, and act. Nobody calls the station to request a song — you get what’s on the schedule. If the station goes silent, listeners assume something broke (timeout / DTC).

Mnemonic: Signals are postcards — fixed sender, fixed receiver, fixed schedule.

Think About It

You add a new CAN signal for a rearview camera status. Nothing else changes. Why do 5 other ECUs need a software update?

Reveal Answer

In signal-based systems, every receiver must know the frame ID, bit offset, scaling, and cycle time at build time — there is no runtime subscribe. Adding RearCameraStatus to the DBC forces the full AUTOSAR toolchain (DBC → ARXML → COM → RTE → SW-C) to regenerate on each ECU that decodes or forwards that frame, including gateway PduR routing tables. The camera ECU alone cannot “just start sending”; the cluster, ADAS, infotainment gateway, and body controller all need matching config and a reflash to accept the new signal layout.

Static Routing: Known at Build Time

In signal-based systems, who talks to whom is defined before the vehicle leaves the factory:

1. Network design: DBC / ARXML defines every frame, signal, sender, receiver
2. ECU configuration: each module’s COM stack knows which frames to TX/RX
3. Gateway routing tables: which CAN frames get forwarded to which buses
4. No runtime discovery: a new consumer can’t “subscribe” without a reflash

This is static routing. The topology is a fixed graph baked into configuration files.

Static Routing Advantage	Static Routing Cost
Deterministic, analyzable	Every new consumer = config change
No discovery overhead	Vehicle variants multiply config matrices
Works on low-power MCUs	Cross-domain changes need full toolchain
Proven in safety certification	“Just add a signal” is never just that

PDU Routing in AUTOSAR Classic

If you work anywhere near body or powertrain on a traditional OEM stack, you’ll encounter AUTOSAR Classic and its communication stack. The key abstraction above raw CAN is the PDU (Protocol Data Unit).

flowchart TB
    APP["Application SW-C<br/>(e.g. SpeedDisplay)"]
    RTE["RTE"]
    COM["COM module"]
    PDUR["PduR<br/>(PDU Router)"]
    CANIF["CanIf"]
    CAN["CAN Driver"]

    APP <-->|"RTE signals"| RTE
    RTE <-->|"Com signals"| COM
    COM <-->|"I-PDUs"| PDUR
    PDUR <-->|"L-PDUs"| CANIF
    CANIF --> CAN

What PduR does:

• Gateway routing: forward PDU from CAN1 to CAN2 or to Ethernet
• Multiplexing: combine multiple signals into one PDU for transmission
• Fan-out: one received PDU feeds multiple upper-layer modules
• Transport protocol: segment large data (ISO-TP) when signals exceed 8 bytes

The COM module maps between ComSignals (what your SW-C sees) and I-PDUs (interaction-layer containers). Your application never touches raw CAN bytes. It reads Rte_Read_VehicleSpeed() and the stack handles the rest.

Common Gotcha

If you add a signal to the DBC and expect your SW-C to see it immediately, nothing changes until the full toolchain regenerates.

AUTOSAR is a chain: DBC → ARXML → COM config → RTE → SW-C. Updating the DBC alone updates nothing. Every link must be regenerated, validated, and re-flashed.

Common Gotcha

Beginner thinks signal-based communication is “simple” because CAN has been around for decades.

Reality: at 70+ ECUs and hundreds of signals, static routing becomes a combinatorial integration nightmare. Every new consumer requires config changes across multiple ECUs — which is exactly why the industry is moving to SOA for cockpit and zonal domains.

Why It Works: Small, Deterministic Systems

Signal-based communication excels when:

Condition	Why Signals Win
10–50 ECUs	Routing tables are manageable
Fixed topology	Every receiver known at design time
Hard RT requirements	Periodic frames = predictable bus load
Safety certification	Static config = analyzable, auditable
Low bandwidth needs	Broadcast is efficient when many consumers need the same data

This is why your ABS ECU, door module, and steering rack still speak CAN signals in 2026. The pattern is 40+ years proven. ISO 26262 evidence for signal-based comms is mature. Tooling (Vector CANoe, EB tresos, DaVinci) is entrenched.

Why It Breaks at Scale

Modern cockpit and zonal architectures expose the limits:

Signal Explosion

A premium vehicle can have 3,000+ signals across 15+ buses. Each signal has sender, receivers, cycle time, scaling, endianness, and variant conditions. The configuration matrix becomes the bottleneck, not the hardware.

Dynamic Consumers

Center-stack apps, OTA services, and cloud diagnostics need data on demand, not on a 100 ms schedule. Adding a new AAOS consumer to VehicleSpeed shouldn’t require regenerating ARXML for six ECUs. In a pure signal world, it does.

Zonal Architecture Mismatch

In a zonal design, a zone controller aggregates dozens of sensors and exposes capabilities to a central compute unit. The zone doesn’t want to broadcast 200 raw signals. It wants to offer DoorService.lock() and CabinTemp.read(). Signals can’t express that.

Cross-Domain Friction

Your QNX VM needs gear state from a CAN gateway. Your AAOS app needs the same. In signal world, both decode the same frame independently: duplicate parsing, duplicate config, duplicate bugs. There’s no shared service contract.

flowchart TB
    subgraph OldWay["Signal-Based at Scale 😰"]
        CAN["15 CAN buses<br/>3,000+ signals"]
        G1["Gateway 1<br/>200 routing rules"]
        G2["Gateway 2<br/>180 routing rules"]
        ECU1["ECU A<br/>decodes 400 signals"]
        ECU2["ECU B<br/>decodes 350 signals"]
        AAOS["AAOS<br/>decodes 200 signals again"]
        CAN --> G1 --> G2
        G2 --> ECU1
        G2 --> ECU2
        G2 --> AAOS
    end

CAN FD and Signal-Based Limits

CAN FD (Flexible Data-rate) raised the payload from 8 to 64 bytes and added a faster data phase (commonly 2 Mbit/s, with arbitration still at classic rates like 500 kbit/s or 1 Mbit/s), but it didn’t change the paradigm. You still have periodic frames, static routing, and broadcast semantics. CAN FD is a wider pipe, not a different language. Automotive Ethernet (100BASE-T1, 1000BASE-T1) provides the bandwidth for service-based communication, which is why the industry is migrating domain controllers and zonal gateways to Ethernet + SOME/IP, while keeping CAN for legacy ECUs and safety-critical sensor loops.

Where You'll See This

You’ll encounter signal-based communication daily even on a QNX/AAOS platform:

• DBC / ARXML files in the repo: these are the “source of truth” for what signals exist. Search for VehicleSpeed or GearLeverPosition to see how your vehicle encodes them.
• CAN logs from CANoe / Wireshark: when debugging “cluster shows wrong speed,” you’ll decode frame 0xXXX and check scaling, endianness, and cycle time.
• Gateway routing tables: the QNX gateway ECU or virtual CAN bridge forwards specific frames between CAN and Ethernet. Misconfigured routing = signal arrives on wrong bus or not at all.
• Signal timeouts: if a frame stops, downstream modules set DTCs. “Speed signal invalid” often means the sender ECU crashed or bus wiring failed, not a software bug in the consumer.
• Variant coding: the same frame ID may carry different signals on Sport vs Base trim. Always check which variant your build targets.

When someone says “just expose VehicleSpeed to the Android app,” the signal-based answer is: update DBC → regenerate ARXML → reconfigure gateway → reflash three ECUs. The service-based answer (Module 3.2) is: subscribe to a VehicleSpeed field on SOME/IP. That difference is why this module exists.

Connect the Dots

Module 3.2 (SOA) introduces the service model that replaces signal explosion. Module 3.3 (SOME/IP) is the protocol your vehicle bus actually runs on. Module 3.4 (gRPC) covers the inter-VM layer where signals and services meet your QNX↔AAOS boundary. Module 0 (Physical Interfaces) covers CAN transceivers and Ethernet PHYs; Module 4 (AUTOSAR Classic) details the COM/PduR stack diagrammed above. Page 9.5 (Vector Toolchain) covers CANoe — the tool you use daily to capture, decode, and simulate the CAN signals described here. Import your DBC file into CANoe to see these signals live on the bus.

Takeaways

1. A signal is a named, typed value inside a periodically transmitted frame, not a standalone message.
2. Static routing means every sender, receiver, and route is known at build time. No runtime discovery.
3. AUTOSAR Classic PduR routes PDUs between buses and modules. Your SW-C sees signals, not raw CAN.
4. Signals excel in small, deterministic, safety-certified systems, and break at zonal/cockpit scale.
5. When you hear “3,000 signals,” think configuration nightmare, not bandwidth problem.

Check Your Understanding

1. A CAN frame with ID 0x123 is sent every 10 ms containing VehicleSpeed and EngineRPM. What communication pattern is this?

Recall

A. Point-to-point RPC — each registered receiver gets a dedicated message copyB. Request/response — cluster requests speed from the powertrain ECU each cycleC. Periodic broadcast — sender transmits on a fixed schedule regardless of listenersD. Event-driven pub/sub — receivers subscribe at runtime to speed update topics

2. What is the maximum data payload of a classic CAN 2.0 frame (excluding the CAN header and CRC)?

Recall

A. 64 bytes — matching the CAN FD extended payload maximum frame sizeB. 256 bytes — matching the ISO-TP transport layer segment size limitC. 4 bytes — limited by the original Bosch specification for data fieldsD. 8 bytes — the fixed upper limit for classic CAN 2.0 data payloads

3. You added VehicleSpeed to the DBC file but the AUTOSAR SW-C still can't read it. What's the most likely cause?

Applied

A. The signal must be sent via gRPC to the QNX VM before SW-C accessB. CAN bus baud rate is too low for the newly added speed signalC. The DBC update didn't propagate through ARXML → COM → RTE → SW-CD. VehicleSpeed must use SOME/IP transport instead of CAN broadcast

4. A cluster ECU detects that frame 0x123 (VehicleSpeed) has not arrived for 5 consecutive expected cycles. What signal-based mechanism triggered the fault?

Applied

A. gRPC stream backpressure stalled the vsock channel between QNX and AAOSB. ISO-TP segmentation failure due to an oversized speed data payload transferC. SOME/IP-SD TTL expiry triggered on the vehicle speed service subscriptionD. Stale-data timeout — receiver expected periodic frames and flagged missing ones

5. Why does signal-based communication break down in zonal architectures with 100+ ECUs?

Applied

A. Static routing and signal explosion make the config unmaintainable at scaleB. CAN signals are unable to carry numeric values larger than 8 data bytesC. AUTOSAR Classic platform does not support more than 50 signals per vehicleD. CAN transceiver hardware cannot physically connect more than ~100 ECU nodes

6. A gateway ECU must forward a CAN1 I-PDU containing VehicleSpeed to the infotainment CAN bus without the application SW-C touching raw bytes. Which AUTOSAR Classic module performs this bus-to-bus routing?

Synthesis

Connects to: Module 4 — AUTOSAR Classic COM Stack

A. RTE — auto-generates DBC signal definitions from application source codeB. CanIf — translates CAN frames directly into Ethernet SOME/IP messagesC. vsomeip — handles inter-VM gRPC proxying between QNX and AAOS guestsD. PduR — routes I-PDUs between bus interfaces like CAN1→CAN2 or CAN→ETH

Further Reading

• ISO 11898-1 — Road vehicles — Controller area network (CAN) — The foundational CAN standard defining the periodic broadcast frame model that signal-based communication builds on.
• AUTOSAR Classic Platform — Communication Stack (Com, PduR, CanIf) — Official specification for the AUTOSAR COM module and PDU Router described in the stack diagram — the software layer between your SW-C and raw CAN bytes.
• Vector CANoe — Network Analysis and Simulation — Industry-standard tool for capturing, decoding, and simulating CAN signals using DBC files — the daily debugging workflow referenced in DailyWork.
• Vector — DBC File Format Description — Technical reference for the DBC signal database format (frame IDs, bit offsets, scaling factors) used as the source of truth for signal definitions.
• AUTOSAR Classic — PDU Router (PduR) Specification — Detailed PduR software specification covering gateway routing, multiplexing, and fan-out between buses and upper-layer modules.
• ISO 15765-2 — Diagnostic communication over CAN (ISO-TP) — Transport protocol for segmented CAN messages when signals exceed the 8-byte (or 64-byte CAN FD) frame limit.
• CAN in Automation (CiA) — CAN FD Specification — CAN FD overview explaining the wider pipe (64-byte payloads, flexible data rate) that extends but does not replace the signal-based paradigm.
• Elektrobit tresos — AUTOSAR Classic Configuration Toolchain — EB tresos and similar tools (DaVinci, ISOLAR) implement the DBC → ARXML → COM → RTE chain described in the Gotcha callouts.