Flat Fabric, Dumb Sensors: Ultra Ethernet's SDV Shift

For decades, every sensor in a vehicle has needed its own brain. Ultra Ethernet ends that requirement. In my last piece, I argued that Ultra Ethernet is a far more optimal networking layer for the Software-Defined Vehicle (SDV) than TSN, pointing to bandwidth, congestion management, and the shift from managed scarcity to abundant capacity. There is a deeper implication I want to take up here. Ultra Ethernet does not just move more data faster. Its flat, fabric-style topology changes where intelligence needs to sit in the vehicle, and that change lets architects rethink the sensor layer itself.

The Sensor Tax Has Been Normalized

For decades, the industry has operated on an unspoken assumption that every sensor needs a processor at the edge. A camera needs an ISP. A lidar needs a pre-processor. A radar needs a DSP. These smart sensors were not a choice. They were a necessity born from the fact that the network between edge and core could not carry raw data at the scale modern algorithms demand.

TSN Ethernet reinforced this model. With 1 Gbps links and statically scheduled traffic, the only way to make the math work was to pre-process, compress, and filter the data at the sensor. The camera sends a reduced stream, metadata, or object list, not raw pixels. The lidar runs first-pass segmentation locally. The radar extracts tracks and sends a sparse list.

This is the sensor tax. Every smart sensor adds cost, power, heat, and failure modes at the edge. It also locks the vehicle into a specific processing pipeline. The algorithm on that camera ISP is typically baked in by the supplier. If the OEM wants to change the perception stack, the conversation starts with a hardware redesign, not a software update.

What a Flat Fabric Actually Means

Ultra Ethernet is not a faster bus with a more capable scheduler. It is a fabric. In a data center, that means any endpoint can reach any other with predictable latency, and the network handles congestion rather than pushing that problem to the application layer.

With Ultra Ethernet, the network between a camera and the central compute cluster is no longer a narrow pipe that needs rationing. It is a wide, adaptive fabric that carries raw sensor data from dozens of endpoints simultaneously without collapsing. Packet spraying, end-to-end flow control, and congestion signaling mean the network behaves like a shared resource rather than a collection of point-to-point contracts.

That changes the design equation. If the network can carry raw data, the sensor does not need to be smart. It can be a photodiode array with a serializer, a lidar receiver that just ships point clouds, or a radar frontend streaming raw ADC samples. The intelligence moves from the edge to the core, where it belongs in a compute-centric architecture.

The Economics Are Not Subtle

While the average selling price of today’s vehicle is well in the range of tenss to hundreds  of thousands of dollars, the cost of every single component, be it wiring, semiconductors, or sensors, is scrutinized down to the last cent. A smart camera module with integrated ISP can cost three to five times what a raw imager with a serializer costs. Multiply that across a dozen cameras, several lidar units, and radar modules, and the savings are platform-level economics.

But the real savings are not just BOM. They are in the flexibility that comes from decoupling the sensor from the algorithm. If the perception stack runs on a centralized AI computing cluster, the OEM can update it over the air, swap in a new neural network, change fusion weights, or experiment with different sensor combinations without redesigning hardware at the edge.

This is what software-defined actually looks like. Not just over-the-air (OTA) updates to the infotainment system, but the ability to retrain the entire perception pipeline because the raw data is available in the core, not locked behind a pre-processing layer defined years ago by a Tier 1 supplier.

The Safety Argument

There is a reflexive objection which is that smart sensors are safer because they reduce dependency on the network. If the link goes down, the edge processor still functions. That is true, but it is a design choice, not a law of physics.

A flat Ultra Ethernet fabric can logically be designed with redundancy. Multiple paths, adaptive routing, and congestion-aware forwarding mean the network is more resilient than a static TSN topology where a single link failure breaks a deterministic schedule. The question is not whether you trust the network. It is whether you trust a network designed for the 1990s or one designed for the 2020s.

Moreover, the safety argument cuts both ways. A smart sensor with local processing is a single point of failure with its own software stack, thermal profile, and supply chain. A dumb sensor with a serializer is simpler, with fewer failure modes. The complexity moves to the core, where it can be monitored, redundant, and updated.  As an aside, it also simplifies the challenges associated with managing security.

The Supplier Dynamic

This shift will disrupt the supply chain. Tier 1 suppliers have built business models around smart sensors. The camera module with integrated ISP and object detection is a product line, not just a component. Moving to raw sensors changes the value proposition.

But OEMs are already moving in this direction. They want to own the algorithm stack. They want to train their own models. They want the flexibility to source raw imagers from one supplier and run perception on silicon from another. The flat fabric that Ultra Ethernet enables is the technical foundation for that business model.

The suppliers who adapt will ship high-quality raw sensors with robust serialization and minimal local processing. The ones who cling to the smart sensor model will find themselves competing in a shrinking market as the compute-centric architecture becomes the default.

What This Means for 2028 and Beyond

The 2028 to 2029 platforms I referenced in my last piece are already making these decisions. The teams designing those architectures are not asking whether Ultra Ethernet can carry raw camera data. They are asking how many dumb sensors they can hang off a single fabric segment before adding a switch.

The answer, based on the bandwidth math, is a lot more than TSN ever allowed. A single 100 Gbps Ultra Ethernet segment can carry the raw output from dozens of 8MP cameras at 30fps, handle multiple lidar point clouds, and stream raw radar data from every corner of the vehicle simultaneously. The fabric scales with the sensor count, rather than forcing a hard trade-off between resolution and edge intelligence.

The Bottom Line

The shift to Ultra Ethernet is not just about faster links. It is about a fundamentally different network topology that enables a fundamentally different sensor architecture. When the network is a flat, adaptive fabric rather than a collection of scheduled pipes, the edge does not need to be smart. The intelligence can live where it is most useful: in the centralized compute cluster, where it can be updated, retrained, and redeployed without touching a single sensor module.

TSN forced us to pre-process at the edge because the network could not handle the load. Ultra Ethernet removes that constraint. The question for architects is no longer how to make the sensor smarter. It is how to make the sensor as simple as possible while letting the fabric do what it was designed to do: move data, in bulk, with predictability, from anywhere to anywhere.

The vehicles that win in the next decade will be the ones whose sensor layers are lean, whose compute is centralized, and whose network fabrics do not artificially force intelligence to the edge just because the pipe was too narrow.  The adoption of Ultra Ethernet in SDVs will be essential in enabling this shift.