MLOps in Software-Defined Vehicles: A Centralized Platform Approach

Software-Defined Vehicles

Software-defined vehicles (SDVs) refer to a new paradigm in automotive design in which vehicle functionality and features are primarily defined and controlled by software rather than traditional hardware components.

In SDVs, software updates can dynamically change and enhance vehicle capabilities, leading to a more flexible and adaptable automotive ecosystem.

MLOPs in Software-Defined Vehicles

MLOps (Machine Learning Operations) encompasses the practices, tools, and methodologies designed to simplify and automate the management and deployment of machine learning models throughout their lifecycle in production settings.

Relevance to SDVs

SDVs rely heavily on ML models to perform critical functions such as autonomous driving, predictive maintenance, user personalization, and more.

The efficient management of these models is not just important, but crucial, to maintain vehicle performance, safety, and reliability in SDVs.

MLOPs Platform, Different Approaches, and How?

We will look at the scope of the ML platform, the approaches to building one, and how to build one using one of the approaches discussed.

MLOPs Platform

A holistic software platform that increases productivity and scalability of shipping, monitoring, and managing the lifecycle of ML models that facilitate the features within SDVs.

Centralized vs. Decentralized

The MLOPs platform can be centralized, managing all of the ML models that help facilitate the features in one central place.

It can also be segregated and built by individual feature teams, with a reduced scope of managing only the models pertinent to the feature.

We will delve deep into a centralized ML Platform for managing ML models and what it takes to build one.

What It Takes To Build a Wholistic ML Platform for SDVs

We would need to consider the following components to build a centralized ML Platform that efficiently manages the ML models that help features within SDVs.

Data Engineering

Organizations tend to build teams at the enterprise level to help manage data needs for training and developing ML models.

The ML platform should have well-equipped utilities to track the Data Lineage required for training the ML models, such as Data ingested, Data transformed, and the Final datasets used to train the current model. A well-tracked data lineage can help the feature teams using the platform gain insights into the data points considered for training the model and thus improve the model to help the feature efficiently.

The usual way to go is an API-first approach to integrate the enterprise-level data management teams into the platform.

Model Development

Although the platform does not have any control over how the model is developed, as it would be the feature teams who will orchestrate that aspect, it is in the best interest of the platform to provide a standardized approach/template to the feature teams to gather the following notebook source tracking, training set ids, validation set ids, testing set ids, preprocessing ids, post-processing ids, model ids and resulting model versions as part of the experimentation, device type and id the model was created for.

The Platform can also standardize the artifacts needed when the model is being developed to be utilized later during model deployment.

Gathering all the above information from a model development standpoint tremendously comes in handy in the model management/monitoring phase.

Model Validation/Governance

Once the model is developed and tested and ready for deployment to the vehicle, the MLOPs platform should provide an interface to validate it before it is released via the frameworks/utilities required for deployment. 

A proper approval workflow-based governance model is essential for vetting the model before it can be deployed to the vehicle.

It is very advantageous for the ML platform if the model goes through a governance process before it is deemed ready for deployment. It also establishes a standard for processing models within the organization.

Model Deploy

This is the meat of the platform; this is where the rubber meets the road. All the above steps build and set the platform to be in an extraordinary position to handle models with ease. 

The standardization techniques employed in the previous steps will level-set all the models and help reduce variability while developing services to ingest the models into the platform and deploy them to the vehicles using various utilities and frameworks to deploy software.

The platform should be able to ingest, track, and manage models uploaded for deployment and easily integrate with Vehicle deployment utilities and frameworks. Again, the API-first approach is the go-to method in this case.

Model OPs

Once the models are uploaded for deployment, several things can apply when performing operations on them.

If partial uploads make the platform unable to handle the model, the platform should be able to detect them and handle them accordingly.

If the model is uploaded and fails the validation/governance process, the platform should be able to handle this.

The model is uploaded and ready to be deployed. In this case, the platform should be able to assess the software needed for the model to function in the vehicle and make decisions accordingly based on software readiness, version compatibility, and other such factors.

If a model passes all the above criteria and is deployed, the platform should be able to move it to a processed model feature to gather more insights from the deployment and future operations on the model.

Model Monitoring

Extra emphasis should be given to model monitoring when ML models are deployed to vehicles, as it is very important for them to function accordingly.

The platform should develop utilities that help compute the data/concept drift of each model deployed using the ML platform. The drift can be calculated by developing a framework that uses aggregated vehicle reports and compares them against the threshold scores associated with the model on a periodic basis.

Notifications are sent to model/feature owners if the threshold criteria are unmet.

Retraining/Rollback/Misc Functions

Model OPs and monitoring help provide dashboards and views to the feature teams so that they can make decisions on Model retraining, Model Rollback, and several other functions related to operating the models within the vehicles.

The platform should be able to handle the various scenarios that can occur for example, maintaining the number of versions in the platform to be able to easily fetch the appropriate version if needed, Rolling back to a previously performing model version if the newly deployed version presents with an unexpected loss in performance, shadow deploy a newer version for critical features, Canary deploy a model to a pre-defined subset of vehicles rather than a complete fleet.

Benefits of the Centralized MLOPs Platform for SDVs

As you can see from the above-mentioned approach, the MLOPs platform helps accelerate the time to value by standardizing the MLOPs functions needed to deploy models to vehicle software, thus improving overall efficiency. 

Below is a rundown of the benefits of this approach

• Helps build reusable workflows/pipelines
• Drives consistency and productivity across feature/product teams
• Provides a central spot for all ML-related functions/operations with respect to ML models.
• Lowers the vehicle integration barriers and the required expertise.

There are many other advantages to building a cutting-edge ML Platform for managing ML models related to Software-defined Vehicles.

This article helps kickstart the thought process around SDVs and how model management is pivotal for their success.