IVN Topology and Bandwidth Planning

Once you know which protocols belong in the vehicle, you still need to decide how they are wired. In-vehicle networking topologies range from a single CAN bus with end terminators to segmented CAN networks and switched Automotive Ethernet backbones. Topology and bandwidth planning decide how robust the IVN will be under control, diagnostics, OTA and logging traffic.

Common IVN topologies

• Single bus + terminators: all ECUs share one CAN or LIN segment with end-of-line termination. Simple and low cost, but with single-bus failure and congestion risks.
• Segmented CAN with gateways: multiple CAN or CAN FD segments (body, powertrain, chassis) are interconnected by one or more gateways that filter and rate-limit cross-domain traffic.
• Star/tree Ethernet with switches: ECUs connect point-to-point into switches or gateways, creating a star or tree backbone that scales to ADAS and central compute bandwidth.

Bandwidth and latency considerations

A practical planning rule is to estimate average load as the sum of each message payload multiplied by its update rate, then add margin for diagnostics, OTA and logging. If a CAN bus runs above roughly half of its usable bandwidth for long periods, consider adding segments or moving heavy flows to CAN FD or Ethernet.

Latency and jitter sensitivity also differ: EPS, brake and certain ADAS controllers require low latency and tightly bounded jitter, while many body and comfort functions only need eventual delivery within human-perception limits.

1. List all ECUs and key signals, grouped by domains such as body, powertrain, chassis and ADAS.
2. Tag each signal with approximate payload size, update rate, latency sensitivity and safety level.
3. Assign signals to LIN, CAN, CAN FD or Ethernet segments according to their bandwidth and criticality.
4. Estimate average and peak load per bus and verify that enough headroom remains for diagnostics, OTA and logging.

CAN, LIN and FlexRay Transceiver Selection

Transceivers sit at the boundary between digital ECUs and harsh automotive wiring. Compared to generic interface ICs, automotive LIN, CAN and FlexRay transceivers must survive wide bus voltages, ESD and surge, meet EMC limits and support low-power and wake-up modes. This section turns the transceiver data sheet into a short checklist for IVN design and procurement.

LIN, CAN/CAN FD and FlexRay selection notes

LIN transceivers support low-speed body and comfort nodes. They should prioritise ultra-low sleep current, flexible wake-up sources and robust ESD and EMC behaviour over raw data rate. A single master and several slaves share the bus, so master-node robustness and fail-safe behaviour are especially important.

CAN and CAN FD transceivers carry most vehicle control traffic. For body CAN, cost and EMC-tuned slew-rate options dominate. For powertrain, chassis and safety-related CAN or CAN FD, transceivers must tolerate harsh faults, support fast data phases where needed and provide diagnostics such as dominant timeout and error indication pins for the MCU.

FlexRay transceivers remain relevant on legacy x-by-wire platforms where dual-channel, time-triggered communication is already deployed. They must support two independent channels, strong bus fault protection and tight timing relationships with the MCU’s FlexRay controller. New designs often migrate to Ethernet backbones while only maintaining FlexRay where absolutely required.

On safety-relevant buses, combine robust transceivers with MCU-side measures such as UVLO handling, error inputs and watchdog supervision. Detailed ASIL allocation belongs to the functional safety sections, but IVN transceiver choices provide the first line of protection at the interface to the wiring harness.

Ethernet PHY, Switch and TSN for IVN Backbones

ADAS sensors, high-resolution cameras, central compute and data logging quickly exceed the bandwidth of CAN and CAN FD. Automotive Ethernet with TSN provides a scalable backbone that can transport both deterministic control traffic and large best-effort data flows over single-pair twisted cables. This section highlights the key PHY and switch parameters you must specify when planning an Ethernet-based IVN.

Automotive Ethernet basics

100BASE-T1 and 1000BASE-T1 are single-pair Ethernet PHYs optimised for in-vehicle wiring. They support point-to-point, full-duplex links over tens of metres of twisted pair and can be deployed in star or tree topologies anchored by Ethernet switches and gateways. Compared to traditional CAN, the physical layer is more sensitive to cabling balance, EMC and connector design.

