 Okay. Then let's welcome Johan for the next presentation. Johan is going to tell us about Linux in cars. Yeah. So, hi everyone. Thanks for having me. I'm actually joining from a car. So, I just want to double check. Is the audio okay, Volker? Yeah. Your audio is perfect. Sounds great. Yeah. So, last weekend in the summer house, a slight change of location really late before. So, praying to the LTE gods. But yeah, it will be fine. So, hi. I'm Johan. I actually work for Ambition, one of our sponsors. I also run a company on the site called CodeRise. I run a conference called FOS North in Sweden that some people might recognize free from. I've been doing lots of cute embedded Linux and with the focus on automotive in the past decade. I also think you're with licensing and so on. So, yeah. I just want to say before starting here that all opinions are my own. I agreed to talking here before my employer decided to sponsor. So, these are my own personal views. Before we dive into the whole problem space, let's have a look at how does an infotainment system look today. And this is a blurred picture of the architecture from Geneva, which is a standardization organization that works with open source solutions around this. And I can just overlay it with these boxes where we see that we are at the very top. We have apps. And these are, of course, vendor specific to a large extent to sort of make it car specific and get that brand feeling. And then you have a huge number of services. This might be anything from workshop production, telephony, media playback, whatnot. Everything that goes into a car, all the services that you need. And then you have a base platform at the very base bottom, which is a classical embedded Linux system. And if we look at this and see where do we have open source, we do have open source in the base platform, we do have Linux. Some of these services are largely based around open source to various degrees. And some at the very top, the brighter colored ones. There is actually no intention to make them open source because that's where sort of the brand differentiation comes in. So then it's more up to the auto maker to to make that open source rather than to to the community. I actually like to color this picture this way. So what is not open source, we have lots and lots of red boxes in here that would be good to address. And why is this? So my takeaway from this is that you have requirements that are only piled on project from project, you copy the last requirement setting, you add some more, you copy the last project again and add some more. And sometimes you can really tell that this requirement is actually a functional requirement. And this one is a supplier that cocked up. So they need to clarify something because last time they had a fight over it. And when you start like this from a very strict requirement sets, of course, open source components doesn't fit one to one, you need someone who steps in between and make adaptations or let's call it integration work that leverages the open source components into building something that fulfills the requirements. And that's one of the parts that is really hard, because then somebody needs to pick up the open source component and then really drive it in that direction and sort of invest in it and do that together with the community. So even when you do that, you don't just take the component and put something proprietary on top of it. So we really need to invert the direction here. You need to start from what's out there that could help an car maker to get the experience they want. And then to specify what has to go on top of the open source components of the shared platform rather than the other way around. That's the industrial problem, I'd say. Let's see. And I mean, why is this a problem? It could be one way to... One thing is to say that we want open source and it's a good thing and there are ethical aspects with it. But even if you look at it from the business side of an automotive maker, it's not invented here, driven development where you start from your own requirements set and sort of everything has to be custom made to your needs is a very expensive way of building anything. You also end up in very strong vendor lock-ins historically. I've been to numerous OEMs in Asia, US and Europe, and it's a situation throughout the industry. The maintenance costs are huge because you maintain your own software stack rather than using what's upstream. That's also one of the risk of falling behind. So it's quite common to sort of adjust an open source component and not follow along, which means that at the end of the day, you're maintaining your old fork by yourself anyway. And really, the biggest one is that you can get access to smart people outside of the automotive industry, which is a huge boost because software in automotive is not where all software people work. It's a rather small niche. But what are the open source actors here? So this is just a very quick recap from what I've seen. So 2009, Genevieve was started, formed expert groups, had industry meetings, discussed on how to do this. And Genevieve to me is a big driver in making sure that we actually have a Linux foundation for these systems these days, even though the services on top aren't open source. They build components that they then will create a development platform to demonstrate how the components can be integrated. But components are generally reusable outside of Genevieve. Since a few years back, Genevieve sort of focused on the coexisting with other systems on how to integrate the Linux-based system into a hypervised system with other systems in parallel and so on. So the component development has, in my opinion, slowed down a bit. There is also another organization joining the market. So 2016, the Automotive Great Linux project was started. This is run within the Linux foundation. It has a similar structure, so expert groups, so the various topics, meeting, writing requirements, trying to find someone to implement it and build things. But I'd say that AGL in general builds their development platform first and the components are built for that platform, which in my experience means that some of the components are harder to use if you don't buy it all. They are more tightly integrated. Both these organizations come from this classical direction that we have an expert group. We write the requirements, and then the intention is to fix an open source component to suit those requirements, but they still come from that perspective. The top down, this is what the car needs, and then we build it. So it's kind of interesting when we had this third one entering. It was announced in 2017. The Polestar cars are starting to reach market now. So I'd say 2020 is the year when they're active. The same goes for the other organizations. I mean, Geneva was formed in 2009. There weren't Geneva-based infotainment systems back in 2009. This is basically Google and the OEMs. They have a very strong infotainment focus. They have a fixed offering. This is what it is, and then it's up to the OEM to integrate it. They've been able to turn this requirements situation around, which is good. But at the same time, I'd argue strongly that this is not an open source solution per se. I mean, the Google Automotive services are definitely not open source. It's something that creates a bit of movement in the market, but I'd say it's not a big open source platform. I wouldn't be satisfied as an open source proponent if Google dominated the market. That wouldn't have solved my problem. So why is this? I mean, we have a set of OEMs. They act with suppliers that are usually called Tier 1s, Tier 2s, Tier 3s, depending on how close they are to the OEM. So as you have an infotainment device manufacturer that produces a silver box, so the actual electronic device that you put in the cart to go with the software, but of course they source a lot of the software from outside like speech engines, navigation systems and all of that, and they do a lot of the software integration. There are quite complex relationships in here, and the Tier 1s supply different OEMs in different organizations, and sometimes a Tier 2 to one OEM could be a Tier 1 to another, and so on. The interesting thing is really what's holding us back, and my conclusion after more than a decade in this is this. You need to scratch your own itch. Who are the members? Who are the ones contributing and driving the software development in these open source organizations? And to a large extent, it's not the OEMs who solve their own problems. It's the OEMs paying someone to maintain a component, and as soon as that stream of money goes away, the maintenance goes away as well. So you need to really bring the software closer to the OEM, and then we clearly see this in many cases. I mean Ambition is one case where that happens, but it happens with other OEMs as well, but this I think is one of the real factors that needs to go into change the industry. Unless you scratch your own itch, you're not driven to fix the complex problems behind which are really more of a business structure or managerial than a technical issue. So what can be done? What challenges do we have? There are tons and tons of challenges. One of the things that I try to tell people when doing interviews or trying to get them to work within infotainment is that this today is primarily not an algorithm or doing cool maths kind of problem area. Then you can go to autonomous driving or do voice recognition engines and smart navigation algorithms. But for infotainment it's more about the integration of lots and lots of features. And this is where you basically have to pick and choose good infrastructure for various problems and put them together into a complete system. And I want to relate this then to what happens in the open source space and primarily what happens within KDE. So I mean where are we close together? Where can we touch base and actually help each other? So I picked out some areas. There are many, many more. I've worked for more than two years in the same project and we've solved more than six projects. It's basically weekly project. So if you want to hit problems or challenges, just reach out and I can give you one. But the very first one I'd like to bring up is screen dimensions and orientation. You have extremely wide screens in some cars where it fits into the dash on the width. But you also have setups like the Volvo and the recent release new S-class where you have a standing screen. You also want a single user interface to work in the front where you might have an extremely wide or A4 sized portrait screen with the rear seat where you generally have a smaller screen integrated into the headrest of the front screen. And a good framework for that is needed. So Kirikami and really emphasizing the ability to move between screens and to provide patterns to do that is a really good starting point to get closer here and to get contribution. Another thing is collaboration between screens and users. And I mean this is where everyone's going now. So I mean if you buy a high-end car this is probably where you are to some extent. But you want to share information. You want to be able to view the same media contents on various screens. You want to be able to pass let's call it video streams or links to video or whatever. However you do it technically between the different screens. And this is where technologies like KDE Connect comes into the picture. I love KDE Connect. The game changer to me is the simple use case of audio docking one of my phone rings. But to take that further to allow to sort of share, cast and move things in between screens and devices. That's exactly where we want to go. And then that's exactly what the whole industry is looking for a solution. And then KDE Connect could be part of that. That would be awesome. And I mean having plasma big screen in there as well excites me because that's very close to rear seating for the system. Is it possible to connect that to KDE Connect? How can we make that generic? Can we allow KDE Connect to sort of be the base for a wider casting, sharing, moving framework? There are big opportunities here. And even more when it comes to this casting and routing and on the audio and media routing is one of the things that makes car systems very complex because in a high-end car you have many many cameras for surround views. You have cameras they can create a projection of the car from the from above. Multiple cameras inside multiple microphones so that you can actually do video calls and and text recognitions from the various seats and then locate where the sound comes from. So really building these advanced media routing and audio frameworks is important to validate Linux but also to Linux with the community services on top of it like PipeWire and Pulse Audio and so on on top of it. And if this thing can be connected to the whole collaboration between screen story that makes it even stronger. We have another one that I'd like to bring up. I'd like KDE boot quickly. I run a pine book and I'm impressed over how fast it runs on actual low-end hardware. Let me call it that and then Pine 64 can say what I'd like. But one of the big engineering challenges that I face is really that we have a legal time limit for two seconds to have the rear view camera up and running and generally you want to have warning sounds before that and traditionally you have a requirement to have a full let's call it desktop experience but the full infotainment experience and an interactive system up by four, five, six seconds depending on the brand. Me being sweet and it's still summer but I would hate to have to wait for 15-20 seconds to be able to turn on the heat in the seat and then start defrosting the window. You need these things quickly. So keep it light, keep additional features optional, make it possible to load things afterwards to load things on demand so to speak. These are important things to make the components reusable to be able to actually integrate them in this type of system and then I have decided to add two more challenges that are good to be aware of but are hard to solve in a generic enough way and also in an open-source way because they involve non-open-source technology. So one of the trends is that you have a hypervised system in these setups and to some extent you have another system be it for instance QNX or integrity to drive functional safety subsystems or even full Android systems sitting next to you and again here the sharing of video and audio and compositing of graphics and resource sharing is important factors to take into account but also sharing state how do you share your contacts? Do you have a centralized service for contacts and so on and that then leads us over to the functional safety area where you have things like the telltales in the instrument cluster it might be if you have an augmented reality system that you actually drive according to all these things that are sort of puts you in the risk of hurting something damaging equipment or even killing people if they fail and here you generally don't build the systems on Linux but you need to be able to coordinate the graphics between the different systems. The QtSafe renderer is out there as one example of how to do it. It's basically a glorified BitBlitz but it's written according to all the process rules that needed to get a TIF approval and to be a part of a functional safe system. So it's it you need to have these flexibilities in and now Folker is counting down quickly. I'm talking too slowly so yeah there are many many more challenges and I love to speak about more challenges than the ones I've talked about but why am I even here? I want to tell you all keep on being awesome and keep on building infrastructure. I mean many years ago in a rainy summer I did this MetaKf5 let's call it embryo that were later picked up by the community in Folker which is great because I did not have time to maintain it but building KDE frameworks providing Kirigami, providing great documentation and being helpful that I mean these are great things that that makes KDE technology attractive and even though you probably will not see a plasma interface in an actual car produced by an OEM the technology the underlying technology is so close by so you probably already share more than you think between your desktop between what you actually work on between what you actually improve with the car industry and having the car industry use it would mean more use cases more resources to to fix issues to to hand off the rough corners and to contribute back so I really hope for this to to move closer and that means I made it on time I think it says one minute left on the on the private chat from Folker so thank you very much for listening I hope I made some sense even though I had to run parts and through parts of the slides and I think it's time for Q&A and thank you for sticking perfectly to the to the schedule we indeed have a few questions the one most on people's mind seems to be what kind of car are you in there I'm I actually tweeted about this so as I made some fun of it a few years ago I saw an ad for a BMW 7 series and they call the backseat the executive lounge I'm in the backseat of a 12 year old BMW 5 series where my 8 year old son usually sits so I had to move over like old food stuff and to to actually be able to sit here so it's very far from the from the executive lounge but it's it's an old BMW okay next question is what form form factor Katie is used to our cars most most similar to desktop tablet phone and start changing it depends on the brand the lots I mean the the the difference between a cheap car and an expensive car isn't much bigger than you think hardware wise so it's a high end car basically has a high power laptop integrated into it or multiple laptops while a low end car has something like a cheap Android tablet in there and then I mean that's where you've seen Android early on where where the OEMs or their suppliers actually did the porting but there's there's a really big difference in in how much money you're willing to throw on the hardware depending on the car but I'd say in in general it's it's ARM systems with some sort of OpenGL capable GPU at least and and then it's just a matter of do you have half a gig of RAM or do you have 16 32 gigs of RAM and then how many cores and so on okay and the next question is will cars allow side loading of apps this was actually a discussion in in an architectural WhatsApp group that I I'm a part of at work they will be app oriented I think where we're basically because you can't have these big projects where you build a single release for each line you need to go towards an a rolling release model and you need to let different parts of the software develop at different cadences if it would be presented as happy to the end user is one question the other one is is the end user even allowed to stall something or do you get like an options package that that simply defines your applications and side loading is even one step further I don't know it's a it's a management question I would love to be able to I would even like to be able to even though it would void my warranty because you have a slight loader car that would mean that you can really bring it forward and and warranty for for the infotainment system might not even be be something that you worry too much about because it's already void right um then the next question we have is how much do you usually upstream when developing at an OEM um is there a tendency or effort to upstream more I would say that historically it's been very low I've been in projects where you actually pick the version of all the components at the start of a three four five year project in order to be able to stabilize them as you put it and that basically means that even though you you upstream something you're you're probably three or two five years too late in doing so so nobody's interested in it and there's also the the the issue that the suppliers are paid to to deliver the function and not to work well with upstream this is one of the reasons for me joining ambition because this is an OEM stepping in and taking the integration responsibility and I mean I brought up some of the advantages of moving closer to open source and maintainability is one and there we're actually fighting very very hard to find a good way to upstream and I I do know that we we have open sourced part of our solution and and we're working on I mean it's it's almost a political work to to enable it within the company how do we do this how can we allow people to do it but I know that we are moving in this direction and I would assume that other engineers are moving in this direction but I don't know where other OEMs stand on this okay I think you have already mentioned the already answered the next question on how closely you are following upstream that leaves the last question on how complicated is all this with the conservative software lifecycle in the automotive industry and that's that's the whole complication that the problem is that you're building a piece of software for a specific car specific hardware device that you upgrade maybe every three years and the whole industry needs to move to a rolling release model somehow or to decouple the software development from from the from the car but of course that that clashes a bit in how you traditionally sell and and run these companies because if you get the newest software even in the in the cheapest model and the high-end one at the same time it might confuse the customer base so it's I think it's necessary the alternative is that googles eats the whole industry as they ate the mobile industry and and they do a rolling software release so and and the the OEMs there simply have to live with it and I think that's where it will land