Menu
Menu
Menu
Bluetooth® has long been a standard feature in the automobile, supporting hands-free telephony, audio streaming, messaging, and contact synchronization.
Current platforms on which this technology is offered typically manage infotainment-based applications. Yet, future in-car requirements consolidate additional features, including continuous connectivity to the internet, commercial applications, advanced driver assistance, and even autonomous driving. This additional complexity is driving migration to high-power computing (HPC) and the need for a hypervisor to manage multiple operating systems running in separate partitions.
Traditionally, different automotive use cases are built on specific operating systems. Infotainment often runs on Linux, ECUs utilizing AUTOSAR will run on Real-time Operating Systems (RTOS), and even other use cases could be supported on Android. As can be seen, different operating systems are required to support the wide array of functions that can be consolidated. Re-writing all code to reside on a single operating system would not be practical. Reusing proven legacy software is a desirable requirement for this emerging platform.
When consolidating very diverse software systems, the designer must also be aware of “criticality,” or the importance of each software system. For example, control functions managed by AUTOSAR are of greater significance than an infotainment system that streams multimedia. Additionally, internet connectivity, required in the connected car model, opens the in-car platform to security breaches. Segregating software systems on a single hardware platform is a necessary requirement. If one software system crashes as a result of an internet virus, all other systems remain affected.
Criticality, security, and the need for different operating systems require a different software architecture from what has been traditionally used. Virtualization, a concept used extensively in IT, is now a viable solution. Virtual machines (VMs) run independently on the hardware platform for the automotive environment and are managed by an underlying hypervisor.
Hypervisors are small microkernels that can be designed to take advantage of multi-core technologies (single core is supported as well) and serve as a software platform providing any number of segregated partitions capable of holding entire operating systems. Each operating system runs independently and remains unaffected by other operating systems.
Operating systems running inside partitions have a need to communicate with other operating systems (in different partitions) or hardware (as in the case of Bluetooth.) Both intra-partition communication and hardware I/O access are strictly controlled by the hypervisor. These connection paths are configured during the hypervisor build process. There are several disjointed pieces needed to complete the Bluetooth solution.
At the heart of the system is the Bluetooth stack and profiles running in a single partition. The Bluetooth controller’s driver co-exists in the same operating system partition where the Bluetooth stack resides and hardware I/O is available once the Bluetooth stack becomes operational. Typically, a high-speed UART is used as the interface to the Bluetooth controllers and drivers are already made available in the operating systems to handle such hardware.
In an architecture that uses a hypervisor, several guest operating systems may require access to one particular driver, such as a graphics driver. For example, separate operating systems could manage a rear view camera, an infotainment system (with Bluetooth,) or an Android implementation, which manages internet connectivity. In such a scenario, each operating system would need access to the display which is managed by a single graphics driver. This driver would be placed into a service partition and made accessible to all operating systems.
Communication paths between partitions are configured in the hypervisor and made ready for use supporting data flows between segregated applications.
As mentioned above, the Bluetooth HMI may need to be accessed by this shared single graphics driver within the service partition. This driver supports multiple applications where each application is kept within its own partition. Although the driver resides separate from the Bluetooth application framework, the HMI required in supporting multiple automotive Bluetooth profiles remains with the Bluetooth partition.
The Bluetooth profiles by themselves are not difficult to manage. However, when combining multiple Bluetooth profiles, management of the HMI and Bluetooth profiles becomes complex very quickly. Hands-free telephony, audio streaming, messaging, and contact synchronization are the most prevalent profiles used within the car and often can be triggered simultaneously. For example, the hands-free telephony use case has the telematics head unit supporting the “hands-free unit” side of the link. It is primarily set up to handle phone calls, but can also handle the following additional behaviors:
In addition to the classic Bluetooth profiles, Low Energy profiles are also finding a place in the car. By being placed in a fast boot partition, Low Energy applications such as sensor data collection can be quickly available for use by the AUTOSAR controller.
Unlike a PC, where the typical boot time is perhaps 1 minute, the car is expected to be in full operational mode within a second. Secondary systems such as those associated with infotainment may become available later in time as they are not as critical, but they still need to boot quickly (within seconds).
Bluetooth is unique in that it should be activated quickly, allowing it to scan the surrounding area for paired devices to connect with. Hands-free functionality could be almost instantaneously supported by the head unit using a “fast-boot” implementation. The graphics capability could be excluded from the initial Bluetooth operation to allow the connection establishment to occur uninterrupted.
For example, in a Linux fast-boot scenario, a lightweight version of Linux could be used to reduce load time into memory. In this case, UBoot would initially load the hypervisor into supervisory memory, and then load lightweight Linux (with Bluetooth) followed by the ECU state manager, and then, optionally, load AUTOSAR. (AUTOSAR is mentioned here because this component must be available quickly in order to manage car control functions.) At this point, the system is booted, partitions are set up, and communication channels are established between partitions. The hypervisor then initializes the guest operating systems (Bluetooth on Linux starts first). This modular boot approach facilitates the need for applications that require fast boot times. Once Bluetooth becomes operational, it immediately begins to examine the environment for devices that it has previously been paired with, establishing a connection with such devices in preparation for supporting the hands-free operation.
It would at first appear that virtualization and the architecture required to support this paradigm is overhead intensive and this would impact performance. However, in some instances, the Linux OS runs even more efficiently resulting from the modifications made to the scheduler. There may be inefficiencies in terms of driver interaction and HMI support since communication paths must be traversed between partitions and performance degradation may be noticed under these circumstances. However, the platforms being used in support of virtualized devices are typically powered by a multi-core architecture and also supported with co-processing power.
As a result, the end user would not notice a slower response from a virtualized Bluetooth implementation. In fact, the fast-boot scenario presented above would be perceived as being just as fast (if not faster) than a non-hypervisor architecture.