• 100BASE-T1: 100 Mbit/s, common for camera aggregation and backbone links.
• 1000BASE-T1: 1 Gbit/s, used for high-resolution sensors and central compute ties.
• Single-pair twisted cable: reduces weight while demanding tight control of impedance and balance.

ETH PHY selection map

When selecting Automotive Ethernet PHYs, start by fixing the data rate, cable type and link reach. From there, look at low-power modes such as Energy Efficient Ethernet (EEE), wake behaviour and diagnostics such as cable fault detection and link quality reporting. For ADAS and backbones, temperature range, EMC-tuned variants and robust link monitoring are often more important than the lowest bill-of-materials cost.

• Data rate and reach: 100 vs 1000 Mbit/s, supported cable length and topology.
• Low-power modes: EEE and standby states, including wake-up timing for ADAS use cases.
• Diagnostics: cable diagnostics, link quality metrics and error counters for production and field tests.
• Temperature and EMC: automotive temperature grades and variants tuned for CISPR 25 performance.

Switch & TSN feature checklist

Ethernet switches in IVN backbones connect sensors, domain controllers and central ECUs. Port count, uplink interfaces and QoS features must match your chosen topology and bandwidth plan. At the same time, basic security and TSN support avoid turning the backbone into a fragile bottleneck or single point of failure.

• Ports and uplinks: x-port switch size, number of sensor and backbone ports, interface to SoC.
• QoS and VLAN: multiple queues, VLAN separation for ADAS, infotainment and diagnostics, IGMP snooping.
• Security: port locking, storm control and basic rate limiting to contain misbehaving nodes.

TSN adds time awareness and per-stream control on top of Ethernet. In practice, most IVN designs focus on a small subset of TSN features:

• 802.1AS – Time sync: used when multiple sensors and controllers must share a common time base.
• 802.1Qbv – Scheduled traffic: used when critical control flows run over the backbone and jitter must be bounded.
• 802.1Qci – Per-stream policing: used to stop a single faulty node from flooding the Ethernet backbone.

You do not need every TSN option in every platform. Instead, decide which flows truly require precise time alignment or scheduled bandwidth, then confirm that the selected switches and PHYs support those specific TSN building blocks.

EMC, ESD, Common-Mode and Cabling Checklist for IVN

In-vehicle networks run across long harnesses in a harsh environment. Robust EMC and ESD behaviour depends on both cabling practices and the capabilities of LIN, CAN and Ethernet interface ICs. This section does not try to replace a full EMC layout guide. Instead, it summarises IVN-specific checks you should review when defining harnesses, terminations and transceiver requirements.

Cabling and common-mode control

• Twisted pair symmetry: keep differential pairs as balanced and consistent as possible over the harness run.
• Common-mode choke placement: place chokes close to connectors, balancing insertion loss and common-mode rejection.
• Termination and common-mode bias: ensure bus terminations and centre bias networks follow the intended topology.
• Shielding and grounding: decide early on single-point vs multi-point shield connection, based on EMC and corrosion constraints.

EMC and robustness checklist for IVN interface ICs

Migrating Legacy IVN Platforms to Ethernet and TSN

Most vehicles on the road started as LIN, CAN or FlexRay-heavy platforms. Moving toward an Ethernet and TSN backbone is rarely a single-step redesign. Instead, migration happens in phases, adding CAN FD segments, short Ethernet backbones and new ADAS domains while keeping legacy ECUs alive. This section outlines typical migration paths and the interface ICs that enable them.

Typical migration paths

• LIN / CAN-heavy → CAN FD + short Ethernet backbone: upgrade high-load CAN segments to CAN FD while keeping wiring largely intact, then add a short 100BASE-T1 Ethernet backbone around the central gateway or ADAS controller.
• FlexRay → Ethernet with TSN: replace time-triggered FlexRay channels with a TSN-capable Ethernet backbone while keeping CAN for legacy body and diagnostics traffic during the transition.
• Mixed buses → Ethernet-centric next platform: on new architectures, treat Ethernet as the primary backbone and keep LIN/CAN as cost-efficient local networks attached through gateways.

