Vehicle Head Unit Runtime Offloading for Low-Cost Upgrades
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
As vehicles age, computing systems like head units become outdated, leading to high replacement costs due to seamless integration with unique form factors and expensive components, prompting operators to purchase new vehicles for newer technology.
Innovation Solution
Implementing an extensible computing architecture that allows head units to interface with a supporting computing system, offloading runtime environment operations and enabling upgrades to the supporting device, which is not seamlessly integrated, thus reducing costs and extending the life of the head unit.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If the head unit is seamlessly integrated into the vehicle dashboard with unique form factors and expensive components, then the user experience and vehicle aesthetics are improved, but the cost and difficulty of replacement increases
Solution Approach 1:
The system separates the head unit (integrated into dashboard) from the computing system (separate device). The head unit handles display and user interface functions while the computing system handles processing and applications, allowing independent replacement of each component.
Solution Approach 2:
The computing system is designed to be universally compatible with different head units through standardized communication protocols (Android Auto, Apple CarPlay). This allows the same computing system to work with multiple head unit models, reducing replacement costs.
2Adaptability or versatility
If the head unit integrates expensive components like large displays and GPS into a single housing, then the functionality is improved, but the replacement cost increases
Solution Approach 1:
The computing system is extracted from the head unit housing into a separate device. This separates expensive components (display, GPS antenna in dashboard) from processing components, allowing users to keep the head unit and only replace the computing system when needed.
Solution Approach 2:
The system uses software-based GPS and other services that can be replicated across different devices rather than relying on expensive hardware components built into the head unit. Cloud-based services replace some hardware functionality.
3Ease of operation
If the head unit is specifically designed for each make and model of vehicle, then the integration is improved, but the availability of replacement head units decreases
Solution Approach 1:
The computing system uses universal communication protocols (Android Auto, Apple CarPlay, Bluetooth) that work across different vehicle makes and models. This allows a single computing system to interface with multiple head unit types, increasing availability.
Solution Approach 2:
The system introduces standardized communication interfaces as intermediaries between the head unit and computing system. These intermediaries translate between different vehicle-specific protocols and universal protocols, enabling compatibility across makes and models.
4Adaptability or versatility
If the entire head unit is replaced to gain access to newer technology, then the computing capabilities are improved, but the expense increases
Solution Approach 1:
The system divides the infotainment system into separable components: the head unit (display and interface) and the computing system (processing and applications). Users can upgrade the computing system independently while keeping the head unit, reducing upgrade costs.
Solution Approach 2:
The system allows upgrading computing capabilities by changing software parameters and applications on the computing system rather than replacing hardware. Operating system updates and application installations provide new features without hardware replacement.
Data Source
AI summary
A main computing device integrated into a vehicle may perform various aspects of the techniques described in this disclosure. The main computing device comprises a memory and a processor. The memory may store a first and second instance of a runtime environment. The processor may execute a first container that enables execution of a first instance of the runtime environment, and execute a second container that enables execution of a second instance of the runtime environment. The first instance of the runtime environment may detect a supporting computing device, transfer, responsive to detecting the supporting computing device, the second container to the supporting computing device, and interface with the second instance of the runtime environment to jointly present the user interface by which the operator of the vehicle controls the functionality of the vehicle.