Intelligent vehicle systems are the combination of onboard computing, connectivity and software that lets a vehicle process data and act on it in real time, rather than logging it for analysis after the fact. The distinction matters commercially, because the second model produces reports and the first produces services drivers will pay for.
For an OEM planning its next SDV programme, the question is rarely whether to add intelligence. It is where that intelligence runs, who maintains it after the start of production, and what it costs to operate in every market the vehicle ships into.
Core components of intelligent vehicle systems
Three areas carry the design weight: the models themselves, where data gets processed, and what the driver encounters at the point of use.
AI and machine learning integration
AI and ML workloads split across two locations. Training happens in the cloud, where compute is cheap and datasets are large. Inference happens in the vehicle, where a decision about a lane change or a cabin setting cannot wait for a round trip to a data centre.
The harder work starts after launch. Models degrade as roads, driver behaviour and traffic patterns drift away from the data they were trained on. Keeping them current requires a working OTA update path with version control, staged rollout and rollback, which is the same machinery type approval already demands. Model refreshes belong inside the OTA process from day one.
The scale of that maintenance job is easy to underestimate. Cubic3 connects 30 million vehicles, and every one of those vehicles sits somewhere on a model version, a firmware version and a market-specific configuration.
Data processing at the edge
A modern vehicle produces far more telemetry than is worth transmitting. Sending all of it over a cellular link, in every market, across a ten-year vehicle life, becomes a cost line that scales with the size of the parc.
Edge processing changes that arithmetic. Filtering, aggregating and scoring data inside the vehicle means the network carries conclusions instead of raw signal. A predictive maintenance function needs a fault probability and the supporting data window, not a continuous stream of sensor values. Latency-sensitive functions such as driver monitoring gain twice over, because local inference removes the round trip.
Coverage governs the traffic that does leave the vehicle. Our global connectivity platform unifies 550+ networks across 200+ countries, which is what allows one edge-to-cloud design to behave the same way in Ireland, Germany and Japan without a per-market rebuild.
User-centric design
Most in-vehicle intelligence fails at the handover rather than in the lab. If a service requires the driver to create an account, enter payment details and choose a data plan while sitting in a dealership, adoption drops before the first journey ends. Activation has to happen in the background, with the connectivity profile provisioned over the air and the driver asked only for consent.
Consent is its own design problem. Drivers accept data collection when the exchange is legible to them, so the interface needs to state what is collected, what it enables and how to switch it off. Our in-vehicle service activation platform was built around that principle.
Integration challenges and scalability limits
Intelligence is straightforward to demonstrate on a prototype and difficult to homologate across a model line. The recurring blockers are structural:
- Legacy domain and ECU architectures never designed to expose data to a central compute node
- Supplier fragmentation, where three tier-one vendors each own part of the data path and none owns the outcome
- Cybersecurity type approval under UN Regulation No. 155, which requires a certified CSMS covering the full lifecycle including the supply chain
- Market-by-market connectivity terms, including permanent roaming restrictions that quietly invalidate a single-profile strategy
Why pilots do not predict production
A connected services pilot on 500 cars in one country reveals very little about what happens across millions of vehicles in dozens of markets. Three things break at scale.
Connectivity provisioning is the first. Physical SIM logistics collapse under global volume, which is why eSIM and remote profile management, now standardised under GSMA SGP.32, became the default for programmes shipping across borders.
Data volume is the second, which returns the programme to edge filtering as a commercial decision rather than a technical preference.
Regulatory variation is the third, and it is the one OEMs can underestimate. CARIAD, Volkswagen Group’s software division, has to orchestrate connected services across Audi, SEAT and ŠKODA simultaneously, and every market it enters applies its own legal, tax and security requirements. Cubic3 carries that layer on CARIAD’s behalf, acting as a single aggregator across mobile network operators so compliance is managed centrally rather than negotiated brand by brand and country by country. Michael Wintergerst, CARIAD’s Head of Vehicle and Cloud Platform, places the strategic weight on the same layer: “Connectivity plays a major role in the software-defined vehicle’s architecture.” The same pattern holds at ŠKODA, where data traffic classification and end-to-end compliance let the brand expand its global footprint without building a compliance function in-house. You can read more about that work on our automotive solutions page.
What changes over the next programme cycle
Zonal architectures remove the constraint that has held back most in-vehicle intelligence, consolidating compute into a small number of high-capability nodes instead of spreading it across dozens of ECUs. That consolidation makes model updates and new services deployable without touching hardware.
Non-terrestrial networks extend the same design into places terrestrial coverage does not reach. Our research team is working with SoftBank Corp on satellite integration for exactly that gap, which matters more for logistics corridors, mining sites and agricultural fleets than for urban passenger cars.
The commercial shift is the substantive one. Once a vehicle can process, act and transact, connectivity starts carrying revenue. FleetWallet3 now reaches more than 5,300 fuel retailers across 12 European countries through the CarPay-Diem partnership, following deployment with GoCar Ireland, and cuts fuel costs by over 10% through fraud prevention and automated reconciliation. On the passenger side, vehicle analytics tell an OEM which features are worth funding in the next programme.
Intelligent vehicle systems: your questions answered
What are intelligent vehicle systems?
They are the combination of onboard compute, sensors, connectivity and software that allows a vehicle to process data and act on it while driving, rather than uploading it for later analysis. Typical functions include predictive maintenance, driver monitoring, adaptive cabin settings and in-vehicle payments.
Should processing happen in the vehicle or in the cloud?
Both, split by function. Model training belongs in the cloud, where compute is cheap and datasets are large. Inference belongs in the vehicle for anything latency-sensitive or high-volume, because sending raw sensor data over cellular for the life of the vehicle costs more than processing it locally.
What does UN R155 require?
UN Regulation No. 155 requires vehicle manufacturers to operate a certified Cyber Security Management System covering the full vehicle lifecycle, including supplier and third-party software. It has applied to new vehicle types in UNECE markets since July 2022 and to all new vehicles since July 2024.
How do OEMs scale these systems across markets?
Through a single global connectivity architecture rather than per-market builds. That means eSIM with remote profile management for provisioning, multi-network coverage that handles roaming restrictions, and a compliance layer that adapts to local legal, tax and security requirements without changing the vehicle configuration.
Plan your next programme with connectivity built in
See how Cubic3 gets intelligent services into vehicles at the point of delivery: activate connected services before the driver leaves the forecourt.
