Vehicle App Store: The Holy Grail of Software-Defined Vehicles

The concept of a Vehicle App Store represents a transformative leap for software-defined vehicles, integrating cloud, smartphone, and on-board services to enable rich, dynamic applications. At its core, this ecosystem requires several foundational elements.

Foundational Elements of the Vehicle AppStore

First, a secure on-board app execution environment is essential, utilizing container technology to create isolated sandboxes where apps can operate safely. This environment ensures that apps have controlled API access, organized into trust levels. For example, apps developed by the OEM (Original Equipment Manufacturer) would have higher trust levels, enabling access to a broader range of APIs, while partner or third-party apps might have more restricted permissions.

The Vehicle App Store itself plays a crucial role, providing a platform for distributing apps to vehicles via over-the-air (OTA) updates, supported by robust cloud connectivity. This seamless connection between the on-board environment and the cloud enables ongoing updates and the integration of new services.

Example: A Mechanic's Smartphone App to Open a Vehicle Door

To understand how this system works in practice, let’s revisit a concrete example: a mechanic using a smartphone app to open a customer’s vehicle door. The app, designed for the smartphone, is downloaded from the app store of the smartphone's provider (e.g., Apple, Google). For this app to function, the OEM must first submit it to the smartphone company’s app store. Additionally, the OEM must ensure that supporting microservices are distributed across the necessary environments.

Here’s how it unfolds:

1. App Deployment: The OEM provides the app to the smartphone company’s app store. Simultaneously, the required software components and microservices are deployed to vehicles via OTA updates. These microservices act as the on-board counterparts to the smartphone app.

2. Backend Services: The OEM also sets up backend cloud services to support both the on-board and smartphone applications.

3. Action Execution: The mechanic presses a button in the smartphone app, triggering a call to a remote API. This API request is processed by a microservice in the cloud, which then calls a remote API exposed by a microservice running on-board the customer’s vehicle.

4. On-Board Operations: The on-board microservice communicates with the vehicle API to execute the requested action, such as opening the door. This involves performing all necessary safety checks (e.g., ensuring the vehicle is stationary, checking surrounding traffic, and confirming no obstructions).

5. Cross-System Collaboration: For this process to work seamlessly, all three components—the smartphone app, the cloud microservice, and the on-board microservice—must be fully functional and integrated. Additionally, the vehicle must have the necessary API (in this case, the open door API) implemented.

The following diagram shows the flow of app components through the system:

The following diagram shows how the distributed app components are interacting after having been installed in the different runtime environments:

Complexities and Cross-System Coordination

The Vehicle App Store paradigm highlights the complexities of creating Vehicle SOAs as a distributed system. OEMs must coordinate across multiple domains, including on-board systems, cloud services, and third-party platforms like smartphone app stores. Each element must work together flawlessly, requiring extensive cross-checks and validations to ensure compatibility and functionality.

Despite these challenges, the Vehicle App Store is considered the "holy grail" of software-defined vehicles. By enabling the seamless integration of applications that combine smartphone, cloud, and on-board services, it promises to revolutionize the vehicle experience, delivering rich, innovative features to customers and establishing a dynamic ecosystem for the future of mobility.