A deep dive article about AI workflows in vehicles by aicas CEO & CTO Dr. James J. Hunt was published by Hanser Automotive. The original german article can be found at Hanser Automotive.
Please find an english translation below.
From Prototype to Production: AI Workflows in Vehicles
By Dr. James J. Hunt
An AI model that reliably recognizes objects or classifies road conditions in a lab is not yet a vehicle system ready for serial production. The viability of a method can only be proven under real conditions. A structured AI DevOps approach at the edge can help bridge this gap.
With the increasing use of data-driven functions, AI is becoming an ever-greater part of vehicles. There, AI models are faced with limited computing and memory resources, heterogeneous hardware, fluctuating connectivity, and strict requirements for realtime performance, robustness, and functional safety. OEMs and Tier 1 suppliers are therefore not looking for yet another AI prototype, but rather a robust engineering process that allows models to be operated, monitored, and further developed in vehicles under controlled conditions. The development of machine learning models for driver assistance, condition monitoring, or data-driven vehicle functions is already very advanced. High levels of accuracy are achieved in preproduction environments, but in the field, operating conditions are constantly changing. Lighting conditions, weather, road surfaces, sensor quality, and usage patterns deviate from the assumptions made during training (image 1). This also changes the behavior of the models. In the context of “Physical AI”—systems that perceive, decide, and react in the physical world—this deviation has a direct impact on the quality of the vehicle function. The critical gap therefore lies between model development, runtime environment, and system operation.
Selective Data Management in Vehicles
A major obstacle to robust AI in the automotive sector is the handling of field data. Modern vehicles generate enormous amounts of sensor and status data. Unfiltered transmission of this data to central systems would quickly cause problems with bandwidth, storage, and operating costs. Additionally, the majority of this data documents standard situations and provides only limited added value for retraining. For training, validation, and root-cause analysis, the data needed primarily consists of instances that reflect uncertainty, edge cases, or anomalous inference behavior. This is where selective data management comes into play. The data is filtered and contextualized at the edge and transmitted only when it is actually relevant for improving the model or analyzing system behavior. In practice, this approach significantly reduces the volume of data while simultaneously improving the quality of the training dataset. As a result, development teams receive less noise and more actionable signals from real-world operations.
The AI Workflow in Four Steps
The operative workflow can be divided into four steps. Step one, “Connect & Capture,” connects vehicles, edge devices, and fleets, precisely selects signals and makes them available as an operational data source. aicas EdgeSuite supports the connection of vehicles, edge devices, and fleets, as well as the targeted tapping into relevant data sources. In the automotive context, the focus is on CAN, LIN, and AUTOSAR signals that are selectively captured and made usable for the AI workflow. At this level, it is determined which signals feed into the AI loop, at what resolution they are captured, and under what trigger conditions a feedback channel to the development team is established. Next comes the “Train & Test” phase. Models are developed with existing toolchains and prepared for the target environment. This also involves adapting and optimizing models trained in the cloud for mobile use to the processor architectures and runtime environments used in the vehicle. Particularly in the automotive context, this step is closely linked to the hardware. Factors such as memory requirements, inference latency, hardware acceleration, and the characteristics of the target platform must be considered early on, as many model properties can only be realistically assessed on the target hardware. The integration of the NXP eIQ Auto SDK into the aicas EdgeSuite addresses precisely this interface. Models can be validated close to the hardware and tested in a controlled pre-production environment. “Deploy & Run” marks the transition into controlled operational use. Rolling out AI models to distributed vehicle systems is technically challenging and organizationally sensitive. Updates must be transmitted in encrypted and signed form. In addition, they must be checked for compatibility and be able to be installed reliably even with unstable connections. This is particularly relevant in software-defined vehicle architectures, as AI models are part of a larger software configuration. A production-ready workflow therefore includes versioning, auditability, hot-swap capability, controlled OTA (over-the-air) mechanisms, and a management layer that makes heterogeneous target systems manageable throughout the entire rollout. The fourth step, “Observe & Improve,” closes the control loop. Continuous inference monitoring reveals drift, anomalies, and performance drops. Real-world observations can trigger targeted data collection campaigns, for example, when a model’s confidence falls below defined thresholds. This data is fed back into training and validation in order to create a closed AI DevOps loop consisting of observation, data collection, retraining, and redeployment (image 2).
Embedded Constraints as a Technical Bottleneck
Vehicles are not homogeneous IT systems. For AI applications in the automotive context, Embedded Linux, QNX, and AUTOSAR Classic or OSEK-based real-time systems are particularly relevant at the operating system level. Depending on the application profile, different processor architectures are used on the hardware side, particularly ARM-based systems, x86 variants, and, increasingly, RISC-V. Vehicle-specific buses, drivers, and application layers are added to further shape the integration process. The operational constraints of embedded systems form another technical bottleneck: limited computing power, restrictive memory budgets, thermal management, energy consumption, and, in some cases, intermittent connectivity. These factors significantly determine how a model can be packaged, deployed, executed, and monitored on the target platform. For mobile use, models trained in the cloud must therefore be adapted to the processors and runtime environments used in the vehicle. Toolchains such as the NXP eIQ Auto SDK support this process. Aligning the model, processor architecture, runtime environment, communication path, and update mechanism is therefore crucial. A model that operates stably in the development infrastructure may exhibit different runtime behavior on the target platform. Validation and operation must therefore be tailored to the actual embedded topology, via direct connection or gateways with additional control and security functions. The choice of topology influences the extent to which control over updates, identities, certificates, and local device networks is possible during operation.
Practical Relevance: AI-Workflow With NXP
The collaboration between aicas and NXP demonstrates how development, deployment, live inference, and data collection can be integrated into one consistent workflow. Models prepared with the NXP eIQ Auto SDK and optimized for the target hardware can be deployed to automotive platforms such as the S32 series, monitored in the field, and further developed based on selected operational data. This shortens validation cycles for development teams and significantly improves feedback between data science, embedded development, and fleet operations.
Technical Benefits for OEMs and Tier 1 Suppliers
This approach offers OEMs and Tier 1 suppliers several advantages. Data volume is reduced through selective data collection. Deployment and update processes become more robust. At the same time, more cost-effective and modular update strategies can be implemented instead of full FOTA updates. This requires signed software packages and a memory-safe runtime environment to ensure that only correctly signed software is executed on the vehicle. Validation on target hardware becomes more meaningful. At the same time, a continuous improvement process emerges based on real field data. The agent running on the vehicle can also be deployed independently of the operating system and hardware, which facilitates integration into heterogeneous platform landscapes. AI DevOps at the edge thus becomes an operational prerequisite for software-defined vehicles, in which AI functions must be stably operated, controlled, secured, and further developed over long lifecycles.