Signal-Based Communication

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, 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.

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 500 kbit/s bus 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).

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

“We added the signal to the DBC, why doesn’t my SW-C see it?” Because AUTOSAR is a chain: DBC → ARXML → COM config → RTE → SW-C. Updating the DBC alone updates nothing. Every link in the chain must be regenerated, validated, and re-flashed. This is the #1 frustration when moving from Android/QNX world (dynamic APIs) to Classic AUTOSAR (static config).

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 increased bandwidth, 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.

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 4 covers CAN and Ethernet buses in hardware detail.

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?

A. Request/response — the cluster requests speed from the powertrain ECUB. Periodic broadcast — the sender transmits on a fixed schedule regardless of who listensC. Event-driven pub/sub — receivers subscribe at runtime to speed updatesD. Point-to-point RPC — each receiver gets a dedicated message

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

A. CAN bus speed is too low for the new signalB. The DBC update didn't propagate through ARXML → COM config → RTE → SW-CC. VehicleSpeed requires SOME/IP instead of CAND. The signal needs to be sent via gRPC to the QNX VM

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

A. CAN hardware can't physically connect that many ECUsB. Static routing and signal explosion make configuration unmaintainable; dynamic consumers can't be added without reflashing multiple ECUsC. Signals can't carry numeric values larger than 8 bytesD. AUTOSAR Classic doesn't support more than 50 signals per vehicle