Typical ADAS TSN topologies this switch has to support

When I plan an Automotive Ethernet TSN switch for an ADAS domain, I do not treat it as an isolated chip on a schematic. I picture the full domain topology: an ADAS domain controller SoC at the centre, multiple camera ECUs around the vehicle, radar and LiDAR ECUs at the corners, and at least one uplink into a central gateway or zone controller. Only after I have drawn that picture do I decide which topologies the switch must support and where I am willing to accept single points of failure.

The simplest pattern is a single TSN switch in a star. Every forward and surround-view camera ECU, plus radar and LiDAR ECUs, connects back to this switch over point-to-point Automotive Ethernet links. One or two uplinks then connect the switch to the ADAS domain controller and, often, to a central gateway or zone controller. For lower-channel-count Level 1 or Level 2 projects, this star is attractive: the harness is easy to reason about, diagnostics are straightforward and every flow passes through one place that I can instrument and control.

As channel counts grow, star topologies start to strain the harness. To reduce cable length and weight, I often see ECU chains or rings, especially for cameras and sensors mounted along the sides of the vehicle. Several camera ECUs may daisy-chain their Ethernet links, with the last node returning to the TSN switch, or a ring may close back into the domain. From the switch’s point of view, this means that some ports aggregate traffic from multiple sensors, not just one. My TSN configuration and uplink budgeting have to reflect that, or my worst-case utilisation estimates will be wrong.

For higher-assurance Level 2+ and Level 3 systems, I also need to think about dual-homing and dual-switch architectures. A critical ECU, such as the primary forward camera or a long-range radar, can be connected to two separate TSN switches with independent power and harness routes. The ADAS domain controller may itself have dual Ethernet interfaces, one into each switch. In that world, the question becomes: which ECUs are dual-homed, which stay single-homed, and which failures I am willing to tolerate without degrading the ADAS function below its safety goals.

Dual-switch topologies also affect how I handle uplinks. I might choose to give each TSN switch its own uplink into the central gateway or a zone controller, or I might concentrate traffic and rely on redundancy only at the sensor layer. Both options have cost and availability implications. A dual-uplink design improves resilience but consumes more gateway ports and harness resources. A single-uplink design is cheaper but may leave parts of the domain without a clean fallback path if the uplink segment fails.

At the end of this exercise, I categorise my topologies by both safety and cost. A single TSN star is cost-effective and simple to debug, but switch, supply or harness failures can knock out many sensors at once. Chains and rings reduce harness cost and make it easier to reach distant sensors, but they increase the complexity of failure analysis and rerouting. Dual-homed ECUs and dual-switch architectures improve availability and safety margins, at the expense of port count, uplink capacity and significant wiring complexity. The TSN switch I choose has to support the topologies I intend to deploy, not just the ones that look clean in a simplified lab setup.

Port count, speed and queue planning

Once I have settled on a topology, the next step is to turn that sketch into concrete numbers: how many ports I need, which speeds they must support, what uplink capacity is required and how many queues I need per port. This is where I stop thinking in generic “multiport TSN switch” terms and start writing specific combinations like “six 1 Gbit/s camera ports, two 100 Mbit/s radar ports and two multi-gig uplinks with at least four hardware queues per port.”

I start with downlink ports. For each camera ECU, I look at the maximum resolution, frame rate and encoding mode to derive a worst-case bitrate, including burst modes such as HDR or high-frame-rate capture. If I have four cameras that each peak near 200 Mbit/s, I treat them as 800 Mbit/s of potential load, not the average values quoted in marketing material. Radar and LiDAR ports get the same treatment, even if their average load is lower. In my selection criteria, I record not just the number of ports but how many must operate at 100BASE-T1, how many at 1000BASE-T1 and whether I need the flexibility to mix and match speeds as sensor generations change.

