 All right. Good morning, everybody. My name is Walt Minor. I am the community and development manager for Automotive Grade Linux. You can follow me on Twitter at vStarWalt. You'll see a picture of everybody here in the room. You could pick yourselves out. I've been with the Linux Foundation and Automotive Grade Linux about three plus years now and my most of my message today is about collaboration. AGL, I think you'll find, is one of the friendliest projects for working on with the developers. We have a lot of developers who pitch in and help out. You'll find that we were always more than happy to help people come onto the project and we really love working together. We had an all-member meeting last week in Dresden, about two hours away from here by train. We had about a hundred and fifty developers come together. Everybody got a lot of work done, had a lot of really good meetings and really helped advance the project. That's really the message of today. Our tagline is collaborating to build the car of the future through rapid innovation and I hope to show you some of what that's all about. Automotive Grade Linux, we're a non-profit. We're an open-source project based with the Linux Foundation itself and we're really working on rapid innovation vehicle software throughout the vehicle. We're working to build a single platform for the entire industry where an OEM, someone who makes cars or a Tier 1 supplier to that OEM, can take AGL and have about 70 to 80 percent of a starting point for a production project. Our mantra is code first, as with any open-source project, commit early, commit often, and really we aim to reduce fragmentation in the automotive industry by combining the best of various open-source projects that have been formed to work in the automotive industry over the last 10 to 15 years. We're working to develop an ecosystem of course of developers, suppliers, and expertise all using that single platform. Like I said, AGL is really the the only industry, the only organization trying to address all the software in the car. Dan Koushi, who's the executive director of Automotive Grade Linux, likes to say, if it's Linux in the car it should be based on AGL. We've been focusing the last few years on infotainment and IVI systems for the vehicle. We're branching out into instrument cluster, telematics, heads-up display. We're putting effort into functional safety over the next year to get the AESL-B and ISO 262 qualified, so we can eventually add advanced driver assistance or ADAS. products and autonomous driving to our portfolio, and like I said, AGL is a code-first organization, so we don't spend a lot of time on specifications, but that doesn't mean we don't spend a lot of time on documentation, but specifications, as we've seen in other automotive industry initiatives, specifications have led to fragmentation as different companies end up implementing those those specifications in different ways, and there's been numerous examples of this in the automotive industry through the years. So just to kind of give some examples of collaboration within the project, this is the list of the top 25 get-committers so far this year on Automotive Grade Linux. I actually ran these statistics on October 1st, so we've had a total of 2,765 total commits this year to AGL repositories. On our master branch, this doesn't include our release branches that we've had. 60 individual committers have committed code this year, 27 individual companies have committed code this year, and you can see some people take our commit early, commit often, mantra to heart, and they really do that. Others who may have fewer commits on this list are still contributing a great deal of code. They just don't tend to commit as as often as other people. By company, I listed every company that's committed this year. You can see it's a pretty wide variety of companies that have committed to the project, both Tier 1s, Tier 2s, OEMs, ISVs, some other numbers. Over the last, we've been running the AGL, what we call the Unified Code-Based Project for the last two plus years now. In that two and a half years or two plus years, we've had 81 individuals, unique individuals commit code, 33 different companies, and interestingly, seven individuals not affiliated with a member company have committed code as well. So people who just saw what we were doing and wanted to contribute saw something that they wanted to help out on. And then there's another measure this year, and this number is actually a little stale because we've done a release since I did this, but this year we've closed 429 individual JIRA issues. So those we use JIRA for project management and for bug tracking. So that's a mix of defects, new features, improvements, things like that that we've tracked throughout this year. So we're making a lot of really good progress. We release code twice a year. We make formal releases twice a year. Our members didn't like when I was just calling it, you know, version one, version two. They insisted that I come up with some kind of naming system. So after a lot of thought, I came up with Fish. I spent a lot of time researching Fish in alphabetical order and of course appropriate adjectives. This is a lot of my time spent on this. So our next, our last release was Daring Dab. That was in July. We've made a few patch releases since then. Our upcoming release in December for, that's targeting the Consumer Electronics Show, is going to be called Electric Eel. And you can see we released the Daring Dab release in July. And since then we've done two patch releases, O1 and O2. We plan on at least two more through this year. And into next year after CES, Electric Eel, we're targeting for the middle of December. The schedule, and I've got a lot, I uploaded the slides earlier today. So you can go to the schedule webpage and you can get all the slides if you'd like. I have all hyperlinks to a lot of the different topics on here. So you can see on our Wiki page, I keep the schedule up to date. I try to update it every couple of weeks as new things happen. And you'll find much more detail than this. You'll find the opening dates and closing dates for our merge windows and things like that. So I just wanted to give a quick overview of what we're working on in terms of the architecture. We, HGL, we have this thing we're calling, we call the Unified Code Base. We've got these releases twice a year. We're based on the Yachto project. So with every Yachto release, we incorporate their release about three months after they make their initial release. We switch over our master branch to using their release. And then we take that and we spend about six months working on that, adding new features, stabilizing the BSPs, et cetera, so that our release then is about a nine-month-old Pocky release from Yachto project. And you'll see here, we get the, the Yachto project includes our Linux kernel and BSP and device drivers and some of the basic services. Then we add, we add this reference code here in blue. So things like audio control, sound, vehicle to cloud, we have an HGL application framework that includes a service binder concept that I'll get into in a second. And we also include security and some transport mechanisms. HGL also includes some reference applications up here that you can use to start playing with, to create your own apps. And what I find whenever I go to a show like this or to the HGL all-member meeting last week is that companies come to me with all these really cool applications that I hadn't even thought of and they're often using all of these bits and taking these reference applications as something to start off with and they go off and they create something pretty cool with it. So there were some really good examples of that once again in Dresden last week of people using HGL to create SDL applications or smart device link. All sorts of audio applications that we've seen coming out of smaller companies. So it's really interesting to see what people do with this thing. So we have this binder binding functionality built into our HGL application framework. You see here that each of the binders that are interconnected to each other and there's security built in, there's a security context built into each binder so that your applications as they call these APIs then we ensure that only the applications that are allowed to use those APIs or other services that are allowed to use those APIs can do that. Our security context, our security is all built on SMAC and a lot of that work was based on, a lot of the application framework work was based on the Tizen application framework and a lot of the guys who work on that Tizen application framework are now working on the HGL application framework and using a lot of the lessons learned there to help improve the HGL app framework and the HGL binder binding mechanism. So again, I included a link. We have a really good documentation site docs.automotive.linux.org so I included a link here to the application framework binder information so you can learn how to build your own. Also this week, I don't recall if it's today or tomorrow, Scott Murray and Matt Porter will have a talk about building your own service binders in HGL and some of the experience that they've had in building the Bluetooth and audio and radio tuner binders. So there's some really good information available there as well. One thing I should point out about this is when I talk about cool applications that people are doing, Leon Anevi from Consult Go is also giving a talk later today. I guess he's built a robotic controller using Raspberry Pi based on the HGL app framework and the HGL UCB. So that's another interesting talk. You can learn where people have actually made use of HGL. We've also got an SDK available for you app developers or people who want to develop new services on HGL. Here's a link here to the documentation and how to download the app, the SDK and get it up and running. Basically it's a Docker image. We're trying to eliminate host dependency issues. Those still tend to come up. But with our platform developers who aren't using the SDK, what we had found early in HGL was a lot of, excuse me, a lot of Yachto knowledge was needed for app developers. We really wanted to eliminate the need for app developers to have to learn a lot of Yachto and a lot about the build system. I presented this to our advisory board last week. Our roadmap for this year, just wanted to run through the roadmap for this year, what we accomplished and what we're looking to accomplish next year. And really the thing to keep in mind is for anything we're looking to accomplish coming up this year, next year and beyond, HGL has people, we have people that we're funding for development, but also a lot of people come to us and work on projects that they're just interested in. Because I think Linus Torvald said the best way to get involved in an open source project is to find an itch that you need to scratch. We've had people add code to the distribution based on something that they wanted to work on. So by no means are we limited to just doing these kinds of things in the next year or two. So like I said, we released our two, we had our Daring Dab release in July where we planned to release and we're on track to release Electric Eel for CES. Our vision at the beginning of the year was we would have the HGL app framework complete. It's really hard to quantify to complete. So basically we're on track with the HGL, the framework is usable, we've got people developing apps, we've got people using the SDK. So I'll call that a win for this year. We want to have HGL reference apps available in both Qt5, which has been our primary target, and HTML5. We're a little behind on the HTML5 side. It's looking more like that'll be the beginning of next year. All APIs available as app framework service binders. Well, again, how do you quantify all? I'll say that we're in progress. We've got a good number that are already available and a good number that are currently being developed. And we should see all of them done pretty soon. Instrument cluster, telematics, other profiles. Like I said, we want to be in all parts of the vehicle. So we've had to do some rework of our build system, of our Yachto layers in order to enable headless profiles in order to do some more enablement of lower end radios and things like that. So the profiles are ready to go. They're in our build system. There's actually a specific JIRA issue, spec 145. You can follow along all of the trials and tribulations of the group working on that. They're basically ready to go and will be turned on and validated more after CES. At this point, we don't want to risk the EE release with fooling around with the build system more at this point in time. A complete set of documentation. Well, again, how do you quantify complete? I'd say we have our new, we launched the dock site at the very end of last year. The documentation there is, it's in progress. It's always evolving. We need to do a better job of versioning the documentation for the various releases. But I think we've got a pretty good start there. We also wanted to do more continuous integration, automated testing, daily, weekly, event-based build, board testing, and publishing test results. So we've got a lot of activity in our continuous integration, automated test group. If you go, we use Garrett. I've got a lot of links to developer resources in the last few slides here that you can take a look at, including to our Garrett site and our various expert groups. And you'll find that all of our Garrett submissions are built by our CI system. There's some level of validation being done, automated testing being done on each of the submissions. You'll see that we've got for our latest electric eel release candidate. We publish test results for the various boards. So we're definitely on track for this. And I think by March of next year, we'll really have a very solid system. And we're also working with a number of outside open source projects like Lava, like Fuego, like CIP, the civil infrastructure project, and coordinating our efforts with those guys so we can all jointly make a bigger impact in this area. Vision for next year, really, we're seeing a lot of interest in major content providers to bring that content onto the AGL platform. So hopefully in the next year, we'll see people like Spotify and Amazon and Comcast and streaming providers in the US coming on board to AGL and making their apps available to the AGL community. We're seeing a lot of interest in this area already. We've had a number of OEMs that are interested in porting legacy apps to AGL. So basically making sure we've got all that enablement in place and start seeing the first of those apps being ported in 2018. Two releases for next year, Funky Flounder and Grumpy Guppy. Spent a lot of time with these names. Functional safety, advancing the functional safety initiative. We've got a lot of different ideas on how to accomplish this and we just need to invest some time and some resources into getting this done. Our board and a lot of our members, we use Qt5 for all of our, most of our graphics backend, our graphics toolkit. So our board and our members really want to see us move to more of a true open source toolkit. There's some concern, I mean Qt5 is a great tool, don't get me wrong. There's some concern about the cost and production. So they still want us to continue to explore with other consumer electronics projects and a true open source toolkit. This is a much bigger project than just AGL though. So we need to work with other projects to figure out how or what we're going to do. We've been working, I didn't mention it in the vision for this year, but we've been working on a new home screen and window manager services for AGL. We want to, we're getting the first version of that into Electric Eel. It was a lot of discussion last week on exactly how to do that when we were in Dresden. Basically, want to complete that in the first half of next year. Have that all in the system and have all of our legacy apps ported, have all the new apps running that. Chromium-based HTML5 apps, like I said earlier, as we move into running HTML5-based apps, we need something to run the back end of that. So we're working with Agalia on making Chromium available to the AGL community. Continue to evolve our app framework, improving security, lessons learned from the work that we do this year. We're always doing post-mortems with our app developers to try to figure out what we can improve. Working with our security team to figure out what we can improve. Tizen recently released their version 4.0 of their app framework. So what can we take from their security work that they've done? Also improving user management and then using C groups and namespace and new work that's been done in system D, especially in the latest version V235, for using dynamic users for managing power, managing memory and CPUs and things like that. Another part of our vision for next year having, I'll call it a sustainable audio solution. We've been using some pieces of the Genevieve, which is another open source project, using some parts of the Genevieve audio manager. We found that parts of that are kind of inappropriate for app level APIs and for managing the actual devices. It can be very complicated to write plugins to their audio manager. So we've got a lot of work in progress. We call it the HGL Advanced Audio Architecture or 4A. Again, I come up with these really cool acronyms, 4A. And having a video player reference app, vehicle to cloud services, there's a lot of, you know, there's been for many, many years in the US especially, but also in Europe, a lot of telematic services, which nobody would have thought of calling vehicle to cloud 10 years ago. But now that's what we call it. So having a telematics architecture and a vehicle, a standardized vehicle to cloud architecture is very much interesting. And we're forming a new expert group in this area over the next month. Speech to text, text to speech services. Not that we would have a speech engine integrated into HGL, but what we would have a common API where different speech providers could then plug in their engine and our apps could then develop to those specific APIs that we provide. We have an ongoing reference hardware system architecture effort being led by some of our OEMs. We have 10 OEMs in HGL. Pretty much all the Japanese OEMs plus Mercedes-Benz here in Europe, Jaguar Land Rover here in Europe, and Ford in the US. And they've been working on defining what the system architecture of the future is in vehicle for not only IVI, but also telematics and ADAS and things like that. So they've released the initial version of that document and will be continuing to review that and figure out the takeaways from that document that we can use for incorporating that into the software. So just a quick overview. We have these things, I really don't like the name. We have these things called expert groups, but let's call them working groups. You don't necessarily need to be an expert to be involved in one of them. We have six active expert groups right now with a vehicle to cloud expert group coming online very shortly. App framework and security, connectivity, continuous integration, automated test, et cetera. So just a quick overview. Our expert groups, when we formed them, we wanted, we really, and we've stuck to this principle throughout the last four or five years, we wanted them, we didn't want to create a bunch of expert groups just to have, say we had complete coverage throughout the vehicle. We really wanted a critical mass so that we would have a minimum of five to 10 people who were participating in these expert groups and working on these issues. And so what you'll see as I go through these is some of the definitions of these expert groups get a little big. And we're not, we really haven't split them out unless there's been a, again, one of these critical masses that are willing to take on the work for these expert groups. So you'll see the application framework and security expert group takes on a lot of different things that you might not think of immediately when you think of either of those topics. And some people don't even think of application framework and security as going together. So the app framework and security expert group tasks, they've made namespace and C groups are now available to use in HGL. But we really need to work on exactly how we're going to make use of those. So the enablement is there. We've talked about doing some resource management. Recently the system, we're using system D version 232, which is the latest Yachto version. We know that the version 235 has some really interesting features in there for dynamic users and things like that, as well as additional features in the namespace and C groups areas. So we really want to up rev to that as soon as possible and start making use of that. I talked about ties in 4.0 already. Our SDK, we've done a lot of work with the SDK. We've created app templates so that the app developers have something they can start with, learning how to create widgets, service binders with a developer guide, all that's available now with the SDK. And this group is tasked with owning that. More things we'll be working on in the next year or in the upcoming year, including identity and user management, so that you can bring a RFID card and it'll recognize you and it'll change the preferences on the IVI system to yours. You'll have your Facebook account, you'll have your Spotify playlist, you'll have whatever it is that comes with your identity. Key management for app installation and making sure that the policies are all correct and Sinara, consent management, things like that are all upcoming on our docket for this group. The connectivity expert group was one of those that was, again, had a very broad remit. And recently, like I said, we've split that out, some of these out to a new vehicle to cloud expert group. But the connectivity group, I think, now has a fairly reasonable focus, which includes vehicle connectivity, CAN, most, LYN, things like that, network and vehicle firewalls, Bluetooth, Wi-Fi, NFC, and smart device link. So they've actually got a fairly reasonable amount of tasks on their plate compared to some of the others. They've been working on vehicle messaging and vehicle messaging app framework binder so that we can abstract the signals coming in from the vehicle, whether they come from CAN or they come from GPIO or they come from anywhere else. The applications don't have to care about that. Bluetooth, we've got binders available for Bluetooth. We're refactoring some of the binders now based on some of the lessons learned. We've got a telephony binder that's in progress, an NFC binder that's in progress, a Wi-Fi binder that's already available. So a lot of work that's been done by this group already. Continuous integration, automated test. They've been integrating Lava with Fuego so we can do remote board testing for our automated testing. They've really done a lot of work with improving our Garrett Jenkins Lava workflow over the last few months. They've created a web interface for test results, so now that you can, for any given board, any given build, you can drill down into what tests have been run, which tests have passed, which tests have failed, taking a look at the log file for any failed test, things like that. We've been working with upstreaming our fork of Fuego. We have a concept of the lab in a box so that companies or individuals will be able to take our test environment and our test cases and move them inside their firewall and run the tests inside their firewall without having to. A lot of companies are a little iffy about punching holes in their firewall, so we want to take care of that. Eventually, we want to add some static code analysis tools that's been on our plate for a while, but we haven't had a lot of time to look at that yet. UI and Graphics Expert Group has a really big set of tasks that might seem haphazard as well, but they're looking at basically what you would consider for UI and Graphics, which would be compositor, layer manager, window manager, GPU interface, things like that. But we also bundled multimedia, audio, display, audio manager, media, we've got a media, reference media player and media manager, so that's all bundled into this UI and Graphics Expert Group as well. They've been working on updating everything to Waylon 2.0, refactoring the home screen and the window manager, updating the window manager for better secondary display support, as well as updating it to include the ability to have multiple apps owning parts of the display and running there parts of the window. Better focus management for out of focus applications. We do kind of a not a great job always with that. They're working on Waltham for Internet display protocol so that you can have apps running on your IVI system and displaying parts of the parts of a window in the instrument cluster. It's a pretty standard feature these days in most in a lot of vehicles. Improving audio management and configuration. We talked about that a little bit already with the 4A architecture. Adding speech services and chromium of course. So we're looking to bring this vehicle to cloud expert group online in the next month or so, including we need to take a look at the overall use cases, Talmatics, personalization, end-to-end authentication, things like that. Define a reference application, work with some back end providers on how to standardize what the back end expects and then identify any reference applications that we want to develop in that expert group. So as I wrap up here, I just got a bunch of links to our developer resources. We have a getting started guide on our wiki, links to our documentation site, links to our JIRA. The getting started guide will also give you information on how to sign up for you need an LFID, links foundation ID to access our sites, but most of you probably already have one of those so you can get the access pretty quickly. We have pre-built binaries and source tar balls available on our basically through this. It's on our wiki page with all the release notes. Release notes are available on our wiki page, which also includes the links to the tar balls and the binaries. Like I said, we use Garrett for our workflow and get obviously on the back end. So I have about five minutes left. Oh, one other thing to point out. We do, like I said, in the spirit of collaboration, we have any number of face-to-face meetings with our developers. You can see this is the list of what we've had this year. So not only at our all member meetings, which we have twice a year, we had them in Tokyo and Dresden this year, but also various sites hosted by companies within AGL. There's usually specific topics. We have an automotive discussions mail list you can sign up for. Whenever there's a new face-to-face meeting, we make an announcement through the mail list. Anybody is free to sign up and attend these. San Jose was focused on audio manager and window manager. There's been various topics throughout the year. And we have our next one coming up in Yokohama in November. So five minutes left. Any questions? There's one over there. Yeah, that's optional. Yeah, I guess I didn't show the slide for the... We have a virtual... So the question was about hypervisor. In the architecture slide, I showed AGL running on a hypervisor. And the question was, do we have a particular hypervisor? We have a virtualization expert group. If you go to the Wiki, you can take a look at that. They've been exploring a number of different hypervisors. Michelle Palino of virtual open systems leads that group. And he's submitted patches now for AGL to run on KVM. But they're also looking at Jailhouse and Zen and some others. I should have mentioned this. One of the topics in the next month or so is having that expert group kind of take a step back and explore what the real use cases are for hypervisors in automotive and create a white paper and then create a white paper that will release early next year. And then use that to drive the work of the virtualization expert group throughout 2018. So if anybody's interested in participating in that effort, I'll be sending out a call for participation next week or maybe, I guess, this week on the AGL mail list to get people working on that. Yes. That's a great question. I don't have the answer. Oh, I'm sorry. He asked, he says, we're talking about... In my slides, I talked about an upcoming ASLB certification. How are we going to accomplish that with Linux? That's a great question. And that's what we need to figure out. It's a big, big topic. And really, is there a hypervisor there that we use just to isolate Linux? Is there some kind of scaled-down version of Linux fully documented? That's what we're working... That's what we need to figure out what we're doing. Can you repeat the beginning part? The comment was, we wouldn't have any luck getting into a cluster without that kind of certification. Yes, I agree. Any other questions? Can you repeat that one more time? Great question. I should have mentioned that. So Toyota announced... The question was, are there any car manufacturers that have adopted AGL into their products yet? Toyota announced at the Automotive Linux Summit earlier this year that AGL is running on the 2018 Toyota Camry and will be migrating to the rest of their vehicle platforms throughout the next few years. And we expect other car manufacturers will quickly follow. Any other questions? I can't hear you. The question was, do we have a hardware reference platform? We're running... Basically, all of our code is available on a number of the EVAL boards, hardware EVAL boards from Renaissance, from Intel, TI, the value board. What we want to do is use the reference hardware system architecture team to drive a more automotive-looking hardware architecture where we truly have the startup from, say, NAND Flash as opposed to an SD card and have some of the real wake-up circuits in there. So we're working towards that, but right now we are available on about eight or nine different boards, and you can find all those on the Wiki page. Any other questions? We have 30 seconds left. No? Okay, well... Oh, sorry. How many? Oh, yeah. So are there more car manufacturers than Toyota? There's a total of 10 manufacturers that are involved with AGL. Most of the Japanese ecosystem, Toyota Han, Denise Han, Subaru Suzuki, I'm sure I'm forgetting somebody, Daimler here in Europe, Jaguar Land Rover, Ford. So there's quite a few, and I owe Mazda as well in Japan. So I expect that they'll be migrating, we expect that they'll be migrating their platforms to AGL very shortly. Okay then, if you have any questions and you see me around, don't be afraid to ask. There's a number of really good AGL talks this week as well that you can attend and you can ask them questions. Thank you very much.