Snapdragon Ride Flex SoC: The central compute solution that’s bringing the SDV vision to reality

The automotive industry is going through a fundamental disruption with the rise of electric vehicles (EV), changes to the electrical/electronic (E/E) architecture, and explosion of software — all leading to a Software-Defined-Vehicle (SDV). Qualcomm Technologies recently announced the Snapdragon Ride Flex SoC, which is an ideal central-compute solution that supports the next-generation SDV solutions for OEMs and across the SDV ecosystem.

SDV is still a buzzword for many. The conversations around it address the many enabling technologies, like continuous integration and continuous deployment (CI/CD), Digital Twin, and mixed criticality, which are primarily a means to an end for achieving the SDV vision. Before going into the details of how the Flex SoC is an ideal compute solution for SDV solutions, here is broader context of SDV, the problems OEMs are looking to automotive platform providers like Qualcomm to solve, and the path to how the Flex SoC is becoming the harbinger to satisfying those requirements complementing Snapdragon Digital Chassis solutions.

Software-Defined-Vehicle: an overview

There is no standard industry-aligned definition of SDV, but one of the most widely accepted could be a vehicle wherein the features are enabled by agile delivery of software over the lifetime of the vehicle extending beyond point of sale. This could also be treated as SDV’s core product objective, as it allows OEMs to tap into new software services models while providing end users an always-improving user experience, as opposed to being a depreciating asset. The Total Available Market (TAM) of software-as-a-service in automotive as per an UBS report is being projected to be around $700 billion by 2030, and the incumbent and new OEMs are transforming themselves to technology companies going through fundamental digital transformation across the organization and their products to capture a piece of this TAM. There are many other parallel industries which have seen the software-defined transformation, from Software-Defined-Networking, Software-Defined-Storage, and Software-Defined-Compute in cloud domain to Software-Defined-Industrial Systems — and, now, Software-Defined-Vehicle (SDV).

Image 1 describes an abstract view of what a typical SDV stack looks like from a car-to-cloud perspective.

Starting in-cloud, to satisfy the requirement of software portability, scalability, increasing complexity, and decreasing developer productivity in automotive, the industry is adopting the mature cloud-native software development design paradigm from other industries like enterprise, as they have seen similar platform requirements in the past. The cloud-native software development could be characterized by microservice-based software development with containerized deployment and a robust supporting CI/CD pipeline, which when complemented by adoption of standards across various levels of the stack allows software to be decoupled from the type and location of hardware — thus satisfying one of the primary prerequisites for “software-defined” everything.

Although the automotive industry is looking at leveraging the cloud-native design paradigm, the former has some unique requirements, which the existing cloud-native infrastructure will need to be extended to support. The software that runs in the car has many constraints when compared to some of these other software-defined segments, considering the safety critical nature of the vehicle. There are software functions in the car that, depending on intended functionality, need to be developed and executed at certain safety and integrity levels, i.e., QM, ASIL-B, or ASIL-D.

With this context, the in-cloud development infrastructure needs to provide the ability to develop and deploy mixed critical workload using cloud-native design patterns on a digital twin of the actual vehicle aiming to provide high level of environmental parity from cloud to vehicle.

Complementing the in-cloud development infrastructure, the in-vehicle infrastructure would typically comprise of a powerful centralized computer capable of running a flexible mixed-critical workload. The in-vehicle E/E system architecture is going through an overhaul, wherein a typical vehicle that used to have hundreds of electronic control units (ECU) performing a fixed function is getting consolidated into domain architecture that comprises of few powerful ECUs, including running in-vehicle infotainment (IVI), advance driver assistance systems (ADAS)/automated driving (AD), and Domain Control functions, while moving to a zonal architecture with a powerful centralized compute solution. The centralized solution is capable of running IVI, ADAS/AD and other mixed critical workloads on a single compute platform connecting to multiple zonal gateways that terminate and transform the sensor/sensor data before sending it to the central compute for further processing.

This centralized compute will typically run platform software to support cloud native mixed critical workloads. The platform software, along with the firmware, hypervisor and OS support, would also be comprised of automotive cloud-native software components. On top of the platform software, automotive OEMs are enabling what the automotive ecosystem is now loosely calling, “Car OS”, that abstracts the vehicle data, sensors, and services. This provides the necessary components to connect the vehicle to the cloud, allowing a consistent south bound interface to write in-vehicle applications across the generations of the OEM vehicle.  

Cloud-Native Software in Automotive

