 Okay, so I guess we'll get started. Thanks everybody for attending. This is the Automotive Grade Linux Birds of a Feather, Developer Birds of a Feather session. And so all the, I posted these slides maybe an hour or two ago to the schedule site so you can download them. There's a lot of links and resources at the end. So you can just click on them. They should all be hyperlinked. So just wanted to do a quick introduction and then we can get into more of a Q&A session. What is AGL? In case you don't know, we're basically an open source project hosted under the Linux Foundation. And our tagline is collaborating to build the car of the future through rapid innovation. We're focused on rapid innovation of in-vehicle software and that includes instrument cluster and in-vehicle infotainment and telematics. And we're focusing on a single code base called the unified code base. So everything that we do is built from a single source tree. We have a total of nine OEMs that are supporting HEL. You can see we have Honda, most of the Japanese ecosystem including Honda, Suzuki, Subaru, Mazda, Toyota and Mitsubishi plus Mercedes Benz and Volkswagen and Hyundai. I was told that I could announce today that we now have 10 OEMs as part of AGL. Ford has officially signed the paperwork. They are now silver members of AGL. So we have almost 150 member companies and you can see we're split up into Platinum, Gold, Silver and Bronze levels. Whoops, what did I do? AGL, Automotive Grade Linux, we're the only organization, like I said, that's really trying to address all of the software in a car that might run Linux. And our tagline, one of the things that we like to say is if there's a computer in the car or there's a processor in the car running Linux, it should be running Automotive Grade Linux. And we've already got device profiles and some reference devices and applications for infotainment, instrument cluster, telematics, SandCloud is working on a head up display and we're working towards eventually advanced driver systems and autonomous driving. And we're working with Alisa and some of the hyper-advisor vendors to on a functional safety solution. And we also announced, I guess with a press release, although it's been running for a while, we have an instrument cluster expert group, Haraki-san from Suzuki, who's over there, he heads up that expert group and as part of the press release we made today about both, Ford wasn't in the press release. There was two, the paperwork was signed too late for the press release, but we made a press release about the happy halibut release that was just made, 8.0, and the instrument cluster expert group being formed. So we've done eight releases now of AGL and they're named after Fish. So the happy halibut release was the eighth release and coming up we release about, well we have a major release twice a year about every six months and the next one will be itchy ice fish. I don't know if I have pictures of the fish here. So we started developing a single code base called the Unified Code Base. We started this effort in 2015. Basically for all of these different reference devices we're creating, we're working on the same Git tree and we're cultivating an ecosystem of developers and automotive suppliers and OEMs and expertise all using a single software platform and that software platform is all running on multiple boards. We have six or seven different boards that we support and if you came by yesterday to the tech showcase you would have seen the IVI system running on an Intel up-squared board and the instrument cluster was running on a Raspberry Pi 3, so. But those are also, we have those also running our typical big green machine if you've ever seen it that one of the shows runs on a Renaissance R-Car M3 for the IVI system and an Intel middle board max for the instrument cluster. So that's our schedule. Like I said, we just released 8.0. We also just made a patch release for Happy Halibut at the end of July 7.03. So you can see we typically do two releases, two major releases a year and we do patch releases for at least the next six months after that. Typically we've done four to five patch releases after the initial update. We're planning another Guppy release in September and we're planning the first Happy Halibut patch release in early September as well. So the AGL architecture at a high level it's microservices based. We've got security baked in using SMAC. We've got this binding binder concept where the APIs are all individual APIs are binding and then all of the APIs collected for a specific service are in a binder. It'll run on multi ECUs and in fact, IoT.BZH in France is working on a port of the APIs and the binders to Zephyr. So we would like to be able to show that we can run the APIs across different architectures. So like I said, this is more examples. We've got a documentation site with more information about these bindings and binders as well. It basically provides a standardized transport and integration method for all of the APIs. Available binders and bindings include all these on this list. In fact, I probably missed a few because we're always adding more. But these are the major ones including home screen, window manager, audio, a bunch for connectivity, location, media player and signal composers, what we use for CAN and for vehicle buses. We're also planning to use that same signal composer for adding sensors for ADAS or for automated automotive autonomous driving systems. We have an SDK. So a lot of everything that we're doing is based on Yachto. We're currently on Yachto 2.6, which is Thor, Thud. Thor would be better. Thud. And what we wanted is our application developers to not need to know anything about Yachto. So we created this SDK. We have both Qt apps and HTML5 apps available now. We have a web app manager that's available for HTML5 that was ported from web OS, open source edition. That was done by a combination of LG and Agalia. Before we get to the Q&A part, developer resources. So I just listed a bunch of resources you can click on. These are all hyperlinked in the presentation. Where our documentation site is, there's a good getting started guide. There's actually one on our Wiki page as well and it's linked from the Wiki page. There's a good getting started guide as well on the documentation site. We use JIRA for our defect tracking as well as project management. We have, for all of the releases, we have pre-built binaries and source tar balls available. If you don't wanna go download the code, you can download one of those. Build instructions, release notes are available on the Wiki. And we use Garrett for code review. And we use, of course, Git for source code management. And in terms of, if you have any questions, we have the weekly developer call on Tuesdays. We get about 30 to 35 people who call in. If there's something you're having trouble with and you need some help, feel free to pop in on the call and it lasts about an hour on Tuesday mornings, US time. But we get people who call in from Japan as well as Europe. We have an IRC channel. We have a weekly newsletter that I've kind of not done for a few weeks because I've been on vacation and we have a very active mailing list. And then finally, we like to get together, have developers meet face-to-face and we organize about every two months a face-to-face meeting. We typically get 20 to 40 developers at these meetings working on, we have an agenda, sometimes it's a hack fest, sometimes it's more of an architecture discussion, but there's always a variety of topics that are listed. They usually last two to three days. The next one is scheduled next month in Berlin at VW's site in Berlin at the Carmack facility. And then you can see we have two all-member meetings a year. The next one is coming up in October in Monte Carlo. And then finally, members can participate in our CES booth and we'll have a couple integration sessions for people who are working on CES stuff that they might need help with integration on. So because it's a BOF session, mostly I wanted it to be dedicated to Q&A. So I'll open up the floor to questions and I'll hopefully, we have some guys who are here in the front or spread throughout the audience who work on the code as well. So anything I don't know about, I'll make one of them answer. So any questions? So the question was, is there a recommended configuration for getting started? Are you talking about maybe hardware configuration? Well, you can use, I would say probably the easiest way to get, there's a QMU, Kimu, QMU builds that we do. That's probably the easiest way to get started. If you wanted to get started on actual hardware, we, most of the development's been for, most of the developers in testing are working on the Renaissance R-Car M3. Because that's what our green machine demo's been using. But I know a lot of people like using the middle board or the up-squared board from Intel. And the green machine itself is switching to the H3 board this year. We've also got Raspberry Pi support, although that's, Raspberry Pi kind of runs out of memory really quickly. What did I miss? Oh, we've got IMX6 support as well, but that's not officially through NXP. We're kind of doing that on our own. Uboot, we're using, the question was, what boot loader were we using? We're generally using Uboot. It's everything's based on Yachto, and I forgot, recently, SandCloud added support for their Beaglebone Enhanced board. We've also got the Beaglebone Max in there. Beaglebone Black, rather. And I think most companies have found it pretty easy if they have a Yachto BSP layer, pretty easy to slide it into AGL and get it building. Yeah, if you're gonna do the IVI side, you pretty much need to support Wayland and Weston. So if you have a BSP layer for a board that gets you pretty much up to date, Weston support, you should be able to just stick that in and build. There's, I think, instructions now. If not the mailing list, you can just ask, and it's relatively straightforward. I did the IMX61 in a couple days, like a month ago. So it's pretty straightforward for anything that has a relatively good Yachto BSP layer. Maybe you could use the mic, I can't. No, no, don't shout, because it's being recorded, so I'll have to repeat it anyway. Yeah, so you mentioned a couple of companies that are actively participating in the project, and I assume that at this time, there are no active deployment in any car. No, that's not true. So starting in model year 2018 that was in the Toyota Camry, and it's now gone into more of the Toyota line, some early versions of AGL, now it'll be going into some Mazda cars and Subaru cars, and hopefully, Suzuki's working on an instrument cluster, so it'll be getting in there pretty quickly. So it's actually been, so some of the members have been actively deploying it into their vehicles now. But what kind of product? Dan Koushi, our executive director, can, yeah. We had a RAV4 at the, yeah, the Mercedes Vans. We had a RAV4 at the CES booth last year. And what product are we talking about? The infotainment systems, or some? The initial deployments have been infotainment systems. Now, starting with Happy Halibut, or with Grumpy Guppy, I think it was rather, we now have an instrument cluster reference device that you can build, as well as a telematics reference device. And there's been a lot of interest from a lot of OEMs on instrument cluster. So we have an instrument cluster expert group that meets every two weeks. And we're actually driving a lot of the requirements into AGL now, and Haraki San from Suzuki has been leading that effort. I actually have a million of questions, but I'll hold, anybody wanna ask something? Cause, all right, so I'll proceed to another one. I mean, just because it's interesting, like speaking of like the IVI, how would you like compare the AGL against other things like the GNEV projects? Well, so GNEV, we have a single code base. Everything that we do is open and transparent. You can go to our website, our wiki page rather, and see everything that we're doing, see all of our meeting minutes. You can go to our JIRA page, see all the defects. Everything I do is completely open. GNEV does not have a single code base. They have different companies bring their own code base, and they claim somehow they're GNEV compliant. If you wanna know what GNEV compliance means, well, you need to be a GNEV member. So it's not transparent. So GNEV really is not an open, to my mind, they're not an open source organization. They're not really open and transparent like we are. But there are some working groups that they... But there's no single, but BMW might have their own version, and when River has their version, and MentorGraphics has their version. So you can download, you can go to our source tree and download the source code, and that is AGL. There's no debating like, is it a Bosch version, a Mentor version? GNEV compliance is kinda nebulous, whereas everybody, if you have a patch or you have something you wanna submit to AGL, you can submit, you know what, a lot of people will come to me and say, well, why aren't you doing so and so? Why don't you have a full up can message messages from the automotive makers? And basically I say to them, look, we're an open source project. If somebody is interested in doing that, they'll bring it in. And Leon's a great example. Leon was really interested in the Raspberry Pi and even the Raspberry Pi 4 recently. So he brought it in. GNEV tends to be more top down and being driven by their executive committee, or whatever they call it. Whereas we're basically, if you have something and you wanna bring it in and it's a good idea, we review it, we'll accept it, and then we'll maintain that. Okay, so I'll proceed. Yeah. So I don't work for GNEV, I did some help to some companies there, doesn't really matter. But there is a lot of like, obviously there is a lot of interest in combining several operating systems, and there is a lot of like work of several SOC manufacturers on providing iPervisors to enable to actually combine them. Usually it's going to be QNX and something, and usually it is going to be the interest of QNX plus Android, or stuff like that. Now, in GNEV in particular, they have some interesting project that have to do with how to deal with the dual- Oh yeah, by the way, oh yeah, by the way, they stole our way paper. So GNEV did. So we- I don't know and I honestly don't care. No, no, I'm just gonna tell you. I'm just gonna tell you what we've done. So last year we published a way paper. We had, we have a virtualization expert group. I don't know what that is. We have a virtualization expert group that has participation from a number of the hypervisor companies, as well as interested parties. So last year in June, we released a virtualization way paper which kind of laid out the AGL virtualized architecture. And you can go download that. I think if you go to our Wiki page, you could find the link to it. I should have put it on here. And then when GNEV started there, their new hypervisor group, one of the first things they did was they took our way paper and they dumped it into their Wiki. So they actually took a preliminary version of it. So yeah, so GNEV is working on that stuff but they're late to the party. And right now, so the hypervisor group is now focusing, we've been working with the Zen project very closely with Lars and with EPAM. Their EPAM is a member and they, we've had a number of demonstrations running both Zen, L4 and other hypervisors. People showing both, Suzuki for example at ALS, Automotive Linux Summit was showing more of a safety solution using a hypervisor where they had isolated the safety critical parts. And then other companies are showing AGL running in one virtual machine and another operating system running in a second virtual machine. So we've got a bunch of different people who've done hypervisor solutions for AGL. Okay. Yeah. Joanne, empty-handed, womp-womp. But like all the work and like the joint work are like organizations that have their representatives and there is some direction by the AGL project, right? I mean, you don't go ahead and like start a workforce and like a funded project to do, I don't know, virtualization, gameplay protocol. Okay, so we do have funded. So if you go back to, if we go back to this slide, whoops, Ford. So if you go back to the slide, the platinum, gold and silver members contribute a significant amount of money to AGL every year. And we take a big chunk of that money, a significant percentage of that money we take and we plow back into developers. So I manage about six different contractors who are actively working on code for AGL. Now, what's top-down is the advisory board sets the priorities for what we're going to have those developers go work on. The virtualization stuff, we have not funded anything. The advisory board has not funded anything. So all of the work that's been done for virtualization has been done by companies on their own and by some individuals on their own. So we have the L4 support that's available out of the box or the KVM support, rather not L4. The KVM support that's available out of the box for renaissance that was contributed by somebody I can't even remember who. But a lot of all of the hypervisor work that you see done by people has been done by companies on their own and most of it has not been contributed back to AGL. On virtualization. But I will say that every time I go to one of these shows and this one has not been an example, this one has not been an exception. Every time I go to a show or a conference somebody comes up to me and says, hey, we're using AGL to do this. I had no idea. So last night at the tech presentation I had at least two different companies that said, oh yeah, we're using AGL. They're not members, they're just poking around. They've actually got some stuff running. In one case it was a virtualization company, in one case it was a company doing some package management type stuff. So yeah, so it's a combination. We are funding developers, including Scott from Consolco, Scott and Leon from Consolco to do some work. And then some of it is just people contributing. Either their own companies are funding it or individuals. Do you have like an active project that's like run Android side by side with a... No, we do not. This is something that is like on the agenda on the road? No, it's not. Completely not. We would not be able to do that. The Linux Foundation would not be able to sign agreements with Google to do that. So there are companies that have done that, again on their own. I've seen them running at trade shows, but we are not going to do that. What I would like to see is, and what I've asked our companies to do who have agreements with Apple for CarPlay and Android for Android Auto, is to at least verify that they can run it on AGL and then if there's any gaps, give us the gaps in the enablers, then upstream the fixes they need to do that. And so there's a few companies that have been doing that. Yeah, so one of the things that we're doing is helping some of the companies that do like a dashboard, IVI, stuff like that. We sell this protocol. So like one of... I was thinking of open sourcing like some of the things that this protocol has to do with running Android because a lot of our clients really are interested in it. And this brought a light bulb, but I'll just take it offline. I don't want to push anything. Just curious because I'm learning about it. Yeah, I think there was a question behind you. You mentioned some of the work being done around safety. I was just wondering what the scope of work there is. So who's driving it? It sounds like kind of some of the... So there's two paths right now. If you're familiar with ISO 26262, we're targeting ASIL level B, and there's really two paths. We're supporting the ELISA project, and they've got some very long-standing ongoing work that started with OSATL, and we've been attending their meetings and trying to help, trying to work with them to figure out what their path is for certification. But I think they're several years down the road. The other path is, which I think is the more pragmatic and faster and probably better path for us, is the instrument cluster expert group, some of the companies that are working there, will build, or they will basically build, they've started building an AGL-based instrument cluster, and as they work through what issues that they have, because you have to certify the whole device. You don't certify just the software. So as they work through their device and go to the certification authorities, they'll come back to us with a punch list of things that we might need to do in AGL to support them getting their device safety certified. So I anticipate that effort will go much more quickly than the ELISA effort, and we should see some announcements from some of our member companies that they've released devices that are safety certified using AGL in the next, hopefully 18 months. Yeah, thanks. So in my opinion, these specifications, like ISO 26262, they were created decades ago, and they were created at a time when code bases were counted into thousands of lines of code. And the whole approach of those types of specifications are basically you build a system, you pour some in on it, and you never change it. And that kind of mentality is so backwards compared to how we develop software today. And in fact, if you talk to a guy like Greg K.H., who maintains Linux kernel and long-term support, he has data that shows that it actually benefits the platform when you apply patches, apply bug fixes, apply security fixes. The platform actually gets better over time, not worse. So this cement model has to stop. So my view is on longer term, we as an industry need to go to the authorities and say, hey, you have it backwards and you need to change the way you look at software because if you don't patch things, you end up with a vulnerable system. So I think the industry needs to get all together behind Alisa, behind Agile, and get them to change the way they think about functional safety certification. And I think that's part of our agenda to push that concept along with Alisa project. So I was a little curious why, I mean, as an outsider looking at some of the stuff in the project recently, the push for more of this like HTML5 support, that kind of stuff in there, which seems to kind of add to the bloat of the code base in some ways. It definitely adds to the complexity and the size, yeah. I'm just curious, where the real motivation is there? Is somebody really... To not use QT or whatever, but it just seems like if I'm designing instrument clusters or things like that. An instrument cluster wouldn't use HTML5. Okay, so I'm just curious where the... So this is again, again, this is something that we basically, it's coming from our members. We don't do anything unless one of our members is interested in doing it. We're an open source project. So yeah, this has come from LG and then the WebOS or SE community. They had a web app manager. There's been a lot of interest for certain companies are very interested in HTML5 for their IVI systems. The ability to do like a Spotify app or a more commercial app using a web app is really enticing. And also there's not a good... Right now there's not a good open source alternative to QT, so if you wanna show something that's not using QT, it's a good quick and dirty way to get there. It's using the web apps, so. In response to the question about HTML5, the other reason why some places are interested in HTML5, not specifically in the automotive, but in the general display of control systems is because the external entities that they're communicating with are more and more commonly generating HTML5 output that you can then insert into your UI. So for instance, if you have an engine, that engine may put out some very specific metrics and tachometer, et cetera, and HTML5 that you can then embed into the overall user interface. So your IVI may be getting this from your external entities, or more importantly, your infotainment center could be getting that from your IVI as a data source that you're then able to embed inside your display without having to manage that information itself. Yeah, one of the things is, Gali has done some benchmarking on the M3 now, the H2, where it says M3, and there's almost no performance difference between the HTML5 stuff that we have and the QML stuff, so I think a lot of that performance gap has been, it's big, it's big. I don't think I see a vector up there, and I'm just curious, do you think that Autosar is a competitor to automotive grade Linux? I mean, I'm seriously trying to understand how far AGL will go, and do you see it taking over more of the gateway modules? So actually, that was kind of the question I got yesterday during the tech showcase, and that's the question I was discussing about our members bringing something in. So I think we could do that, but so far our OEM members have not shown an interest in doing that, which befuddles me, because I would think that they would be looking for a way to eliminate, we'll call it the vector tax. They pay a huge amount of money to vector. Every car, every, not only every vehicle line, but every vehicle they wanna do, they've gotta redo the messages. I would think that our members would be usually interested, our OEM members would be usually interested in pushing that, and so far they've not been. The CAN stuff that we've done has largely been pushed by Tier IIs and Tier Is, not by the OEMs. I cannot get, I've not been able to get an OEM to agree to give me a message library. I've, having worked for Motorola, Telematics, and Continental in the past, I know, and being very familiar with some CAN requirements in terms of factory requirements and programmability of message libraries, I've tried to push some of those requirements into AGL, but the fact is I'm not willing to really fund those with our development money, because if none of the OEMs are gonna pick it up, it's not really worth our development funds. I wanted to follow up, so I know you have CAN support, but what about like LinBus, FlexGray? We have Lin there. Oh, cool. So basically our HVAC app now runs Lin, and what you'll see coming up in our next version of our demo is, Suzuki has donated some steering wheels and the controllers, and we're adding a Lin controller for the steering wheel as well. So the steering controls that go into the IVI system. So we've got, we've got Lin support in there, we've got CAN, we've got most, but I think, I think for us to go to the next level with the CAN support to get to that vector type, we need that to be pushed by our OEM members. Yeah, it makes sense. All right, thanks. So regarding the AutosR, that question there, it's the AutosR consortium has something called adaptive AutosR now. It's adaptive AutosR is basically a set of libraries that is transporting all the AutosR functionality on top of Linux there. So basically this will be a concept of libraries that can be used for all AutosR applications. So the companies that still use in AutosR can actually reuse their applications without rewrite codes. Yeah, we'll see. I don't know if I believe their story. What? I don't know if I believe their story. We'll see. Yes, I see it running in my machines in my development there. It's not, it's not, it's really going to the prototyping right now. So it's not an history, it's happening, it's official. Sorry, that's a reality. It's my project, a big project right now inside BMW for next year. So it's not a joke. I don't think it's a joke, but we'll see. Yeah, it's there already. Again, it's a closed system, so it. AutosR is closed. Yeah. AutosR is not closed. It's depending on foundation. It's not a different thing. The completely specification is open. The specification, what about the code? Is that a yes or a no? No, the code, of course, each implemented, they actually. So it's not, it's not open source. You can be like, you can have an open spec, but without. And the implementation code is open. It's coming from Adaptive AutosR. If you want to do your implementation, that's usually what vendors do, tier one and tier two. Actually, that doesn't, then it's proprietary. But then, you have the implementation code as long that you're part of organization. It's basically the same idea you say this about Genevieve. So we'll see. Any other questions? I think our time is up, but anything else? Well, thank you, everybody. This was great.