Tux Racer!

Dan Cauchy brings Jonni Bidwell up to speed on Automotive Grade Linux, coming soon to a car – or even a boat – near you!

Dan Cauchy brings Jonni Bidwell fully up to speed on Automotive Grade Linux, coming soon to a car – or even a (narrow) boat – near you!

DEALING WITH IN-CAR AV STREAMS “If the navigation is trying to talk to you and a phone call comes in and the lane departure warning needs to tell you something, you need to have that capability.”

Dan Cauchy is executive director of Automotive Grade Linux at the Linux Foundation. Before that he was VP of Automotive at Montavista, which was a pioneer of embedded Linux. And before that he was a board member for the GENIVI Alliance, which was instrumental in getting car manufacturers to adopt open source, standards-based IVI (invehicle infotainment) systems.

AGL isn’t so much about self-driving cars as powering its infotainment and instrumentation systems. We actually met Dan before, back in LXF218. But you can imagine things move fast in the world of cars, and also we like Dan, so we thought a catch-up was well in order. As luck would have it, both he and roving reporting unit Jonni Bidwell were at October 2019’s Open Source Summit in Lyon, where the following exchange ensued…

Linux Format: How did you get into open source and automotive software?

Dan Cauchy: I was a general manager and VP of the automotive business at Montavista Software. Montavista was a really pioneering company, in that it was the first to identify that Linux could be put into devices. Things like Canon printers, Sony ebook readers, the Playstation 3… these are all things that Montavista did the kernel for. They were known as a Linux kernel guru company.

Eventually, among those things we got into automotive and I ran that whole division. We were the first to put Linux in a vehicle, I can’t mention which vehicle any more, but your readers can easily look that up on the Internet. I was on the board of directors for the GENIVI Alliance and I was the chairman of the compliance programme. So that more or less propelled me into this whole Linux-incars world, and AGL became an obvious thing for me.

LXF: Propellers you say? This reminds me, I own a narrowboat. Do you think one day I can power it with AGL?

DC: A narrowboat? Cool. We will absolutely support other types of vehicles. We’re actually working with the government of France and one of our members has been funded to do some work on boat Linux. And it would be 100 per cent Agl-based because the requirements are the same. There might be new features that are boat-specific, but it makes total sense.

And by the way, one of the guys working on this has a 50-foot sailboat so he’s all excited about that as well. So yes, absolutely, it’s coming.

LXF: So we last met in Berlin in 2016, I believe. I guess an awful lot has happened with Automotive Grade Linux (AGL) since then. Can you summarise what’s new?

DC: We’ve literally exploded in the past three years, in terms of member participation. We now have 155 member companies; when we last spoke that number was probably less than half of that. The most important part is the automotive manufacturers: we now have 11 OEMS on board. And if you look at the market share of these OEMS it accounts for approximately 60 per cent of annual worldwide vehicle shipments.

So these are the big ones: Toyota, Mazda, Daimler, and we recently signed up Volkswagen Group, so that’s the whole group including Audi, Porsche, Scania, Skoda, Lamborghini, Bugatti and I’m still missing a few. We recently signed up Ford, and on top of all of that we signed up SAIC from China.

So in 2016, when I last talked to you, people thought we were a Japanese-only consortium, because most of our partners were from there. We can now safely say we’re a worldwide consortium. We’ve had Daimler signed up for a long time, but the addition of the Volkswagen Group means we’re quite big in Germany and the rest of Europe. Adding Ford means we now have this ecosystem in the US, and adding SAIC means we can start building our ecosystem in China. So the growth is still going and I don’t see it stopping any time soon. Oh, Hyundai signed up a year ago too, so that’s key for South Korea as well.

LXF: Olly, my trusted photographer, drove us to the airport, which involved judicious sat nav use. So I was telling him that this might well be powered by AGL. He was shocked to hear Linux isn’t just for people who want to make their desktop computing lives difficult. There’s a whole world of embedded systems that use it. Maybe we talked about this side of things last time, but being an infotainment system means there are

some features people will recognise from desktop Linux distros. I gather you’ve just started using Pipewire, for example? DC: Yes we do. That was a move we debated quite a bit actually, because automotive audio requirements are in many respects quite different than mobile devices and other devices. There’s not only safety requirements, there’s also, for example, the layering of the audio: if the navigation is trying to talk to you and a phone call comes in and the lane departure warning needs to tell you something, you need to have that capability. We’d built a lot of that capability before and we were reluctant to move to something new, but the community is all about seizing the future, and Pipewire seems to be the way things are going. So what we’ve been doing is feeding automotive requirements into Pipewire, and anything that we modify will end up going upstream, of course.

LXF: Do you think, with so many manufacturers on board now, that AGL is becoming a de facto standard? Last time you explained lots of OEMS were building solutions, which were woefully out of date by the time they got to market.

