 Welcome to the presentation. I always get the best time slots, usually the last day right after lunch. So hopefully, I'll keep you awake. So hopefully, I don't know if anybody got to go see our tech presentation last night at the Tech Showcase, but we had some of our demos running last night. And through a couple of the other presentations I've attended, we've had a lot of questions about what AGL is. So hopefully, here, next 45 minutes or so, I'll be able to answer your questions. And if we can't, at the end, I've got some time left, I believe, for some Q&A. So first of all, what is Automotive Grade Linux? Well, basically, we're a nonprofit open source Linux-based collaborative project of the Linux Foundation. That's a mouthful. Focusing on rapid innovation of vehicle software. And our tagline is collaborating to build the car of the future through rapid innovation. And I like the, in this tagline, I like the collaborating part the best. So as an example, I used to work for a tier one. I used to work for Continental. I used to work for Motorola telematics as well. And tier ones, in my experience, never collaborated. In fact, it was always dog eat dog. There's another collaborative project out there called Geneva. And we never saw any real collaboration between the tier ones. We were never incentivized. And the amazing thing about the way we've done things at Automotive Grade Linux is we have tier ones actually collaborating in real time on the same software. So for our latest release, we had a few hackathons or integration sessions in Yokohama, Japan in November and December. And we had 35 to 40 people show up at these events from 20 to 25 different companies. And we had tier ones like Panasonic and Aishinaw and Denzo working on the same source code, sitting in the same room together, getting applications to work, whether it was the navigation app or the instrument cluster or the home screen. We're seeing a lot of really good collaboration. And so it's rapid innovation. I'll show you some of the statistics on the progress that we've made. But it's also a real time collaboration between all of these competitors who are doing things for the greater good of the automotive ecosystem. So goals of HGL include building a single platform for the entire industry, for the entire automotive industry that will benefit tier ones, OEMs, and service providers so that everybody has a strong base from which to start to write applications. And getting the OEMs and the tier ones to that 70% to 80% mark for developing a product that actually eventually ends up in a vehicle. Reducing fragmentation. So there's a lot of different open source projects out there. There's a lot of different proprietary projects out there that people have used in automotive. And there's just tons of fragmentation all over the ecosystem. And you can see that in even an Android with their attempts to reduce fragmentation by having people sign agreements that backporting applications between different Android versions is very difficult. So we're trying to create an ecosystem of developers, suppliers, and experts in the open source field all to create this single unified system. So HGL is the only organization that's planning to address all of the software in the vehicle. As my boss, Dan Koushi, once said at Automotive Linux Summit, if it's in the car and it's Linux, it should be HGL. So we really believe that Linux is an appropriate operating system for all these different types of vehicle systems, including infotainment, which is our primary focus now. But we've expanded. We showed demonstrations at CES of an instrument cluster in a couple different configurations, telematics, connected car. We're looking at functional safety. There's a lot of interest in autonomous driving and ADAS. In fact, I think Intel was showing an ADAS demonstration using one of the boards that we have planned to add to our board support system. We've had remarkable growth over the past year. We now have over 90 members. We have 10 OEMs that are members of HGL, including all of the major Japanese OEMs. Basically, in terms of membership growth, we had over 60% growth in 2016. I think this morning, I approved the 690th subscriber to the HGL mailing list, so the Automotive Discussions mailing list. And you'll see a lot of good technical discussions taking place on that mailing list, people asking questions, people getting help, releases being announced, patches being sent. So it's a really strong, thriving community on that mailing list, as well as other places. So the 10 OEMs that we have that have joined HGL include all the major Japanese ones, Toyota, Honda, Subaru, Suzuki, Mazda, Mitsubishi Motors, Honda. And then some of the non-Japanese ones include Ford, Mercedes-Benz, and Jaguar Land Rover. And we're looking to gain more traction in Europe through 2017. So we hope to see more European manufacturers join us. So this is the eye chart of the 90-plus members that have joined HGL. We have four levels of membership, platinum, gold, silver, and bronze. So our platinum members are Denso, Mazda, Panasonic, Renaissance, Suzuki, who just joined a couple months ago, and Toyota. So we like to say that HGL is a code-first organization. And one of the main things we truly and honestly believe is that specs lead to fragmentation. Specifications without code or specifications without the API written and reference applications to exercise those APIs really at the end of the day lead to fragmentation. In the automotive industry, we've seen things like the most cooperative, which was intended to be really a spec organization that defined not just a hardware or physical layer, but also these function catalogs that were supposed to be common across the industry. And what we saw what happened with those was that the function catalogs themselves were incomplete. You couldn't actually implement a phone, for example, application using the phone function catalog. And so all of the different manufacturers ran off and specified their own proprietary extensions to the most function catalog. And then the catalog itself didn't, because it was just a piece of paper, it didn't specify behaviors. So it didn't tell you what was supposed to happen when you invoked a dial command on the most ring. It just told you invoke this and somehow, magically, a phone call will start. So we found that as a tier one, rather, we found that we were constantly re-implementing these standard function catalogs that were written down, and we could not reuse them from manufacturer to manufacturer. So really, without code, without being code first, and without having code that everybody is reusing across the ecosystem, a spec will only just leads to fragmentation across the ecosystem. So in terms of code first, last year, we had a banner year. We had a record year. We started 18 months ago. We up to about 18 months ago, we were using Tizen IVI as our base distribution. And the advisory board made the decision to move away from that and move towards an HGL-specific distribution. And we call that the unified code base. It unifies the best of Tizen IVI, takes the lessons learned, there, improves upon them, takes some of the Geneva components that are well done, incorporates those, takes the best of standard open source components, unifies all of those, and we create an HGL distribution. So I like to, this is my annual or semi-annual, you too can be famous slide. In the past, I would list every single developer who committed something. But we had such a great year in 2016 that I only included the top 25 committers. We had a total of 1,791 commits. This is just to our master branch. Doesn't include all of the release branches and the sandboxes. 45 different committers last year, a total of 24 companies. And you can see we have quite a variety of different companies and people committing to the baseline. My company, I think this lists all 24 companies that contributed in one way or another. But what's hidden behind this in a couple, what's hidden behind this is that in some cases we have companies that are, Toyota may appear here, I think only four times, my glasses, I don't have my glasses on. Toyota only appears here, yeah, five times. But we know that Toyota is also financing some of these companies to do work for them. So some of these companies are doing work on their own, as well as being paid by Toyota or by other tier ones or OEMs to do work for them. We also know that in the case of Microchip, they only had one developer on the list. We know that they have four or five developers working on AGL and they've just chosen to use one developer, Christian, as their proxy. So it's a pretty good ecosystem now of people using it. Before I continue with the roadmap and the schedule, just one explanation, so you'll hear us, me use the term Chinook or DAB or Blowfish. So we name all of our releases after Fish. It's a very, we have a very large committee that gets together, determines the name of the next Fish, that would be me. And so the latest release that we did last year in 2016, we did the Agile Albuquer and Brilliant Blowfish release. And really for Blowfish, we really put together a lot of our processes, put together the infrastructure for doing the builds, things like that. We showed through Blowfish for the next six months. We did patch releases on a regular basis. I think we did our final patch release to Blowfish in January, I think we had the initial release plus five more. Charming Chinook, our latest release, we released in January, end of December. We've already done one patch release to that and we plan to continue about every six weeks doing patch updates. And then in July of this year, we'll have Daring DAB and then Electric Eel at the end of the year. So I have to get my yield picture still. So I just put together this picture of the schedule through the rest of the year. So people have questions about when we're doing things. As you see the roadmap, we already released the 3.0 release, first of the first patch release to Charming Chinook and we plan through the, at least through the middle of the year, at least six months of support for Chinook through 3.06. We're trying to be, this year, we tried last year and we were somewhat successful, but we're gonna be more disciplined in our enforcement of it, of enforcing, having a release candidate, one where feature development is complete and then start driving down bugs and getting the platform ready and having the platform ready for app developers to start developing their apps at release, at the first release candidate. So we announced a few weeks ago that this would be our schedule for Daring Dab and Electric Eel as we go through this year. I think the RC candidates here and the final release dates you see are the ones that we published and then, roughly speaking, if we go on our current of about every six weeks, we'll see that kind of a schedule for the patch releases of 4.0 as we go through the year. So Charming Chinook, it's the release we just did. We released it on January 6th. We were Yachto-based, everything we do is based on Yachto and we're trying to have a cadence of the Yachto releases come out in April and October, I believe, and following that release, our release will follow about nine months later. So Yachto 2.1 came out in April. We started our Krogoth builds last summer and basically solidified our Krogoth builds through the fall and released it. And the reason we chose this was we could have gone for if we had chosen to upgrade to 2.2 in October, having a three month window between the Yachto release and our release just wasn't practical. The BSPs weren't settled down enough from the chip suppliers. So this nine month, this nine month lag seems to be about the right lag for us. So we updated the Krogoth, our AGL application framework had quite a few improvements go in. We did, I have a slide that shows kind of the demos that we did, but we did a large number of demos for CES and we required that everybody who wrote a demo application for CES, we had 12 different sets of demo hardware with applications running on it. And we required that everybody who did an application use the AGL application framework and use the packaging system and the start and stop mechanisms. And as Stefan does know from our app framework development team stated that either at ELC Europe or at the AMM we had, he said, well, we want everybody to use it so we can have more bugs. And because in order to really test, like I said before, having a specification is great, but in order to test the APIs and to test the implementation, you really need people using it and you'll uncover bugs and you'll make it better. So he got his wish, he got a lot of bugs. Basically, we completed our application packaging, installation and widget installation. We converted over to using system D for app control. We now have a template for what we call application framework service binders that people can use and create service APIs. We now have an SDK for app developers and we created a bunch of reference applications including the home screen, media player, settings, AMFM tuner, HVAC and a few others. So if you stopped by last night and you saw some of those applications running, those were all the reference applications that we developed for Charming Chinook and CES 2017. So the initial release was July 6th, I mean, July January 6th. The first patch update was January 30th. We're using the Chinook branch and our Git repositories for this release, for these releases. We have a wiki page where you can go to and you can pull down the release notes or in the binaries and the source code and the links to repo and Git. It's all on a single wiki page so you can pull down any one of our releases. And by the way, I already uploaded these slides to the scheduling system. So you should be able to download them from the event schedule. And our next patch update is planned for March 8th. So we'll be closing the merch window for patches on March 1st next week and then releasing it about a week later. We rolled out a new documentation website. It's docs.automotivelinux.org. Basically, like we said, the APIs tend to be living things, build systems tend to be living things. They tend to change the readme files. So basically, we're pulling as much of the documentation as we can directly from our source code repos from the markdown files and the source code repos and publishing them as web documents. And then any architecture documents that we developed or we developed or any requirements documents also get published to the documentation site. So as part of that, either the source code or the other documents we're using Git and Garrett for version control and reviews. In some cases, we're using GitHub instead of Garrett, but depends on the document. So board support for Chinook. We have the Renaissance R-Car 2 to the Porter board. We have the Intel MinoBoard Max and Turbot. On this version of the slide, I forgot to, I forgot to include, we have the Intel Jewel board also supported. We have a Kimu emulator that you can download and run on your PC or run it as a virtual machine. We have community BSPs that are basically the best effort by the AGL community. So the reference BSPs are basically supported by the board manufacturers. This slide is actually slightly out of date. I should have included the TI Jacinto 6, the value board as a reference BSP as well. It's being supported by TI. So for CES, we had three major announcements, including that Suzuki had joined as a Platinum member, that Daimler joined AGL as a Silver member, and that we released the UCB 3.0, which is what we called Charming Chinook. We had 12 member demos in the AGL suite, so we had a demonstration showcase suite that over 1,000 people attended. It was a bit crazy that night. We had a lot of press and media interviews. So if you saw the demos that we had last night, they were basically, we were showing single boards with a display. What we had at the CES was a bit more elaborate. This was the official AGL demo, this green one. I didn't pick the color. Microchip, this one was Panasonic's. But we had 12 demos that were very high quality, showing a lot of different, all of them featuring the AGL Charming Chinook software as the baseline. All of them featuring the same AGL home screen and reference applications, and then adding features on top of it. So the Panasonic one was pretty cool. You could actually swipe between these two screens and have applications move, and it was very fascinating. And again, whenever we go to one of these AGL events or we go to an event like Embed Linux conference, and we find someone's doing something with AGL, they always surprise us with what they come with. So that's one of the great things about this is that we find that people are actually downloading it and using it in ways that we never really imagined. And that's the beauty of open source. You just never know what people are gonna do with it. So that was one of the reasons that we held this demo showcase the way we did. I put out a call for participation, asked anybody who had hardware they wanted to show or applications they wanted to show. We got a lot of good responses and showed a lot of different demos. So what I wanted to do, we'll see if this works. I gotta move this. Great Linux. Our goal of AGL is to build 80% of the starting point of an infotainment platform for the car. So an infotainment platform is basically what you see in the dashboard with navigation and all of the features. At the other 20%, our goal is to have the automaker customize that in order to make it look and feel like their own brand. So behind me right now is a demonstration of the AGL Unified Codebase. This release includes several new features that we're gonna be showing you in this demonstration today. First of all, I'd like to mention that our AGL platform now has a new home screen, which is new in this release. It includes a completely new look and feel and has also a completely new application launcher underneath this, including application APIs and so on, which is new in this release. So let's start by showing the HVAC control system. So here you have a standard HVAC control system with driver and passenger side temperatures. And what's really cool about this demonstration is that we're using real automotive hardware being controlled by real automotive software over a CAN bus. So unlike demonstrations of media players and things like that, this is actually real automotive stuff that we're showing here. So if you change the temperature of the driver's side versus the passenger's side, these actuators are actually gonna move based on the temperature differences. And also we also can control the fan speed and when we increase the fan speed, you'll see the fan here, the airflow increase. Okay, let me show you the navigation feature. This is simulating a map and a navigation and let me click on a destination here and start the navigation process. As you can see, we have a simulated driver here, but what's really cool about this particular release of AGL is that for the first time, we're supporting dual display. And so this allows the map and the navigation information to be shown in the instrument cluster, which means less distraction for the driver since it's in his line of sight right there below the windshield. Next, let me show you the multimedia feature. So here we have a media player and we'll start some music. And what's really cool about this demonstration is that we're actually playing this multimedia over a most ring using a most device driver that is completely open source, the first ever open source, most device driver in the world that is hosted by Automotive Grade Lennox. And as you can see, we can change songs and play different media all through the most ring, simulating front and rear speakers. Okay, next I'd like to show you a new feature for AGL, which is the radio application. So here we have a radio application where you can tune to a channel and start playing the audio. But what's really cool also in this particular release of AGL is we added audio management and prioritization. So for example, if you go to the phone application and you make a phone call, the phone app can now take over the audio from the radio, which is a real world application in terms of prioritizing audio in the car between phone, radio, navigation and anything that needs audio mixing and prioritization. So all of those features are now part of AGL as a standard and application makers can now make use of those APIs and the middleware features. Okay, next I'd like to show you the vehicle information dashboard feature. Essentially this is a simulated feature here since we're not in a real vehicle, but you can see that it shows the tire pressure, the speed, your current trip odometer, et cetera. And all of this in a real vehicle obviously would be read off the CAN bus and actual figures would be shown. Again, real automotive software controlling real automotive hardware. What's really exciting about automotive grade Linux and specifically this demonstration is that over two dozen companies have collaborated to this demonstration and to the AGL platform, which is essentially a testament to the fact that this platform is becoming the de facto standard for the industry. Coming up in the future, in the coming year or so, we're gonna be adding several key features such as over-the-air upgrades, integration with smartphones, including protocols like Spark Device Link. And even more exciting is that this platform will be in production, in vehicles on the road, we expect in the coming year or so. And that's really what AGL is all about. All right, Max, you're supposed to make your life easier. I've tried, okay. So, I skipped a few slides here, but I kind of explained the different layers in more detail, but they're in the deck that I uploaded. So, basically, like I said, we're using Yocto. We've had to do some extensions to the Yocto build system in order to accommodate optional features and multiple boards. So, in general, you can see that we've got an AGL core distribution, which is basically meta-AGL plus meta-OE and other parts that come from Yocto. We have extra features that basically are optional features that have been defined by the developers as we go along. And we have, I'll show in a second, how you can enable and disable those optional features. And then we've got the demonstrator code and community development. So, the demonstrator code is basically the apps that you just saw. All the source code for those applications are available, as well as some other applications that we didn't show during the video. And then any community development would be forward-looking features that may not be in the build right now, but we're preparing for some future update. So, pre-built binaries and source tar balls are available on our website at that address. And source code and build instructions are available on our Wiki page. And you can also get the links to these from the release notes page that I showed before. Once we, once you download the code and you want to get building, we had to create a setup script called AGL setup. We're very imaginative with our names. And basically to set up the proper build, to set up the proper board you want to build for and enable the features that you want. So just, if you do a AGL setup that slash H you can get all of the build options for both the boards and the build and the optional features. But just as an example, if you were gonna build the Kimu AGL demo code that you just saw for your Kimu emulator, you would first run that AGL setup script and then do the bit bake. And sometime later, hopefully not too long later, you would have a build that does all of that. Of course we also provide that as a pre-built binary. So more about getting involved with AGL. AGL has expert groups. So we have a, first we have a weekly developer call that I run on Tuesday mornings, US time, Tuesday evenings, Japan time, afternoon, Europe time. Anybody's welcome to join that. The link for that's, I think a little later. And then in addition to that, we have six expert groups that are really worried about requirements and architecture. And the expert groups meet either weekly or every other week, depending on the group. And they're focused around six major areas. Application framework and security, graphics and UI, continuous integration and tests, navigation, virtualization and connectivity. So, you know, expert groups are focusing on the requirements and the architecture and then within the dev call, we have people who are focusing on some of the individual components that may not be covered by expert groups or they're getting the code that's being specified by the expert groups into the source tree. The first four expert groups, app framework, UI, connectivity and CEOT, we defined there what they were doing rather broadly. We didn't want to form, first of all the name expert group is a little bit of a misnomer. It's a carryover I think from some other project, but you don't need to be an expert to be in the expert group. You just need to want to participate in the architecture and design. I personally don't want to be an expert in anything so it just takes too much time. So, if you want to help with the architecture, you want to learn more about the architecture, dialing into one of the expert group calls or checking out the wiki page for that group is a good way to go about it. The expert groups themselves have sometimes overly broad coverage of what they're doing because we didn't want to form an expert group where there were less than five to 10 people who would be participating. So, we didn't want to have expert groups just to have one, just to say we had one. So, once as some of these areas get more people interested in them and they grow to be too big for one of these calls or one of these teams, then we split it out into a new expert group and that's how the navigation and the virtualization teams have come about. So, you can see the application framework guys are focusing on the, obviously the application framework, security, software update and secure update, secure boot. So, some of these topics seem a little off base for that, something you call app framework, but right now it's all kind of piled into one. And each of these groups has a road map that they're working towards. So, the app framework team task list for this year includes, well they did a number of improvements to the app framework and they completed the conversion to system D for Charming Chinook. And then based on the implementation in Charming Chinook and the feedback that we got from app developers, we are working on refactoring the architecture and design of both some of the app framework and graphical rendering components this year to make the application developer experience better and to make the applications themselves run more smoothly. So, the app framework group, in addition to doing that kind of work is completing the implementation of C groups and namespaces, doing a better job or implementing resource management using C groups for things like memory usage, CPU usage, which CPU you're allocated to, possibly network bandwidth at some point. Other tasks they're looking at for this year, identity and user management. So, somebody comes in, if you have multiple people who drive the car on a regular basis and they have a set of preferences, they come into the car, they're identified and the IVI system automatically changes. It's set up so it's showing your preferred applications say or your preferred language, whatever else you might have. Management of keys, storing app installation, first boot app, installing applications on first boot, which actually we didn't do a very good job of in the initial go round. Most of our applications, all of our applications were hard-coded in terms of where they are on the home screen and when they get installed. So, we're revamping that this year. A lot of questions we get about, I have a legacy app, how do I convert that to being an AGL application? So, working on documentation on how to convert legacy apps. And then, consent management, so you have that whole user identification thing. Now, let's say you have a payment system associated with it or maybe some geo-fencing or some other things associated with the vehicle. How to ensure that only the appropriate users can say make payments or can go to particular places. So, the graphics and UI group, they're looking at the compositor and layer manager, window manager, GPU interface. They also have other things on their remit that are maybe outside of what you would expect like the multimedia player and video player, things like that. Eventually, we may split that out into a separate group. Speech recognition, browser engine, all got piled into there as well. So, like I mentioned a minute ago, refactoring the home screen and splitting it out from the window, splitting out the window manager from the home screen. It was all tightly put together in the current implementation of the home screen that you saw. We didn't really have pop-up support, so if you have a phone call come in and you wanna see a message pop-up on the UI, we don't really have that implemented at this point. Secondary display support, you saw some of the secondary display support we have in there, but it's really difficult to manage within the current architecture, so making that easier to manage. And then focus management and how to manage applications that are not currently in focus, so we had some issues with applications that had lost focus on the screen, not being able to do some things in the background, so fixing that. Instead of going through it, I put a link to the latest proposal for all of this. It's a very lengthy one that was given by Philip, our full at our member meeting a few weeks ago, but it's really, it does represent what we're focusing on for this year, so if you're interested in these topics, I highly recommend taking the time to go through Philip's presentation. So connectivity expert group looks at the things you'd expect, Bluetooth, Wi-Fi, NFC, as well as vehicle connectivity, CANMOS, LYN, smart device link to a phone, cloud connectivity, so we have OIC integrated already, open Iotivity, remote vehicle interactions connected car, continuous integration and test is working on getting our, they work on doing the daily builds, getting continuous integration system, keeping it up and running, it is up and running, we have daily snapshot builds, we do release candidates, making all that available. They're working on using Lava for device tests on real hardware, test environments such as Fuego, we're hoping to merge back into our fork of Fuego back into the main line and the other main thing that we need to do this year is publishing our test results on a regular basis and making sure they're readable, human readable and then adding new reference boards as we go along, as we add board support packages, make sure that those boards get built in the CI system and make sure that we do the automated testing on those boards. So for Daring Dab, which is the release coming out in July, we've already updated to Yachto 2.2, the Morty branch, working on some of those app framework improvements that we described, secure signaling and notifications, so basically the making, we already have a signaling architecture in there for getting can messages and most messages into, out of the off of the bus and talking to can and most, but basically working on the security part of that and integrating that into our app framework. If you go to our, I should have put the link in here, but if you go to our docs website, you can see the proposal, the architecture proposal that we're working towards and then having basically making the service APIs secure by adding them, adding service binders to them so that we ensure that only authorized users can access the various devices and APIs in the system. So we're looking at adding the Renaissance Rcar 3 and the Qualcomm Snapdragon 820, possibly the Beaglebone. We're getting, I've heard a lot of questions about Beaglebone and it doesn't sound like it'll be that too hard for us to add, so it's something we're gonna look into. So, and then the kind of the overall goal for the year would be to get to having AGL reference applications available with the backend of the AGL application framework running both Qt 5 and HTML5. Everything that you saw in the demos is running Qt 5.7, but we've had a lot of requests from our OEMs to have applications run with an HTML5 backend. So having the same level of security and the same app framework available for both backends, that's our overall goal, our overarching goal for the year in terms of the app framework, because I wanna leave some little time for Q&A. We have a series of face-to-face workshops that we run for both architecture design requirements and architecture design requirements where we get together and discuss what's happening next in the roadmap and the best way to get there, as well as integration sessions. So, this is the upcoming schedule through the rest of this year. And this again, this schedule is posted on our Wiki page. So if you're interested in participating, if you wanna join AGL, you're interested in participating, there's a lot of opportunities to meet the developers and work together, both on the phone, through IRC and the mail list and face-to-face. So, Q&A. So the question was, are we addressing the economics of keeping the devices up to date over the lifecycle 10, 15, 20 years of the car? So we have a software over-the-air update or over-the-air update built in using OS Tree that's currently in there. It's one of the active features that we're working on. In terms of end-to-end architecture, that question really is, we wanna provide the enablers so that all the pieces are there so an OEM can then go engage with a service provider and have the pieces on their device to have all the pieces there. But in terms of the overall economics, that's not really something we're addressing. It's really that we're just trying to be the enablers for the OEMs. Snapdragon 820 is not a community board. It would be a reference board. We're working with Qualcomm to get that in. They actually, the Qualcomm demo that they showed at CES was using the Snapdragon 820. So they have the BSP where it works. It runs on Charming Chinook. We're just working with them now to get it upstreamed into our repositories. Beaglebone would be community-supported. Do we have an application in the native CAN protocols? So the vehicle signaling architecture we're working on is working to abstract the CAN layer or the most layer in a secure manner so that the applications don't need to know anything about the native CAN. Now, Microchip in particular has been working on native CAN drivers for AGL. The difficulty we have is that the CAN message, the messaging and the vehicle typology is all proprietary for the OEMs. What we have done is we have asked our OEMs in one of our groups, our Cockpit Reference Architecture Group. We've asked our OEMs to provide a typical and worst case network typology in terms of message rates and how many devices we'd have to worry about. And then we would build a simulator, a CAN simulator using actual CAN hardware based on that typology that's something we're working on for this year. So the question was how do we decide what board to support and what is the process for getting a board in there? So we have two levels of board. The reference boards would be an OEM or a board vendor comes to us and says we have a board. We'd like you to add to AGL. We have a list of criteria on our Wiki page that these are the things you need to do. You need to provide us with boards for our board farm, for our CI system. You need to support the BSP. You need to add the BSP. We have a template for how you do that. In terms of community boards, any community member can propose BSP and post it to our Garrett. And there is a template for doing that as well. And we'll work with you to get that community board into the build system. So we try to be completely open and transparent. So if somebody has something they want to do, they're welcome to go do it, come do it. Yeah? Yes, it's based on the Yachto SDK build system. We're working on a Docker container so that you can basically download a container and run your SDK in the container and eliminate all the host dependencies. I'm gonna defer that to... Yeah, he's the man, he's doing that. Well, we're using... The question was what graphics library is being used to interface to the GPU? Whatever the board manufacturer provides is the graphics library we're using. We're not trying to rewrite GPU drivers. We're using Wayland and Weston as our primary backend right now. And part of it, if you go look at the proposal from Philip, you'll see that we are evaluating what the best... We're not using X, we're strictly using Wayland. And what we're trying to do is evaluate which is the best Wayland implementation for AGL. And that's one of the main topics for this year. Right now we're basically using the Qt Wayland. Any other questions? All right, well, thank you very much, everybody.