Uplink sizing is where people often under-specify. An uplink that looks sufficient on paper with average bitrates can be dangerously close to saturation when every camera and radar is simultaneously active during a safety-relevant manoeuvre. I budget uplink capacity from the worst-case downlink sum, plus control, diagnostics and logging overhead, and then add margin so that my target utilisation under worst-case load stays well below one hundred percent. That margin gives me room for future software updates, added sensors and real-world traffic patterns that are more bursty than my early models assumed.

In many ADAS designs, this analysis quickly pushes me beyond a single 1 Gbit/s uplink. If a switch is aggregating several 1 Gbit/s camera ports and additional radars, I often prefer either dual 1 Gbit/s uplinks with well-defined flow placement or a higher-speed uplink such as 2.5GBASE-T1 on the path towards the ADAS domain controller. The TSN switch I select must therefore support the mix of downlink speeds I need and either multiple uplinks or a multi-gig uplink with the right automotive-grade PHY options.

Queue planning is just as important as raw bandwidth. Each physical port must have enough hardware queues to accommodate my traffic classes without collapsing them into one generic “high” and one generic “low” class. If my switch only offers two queues per port, it is difficult to give control traffic, sensor streams and logging distinct behaviours. With four or more queues, I can map brake and steering control into the highest-priority queue with time-window protection, assign camera and radar flows to shaped queues, and reserve a lower-priority but still guaranteed queue for diagnostics and logging.

Per-queue shaping and policing turn those queues into real tools. I look for the ability to configure minimum and maximum rates per queue, so that my control and safety queues have reserved capacity that cannot be stolen by camera bursts, while logging and OTA queues are capped to avoid creeping expansion. On some links I might allow camera queues to use unused capacity opportunistically, but I never want them to be able to push control or safety-critical flows into unpredictable delay.

Store-and-forward versus cut-through switching is another dimension I have to decide explicitly. Store-and-forward switching waits for the full frame and verifies its integrity before forwarding, which adds per-hop latency but keeps corrupted frames from propagating further into the network. Cut-through forwarding starts sending a frame as soon as the header is received, which reduces per-hop latency at the cost of potentially forwarding corrupted data. On short, high-quality ADAS domain links where every microsecond counts, cut-through can help my latency budget. On longer or noisier harness segments, or where diagnostics are more important than a few microseconds of latency, I may prefer store-and-forward.

For that reason, I treat switching mode as a configuration requirement, not a footnote. In my RFQ and design notes, I specify where I expect store-and-forward behaviour and where cut-through is acceptable, and I ask whether the TSN switch allows per-port or per-class control. The IC that gives me this level of control makes it much easier to balance safety, diagnostics and latency systematically instead of accepting whatever default behaviour happens to ship with the device.

By the time I finish port, speed and queue planning, I have a concrete picture of what my TSN switch must look like: a precise downlink port mix, uplinks sized for worst-case and future headroom, enough queues per port to reflect my traffic classes, and explicit control over shaping, policing and switching mode. That set of requirements is far more actionable than a vague “TSN-capable Ethernet switch,” and it directly supports the ADAS safety and performance targets that I am responsible for.

Time sync and timestamping in the switch

I only start worrying about time sync inside the TSN switch when I care about more than just moving packets. In an ADAS network, my cameras, radar and LiDAR are all watching a moving world, and the ADAS domain controller wants their data aligned to a single timebase. If the switch does not help preserve or refine that timebase, it quietly becomes another source of error between the grandmaster and each sensor. So when I select an Automotive Ethernet TSN switch, I treat time sync and timestamping as a first-class requirement, not a background detail.

The first question I ask is what role the switch is expected to play in the gPTP or 802.1AS domain. In some designs, the switch stays out of the timing domain and simply forwards PTP messages transparently while a dedicated time-sync IC or the ADAS SoC itself runs the grandmaster and boundary clock logic. In others, the switch acts as a transparent clock, measuring and compensating for its own residence time so that multi-hop paths do not accumulate uncontrolled delay. In more advanced domains, the switch may host a boundary clock and participate directly in the 802.1AS topology. I do not need to decide every detail in this page, but I do need to state clearly which of these roles I expect the switch silicon to support.

