 Okay, first, a few words about myself. My name is Mahdi Shura B. I am team leader of HPC software team in AVL software and functions. Headquarters in Huygensburg, Germany. I have more than seven years of experience in various industries, building with safety critical systems and on, and yeah, other kind of mostly embedded systems. I have visited a couple of transport museums in Germany and other places, and I have experienced cars back in 1920, so I can say I have more than 100 years of automotive experience, maybe. In HPC software, we're dealing with enabling high performance controllers for automotive use case, and also we are offering industrial embedded solutions to our customers. Okay, agenda that I'm going to talk about is, okay, what is self-prodefined vehicle? We look to challenges that are on the way of SDV and what are the key components of this topic, and we talk a little about collaborative ecosystem and how open source can help this, and after that I will present Huygens, some of our developments in AVL software and functions about self-prodefined vehicle. Okay, the first question is, what is self-prodefined vehicle? And this is my attempt to defining self-prodefined vehicle after that. Yeah. If you want to answer this question, a better, a good way is that we first ask what was or what is hardware-defined vehicle. A hardware-defined vehicle, which is up to now the current development of current automotive industry, is that we use software as an enabler to do the development of a vehicle, complete automobile, to push it toward SOP or startup production, and after that, this design and development will stop, and the production line will continue developing, producing, manufacturing this vehicle for a long time, maybe for a couple of years, and after that this development is, this production is dead and this vehicle is no longer available. But with self-prodefined vehicle, the development cycle is like this, that after development and after startup production, the development cycle will not end, and this will continue as long as the hardware is capable to get new upgrades, and that vehicle has new features through software. So software has a continuous roll after a startup production. As you can see, in traditional way, we had recycle development, and this is one-time development, yeah? And by having software-defined vehicle, a new layer of processes should be around this vehicle to actually for this continuous development after a startup production. If there is any doubt that still whether software-defined vehicle is for real, I have a proof here. If we, yeah, despite the fact that first vehicle invented very, very long time ago, some time around 1880, when we look at a first cell phone and how smartphones progress during last 50 years, we see that in 50 years the cell phones and smartphones become a couple of hundred million industry, yeah, in software. But vehicles does not follow this sort of progress during time. Okay, one reason for that is that vehicles are dealing with safety critical requirements, and mobile phones are not just. You can use it without any safety critical requirements unless the battery explodes in your pocket. Okay, there's a reason for that. If you now look at the smartphones today, you see they have a very common platform, yeah? A large screen, a couple of cameras and charging points, and most of the smartphones in the market has this set up basic hardware platform. What is happening in vehicle, in automotive industry, and especially after electrification, because by having the electrification, no longer the mechanical features of a car is competing point for OEMs, yeah? And now OEMs need to focus more on other features that can be created through software. Especially after electrification, we can see that automobiles are going to be very similar to smartphones, yeah? A platform that can handle different softwares and get new updates through software. So this is happening, this is happening. Of course there are challenges in this way. One measure could be that we look at how much lines of code this normal vehicle has and compare it to other systems. For example, in this chart you see that a normal vehicle nowadays has more than maybe 100 millions of lines of code. Comparing this to, for example, Android, we see that it is less than two million lines of code. And by having, and by implementing the concept that are in STV, this is going to be tripled, maybe more than 300 millions of lines of code. So we're going to face a huge complexity in STV topic. And on this topic, there are also other challenges. One is that STV needs an architecture, a software architecture that lasts longer time. So we're talking about that development should continue after start of production. So this software architecture should be able to get new updates on the software. And also the software is so complex, so there is going to be some sort of platform independence so that this software can be easily migrated to another platform, another hardware. And also this complexity is not just about software. When software gets bigger, also the development cycle should be reviewed and this is also a big challenge. And of course, up to now, there was a lot of developments in automotive industry, the vehicle that nowadays we are using and we are using has a good level of safety, has a good level of maturity. And we can adjust easily through them, through all the developments out and start everything from scratch. So still even in software defined vehicle or even the transition lane, transition to software defined vehicle, old software modules and older developments still needs to be reused. And what are the key components of software defined vehicle? We're talking a lot about, we're using a lot of terms software and software defined vehicle, but this doesn't mean that hardware is negligible in this concept. But software is really important because it's going to carry that portable software that is going to be updated over time. So it's maybe even more important in STV. But we are going to see some architectural changes in software maybe, like what Jerry has presented, that architecture is changing and instead of having scattered issues across the vehicle, there could be central high performance or zonal high performance issues that by for example, using techniques like virtualization can adapt multiple functions, can consolidate multiple functions into one zonal high performance controller. And of course, because of this updateability, there is a need to using cloud to get updates for example, or this could be to offload processing because for example, if you're talking about having intelligent inside a vehicle, all the processing cannot happen on the local issues and some of these processing should be offloaded for example, to cloud services. And yeah, as I said for OTA update and also for V2Hs or vehicle to everything communication vehicle to vehicle, vehicle to infrastructure, this cloud connectivity is really important. And also user experience is going to be has great share in software defined vehicle because yeah, as I said, for example, by this electrification, user experience is the only place that OEMs can compete to each other. Okay, if we look at the news, we see that for example, what happened in Shanghai Motor Show this year, that lots of new OEMs are coming into market. And also on the other side, we see that traditional OEMs are or for a very long time tried to adopt agile development methods and try to get their development process very fast and quick so that they can quickly adopt with the new features needed, especially in software. So software defined vehicle and complexity of this concept requires quick processes. But can these newest startups that become new OEMs can handle this level of complexity if they continue the path that traditional OEMs was doing that? The answer is simply no. And the reason, maybe Fort C or really good explain that in this sentence that the problem is that the software in automotive is written by more than 150 different companies that and they don't talk to each other. So traditional ways of development doesn't work. Any way strategies needed. And this new strategy is the proven way of open source. Yeah. Okay. So here I'm going to present to you a couple of very limited number of projects that has a very great work toward STV or they have expert groups dedicated to STV. Of course, there are lots of projects that could be related to this concept. On the right side, you can see the members of each project. The first one is Covisa, which was actually rebrand of Geneviu Alliance since 2009 and Covisa newly in 2021. It has expert groups for data and data expert group, for example, and automotive Android operating system, electric vehicle charging, different sort of expert groups. One of a couple of notable projects that it has, one of them is a vehicle signal specification, which is for creating a common interface and understanding of vehicle signals. And another one, yeah, this is one of the notable projects it has. And it is mainly working on specifications and standards, but not really quote-versed approach. The next one that I have here is Eclipse STV, which recently, this year, announced this project. But the project that are inside Eclipse STV are very old, for example, like CovisaVal or Chariot. CovisaVal is using VSS and Chariot is about middleware in the vehicle. Different expert groups like STV Edge, STV Ops and Devs are there. Edge is working mainly in vehicle software and Ops for cloud solutions and for development tool chains. And of course, Automotive Grid Linux, which we are also using and a member of Automotive Grid Linux. Different expert groups for famous infotainment and vehicle infotainment and instrument cluster and also working to vehicle cloud and also STV, which is a combination of containers and virtualization expert groups, has a more comprehensive approach but for enabling 70, 80% of the Automotive software and yeah, of course, quote-versed approach. All right, and from here, I'm presenting you developments that we have or running in AVL software and functions. Our journey with the development toward software-defined vehicle or make a realization of this concept started with this project. We had a successful project for running this autonomous bus in a city in Germany. We got permission from authorities to run this shuttle. The main focus in this project was ADUS and autonomous driving using our own developments of AVL IUNIC, which is a high-performance controller. Briefly, I will introduce to you. After this successful experiment, we thought that, okay, we can have another realization this time including the STV concepts, yeah? Cloud connectivity, OTA update and everything. Before I present you the software architecture that got implemented and we're testing and working on, I want to quickly introduce you the AVL IUNIC, which is our high-performance controller, which we're using. High-performance controller can be used mainly firstly for ADUS applications and it is capable for running STV concepts realization and yeah, I262 compatible and lots of many, many interfaces for ADUS and sensor connectivity. And we have a couple of VSP releases for our IUNIC-ready working for generically Linux and agile release and also some certified real-time operating system. Okay, and what we are developing right now for realization of this STV. First of all, on top of our HPC platform, we run Zen hypervisor on the right side. In the console, you can see that Zen is booting. On top of Zen hypervisor, Zen hypervisor is a type one hypervisor, which means that it's completely attached to the hardware and can deliver high-performance to the virtual domains. On top of Zen hypervisor, we have a couple of domains there running. We call one of them AGL domain, which AGL application is running there and we call one of them ADUS domain. Our own developments of ADUS is there and also a VCD domain, which is a vehicle control functions. And also a Zephyr is running as a separate zone as a real-time operating system there. As you can see also here that different domains of Zen is running actually in the background. Okay, yeah, and the AGL applications that are running, for example, AGL IVI, AGL IC and other AGL applications can run there. You can see that AGL IVI is running on the display. Not very good tune with the display size, but it's working. Yeah, and different domains of Zen also are loading there. And in the ADUS domain, we have our own developments. This domain is not included and you cannot see it in the console. It is under construction. Actually, we're working on that. And the other domain, which is the domain that I'm, maybe it is more in our interest, is vehicle communication domain. Vehicle control unit or domain. Yeah, this internet connectivity is also available. Yeah, I forgot to mention that. The HPC platform using LTE is connected to internet. And we are using Mender, open source Mender as the for over the air update. As you can see in Mender portal, our device is recognized. All the information about our device, IP and everything is there and devices fully registered and available there. So what we can do, we can over Mender platform, we can create a new deployments and deploy it on our system over the air. Okay, and in this vehicle control domain, we are running two containers or a couple of containers for vehicle control functions based on Docker. You can see in the right side that by running Docker PS, this speed limit application is running. The goal is that this speed limit application, what it does is actually getting a command from cloud over MQTT and it creates some can message to control the speed of the vehicle. For example, I give you an example of use case, consider that you're driving your vehicle and a kilometer or a couple of kilometers ahead, there's an accident. And that car in the accident, you cannot see it because of care or everything, that car can send the command to cloud or can somehow inform your car that, okay, there's a hazard there and you need to limit your speed. This is an example use case. And the car is here, we are actually enabling this feature, that's over cloud, over MQTT, we're sending a command and adjust the speed through that. And what you want to do is using Mender OTA framework, we want to update this container that does this job. Okay, we can see here that in Mender panel, we are actually sending a new deployment, which is now in progress. And through that, we are updating the container that are flashing there. A deployment is done here, this speed limiter HPC, the container that is running is now should get updated. And we run again this Docker PS command, we see that the hash of container is now updated to a newer version. Yeah, a new image of the Docker, a new Docker image is now installed with V1 and yeah, the hash is new and this container is now updated. All right. And yeah, this is our ongoing work toward realization of an STD, getting powered by our experience with ADUS workflow. We want to integrate more and more open source solutions and combine it with our developments or available developments for safety critical application like ADUS and creating a working demonstrator for STD and realize this topic. And as an access step, yeah, with help of partners, we can improve this technology and ecosystem together. And finally, of course, contributing back the advancement to open source. All right, that's it. Thank you, is there any question?