 Good morning, or afternoon, wherever you are. My name is Jeff Rowe and I'm a community architect within Red Hat's Office of the CTO. I'm here to introduce a great panel to talk about Red Hat's new effort in the automotive space. Today we're discussing automotive computing with a group of program managers who are responsible for various aspects of the initiative within Red Hat. I'll let each of them introduce themselves. So first I want to introduce Whitney Chadwick, who is the Lead Technical Program Manager. Whitney, do you want to say some words about yourself? Hi Jeff, I'm Whitney Chadwick, Lead Technical Program Manager for the N-Vehicle OS program. I'm responsible for building the program ecosystem as it becomes integrated into the Red Hat product portfolio. Great. Rachel Sibley. Hi, I'm the QE technical lead for the automotive program. I'm primarily responsible for coordinating and leading the testing efforts which includes deep collaboration across all feature teams including REL as we continue to scope new requirements for the N-Vehicle OS. Thank you. Allison King. Sure, thanks Jeff Rowe. My name is Allison King. I'm a technical project manager within the automotive program here at Red Hat and I've been working with engineering teams both inside Red Hat as well as externally with partner engagement teams to help identify customer requirements, build upon them in the form of MVPs and POCs and ultimately taking that information to shape the future of the Red Hat N-Vehicle OS. And doing all of that within the agile framework to keep things fluid and keep things moving forward as effectively as possible. Thanks Allison. Can you tell us what exactly is an MVP in a POC in case people aren't familiar? Yeah, sure. So an MVP is when we are working together typically with a partner engagement team in this scenario to create a minimal viable product. So it's not necessarily something that we're going to productize but it's something that's going to showcase the technologies that we have and that we're working toward and really gives a functional increment of software without having to go the whole route of deploying it at a production level. In terms of a POC, that's more of a proof of concept and in the way that we've been handling POCs up until this point they've been more business level engagements and really trying to identify requirements timelines and really proving our concept will work within the timelines and structures set up for us by the OEMs. And finally, Sabine Vogel. Hello. I'm working as an agile practitioner at Red Hat with an automotive. I assume the role as technical project manager with a focus on functional safety and I'm working with the engineering teams as well as external certification partners to support the new requirements for the in-vehicle OS and the required certifications. So diving into questions. First, let's talk with Whitney about the overall program. Sure. The in-vehicle OS program, it's one of the major pillars that supports the Red Hat's open hybrid cloud to the edge by bringing the Linux expertise to the markets that are being transformed to the edge. The program has been in R&D mode and will continue as we move to our more formal product. We have engaged with some potential partners on collaborative efforts. Internally, we have been building a lean adult team to plan and execute on requirements. We have gotten some really good experience. We've engaged with some potential partners on collaborative efforts. And with Red Hat's already well-established presence in the upstream Linux and cloud communities, we are working to have a presence in the automotive community through the automotive sent off SIG as well as other public-facing communities. Great. Thank you. Rachel, do you want to describe the QE approach? Regarding the QE approach for the automotive program that is already well established, that we will leverage well as much as possible, the same holds true for testing. We will run existing test suites where it makes sense by testing the offering with additional coverage to specific to automotive. New test cases will need to be created or existing cases expanded upon as we continue the scoping efforts for functional safety related activities, including both gap analysis and hazard and risk assessment. This also holds true for the customer engagements, which will help shape the offering and how we plan to test. While keeping in mind we don't want to tailor to one customer's needs but instead do it in a scalable way, which will align with all future customer engagements. As we expand our testing processes and automation, this will enable us to dive back to REL to strengthen our testing practices and coverage to make it more safe and stable. For example, vulnerabilities and different attack factors are concerned for functional safety. For device input testing, which can include wireless USB or Bluetooth testing, we would like to expand our existing test suites to include pen testing or fuzzing, which would equally benefit the enterprise model for REL. As a result, we will extend our gating tests used for REL with increased test coverage based on the new knowledge and use cases that are automotive efforts render. In addition to leveraging development and testing practices for REL, we also want to reuse existing CI tooling technologies which are currently running. For example, we plan to reuse TMT and testing farm in addition to leveraging our CI infrastructure. TMT stands for test management tool, which is a standard test framework used to invoke our test drones. While testing farm is an open source testing system as a service, which is currently being used to deploy our CI workloads for both Fedora and REL. Great. So Allison, can you tell me a little bit more about some of these POCs? Yeah, for sure. Our engineering teams have been engaged with partners at various levels, from business level and roadmap POCs to determine timelines, like I mentioned earlier, and really identify customer specific requirements for FUSA or functional safety, which Sabine has touched on a little bit earlier in this conversation. To more technical efforts where teams have been embedded to produce an MVP, which replaced the partners current build system with a REL-based system. And at the same token, we've also had the opportunity to embed with hardware providers to really become or to begin our effort in becoming hardware agnostic. And we've been working very closely with hardware provider engineering teams to start laying that foundation for being able to get Red Hat's in-vehicle OS offering running on different platforms. And it's been really great to embed with these partner engineering teams because we get a lot of different insight that we might not have received otherwise. For example, how a binary-based approach with a vendor-supplied distro can provide value to developers beyond the safety, the stability, and the security that we already knew was associated with an open-source solution. Excuse me. For example, we've brought developers more flexibility through package-level changes and package reuse first having to do a full flash of the system or creating a brand new image each time they want to make a change. And in addition to this, we've been able to improve build times by up to 90%. And I know it's a small scale and it's really early on, but it's really encouraging to our team to see results like this with these various engagements. And I think the POCs have really helped us identify new requirements and learn a lot of different things about the industry, the ecosystem, in a holistic way, which is really crucial in shaping the future of our in-vehicle OS at Red Hat. That's great. Savin, how about the functional safety approach? So one of the important requirements for this offering or a part of the offering is being ISO 26262 certified. Any offering in the automotive industry is expected to comply with the ISO 26262 standard to be accepted by the broader automotive vendor community. So that ISO standard is a multi-dimensional set of guidelines for asserting fitness for purpose, for safety, critical applications. And our foundational assumption is that the core components of REL and the long-standing processes for creating it are already high-quality material that is generally suitable for certification under these frameworks. In case of software, that is used in various parts of the car. So the certification processes include validations on how the software is built and how it is utilized in the car. These arguments will lean heavily on the development heritage of REL and open source more broadly, as well as on our proven track record of fitness based on the widespread use of REL and the derivatives in critical applications over the last 20 years. So these arguments may also involve creating non-trivial new runtime testing frameworks that Rachel already mentioned. So what do you suppose are the challenges for functional safety within automotive? Yeah, so as I already mentioned, any offering in the automotive industry is expected to comply with the ISO 26262 standard to be accepted by the broader automotive vendor community. Such a software certification has not been done before in open source by any other organization. We're going to build a community around this initiative so that anybody will be able to participate in development of the methodology and benefit from this approach. Community members would be able to become specialists in this methodology. Through this public exposure and community, we will be able to jointly build a way to certify complex software stacks against the safety standards targeting different industries. Just to mention, Redhead has newly initiated a special interest group for automotive a few weeks back, and the link is shared in the notes section. It is also worth mentioning that we're working with our consulting and certification partner, Exida, on figuring out a balanced approach to the certification. Redhead is in the unique position where we can pull together the subject matter expertise and review rigor of the upstream communities, combine it with integration and stabilization value of Fedora, and enhance it with development practices of central stream, quality with the extensive review and testing practices of rail development cycle, and provide evidence of the increased confidence with use based on customer adoption and recognition of the stability, reliability, security, and quality of the Redhead Enterprise Linux operating system. The certification narrative is pulling together all those aspects into a coherent story, not relying on a single aspect like testing, but rather on a combination of all these factors in complementing each other in balance. Rachel, how about some of the challenges with QE? As far as the challenges go from a testing perspective, one of the biggest challenges so far is testing on real hardware. For now we're running our CI workloads using a virtualized environment, but eventually we'd like to have access to edge devices, possibly Raspberry Pi or NVIDIA just boards. One, and then later on accessibility to the OEM boards and testbeds. There's work already started to enable edge devices in Beaker, and for those who don't know, Beaker is a framework we use at Red Hat for hardware inventory, OS provisioning, test harness, and visual results that database to name a few. However, it has been quite challenging from what I'm hearing to configuring these devices for remote provisioning where we can tie it back into our Steam CI. There's ongoing work to enable several NVIDIA boards currently, but there's an existing bug which can, which is blocking progress where it requires manual intervention to finish the installs, which is not suitable for automation. It's still unclear whether or not we'll use Beaker or some other external service where we can access remote hardware clusters, edge devices to run our workloads. In addition, depending on the conversations we have with the OEMs and continuing engagements, we need to better understand what are the boundaries that we plan to deliver in the offering versus the OEMs, what the OEMs will provide. Part of that is understanding what we will be responsible for testing versus the tier ones in the OEMs. As we learn more with the proof of concepts and customer engagements, we'll be able to make better decisions regarding hardware accessibility and what's feasible for us to test in-house or whether we can use something similar to distributed CI at our customer sites. Allison, I'm guessing you're also encountering some challenges with proofs of concept. Absolutely. As great and successful as the POCs and the MVPs have been up until this point, it's still difficult to get customers and partners to allocate the resources to really embed and work with our engineering teams early on. On the same token, once we have these resources, aligning them with the life cycles and timelines across OEMs, hardware providers, and internal teams has really made it difficult to determine the feasibility of achieving milestones that align not only with the OEM model years, but also the Red Hat Release cadence. That's more on the business side, but on the technical side, we've also ran into a few challenges. There's definitely a learning curve associated with moving toward a binary-based approach. We've spent an extensive amount of time mapping the sources for software components to bits that are available in a binary distribution ecosystem. This comes as a result of the fact that most OEMs and developers are either starting from scratch, migrating from a real-time operating system, or from other built systems, where they pull these things together in an entirely different way. Along with the mapping, also comes some education and retraining on the new processes. That's a great learning experience for all parties involved. Something else I'd like to piggyback on that Rachel had mentioned is we've experienced some challenges in gaining access to partners' actual automotive hardware and testbeds. In our experience, this embedded hardware hasn't been set up for full remote access the same way servers are, and that makes it difficult to collaborate and troubleshoot in a distributed environment. This challenge has definitely been exacerbated by COVID restrictions. There's been times when our partner engineers could not even get on-site to access the hardware systems in their own offices because of restrictions. But challenge brings out creativity, and the teams have really done a great job setting up creative work-arounds using webcams and Zoom and keeping things moving forward even with these challenges. In the same spirit of creativity and pushing things forward, the last thing I want to outline is not as much a challenge, but an opportunity for us and for the automotive community as a whole. Early on, we didn't have a SIG or a special interest group. So now that we have the CentOS Automotive Special Interest Group, we have the chance for future POCs and MVPs to contribute to development in a public area versus in closed environments. So all of the progress and all the lessons learned can be open-source and shared with the greater ecosystem. And maybe to wrap it up, Whitney, if you want to talk about some of the challenges the overall program has been encountered. So I think this is a new space for Red Hat. So building a new ecosystem means we're hiring a lot of new people, we're taking a look at a lot of our existing processes and we're refining those processes to be more efficient, more agile. And this takes a lot of evaluation and discussion internally. While we have the rest of the externally facing team building that are presence out with customers. And like I've already mentioned in the communities, the other piece that's obviously going to be very anybody who knows anything about automotive knows that the functional safety work to gain certification is going to be extremely it's going to be a lot of work. And so and it's really going to look it looks across the entire company of all business units and all functions to make sure that we are we're practicing what we say we're doing in terms of quality and safety. And so that's going to be a major challenge just making sure that we get all of the T's and I's dotted. Anyway, so that's that's really from an internally looking person like myself. That's those are the challenges thus far. That's really great insight. Thank you. So although we pre-recorded this panel, we did want to make sure to leave some live Q&A time. So please feel free to enter questions in the Q&A box and those of us who are here live will be able to answer. I want to say thank you to all of our panelists. Thank you very much. Be happy to answer any questions. If you want to put them in either the chat or the Q&A box we'll keep an eye out for them. Yeah, hi. I'm not able to see any of the questions in Q&A right now. Okay, so not Q&A. So if you do have questions make sure to add them in the chat box please so that we can see them. Yeah, so please everyone if you have any questions just put in chat box. Because we have all the speakers live so that will be so great to answer any of the queries you have now. Any questions that come up? I also want to make sure to extend an invitation to everybody to the CentOS Automotive SIG we want to get as much participation there as we possibly can. We've only had one meeting so far and we will be doing another one. There is a question in Q&A. Is this initiative focused on traditional automotive traditional cars or electric vehicles? I could take that or any of you probably could too. Go ahead. There you go. So the level that we are addressing the automotive offering at is the operating system so it's not actually determined the drive style or the drive really determine it. It can be either regular automotive regular cars, gas cars electric vehicles or anything else that comes up. So we would of course like to promote electric vehicles so we will be on charging and I know that there are open source options for charging that we will likely be integrating but we're not going to be limited to just EVs available for all cars. Thank you for posting the CentOS SIG so yes I think other questions like how is the compares with some of the existing platform with Apple car, Android car or maker specific platform out there. Would you like to tackle that? Can you repeat? I mean I can kick it off and if anybody has anything to add afterwards feel free. But how we're going to be different in the industry compared to some of the existing solutions is first off being an open source solution that's functionally safe certified. Sabina talked a bit about that during her sessions here and being functionally safe means that we are we're a step above some of the other solutions in the industry that already exist and secondarily will be different because we're striving to be hardware agnostic which will be a game changer really in the industry. I would also throw out that having this from the point of view of a binary distro that can be customized by the customer will be a very different from some of the other solutions. The ones mentioned Android Auto and Apple CarPlay are actually kind of they're at the very top end of the stack so there would have to when you use Android Auto or Apple CarPlay you are going to have a screen from your phone on the screen in the car and so there has to be an operating system running underneath that screen in order to accept the input and that's where the Red Hat Automotive Operating would come in. On top of that as well some of the existing solutions in the industry now require developers to curate their own distros and then manage those so being that we're running it will be a Red Hat product you'll be receiving the scalability the security and the stability that's associated with Red Hat product and an open source product as well so it won't be on each individual OEM's developer team to manage their own curated distro they'll be able to take advantage of all the work of our internal teams as well as the open source community. And just to expand on what Allison said earlier about being doing the certification path Red Hat wants to be one of the very first certified Linux versions of distros running in the car so there's a lot of work that's going on that Sabine had touched on her parts where we're going to make a lot of strides and a lot of changes to make sure that we're doing the right thing and checking all those boxes to make sure that we're functionally safe for the customer. Yeah I think that answers the question that Jagdish might have. So we're not having another question we would be happy to answer any questions further through the breakout room or definitely feel free to join us at this CentOS SIG the next meeting, the next official meeting will be in about three weeks I think two and a half weeks and an interim working session in between there. So bring your questions and bring your hammer and screwdriver and help us with this. Thanks a lot for joining in. Thank you everybody. Thank you everyone. Bye. Bye.