Traditionally a highly secretive and competitive market, the automotive industry and its long design cycles are now confronted with consumer demands for smartphone functionality in the car. Dan Cauchy, General Manager of Automotive Grade Linux project for the Linux Foundation, discusses how the shrinking time-to-market expectations for in-vehicle infotainment (IVI) systems and features are compelling members of the automotive industry to collaborate on software standards for all aspects of the automobile.

Can you give us some background on Automotive Grade Linux?

CAUCHY: Our marketing tagline is “Collaborating to build the car of the future through rapid innovation,” and it’s more than just a marketing tagline. The reason Automotive Grade Linux (AGL) exists is that the car manufacturers realized that what they were doing was not working. An infotainment system production cycle on average, according to some industry data, is up to 39 months from start to shipping in a car. In that 39-month period, three versions, maybe four versions of iPhone and Android phones have come out. So the car manufacturers realized that the way we’re doing it now with black boxes and paying our suppliers to provide us something to our spec is just not working, and they needed to adopt a new way of doing things. This is essentially why AGL was created.

Basically, we’re an open-source collaborative project. It’s about enabling rapid innovation. Some people often think that open source is about saving money and it’s about free, but actually that’s not the motivation here. The motivation is more about keeping up and providing features for the end user that are at least on par, if not better, than the mobile phone experience. It’s clear because you pay $1,000 or more for an infotainment system in your car, but let’s face it, right now it’s nowhere near the functionality of the mobile phone in your pocket. So that’s what we’re really trying to address here: rapid innovation, new features. We’re building a reference platform that is 70 – 80 percent of the starting point for a production system, but our goal is not to make it a production system. We’re not going to be in the business of testing this and fixing every bug. That’s for a commercial entity to take the platform and bring it to production, either the car manufacturer themselves or they pay one of their suppliers to take the platform, customize it, add the user interface (UI) that they want, the look and feel, add the applications that they want, and then productize it and make it available to the end user.

That 70 – 80 percent we provide is all the common bits: the common operating system (OS), the common middleware, the common frameworks that everybody needs in a car – everybody needs audio support, everybody needs graphics, all these things. Why not just have all these companies share into the collaboration on this single platform and focus on the bits that matter, which is the differentiating part? So that’s what AGL is all about.

The industry is looking for this because there’s been a mixture of OSs and platforms out there. There was Windows for a while that wasn’t super successful and is kind of fading away; QNX was the incumbent but is rapidly fading away because of the acquisition by Research In Motion (RIM). So people are looking for one standard platform, and if you’re going to do that Linux absolutely makes sense because the rest of the consumer electronics industry is using Linux – TVs, phones, Blu-ray players, etc. So, that’s why AGL is in the position to become the industry standard for all of automotive. And with the backing of Toyota, the largest car manufacturer in the world, that helps a lot. It will help this get standardized.

Another thing in our charter is requirements specifications, so we have built a big specification document, and another big part of what we do is work upstream with other projects. For example, we don’t reinvent the wheel, so if there’s a Wi-Fi stack or a Bluetooth stack that exists out there we just reuse it, and if we make automotive-specific changes to it, we just push those changes back upstream to that project. That open-source development methodology is a big part of what we do.

Can you explain how AGL plays with GENIVI right now?

CAUCHY: So, just so you know where I’m coming from, I used to be on the Board of Directors of GENIVI for three-and-a-half years, and I also was the Founder and Chairman of the GENIVI Compliance Program. The two organizations, first of all, are not competitive, and that’s a misconception that some people sometimes have. GENIVI was founded under the premise that they would develop this compliance specification, and then anyone can bring their own platform and be compliant to the spec, but there is no one open source platform that people are working on. What people do is get a commercial platform from a Wind River or a Mentor Graphics, and then that platform goes through the certification process and then becomes compliant to the GENIVI spec. But it’s always been a bring-your-own platform kind of approach.

AGL was started with an opposite kind of methodology, which is we are building the platform, which is the one you start with. You don’t go off and build your own, you take AGL as the starting point, and it’s open source and we’re not for profit, so here it is, you take it, and you go build upon it. So we’re a code-first organization, whereas GENIVI is a specification-first organization.

What has happened is that GENIVI has been building a couple of very good and interesting middleware modules, but they’re not part of a big distribution. So what we do, and this is how we play with GENIVI, is we port those middleware modules onto AGL, and someone who needs those can use them no problem. We talk to [GENIVI] every week. Their Chief Architect attends our meetings and gives us feedback, and we’re designing our stuff to make sure we’re collaborating with GENIVI and that we don’t make decisions that alienate GENIVI. So we’re working very closely together.

Let’s get into the recently released AGL Requirements Specification 1.0. What can you tell us about that?