Migration strategy

• Do not upgrade every ECU at once: prioritise nodes under the most pressure from bandwidth, diagnostics or OTA—typically gateways, telematics and ADAS domain controllers.
• Use gateways for protocol conversion: treat the gateway as the boundary between legacy LIN/CAN/FlexRay segments and the new Ethernet backbone, with message filtering and rate limiting built in.
• Insert Ethernet first around new ADAS domains: connect new ADAS controllers and sensor hubs via 100BASE-T1/1000BASE-T1 links rather than adding more CAN branches into already congested buses.

Key risks in mixed networks

Mixed networks introduce new diagnostic and timing challenges. OTA and service tools may need to traverse telematics, Ethernet, gateways and legacy buses to reach every ECU. At the same time, Ethernet and TSN nodes often share a precise time base, while older CAN or FlexRay ECUs only have coarse timing awareness.

• Diagnostics and OTA: verify that each migration step preserves end-to-end access to all ECUs, and that gateways do not become a throughput bottleneck for updates and logging.
• Time synchronisation: plan how critical ECUs will align timestamps between Ethernet/TSN and legacy buses, even if older nodes only support coarse synchronisation via the gateway.

BOM Fields and Procurement Question Checklist

This section is written for procurement teams, project owners and small integrators. The goal is to turn the IVN discussions above into concrete BOM fields and RFQ questions, so suppliers clearly understand which protocol types, robustness levels and diagnostic features you need. The bullets below highlight what should be written into your enquiry forms rather than left implicit.

Bus & protocol basics

• Bus / protocol type: LIN, CAN, CAN FD, FlexRay, 100BASE-T1, 1000BASE-T1 or other Ethernet variants required.
• Topology and segment role: single bus, segmented CAN, Ethernet backbone, sensor link, camera link or domain-to-gateway connection.
• Data rate and maximum length: required bit rate per segment and maximum harness length for each link class.
• Node and port counts: number of ECUs per segment, switch ports and any planned expansion capacity.

Robustness & EMC

• Supply and protection: supply voltage (for example 5 V or 3.3 V) and compatibility with load dump and jump-start conditions.
• ESD and EMC levels: bus-pin ESD targets (for example IEC 61000-4-2 contact / air levels) and desired CISPR 25 or similar emission and immunity performance.
• Bus fault protection: acceptable short-to-battery and short-to-ground limits (for example up to ±58 V on CAN or LIN pins).
• Temperature grade: required operating range such as –40 °C to +105 °C or –40 °C to +125 °C, depending on mounting location.
• EMC options: need for low-EMI variants, slew rate control modes or pin-compatible options with improved emission behaviour.

Integration & diagnostics

• Sleep and wake behaviour: maximum allowed sleep current and which wake mechanisms are required (bus, local pin, timer, remote wake).
• Diagnostic features: bus error flags, dominant timeout behaviour, cable diagnostics, link quality metrics and error counters.
• Safety and monitoring: needs for short-to-battery detection, bus-stuck detection, over-temperature shutdown and safety-related monitoring pins.
• TSN support (for Ethernet): whether 802.1AS, 802.1Qbv, 802.1Qci or other TSN building blocks must be supported in hardware or software.

Typical ECU Network Configurations – Quick Reference

This section gives a quick view of how common ECUs connect into the in-vehicle network. The table below maps each ECU type to its primary and secondary buses, along with typical interface IC combinations. It does not explain each function in detail; instead it focuses on practical network configuration and the link devices you will usually see in successful designs.

Recommended topics you might also need

• Gateway / Central Compute
• ADAS Domain Controller
• Telematics / Connectivity

In-Vehicle Networking – Frequently Asked Questions

These twelve questions turn the IVN topic into short, decision-oriented answers you can reuse in specs, RFQs and customer discussions. Each answer shows how to think about Ethernet or TSN, bus selection, EMC levels and typical per-ECU patterns so you can move from slideware to a realistic network plan.