What to Ask a Gateway Vendor Before One Chip Takes Half the Car Down

Ask the vendor what the vehicle network does in the 50 ms after the gateway's application SoC stops responding. How they answer will tell you more than the datasheet does. A zonal gateway concentrates routing, security termination, diagnostics and OTA staging in one enclosure, so how it fails sets how half the vehicle fails. With little lab time available, rank the shortlist by the risks each question uncovers, not by the length of the feature list.

Redundant against what, exactly

Most shortlisted gateways pair a high-performance SoC with a lockstep safety MCU and call the result redundant. The question that matters is whether the two share a power rail, a PMIC, a clock source or a reset line. If they do, the redundancy collapses into a single common-cause failure, because a brown-out on that rail silences both at once. Ask for the dependent failure analysis done under functional safety standards such as ISO 26262, and ask which coupling factors were judged acceptable and why. A vendor who answers with the ASIL rating of the silicon instead of the gateway architecture has told you that nobody did the decomposition at system level.

The failure that looks healthy

The most dangerous failure is not a dead gateway but a half-alive one. The routing task freezes or the Ethernet switch locks up, while the CAN controllers keep sending the last buffered frames. Downstream ECUs then receive stale values that look valid. Whether anyone notices depends on one architectural choice: whether end-to-end protection passes through the gateway untouched or is terminated and regenerated inside it. If the gateway rewrites alive counters and CRCs itself, it hides its own staleness, so ask who detects a frozen pipeline. Also ask whether the windowed watchdog on the safety MCU checks that frames are actually moving through routing, not just that a heartbeat thread is still running.

The shortlist rule

If the vendor cannot show you fault injection on the shared supply and on the switch, with the switchover time measured against your 50 ms deadline on their own bench and the raw timestamps handed over, treat the redundancy as absent, whatever the safety manual claims.

What degraded mode actually keeps

Find out exactly which routing table the safety MCU holds once the SoC is gone, and which CAN or Ethernet paths it can still forward without the main software stack. Ask whether A/B partitions can roll back when the update agent itself is the part that crashed, and whether the HSM keeps freshness counters for secure onboard communication across an SoC reset, so the vehicle doesn't reject its own messages on restart. Every function added to the fallback means more code on the safety island, more to qualify and more to keep in sync with the main image. Every function left out is one the driver loses. Before the vendor meeting, decide which functions you are willing to lose, and put that list in the request for quotation. A vendor can only design a degraded mode against a list that exists.

How can I check these claims with almost no lab access?

Ask for the dependent failure analysis, the raw fault-injection logs with timestamps, and the configuration used on the vendor's bench. Then replay the single most worrying scenario, usually the shared-supply brown-out, on a borrowed evaluation board.

Back to AutomotiveGateway · Domains

← Back to AutomotiveGateway
Engineering & Architecture Brief

What to Ask a Gateway Vendor Before One Chip Takes Half the Car Down

Ask the vendor what the vehicle network does in the 50 ms after the gateway's application SoC stops responding. How they answer will tell you more than the datasheet does. A zonal gateway concentrates routing, security termination, diagnostics and OTA staging in one enclosure, so how it fails sets how half the vehicle fails. With little lab time available, rank the shortlist by the risks each question uncovers, not by the length of the feature list.

Redundant against what, exactly

Most shortlisted gateways pair a high-performance SoC with a lockstep safety MCU and call the result redundant. The question that matters is whether the two share a power rail, a PMIC, a clock source or a reset line. If they do, the redundancy collapses into a single common-cause failure, because a brown-out on that rail silences both at once. Ask for the dependent failure analysis done under functional safety standards such as ISO 26262, and ask which coupling factors were judged acceptable and why. A vendor who answers with the ASIL rating of the silicon instead of the gateway architecture has told you that nobody did the decomposition at system level.

The failure that looks healthy

The most dangerous failure is not a dead gateway but a half-alive one. The routing task freezes or the Ethernet switch locks up, while the CAN controllers keep sending the last buffered frames. Downstream ECUs then receive stale values that look valid. Whether anyone notices depends on one architectural choice: whether end-to-end protection passes through the gateway untouched or is terminated and regenerated inside it. If the gateway rewrites alive counters and CRCs itself, it hides its own staleness, so ask who detects a frozen pipeline. Also ask whether the windowed watchdog on the safety MCU checks that frames are actually moving through routing, not just that a heartbeat thread is still running.

The shortlist rule

If the vendor cannot show you fault injection on the shared supply and on the switch, with the switchover time measured against your 50 ms deadline on their own bench and the raw timestamps handed over, treat the redundancy as absent, whatever the safety manual claims.

What degraded mode actually keeps

Find out exactly which routing table the safety MCU holds once the SoC is gone, and which CAN or Ethernet paths it can still forward without the main software stack. Ask whether A/B partitions can roll back when the update agent itself is the part that crashed, and whether the HSM keeps freshness counters for secure onboard communication across an SoC reset, so the vehicle doesn't reject its own messages on restart. Every function added to the fallback means more code on the safety island, more to qualify and more to keep in sync with the main image. Every function left out is one the driver loses. Before the vendor meeting, decide which functions you are willing to lose, and put that list in the request for quotation. A vendor can only design a degraded mode against a list that exists.

Technical FAQ: How can I check these claims with almost no lab access?

Ask for the dependent failure analysis, the raw fault-injection logs with timestamps, and the configuration used on the vendor's bench. Then replay the single most worrying scenario, usually the shared-supply brown-out, on a borrowed evaluation board.

Related Architecture Specifications (AUTOMOTIVEGATEWAY): gatewaycan.com · automotivecompute.com · vehiclegateway.com

More Technical Articles on automotivegateway.com

Why Technical Domains Decide Authority in the AI Era →CAN Gateway Filtering, Routing and Diagnostics →Software-Defined Vehicle Reference Stack →ISAC and V2X Convergence for Cooperative Mobility →Centralized E/E Architecture: Consolidating the Vehicle →Zonal Architecture: Wiring, Power and the Ethernet Backbone →Automotive High-Performance Computing (HPC) →Automotive Ethernet and TSN: The Deterministic In-Vehicle Backbone →