Every connected feature raises the same question: does this computation happen in the vehicle or in a datacentre? The answer is usually forced by constraints rather than chosen, and knowing which constraint applies saves a lot of debate.
The four constraints that decide it#
Where things actually land#
| Function | Where | The deciding constraint |
|---|---|---|
| Braking, stability control | Vehicle (safety ECU) | Latency, availability, safety |
| Lane keeping, ADAS perception | Vehicle | Latency, data volume |
| Cluster rendering | Vehicle | Latency, availability |
| Voice wake word | Vehicle | Latency, privacy |
| Voice understanding | Usually cloud, with fallback | Compute cost |
| Turn-by-turn guidance | Vehicle, with cached maps | Availability |
| Route calculation with traffic | Cloud | Needs fleet-wide data |
| Charging-stop planning | Cloud, cached on vehicle | Needs live charger status |
| Media playback | Vehicle, streamed content | Availability of the UI |
| Fleet analytics | Cloud | Needs every vehicle |
| Fault detection | Vehicle detects, cloud correlates | Both — see below |
| Model training | Cloud | Compute cost |
| Model inference | Vehicle | Latency, data volume |
The hybrid patterns worth knowing#
Most real features are not purely one or the other. Four recurring shapes:
Detect locally, correlate centrally#
Compute centrally, cache locally#
Route options, charger locations, map tiles, media metadata. Computed where the data lives, cached on the vehicle so the feature survives a tunnel.
Cloud with a degraded local fallback#
Shadow mode#
Where teams get this wrong#
Gotcha
Assuming connectivity. The most common error by a wide margin, and it comes from developing on a desk with good Wi-Fi. Test in aeroplane mode, deliberately and routinely.
Sending raw data to decide in the cloud. Discussed in the previous topic — this is usually a volume problem disguised as an architecture preference.
No degraded mode. A feature that works only online is a feature that visibly fails in every car park.
Putting a latency-critical loop behind a network call. It will work in testing and fail in a tunnel, at the worst moment.
Ignoring cost. Cloud compute per vehicle per month, multiplied by a fleet over fifteen years, is a number the business needs to have seen before you build.
Forgetting the fifteen-year horizon. A cloud service the feature depends on must still exist in 2041, or the feature must degrade gracefully when it does not. Vehicles have outlived the services they were built against, repeatedly.
Practical questions for a design review#
Ask these five, in order, and the architecture usually settles itself:
- What is the latency budget? Under a second means on-vehicle.
- What happens with no network? If the answer is "it breaks", that is a requirement, not an accident.
- How much data must move? If the input is a video frame, the decision is made.
- Does it need data from other vehicles? If yes, part of it is in the cloud.
- What does this cost per vehicle per month, for fifteen years?
Next#
Who is accountable for all of this data — governance and privacy.