With automotive displays mounted in the center console, in or above the dashboard, on the backs of the front seats, and/or overhead in entertainment panels, the automobile is fast becoming a state-of-the-art mobile device. Often times, integrated in-vehicle infotainment (IVI) systems run these entertainment, information, or internet-connectivity applications.
Mobile-device connectivity has become a major component in IVI systems in an effort to meet consumer demand to access internet and common smartphone content, such as music streaming, traffic information, and weather forecasts. In addition, IVI now must handle various data streams, including high-definition multimedia and 3D graphics, wirelessly transmitted information connecting the car to local- or wide-area (the "cloud") networks, and advanced driver assistance system (ADAS) data showing lane-departure warnings and other content (e.g., vehicle system checks) that impacts safety.
Overall, consumers expect the same functionality in their vehicles as on their smartphones, so the amount of software required to support IVI functions has grown exponentially. In the past, each individual automaker would tend to develop its own IVI system—Ford with SYNC, BMW’s ConnectedDrive, Chevrolet’s MyLink, Audi’s Connect PRIME, etc. Then there’s also CarPlay and Android Auto from Apple and Google, respectively, which were developed initially to serve their main market of smartphone users.
Consider this for a moment. What would happen if each PC brand had a different OS developed by the manufacturer from the ground up? Imagine how difficult it would be to develop a new application for both software developers and manufacturers faced with essentially having to reinvent the wheel each time out. This increased amount of software would also elevate the costs of building these systems as well as slow time to market.
Instead, OEMs want to add services in their IVI stacks that will support a variety of options for their customers in the form of Android, iOS, or other smartphones, and be adaptable enough to support the rapidly changing pace of mobile technology. The solution? Linux Open Source software.
Automotive Grade Linux
To meet this challenge, Automotive Grade Linux (AGL) was launched by The Linux Foundation in 2012. AGL brings together automakers, suppliers, and technology companies to accelerate the development and adoption of a fully open software stack for the connected car. Although AGL initially focused on IVI systems, the group envisions branching out to include telematics, heads-up displays, and other control systems.
The idea is that the kernel, middleware, and app framework will all be common and shared among manufacturers and suppliers. Called the Unified Code Base (UCB) infotainment platform, it was developed to build standardized platforms and an app framework for the industry, providing 70-80% of the production IVI that ends up in a vehicle. Automakers and suppliers would customize the other 20-30% by adding features and modifying the user interface to meet their unique product needs.
AGL recently released the latest version of UCB 4.0, aka “Daring Dab.” Its new features read like a developer’s letter to Santa: speech-recognition APIs; application services APIs for Bluetooth; audio, tuner, and CAN signaling; secure over-the-air (SOTA) updates, and improvements to the app framework and software development kit (SDK).
1. Here’s the Renesas R-Car M3 in block-diagram form. (Source: Renesas)
Of particular note is UCB 4.0’s support for Smart Device Link integration (SDL), a technology developed at Ford that enables an automatic sync between IVI systems and mobile phones. SDL aims to be an OS-agnostic alternative to Android Auto or Apple’s CarPlay. An open-source version of Ford’s proprietary AppLink technology, SDL lets developers add extensions to mobile apps so that they work over compliant IVI systems.
Also new to UCB 4.0 is default board-support across Intel, ARM32, and ARM64 architectures, as well as added board support for the Renesas R-Car M3 and Qualcomm’s SnapDragon 820. R-Car M3 is available as a standalone chip and as a system-in-package (SiP) module mounted with DDR memory. It features dual 1.5-GHz ARM Cortex-A57 cores and four Cortex-A53 cores, and provides a “dual lock step” Cortex-R7 MCU (Fig. 1).
Dual lock step refers to the ability to implement the Cortex-R7 processor with a second, redundant copy of the cpu_noram, scu_noram, and axis modules. This provides redundancy in the logic without duplicating the RAMs that are protected by ECC. Both copies of the logic run in parallel, although offset in time, and the outputs are compared to detect errors.
Renesas’ first R-Car SoC incorporating AGL platform-based software has started volume shipment for Toyota’s new 2018 Camry (see “Toyota Including Automotive Grade Linux Platform in 2018 Camry”).
“Daring Dab”—UCB 4.0—follows UCB 3.0 (“Charming Chinook”) that first appeared in January and precedes “Electric Eel,” currently under feature development (Fig. 2).
2. The chart details the AGL development schedule for 2017. (Source: The Linux Foundation)
Although initially focused on IVI, AGL plans to address all software in the vehicle, including instrument cluster, heads-up display, telematics, ADAS, and autonomous driving. A new Virtualization Expert Group (EG-VIRT) being developed by the AGL Cockpit Architecture Group is the first major step toward AGL’s long-promised expansion from IVI into telematics, instrument clusters, and HUDs.
Virtualization is required because these more safety-critical functions, e.g., the vehicle’s CAN bus, need to be separated from less-secure infotainment applications. An open virtualization solution could allow for the consolidation of multiple applications such as infotainment, instrument cluster, heads-up display and rear-seat entertainment on a single multicore CPU through resource partitioning.
According to AGL, the EG-VIRT will identify a hypervisor and develop an AGL virtualization architecture that will help accelerate time-to-market, reduce costs, and increase security. The need for quick turnaround suggests that EG-VIRT will pick an existing hypervisor rather than try and create a new one.
The AGL community will come together for their bi-annual All Member Meeting on October 18-19 at the Hilton Dresden in Dresden, Germany. Topics discussed will include distribution and design considerations, application design and framework, security, tools, and support and maintenance. Other subjects expected to be covered range from autonomous driving, AI, and augmented reality to machine learning and vehicle-to-vehicle (V2V), vehicle-to-cloud (V2C), and vehicle-to-infrastructure (V2I) communications.
GENIVI
Of course, AGL isn’t the first attempt at IVI software unification. GENIVI is a non-profit open-source alliance of more than 140 companies that includes Daimler Group, Hyundai, Volvo, Nissan, and Honda. It was formed in the beginning of 2009 in an effort to counter the increasingly complex and expensive process of developing, testing, deploying, and supporting IVI systems. GENIVI pioneered the use of free and open-source software, including Linux, for non-safety-critical automotive software like IVI systems.
3. This block diagram shows GENIVI’s upper and lower platforms. (Source: GENIVI)
GENIVI Development Platform 12 (GDP 12), released by the GENIVI Alliance in May, combines the latest open-source automotive software components with the latest, stable, generic Linux-based software provided by the Yocto project (Fig. 3). Version 12 includes:
- Chromium browser
- Integration of home (and wearables) interface
- SOTA update functionality
- Expanded support for remote vehicle interaction (RVI)
- Lifecycle integration
- An integrated car data logger
The next target for GENIVI is to leverage its unique features while improving code reuse.
GENIVI has a different approach than AGL. It comes with a particular set of specifications and any company can comply, even with a different kernel or any other software module. The GENIVI platform packages OS and middleware components—it’s not a complete IVI environment. With GENIVI, the industry can flexibly generate bindings to fast-changing technology.
AGL has a similar goal, but uses a unified and customizable platform among all suppliers and manufacturers. Rather than writing specs and getting vendors to stick to them, AGL developed an actual Linux distribution. The scope of AGL goes beyond IVI; in the long run, the project aspires to include telematics and instrument clusters.
AGL now has more than 100 members, including Jaguar, Toyota, Nissan, Ford, Mazda, Mitsubishi, Mercedes Benz, and Subaru. It has a greater focus on fast boot-time, security, and getting access to vehicle-specific buses such as the controller area network (CAN). To some extent, the AGL platform complies with the GENIVI compliance specification. Since the AGL IVI platform is based on Tizen IVI, which is an IVI layer/profile for the Tizen OS originally created for mobile and embedded devices, it builds on an extensively tested OS platform by adding more user-interface and middleware components.
Despite the different approaches between these two open-source initiatives, they are attempting to solve a common problem faced by the entire industry: An increasingly repeated effort and the associated high cost of development and maintenance of software for automotive IVI purposes. Engineers will likely find that they’re closer to complementary entities than real competitors.
