 Okay Good evening, ladies and gentlemen, I'm Jerry Zhao from Panasonic Auto Motif Today on behalf of AGL virtualization expert group, I will introduce how AGL is approaching software-defined vehicle Actually together with me there was a co-speaker Hayden from AWS leading the container and the mesh expert group. Unfortunately, he was sick today and not able to join onsite, but he will be online and if you have any questions, you can ask on the virtual platform I hope you have already joined Dan Kochi's session in the morning He mentioned about the club native has been a hot topic in the automotive world and AGL is Approaching this software-defined vehicle for many years. So for this software-defined vehicle It actually enables OEM and tier one to develop their software Independent from the hardware so you can develop the software and deploy it to any hardware you would like to have and Today I and the regional Hayden will shortly give this Presentation of also software-defined vehicle, especially our work in the vert eG and container eG Regarding the vertio, which is a common device virtualization framework and also the container and Container orchestration framework So let me first go through about the virtualization expert group up which we Focus on decoupling the software from the hardware with the standard device virtualization framework where they all Let me first to give a very brief introduction of a gel virtualization expert group it was started from 2017 and Nowadays it is focusing on applying and extending where they all for diverse automotive use cases for AGL So first let me talk about some background of the virtualization so as an as shown in this picture it actually an ear of changes in the automotive industry that cockpit is Transforming towards fully digitalized and a lot of devices and the displays are going to be be Unboarded to the future vehicles which we call it cockpit or cabin and this kind of a distro Sorry and this kind of a lot of devices and display in the system and boarded to the Future vehicles need a lot of easy use if the traditional architecture is launched however, that will be costing a lot of Money in the hardware so and it will also increase the significant significantly for the software development so a common way that in the in automotive world is using the virtualization solutions like such as a hypervisor to combine series of domains on the same hardware and virtualization is actually Powerful in having different Domains with different function safety and real-time real-time requirements However in the automotive computing architecture, there are two Two essential problems regarding the device virtualization, so which I explained here. So one is that Actually for different car models and car generations They may have completely different set of devices and even for for same OEM For different car, they probably need different devices different displays different models which cause a big fragmentation in terms of the hardware Point of views on the other hand as I mentioned in the previous slide if the Currently automotive world using a lot of easy use maybe Maybe 100 or more which is a really high distributed architectures and if you added more software functionality It will be a great conflicts between the optimized allocation policies of applications and devices you will be confused that to put to put the application to wear so This kind of issues will will cost the software dependent on the Beneath hardware Architecture so we even we thinking about the single system the similar problems that happens because even you Consolidate the multi easy use or multi hardware into one single system. You still have a Multiple VMs and for the application there. You still need to decide which VM it should be Addocated to and the which device to be attached to which VM. So this is the traditional problems in automotive world on the other hand, there is also a Currently popular trend in the auto-multi world that people would like to First develop their software in the server or or cloud. So which is called the virtual ECU So that means you developed your automotive applications in in this kind of virtual environment but that actually also Relate to another issues that the currently cloud and server hardware are completely different with the Automotive edges, especially in terms of the peripheral devices and even different to cloud have their different hardware Architecture which also cost the fragmentation across the multi cloud So there it will be an issue when when when having the hardware between multi-clouds and even and also the hardware different fragmentation between cloud and automotive edge so with all the problems we Summarize the before we to achieve this kind of software Defined vehicle. We need a common device virtualization framework to completely decouple the software Implementation from this diverse target across vehicle variants generations architectures, where is a single or multi issue? What kind of hypervisor is using and also this kind of development environment real or virtual ECU and Ideally from the application point of view what you will see is only a virtual devices that It can call to the same interface no matter what kind of a hardware Structures it is under this virtual devices so with this background a gel is continuously working on the virtual and We have already developed this as a common device Friction framework for the AGL So this is the general General picture of what we are doing in the AGL. So we Using the word as a standard device virtualization to establish a complete healthy ecosystem AGL to enhance the Interchangibility and interoperability in various scenarios including hypervisor environment non hypervisor environment multi issue environment and this cloud native environment So I will break down Step by step and first I will give you an introduction about what are the pains? Around the virtualized the AGL in the past You know in the past though when there is a no common interface is AGL has to adapt to arrow every single incompatible interfaces provided by hypervisor and stock vendors with their own solutions which is a great fragmentation and The AGL will have a great dependency on the specific virtualization solution because you cannot adapt to every Interfaces with the community resources and this will definitely Has been a barrier for the virtualization development in the AGL so in order to solve that problems we Enter the standard virtualization framework word. I owe which was actually Developed in 2008 as a hypervisor neutral wheel in the server or clock world and this has been very Successful in the service in the server world since the 2008 but actually it is all focused with the server related peripheral devices like Blog or NAT this kind of things to come in the In the server world so by extending the word to the automotive use cases especially To adding the support of multiple Vehicle related peripherals which I will introduce in the in the later sessions we Have a successfully constructed this so common interfaces and implementation for the Paral virtual devices which makes the the fragmentation to the limited to the to the minimum and This kind of a common interface defined by where they all largely improves the committee and encourage the the ready a BSP for the virtualization and it enables a Interoperability and healthy competition and efficiency in the development of a GL virtualization So regarding the word I owe hypervisor What I work for the hypervisor environment thanks to various Contributing companies like open synergy linear all in the in the word DG we have a successfully supported the most of the multimedia devices necessary for the common HL use cases and we so in 2021 we supported some basic and devices for the base use case and and multimedia use case like IVI and IC and the HL has successfully Launched this word our framework as a standard device virtualization framework in the 2021 and in 2022 before they're enlarge some more advanced these advanced the multi media features like camera like a video like this Bluetooth and So nowadays we can probably say that the word L in the for the hypervisor environment actually already covered the most of use cases for the existing a GL and definitely we will completely the supporting more features make this Word L able to support all the use cases of a GL So after this a great success in supporting what I owe in the hypervisor environment, we haven't stopped our steps We actually imagine the world of what I owe to be used as a common device virtualization framework which can be used as a well-defined develop how Which can further reduce the fragmentation across socks and encourage the a GL a ready BSP able to portable to anywhere So We also have to have also extend this kind of a original Automotive edge where they all interface back to the cloud the cloud server world Enable a common interface between the cloud and that so that you can have achieved the complete environment parity between the cloud and edge Oh, sorry so by doing all of this we have maximized the Comparity Comparity of the age of software among socks Word or numbered or cloud or edge environment and we This is our automated to go to have this kind of a device virtualization across the multi levels So regarding this work for the non hypervisor environment We have finished the design and implementation of a common Where they'll based how layer which we call where they'll look back Which is portable to execute on both native and virtual? Environments, so this has been already verified with a blog Random generator and input devices and in particularly we added the touch sensitivity sensitivity control features which was cooperated with IVIG to Fulfilling their product readiness IVI features So we're ready to start the next step about the future supposed to the more product related Agile unit activities from the IVIG and ICG so regarding the architecture and the implementation details I will I'm glad to Say that we have another session Just after this This session so in the same room by Mikhail from virtual open system. He will give a deep dive on this topic So on the other hand, we also extended the Traditional word I will framework to a multi issue or say multi sock architecture in particular we are working with the display so we develop a unified virtual display based on retail GPU and This can be established to share integrity the control of multi display play on distributed SOC system So it has two Features which first you are mapping you can map in the a multiple physical devices physical displays of the cockpit or smart cabin into a single large virtual display So this is a from the physical world to mapping to a virtual world and all the application can just render their their graphics to the arbitrary region of this unit is a big unified virtual display which enables the applications can be Render on any displays So by so by doing this So Panasonic has created this kind of framework to change the current situation that the displays is tightly bonded to the Display and hardware so that original legacy HMI system has the Significant strict restriction on this kind of relationship which will will cause the The harmful impediment for the cockpit UX and for developers you can you don't have the Flexibility to develop the UI UX and to put the contents your desire to put on the correct place and By developing this unified HMI system We can have a full flexibility on this issue and a function display relationship for the cockpit UX innovation Which you can just modify your your Just adjust your your applications to any display you want So before going to the introducing the technical details. I would like to show you a Video to illustrate this idea a demo environment This is the configuration of the demo equipment. The window manager is integrated into this board The window manager sends graphic rendering data to the ECU for EV display as well as the ECU or tablet connected to the instrument cluster In addition images of the actual automotive interior and the Hado rendered onto the screen of the desktop computer on the left Now let me demonstrate how multiple displays interact with one another using the window manager in this environment First I would like to show you how a HVAC app can extend over multiple displays Including EV hide and instrument cluster The HVAC application is integrated only into the window manager But the information can be transferred from EV to the instrument cluster or displayed on HUD and a tablet Even an ECU without the application is capable of displaying the information Moreover one display can be spanned across multiple screens to create one large display I Will show it by using this navigation application The navigation app can present the information on one screen for EV or two screens using part of the instrument cluster display as Demonstrated it is possible to stretch one display across multiple screens In short with a window manager HMI applications can be managed cohesively to achieve flexible seamless multi-display processing Okay, thank you for watching this video and I think this illustrates the most of important features of the unified HMI and you can even see this is not a ECU but is a tablet or your phone you can just Have this contents extended to the automotive Related ECUs So let me give a high level introduction about the unified HMI architecture so basically we Extend this Framework from the word L GPU originally on one sock Thanks to the word L GPU I mean the word L architecture of the front end and the back end which you can imagine as the Client and server we can easily actually split those kinds of Two front ends and back ends and to put it on to different ECUs so that means for example for the application you can just keep the front end on one sock and Keep the applications running on one sock but Rendering its graphics on another ECUs by putting the word L GPU Back end on the other socks definitely this For this framework, it's not necessary to having a hypervisor. Of course, you can have it but the general idea here is actually splitting the the computing power especially for the graphics from the original main socks which enables you have a More a CPU computing centric a sort architecture on the other hand If you would like to have the GPU originally on this the main sock so it enables your applications to be rendering on all the displays or all the GPUs on all the socks So you you never need to worry about which application should be attached to which ECU or which VM because everything is mapped to this virtual Unified display and you can just Accommodate your your your graphics Rendering with your real use cases and this can be very easily updated even you Develop you're deployed to your real products so We Panasonic have already open sourced this framework in the GitHub and if you are interested you can have a look it and we will also Apply this unified HMI to the ADR USB next year hopefully in O and PP and we are going to have a Full demo of this unified HMI even with the cloud native features because for the UI UX design actually with the the one I showed here you can maybe just To develop the graphics UI UX designs in the cloud or in the virtual Environment and then deploy the same thing to the edge So please We are welcome to you to join our CSA gel booth to dig more details about unified HMI as I mentioned a little bit of a cloud native actually we also had working to extend this word for the cloud native environment and we continues to contribute collaborating with the continuity and to make a Reference environment of the cloud native a gel by making the virtual and the container orchestration work on both cloud and edge Agile instances and enable developer to develop their UX features on cloud environment and you can definitely Verify the graphic and the audio from your local PC So before going to the cloud actually our easy group so also has a preliminary Implementation on the MacBook So they run they a GL with the word they all on the top of your MacBook with Apple Mac OS 3 virtualization framework. It is that directly without any changes It's just that a GL very coming from the Agile github and you can just run run it on the top of your Mac and this is all because of the virtualization of Virgo and So currently we have a Already supported the most of the basic devices like blog input and GPU and network in both cloud and edge they are completely the same and for next three years, we would like to support more advanced devices like audio video camera and can and You can see from the disk diagrams we are using we are collaborating with the container e.g So that in the cloud we are using the AWS gravity tone, which is arm-based the server so in terms of arm-based the server you do not need to have a Additional emulation from the x86 to the arm-based architecture to running a gel or to running the The edge a gel otherwise these will be a huge performance overhead So using this gravity tone we put the KVM and where they'll dare on the cloud and in the edge we use the hypervisor from our EG member open synergy cocos hypervisor, so so through this where they'll we have the completely Identical a gel bannery so running on the a gel AWS gravity tone Cloud instance and also the a gel reference hardware. So So for this is your reference hardware now it is the support in renaissance work, but definitely next year so There will be a column based the sock to be provided and with word. Oh, it doesn't matter what kind of sock It's going to be used and you will have a one a gel bannery on cloud and deploy to any platforms with any sock originally this part should be a Presented by hidden but as I mentioned he is a little bit Sick today, so I will present in steps So for the container and mash EG, which is another expert group in a gel we Actually, we are working closely together with this container EG and the virtualization EG because we think that's a Both solutions are helping the a gel to shift to the software defined vehicle And in this part, we would like to introduce a little bit more about the cloud native computing Which I I mentioned in the vertigie part So here you can see actually Illustrated a little bit more about why the software defined vehicle or as needed for the automotive world So due to this connected of the normal so shared and the electrification which we called case transient automotive world So the out the portion of the software values in the vehicle has been increased the more and more and more and now By 2030 at least the 50% of your vehicle value will be relying on a software But looking at the current the problems so you will have a lot of headaches like city features quality security and varying harness cost the integration test and the the VV models, which is very complicated and time-consuming you have a regional regulatory differences and the different hardware and software implementation you have the supply chain fragility which also may be impacted by some political or military reasons which no one can control and all this kind of issues actually is Depending on the hardware so which actually blocks the The revolution or the evil innovation of the software for the automotive. So this is the reason why the world is The calling for a software defined vehicle to decouple this kind of software from the hardware to solve this kind of hardware related issues So what is the software defined vehicle and how to make it possible? I will I think there are three points here So the first one which I already explained in the virtualization expert group part is to decouple your software from the hardware This is very important so that you can have the environment parity across different platforms in cloud in edge in in any socks you would like to have and The second one is that you would like to have your functions to be a very small block Which we call it a micro services, which is supportable to to to to develop the on any platform on any sock and on any cloud platform or on any Linux or systems or Android or whatever and those kind of a container based the macro services, which is able to port to different generation and different vehicles and Last one are definitely so why this kind of features are needed because you you would like to have your big vehicles to be updated after use you are selling the cars you would like to have your Your vehicle to produce the continuous values to the customers So this is the is especially the auto which is so you can update your your software over the L over the L continuously and frequently and if you look at the Tesla's reports you will find that Tesla actually have a Update every two day or even one day as this is really something unbelievable in the traditional OEM or or tier one business model So as mentioned in the previous slide this actually For the more summarized we need a hardware consolidation and virtualization We need a vehicle micro services and we need an application in caps encapsulation for all this We are decoupling the software development from the hardware to enable a Automotive DevOps to have the CICD rapidly to and reliably build and test and deploy your software even with the mixer criticality management of different automotive domain domains and environment parity between the cloud and edge and even across different automotive edge So is this kind of background that you can see actually the architecture of the automotive world has a Huge changes in the in the recent years So for the traditional character, which I also mentioned in the previous Sections and you will have hundreds of issues and if you would like to have some inter issue features you will have a solid and of a varied connections between issues which will significantly significantly add the The weight and cost to your vehicle Which is definitely something not feasible So most of OEMs has already Evolved their their software to this kind of domain architecture they they concentrate their issues into several domains and Like could I this IVA domain a does AD domain and poverty domain to to have a is more centralized the architecture to reduce the complexity of the hardware and even more Some OEMs are also actually is heading to this donor architectures, which has a more Centralized the architecture which we call it high performance computer, which I think is so very familiar for the cloud cloud related engineers and This kind of high performance computer computer will have the older computer resources centralized in in this hardware and For all the other sensor or or or cameras it will be connected to the tunnel gateway Anyways, it will be like the brain of the Of your your your vehicle So for cloud native computing, so this is something I think most of people here is very familiar here for the computer computing Foundation they are standardized with kubernetes and the container service mesh and technology And the inside a GL actually we are trying to bring in this technology Into the a GL to make this Containers the solutions able to make the a GL some more micro service and I've mentioned this is working closely with virtualization EEG combining with the hypervisor solution to provide the most suitable architecture for the OEMs and We are now For both EEG we are Collaborating together to have the HR running directly on the AWS the Graviton you see to and So in the future, we are expecting that different VMs of different containers can all develop on the On the cloud and you can use a Kubernetes to coordinate those special Containers and VMs and deploy them to the automotive edge and this all Will be based on the container orchestration and also the virtual standard device virtualization framework which I mentioned in the the first half So together with the two EEG we are trying to lead the a GL To evolve to a more software-defined styles of development and architecture and we definitely hope if Anyone is interested in just to join our expert group expert group co for the further discussion and thank you Yeah, are there any questions from the ground? Oh Well a very fiddly question not very important, but can we return to your presentation from earlier? Pay I think slide 11 We do a second This one not that one. I think I think where it showed There was a number 11 down in the bottom Ah, can we go this one? Oh, okay. This sorry. Okay 13. Sorry my mistake Okay Say the vertio of inch layer Now under multi ECU environment, you have just one vertio crossing multiple socks Can you explain why it's laid out like that? Okay? Let me show you I Think exactly this architecture you have a front-end on one ECU and you have the back-end on on the other Maybe can have the multiple front-end the multiple back-end Okay Or always we this the word and all framework across the different easy. I'm with you now. Thank you very much Okay regarding this cloud native demo we have a lovely demo in the hgl booth in the in the sponsor Demo room and if you're interested, please just come here to have a look Thank you