DC: We’re definitely becoming a de facto standard – we’re already shipping millions of vehicles. We expect two or three new manufacturers to come on board next year (which I can’t disclose). And I think we’ll have about 17 or 18 companies showing AGL running on their products in our CES booth. [Now, with the passage of time, we can safely say that in January at CES, Subaru announced that its 2020 Outback and Legacy models would ship with AGL].

But back to your point, yes, we’re becoming a de facto standard. Design cycles are still slow, so the ones that have recently joined probably won’t have products out for another two or three years. But that’s expected… y’know those are the timelines required for automotive! We already have millions of cars on the road, but once we have four or five more manufacturers, then we’re here to stay.

Probably for decades, because we’re just going to continue evolving the platform, changing with the times, adding new features.

Right now, in terms of open choices, there’s really no other choice in the market. These other flavours of Linux that companies have built are all one-offs. And that’s precisely the kind of fragmentation we’ve been trying to eliminate, and

I do think we’re succeeding. One of my measuring sticks, when I look at a company like Amazon, is that they have unlimited funds, unlimited whatever, they could do whatever they wanted… and they chose to support AGL, and not just in the vehicle but outside the vehicle, too. So I’m using this as a great example for our ecosystem. Amazon has already ported Alexa to AGL and are already shipping it through Toyota.

