 Just a quick introduction to Automotive Grade Linux. Hopefully, most of you are already aware of what it is. But Automotive Grade Linux is an open source project based at the Linux Foundation, hosted by the Linux Foundation, focused on rapid innovation of vehicle software. And that includes vehicle software like the in-vehicle infotainment and instrument cluster systems. And our tagline is collaborating to build the car of the future through rapid innovation. We have a total of 11 car manufacturers that support HGL that are members. These include most of the Japanese ecosystem, like Toyota and Honda, Mazda, Subaru, includes US, like Ford, includes manufacturer in China, SAIC. And then recently, we've added Mercedes and Volkswagen from Germany, from Europe. So it's a good worldwide ecosystem. And overall, we have 155 total member companies, including a large number of Tier 1 suppliers and Tier 2 suppliers. And those are broken up into platinum, gold, silver, and bronze level members. Like I mentioned before, Automotive Grade Linux is the only organization addressing Linux in all different types of ECUs within the car. So our primary focus the first few years of the project was infotainment. We have a very active instrument cluster expert group right now that's working on bringing an instrument cluster prototype out that some of our members can use in their vehicles in the next few years. We have a telematics and connectivity profile. We're involved in Alisa, the embedded Linux in safety applications projects within the Linux Foundation. And in fact, recently they announced that there is an automotive working group that's going to be starting within Alisa. We're also looking at advanced drivers, ADAS systems, and eventually building up to autonomous driving, although that's sometime in the future. I think GL, we work on something called the Unified Code Base. It's basically we're using a single code base, single piece of software, single set of code repositories for the entire industry. And we're obviously to reduce fragmentation throughout the industry. Our goal is to provide at least 70% of the base platform for a production project in whatever of the profiles you might see here. We have reference hardware and applications available for adaptation. And really the overarching goal of the Unified Code Base is to cultivate an ecosystem. We have developers, suppliers, automotive expertise, everybody contributing to a single code base with all of the various repositories that we control. So this is our 2020 schedule. Our releases are codenamed as Fish. We have the Ichi Ice Fish release, 9.0, earlier this year. We've already done two patch releases. We have another patch release scheduled for the end of next month. Meanwhile, we're focusing on working on jumping jellyfish where we are moving to the Yachto 3.1 version. The Yachto, which is their LTS version, if you saw their earlier presentation on LTS. And then at the end of this year, we'll be releasing the final release for jumping jellyfish as planned for the January timeframe. And then we'll be starting on Kuki Koi as we finish up the jumping jellyfish release. So the AGL architecture is based on the AGL application framework built on top of Yachto. It's a microservices architecture. We have a concept of bindings and binders with a whole lot of different services available on top of that. Just a, I think a short list of available binders includes a home screen, window manager, audio, connectivity, including networking, wifi, Bluetooth, vehicle signaling like CAN, telephony phone book, location services like GPS and geo fencing along with some reference apps that build on top of these things like a navigation app. We've got media player, media scanner using light media scanner. So there's a whole bunch of different binders available and that list of binders grows seemingly every month or something new introduced. In terms of developer resources, all of these slides will be posted on SCED later on, so you can click on all these links. The developer resources, so we have a getting started guide on our wiki page. We have a documentation site. You can see there's a getting started guide on the documentation site that allows you to figure out how to get up and running as quickly as possible with your chosen board and how to write applications. We use JIRA for defect tracking and project management and we capture our test cases in JIRA as well using, I think it's Zephyr. You can go get pre-built binaries and source tar balls for all of our releases. Release notes are available, of course, on our wiki. We use Garrett for code review and merging. There's a Git mirror available and we also offer a number of different ways to communicate with the community. So we have a weekly developer call on Tuesday mornings. We, you can call in, you can ask questions. We usually get 20 to 30 people calling into that every week. We use IRC, there's almost always people on IRC on free note on hashtag hash automotive. We have a developer mailing list that you can subscribe to and just wanted to show this. So typically in a typical year, because we're trying to be, again, we're trying to develop a community in an ecosystem here, we would get together six or seven times a year, either at AGL all member meetings or events like embedded Linux conference. Or we even host some developer meetups at various companies throughout the world. You can see last year we had a good number of these. This year, unfortunately, we've had to cancel, we've had to cancel a lot of that because of the coronavirus. But if you are an AGL member, we do have the Berlin all member meeting coming up next month in July. And we'll figure out as we go through the year whether we can hold our usual integration sessions as part of the Automotive Linux Summit and the CES integration sessions that we would normally have. So that's it, we just wanted to give a really short overview of automotive grade Linux. And so I see we do have a question. Do you have any questions? Just like I said before, if you have a question, please pop it up, pop it into the questions tab. And if you can answer the question, if you can answer the question better than I can, then most likely somebody can. You can raise your hand and we can activate your microphone and you can give the answer. So the first question I see here is from Jesus. It says, when I say that this Linux approach, this Linux approach to an AutoSAR similar platform. So I don't know if you're talking about Classic AutoSAR or I forgot the new one's called, but Classic AutoSAR definitely not. Classic AutoSAR is really dealing with, it's a very close system dealing with just the low level can interfaces. And messaging through can. We're at a higher level than that. And the newer AutoSAR adaptive, yeah, I would say, I guess it's similar to that, although more inclusive. I don't know a lot about AutoSAR adaptive given that they're a closed ecosystem. If somebody has something else, some additional, something else they wanted to answer or add to my answer there, you can raise your hand. So another thing we should bring up in terms of what we provide on our motor freight limits. So I mentioned we have a Garrett system. We use Garrett for code reviews. We have a continuous integration. We have a CI system based on Jenkins with remote test labs and using remote boards as well as QEMU. It looks like I've got a question here. Is there a way to test software without equipment maybe like demo software? Yes, there's a couple of things you can do. We have board support packages for inexpensive boards like Beaglebone Black, especially the Raspberry Pi 4. We can also use QEMU, the test. And then we have, every year we have done a, last few years we've done a CES demo using what we call the green machine. And all those demo applications are available in our Git tree. You'll see, if you look in our Git tree, you'll see there's a set of applications there like multimedia, phone, HVAC. There's a home screen. There's a navigation app and a POI search app. So there's a whole host of applications you can use including an Alexa app as well. So we have speech integration there. So hopefully that answered your question, Jamie. So Andrew Murray has a question and I think Jan Simon could pop raise his hand and maybe answer this one, help me answer this one. Left to get more information on how we do CI testing in QEMU and on physical hardware. So we use lava for that. And can you, Kate, can you please give Jan Simon mic access, please? So Jan Simon is the, he runs our continuous integration and automated test expert group. Hello. Yes, we can hear you. Yeah, okay, yeah, connection stabilizes. All right, so yeah, we can actually run tests on QEMU and on physical hardware. This is done by the lava software. So this is a framework that allows you to manage farms of boards, kind of multiple boards of the same type, but QEMU is basically just, yeah, a subtype here as well. So when we built a submitted change set in our CI system in Jenkins, the artifacts get published to a web server and the lava labs get a job submitted and then pull the artifacts, run a series of tests. And that can be QEMU, that could be physical hardware. If you are interested in details on lava, just hit me up on Slack. I can give you some more pointers. But in principle, you can hook up any hardware where you can do power control, serial and network. So that's the three things you need and then you can hook that up with lava. Okay, so let me see if there are any other questions. Okay, so we have another question. Anybody here specializes in mobile 4 or 5G connectivity in the automotive context, if not any contact info. So we have, if you go to our JIRA page, we have a number of expert groups within AGL, including the connectivity expert group. And the connectivity expert group meets every other Thursday and they're focusing on connectivity, including mobile connectivity. And we have some of that available already in our repositories and in our applications. I'd say right now we have a lack of people who are actually working on those modems who have been participating. We've been more focusing on it from a user perspective. But the telematics use cases and we also have a vehicle to cloud expert group that meets every other Monday. In fact, they met this morning and they are also focused on connectivity to a server backend for vehicle data collection and things like that. But again, so I guess it's, Claude, I guess it depends on whether you're interested in the low level interaction with the modem or with more of the high level and application type use cases. So the connectivity expert group is really focused on the lower level stuff and the vehicle to cloud expert group is more focused on the application level and connectivity with a server. Somebody asked if I could click on the answered ones and I don't see a way to do that. So are you guys using, okay, Zach has asked the question. It's interesting, so Zach is from Cary, I'm from Cary, but I'm guessing you're from Cary, North Carolina. I'm in Cary, Illinois. Zach, are you guys using smack as our Linux security module? If so, how has your experience been with it? Boy, we are using smack. Let me, I'll ask if Scott or Scott Murray or John Simon want to talk a little bit more or anybody else about our usage of smack, but all of our, so all of our binders require smack enablement and through the application framework. I'd say we've run into a few issues, but I probably, I have not been directly using that. I think Scott and some other folks have been more direct users of it. And I think the guys who set that up who work for, like Jose, he's probably asleep right now because it's midnight in France. Someone raised their hand. So can we let Scott speak? Complicated compared to policy setups you could imagine. Basically every installed app gets its own label to the policy, which is sort of similar to the early visions of how Android SE Linux, which makes it somewhat straightforward to understand how it works. But now they're, because smack doesn't have a really large user community, recently you've had some issues with things like pipe wire and they started to use math Ds for things to pass memory buffer handles round. And smack doesn't really support labeling things that don't have presence, like they're not in the file system. That complicates things a bit. Whereas, as I understand, SE Linux has had support added for things like that. So it does raise some questions about how future proof smack's gonna be outside of AGL, probably at this point, ties into the only real user of it that I know of. So I think that's it. Does that answer the question? I'm sorry, I muted myself. I think so. If there's a follow-up, Zach, please ask the follow-up in the question area. Yachto LTS was announced. Which version of Yachto does AGL use and how long has it maintained? So we are actually, so for jumping jellyfish coming up in September, we will be using the Yachto LTS version. So our next release, the 10.0 release, will use 3.1. And so if you go to our master branch now, that's already running the LTS version. In the past, we have switched Yachto versions once a year in our January release and stuck with it for a year. Our tentative plan right now is to stick with the Yachto LTS version through its two-year life cycle. The commitment from our board vendors who are members of AGL and the boards that we use is that they'll stick with that version and continue to support it. Our understanding from the Yachto team is that the non-LTS versions will only be supported for I think nine months. So we were using, we were thinking about using Zeus rather for the next version, which would have been 3.0. And that's already going out of support from Yachto. So the plan right now is we will stick with the LTS version for the next two years. And I think at that point we'll revisit what we do. Either Yachto will declare another LTS or AGL will decide to continue to use that same one depending on what our members and what our advisory board wants to do. So I'd say for at least two years locked into the LTS version and that'll be released with the jumping jellyfish in September. Next question is from Pratik from Hitachi. Is AGL related to CIP? Not really. So it's a completely different project with different goals. They're more focused on I think a 20 year use case. So there are some cross members but nobody's really working on, no individuals that I know of are working on both projects. How can someone help start helping the project more beginner oriented? A lot of different ways. So we obviously download the code, play with it, see what works. If you see something that doesn't work, submit a fix or submit a bug, a bug report. If you have trouble downloading it and getting it running, certainly the mailing list people are, I think, I think we have a fairly friendly community. The people answer questions on the mailing list. We also, like I said, we have our developer chat, we have our developer call on Tuesdays and the IRC channel. If you, it's as with any open source project, if there's something missing and you feel like it needs to get done, we always accept contributions. We have some people working on some cloud use cases. Right now, there's also a list of roadmap items that we have on our Wiki page. And you can just drop me a question as well or something you think you might wanna work on. Just let me know. And of course, I mean, I hate to say this, but documentation is always an area we need help on. So I ask anybody who's been going through, bringing up the board, if they find a problem with the documentation to help submit updates there as well, it's greatly needed. Or greatly, greatly needed when greatly appreciated. So I think we already answered the next question from Claude. Has HGL, Anthony asks, has HGL gone through any government slash safety compliance slash certifications? So we are members of the ELISA project that bed leaned at Linux and safety applications. When you think about for automotive, you think about AISO 26262 and the AISO levels. We're targeting AISO B for our instrument cluster solution. The instrument cluster expert group is working very much hand in hand with the ELISA automotive working group that's forming now. We've been very active in their existing efforts. So the ELISA team has people from different certification bodies that are helping us with understanding what issues we need to solve an AGL there. So we have not gone through any of that stuff yet. Of course, when it comes to AISO B or any of those certifications, you get certified at a system level, not just the AGL software itself. So we wanna make those artifacts available that a company would need in order to meet those certifications. And that's kind of what the goal of our instrument cluster project is, is to try to figure out what exactly we need to provide. So again, if you're interested in that topic, I'd say our instrument cluster expert group is probably the furthest ahead. I'm gonna skip to some variants. I'm gonna say it wrong. Some sub-Romanians question on the bottom because it's easy for me to answer. Where to find the list of eval boards supported by AGL at present? Go to the release notes on the Wiki page. And you can also pre-build, you can also find pre-built binaries for Raspberry Pi 4 and the number of other boards there. How mature, okay, so David is asking, how mature are AGL binders for CAN bus management and data logging? Is it still in development or more production ready? How mature, so they've been, we've had them available now for a few years. We use them in our demo. Our green machine has a separate boards for instrument cluster and the IVI system with a CAN bus connection between them. We have what we call a vehicle signal manager, which allows you to create abstractions of the messages so the applications don't need to know the exact messages and you can combine fields in the messages and get notifications and things like that and send messages on the bus. Is anybody, is it in, I would say it's still in development. We know there are some issues around production readiness. There's a lot of interest around building up that functionality. So we have, right now we have a member in Germany with the Rutlegan University that's been kind of building up more and more that functionality, creating some tooling around taking canoe messages and canoe message databases and converting them to the JSON needed for the vehicle signal manager. And I think that's looking very promising. And Denzo 10 has done a lot of work with it, has done a lot of work with the CAN bus as well. But I don't think anybody has put it into production yet. And the instrument cluster guys may hopefully will pick that stuff up as well. I hope that answered your question, David. Does AGL support OTA over the air updates? We have support for OS tree. John Simon or Scott needs to chip in because I always forget the answer to this. Okay, so we have the building blocks for OS tree and John Simon raised his hand so maybe we can promote him as well to speak. And AGL in general is not worried about the end to end OTA solution. The manufacturers, the OEMs have said that they'll take care of that. They'll own the solution from the server to the device. John Simon, you can speak to what enablers we have on there, in there already. Yeah, so the OS tree over the air update system has been submitted a while ago by ATS, Advanced Telematic Systems. This is based on OS tree and is integrated into the current code base. There are some board specifics, so not all boards have those enabled, but the usual suspects have. Yeah, so you just have to enable the AGL-SOTA feature and OS tree-based support will be there. It's not hard to try it out. There is a guide on the wiki, which should work pretty much fine. Scott, did you wanna add anything? I know somebody had asked, I think somebody had asked that question on the Slack channel earlier and Scott was talking about some of the work that Leon did with ATS. So if you go search the Slack channel, I think there's some discussion of that as well. Okay, is there any other questions? Well, this hasn't been quite as interactive as a typical bof, but I think it's been okay. Just give another minute for anybody else has a question. Otherwise, I guess we can end early or I can sing. I mean, you don't wanna hear me sing. Was there something new in the chat? Okay, we do have another question. Does AGL support dynamically installed apps? Yes. So I guess it depends on what you mean by dynamic. How dynamic? The short answer is yes. And I think Scott might be able to give a better, expand them now a little better than I can. Scott, somebody raised their hand. Oh, there he goes. But if you can get the widget file, I mean, we regularly use that in testing. Yeah, they have another question from Karthik about does AGL have an app for Android Auto? No, we do not. So we believe, so being a collaborative project for the Linux Foundation, we could not sign the necessary agreements with Google to support Android Auto out of the box. But we know that some of our tier one suppliers and tier two suppliers have written Android Auto on top apps on top of AGL. So we know it can be done. But we unfortunately do not have the ability to provide that as an application from AGL out of the box directly. And then the same thing with CarPlay, with Apple CarPlay.