 Oh good morning or nearly afternoon. My name is Walt Minor. I work for the Linux Foundation on Automotive-grade Linux primarily doing develop developer management community relations things like that So I'm here to introduce Automotive-grade Linux and why it's changing the way automotive manufacturers build and manage software. So just a Little bit about my background before I came to the Linux Foundation to work on automotive-grade Linux I worked for Motorola Automotive Motorola mobile devices Continental automotive and their connectivity and infotainment group and then I worked for Monavista's automotive group and helped Bosch launch the Cadillac Q program So I've seen a lot of different OEMs and tier ones in action over the years and They the culturally these guys don't they don't share there's never been an incentive to share that it's a it's a dog Eat dog especially among the tier ones getting that work from the OEMs and so It's interesting in the AGL that this is the first time I've seen tier ones and OEMs cooperating with each other and working on the same Software sitting in the same room at times last year I was in Yokohama before our about six weeks before our CES demo in Las Vegas and we had about 15 developers sitting there from Seven or eight different companies including Denso and Panasonic and Toyota and Pioneer and to see Really these these dog eat dog competitors sitting there working on the same piece of software Working towards the same goal really to me brings home the fact that AGL is really about collaborating to build the car of the future Amongst these competitors and doing that through rapid innovation So that's our tagline, but I really do believe that that's what that's what we're accomplishing within within AGL and within these companies Dan Koushi is the general manager for automotive grade Linux. He's my boss and I wrote down this quote from automotive limit Linux summit last year in Japan If Linux is in the car, we want it to be based on AGL no matter what the function so we're the only organization that's really trying to address really planning to address IVI or in vehicle infotainment instrument cluster telematics HUD various control systems in ADAS with Linux and In my own experience, I've delivered with tier ones and with tier twos. I've delivered IVI systems telematics systems and other control systems All based on Linux to various tier ones and OEMs. So it can be done AGL is changing the future of driving. We have eight major OEMs now that are Working with us that are members of AGL including they're all listed here but especially Toyota has been a very long time member as well as Jack Jaguar Land Rover and This year we've had Ford Mazda Subaru and Nissan take on larger roles within AGL So it's been a very exciting time of growth. We have As of the time of this slide, which was back at ALS time We had 76 members since then we've had four or five members join as well So I didn't get a chance to update the logos on this slide, but we have about 80 or 81 members now and We have five platinum members Two gold members and a large number of silver and bronze members within AGL So really we we're changing the industry creating a new software development methodology for For automotive across automotive using open source Jim Zemmel the other day in his keynote said that Linux represents the greatest collective investment in collaborative software in the history of the industry and we're leveraging that in AGL We are we really are changing the way automotive manufacturers build manage and treat software as opposed to Everybody trying to build their own closed box trying to collapse We're collaborating amongst tier ones and tier twos to bring that software across the industry And we will change the way Consumers interact with their vehicle the way OEMs interacts with their design process and their creation process of the Vehicle and the way vehicles interact with the cloud as we bring IOT and open connectivity features into the into the ecosystem AGL is bringing a standardized open operating system and application framework That's not under the control of any one company within the eco within the within AGL We have a lot of we have participation across the board. We're very much a code first organization people have been bringing in code getting it accepted by the community and Really collaborating amongst the various companies on the common bits of software and that collaboration is is Really enabling companies to develop their own applications and with their own look and feel I've seen this I've seen this at AGL or at ALS I was really surprised at the number of different companies and the number of different applications that companies had written I really truly had no idea that some of these some of this work was underway and they were showing some really Fantastic applications that based on the AGL's ecosystem in the very short time. We've had it available One one question like one question we get a lot and this is really the only place. I'll address it is you know, there's another Open-source collaborative project called Geneva out there. That's been around since about 2009 and Really AGL and Geneva. We're collaborating on software components Where it's appropriate Geneva has a much different Governance model it's very much bring your own platform. They've got a very detailed compliance spec there's multiple different Instances and implementations of the Geneva software even within Geneva. They've got multiple different baselines AGL is a single baseline a single distribution one code base we're building a complete distribution including middleware and an app framework and The idea is that the OEMs and tier ones and anybody else We'll use the same we'll use that same software base as their starting point For their products and they'll use they'll be able to differentiate based on that So we really are organized and we run like us I hope like a standard open-source project and I'll show you some of the ways that we do that About well, it's been about 14 months ago at a at the Automotive Linux Summit in 2015 in Tokyo and in July of 2015. We announced that we would start collaborating on a unified code base and We made the first release of that unified code base in January as part of our CES Demonstration in Las Vegas and the goal of the unified code base of a GL is to bring the best of Tizen IVI, which was another competing open-source project. That's more or less gone defunct Genevieve and other open-source bits into a single code base that the entire industry could use and collaborate on Collaborate around We're really aiming to reduce fragmentation and focus on innovation and bring new features into the automotive space and the one one real differentiation between us and say Tizen was we're using Yachto and Paki at the time Tizen was using Open build system OBS So we're bringing together the best pieces of what was out there and what's out there in open source and putting them together And making them work together as part of the a GL unified code base We have a I'm not going to show it here. We have a video of the demo from CES the excited thing about that We got a lot of feedback from longtime Genevieve members. We put this together in about four months Late last year and we had not just the usual here. Here's the here's a board Here's a display, but we had some real open We had some real automotive components in there We had an agent a simulated HVAC system with fans and actuators for moving the doors of your Of your air conditioning and your heating system and we were able to we had a most ring doing 5.1 audio And you can see all that on the video We we put that together in a pretty short amount of time we had 14 different companies that contributed code to that effort and a number of different companies that contributed to the hardware build as Well, so it was very exciting to see that come together We continued that we extended that demos that demonstrator for automotive Linux summit we showed that in Tokyo last month and We'll continue to build upon that We've added more automotive type hardware to the to the demonstrator. We now have a BMW style iDrive controller that were we've added And we were adding we've added a rear rear seat display so we can show video in the rear seat as well as the traditional Navigation and multimedia and other applications in the front seat so We also extended the ALS we also extended the number of boards that we support we were using the we've been using the Renaissance Porter board Which is the our car m2 board for our demonstrate for our main demonstrations, but we found as we approached ALS in January or July that a number of other companies Had boards that they were running a GL on including ti and nxp And then a surprising number I think we had nine or ten different companies with different Homegrown apps that they were running on top of the a GL distribution everything from somebody a company that was running a Mirrorcast type application where they had a a smartphone and they were showing exactly the same thing on the main display Of the vehicle as they were on the smartphone people adapting their own ui's to the a GL distribution It's very exciting to see a lot of the a lot of the progress that people were making with the code so one thing that People demanded was that I come up with a name for the releases because it didn't like things like ucb 1.0 so I of course came up with fish so The brilliant blowfish release we just made So that was the 2.0 release. We made that in July Charming Chinook Chinook is a salmon for those of you who don't know Is coming out in January and I'll show a little bit more of the the roadmap and what we've accomplished We released brilliant blowfish in July That has that uses Yachto 2.0 as the baseline and as I said, we were using we were using Renaissance is Porter board as our main board in the initial release and the agile albacore release We added Some additional BSPs. We have Kimu support, which we've had from the beginning We added an audio manager layer a better layer manager and Automated test improvements to the to the release We also have the initial version of our application framework in there and some better vehicle messaging Vehicle signaling as well So in our in our build system We now have reference BS I'll explain that what we consider a reference BSP in the community BSP in a second We have reference BSPs from Renaissance and Kimu as well as the the minnow board max from Intel and We now have other BSPs that we've added we call them community BSPs because they're basically their best effort by the community including BSPs from NXP From the Jacinto 6 from TI the Qualcomm Dragon board Raspberry Pi and We've had interest expressed from a number of other companies to add their boards either as community BSPs or From some of these companies like NXP and TI to upgrade their status from community to reference boards So when we when we call it won't when we consider something a reference board for for AGL This is I know this is a little wordy and might be hard to see but The BSP is available as part of the core distribution It's a BSP that's actively being maintained by the Silicon vendor or the board vendor We've got a we've got documentation and a kickstart guide available so you can get the code downloaded from our website or as a Pre-built binary get it on to the board get it running very quickly We'll have an SDK released and maintained We have the manufacturer supplying at least two boards for our continuous integration team and automated test infrastructure you'll see daily snapshot builds available for those boards and We are working with the companies to set up test and Qa Remote nodes so that we can we can those companies can both provide some internal resources for testing the boards And we can access the boards remotely So the community boards may be hobbyist boards like the Raspberry Pi They may be older automotive specific boards that are no longer sponsored or maintained by the manufacturer of the board Generally, they'll be best effort by the AGL community to continue the maintenance of those BSPs and we may have a featured be a community BSP that's Proposed by the community and designated by our system architecture team We're still working on what exactly that means, but we would provide probably would probably provide some more resources for testing and validating that BSP against the AGL release and a complete list of all the boards that are available and where to access the source code and Download the binaries is available on our wiki site that I have listed there And I'll have all these slides uploaded to the Event page right after the presentation here Coming up in January. We've got our charming Chinook release That we'll have we're upgrading we're in the process right now upgrading to Yachto 2.1 Which is the version that just came out in May We'll have additional reference AGL apps with an AGL compositor Home home screen reference app available in both cute and an HTML 5. I guess I can't spell HTML We'll have a device profile definitely for telematics as well as IVI We may have one for instrument cluster in ADAS where that's still to be determined Our IP network manager con man is already in the build. It was in the the brilliant blowfish release, but we'll have some reference applications on accessing the connection manager and Device management profiles built on top of con man in the in the January timeframe as well We added smack as part of brilliant blowfish and as part of our initial application framework so we're working on Hardening that and and making sure we've got the the correct configuration for smack Based on our requirements, and that'll continue to evolve throughout this year as we get to the charming Chinook release And we have some work that we're carrying over from the blowfish release that we didn't quite finish Audio manager plugins for pulse audio. We have some available already In the blowfish release we'll be adding more We'll be completing our security Specification so exactly what a developer or an OEM can expect from HGL as part of the security as part of the application framework What kind of application lifecycle? Can you expect what kind of security? Can you expect in terms of? automotive bus isolation We're aiming to we're aiming to finish that security spec in the next month We have an AGL all-member meeting coming up in Munich in two weeks And we'll be work continuing to work on that and hopefully we'll have that available as a an alpha version coming up in the next month or so so We're working on getting a software development kit out there We want to have it available for our reference boards with published images that includes the graphics drivers The graphics drivers have usually proven to be the sticking point. There's usually closed source and Have click-through licenses that are difficult for us to redistribute, but we're working with our Our members and our board suppliers to be able to redistribute those graphics drivers into in pre-built binaries And the goal that we've set out is we want to be able to have a developer be able to download the code Have an app have the board on their their desk Be able to download the SDK and write a hello world application and get it on their board And run that in less than one hour My personal experience with this was in the Agile Albuquerque timeframe that was about three days of painful downloading and building and going through the process and Really to get from three days to one hour. I think will be a fantastic achievement and right now we We're down significantly under under under a day, but we're not down to an hour yet so How is the code structured? So we wanted to we want people to be able to readily determine what The question we get it. We get asked it frequently. It's okay. So what is Agile? So we wanted people to be able to know what is you know What is the the core thing that it is that you need to have in your box in order for it to be considered Agile? so we We created a we created a layer called meta Agile that in the Octo that builds upon Pocky and Has the Agile reference BSPs included? Any additional Agile code in terms of middleware above and beyond Pocky any tooling any build scripts that we have that are specific to Agile We have excuse me the test results are we have it we have an Agile test framework. That's based on the LTSI Fuego test framework. We have Test results that are based on that that we can provide and we'll we'll base it. We'll fully support that with Updates for at least six months. So the brilliant blowfish release came out in mid-July We've had our first patch release already 2.0 point one and we have another patch release planned for next week So we are supporting that with with fixes and We'll continue that for until at least the the Chinook release comes out and probably a little longer beyond that then we needed to we need a mechanism for enabling optional and experimental features because one of the Great questions that came up or that's come up amongst our members is you know this application frame you're working on It's interesting, but I don't want to use it. I want to use my own so Can we make that an an optional feature and can we can we ensure that you can choose those optional features that you want to build in your specific environment, so we had to we had to do a little bit of work on Creating a mechanism in both the octolayers and in the build system so that you could pick those optional features that you wanted So we have the a layer called meta Agile extra We're providing the app framework device profiles and things like that as part of the meta Agile extra layer and I'll show in a minute how you can select the various optional features the extra features that you might want But there's also in addition to that Community development so the typically the extra features will be the features that are Officially in our roadmap officially being supported by the Agile Advisory Board and the Agile membership, but we're also finding that there's people who are building Features or building Packages on top of the Agile build that they want to contribute and we needed a place to be able to build those and Share those so that people could work on them together and collaborate. So we created this Agile meta Agile Devil or developer layer We have snapshot builds daily snapshot builds that we provide for the for meta Agile and meta Agile extra We may at some point provide some snapshot builds for the community layers Right now. We're not but we certainly could think about it. We're still expanding out our our CI infrastructure and being able to handle more builds. So we will be able to do that in the future in the very near future These may be community BSPs that don't have official support would be in that layer and so it's It's really allowing Some companies and some some individuals in some cases to build on top of Agile and Collaborate with others who might be interested in there that area of x that area of Expertise that they might have or that area of interest that they might have and then finally from the beginning We've had this this area called meta Agile demo for the demonstrator code so you can all of our demonstrators for ALS for CES for anything that's upcoming That's all available for download. You can download that and use it you build it and use it We're providing binaries in some case in most cases as well. So Really the Agile demonstrator is code is really intended for kind of one-shot Demonstrator type uses usage in some cases. We've built upon the we know one demonstrator into the next demonstrator But it's provided as is But there's some interesting stuff going on there as well So like I said, we're release management. We're providing a release twice a year a full release twice a year as well as patch releases on a regular basis For the core distribution and extra features features will basically provide all all the code and tooling with test results The community features and the Demonstrate the demonstrator apps will be provided as is We may as Our members the turn to using Agile production There may be a use case we can see for longer term support for a given release That'll be determined by the advisory board as we move forward But at this point, no none of the releases have been selected for Longer term support because we're still in the the build out phase of the of the software So this is just a summary of the Of the octolayers that I was describing as we went through here. We we also created in in meta Agile A meta IVI common layer That's a what we're what we're intending to do there is to allow somebody like Geneva to come in and build their Geneva code on top of Agile by providing a common layer that between meta IVI common and Pocky they could then build on top of that and and have their Geneva specific stuff and Still be built in the same fashion off of off of Agile with the same BSPs and the same other base code so To find the code We have pre-built binaries and source tar balls available at that on our website I'll basically I'll I'll update that why I keep updating that website whenever we have a new release and Then you can find Instructions on how to download the latest source code From from Garrett on our wiki at that at that address and that will list that by board and then the build options like I had said we We didn't really have the tooling for Being able to build out the extras or the Optional features so recently we came up with a we had a Script we recently revised our script for selecting the features and if you once you have the repo set up The instructions are on that wiki page that I just pointed out to you You can run the Agile set up script with the the dash help dash H And it'll give you all a list of all of the options that you have for various extra features or machine support that you might want and As an example if you run that Command that will build you the The Keymoo version of the Agile demo that we showed last month that day less But you could also run you could also build that for the Porter board for any for the minnow board max There's other optional features that you can run And they're all listed in that that help file as well as on our wiki We've been trying to document keep the keep the wiki up to date, but as you guys know developers don't always update the documentation in a timely fashion, so And there's also the usual Readme.md files in the in the repos as well so this is just another summary of of what we just went over in terms of What's available in terms of QA and release support and daily builds for the different for the different yak doh layers so I know you're all excited about automotive. How do I get involved? So we have a wiki site It we try to keep it up to date. I think we're doing an okay job of that We have a single sign-on using Linux Foundation identities. This was a recent change We used to have a separate Agile identity, but now we're managing it all through the Linux Foundation identities Basically the single sign-on gets you access to Jira get Garrett Doors NG which we're using for Requirements, and I'm we're trying to deprecate and the Agile wiki so you can you can view you can view any of those without the account you can Submit issues in Jira you can submit defect you can submit patches in Garrett, etc Or update the wiki if you have the account So you don't need the account in order to download or see anything you need the account if you want to Purchase if you want to participate you want to add something We have a mail list. It's a You can sign up for the mail list at that address We also have a number of people on IRC at hash automotive So if you have any quick questions you want answered There's usually people hanging out there who can jump in and answer them Just a quick couple slides about our mail list. So we at the end of In the 2014 is when we really we're about to make our first release the mail list was kind of stagnant we had a hundred and ten percent growth last year in 2014 on our main mailing list, which is the automotive discussions one and So we've and then even This year we've had another 25% growth so we now have five hundred and seventy nine subscribers Compared to just over two hundred at the end of when we first started this effort So a mailing list traffic you can see automotive discussions was pretty poorly Used initially we only had 81 messages in all of 2014 and That's now grown quite a bit. So the traffic should double again this year in 2016 So there's a lot of interesting things going on in the mail list in terms of I Send out status updates People send out, you know requests for information in terms of how do I do this? It's the usual The usual stuff that you'll see on a mail list, but it's become it's become quite active and I think I Think people there are also ready to jump on things and help out If you have any kind of problems with building or we're getting things to work we need we have a weekly developer call every Tuesday at 1300 European time or UTC rather and The information is on our wiki how to dial in anybody is welcome. I run that call every week we Need This is my shameless my shameless plug here. We need app developers, of course and many you know numerous subsystems can use could use some help particularly audio graphics Browser Those are probably the main ones that we need we're looking for help at this point and the app framework We're doing a lot of work on the app framework. So And then we have Jira you can check Jira for our Current product our current project roadmap in terms of what projects are active And we're also using it for defect tracking things like that. So our Contribution our code our development process is also documented on our wiki And again as we continue to we'll continue to evolve that as we mature and as we add more developers I'm trying not to build out a huge process for you know Trying to scale the process as we go along as opposed to building a very onerous process for 20 people, you know We don't need a huge, you know We don't need the same kind of processes that say the Linux kernel has with thousands of developers as you need for the Small much smaller number that we have So obviously we're using git for version control We use Garrett for code reviews and for managing the Submissions And there's the addresses for where you can find those And again, we're using the Linux foundation identity for logging on to those and for submissions So this is just a description of how we set up our Garrett basically we have met it we have a GL area which contains the Build scripts in the recipes for building the distribution and then we have some source code repos For where we where we're housing any code that's being developed specifically for a GL Obviously we're using a we're reusing a lot of code from elsewhere Most of our code is housed elsewhere, and we're not attempting to mirror all that that would be that would be Pointless, so the source and staging repos are fairly small and Again a complete description in the links can all be found in the wiki on the wiki site We're using Jenkins For continuous integration Based any any submission made to Garrett is automatically built by Jenkins and Jenkins can give a plus or minus one Based on whether the build passes or fails So we don't we won't integrate anything unless the build passes We're also providing daily snapshot builds for the reference BSPs and That's the link. There's I gave you the link before for the Website where you can get to the It'll it'll lead you to the snapshot builds. That's actually the direct website to the snapshots and you can get every daily Build there that you may want We're using like I said before using Fuego For automated testing we have a pretty vibrant and large community working on both improving Fuego itself and committing test cases and running test cases and There's a lot more information about that on our wiki site at the test framework site and I would say they that's That's been a huge help in terms of the number of people contributing in the number of test cases and what they're what they've been finding for us so just a One last thing so we're kind of our governance. We're kind of structured into some expert groups as well as We have a system. We have a basically a system architecture team and some expert groups But I hate the name expert group because you don't have to be an expert to be in the expert group really, it's a team working in a specific area of of a GL and In many cases there may be component teams that own specific software That's not specifically assigned to an expert group really the expert groups are working on more advanced features or Working on features that we need to add to the we need to add to the system So each team has a dedicated wiki page And you can see those directly from the the home page of the wiki Just a quick run through we have an application framework and security expert group So this group is working on completing the application framework this year Working on the security framework and the security spec that we that I mentioned earlier And then each of these expert groups kind of has maybe some areas that are don't seem obviously part of their remit What we've done is What always what we've purposely chosen to do is if there's an area let's say software update That has interest, but maybe there's only two people interested in it We're not going to create an expert group with two people in it So we were trying to maintain some kind of critical mass in the groups of at least five to ten interested parties So what I in these slides the areas that you see in green are really the areas that are the major focus for that group This is another extremely active group the UI and graphics expert group. They're looking at creating an AGL compositor Layer manager and GPU interface They've also got the multimedia Manager including multi working on multiple display and display sharing within a GL. They also own The audio manager, which doesn't really seem like an obvious fit, but it was somewhere to put it Browser engine speech recognition and navigation We've had proposals recently to create a speech rec and a navigation expert group I'm not sure we have critical mass for that, but This again is more in the In terms of creating API's for these are creating interfaces to it to a speech end to a speech engine or to a navigation engine We're not looking to create an open-source Navigation engine at this point. It's that's beyond our our capabilities But we would like our our OEMs and our tier ones would like the ability to say substitute different speech engines or different navigation engines and have a consistent API that their suppliers can use the connectivity expert group mostly they've been focusing on vehicle connectivity and network and vehicle firewalls They're starting. They've been also looking at some cloud connectivity smart device link, which is the Ford developed Interface to a smart phone that they're open sourcing Toyota's also been involved with that So the connectivity expert group has a lot of different Places to participate as well. And then finally the continuous integration and automated test group They've been really hard at work at building I'm building out both the Jenkins infrastructure the build infrastructure daily snapshot builds and then a sub team within that has been working very hard on test environments and Fuego and Getting lava set up or something like it that'll allow us to test Boards remotely and not have to have all of our boards sitting in a single location so this groups of making a heck of a lot of progress and But of course can always use some more help so That was all the slides I had and We still have about five minutes left if anybody has any questions that I can evade Yeah so the question was about just to repeat the question the question was about can what we plan to do about it and Navigating around the There's a lot of different proprietary messaging and implementations around can so As a former tier one employee, I can tell you that I spent a lot of time working on most which is Similar issues to can and that you know electrically the spec is pretty Simple and at the application level. It's either in Cairns case. It just isn't there every but every OEM has their own Application layer most it's there, but the function catalogs are very inconsistent from OEM to OEM and Right now what we're looking at providing is a Consistent messaging interface to abstract the the messaging of can Away, so we were we were initially using automotive message broker, which was developed by Intel as part of ties and IVI and We found that it doesn't have it didn't have the security built-in that we really felt was needed in order to isolate the bus So we're mostly looking at at this point bus isolation You know not allowing rogue applications to access the bus or rogue Middleware to access the buses We do have in the demonstrators we do have a very simple can interface Based on some work that that microchip has done But it's not it doesn't at all deal with the you know multi-vehicle scenario and You know where an OEM has seven different message sets for different vehicles We see what we hear from the OEMs is that Can will probably continue to either be a separate a dedicated vehicle processor not Linux-based for the time being or it'll be in a Container or More likely a virtual machine Running a separate operating system We had some we've had some talks with autosar about you know how we can collaborate with autosar on their can specific stuff I Think right now we're mostly focusing at the messaging level and not at the Physical can interface level I'd like to get there most will probably be more directly on the bus that's the way that's the way the stuff that we haven't wanted so far works and The good news about most is microchip open sourced their most driver Which is part of the AGL distribution? So going forward you can just plug in their their most chip and the driver will be available It's in the four dot. It's in the latest kernel even So I think most is is much closer to Which you'd consider a real open-source solution than can will be and then anytime in the near future Yeah the back Mode I love motorcycles for those of you who don't know and maybe if you don't follow me on Twitter Because you probably don't I actually rode my motorcycle here from Chicago. So Yes, we've actually had some talks with Some boat people some boat manufacturers or some boat equipment manufacturers about incorporating AGL into their stuff I know that Harley-Davidson had a I don't own a Harley-Davidson, but Harley-Davidson had a fairly complex IVI system that Somebody built up. I don't know off the top my head. I don't remember. I think it was becker Harman becker But yeah, I do I do see us going in that direction Pardon me. We do we have some aftermarket suppliers that are members certainly actually if I were if I were an aftermarket vendor, I would be very interested in it, but Especially on the The multimedia side and the networking side it's you know Linux to me seems like an obvious way to save Save costs and save schedule Yeah, if anybody wants me to test drive their racing vehicles, I'm I'm here for them Anything else you guys hungry you want to go eat lunch? Okay. Well, that's it then. Thank you