 All right, so it's six o'clock, so it's time to start. My name is Walt Minor. I am the Community Manager for Automotive Grade Linux, or what was it, Agile Government Logistics, whatever you want to call, AGL. And what I'm going to do is this is the birds of a feather session, so the way it works is I'm going to go through, I don't know, I've got about 10 or 15 slides real quick just to tell you what AGL is and a little bit about our community. And then you're going to get to participate and ask me questions, or even better, I'll throw the question to somebody here who actually knows something, unlike me, and they'll answer the question, so that would be even cooler. So what is AGL? Basically, we're an open-source project hosted at the Linux Foundation. I'm an employee of the Linux Foundation, my colleague, Yancemon Muller, who is the AGL Release Manager. He's also an employee of the Linux Foundation. And we're basically a neutral party among 155 members or so collaborating to create the automotive software of the future. And we have a single code base that we call the AGL Unified Code Base. It's called the Unified Code Base because of the time we created it, there were a bunch of different automotive and non-automotive software open-source components running around from Tizen, from Genevieve, from Yachto. And we're taking all of that, combining it with some open-source components that we've built in AGL over the last four or five years. And that's what we call the Unified Code Base. We have 11 different automotive manufacturers that are participating and supporting automotive-grade Linux. Just this past year, we've had some important new members, like Volkswagen joined this year, Ford rejoined, and SAIC, the largest car manufacturer in China, is now a member. We have, like I said, 155 total members. So across the spectrum of the automotive industry, tier ones like Panasonic and Denso and Continental, tier twos like, you know, and SOC vendors like Renaissance and Intel and Qualcomm. So a whole host of an Amazon participates with their speech recognition engine that everybody's familiar with. I won't say her name because she might go off. So a really good collection of companies that participate. We like to say that if there's Linux in a car, it should be running automotive-grade Linux. And we're the only organization, the only open-source organization, especially addressing all the software in a car. So we've already got, with our UCB, we've got profiles for infotainment, for instrument cluster, for telematics and connectivity devices. We're adding heads-up display. And as we move into the next year or so, we'll be adding functional safety and then ADAS and autonomous driving. So the AGL Unified Code Base. Basically, there's one source tree that we build from to build all these different devices for a number of different reference hardware platforms. Our goal is to provide 70% of a base platform for production projects for your tier one suppliers. And really, open-source is fairly new within the automotive industry and collaboration on source code is really new among the automotive industry. So really, we're working to cultivate an ecosystem of developers and suppliers around open-source, all using the single source code base. We have all of our source code. AGL is completely open and transparent. I'm the community manager. We have an open mailing list. Anybody can join the AGL Dev Community Mailing List. I've got a list at the end of these slides of a bunch of different developer resources you can use. All these slides are already uploaded so you don't have to go take pictures or worry about hyperlinks. They're all the hyperlinks work as far as I know. So you can download all the source code for the reference applications, for the BSPs, et cetera. It's all available on our Git page. Just to show you the amount of collaboration we've got. This year, we do a release every six months, but twice a year. For one year, every year, we pick a version of Yachto and we stick with it. This year, we've been running 2.6 or a Thud. And so our releases are named after Fish. I think I've got a complete list of all the Fish names. This year, we released our seventh and eighth releases, Grumpy Guppy and Happy Halibut, both of those running Thud. No, that's not true. Happy was running Rocco. Halibut and Ice Fish will both run Thud. We've done, since we released Grumpy Guppy at the beginning of the year, we've released four patch updates, it was security updates and kernel upgrades. We released Happy Halibut in July, so that's where we switched from Rocco to Thud and we've done two patch updates since then, just about two weeks ago was the last one and we'll continue to do updates of that through the beginning of next year. Probably five patch releases, possibly six, depends on how things go. That middle line here to show you, I've got a slider that addresses that, but basically, those are all the opportunities we have for our community to get together, have a face-to-face meeting among our developers. We had an all-member meeting last week in Monte Carlo, so 120 people, 120 developers got together and talked about AGL and worked on source code, things like that for three days in Monte Carlo last week. This is probably an old slide, but the AGL architecture is microservices-based. We have this binder binding concept for adding new services to AGL. We use SMAC for security. We're adding token logic for security as another security method as well. Just a quick picture that shows at a high level how that all works and there's a lot of, we have a documentation site, so you can go take a look at all this architecture. We have binders available, so we need to basically consider a binder as a collection of APIs or a collection of bindings for a whole bunch of different areas, home screen, window manager, audio, a lot of connectivity, geolocation, GPS, media player, so both automotive functions and more of your standard networking and functions like that, all of which are then, we have security provided by SMAC using the AGL application framework, so you can't access these APIs, these bindings, unless you have the right permissions. We've also got an XDS-based SDK that you can download, you can quickly get up and running, you can either start with the reference applications we have or write your own. You've got Qt-based, I should change this, HTML5 is not just planned, HTML5 apps are now available using the web app manager that we have, so you can basically download the applications and be up and running in a pretty short time. There's, again, there's another page on our documentation site about how to build your first application and download it and get it up and running on a board or using the QMU emulator, so just a list of different developer resources like how to get to our Wiki page, where the source code is, we use Jira for issue tracking and for project management and things like that, you can go download, you can go grab tar balls or pre-built binaries, release notes are always available on our Wiki, we use Garrett for code reviews, we use Git, of course, for source code management, and then we have weekly developer call that I host on Tuesday morning US time, Tuesday afternoon in Europe, Tuesday evening in Asia. You can always are welcome to join that, we usually get about 30 to 35 people, you can ask any question you want, we have an IRC channel where a lot of folks hang out, you can ask questions there, we have a dev community mail list that was recently moved over to groups.io, so that's available as well, so there's all and when we moved from mailman to groups.io, all of the back history was ported over to groups.io, so it's a much nicer, searchable format, so if there's any question you have, you might be able to find the answer right in there, or you can just post a new question to the mail list and to the topics. And then finally, so I'm trying to keep this part to 10 minutes, we've got, this is kind of the list just to show you some of the workshops that we've had this year, we've had a lot of face-to-face workshops, we try to get together our developers together about every two months or so. We just had one, like I said, in Monte Carlo last week, we were in Berlin last month, we had I think 30 or 30, no, we had 40, I'm sorry, 40 or 45 people show up in Berlin. We'll be, a lot of you have some semi-ultaneous sessions in Karlsruhe, Germany, in Yokohama, Japan next month, and we'll be in San Francisco in December, all leading up to our big CES event in January in Las Vegas. So with that, this is mostly a boff session so you're all supposed to come prepared with questions and I'm supposed to have answers but I probably won't have answers from other people here. So who has a question or who has something they wanna ask or talk about? Otherwise we can just go to the bar. Oh, you want a leading, oh, I didn't give you any leading questions this time? Okay. Yeah, okay, there we go, we got a question. The man in yellow. So is this automotive grade Linux project has been used in any industrial project yet or? Industrial projects? Yeah, I mean like in even a proof of concept with any OEM or? So in a car, yeah. Yeah, in a car, yeah. So industrial is kind of another vertical but we have had interest from industrial companies in looking at AGL. Toyota has said that there has announced that they're using automotive grade Linux, the earlier version of it, in the starting with the 2019 Toyota Camry and now it's in the RAV4 and other vehicles as well spreading into their Lexus lines. I think Mazda has said they're going to use it and we've got other, we have like I said 11 different OEMs so expect that we'll get more announcements from those OEMs as we go forward for the next couple of years. The existing implementations in vehicles are infotainment. Yeah, this year was the, earlier this year we released the instrument cluster reference device. We have an instrument cluster reference group, expert group rather that meets every two weeks. Suzuki, Haraki-san from Suzuki leads that expert group. There's been a lot of interest from both OEM members and tier one members like Panasonic, Denso, Blash, Continental, Nippon, Nippon CK, is that how you pronounce it, all participate in that expert group. I don't recall if they're, if they are showing anything this week, if they had a presentation this week but if you go to the Linux Foundation events site, you can find the all member meeting link for last week and Monte Carlo and there was a, there were a number of presentations about instrument cluster expert group and there's also a wiki page for that and they're planning on doing some, some work on a containerized solution to allow IVI and instrument cluster to run on the same device as well as Suzuki has shown, already has shown an AGIGL instrument cluster running on the Renaissance E3 hardware and then Scott Murray here has been doing a lot of work on the instrument cluster reference device that we have runs on all the different boards that we have. A very sophisticated demo is what he said. Yeah, so we have a table at the tech showcase tomorrow. Tomorrow evening, you know, there's the tech showcase and booth crawl. So we have a table at the tech showcase, we don't have a booth, but we do have a table and we'll be showing that, hopefully we'll be showing that instrument cluster demo tomorrow. We should be showing on the Raspberry Pi, the SandCloud, the Beaglebotta Enhanced and we should be showing on the UpSquared. Intel UpSquared. We should be showing it on some mix of those boards, both IVI and instrument cluster. Adaptive AutoSAR, so this question was, do we have plans for completing or competing cooperation with it? Oh, AutoSAR is a closed organization so we've had some discussions about working with them but it's been hard to find a way to do that. They just have different business interests than our members. Can you repeat that? What is the AGL, in fact, is it a distribution? Is it what exactly? So there's a distribution, absolutely, there's a distribution, all the source code you can go download. There's a meta AGL Pocky Layer that's a major component of that. So basically, and then on top of that, you can build, we build different reference devices so we have a meta instrument cluster, I think it's called, meta. So you can basically then build all those reference devices. We can build AGL Core Minimal and then the devices on top of that. What is the benefit compared to Yocto or to... So there's other infrastructure that AGL members have contributed and then the project itself has funded. So the application framework that Walt mentioned, that's the significant value add. It's an AGL specific enabler for OEMs to build applications to run on top of the AGL platform and that's an AGL open source project that doesn't exist for, you know, it's a unique thing that AGL brings to the table. I mean, you just... This is our Git mirror here. So you can see... Don't see it. See if I do this. Okay, so that's our Git mirror. Scroll up a little. Scroll up. So we have these meta-AGL layers. Yeah, so that together with Yocto layers, with that we build AGL. The collection that you need to pull down, you will find in AGL repo. So we are using the repo tool like in Android to pull all the different Git layers down. Then the AGL specifics are in meta-AGL. And here you see all the reference apps, the services, the reference applications, and if we scroll down to source, then there are the unique middleware components. That AGL hosts. So the application framework, Sina Gora, that is one of the key components in AGL. A little while ago, we talked about instrument cluster. And when it comes to instrument cluster, a lot of buzzwords around security, safety, compliance, certifications come. So how does AGL as an organization or project deal with this? So with respect to safety in the instrument cluster, so the instrument cluster expert group is addressing that, and I don't have the, I could go grab them, but so they're addressing that with a containerized solution. There's also been a proposal for a hypervisor solution to keep the AGL code in a separate virtual machine or a separate container with the safety certifiable part in another virtual machine or container, depending on which architecture you look at. The instrument cluster expert group in particular, if you go and look at last week's all-member meeting, they made a presentation, it was led by Yamaguchi-san from Aishin 10, from Aishin AW. They made a presentation last week about the architecture they are proposing, that they want to show at CES and get into the source tree with the IVI system and the instrument cluster and the safety, the telltales and the buzzers, all in different Linux containers. And so that's the approach we're taking now, being led by Suzuki, because they want to get this into vehicles as quickly as possible. And we are also participating in the ELISA project, where basically we are encouraging our members to join ELISA. We're doing a little bit of support, Jan Simon and I. I'll be attending the functional, what are they calling it, the security, the Safety Critical Systems Summit on Thursday. So we'll be working on how we've got a presentation about that group in particular, that instrument cluster group and how they're going about their work and how we can continue to cooperate with ELISA. So I expect that in the next 12 to 18 months, you'll see both source code and some more definite plans from our OEMs and tier ones on how they're going to achieve that safety certification. You're welcome. Could you spend a few more words about the architecture of the SDK, which comes with AGL? Can you repeat that, the architecture, which what? Of the SDK for application development. This is a question basically from a Yachto person, which is interested in knowing if it's possible to leverage any concept for different context. I mean, is this really specific for the middleware that you are providing or? No, the XTS is basically a wrapper and it has a web UI and it can take basically any Yachto SDK and it provides a couple of wrappers that you can integrate into your IDE. Actually, I might throw the ball over to Stefan. There's our SDK people over there. So he can tell a little more. This is why I said, I don't really know anything, but I have people here who do. Yeah, thank you. Well, there are two parts. In fact, the first one is that the SDK we produced with AGL is, as you stated, a pure Yachto SDK so you get the cross tool chain and obviously, I would say the development packages for the application development. I would say the development packages for the application framework for the binder, everything you need to develop your code and run it, right? But as many Yachto developers or not Yachto developers, in fact, people want to develop things on top of Yachto. You have two solutions. In fact, either you write your own recipes, so it's a hassle, it's a bit of paint. The learning curve is quite difficult. It's doable, of course, but it takes months and years to get something correct, I would say. The other path is to use the SDK which is produced directly by the build. And for this, you need an environment which is stable, which follows the releases of AGL and which is quite easy for you as a developer. I mean, you, if you think about someone who is developing web applications, for example, or cute applications, so it's not someone which is especially used to security, embedded stuff and very low details, I would say. So we wanted to create something which makes life easier for those people. And typically, if you are able to take your idea, because your preferred idea would be Eclipse or Visual Code or whatever idea you want, and you would be able to compile, run and debug your stuff while still leveraging the Yachto SDK, that would be great. So that's what we did with XDS. It's just an abstraction of the whole build system through the Yachto SDK. There is a Docker container which embeds the tool chain. You have to share the sources with that container, et cetera. So I wouldn't say it's very easy, but at the end, the result is that you will build your application using your IDE as if you were building natively. It's very close to, in the concepts. Yeah. No, no, it's very generic. It's, as Jens Seymour had said, it's closely related to Yachto SDK, in fact, more than AGL. But one thing is specific in the automotive world is that for cost reasons, you want to have a big community of developers and high-level apps developers, which cost nothing. So you have to deliver some tools for those people to get hands on, right? That's a reason for XDS, but it could be moved to any other market or project easily. That's open source after all. No, no, no, exactly. You can have something linear, definitely. While answering one of the previous questions you mentioned that there were inquiries from the industrial automation industry, what were they looking for in AGL? Because automotive is kind of orthogonal or quite different to the industrial industry. Yeah, I think they were mostly interested in kind of how we're packaging up things, especially with the application framework. So no specifics like looking for how the middleware is working or taking a slice out of that, how the middleware is implemented? Well, I mean, if you think about the application framework and how we're doing the security and how the middleware then combines into that with the binder and the binding concept, that's what I think they're mostly interested in. I really haven't had that many discussions with them. You know, what I find typically is I come to something like this or one of our all-member meetings and I always learn about somebody using AGL for some new way that I hadn't heard of because people are grabbing the code and because we're completely open, people are always grabbing the code, downloading it and doing something interesting with it and they're not necessarily contributing anything back, especially when we went to Embed World in Nuremberg last year. We saw all sorts of AGL demos running in different booths with no credit. In fact, some people had even removed the AGL logo from the UI. Uses and abuses, yeah. What's that? Uses and abuses of the code. Exactly, exactly. Anybody else have a question? Okay, one more. Since a few years there has been a project called Apertis. I think it's mainly backed by Bosch. Right. And they have some components for middleware like video playback and infotainment components. Is there any sort of contact or collaboration with them? So Bosch, I think they've contacted us about how we could possibly collaborate. We've had some internal discussions with them, but nothing concrete. You're not allowed to ask any questions. And do you have any test case suits? Yes, so actually, Young Simon runs our Continuous Integration and Automated Expert Group and we have a large suite of tests that we run and I'll let him talk about that. Okay, so we have a set of automated tests that we run. Any code that is proposed in Garrett will be built and we test it on our reference platforms. Of course, we can throw in and should throw in even more. No question. We also have a set of manual test plans. They are in our JIRA, so there's a separate test plugin in JIRA. So they're called Zephyr. Yeah, yeah. So there's a test plugin in our JIRA and we have test cases there. Eddie from Consulco does those on a weekly basis for master and the latest stable. And Fujitsu is also doing test runs. And that is... If you go to groups.io, our new mail list that I have listed up there, you can sign up for the test reports mail list and you can get the test reports that come out of... That's the automated tests. They run after our Jenkins builds. We will trigger a run on the lava infrastructure with the different boards. The results are then passed on to KernelCI and KernelCI will do the email reports and that's what you see in the test reports group. It's not much of a technical question, but can I ask how do you get the funds for... How do we pay for all this? How do we pay for all this? So AGL has, like I said, 155 member companies and all these member companies have to be members of the Linux Foundation and then beyond that they join AGL as a project and the platinum, gold and silver members pay additional money to be part of AGL and they get a seat on the advisory board or it could be elected to the advisory board. So they get a little more, in addition to having a bigger financial stake in AGL, they also get a little more, say, in the governance. That's not to say it's pay to play because many of our bronze members are some of our biggest contributors in terms of code. So once you're a member of AGL, once you're a member of the Linux Foundation, you can join as a bronze member, basically for free, above and beyond the Linux Foundation membership. And then if you want more, say, in the governance then you can join that silver, gold or platinum. So mainly it's through this membership fees, sort of. For the Linux Foundation? No, no, it's mainly that the funding is... That money that we collect from silver, gold and platinum members then goes to fund AGL activities like the infrastructure, me. Yeah, I'm Simon. Thank you. Hi. What is the main difference between AGL and the Android Automotive? I honestly don't know a lot about Android Automotive other than what I... because a lot of their stuff is under NDA. Basically, work Android Automotive is being controlled by Google. You've got to sign a lot of legal documents with Google. You have no say in the governance and what Google decides their roadmap is going to be. AGL is completely open. You can download our code at any time. You can go do whatever you want with it based on the open source licenses that we have. If you want to join as a member, you can have some say in the governance of it and the roadmap, things like that. So the biggest difference is really work... we're a completely open project and anybody can contribute and have a say in where we're going, which is not the case with Google. Anybody else? He likes to be called a microphone engineer. That's a question about whether that AGL has some tooling additional. I mean, like, a lot kind of... AGL has its visual tooling from different software companies. Do you have something like that that will ease my, as a developer, life? I have different LCUs and I want to easily communicate with my software written with AGL underneath. So a couple of ways to approach that. We have a documentation site and a Wiki page. In terms of tooling, we've got the SDK that Stefan was describing that I think we're working on improving all the time. And then the great thing about this ecosystem is there's a number of companies who have been contributing quite a bit to AGL, smaller tier twos, who are always willing to jump in and help people who want to get up and running quickly. Of course, they want to get paid for that. So depending on the scale that you're trying to ramp things up, you have the option of just joining the community, working out in the open, or working even behind closed doors and just asking us questions. I've seen companies do that, too. Or you can engage a services company to help you out. And from what I've seen, there's a number of... Emily should have said something while she was sitting there. On our website, we have a vendor marketplace or a vendor directory you can go to. And I can't see my screen very well. But I can add that link to the slides. If you go to automotivelinux.org, you'll see there's a vendor marketplace and you can click on that and you can see all the different vendors who offer services around AGL. If you need help getting kick-started, you can go that direction as well. There's also a link there where if you're a vendor who's a member of AGL, you can click the link there to be added to the vendor directory if you have a product or a service around AGL that you're providing. That's all part of the we're building an ecosystem of companies. So, time-wise, I think our time is up. Thanks all for coming and participating, because otherwise, if you didn't participate, it would be pretty boring. And hopefully, I'll see you around this week. I'll be here all week. Thank you.