Having looked at the generic version of the SDV stack, let’s look at the details of what it means to adopt cloud native software development for automotive, while deriving in-vehicle and in-cloud automotive infrastructure requirements expected from platform providers like Qualcomm for OEMs to enable such an infrastructure.

Let’s consider image 2, from a cloud-native automotive software developers’ perspective, and the type of development and deployment flow developers would expect.

The automotive software developers’ journey would start in the cloud, where the developer would build optimized machine learning (ML) model performing ML operations (MLOps) on the data ingested from the car or in-cloud simulation for various operational design domains (ODD). The outputted model then gets integrated into a functional stack that would typically comprise of a combination of software components that could be microservice or incumbent real-time operating system (RTOS) based or a combination of both. In case of the former, depending upon the application functionality to be achieved, a developer can build an application that would comprise of containerized microservices that may be mixed critical in nature requiring QM, ASIL-B or ASIL-D safety level. In case of the latter, the developer can build a monolithic RTOS image with the intended functionality and which has been the incumbent way of automotive software development. The microservices and monolithic application components can communicate with each other through a service-oriented middleware. The RTOS or microservices can host both Adaptative AutoSAR and ROS based infrastructure, while RTOS-based environment continues to support AutoSAR classic-based on specific application scenarios. 

To enable such a highly productive microservice and monolithic application development infrastructure, one of the key performance indicators that defines the efficiency of the DevOps infrastructure is the developer feedback. The developer feedback can be defined as the time it takes for a developer to get feedback if the feature developed works across the system. This is enabled by the underlying DevOps infrastructure wherein when a developer commits their changes, the DevOps system triggers a complete integrated set of actions to perform unit, module, system, software-in-the loop (SIL) and hardware-in-the loop (HIL) tests across various types of virtual platforms (sometimes also referred as Digital Twin) providing environmental parity with the on-road physical hardware. It is expected that the application software binary should not need to be changed to adopt to any of the underlying platforms and the same binary should be tested, validated, and executed in development and production environment. 

Once the feature has been tested in the development environment, it needs to be deployed in production, i.e.  inside the vehicle. As described in previous sections, the in-car compute system is going to be centralized and clustered in nature with multiple compute blades performing specific tasks capable of running mixed critical workload. Depending upon the service level agreements (SLA) and feature quality of service (QoS) requirements specified by the developer for the feature, the orchestrator that could be running in car and/or in cloud should configure and deploy the feature to the appropriate compute location across the vehicle to cloud compute continuum. This functionality would be like that provided by container orchestration frameworks like Kubernetes but due to the specialized constraints of running any software in the vehicle as described above, some of these fundamental cloud-native components need to be updated making them suitable for orchestrating and running container in the vehicle. 

SDV Compute Development and Deployment Platform Infrastructure Requirements 

In the previous section, we described at high level cloud-native automotive software development and deployment workflow that is a key enabler of the SDV vision. To enable such an end-to-end development and deployment flow, the in-cloud and in-vehicle compute and software infrastructure needs to satisfy several requirements that can be considered unique to automotive when compared to other segments such as enterprise where cloud-native has been deployed for over a decade with infrastructure components well understood.  In this section we list out the most important of these infrastructure requirements.

In-Cloud Infrastructure 

Below are some of the key in-cloud infrastructure requirements when it comes to enabling the cloud-native flow described above for automotive:

• DevOps: The in-cloud infrastructure needs to provide a scalable DevOps infrastructure that can support development of both microservice-based and regular monolithic RTOS-based software development workflows. The former has existed in enterprise space for about a decade, but considering the mixed criticality nature of automotive software, there will be need for extending the existing infrastructure components. As for the latter RTOS-based development, there are already multiple efforts that have been publicly announced by few Cloud Service Providers (CSP) and Operating System Vendors (OSVs) to enable this workflow in the cloud. 
• MLOps: With petabytes of data getting ingested from on-road vehicles and through simulation to build the ML models, the MLOps infrastructure needs to support the typical big loop of data ingest, cleaning, labeling, model training and deployment. The key requirement in addition to typical MLOps is to reduce the reprocessing time (time taken to capture data, train the model and do KPI analysis for the suitability of the model) to increasing the developer productivity.
• Virtual Platforms: One of the key infrastructure requirements in DevOps is to increase the developer productivity. To achieve this, we need to enable environmental parity between the developer platform in the cloud and the hardware running in the vehicle on road. To address this requirement, virtual platform with varying level of parity need to be enabled in the cloud integrated with the DevOps and MLOps flow. The varying level parity could be starting with as simple as developing and testing code on development system with the same instruction set as the in-car system so as to avoid recompilation of developer code reducing the developer feedback time, increasing in the level of parity to SoC parity (Virtual SoC), ECU parity (Virtual ECU), going all the way to complete in-vehicle E/E architecture simulation (Digital twin). The performance and fidelity of each of the virtual platforms have direct impact on developer effectiveness. 
• Scalable Deployment: After the software feature in the form of a set of microservices is developed and validated as part of the DevOps flow, the next key infrastructure capability needed is to orchestrate these microservices that can be mixed-critical in nature to the right compute node across the cloud to vehicle compute continuum based on the service level agreements and quality of service determined by the developer and the system. 