But the AWS division also decided to create a cloud solution that connects to AGL. You go to the AWS website now, and there’s a page that will show you how to create your AWS instance and connect it to AGL within minutes (see https://aws.amazon.com/solutions/ aws-connected-vehicle-solution). That’s the kind of ecosystem we’ve been striving to create. If you made your own, one-off fork of Linux you couldn’t convince someone like Amazon to use it. But we can, because we’ve got the backing of 11 manufacturers and 155 companies, so that’s pretty cool.

LXF: Can you speak about the structure of AGL a little? Is it fair to think about it as we would a regular Linux distribution? I think last time there was a sort of fourlayer structure in place.

DC: We’re embedded, so I don’t really like the term ‘distribution’ so much. We don’t have a package feed, so we’re not really like a distribution – not like Debian or anything like that. We custom build an embedded image for a given hardware platform, and we use Yocto (See LXF251) to do that. So in that sense it’s not a distro.

Having said that, we have a lot of members that are looking at creating a Yocto-based package feed. And that would be interesting. It hasn’t been done yet, and we don’t want to get away from the Yocto methodology, because that’s what we do. But using the metalayers that we have for all the middleware and stuff we could create this Yocto package feed. And that would be an interesting way to go.

LXF: We did a virtualisation feature recently, and I was impressed to see

how big of a role that’s already playing in the embedded sphere. What about virtualisation in automobiles?

DC: We set up a working group on virtualisation a little over two years ago. It’s extremely active. We’ve already demonstrated an AGL instrument cluster running side by side with AGL infotainment on the same processor, using a hypervisor. We’ve shown it with open source hypervisors like KVM and Zen, and commercial providers have shown it running with the likes of Greenhills or L4 Kernel. It’s a big part of the strategy of what we call ‘cockpit consolidation’. We see a day where a single powerful SOC combines the functions of instrument cluster, heads-up display and infotainment all on one processor. That will be enabled by virtualisation and you’ll be able to separate things for safety, certify those components that require it (like the instru ment cluster), and not have to worry about that for things that don’t (like infotainment). It’s a big part of our strategy, and that group is working on some really cool stuff, actually.

LXF: So infotainment’s pretty cool: we all want Linux playing our tunes and navigating us to our destinations on time. But where else does AGL connect to? Can it talk to CAN buses and such, so that you can read engine and sensor data, for example?

DC: Absolutely. From day one. CAN buses, Ethernet – because in vehicle AVB (audio video bridging) is becoming more prevalent – we have full device hardware for that and we support that. But more importantly, you want other functions, so instrument cluster feature was released [in 2018] and is working very well.

Since then we’ve had an important development. We’ve formed an instrument cluster expert group, and it’s being led by Suzuki. Having an OEM lead it means it has credibility, makes it legit. Suzuki is helping us reduce the form factor and basically optimise it for lower cost, so that it can go into cheap Socs for low-end vehicles or even motorcycles. It plans to have a demonstration of all of this at CES. So the next phase, which involves deployment to things like motorcycles, and all sorts of things that have a screen but don’t have all the infotainment requirements, is pretty exciting. You don’t have a quad-core SOC there – it can be a very simple SOC.

LXF: I was just talking to Kate Stewart from Zephyr (and through the magic of print media time travel you can read it in LXF260). Do you think there’ll be some sort of Agl-zephyr collaboration? Cars aren’t necessarily IOT devices, but they must have, or surely will in future have, lots of Thing-like hardware in them.

DC: I know Kate, and that’s definitely a possibility someday. If Zephyr intends to enter the world of small microcontrollers in the vehicle then we might have a reason to work together, which would be great. We’d like to see Zephyr replace some of the proprietary RTOSES, and that would be better for everyone.

But back to Kate: we’re collaborating with another of her projects which is Elisa. The Elisa project was founded by BMW and Toyota, and lots of other big-name manufacturers are involved. It plans to bring functional safety to Linux. Not just for automotive, but for industrial too: so nuclear power plants, trains… things like that. We’re collaborating on bringing functional safety, especially to the instrument cluster that we’re building. We want to bring functional safety certifications. And we’re piggy backing on what Elisa does. Whatever methods and artefacts and testing that they come up with, we’ll piggy back on that. What’s nice is that we’re all under the Linux Foundation umbrella, so it makes everything easier.

LXF: That’s a pretty big umbrella, which seems to get bigger every day. I guess you can’t do everything for automotive manufacturers – a lot of the integration has to be done on their side. But what do you do to make this easier? How does the AGL Unified Code Base (UCB) fit into the picture?

DC: The Unified Code Base is basically our platform, and it has multiple instantiations. We’re able to use the methods that Yocto provides using metalayers to do this. So we’re able to include or exclude certain

COCKPIT CONSOLIDATION EXPLAINED “We see a day where a single powerful SOC combines the functions of instrument cluster, heads-up display and infotainment all on one processor.”

packages from certain solutions. The infotainment subsystem is the big one. For instrument cluster we can take whatever subset, so we remove some of the graphics, some of the 3D stuff for lower cost, smaller class hardware, but it still has a lot of the same software.

For telematics we remove all the graphics and audio stuff, because it’s basically headless. You don’t need that stuff. What you really need is a communication stack with a good crew. But it’s all built using one code base, so there’s a lot of re-use and that’s why we called it Unified Code Base. We’re unifying everything, and adding and removing what’s needed for each solution. That’s been our strategy from day one.

LXF: Does AGL have its own patching mechanism? I imagine that it must support some kind of OTA (Over The Air) updates.

DC: We have OTA today, we use Ostree and we’re able to patch at the package level. But to be honest all those things are manufacturer specific. So we provide mechanisms, but the manufacturers all have their own rules because managing your vehicle for safety, bringing your vehicle into the dealership – they all have different philosophies. Some still want the dealership model, some want a more conservative OTA, something like one patch a year. So it’s still manufacturer specific and we don’t get involved in that. But we try to encourage them, through data, that patching more frequently is better for everyone.

We hope that eventually they’ll adopt a similar mentality to mobile phones: when you have something serious, patch it and push out that patch. I think that Tesla is doing this and Tesla is a model for the other manufacturers to follow. I think it will happen – it’s just a matter of time until they figure out the management of these things.

LXF: Do you see Tesla as a bit of a, hmm, maverick manufacturer?

DC: I knew you were going to say maverick. I would say so. But it’s also quite innovative. It has done things very quickly, as a new manufacturer, that others are probably striving to get to. Especially the OTA capabilities, and some of the functionalities it’s introduced such as finding an electric charger, finding your route – those are all really innovative

BUILDING ON A FIRM FOUNDATION “The Unified Code Base is basically our platform, and it has multiple instantiations. We’re able to use the methods that Yocto provides using metalayers to do this.”

things. Other manufacturers haven’t caught up, but they keep innovating and they keep pushing the envelope. It’s great for our industry and it’s great for AGL because then our manufacturers want those same features. So it’s pushing everybody forward.

LXF: And before we go, what does the future hold for AGL?

DC: Right now we’re working on completing all the solutions for the major Socs in the vehicle. I’ve mentioned them all already – infotainment, instrument cluster, heads-up display, telematics – we have solutions for them and we’ll continue working on them. The next phase, which we’ve started working on, is getting ADAS (Advanced Driver Assistance Systems) and autonomous.

We’re not trying to get into the AI business, because companies there are spending billions of dollars developing those algorithms and things. But all those companies need a rock-solid, functional safety certified Linux platform. And the part they’re missing today is that a lot of them are using Debian or even Red Hat, which isn’t appropriate for the environment that they’re in. It’s fine for the R&D phase, but eventually, when these cars get on the road and start driving themselves, they’re going to need an embedded Linux-based solution that has functional safety. So that’s what we’re planning to build. We’re going to use Realtime Linux for that. We’re going to add radar, lidar, camera, sensor support, visualisation… all that stuff. We’re going to solidify that base platform, bring it through functional safety with Elisa collaboration. And that will be the platform for ADAS and autonomous. You wouldn’t believe how many companies have contacted us wanting such a platform. So we’re starting to build that now and we’re hoping to have something to show next year.