Hardware timestamping is the next layer. I care about where the switch can apply timestamps and how precise those timestamps are. On a basic level I want ingress and egress timestamps on PTP event messages, at least in the microsecond range and preferably in the sub-microsecond or nanosecond range on critical links. I also want to know how those timestamps are exposed to the rest of the system: are they attached to descriptors, stored in per-port FIFOs, or made visible through dedicated registers that my PTP stack can read without racing the data path? Without clear answers, my time sync implementation will be guessing about what really happened in the switch.

Beyond pure PTP, I think about how timestamps flow into the sensor-fusion pipeline. If my cameras and radar send their data through the TSN switch into the ADAS SoC, the SoC needs either precise timestamps attached to the sensor streams or a tightly bounded delay model inside the switch so that software can reconstruct the timing. If I intend to trigger multiple cameras off a shared timebase, the switch has to forward the timing messages and schedule TSN windows in a way that keeps exposure and readout aligned. Otherwise, the apparent time alignment in my fusion algorithms will be an illusion.

In practice, I phrase these needs as requirements rather than as protocol names. I write down that the switch must preserve and, where applicable, correct time information for multi-hop ADAS sensor paths, provide hardware timestamps on PTP events at a given resolution, and make those timestamps available to the SoC without excessive software overhead. I also clarify whether I expect transparent or boundary clock behaviour and on which ports. The more explicit I am in my specification, the less likely I am to discover late in the project that my chosen switch cannot meet the fusion timing budget.

I do not try to solve the entire time-sync problem on this page. Detailed time-sync topology, grandmaster placement and error budgeting across PHYs, cables and ECUs are a separate exercise. I keep that work on its own Time Sync for Sensor Fusion page and let this section focus on what the TSN switch itself must support. That separation keeps my selection process clean: this page defines what I demand from the switch, and the time-sync page explains how I build a complete timing architecture around it.

Redundancy, health monitoring and diagnostics

Redundancy and health monitoring are the parts of the TSN switch that I only appreciate fully when something goes wrong. A link that flaps intermittently, a camera ECU that starts flooding the network, or a harness that slowly degrades over time can all turn a clean lab demo into an intermittent field failure. If my switch cannot detect, localise and contain these problems, the whole ADAS domain becomes difficult to debug and painful to operate. So I treat redundancy, health monitoring and diagnostics as core selection criteria, not as optional extras.

I think about redundancy at three levels. The first is topology, where I decide whether I am building a single-switch star, a chain or ring of ECUs, or a dual-switch architecture with dual-homed sensors and uplinks. The second is protocol behaviour: which forms of link aggregation, redundancy and fast failover are actually supported and how they interact with TSN scheduling. The third is the switch’s own fault behaviour: what it does when a link goes bad, a port storms the network or a switch in a redundant pair fails. A device that looks attractive on a block diagram but ignores the second and third levels is a poor fit for a serious ADAS project.

At the protocol level, dual uplinks and dual-switch topologies are the most visible features. If my TSN switch has two uplinks toward an ADAS domain controller or central gateway, I need clear behaviour when one uplink fails. Does the switch advertise the failure quickly to the redundancy protocol? Does it drain and reroute flows within a bounded time? Similarly, in a dual-switch architecture, I must understand how the chosen protocols and the switch hardware interact when one device goes offline. The silicon does not have to solve redundancy by itself, but it must expose the right signals and controls so that my redundancy strategy actually works.

Per-port health monitoring is just as important. I rely on per-port counters for link up/down events, link flaps and a range of error conditions such as CRC errors, symbol errors and alignment errors. Those counters let me decide whether I am dealing with a marginal harness, a noisy environment, a faulty ECU or a misconfigured TSN schedule. Without them, every failure looks the same in the field: “network unreliable,” with no clear path to root cause. I also expect to see storm-control information so that I can detect and limit broadcast or multicast floods before they take down the entire domain.

