Most of the initial UI components are related to IVI functionality except for the HVAC app, which hooks into a car’s telemetry system via an Automotive Message Broker (AMB). Applications include media playback, Google Maps, a news reader, audio controls, and mobile device integration, including Bluetooth support.
This week, I spoke with Dan Cauchy, general manager of automotive for the Linux Foundation, about the role of Automotive Grade Linux comparative to GENIVI and other IVI platforms, We also discussed the future of Linux in automotive, including autonomous cars.
Cauchy has played a major role in the Linux IVI scene, as a VP of marketing at MontaVista Software, helping to develop the GENIVI-compliant, MontaVista Linux based Automotive Technology Platform (ATP). During the same period, he acted as a GENIVI board member and chairman of GENIVI Compliance.
Cauchy later helped MontaVista sell ATP to Mentor Graphics before leaving to join the Linux Foundation. Earlier in his career, Cauchy was also chairman of the Linux Foundation’s Carrier Grade Linux working group, which plays a somewhat similar role as AGL, except for high-end networking.
Last year IHS projected that by 2020, Linux will push past QNX and Microsoft to lead a 130 million-unit IVI market with a 41.3 percent share. Do you also see a shift toward Linux?
Cauchy: In general, automotive is moving to Linux, and it’s just a matter of time before Linux is the leading platform. The automotive market is where telecom and consumer electronics were about five years ago. It’s only happening now in automotive because the product cycles are longer, and the manufacturers have been concerned about open source licensing. But it won’t be any different than any other market where Linux has made gains.
Aren’t carmakers concerned that Linux lacks the real-time capabilities of say, QNX?
Cauchy: Over the last few years, we’ve seen about 90 percent what we used to call the real-time patch, implemented in Linux, including preemptive scheduling. If you want 99.999 percent determinism, it’s quite good today, but if you need 100 percent it’s not yet there. In any case, it’s not an issue with IVI. When we get more into telematics, real-time becomes more important.
How does building an automotive computing stack differ from other embedded Linux technologies?
Cauchy: The basic technology is not that different. It’s the same kernel , middleware, a lot of the same open source components. That’s the beauty of using open source Linux — you can reuse what’s available. There is, however, more of a focus on fast boot and security, and you need access to the vehicle’s CAN bus. That’s not a huge adjustment for Linux.
What needs are being filled by AGL that are not already supported by GENIVI?
Cauchy: GENIVI and AGL were launched with different goals. GENIVI wants to promote Linux and open source in the automotive market, and it did a fantastic job at that. They educated the manufacturers about licensing and liability. The focus with GENIVI is on the spec and the compliance program. It was never about an actual distribution or a common platform. It’s more about people building their own platform and making it compliant. AGL was started as a distribution reference platform from the get go.
Another difference is that AGL is a completely open source project. The GENIVI spec has some components that are not available in open source. With AGL, any developer can contribute code, and everything is released in the open.
AGL and GENIVI are really not very competitive, and in fact, we are pretty closely aligned. We’re talking to GENIVI about other ways our two organizations can become better aligned.
Speaking of alignment, Intel said that its new Intel In-Vehicle Solutions (IIVS) automotive reference platform, based on the Intel Atom E3800 and Tizen IVI, is “aligned” with AGL, but not fully compliant with it. How would you define the relationship, and will there be other Tizen-based automotive platforms that don’t fully comply with AGL?
Cauchy: I can’t comment on IIVS. All I know is Intel is very supportive of AGL.
I’ve heard that Toyota and Jaguar/Land Rover are both working on Tizen IVI systems based on AGL. What is the timetable for releasing products, and are other AGL members like Hyundai and Nissan planning AGL products?
Cauchy: I can’t comment on OEM plans. However, Toyota and Jaguar/Land Rover are both very active in AGL, and have developers working on the platform. I think we can expect at least one manufacturer to come out with an AGL-based IVI system within the next year.
AGL is processor agnostic, but what chips are being used in the early designs?
Cauchy: The Intel Atom is a big cornerstone, and we are also supporting Renesas R-Car and TI’s OMAP5-based Jacinto. We don’t have Freescale i.MX6 support yet. In general, we support inexpensive, $300-$400 development boards so a wide range of developers can use AGL. But the car manufacturers are responsible for porting to specific platforms.
Will AGL and/or its partners collaborate with some of the emerging schemes for standardizing interactions between IVI systems and mobile devices, such as MirrorLink, Apple’s CarPlay, or the new Android Auto?
Cauchy: It’s not within our scope to support them because it requires manufacturers to enter into agreement to offer access. There’s nothing preventing any of those standards to run on the AGL stack. If membership wants us to provide standardized access, however, it would be possible.
Renault is using Android for all its IVI systems. To what extent will Android catch on as an IVI platform?
Cauchy: Android has a problem in that a lot of car manufacturers are not willing to give up the control of the display to Google or Apple. They want to keep that relationship with the consumer and maintain their branding, which is something that AGL and Tizen IVI are better designed to support.
What benefits does Tizen IVI provide that are not available on Android or other GENIVI Linux flavors?
Where is the dividing line between AGL and Tizen IVI?
Cauchy: AGL builds on top of Tizen IVI with a UI and automotive specific apps. We develop things that we submit upstream back into Tizen, and then there are other things that are AGL specific. The delineation is that AGL tends to reside above the middleware stack.
What are the future directions for AGL? Any new releases expected this year?
Cauchy: We use a code-first methodology, so when there are chunks ready, we release them. We’ve implemented Wayland support and W3C extensions, and we will keep extending support for new web APIs. We’ll move from the Webkit runtime to Crosswalk in the third quarter. Smack is under consideration for holistic security, but we’re also looking at SELinux.
Will AGL move beyond IVI to support more telematics functions, and eventually advanced driver assistance systems (ADAS) and autonomous cars?
Cauchy: From the get go, we have wanted to support everything in the car, not just IVI. The next steps will be to support instrument clusters — there are all these LCD clusters now that run Linux — and then HUD [head-up displays] and more telematics. Manufacturers want all of these systems, plus IVI, running on one system, with a portioning scheme using a multicore hypervisor. But that won’t happen for a while. Today all these run on different systems, many of which have their own RTOS. But it makes sense to have Linux control the cluster, which is a lot like IVI. Why wouldn’t the OEMs want to standardize on that?
ADAS is not in our scope right now. It’s too early. You’ve got some ambitious folks at Google who seem to be going the full autonomy route, but the rest of the industry is probably moving to a more semi-autonomous design, with vehicle to vehicle communications. All this will take time to get properly automated. The world is not yet ready for an autonomous car.