In-Vehicle Infrastructure Requirements

Moving to inside the vehicle, below are some of the key In-Car infrastructure requirements when it comes to enabling the cloud-native flow described above for automotive:

• Mixed Critical Heterogenous Centralized Compute Platform: As part of the zonal architecture, the centralized compute forms the brain of the vehicle that should be capable of running multiple mixed critical heterogenous compute workloads operating on the sensor data received from the rest of the system connected through deterministic ethernet bus and other legacy communication interfaces.
• Base Platform Software Supporting Mixed Criticality:  On the centralized compute, the base platform software needs to provide the capability to execute mixed critical workloads that could be enabled by a safe hypervisor providing the ability to instantiate a QM, ASIL-B or an ASIL-D workloads concurrently running same or different operating systems that can be a mix of Safe RTOS, Android, Safe Linux, etc. The workloads hosted could be IVI, ADAS and AD workloads all consolidated on a single compute platform.
• Automotive Cloud-Native Container Infrastructure: With containers being key ingredients in the overall cloud-native narrative, the in-vehicle stack needs to enable an automotive version of container runtime that can run mixed critical microservices along with being footprint sensitive considering every cycle in the car is measured. In addition to the container runtime, the stack might enable an in-vehicle workload orchestrator making the best use of in-vehicle resources.
• Service Oriented Communications Middleware: Automotive workloads will be distributed in nature with various of its sub-components executing across multiple compute nodes in the car connected via deterministic ethernet bus. A key requirement in such a system would be providing ability for all these distributed components to communicate to each other via a high-performance low latency automotive grade service-oriented middleware like SOME/IP or DDS that can provide variety of QoS mapped all the way across the SoC and the communication backplane. 
• Heterogenous Compute/AI Libraries: Automotive workload rely heavily on heterogenous computes elements of the platform which could range from usage of compute libraries like BLAS, Eigen accelerated using in SoC GPU to using AI libraries of ML inferencing utilizing the machine learning accelerator. The in-vehicle stack needs to provide a rich ecosystem of these heterogenous compute libraries to be consumed by the in-vehicle applications

Flex SoC – an ideal SDV compute platform

We described what SDV is about, calling out some of the key vehicle-to-cloud infrastructure requirements that need to be provided by the underlying compute platform. Now let’s discuss how the Flex SoC could be an ideal in-vehicle compute solution for next-generation SDV solutions complementing the existing Snapdragon Digital Chassis solutions.

We recently announced the Flex SoC (image 3) as the latest addition to the Snapdragon Digital Chassis product portfolio, which is packed with heterogenous compute performance capable of hosting flexible mixed critical workloads on the same SoC — making it ideal for a scalable centralized compute solution.

SDV Development and Deployment Infrastructure Readiness

As can be inferred from previous sections, SDV is a system concept requiring various platform components across the cloud to car compute continuum. To accelerate the OEMs journey to SDV, Qualcomm as part of its Snapdragon Digital Chassis Solution shown in image 4, provides fundamental system components to build a complete SDV compute solution while image 5 maps the Snapdragon Digital Chassis solution across the cloud to automotive edge SDV infrastructure.

The Snapdragon Ride and Snapdragon Cockpit platforms form the in-car high performance compute platform of which Flex SoC is the latest addition. They also provide the corresponding in-cloud infrastructure components like SoC Virtual Platform needed for SDV development. The Snapdragon Ride and Snapdragon Cockpit platforms are complemented by the Snapdragon Auto Connectivity platform that brings our best-in-class 5G connectivity in the car, providing low latency high throughput access to edge and cloud resources enabling unique V2V and V2X usages. To top this up, the Snapdragon Car-to-Cloud Management Platform provides services like over-the-air (OTA) up-dates, SoftSKU etc. making the Snapdragon Digital Chassis an ideal solution for any OEM to accelerate their SDV solution.