Loop detection and storm control deserve special attention. During service or late changes, it is easy for a harness to be miswired and create an unexpected loop. In a pure Ethernet world, that can saturate links, overload queues and disrupt time-sensitive traffic. A TSN switch that can detect loops, limit storm traffic and, if necessary, shut down or rate-limit the offending port gives me a controlled failure instead of a chaotic one. When I write my requirements, I state explicitly that I need loop detection and storm control with thresholds and actions I can configure.

I also think about “safe defaults” and isolation behaviour. When a port or a connected ECU misbehaves, I do not want the switch to oscillate randomly between states. I want it to apply clear rules: count errors, raise warnings, and if thresholds are exceeded, isolate or downgrade that port in a predictable way. Blacklisting a chronically faulty node, reducing its speed or confining its traffic to a limited set of queues are all useful tools, as long as the switch gives me enough control to document and justify the behaviour in my safety and service documentation.

None of this matters if the information stays locked inside the switch. For redundancy and diagnostics to be useful, the ADAS domain controller and any logger or event data recorder must be able to see the relevant statistics and events. I plan how the switch exposes its counters and alarms through a management interface, whether that is a dedicated management Ethernet port, an internal host interface or a sideband control bus. Then I define how the ADAS software will poll or subscribe to those signals and how it will write them into logs so that field engineers can reproduce and understand failures after the fact.

In my specification, I translate all of this into concrete expectations. I ask for per-port counters and clear link-flap reporting, configurable storm control and loop detection, and a way to isolate misbehaving nodes without disturbing the rest of the domain. I require that the switch support the redundancy topologies I intend to deploy and that it expose its health and fault information cleanly to my ADAS domain controller and logging system. A TSN switch that meets these criteria gives me a network that not only behaves deterministically in normal operation but also fails and recovers in ways that I can explain, test and support over the lifetime of the vehicle.

Power, thermal and layout notes

When I select an Automotive Ethernet TSN switch for an ADAS domain, I try not to treat it as a simple “bigger Ethernet PHY.” At the board level it is a dense digital and mixed-signal device with multiple rails, SerDes blocks, internal PLLs and sometimes integrated packet processing engines. If I do not plan power, thermal and layout details early, I can easily end up with a switch that meets the functional specification on paper but fails to deliver deterministic latency or long-term reliability in the vehicle.

On the power side, I first map out the rails. A TSN switch typically has at least a core rail, one or more I/O rails, SerDes rails and PLL or reference rails. I want to know which rails can share a regulator, which demand their own low-noise supply and whether any rails have special sequencing requirements. The rail map goes into my power-tree planning and will later drive the selection of a safety PMIC or discrete regulators; the detailed PMIC design lives on my separate Safety PMIC for ADAS Compute page, but here I still record what the switch itself expects.

I also look at how typical power scales with port count, line rate and TSN feature usage. A bare switch with a few 100 Mbit/s ports enabled is not the same as a fully loaded device aggregating several 1 Gbit/s cameras, radar and LiDAR streams while running time-aware scheduling and per-stream policing. I ask for numbers or estimates that reflect the worst realistic configuration for my project, not just a “typical” low-activity setting. Those numbers feed directly into my thermal budget and my PMIC current planning, especially if the ADAS domain controller and TSN switch share parts of the power tree.

Thermal design is the next step. Whether the package is QFN or BGA, I want to understand how much heat I am being asked to move into the PCB and eventually into the vehicle structure. For QFN devices, that usually means a generously sized exposed pad with a dense grid of thermal vias into a solid inner layer. For BGA, it means enough copper area in the core layers and, if needed, local copper floods on the outer layers to spread heat. During layout I reserve this area up front so it does not get eaten by late routing changes or nearby high-speed interfaces.

In higher-port-count or higher-speed designs, I also decide whether the TSN switch needs additional help, such as a small heatsink, a thermal interface pad to a shield or chassis, or enforced clearance from other hot components on the same board. I have learned that it is easier to plan mounting points and copper keep-outs early than to retrofit cooling late in the design. Whatever solution I choose must survive the vehicle’s ambient range while keeping the switch inside its specified junction temperature, because excessive temperature drift can translate into timing variation and reduce margins for TSN scheduling and timestamp accuracy.