CAUCHY: To our knowledge, this is the first open in-vehicle infotainment (IVI) specification available. It’s open to anyone, can be downloaded from our website, and anyone can go ahead and give us feedback on it. It defines a highly integrated, Linux-based reference platform that has all of the services you would expect like Wi-Fi, Bluetooth, multimedia, location-based services (LBSs), a windowing system, layer management, lifecycle, and audio management (Figure 1). It defines support for both native Linux apps and HTML5 apps, which makes us unique because we’re going to be supporting both as we have members that want HTML5 and we have members that want native, so we’re going to make them coexist (Figure 2). We’re building the reference platform on multiple types of hardware, so x86 of course and various versions of ARM chips. Right now we have a Renesas R-Car reference board and we’re planning to add a Texas Instruments (TI) and a Freescale board also. So, basically whoever is willing to step up and help us on a given hardware platform, we’re willing to do it.

(Click graphic to zoom by 1.9x)

(Click graphic to zoom by 1.9x)

Then, one of the differences between the spec that we have and something like the GENIVI spec is that we’re using it primarily as gaps analysis to figure out what the desired features are and how they should work versus what’s in the code. We’re a code-first organization and will always be, so we’re not planning to use the spec as a compliance document. It’s more about the carmakers saying, “Here’s what we need. Here’s what we want.” And we’re analyzing, “What are the gaps between the spec and the code? Let’s go write the code that’s missing.” That’s essentially how we’re using it. It’s more like a design document than it is a specification or compliance document.

But to me the key takeaway is that this is the first time the automakers have really sat down together with their suppliers and worked collaboratively on a spec, because they tend to be very competitive. It’s a clear indication of the shift that’s happening in terms of them adopting an open-source development methodology. So they’re doing things in the open, in a collaborative way, and to me that’s the real message here because that type of thing wasn’t done in the past. There was secrecy and all of these things. They’ve broken barriers to make this happen, and that’s really good news.

So, why was Tizen chosen as the foundation for the reference platform?

CAUCHY: We wanted to make rapid progress and we wanted to show traction and attract new members, and Tizen was a good platform. It’s being supported, there are literally 1,000 developers working on Tizen from Samsung, Intel, and others, and it was a good base for us to do our prototyping and release a version 1.

Having said that, we’re moving away from Tizen now, which was always our plan. We are developing our very own AGL distribution, and the codename right now is Unified Codebase. What we’re trying to do is bring the best of Tizen, AGL, and GENIVI together into one unified codebase. We’ve announced that we’ve started the work, and basically we’re going to have different layers: a layer that brings all the common parts together, a layer that brings the GENIVI stuff, a layer that brings the AGL stuff, and then two app frameworks, one for native and one for HTML5, all in one platform.

Right now we’re really focused on rearchitecting this Unified Codebase, so we’re going to be doing a lot of work on yocto layers, which are basically meta layers that define where to get the code and tell the compilers what to compile. So it’s not actually writing code, it’s more about rearchitecting so that we have the layers that we need for long-term maintenance. We’re getting maintainers for each layer, so that work is ongoing right now.

What plans, if any, do you have beyond infotainment?

CAUCHY: We plan to address everything in the car, and I always say that if Linux is in the car, we want it to be based on AGL. Part of our charter is to address the instrument cluster (which is increasingly LCD displays); heads-up display (HUD) units; telematics, which is basically the “connected car” and all of the connectivity to the cloud and all of these Internet of Things-type (IoT-type) features; and eventually control systems, which require certain safety-critical certifications that we’re actually starting to work on right now.

We started where we did primarily because infotainment is the biggest pain point for the automakers right now. They just have not been able to keep up with the smartphone, and the lack of a single platform and the lack of a standardized application framework has been a real pain point. So this was the one with the most bang for your buck, and what we’re going to do is take the base platform and have different profiles. So it will be the same base platform, but when you build it the compilers are going to pick up different modules for the cluster or HUD, but we’re going to try to reuse as much as possible of the base platform.

More long term, how much do you think smartphones are going to continue to play a role in in-vehicle infotainment (IVI) platforms for automotive? What do you think the role of the smartphone will be 5-10 years from now?

CAUCHY: That’s an interesting question because there are two trains of thought, two camps in automotive right now. There’s the camp that says, “Let’s just use projection mode. Use the phone, project it to the display, and there you have it, we’re all done.” But there’s a problem with that. One is that you still need an OS and you still need a lot of features in that head unit because you still need an air conditioning control and all the functions of a car still need to be displayed in that head unit, which means you need a full-blown OS – you’re not going to ship a car without a radio, you’re not going to ship a car without Bluetooth. So suddenly you’ve got two things: you’ve got a full OS in the car and you’ve got a full projection display in your hand, and you have redundant systems there.

That’s one problem, but the other, bigger problem I think is that some of the car manufacturers have said, “We don’t want to give away our customers’ data and the relationship we have with our customers to Google and Apple.” So there’s that philosophy of, “Wait a minute, it’s our car, it’s our system. We’re going to have this excellent experience based on our brand, not someone else’s.” So the portal that the customer goes to is going to be branded by the car manufacturer, not by Google and Apple. So those kinds of philosophical debates on who owns the data and who’s going to make money off the data – for example through LBSs and things like that – a lot of car manufacturers are saying, “We’re not going to go that way. We’re keeping our customers.”

Dan Cauchy is General Manager of Automotive for the Linux Foundation.

Automotive Grade Linux

www.automotivelinux.org

[email protected]