A shared in-vehicle runtime can manage which models remain active and which run only when operating conditions require them
Commercial vehicles face a resource problem as their AI capabilities expand: running every model continuously adds demands on finite compute and memory, making new functions harder to integrate, validate, and operate. The architectural challenge is how to support more intelligence within the resources available on the vehicle.
Each additional model can require CPU or accelerator capacity, memory, integration work, and validation. Yet a model needed during a diagnostic event or service workflow may have little reason to run throughout every trip. Keeping that model active even when its function is not required consumes execution resources unnecessarily.
For manufacturers, this creates a design challenge that extends well beyond initial production. Commercial vehicles operate over long lifecycles, and FleetOwner reported that “Fleets haven’t operated equipment this old in over a decade.” The compute and memory installed at build remain largely fixed, yet expectations for the software and AI running on them keep growing. Engineering teams must determine how new workloads fit alongside existing functions and how they will be deployed, updated, and monitored across a fleet.
For operators and service teams, the same constraints show up in the data. Storage, bandwidth, and connectivity limit how much telemetry can move to the cloud, and collecting large volumes of data leaves teams searching for the events and signals that matter for diagnosis. The tradeoff is hard to avoid: send everything to the cloud and absorb the cost and noise, or send less and risk missing the key event.
Both problems point to the same answer: move intelligence to the vehicle, and manage it as shared vehicle infrastructure rather than a set of separate, always-on models. A common runtime can manage a portfolio of models, allocating execution resources according to the requirements of each function.
Separate deployment from execution
The key idea is to decouple “deployed” from “running.” Keeping a model available on the vehicle and executing that model are separate decisions. Deployed models still occupy storage, but their execution can be managed according to operational needs.
This distinction allows two categories of edge intelligence to coexist. Persistent intelligence includes models that must remain active to support continuous or safety-critical functions. An example of persistent intelligence would be an ADAS road-object detection model that processes camera feeds while driving to identify vehicles, pedestrians, and cyclists for collision avoidance.
On-demand intelligence includes models that activate only when vehicle context or operational conditions require them. An illustration of on-demand intelligence would be a battery health assessment model that activates during a charging or depot session to evaluate battery degradation and flag for maintenance. Supporting both on the same hardware means something has to decide what runs, when, and with which resources, without disrupting the functions that cannot be interrupted.
A shared in-vehicle runtime can make those decisions. It can manage deployment, activation, deactivation, model versions, access to vehicle signals, outputs, and monitoring, while allocating CPU, memory, and other resources according to what each function needs.
Those decisions must respect the requirements of each function, including validation and resource availability. On-demand execution does not remove integration or validation work; it provides a way to manage workloads that do not need to operate simultaneously.
Let vehicle context determine when models run
Vehicle signals, diagnostic events, operating mode, geography, service context, and other model outputs can provide inputs for activation. A vehicle condition creates a trigger, the platform activates a model, the model performs its task, and the platform deactivates it when the task is complete. The model consumes resources only while its function is needed.
Because an activated model competes with persistent functions for the same resources, making this practical requires visibility into CPU and RAM use, storage, model footprint, and concurrent models. Engineering and operations teams also need fleet-wide deployment visibility: what is installed, what is running, and whether available resources can support a requested workload.
A shared orchestration layer can manage a range of applications consistently, without requiring a separate architecture for each. These include remote diagnostics, edge log analysis, configuration monitoring, service or shop modes, model evaluation, and targeted engineering workflows, each with different execution needs.
Detect locally and collect selectively
Vehicle data collection illustrates what this architecture changes in practice. In a workflow centered on cloud analysis, teams collect data, upload it, search for anomalies, identify interesting events, extract relevant signals, and then diagnose the issue.
An edge-intelligent workflow changes that sequence: detect an anomaly locally, trigger targeted collection, upload relevant context, and diagnose. Decisions about which data matters can now move into the vehicle.
Sonatus’s Fastlane™ Edge Smart triggers feature is one concrete example. Smart Triggers connects an AI model running in the in-vehicle edge runtime with Fastlane™ Collector. A lightweight anomaly-detection model or math function at the edge can monitor engine behavior thresholds. When it detects an abnormal condition, it triggers a Fastlane Collector policy that captures relevant engine signals surrounding the event. Targeted data collection occurs only when an engine anomaly is detected.
This approach can produce more relevant diagnostic datasets and reduce unnecessary vehicle-to-cloud data movement and manual log searching. Whether it improves connectivity use, storage use, or investigation time depends on detection quality and the collection policy.
Ultimately, the broader architectural implication is that deployment, execution, resources, and lifecycle management need to be considered together. A vehicle can support a growing portfolio of AI capabilities without requiring every installed model to run continuously. Edge AI scales when intelligence becomes a managed vehicle capability.