On the layout side, my first focus is on the Ethernet pairs themselves. Differential pairs to the magnetics or direct-connect PHY interfaces need controlled impedance, tight pair matching and limited skew between pairs that carry related signals. Within reason, I keep critical TSN paths as short and symmetrical as the mechanical constraints allow, both to control signal integrity and to avoid unnecessary variation in link delay. Around the magnetics and common-mode chokes I reserve clean reference planes and avoid routing noisy digital signals that might couple into the Ethernet lines and raise my EMI or jitter.

I also pay attention to how the TSN switch sits relative to other high-speed blocks such as SerDes lanes, DDR interfaces and the ADAS SoC itself. I try to keep noisy DDR fly-by routing and large return-current loops away from the switch’s PLL and SerDes supply regions, and I avoid routing long, aggressive aggressor traces under or immediately adjacent to the most sensitive clock and reference pins. If the board density forces me to share layers, I rely on solid reference planes and careful layer stack-up to keep coupling under control. The goal is not perfection, but a layout where TSN timing and jitter are dominated by the Ethernet and optics, not by self-inflicted board noise.

Finally, I include a few EMC and transient notes in my selection criteria. When the ADAS domain powers up or transitions between modes, the TSN switch can draw significant inrush current as its internal logic and SerDes blocks start. I want to know whether the device has any built-in soft-start behaviour, whether it expects a particular sequence between its rails and how it reacts to short supply dips or line transients. Those points feed back into my PMIC and protection device design and help me avoid scenarios where a harmless transient becomes a domain-wide reset or a long recovery event. By capturing these power, thermal and layout notes alongside the functional requirements, I make it much more likely that the TSN switch I select will behave as intended in a real ADAS vehicle, not just on a lab bench.

IC selection mapping

By the time I reach the IC selection step, I already have a clear picture of what my Automotive Ethernet TSN switch has to do in the ADAS domain: how many cameras and radars it aggregates, which flows need deterministic latency, what redundancy I expect and how tight my power and thermal budgets are. At this point I stop thinking about a single “perfect” device and instead build a small family of acceptable IC series types. That way I can map different vendor product trees into the same set of expectations without locking myself into one brand too early.

The first axis in that mapping is port count. A small camera-only leaf switch for a limited L2 feature set does not need the same number of ports as a full ADAS domain switch that aggregates multiple forward and surround cameras plus radar and LiDAR. I roughly separate devices into classes such as low-port-count switches for three to five sensors, mid-range parts for mixed camera and radar clusters and high-port-count devices for domain aggregation with dual uplinks. When I write this into my spreadsheet, I do not write arbitrary numbers; I tie each port count range to a clear role in the vehicle so the mapping stays meaningful.

Maximum line rate is the next axis. Some IC families are optimised for 100 Mbit/s only, which might still work for legacy radar or small control domains but will not carry modern high-resolution video. Others are pure 1 Gbit/s devices that handle new camera and LiDAR ECUs but offer no simple way to connect older 100 Mbit/s nodes. In many ADAS designs I need a mixed portfolio: some ports at 100 Mbit/s for legacy devices, others at 1 Gbit/s for newer sensors, and at least one uplink that can run at a higher rate such as 2.5 Gbit/s when I aggregate multiple streams. I capture all of this as a port-mix profile for each IC family rather than just writing “1G capable.”

TSN feature completeness is where the series begin to separate. For simple ADAS functions with modest traffic, a basic TSN implementation with prioritised queues and coarse shaping might be enough. For more demanding L2 and L2+ systems I start to require time-aware scheduling, per-class shaping and tighter control over how control, sensor and logging traffic share the fabric. At the top end, for dense sensor domains and more ambitious automation levels, I look for devices with deep per-stream policing, frame preemption support and rich hardware hooks for time sync and timestamping. In my own mapping I label these as “basic,” “medium” and “full” TSN feature levels so I can group vendor series into the right buckets.

