 All right, good afternoon, I guess it's 412, so I guess we could start. So good afternoon, everybody. I just flew in this morning. I landed at 6.30. So if I start spouting gibberish, that's why you'll know. So first of all, an introduction to who I am. My name is Walt Minor. I work for the Linux Foundation on Automotive Grade Linux. I've been with the Linux Foundation at Automotive Grade Linux now for two years. And prior to that, I worked for some tier one suppliers, namely Continental and Motorola Telematics. I also worked for some Linux suppliers, particularly Monavista. So I spent a lot of time in the automotive industry and in mobile devices with Linux in general. And I also like to ride a motorcycle, although I don't own that BMW, everybody. I like people to think I own a BMW. It makes me seem like I'm very hip and with it. And this slide I showed, at HGL, we have an all-member meeting twice a year. And this slide I showed at our member meeting in Munich about a month ago. One of the reasons I really like HGL has been the opportunity to work with a variety of different tier ones and a variety of different tier twos and the collaboration that people are really showing around automotive, which in my past experience, working for a tier one, it's always been a very cutthroat, very dog-eat dog. And you can see, I made this, I took the Git logs from January of this year through beginning of September of this year. And you can see we had a number of different people with commits with 18 different companies represented. And there have been times where we've been integrating software in a room with multiple tier ones sitting down together and multiple OEMs sitting down together all working on the same code base. So HGL really is all about collaboration. And you'll see it's not just tier ones and OEMs on this list, but also smaller companies, some individuals. It's really been a great show of collaboration amongst the members. And if I went back to the beginning of the UCB or the unified code base for HGL, the list would expand even larger and the number of companies would be even larger. So that's really been the thing that I've been excited about within Automotive Grade Linux. So this is my, by the way, at the All Member Meeting. And now here at the MetaLinux conference, I can say this is your You Can Be Famous slide. If you contribute to HGL, even one commit and you'll get on the slide. So you too can be famous. And so today's goal, basically to educate you about what HGL is all about, add access, how to get to our source code and our documentation, and basically generate interest in participating in HGL and show you all the different places that you can participate. Where are you? Sorry about that. So our tagline is collaborating to build the car of the future through rapid innovation. And really, I wanted to show that earlier slide with all the different people who've been committing code to our repositories, that it is really a collaboration. It's not just a few people sitting in a room writing software and throwing it over the wall. It really has been a lot of different people collaborating at a lot of different levels from device drivers to the test infrastructure to applications. And we've really shown a lot of great collaboration in the year and a half or so that we've had this online open code base. And Dan Kaushy, my boss, made the statement that if Linux is in the car, we want HGL to be based on HGL, no matter what the function is, whether it's an IVI system, a telematics system, navigation, working our way into the ecosystem of the vehicle where it is appropriate. And if you saw Greg's talk this morning, this fireside chat this morning, there's still going to be ECUs in the car that are really too small to have Linux. And that's fine. But if Linux is in the car, we want people to think about HGL first. So we really are code first. HGL is a collaboration project of the Linux Foundation. We're leveraging Linux and open source technologies across the board, not just Linux, but all through the ecosystem up into the application space. We're trying to develop about 80% of the starting point for a production project so that a tier one or an OEM could take our code and turn it into a finished product in a much shorter amount of time than they have been. Traditionally, these IVI systems have taken three years plus. I think I finished the project when I was working with Monavista that I had quoted. We finished the project in 2013. And we quoted it in 2009. So to give you an idea of the time span of rolling out a new IVI system. And we really want to shorten that down to half or less of that time. So HGL is a code first organization. We have some documentation in terms of specs. But we're not focused on specs. We're focused on writing the code. We understand that our belief is that if you write a spec, an API spec, and it's just a document that stands alone, the spec and the code, as everybody knows, tend to drift apart. So really, we're saying here's the code. Here's some documents on top of that, but really focus on getting the code done first. We have eight different OEMs that have joined HGL at this point. And you can see that spans from Japan, Toyota, Mazda, Subaru, Honda, Mitsubishi Motors, to the US with Ford, and Europe with Jaguar Land Rover. And we're always gaining new members. We have, at the time I made this slide, we had, I think, 76 different members on this slide. Now we seem to be gaining traction with about a new member every week or so. I think we're over 80. I think we're up to around 85 different members now on HGL. And you can see the level of commitment. We have four different membership tiers, platinum, gold, silver, and bronze. So really, HGL, we really believe we're changing the industry and how car manufacturers, how OEMs and tier ones interact with software, how they interact with their customers, and eventually how customers interact with their vehicles. And how vehicles interact with the cloud. We have members that are focused on all different parts of the ecosystem, from the deep guts of the vehicle messaging subsystem, all the way up through the cloud infrastructure and cloud to, I accidentally said this morning, I saw somebody, it was cloud to ground infrastructure, but the cloud to ground ecosystem. But we really are focusing on all different levels, both of our applications and our middleware. By the way, for the life of me, we had some problems with my slides, and for the life of me, my slides on my screen show up about that big. So I cannot see them. That's why I keep looking up there to make sure what slide I put in what order. So we have, the HGL now has a, we're calling a unified code base. Up through HGL is about, I think five or six years old, it predates me by a few years. And originally we were using Tizen IVI as our code base, and the IVI part of Tizen kind of went away almost two years ago, and in terms of support in the ecosystem. So we decided within the HGL advisory board to take the best parts of Tizen, take the best parts of Geneva, and take the best parts of other open source components, and put those together into what we call the unified code base. We first announced that in March of 2015, so about a year and a half ago. And the first release was at CES in January in Las Vegas. That was Agile Albuquer, we called it. And it's Yachto, Pocky-based, with some HGL specific layers on top of that. And I'll show how we structure the layers in a few minutes. So we first called this HGL distribution, and people wanted a better name. So I, being the creative type on the program, came up with Fish. So we named our releases after Fish. Agile Albuquer was our initial release back in January. In July, we had our brilliant Blowfish release. And coming up in December, in time for CES of 2017, we'll have our charming Chinook release. And D fishes were kind of hard, but I came up with Daring Dab, somewhere I have a picture of one later on. So that'll be our mid-year. So we're basically at every six month release cadence. And along with those releases of the Middleware and the BSPs, we also are releasing demo applications. And at both at CES this year and at the Automotive Linux Summit in July of this year, we showed some demonstrations of the HGL releases. And there's a video available of the CES demonstration on YouTube that shows what we put together. We put together a demonstration that showed our board controlling an HVAC system, a simulated HVAC system with fans and actuators for the vents, as well as a multimedia system, some navigation, a home screen, things like that. And we keep improving upon that, expanding upon that as we go along. The other thing that in terms of collaboration I wanted to mention, at ALS in July, we had released brilliant Glowfish, and we had 15, I think it was 15 different sponsors with booths at ALS. And I was amazed at the number of different applications that people had developed on top of HGL. And I didn't even had no idea. I learned during those days, during the few weeks before, people came up to me and said, here, look what we've done. Look at this application. And they were showing it at Automotive Linux Summit. So what you'll see in a few minutes, what we've decided to do is kind of open up the ecosystem a little more in terms of demonstrations. And we're calling for, I sent out some calls for participation so that people can submit their applications and have them part of the official demonstrator. Because one of the things that we kept getting questions about two days before CES, a week before ALS, was how can I be part of the official booth? So again, if you have an application and you have a cool application, you have a cool piece of hardware, you want to show it at CES or at ALS as part of the official HGL suite, there's now a mechanism for you to participate. And I'll show that in a minute. So as part of ALS, we released our Brilliant Blowfish release. One of the things that we're committed to doing is occasional patch releases, occasional updates. So since then, we've had two patch releases. We just made a second one on Friday, 2.0.2. We are using, with this release with Blowfish, we're using Yachto 2.0. We added some additional BSPs on top of what we were showing with Agile Albuquer. I've got the list, I think, on the next slide. We added the IVI audio manager, which we somewhat borrowed from Geneva, somewhat added some of our own plugins, IVI layer manager, and a significant amount of automated test improvements using Fuego, which I think Tim mentioned this morning during his introduction. So we became one of the early adopters of Fuego. So this was the list of BSPs that we have. We have basically what we're calling reference BSPs and community BSPs. Reference BSPs are fully supported by the manufacturers of the board. They're helping with updating the BSP with integration, things like that. Community BSPs are typically either older automotive boards or hobbyist boards. And they really represent the Agile community best effort at maintaining the BSPs and the applications on top of them. And you can see we've got a pretty wide variety of different boards available. And as we go through Charming Chinook, we're adding to the support for each of these. So, and we're adding additional support for new boards as we go through this process. This is probably a bit of an eye chart. But the qualifications for being a reference board include not just the BSP being maintained by the board manufacturer, but having a documentation and a quick start guide so that you can buy that board, get going pretty quickly, write an application, and have it running in a very short amount of time. A lot of times you get the board and you might want to put some, we'll call it non-standard distribution, Agile would be a non-standard distribution for say a Raspberry Pi. And nobody really tells you how to do that. So, we're trying to put together a quick and easy quick start guide for each of our boards on how to grab our code and get going. Basically get those builds into our continuous integration infrastructure, our automated testing, things like that. So, for the complete list of boards that we have at any given moment, it's on our Wiki site. The Wiki site will also point you to the source, both the source git repositories, tar balls for the releases, and binaries for the reference boards that might be available. So, for Charming Chinook, which is coming up in December, January timeframe, we're looking to have a complete SDK available for app developers. In fact, we're asking that as part of the CFP that we're doing for CES apps, that any apps that we get from developers run in our application framework, which is being highlighted by our software development kit. The Agile compositor is probably not going to happen in this timeframe, but we're working on, we've got someone working on the Agile homescreen reference app in Qt. We're also looking at doing one in HTML5. We're looking at adding device profiles for telematics, in particular. We've had a lot of interest from the community in adding telematics devices. We've got IP network management in terms of, we have Conman in our build, and we're looking to add device management on top of that as well as some reference applications for controlling Wi-Fi and controlling Bluetooth. Another thing we're trying to, we're moving away from is we were using, we have been using a tool called DoorsNG for requirements management. That tool is very cumbersome and difficult to use. There's probably only a few people on the project who actually understand the tool by few, I mean one. The other guy quit. So we're trying to move all of our documentation into something standard that all developers understand, which is create the documentation from using Markdown, and then publish that directly to the web. So we're piloting that now with some of the documents that we're currently creating with the idea that I'll move the requirements spec out of DoorsNG and then to Markdown and we'll maintain it that way. The requirements spec that we have was written about 18 months ago, was released during the 2015 ALS, and it's more of a marketing requirements document than it is an engineering requirements document. It really focuses on what we'd like the AGL to be. And again, because we're code first, there hasn't been as much interest in updating the documents. Engineers don't like updating high level requirements specs. So we're hoping that by moving it to Markdown, we'll at least encourage people to update the document. Just the other tool is just extremely difficult to figure out and not very user friendly. So the first document we're focusing on there is the AGL security spec. So we have a security blueprint document that we have in progress, where we want to at least explain to developers and people who are interested in AGL what it is you get out of the box in the AGL application framework with security. So that's something that's in progress. The, a little bit more on the SDK. So we want that available for all of our reference boards with the published images, including the graphics drivers. As you know, anybody who's working with embedded boards, the graphics drivers, the faster, the better drivers tend to be proprietary and we don't have redistribution rights. So we've been working with our BS, with our board vendors to get redistribution rights so that we can fully publish the binaries and make them available to people. And like I said before, our goal here is rapid innovation, rapid development. And the goal that I stated I put out there is you should be able to sit down and write what I call your Hello Walt application in an hour or less and have that running on the board. And so the first time I tried doing this last year, just prior to CES, it took me with the instructions that we had. It took me three days. So, and it was not a fun process. So getting that down from three days to less than an hour is my stated goal here. We'd like support for both Qt and HTML5 based applications, having an IDE with full debugging supported. Of course documentation, these quick start guides so that you can get going. You can get your stuff up and running in less than an hour. And one of the difficulties we have now is if you wanna use our code, it really does rely, if you wanna modify the code, it really does rely on a certain amount of Yachto knowledge. And the deeper you get into it in terms of device drivers or adding new code, there's really a lot of Yachto knowledge that becomes required. So we really wanna get it so that the app developers don't have to worry about that. They don't need to know the guts of the build system. HGL compositor, so there's nothing really out there on the market in terms of open source that meets all the needs for an automotive IVI system in terms of a compositor. So there are, the Qt compositor is very good. Qt compositor is very good. Qt has a commercial license for a lot of its stuff so we're trying to not use the Qt, reuse the Qt compositor. So ideally we're looking for a member company to donate a solution. We have a member company that has stepped up and is offering one where they're in the process of clearing it through their internal processes to make sure they can actually donate it and hopefully we should have at least a starting point for an HGL compositor beginning of next year. I don't think it'll happen for Charming Chinook because we all know that big companies take a long time to clear things through lawyers. Let's skip this, we talked about network management briefly already. So Daring DAB, which is our next release, middle of next year prior to ALS. We're looking at Smart Device Link which is the Ford developed open source MiraCast type solution. They've open sourced this. It's primarily, their primary implementation is Qnext based but there is a Linux implementation available and they've started working with us on porting that to HGL. And then as we expand our, we've been really focusing on building out our infrastructure, building out the initial application framework and giving people the ability to add APIs to that. So some of the APIs we wanna focus on in terms of reusable components down the road are navigation, speech services, browser engine so that people can come in with a, the applications can have a consistent API and people can come in and plug in whichever solution they want and in some cases like speech or navigation they could be either on board or off board solutions and we like that as much as possible to be transparent to the applications. So again, we're looking for, we had at our all member meetings, we had some buffs there with interested parties and looking for donations from members because we know that anybody who's developed an IVI system already has a speech API. They already have a navigation API so if we could get one that works, donate it as a starting point, that would be the ideal situation rather than trying to start one from scratch. So one of the questions we got asked originally, in fact one of the questions I used to ask before I joined HGL is what is HGL? How do I know what HGL is? So this year through the beginning of the, through the first half of the year we worked through how to describe that and came up with some requirements for what is the HGL core distribution? What are the extra features? What are the optional things on top of that? What are the more future looking features that people might be developing, et cetera? So we came up with this concept of the HGL core distribution. So if in that, that's basically the stable Yachto release that we've decided to use in the case of Brilliant Blowfish, it's 2.1, 2.0 and Charming Chinook, we're moving to Yachto 2.1. It's those reference BSPs. It's the documentation and tooling that you need to build an HGL, to create, build HGL basically. It's test results that are provided using the HGL test framework, which is using Fuego. Fully supported with updates for at least six months because like I said, we're on a six month release cadence. So we've been working through the release management process, we've now made patch releases to Brilliant Blowfish a few times and we have a Yachto layer called Meta HGL that defines that. So basically what we're saying instead of having a complicated compliance spec, we have basically used Meta HGL and that is HGL. So like I said, we're code first. Then we want to provide a mechanism for enabling optional or experimental features. So we developed two layers, we created two layers. The HGL extras basically builds on Meta HGL builds on the core distribution. The features are fully tested and are supported as part of the release. We have device profiles that might be supported through HGL extras. We really worked hard on coming up with a name so of course we called it Meta HGL extra. And we also created this thing called Meta HGL devil which is those forward-looking features that may eventually make it into the HGL core or into HGL extras. So they may eventually be fully supported but right now they're not. They're being worked on by the community and we have a process for considering moving them from Meta HGL development to Meta HGL or extras. We provide daily snapshot builds for all of our boards. We may have snapshot builds for the experimental features that depends on how far into their life cycle they are. We may not. We're basically not providing formal QA for those. The community will do whatever they feel they need to do for QA on those features. And then those community BSPs, those technically would be, I would consider those part of Meta HGL devil but it doesn't really fit that model but that's kind of my way I look at it. And then we needed an environment for the demonstrators, for adding applications, for adding, code that might be one shot in nature. Maybe we're using an application that we're creating an application for CES and we want people to be able to play with that. So we have a Meta HGL demo application. All of our ALS and CES applications are available through Meta HGL demo. So in terms of release management, we're doing twice a year code releases with binaries for the reference BSPs. We eventually may get to a model where we have long-term support. We've had members ask about this, say two plus years of support as, say some of our members go to production with a system. We have that under consideration. At this point, we've had no requests for many of our members to do this yet so we know it will come someday and we're planning for it. Right now, I couldn't tell you which release might end up being a long-term two-year plus supported release. But we do provide daily snapshot builds and for all of our reference BSPs, some of our community BSPs, et cetera. So this in its totality, which is another bit of an eye chart, I'm sure, is all of the different Yachto layers that we have. Not even all of them, there's always more. But this is the basic structure of our Yachto layers for HGL. So how do you get all this stuff? I'll post this presentation today so you don't have to worry about getting these links. Some of them are long. All of our pre-built binaries and source tar balls are available at that link and the latest source code and build instructions are available as well. So you can generally find all of our latest stuff. It's in Garrett, it's in Git. One of the things that we had to do, we had to think through in the last six months, was with the meta-AGL extras and developer features, we had requests from members, oh, I don't want, maybe I don't want to add this particular thing. Maybe I don't want to add the network boot or maybe I don't want to add the application framework. I want to test it without it. So we had to come up with some tooling around optional features. We just released that as part of Brilliant Blowfish. And this basically, if you go to AGL setup, that's our setup script now, and that basically lets you configure the optional features and the development features that you want to run with. And I think, no, I had a list. I must have lost it. I had a list of all the optional development features so that you could, whatever you want to mix and match on top of the initial AGL build, we're trying to simplify that because Yachto does tend to be a little complicated when you want to just add something that we think should be relatively simple to enable to turn on or to turn off. So we have this setup script now developed. So this was the call for participation for our reference apps for basically how can you, if you had a cool app you want to show as part of our demonstration suite, or if you want to just include it in the Meta-AGL demo layer and have the ability to contribute to it, we've asked people if they want to contribute something. So we've had quite a good response from this. I sent this out maybe three weeks ago. We're trying to, there's still time if you have a cool app you're just thinking to yourself, hey, I've got something I want to do. There's still time to submit it. Basically, you send me, there's a little form to fill out in an email. I don't think I put the schedule in here, but basically we have the initial applications are due, the beta versions are due by November 15th so that we can get them fully integrated for the CES demo. We also had probably less, maybe of less interest to people here, but we also had people asking, how can I get my hardware in? So we did a similar thing in terms of a call for participation from harbor vendors and so we've had some interesting responses there as well. So we should be showing a number of new BSPs with the Charming Chinook release. We have, one of my jobs is really to make sure that people are collaborating, people know what to do if they, people don't get stuck basically. So we started some time ago, it was a weekly developer call. Anybody's welcome to call in. If you're trying to work with AGL and you can't figure out something, call in. There's people on the call. We can usually point you in the right direction. We've also got mail lists available. I think I've got a link to how to sign up for the mail lists. And we really, you know, particularly the developers in the middleware and the application space. So we have JIRA available if you want to see all of our, any open issues and you feel like you have something you might be interested in working on. Go look through the issue list and you're more than welcome to participate. So we've got a contribution process. It's fairly lightweight at this point in terms of there's no code contribution agreement or anything required at this point in time. And the process, we try to make it as flexible as possible and we continue to evolve it as we go. We're using obviously Git. We're using Garrett, despite Greg's reservations about it. And the links for finding those are here as well. So garret.automotivelinux.org. We... So we're using Jenkins for continuous integration. We just did a significant amount of work to upgrade our Jenkins infrastructure. We now, we've been for quite a long time, we've had Jenkins builds being done on every submission, code submission to Garrett. Now recently we're moving to, we would only build it for I think the Kimu build and if that worked everything was good. And so recently, John Simon did a lot of work on upgrading that and it's now kicking off builds for all the different reference boards. And if you submit a patch, basically submit some code, it has to be built by, successfully built by Jenkins before we can approve it. And we're moving towards adding automated testing into that as well as just a build. So having some kind of smoke test for the patches as well. So basically every day we have snapshot builds that we make available. Basically binaries that are available for download that come out of Jenkins as well. This is the link for our AGL test framework which is based on Fuego. We have a continuous integration and automated test expert group. They have a call every two weeks. They're very active as well. A lot of our contributors that you saw listed on there are contributing to the test framework or the test cases themselves. So if that's something you're interested in, there's definitely a lot of activity around automated testing and continuous integration. So we have also some running what we call expert groups. I hate the term expert groups because we really don't actually require you to be an expert. I personally have said I don't want to be an expert in anything. It implies too much pressure. So basically we have four expert groups that are up and running. I think they all meet every other week except for one UI and graphics expert group that meets once a week on Mondays. And every expert group has a dedicated wiki page. And from the wiki page you can get a link to the meeting minutes to their project backlog in JIRA to their roadmap. All sorts of good stuff from there. And so the first one we have is the app framework and security expert group. So they're in charge of obviously or they're working on obviously the application framework and security. But then you'll see the main topics I listed for each of the expert groups are in green. The breadth of some of the expert groups is quite large mostly because we didn't want to form a lot of groups with only one person or two people that were interested. We wanted to have some critical mass to each of the groups. So we kind of bundled stuff into the expert groups that maybe don't belong there. And as we get critical mass in a particular topic we will spin off a new expert group. So you can see the app framework also has things like diagnostics and secure boot which may eventually get spun off. And for each of the expert groups I included a link to their wiki page so you can quickly find them. We have UI and graphics and this one I think has the truly strangest mix of things. It's got not just UI and graphics like the compositor and layer manager and GPU interface. It also has multimedia, the media player, browser engine, speech rack, navigation, you name it. So kind of the separation here was the app framework guys got the core infrastructure of the application plumbing so to speak. And the UI and the graphics guys ended up with the applications themselves is kind of the way it fell out. We have a connectivity expert group. Again, actually there are green stuff I should move some more to their green stuff up there also looking at Bluetooth, Wi-Fi, connected car and remote vehicle interactions have become hotter topics within this group. So this is a pretty wide ranging group from guys like Microchip who are interested in CAN and most connectivity to other people who are interested in cloud connectivity so it's a really diverse group of interests that eventually probably will get split into some kind of subgroups once we get more critical mass. So this is our continuous integration an automated test group. So that was it for my slides. I think I still have a few minutes left for questions. And Jan Simon did you have a question? Five minutes. So any questions? So what I was thinking while you were talking so if I have an IMX board and a touch screen and I want to hack install an infotainment system in my old car how does AGL help me in terms of interacting with the car as opposed to other distribution? The bottom line is what we want to have is the plumbing so that you can talk to the car in terms of a way to talk to the CAN bus. I highly doubt we'll have messages or messaging available for specific vehicles. You may have to go figure that out yourself and plug it into our system. But I do know somebody who's done that a guy that I used to work with a continental grid unit based on an old IMX 35 board and plugged it into his car so it can be done. I know some guys have done it. So we'll have the basics of the applications available. We'll have at least the plumbing available to talk to CAN. We probably will not have the CAN message sets for particular vehicles because those tend to be very proprietary and nobody wants to give those up. The way the automotive ecosystem works is the tier 1s are usually responsible for delivering the final product final IVI system. So some combination of the tier 1s and the OEMs. But then enabling an ecosystem around that so that people can jump in and participate and there's a whole tier 2, tier 3 ecosystem that's out there already. Being able to move from one IVI system to another today if I want to move from if I want to work on a Mercedes system this week, this year and move to a Toyota system next year it's a completely different environment and what we want to do is normalize that throughout the ecosystem. Thank you. Someone in the back. I didn't notice anything about safety in your slides are you avoiding safety domains at this point or is that in plans for the future? There is a functional safety there is a group looking at functional safety in ASLB and ISO 26262 within AGL but it has not it hasn't bubbled up to the top of the list in terms of where our code has been focused. You mentioned that as kind of fusion of Genevieve and AGL and all the other things but how do you coordinate your roadmap in bringing frameworks bringing in APIs with Genevieve is there any coordination? There is no formal coordination we are not Genevieve members we do have members of AGL that are also members of Genevieve and we have incorporated some Genevieve components like IVI shell and some of the audio manager components if one of our members is interested in bringing Genevieve component into the AGL ecosystem by all means bring it over but right now we don't have any formal coordination I call into the Genevieve because some points of the roadmap I've seen they look pretty much like things we have also seen in the Genevieve roadmap maybe a couple of months or already years ago like the navigation there's a navigation API and we've had members ask why don't you use the navigation API from Genevieve we're not AGL specifically it's not a Genevieve member so I can't just go grab the navigation spec and pull it over so what we've said all along is if you're a Genevieve member and you're interested in bringing Genevieve components in bring them in that's really how we're looking at collaboration it's hard for us as non Genevieve members to get access to everything behind some of their firewalls no more questions ok well hopefully I didn't spout too much gibberish in my semi delirious state thank you all and enjoy the rest of the week