 Automotive SIG update, yes. Am I good to start early, yeah? I think you can start early, because we're not gonna get, the other rooms are in the middle of a one hour talk, so nobody's gonna be coming over. Cool. Yeah, so this is a general update. All sorts of going on in the CentOS Automotive SIG. So for those of you who don't know me, I'm Eric Horton, I'm a software engineer at RedHash. I work mainly on automotive stuff. Oh, and I wanted to give special thanks to Sandro, because I found this beautiful slide deck laying around, and I asked him, could I use it and extend it, and embellish it, and he said, yeah, so. Thanks for helping me create this slide deck. So yeah, our SIG is still relatively young, I think it's about two years old now. So just to give a description what it's all about, this is an example of an open hardware vehicle called, from a company called Open Motors. It's a very bare-bones framework. It comes with no software, no electronics. It just has the minimal requirements for building a vehicle, so you can make your, bespoke custom changes on top to make your vehicle more individualistic. So I kind of think of CentOS Automotive Stream Distribution and RIVOS, Red Hat and Vehicle Operating System. It's kind of the software version of this, so building up your software in a vehicle starts from the operating system. So CentOS Automotive Stream Distribution, for short, sometimes we call it auto SD, enables you to do this. So just before I describe this slide specifically, our model is very simple. It's very similar to the CentOS Stream Rail Model, where CentOS Automotive Stream Distribution is based on CentOS Stream, and we just have additional automotive repos that generally add extra automotive specific packages, except in the case of the kernel, we actually replace the kernel. And same goes for Red Hat and Vehicle Operating System, that's based on rail, and we add additional packages for automotive. So because we're based on CentOS Stream and rail, the usual workflows for contributing to Fedora, Apple, CentOS Stream, all apply of course. But for an automotive specific change, we also have one other route for contributing. So this would be what's called in this slide, the CentOS Automotive Sig Repos. So if you can contribute your change there, it'll make its way to CentOS Automotive Stream Distribution, and which limits you make its way to Red Hat and Vehicle Operating System. And then we have this kind of continuous certification and testing framework, so if anything pops up, the change is made into the repo and it propagates through the pipeline again. So yeah, we receive all kinds of contributions from hardware vendors doing hardware enablement, from automotive vendors, like general motors or something like that, for feature requests and whatnot. Sometimes software developers just want to add certain libraries that maybe aren't in CentOS Stream as the base, and we also work with other partners like Sophie and Eclipse STV. So sometimes we include reference implementations for the standards that come out of those groups. And, oh yeah, so this is one of the few packages we actually replaced, so we have our own automotive kernel. This is like 99% of kernel that goes into CentOS Stream. The key difference is we use the real-time Linux patch set, so basically the scheduler for this type of kernel that the folks on determinism and low latency. And sometimes I use this analogy to describe the whole real-time Linux thing for people that are familiar with. Let's say you're a driver of a vehicle and you hit the brake pedal, you would probably like the brakes to react quickly. And within a certain timeframe, so this is kind of what real-time Linux is all about and it's kind of safety-critical don't means it's often used. So yeah, there's a focus on functional safety, there's specific certifications that we aspire to achieve for the operating system and this is all about basically reducing the risk factor and ensuring every function is carried out as prescribed. I've heard this analogy from a couple of people in automotive in the past, so obviously we can't ensure that bad things never happen but the analogy often used if I give you a gun and you shoot yourself in the foot, that actually worked as designed, you just used it in a poor way, so a lot of that is going down to things like reading the man pages. Do the man pages say what actually happens when you actually call this function and execute the code? So it's all that sort of thing. And of course there's performance standards. We aim actually to be the first continuously certified Linux platform for road vehicles and this effort is kind of essential to be honest to the safety of automotive Linux distributions. We actually pump a lot of effort into this area. Oh yeah, another difference from say vanilla CentOS stream is we use Austria kind of as our immutability solution. A bunch of Red Hat based operating systems use this just to name three is rail for edge, rail chorus and CentOS stream chorus, which if I remember correctly was announced at the last CentOS connect. So what does Austria provide? It has a lot of desirable qualities that are suitable for automotive. So Austria gives you atomic upgrades. So say if you get a power cut in the middle of an upgrade or whatever there's not such thing as a partially applied upgrade or whatnot. There's also kind of a tool that complements Austria called Green Boot. So once you do an update or install an extra package when you reboot there'll be health checks and you can mark a boot as successful or healthy or bad or fail and in that case you would obviously roll back. So the atomic upgrades feature is desirable. I started calling what OS tree does and directory based AB updates because I've talked to partner in the past and saying and they've often said it's not AB. It doesn't do AB switching because you don't require A and B partitions and that's not actually true. We just do AB updates in a different way. It's more directory based rather than partition based. So yeah, we apply Delta upgrades because OS tree is basically like a Git repo for our file system. So you just apply the def on top every time you do an upgrade. So provides immutability. So like the file system is read only so you can't really change it that easily. Although I will say if you're a developer there are some developer tools that can give you the right access. There was an interesting talk earlier about secure boot. A kind of related, somewhat related project to OS tree at the moment is something Alexander Larsen and Giuseppe are working on called compose FS and basically what compose FS kind of does it kind of extends the chain of trust further down to the file system. So you can like detect malicious changes or bugs that cause data corruption or whatnot. And something that we don't include in automotive stream distribution but I think it's an interesting advancement at the moment in the whole OS tree ecosystem is there's a tool being developed called Bootsy and what Bootsy is it's using OS tree containers as a transport and delivery mechanisms. So it's you're booting into a container but it's not a container per se you're just using the protocol basically. So that's kind of cool cause it's kind of consolidate in our transport and delivery mechanisms but yeah this is kind of a future thing. Oh yeah go on to more detail about compose FS I left a link to a talk Alexander did there and the github repo but yeah there's ongoing upstreaming in the Linux kernel and we intend on back porting that I suppose I should say sent to a stream cause that's where it actually lands but eventually propagates to real and since we're based on those operating systems excuse me we will be one of the users of this so yeah as I said it detects it verifies the file system is the way it's supposed to be like in case your hard disk failed or something and there was disk corruption it detects that kind of thing. What else do we have? Oh this is, this was brought up in an earlier talk as well about how we build images we do something slightly differently to the other sigs so you may have heard of image builder before the core kind of framework that image builder used to compose operating systems is called OS build so we just use that actually. We're not so interested in the UIs on top so we just kind of wrap some make files and scripts around OS build and basically that's how we build our images we don't have Anaconda installers or anything like that either because people don't, well 99% of people don't install their own automotive operating systems yes yeah, there's always the 1% oh yeah this is just another diagram so we take, oh, I finally had to remember why we put in this slide one of the difference with one of the difference with differences with CentOS Automotive Stream Distribution and Red Hat and Vehicle Operating System is although we provide sample images for each player around it and develop on and whatnot it's actually generally the end customer that does the final build so they'll take all the CentOS stuff and they'll also add their packages and whatever on top and they'll actually do the final image build so then they get their own custom and vehicle operating system so yeah these are some various communities we're involved with I'm more familiar with some than others to be honest, the scope of this talk is a little large but just to give you an idea of some of our partners we work on on automotive standards and that kind of thing actually yeah, I wanted to talk a little bit about the difference between CentOS Automotive Stream Distribution and Red Hat and Vehicle Operating System and I'm actually gonna go back a bunch of slides cause there's something I forgot to say on this slide, actually there are some packages that only make it as far as CentOS Automotive Stream Distribution and don't make it further cause there's a distinction between the project and the products and I'll just give you a simple example of some of those packages we allow you to install CentOS Automotive Stream Distribution on a Raspberry Pi to have a generic environment to kind of play around with things and we have a bunch of packages that enhance the experience on Raspberry Pi but those packages will probably not propagate Red Hat and Vehicle Operating System for example cause Raspberry Pi is not an automotive board. So sometimes there's a difference between like the CentOS Automotive Stream project and community and actually the final product so that's something I forgot to talk about not every package makes it all the way and this goes, the next group of slides are gonna show some slight differences between CentOS Automotive Stream Distribution and the final product as well. So what is CentOS Stream Distribution made up of? We have a kernel, we have a container runtime and all sorts of container based tools. We have an OTA framework that delivers security updates and that kind of thing. We provide logging and mechanisms for monitoring and diagnostics the usual system desafs, syslog and that kind of thing. We have various tools for development. We have a lot of health checking tools for various types of failure detection. We have mixed criticality support that's kind of like this whole software defined vehicle approach has gotten very popular and most of the industry is actually trying to reduce the number of ECUs in a care. So boards now have to satisfy many different roles. So this mixed criticality support is what this is all about and I'm actually gonna briefly describe that in a slide later on. On priority boot up, we've been putting in a lot of effort trying to optimize our boot because there's kind of an expectation in automotive to boot like really quickly. Often people talk about the two or three or four second boot or whatnot for different services. And then there's redhead in vehicle operating system which obviously has all these neat features but then it has certain additional things on top. So if you want the certified version that's redhead in vehicle operating system and you also get very safety manuals and documentation and that kind of thing. Here's another project that started in the automotive org. It's called Hurchia with an asterisk because it's going through a renaming process. I think it's on its third name now. So hopefully we have the final name next time. It's a multi-node service controller. It's kind of like a new container orchestrator but it has alternative qualities that are different to traditional container orchestrators. So it aims to be deterministic rather than an for eventual consistency. It's lightweight, there's a focus on performance. And it's also very simple and like the lines of code count isn't exactly huge which makes it easier to certify. I left a link to a blog post and there was also a recent talk about that at DevConf that goes into more detail. QM was kind of a related tool to Hurchia. This is something else we're working on. It's kind of all about name spacing containers to make sure that they don't interfere with other workloads because some workloads in a vehicle are a lot more critical than others. Like, I don't know, the breaks might be more important than Netflix, I don't know, that kind of thing. So it achieves out using various tools like Hurchia Podman, C Groups, namespaces, SE Linux, Podman. And actually an interesting thing about this QM containerized environment to each container even launches its own instance of system D. Yeah, so you'll hear a lot about ARM enablement in automotive because 90% of the SOCs deploy the ARM best. So it's part of the reason I've worked on some of the ASAHI stuff with David and Neil, their talk is soon. But that's our focus. We're also open to alternative architectures in future as the industry involves. Like, we have our eyes on architectures like RISC-5 and that kind of thing. So I wouldn't roll out those. We also build everything on X86-64 also which brings us to our next slide. That wasn't supposed to be the next slide. Which developer tools, yeah, we build them publish everything for X86 also so people can develop on their laptops like ThinkPads or whatnot. So we have VMs, you can actually spin up an instance now in AWS, all the various container tools we even have a container on Quay now so you can use those for development. As I said on X86 and ARM, we even have emulators if you need an ARM environment on your Intel-based machine. We actually even produce a Raspberry Pi bare metal image if you want to kind of a physical board to work on that doesn't break the bank. And we have a lot of these artifacts are downloadable at this link. There actually are further artifacts that you have to build yourself, but. So now this slide. These are some of our various publicly announced partnerships. So GM, Qualcomm, Luxoft and Itas. Some of them are more related than others, but yeah, it's all part of the wider automotive scene. What else, do I skip over anything? No, so yeah, I think I said everything I was supposed to say. These are just some things as an aside. One of the guys I know on the team asked me to spread awareness that the Fedora Robotics Sieg is kind of being brought back to life. So there's a lot of similarities between the stuff we're working on in the robotics Sieg. So that's kind of a Sieg that's getting some more attention now. And as we said, actually a huge focus in the automotive Sieg is on ARM enablement, with various automotive boards. And David and Neil are actually doing a talk after this and it's around the enablement work we've been doing for Apple Silicon. And actually I found that really useful because we talked about the Raspberry Pi in the past. Raspberry Pi, it's an 100 Euro board, so it can be a bit slow. So I actually find the Apple Silicon hardware, it's very useful if you look for generic ARM development environment for auto SD or other ARM based operating systems. These are some of our community contacts. You may have met them before people in the room, but we have Jeff Roll, who's our acting chair. He runs monthly meetings, which are quite nice if you want to learn more about the community. They're quite informal. We normally have decent attendance of 20 plus people. So that's a great way to informally just jump in and chat and speak informally about things you're curious about. We have Pingu, who works with Jeff Roll. And we actually have Leo Rosetti. Leo Rosetti is often our point of contact for the Sophie community in eclipse suffered by a vehicle. Yeah, here's some various links to those monthly meetings I was talking about at Jeff Roll, post most of them on YouTube in the end. We have a GitLab where you'll see all our automotive artifacts. If you can't attend those, if you don't want to attend those monthly meetings and would just like to informally ask questions, I find the matrix is very good, as well as the mailing list. They're all very responsive ways of communicating with the community. Yeah, and that's kind of it, unless there are any questions. Looks like I'm good. Thanks very much, guys. You made my job very easy. Thank you.