FlexRay TDMA Architecture - Vehicle Networks

TDMA Fundamentals: Deterministic Slot Assignment

FlexRay Communication Cycle Structure

  ←──────────────── One Communication Cycle (e.g., 2 ms) ─────────────────→
  ┌────────────────────────────┬──────────────┬──────────┬─────────────────┐
  │  Static Segment (TDMA)     │   Dynamic    │  Symbol  │  NIT            │
  │  Slot 1 | Slot 2 | Slot 3  │  Segment     │  Window  │  (sync correct) │
  │  Node A | Node B | Node C  │  (FTDMA)     │          │                 │
  └────────────────────────────┴──────────────┴──────────┴─────────────────┘
  Each static slot: pre-assigned globally — one node per slot
  Node always transmits in its slot regardless of whether it has new data
  Worst-case latency = 1 cycle = deterministic (e.g., 2 ms)

💡 FlexRay vs CAN for Safety-Critical Functions

CAN arbitration provides best-effort access — a high-priority message can be delayed by a burst of lower-priority traffic or an error frame. FlexRay static slots provide a mathematically guaranteed transmission window every cycle — no node can prevent another from using its slot. This deterministic guarantee is why FlexRay was chosen for X-by-wire systems (steer-by-wire, brake-by-wire) where worst-case message latency must be bounded.

Communication Cycle Parameters

Parameter	Symbol	Typical Value	Description
Cycle duration	gdCycle	1–5 ms	Duration of one complete communication cycle
Number of static slots	gNumberOfStaticSlots	50–200	Total static slots per cycle across all nodes
Static slot duration	gdStaticSlot	2000–5000 ns	Duration of one static slot (all same size)
Max static payload	gPayloadLengthStatic	12 words (24 bytes) – 127 words (254 bytes)	Payload length in 16-bit words; all slots share same size
Number of minislots	gNumberOfMinislots	0–7988	Dynamic segment size; 0 = no dynamic segment
Minislot duration	gdMinislot	200–2000 ns	Duration of one minislot in dynamic segment

Pythonflexray_bandwidth_calc.py

# FlexRay bandwidth utilisation calculation
gdCycle_ns     = 2_000_000  # 2 ms in nanoseconds
gdStaticSlot_ns = 2500       # 2.5 µs per slot
gNumStaticSlots = 50
gPayloadWords   = 12         # 24 bytes per slot
data_rate_bps   = 10_000_000 # 10 Mbps

# Payload bandwidth per cycle
payload_bits_per_cycle = gNumStaticSlots * gPayloadWords * 16  # 16 bits/word
static_segment_ns = gNumStaticSlots * gdStaticSlot_ns
static_utilisation = static_segment_ns / gdCycle_ns * 100

print(f"Static segment: {static_segment_ns/1000:.0f} µs of {gdCycle_ns/1000:.0f} µs cycle")
print(f"Static utilisation: {static_utilisation:.1f}%")
print(f"Net payload throughput: {payload_bits_per_cycle / (gdCycle_ns/1e9) / 1e6:.1f} Mbps")
# Net payload: 50 slots × 24 bytes × 8 bits / 2 ms = 4.8 Mbps of 10 Mbps total

Physical Layer: Dual-Channel Redundancy

Parameter	Value	Note
Channels	A and B (independent)	Identical data; fault tolerance via redundancy
Topology	Active star or passive bus	Active star (TJA1080) for > 2 nodes; passive bus for 2 nodes only
Data rate	10 Mbps per channel	20 Mbps effective with redundant transmission
Differential signalling	±1 V (BP-BM)	Similar to CAN but with different voltage levels
Active star	TJA1080A	Regenerates signal on each branch; monitors branch health
Bus Guardian	Optional on node	Prevents a node from transmitting outside its slot (babbling idiot protection)

Node Architecture: CC, BD, Host

FlexRay Node Architecture

  Host (MCU/ECU Application)
  │  CHI (Controller Host Interface) — writes/reads frame buffers
  ▼
  CC (Communication Controller)
  │  Handles: slot timing, CRC, sync algorithm, startup/wakeup
  │  Infineon AURIX TC3x: integrated CC (E-Ray IP core)
  │  NXP MPC5748G: integrated FlexRay CC
  ▼
  BD (Bus Driver)
  │  TJA1080A — physical transceiver
  │  Handles: differential signalling, channel monitoring
  │  Active Star variant: adds branch power-down on fault
  ├──► Channel A bus ─── to other nodes
  └──► Channel B bus ─── to other nodes (redundant)

Summary

FlexRay's TDMA static segment provides deterministic worst-case latency equal to exactly one communication cycle — a mathematically provable bound unavailable in CAN. The dual-channel physical layer adds fault tolerance: if Channel A fails, Channel B continues operation transparently. Active star topology isolates a babbling node to its own branch, preventing one faulty node from disrupting the entire cluster.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.