 Hello everybody. Welcome to the Automotive Grade Linux Birds of a Feather session. I prepared a few slides, not too many. I think these sessions usually are more supposed to be interactive. If you happen to be at the AGL, all-member meeting in Dresden, you probably saw some of these last week. Or if you know what AGL is already, these might be a little bit boring. I'm sorry. So, well, by the way, my name is Walt Minor. I'm the community manager, the development manager for Automotive Grade Linux. So, you'll see my name pop up on schedules and emails and things like that. Automotive Grade Linux, our tagline is collaborating to build the car of the future through rapid innovation. I don't know if anybody saw Dan Koushi's presentation earlier today, but we really are focusing on building a single distribution unified code base for all of Automotive. And our goal is really to be the Linux, the code base that uses Linux. If you're using Linux in the vehicle, we really are aiming for AGL to be that code base. We're a nonprofit or open-sourced, obviously open-sourced Linux-based collaborative project hosted at the Linux Foundation. I work for the Linux Foundation. So, I'm very neutral in any kind of discussions amongst all of our members. We have 132 members now. I don't know if I have that slide on here, but we have 132 members across the automotive industry, including OEMs, tier one suppliers, tier two suppliers, content providers, etc. The unified code base that I'm talking about, we're looking to build a single software platform for the entire automotive industry. And we're even seeing interest from outside of the automotive industry. Really, we're focusing on getting 70 to 80 percent of the starting point of a production project so that someone who wants to develop a device for the vehicle can pick this up and be about three quarters of the way there. And the aim is within automotive to reduce fragmentation. So, there's a single starting point for everybody. And we have basically developing an ecosystem of developers and collaboration across the industry. And we're seeing some very unique collaboration, I think, when you see, you know, five OEMs on stage at Automotive Linux Summit, together promoting automotive grade Linux. Or you go to an integration session where we have a bunch of our developers working together across tier ones. And you see Panasonic and Denso and Aishin and NTT Data MSC, all these tier ones that are normally competitors in the automotive industry working together on a single code base to promote AGL. So, focused primarily, initially on the infotainment use case, moving into now in the last few months, instrument cluster and heads up display, and adding device profiles also for telematics and any kind of headless devices, any kind of straight silver boxes in the vehicle. And what we, what's going on now is, so we've got the device profile set up in the build system for these, for these devices, you can build a complete demo, complete reference box unit, complete reference unit for infotainment for IVI. And now we're working on instrument cluster and heads up display with some of our partners in the ecosystem so that by the beginning of next year, you should be able to download a complete reference app, reference device and reference applications for an instrument cluster and a heads up display system. AGL is a code first organization, code early, code often, commit early, commit often, and our belief is that specifications lead to more and more fragmentation throughout the industry. So, we do have a AGL requirement specification or system specification that was done three or four years ago. We're looking now to update that to kind of reflect the current state of where AGL implementation is and where we want to be in the next three to four years. But it's not a compliance spec. It's, you know, look at it more as a PRD or an MRD type document. We've had within the unified code base, we've had five releases so far. We named them after fish. I spent a lot of intensive time researching fish names and trying to get them in the correct alphabetical order with an appropriate adjective in front. And you can see I spent a lot of time on this. We just released Funky Flounder. I think it was October 8th, 6.0. And we're now working on Grumpy Guppy, which should come out right after CES in January. And so this is a slide that I make every major show, basically to show how many different committers that we've got working, how many people, how many people are different people are working on AGL. So you can see on our master branch this year alone, as of October 10th, a couple weeks ago before I left for Europe, we've had almost 2,000 total commits on our master branch. You can see we've had 59 different people who've committed code this year and 24 unique companies that have committed code this year. And that's just our commits to master. I think I've got another slide that shows the numbers for our release branches as well. And a number of these people on this list are here this week. So you can get to know some besides me and Jan Simon is here from the Linux Foundation as well. But some of the Consulho guys are here and some of the IoT.BZH guys are here as well. Actually, some of the Renaissance guys are too. By company, I just broke just a different way of viewing it. By company we've had, like I said, 24 different companies this year that have committed code. Other numbers, we've got three, as of now, three active release branches. So we've had over 200 commits to various release branches. Since the start of the project, I think we started the unified code base in 2015. We've had 110 unique individuals and 37 unique companies that have contributed to the project, including this year in 2018, we've had 19 new committers. And then question I've gotten a number of times today actually is, do I have to be a member company to work on AGL? And the answer is no, you don't have to work for a member company. In fact, we've had 11 individuals who've committed code who are not affiliated with a member company at all. All of our work is in the open. I've got a couple slides here that list developer resources like where to find our source code, our wiki page, our documentation, and all of that is open to anybody. We used JIRA for project management and we've closed 482 issues this year. And since the start of the project, about over almost 1400. So this is the overall schedule for this year with our various releases. If you go to this page, the schedule is always, mostly up to date. I try to keep it up to date as much as possible. You can see we had our electric eel release at the beginning of this year. We've done four patch releases. We've got a fifth one scheduled coming up. Funky Flounder, the actual schedule here is a little wrong. We had seven release candidates at the end of the day. I think I put the wrong version of the slide up here. And then Grumpy Guppy is now in development. So for next year we've got Grumpy Guppy and then Happy Halibut and Itchy Icefish that are coming up. And somebody kindly pointed out to me today after I've shown this slide a number of times that I got the numbers wrong that this should be seven and these should be eight. So I need to fix that. I neglected to do that this afternoon. Our vision for 2019 and beyond, what we're hearing from our members, especially our advisory board, make AGL production ready. Get to that 70% number. So part of my job is figuring out what that means and we're getting some analysis from our OEMs and our tier ones as to where they think we stand with our against our requirements or against their priorities for AGL, for using AGL in a production system and closing that gap for their top priorities. Web App Manager, HTML5 apps, so far our demo apps have been Qt-based. Now we're moving towards enabling both Qt and web applications. We've got an alpha version of that available in Funky Flounder and we're continuing to work on that through the end of this year and then into next year. Improving, vastly improving our window manager and home screen services, implementing or picking an AGL reference compositor and making that, we have competing compositors now between our native applications and our web applications, so consolidating towards a common way that all applications then talk to the window manager and the compositor. This is a lot of words, but basically continuing to build out our application framework, particularly with an eye towards application lifecycle. We work a lot with LG who earlier this year or late last year open sourced a version of WebOS, WebOS-E, WebOS-OS-E or something like that. We'll basically figure out the best path forward for doing a better job of starting and stopping apps and managing resources of apps that begin to hoard resources. We now have a very high end IVI profile. We found that some of our reference boards like the Raspberry Pi are resource constrained, so coming up with a low end hardware IVI profile that will run on say a Renaissance E3, their low end processor or the Raspberry Pi 3. Improved localization support. Running as non-root. Currently we run everything as root, so we've been working on running as non-root and an updated open source navigation solution. So we have a navigation app available. That's not the best quality. It's very hard to maintain. It was donated to us a few years ago by from Hitachi. Now some guys at ICN-AW and elsewhere are working on a revised navigation app using Mapbox as the mapping software. And we already have in our AGL, we already have the AGL services for geolocation, for GPS, things like that. So and then go moving into speech recognition and ADAS and beyond. We've got a nuance in Amazon currently working on a speech architecture that's been very active. That's available on our on our new Confluence page. Overview of AGL services and how it works. Basically we've got a smack based security system with a base platform and a base platform with the kernel and the Linux kernel and drivers and communications graphics and things like that. There's an AGL application framework that has security baked in. If you want to access a service or if you want to access a device, you've got to use this binder with various bindings attached to it and each one of these runs in its own security context. So basically we're considering security from the ground up. As you want to add new services to AGL, you add a new binder. As you want to add services to a particular binder, you can add new bindings and you'll see if you look in the AGL code base, there's a whole list of available binders that you can currently pick up and use now and install those as widgets on the AGL system. I'm going through this rather quickly so I know again I wanted to kind of encourage discussion at the end. Also here's the list of available binders that we have at this moment including home screen, window manager, audio, a bunch of connectivity, location, media player, media scanner, AMFM tuner, our signal composer for automotive, for CAN, allows you to combine signals that are coming off the vehicle bus and HVAC. We've got an SDK for app developers. The early days of AGL we had a very intensive development process that required a lot of knowledge of Yachto. Now our colleagues at IoT.BZH have come up with this SDK that is XDS based. It's available to be run on numerous of our reference boards and really the key here was eliminating anybody, eliminating your app developers, your typical app developer from having to dig into the guts of the Yachto system to just build an app. All these slides are posted on the schedule page already so you can download all these and get all these hyperlinks. So just a list of our resources for developers including our wiki page, our documentation site which we're in the process of updating and revamping. We realize that there's a lot of deficiencies. There's a lot of information on the documentation site but not a lot of it is coherently presented. So we're working on better presenting the documentation that we do have and then filling in a lot of gaps. The APIs that I just described in these binders are not really very well documented on the website on the documentation site. So improving that level of documentation as well. Taking a very use case-based approach to documentation. Basically we've hired a professional somebody who's actually done documentation sites before. Scott Riffenbach who people may know from the Yachto project documentation is working on this for us. So we've got a wiki, we've got JIRA, we've got pre-built binaries, we've got release notes so you can always see what you can always grab the latest release or an old release. We use Garrett for our code reviews and code management. You can take a look at our Git through our Git mirror there and we have a weekly developer call every Tuesday. I'd say we have anywhere from 20 to 25 people call in most weeks if you have a question or if you need some you need some help with something you're always welcome to call into that or use our discussions mailing list to ask a question. Any number of face-to-face workshops every year where people get together either work on architecture issues or work on code including this just some of the this is the list pretty much for the last third of the year where we'll have people getting together at various places including in the U.S., in Europe and in Japan. And that is it. So I skillfully left us 20 half the time for discussion and really I won't answer any questions because I think I see a lot of people who are in here who are much smarter than me so anybody have any questions or anything they want to bring up I've got a microphone too come on you can't you they're our first winner I'll give you a free AGL sticker after we're done okay thanks um by taking a look at the commits of this year I just observed that there are a lot of Japanese companies um what is your feeling uh if you get the grip on on European car makers and tier ones is there some progress actually so if you go if I'm smart I put it in my pocket if you go back to that list let me go put it back up I didn't I didn't carry it down with me here you can hold on to this and pass the mic to the next person you could be the winner you can get a sticker too okay so so AGL was started by Toyota and had a lot of their um ecosystem join the project very early on and we really were when I started on the project in 2014 we were very uh Japanese centric um but if you look at this list today these first two companies are not Japanese IOT that BZH is based in France Consulco is based in in Europe and the US as well so yeah there's a lot of I think we've done a very good job in the last four years of making it a more worldwide platform we've got Mercedes Benz on board uh we're currently talking to a number of other OE at European and US OEMs about joining so I think I think we're very much not necessarily a Japanese centric organization like we were say four years ago it's a big room what do you use for web applications so it is a cute web engine or or what what do we use for for what HTML applications oh we're using the LG web OS we're using chromium and they're using cute what's their what's their back end now is it currently cute Wayland cute web engine is it where's our AGLIA guys and none of my AGLIA guys are here so uh the LG has been working with AGLIA on getting the web engine stuff ported into AGL and one of the one of the activities here is towards consolidating the getting rid of the getting rid of any cute dependencies that we have on the on the bottom of the stack um on the platform itself so we had a discussion just last week at our old member meeting about moving towards a chromium for the web engine and which version of chromium that we should use and um AGLIA has been working on getting rid of the cute dependencies but why don't you use again that's a cute existing web engine or what it is because then you like another dependency I mean now you have cute now you add another thing like web OS or whatever so the base platform the AGL base platform this stuff none of this has a dependency on cute so if you build just meta AGL by itself there's no cute in that it's not until you bring in the AGL uh demo the AGL demo uh meta AGL demo that you bring in the cute dependencies so if you were the the goal is that if you're building just AGL with the web OS stuff you would only have you would have no cute dependencies eventually the goal is to have no cute dependencies in the demo apps themselves but we're not we're not there yet so then you're planning to use web OS for everything instead of cute the idea is that you could plug in I don't have a good it's a different deck sorry I don't have a good picture of that but the idea is you could plug in you would have your option you'd have your choice you could use cute you could use what you could use web OS for the web app manager or you could use something else you could bring something else in but the idea is that everything is replaceable okay thanks the question back there yeah hi uh currently I work for integration of android on automotive systems like most infotainment systems today we are integrating android so uh what are the benefits of using AGL over android because android also provides the same uh benefits like whatever you have mentioned like it provides all the web services it also provides its own player it has its browser it has its own navigation system voice engine so when when we see android as a OS uh I mean as as a developer I have integrated android so what are the benefits of using AGL over android or why should we prefer AGL over android I think it's mostly it's it's not going to be a technical decision but a business decision so do you want uh there's a company want google to be in charge of their ecosystem uh possibly getting having their hand probably having their hands on all the data that the automakers want to collect uh do you are you going to rely on google to uh continue to support android in the in the car for the next 10 years 15 years uh google's had a history of pulling out of things when they you know they don't when they don't make money or when they when there's regulatory issues uh also china you've got to think about china if you can't you right now you can't use google in china anywhere so there's a lot of business considerations I don't I honestly don't see it as a technical consideration but a business consideration as to why you would pick one over the other okay thanks do you have any kind of support for the flex ray bus not at this moment uh the micro the guys who work on that stuff are from microchip I don't see any of them here but I've asked about flex ray and they keep telling me it's dead so I I'm agnostic yeah unfortunately some of the big premium manufacturers still use flex ray and some systems right right none of our so to date none of our oems have asked for flex ray and when I asked um microchip and some of the companies that work on them on that kind of stuff they say they're not they're not interested in in promoting flex ray into agl so you know being an open source project if somebody brought flex ray in tomorrow if somebody gave me an open source uh solution for flex ray and could it want to hook it up into our our signal composer it'd be very it'd be welcome it's not a problem um but until one of our members or somebody brings it to us that's interested in doing it I don't see it happening it's not on our roadmap right now okay thanks um what do you have or have planned in terms of um vehicle site protocols and connectivity like something like tp isotp on can for diagnostics or maybe j1939 the lower level part of the stack for commercial vehicles um dup that kind of that kind of area for we have a vehicle that I didn't go over our expert groups I think I eliminated those uh eliminated those um slides here but we have a vehicle at the cloud expert group that's looking more at the telematics profile and I've been stressing to them as well as uh some our our can developers of the the the signal composer guys that we need to think about a keyword protocol and and j with those old diagnostic protocols and then how to store dtcs I asked our advisory board about that last week and they're interested in getting including that as part of our um making agl production ready uh right now we don't have support for those directly uh we do have we do have a basic we do have the can so we do have can supported we do have the ability to with this vehicle signal composer to add uh layers on top of the basic can messages but we don't have support for that stuff directly right now okay I will figure out whether I can get in touch with you for that second part of the question um what maybe one more level of detail regarding ADAS what do you have planned for v2x lower end of the stack but uh in particular is there anything on the roadmap right now I think our uh in my querying of our members uh v2x is not really uh a high priority um I know we were looking at the new 802 11 I forget what it is p um but again nobody nobody's shown enough interest to actually go and go off and start adding it yet thank you um can you please explain a little bit more why this switch from qt from q to web applications is so it's not it's not a it's not a switch it's enabling enabling you to make a choice so you can choose which when we get to gg in uh january you'll be able to choose which one you want to use and we we envision that people will want to use actually some so most people who choose the web apps will probably want some mix of the two um but it's not designed it's not so it's not intended to be a replacement it's intended to be um you you the device designer can choose which one you want but isn't the web application a web application much more resource hungry than the qt application in the car that's one of the things that we're we're we're investigating so actually if you go to I think they're showing it this week but if you go to agalia's booth and talk to uh talk to those guys they've been working on the web app manager and optimizing that for the hardware that we have um it is much less resource intensive than it was say a year ago they've done a lot of work on optimizing that um but I think once we have a once we have that into our mainline of code later this year we'll start doing some performance testing and see where we really stand um what I saw this what I saw last week from agalia it looked pretty um it looked almost as smooth as the the native apps that we have and you mentioned uh webOS from LG um web applications written for webOS will they always also run in a browser on the desktop or just just on the car the intention is oh so they I think agalia and some other companies actually have had those running on the desktop I've seen that where they've done development work on the desktop and then moved it on to the under the target so that would be the idea it will not be the code what we have now is we're working with LG and agalia and some other companies they've open sourced all you know web os e and we're in the middle of analyzing which uh components of that we want to pull into agl it's not like we're pulling all of web os web os in I think the next besides the web app manager the next component we're going to look at is um configuration their configuration manager but uh these these html apps web apps designed for use in the car or yes in the vehicle will they also run in a regular web browser on the desktop you're gonna need the you're gonna need this the agl services running as well but yes we've seen these guys doing this is they have run they have run the agl apps on the desktop okay thank you you've used up your questions sorry so that's again about uh web rendering by your qt or web os so when qt you have a cute compositor which works to some extent on top of uh valence but what about web os if it use chromium then you're speaking english but i actually honestly don't know what you're talking about i'm not an expert in this area so i would i would defer to someone else who was an expert who's maybe working on agl like daniel possibly okay thank you here let him answer yeah i can kind of speak to that um settle in he's he's getting settled no there's currently agl has shipped users western um which is quite a relatively conservative but steady and performant compositor our qt is one option it's qt wayland gives you a really good ui um but it does miss a number of wayland features that you need for really good media playback in particular um and also um there are some it's a lot more difficult to do uh some of the automotive apps in the way they want to do window management it's much more difficult to do that on top of qt um and then chromium is a whole another kettle of fish um what whatever you do you end up building quite a lot of your own ui on top of the core compositor be it western or qt wayland or if you um use something like chromo s have uh freon which is chromium acting as a wayland compositor and directly displaying the surfaces but you always need quite a bit of ui and policy and especially for the tier ones and oams that's where a lot of the work and the differentiation of value add or however you want to call it is going to be um is in that that ui and that policy of how you deal with displaying and managing all the different applications and surfaces but it it doesn't it doesn't mandate a particular wayland compositor um you know the the bits of web or us that are released to using qt wayland and as long as it is speaking the same wayland protocols you can exchange that in for western if that answers your question we have uh so this this is one of the ongoing efforts within agl um there's a slide deck that will be available on the wiki page it should be there already or if i didn't put it there it'll be there this week later this week where we discuss kind of the options for updating our interface and our compositor and we have decided now to we have a number of expert groups that we have uh we the system architecture team last week made the decision to put this activity in the application framework expert group um so we should see a lot of progress if you're interested in following it um this this this particular slide deck will be available as well where we went through um a number of possibilities for um improving both the compositor and management window management so um it's really it's an area that that we recognize is holding agl back at this point and we really need a better a better solution so we've asked collaborator work with us and agalia and others to help uh make some rapid progress in this area okay we still have five minutes left if anybody has a question oh we do yes one more um you you um had before on your slide raspberry pi uh three hardware as a low end hardware so uh low end in terms of some of our ivi use cases right now we if you try to run let me go back to that uh if you try to run agl the agl demo platform the ivi demo platform on a raspberry pi you'll run out of graphics memory very quickly um so you run out just run out of memory period very quickly and you'll you'll be less very less than satisfied with its performance so we um are talking about creating a profile a demo profile or device profile that more is focused on those more memory constrained and graphics constrained devices so it will also not perform very well let's say on an imx6 it performs okay on an imx6 depending on which one you pick a smaller one a single core i don't think you'll be very happy with um what were you Scott what were you guys using the double or the quad yeah last year at the amm and i think we had it here at uh at well at elce and prog we had a demo set up with a uh one board with the quad psalm on it imx6 um and that was running the uh free scale uh binary driver and it worked reasonably well on the eel release of agl um having at the time to get back and try and get it working with that at nadeev uh recently but that's one of our sort of back of the burner goals just to try and get that working um but it's it's quite nice hardware actually um it's well supported uh in open source and uh it's it's probably a reasonable target at this point um but uh yeah it's not uh one of the core platforms at the moment on agl unfortunately but it wouldn't be would be nice to get it there to kind of round it out a bit but if you have any other questions myself or matt porter who's probably wandering around somewhere's uh i've played with that a bit so we could answer them anybody else have any questions no well i'll be around all week uh some of the most of the people who answer questions will be here so they'll let us know if you have any more questions thank you