Safety and diagnostics depth is another selection dimension that does not show up in a simple port-count filter. Some switch families provide only basic per-port error counters and simple link up/down information. That may be enough for a small, non-safety-critical subsystem, but it is not sufficient for a central ADAS domain where I want to monitor link health, detect flapping ports, distinguish between symbol errors and CRC errors and enforce storm control policies. Other families offer deeper diagnostics, better logging granularity and clearer hooks to feed events into an ADAS domain controller and logger. I capture that difference as a “diagnostic depth” level in my mapping so I know which series are suitable for which roles.

Packaging, temperature range and qualification form the last group of technical axes. I note whether a given IC family offers multiple packages with different sizes or ball maps, which ambient and junction temperature ranges are officially supported and what AEC-Q100 grade the devices target. I prefer series that offer several package and temperature variants while keeping the same fundamental architecture and programming model, because that allows me to reuse software and a large part of the validation work across platforms. In the spreadsheet these become simple columns, but they carry a lot of weight when I think about long-term platform planning.

To keep all of this organised, I build an IC selection matrix that does not mention any vendor names. Each row represents an abstract IC family type that I am willing to use in my ADAS networks and each column captures one dimension of capability. Later, when I evaluate specific vendor products, I map them into one or more of these abstract rows. That way the technical discussion with the rest of the team can stay vendor-neutral, and we only bring brand choices into the conversation when we already know which class of device we are looking for.

A simple version of that matrix can be captured in an Excel sheet with fields like the ones below. I use English field names so they can be copied directly into tools or shared with suppliers:

• IC_family_alias – my internal name for this abstract series type.
• Role_in_ADAS_domain – camera leaf switch, radar cluster switch, full ADAS domain switch, and so on.
• Total_port_count – total Ethernet ports on the device.
• Downlink_100M_ports, Downlink_1G_ports, Uplink_1G_ports, Uplink_multigig_ports.
• TSN_feature_level – Basic / Medium / Full, based on scheduling, shaping and policing depth.
• Supports_time_aware_scheduling, Supports_per_stream_policing, Supports_frame_preemption – simple yes/no flags.
• Diag_depth_level – Basic / Deep / Safety_ready, reflecting how rich the counters and logs are.
• Per_port_error_counters, Link_flap_detection, Storm_control_loop_detection – availability of key health features.
• Event_logging_granularity – low, medium or high, depending on how detailed the events can be.
• Core_rails_count, IO_rails_count, SerDes_PLL_rails_count – for power tree planning.
• Typical_power_at_target_config – power estimate at my planned port mix and TSN usage.
• Package_type, Package_size_mm, Temp_range, AEC_Q100_grade.
• Target_ADAS_level_fit – which automation levels this family is comfortable with.
• Topology_fit – star, chain, ring, dual-switch or mixed topologies it suits best.
• Notes_for_this_project – free text where I record trade-offs or platform-specific comments.

When I keep this mapping vendor-neutral, I can revisit it across projects and reuse the same structure for new platforms. Later, on BOM and brand mapping pages, I simply link concrete IC series into these abstract categories so that procurement and design reviews can see both the technical fit and the sourcing options without having to rebuild the logic from scratch.

BOM & procurement notes

When I send out a request for quotation, I have learned that writing “Automotive TSN switch” as a single line item is not enough. Suppliers will quite reasonably respond with a wide range of devices, many of which are optimised for very different markets: simple industrial nodes, in-vehicle infotainment or small gateways that do not need the determinism and diagnostics depth of an ADAS domain. To avoid weeks of back-and-forth, I now treat the BOM and RFQ fields for the TSN switch as part of the design work, not as an afterthought.