In the following section, we analyze the readiness of Flex SoC with the SDV infrastructure requirements that we enumerated above.

In-Car infrastructure

• Mixed Critical Heterogenous Centralized Compute Platform: Flex SoC provides an ideal mix of compute and heterogenous accelerator engines required to meet the needs of next-generation SDV workloads. It provides flexibility to host multiple mixed critical workloads on the same platform, enabling the ability to consolidate various domain controllers performing IVI, ADAS/AD compute onto a single platform. In addition to the typical compute features, there are specific hardware features that Flex SoC facilitates to support spatial and temporal isolation that are crucial for supporting a functionally safe system.
• Base Platform Software Supporting Mixed Criticality: To complement the powerful hardware features, Flex SoC supports a rich base platform stack as shown in image 3. On the application processor, the Flex SoC supports safe hypervisor which provides spatial isolation between multiple mixed critical domains with support for rich base operating systems like Linux, Android and QNX. Additionally, Qualcomm is working on providing the support for specific hardware features that may support mixed criticality across the base platform software stack facilitating necessary QoS control interfaces for higher level middleware and cloud-native infrastructure to leverage. The Flex SoC also supports an ASIL-D safety island to host AUTOSAR Classic system level safety functions along with run mixed critical low latency hard real-time OEM applications.
• Automotive Cloud-Native Container Infrastructure: On top of the base platform software that enables a cloud-native workflow, Qualcomm plans to support in-vehicle mixed critical cloud-native containers and orchestrator infrastructure working closely with the ecosystem. This capability will extend the flexibility of Flex SoC to execute concurrent mixed critical workload to the cloud-native design paradigm and one of the cornerstones to incrementally bring the SDV vision to reality.
• Service Oriented Communications Middleware: With the base platform software and automotive cloud-native container infrastructure in place — which allows the execution and orchestration of automotive containers — the other most important software component is a service-oriented communication middleware to enable a standard-based high performance low latency inter-process and inter-node communication between containers running in a single or multiple compute node. Flex SoC platform supports SOME/IP and DDS as the two most used communication middleware in automotive with extension to leverage mixed critical features in Flex SoC. 
• Heterogenous Compute/AI Libraries: To complement the solid platform software and hardware infrastructure — to allow the automotive software developers to write software making the best use of Flex SoC capabilities — Qualcomm provides multiple safety certifiable libraries like AI SDK, that can be used to write application on bare metal or in containerized environments.

In-Cloud infrastructure 

• Virtual Platforms: As part of the Flex SoC offering, Qualcomm is supporting virtual platforms with different levels of parities that are getting integrated as part of the cloud-native DevOps and MLOps infrastructure of some of the leading OEMs. Depending upon the level of system parity an OEM needs, they can integrate either the virtual platforms that virtualize many of the Snapdragon IPs with high performance and fidelity or use one of the EDA vendor’s virtualization platforms that Qualcomm works closely with to create a virtual Flex SoC that can be integrated in a virtual ECU implementation. As part of its expanding automotive virtual platform portfolio, Qualcomm is also working on adding advanced capabilities like supporting in-cloud hardware accelerated reprocessing pipeline, allowing automotive developers to quicky verify the KPIs of their AI models developed for Flex SoC when new in-car or synthetic sensor data becomes available, thus contributing to increasing the developer efficiency multi-folds. 
• DevOps/MLOps: As mentioned above, Qualcomm is working with multiple OEMs to support Flex SoC-based development infrastructure as part of their DevOps/MLOps flow with intercepts into the Snapdragon virtual platforms. One of the key objectives is to promote the Flex SoC and Snapdragon Digital Chassis as a complete SDV product portfolio to provide the optimal in-cloud infrastructure to provide best-in-class developer effectiveness 

SDV, the software-defined vehicle, is no longer a buzzword but a real-world solution that’s being realized today. The Flex SoC-enabled SDV development and deployment infrastructure described above, supports shift-left automotive system development reducing the time to market for OEMs while providing infrastructure to develop and deploy new features across the lifetime of the vehicle. This allows OEMs to create new post-sale service-based business models while providing end customers with enhanced user experiences across the lifetime of the vehicle.  

We have just scratched the surface of SDV, and how the Flex SoC is well-suited as the SDV compute platform of choice. Look for upcoming information on the technologies that Qualcomm is, and will be, enabling to become the platform of choice across the SDV ecosystem.