The first group of fields I fill in describes the switching capability and TSN features I actually need. Instead of just quoting a generic bandwidth number, I specify the required switching capacity or aggregate bandwidth in terms of “non-blocking support for N one-gigabit sensor ports plus M additional 100 Mbit/s ports and at least one high-speed uplink.” I also state which TSN feature set I expect. If the project requires time aware scheduling, per-class shaping and per-stream policing to keep camera, radar, control and logging traffic under control, I say so explicitly. That way the supplier knows that a very basic TSN implementation will not be sufficient.

The next group of fields captures the port mix and speed. Here I list how many downlink ports I need at 100 Mbit/s, how many at 1 Gbit/s and what kind of uplinks I expect, including whether I prefer multi-gig uplinks for aggregation. I also state what redundancy mechanisms I need: dual uplinks to the ADAS domain controller or gateway, dual-switch architectures for critical sensors, and any failover behaviour that must be supported within a bounded time. That information turns vague requirements like “redundancy needed” into actionable design constraints suppliers can respond to.

Diagnostics and health monitoring need their own line in the RFQ as well. I explicitly ask whether the device provides per-port error counters, link flap detection, storm control and loop detection, and how these statistics and events are exposed to the host. If I want to integrate the TSN switch into a health monitoring and logging framework for the ADAS domain, I explain that I need more than a simple “link up/down” view. I want enough detail to distinguish marginal harnesses from faulty ECUs and to correlate field failures with network conditions.

Functional safety expectations also need to be captured, even if the switch is not itself a safety element in the strictest sense. I describe the role the device plays in the overall safety architecture, such as carrying safety-related sensor traffic or providing redundant paths for critical camera feeds. I then outline the level of diagnostic coverage I need and whether I expect safety-oriented documentation or design features. The detailed safety decomposition belongs elsewhere, but this high-level statement in the BOM tells suppliers whether they are dealing with a safety-relevant network or a purely comfort-oriented subsystem.

I also include project and lifecycle fields that are important for procurement but easy to forget during early design. I state the target SOP year, the expected project lifetime and any second-source strategy I have in mind. If the platform is expected to run for a decade or more, or if I know I will need multiple sourcing options, I say so clearly. I include my preferred package types, temperature range and AEC-Q100 grade so that suppliers do not waste time proposing devices that cannot survive the environment or fit the board.

All of these points can be translated into structured fields in my BOM and RFQ templates. A typical TSN switch section might include items like:

• Switching_capacity / Aggregate_bandwidth – non-blocking requirement for the planned port mix.
• TSN_feature_set – time aware scheduling, shaping, policing and any other required TSN tools.
• Port_mix_and_speed – counts of 100 Mbit/s and 1 Gbit/s downlinks and high-speed uplinks.
• Redundancy_requirements – dual uplinks, dual switches, expected failover behaviour.
• Diagnostics_requirements – per-port counters, link flap and storm detection, event export.
• Functional_safety_expectations – how safety-related the carried traffic is and what diagnostic depth is needed.
• Time_sync_dependency – whether the switch must support specific time sync roles or hardware timestamps.
• Power_and_thermal_constraints – power budget at the intended configuration and available cooling options.
• Temp_range / AEC_Q100_grade – environmental and qualification expectations.
• Target_SOP_year and Planned_lifetime – project timing and duration.
• Second_source_strategy – whether multiple compatible series are needed.

The most important lesson for me is to avoid hiding the determinism requirements behind four vague letters: “TSN switch.” In my BOM and RFQ I now describe which traffic classes I have—camera, radar, LiDAR, control, diagnostics, logging, OTA—and which of them must be delivered with deterministic latency and bandwidth guarantees. That single change makes it much easier for suppliers to propose appropriate devices and for my own team to judge whether a suggested IC truly fits the ADAS domain we are building, rather than merely matching a generic buzzword.

FAQs — Automotive Ethernet TSN switch/router

When I plan an Automotive Ethernet TSN switch for an ADAS domain, I keep coming back to the same practical questions. I use this FAQ as a checklist when I decide whether I really need TSN, size links and uplinks, plan redundancy and health monitoring, and talk with suppliers about concrete IC options for my network.