 Good morning, everyone. So I'm Jerry Zhao from Panasonic Automotive Systems. And I also have another hat, which is a AGL software-defined vehicle expert group leader. As Dan and Wood has mentioned a lot about SDVEG, which gave me a lot of pressure. So I will give an over-introduction, especially about the virtualization approaches that we are doing in this software-defined expert group. So I saw a lot of old friends and also a lot of new friends today. And I think this session, I will hope to give you a lot of insights about what we are doing in AGL. So our agenda about today, for example, I will give some backgrounds of the SDVE. And I will also give some introduction about the underlying architecture changes in the automotive world towards this kind of software-defined vehicle architecture. And also how and what we are going to do in the SDVEG of AGL. So first, let me go through some industry backgrounds for this software-defined vehicle. So the automotive industry is actually undergoing a drastic change in the e-architecture and moving from a distributed architecture of the electronic control unit that is ECU to a consolidated high-performance computer, which is called HBC. Along with this, the software stack uses a more open source and de facto standards to optimize for an always connected AI-powered user experience. So these are not independent events, but underpinning that vehicles are rapidly adopting and optimizing towards becoming software-defined. As a result, the ability to speedily deliver the values to customers is becoming an even more important competing field in the SDVE world. So we can also explain SDVE in this kind of way. So in fact, if we look at the independent research data, the capacity of the automotive software in cost that has been rapidly increasing since 2000, leading to a higher number of software-related recodes and decreasing customer satisfaction. In addition, we see an increase of cost contribution by the factor of 2.5 times over the same time span, making the software cost dominant for the vehicle as a product. This cost cannot be easily to be passed to the customer, lowering the margins, and creating cost control challenges for the automotive makers. So this is the exact same path that existing software-defined product such as the computers and smartphones has already followed. So in other words, SDVE is actually a game changer. Those who can advance software more rapidly will gain the crucial competitive advantages. However, it requires more than just the simple efforts such as increasing the LOC per month or just this kind of efficiency or having a larger organization to accelerate the software development. A shift in key strategies to sophistication of architecture, formation of ecosystem, and acceleration of product discovery will become more essential. So in order to do that, we need to rethink what we should develop a software. And so this actually calling to a new approach, which is called the software first. And this should be shifted from the original, or say the traditional, method of hardware first. So on the left-hand side, the traditional hardware first approach, where the hardware is first designed to define the product value. And then the software is developed to make it working. So trends to result in a really long time to market. Also, the software often needs to be reworked to match the hardware. So in the middle, you can see to squeeze the time to market, we can introduce the hardware emulation to support software development, even if the actual hardware is not yet ready. This is shifting to software defined a little bit slightly, but the idea of hardware defined, where hardware is designed to realize the product value is the same as with the traditional approach. So you can see on the right-hand side, what feeds in the SDV era best is a method of continuously evolving the software that realize the product values. And with appropriate timing, develop the hardware that is optimized to run that software. So this cloud native approach is based on the idea that software is the source of innovation and the most expensive asset of the vehicle that will evolve over the vehicle's whole lifetime span. So I will also giving an introduction of the underlying architecture changes in the automotive field. So for the left-hand side, which is actually the traditional hardware or say you have a lot of ECUs and you define the architectures for each single ECU, which actually I think done and what has also mentioned in their presentation. But what we needed to, as Dan mentioned, is just to decoupling the software from the hardware. So we need a logical architecture to do this. To, we need to have a two pieces. One is this kind of hardware virtualization framework. So which needs to decouple the software or say the operating system, for example, from the underlying hardware. So we also need an application framework to decouple the application implementation from the underlying operating systems. So ECU consolidation is not just a purpose, but a message that the purpose is to establish the optimal architecture for evolution of software that the software can be evolved decoupling from the hardware or removing the hardware limitations. So we are looking at the historical trend of the general computing architecture. It's always actually swing from the distribution and the centralization. So there's never a always optimal architectures. So it really depends on the hardware and the situation and the use cases you want to achieve. So this kind of repeating the cycle between the centralization and distributions and we definitely see the same trend that is happening in the automotive world. And especially when you're thinking about automotive, it's a little bit different from the traditional server. So it's not only about computing, but it's also about different peripheral devices, those kind of multimedia devices that's majorly you are not using normal server use cases and allocations of those different displays, different cameras that can and whatever peripheral devices to a different ECU will always be a headache for automotive developers. So this complicated the natures of devices and applications of automotive makes a greater complexity for automotive. So what we need is actually really something that no matter how the underlying hardware architecture changes, we need a really a good architecture that can be always applicable. So no matter how the underlying computing architecture has changed a consistent objective is to decouple the applications from the underlying computer architectures, which is actually what I mentioned, we need a hardware agnostic virtualization framework to decouple the operating system from the hardware and then always agnostic application framework to decouple the application from the operating systems. And this is the key to drive the industry shifted from the hardware centric or say the hardware first to the software defined or say the software first. So in order to decouple this kind of software from the hardware, the width device of virtualization, what we need is actually had the real hardware logic from the software implementation of the applications. So software defined vehicle needs really a common device virtualization framework to decouple this kind of implementation of software from diverse hardware targets across various vehicle variants, generations, architectures such as a single ECU or multi ECUs and development environments such as real ECU or the virtual ECU environment. So we definitely need this kind of a common device virtualization framework. So this is the actually what we talk about. We have the ECU consolidation and we need a common device virtualization framework but the original frameworks usually have this kind of property interfaces and we need this kind of a standard interfaces that's capable to apply into different OS and different hypervisor, different socks. And that's the background of the concept of WordIO and it has been really a good standard that having the standard specification in OSes and standard implementation in both Android and in AGL for example. So let's come about what in AGL we are trying to do. So in AGL we are trying to establish the common device virtualization framework with WordIO to establish a complete and healthy ecosystem for the AGL to enhance the interchangeability and interoperability in various scenarios you can see here. So from the traditional hypervisor environment to the non-hypervisor environment to even a multi ECU environment or in the last a cloud native environment. As I mentioned, I think this is just a detailed page about what I mentioned if we have a fragmented interfaces you will always have a dependency on the specific virtualization solutions and you have to adapt to every single interfaces you will limit yourself their metagreatability to the other hardware and also cloud for example. So we just want to throw that and this is the WordIO to give a simple introduction. So WordIO is actually originated from the server world in 2008. So it's originally targeting for those kinds of server use cases like network or block devices. But it's really a good framework. But we think this is the very important also for the automotive industry. So we Panasonic actually tried to extend this kind of WordIO to cover the use cases of automotive especially for example for the multimedia and for those kind of for vehicle communications part. And as a result actually we have supported WordIO in the AGL since 2020 and with this common interfaces we will have a really limited fragmentation. So all the interface will be very standard and we can select the different hypervisor or shock and so that you can just have a freedom of choice to complete your product. So this is generally what we have already done in the AGL in the past several years. So we have extended most of the multimedia devices and also like can to give this kind of support. So for the hypervisor environment we can already see it's basically we support most of the fundamental use cases for covering the basic AGL needs. But beyond the traditional hypervisor environment we actually doesn't stop at that point. We also considering some other use cases. For example even you don't use hypervisors as maybe someone would like to use containers or whatever architectures you want. So WordIO can also utilize a low level hell to abstract the hardware. So in that case we can achieve a real hardware agnostic AGL ready BSB which able to apply to any kind of hardware. On the other hand I think in the last year we are really the cloud native topic is really really popular in the automotive field and more and more OEM satiric ones and vendors who like to develop their software in a virtual environment. And WordIO also enable this kind of capability to develop your software in another hardware which is cloud. So cloud is just another applicants of the hardware targets. So in this case we can use the WordIO as a common interface with the cluster-based AGL and also different SOC or hardware environment to achieve this kind of a common commonality of the AGL software among various environments. So for the details of this non-hypervisor environment as maybe what has a little bit mentioned we actually complete 80% of the works like the GPU, like the audio. We have already supported and what's going to next is that we are not only limited to this kind of for maybe one ECU architecture. So we are also thinking about to extend this framework on to the multi ECU architecture and also support this non-hypervisor environment even in the cloud related environment. And for example, we also having a collaboration with ICG in progress which is to support the WordIO sound with this kind of non-hypervisor environment or say this container environments in the AGL. This is under progress and we hope something can be shown in CES or later. I don't want to disclose all the information in these sessions because there will be another technical insights about the non-hypervisor or say this kind of virtual loopback architectures by my EG colleagues, Michelle and he will give a presentation in the same room tomorrow. So please kindly drop by the sessions to have more insights about it. Another topic is also about the WordIO work for the multi ECU. So as Dan and Ward mentioned, we called it Unified HMI to have a virtual display to virtualize the older displays in the vehicle to have a unified control or integrated control of the whole displays across the systems. You can see it's mapping the multiple phyllo display into a single large virtual display so that you can put your applications, your layouts, your UX anywhere you like. And this is having no dependency on the underlying architecture. So whether you are using hypervisor, whether you are using one ECU, two ECU, three EDU, or whether you are using SOC A or SOC B, whatever you lack. So this actually enables a transition from the legacy HMI system which you have a strict restriction on ECU and function display, which you have to map every ECU with the specific applications or specific display. So which is really, you have a lot of dependency and a lot of restrictions in that case. And this unified HMI or say this kind of a virtual display technology can enable such kind of a unified HMI system that is fully flexible on the ECU and a function display relationship. You can have a many to many mappings of your ECUs and display and applications. So whatever physical layouts you want, you can achieve the UI, UX as you like. I don't want to go to the details in these sessions, but this is the general architecture. We are, actually for this unified HMI is also quite related with Word.io. We extended it from the original Word.io GPU to support it on the multi SOC or multi VM architectures. So for details of this unified HMI, I would like to also ask everyone to attend another technical insight sessions tomorrow by another SDVEG member, Degu Jisang. So please kindly drop back and join the sessions for me more details about the unified HMI technology. So last is that we also working on the Word.io for the cloud native environment. We have a collaboration with AWS also who is also a core member of AGLs. We enable this AGL with Word.io on the AWS Graviton and this enables a cloud native or seamless binary exchangeable cloud native environment. On the other hand, actually since Word.io is actually cloud agnostic or hardware agnostic, you can also running it on Mac or any other hardware. So some of our EG members has already enabled the AGL running on its Mac OS. And we did a demo in the 2023 booth with this kind of Word.io related features to enable the identical software between the cloud and edge. So to give a highlight or also give a break for everyone's brain, I would like to show a small video. We will show a demo of cloud native about edge binary parity and so agnostic deployment things to the standard device virtualization framework, Word.io. Let us introduce the demo environment first. On the left display, AGL is running on a virtual ECU on the AWS cloud. On the other hand, there are two automotive hardware used in this demo, a Renaissance reference board in the middle and a Qualcomm reference board on the right. In this demo, you will see how software development is done on the cloud without using physical hardware and then the same OS binary will be applied to the two physical automotive hardware and works as it is. Now, let's look at the development on the cloud. We are streaming the graphics of AGL running in the cloud virtual ECU to the local browser through WebRTC. Touch and swipe operations work with low latency. With this system, developers can proceed with automotive software development while checking the behavior of the software, even if they don't have any physical hardware at hand. Next, we will update the software on the cloud. With the update, the latest AGL starts up and the appearance of the home screen changes. We'll apply the update made on the cloud to the automotive hardware with Renaissance Soap. Currently, the old AGL is running, but we will replace it with a new version. Because the software is large in size, we have stored it on a USB in advance. The hypervisor running on the hardware loaded the OS binary image from the USB and started up a new AGL VM. The OS build ID ends with 95E4, the same as the cloud. From this, we can confirm that the software developed and the cloud works as it is on the automotive hardware. Finally, we will show you that the same software also works on different automotive hardware. We will swap the software that was running on Renaissance Soap to Qualcomm Soap. Here too, the same AGL VM started up. The build ID also ends with 95E4, the same as the cloud in the Renaissance One. From this, we can confirm that the software developed and the cloud works on two different automotive hardware. So this is the end of this small demo video, but actually it illustrates the main concept of Word.io that you can run in the same software binary across different hardware in the cloud, in different SOC type. So I would like to give a last conclusion or say a moving forward to talking about the future activities inside this SDVEG. So first, we will give an update in the CES demo to have this kind of a software defined or say the cloud native unified HMI demos, so which actually combined most of the features we have already developed in the SDVEG, the unified HMI, Word.io and the cloud native technologies. We combined all this to these systems. You can design your UI and UX, your software on the cloud and then deploy the software to different architectures. For example, in the left-hand side, it's using two Renaissance boards with these two ECUs type and on the right-hand side, it's using another Colocom SA8295 platform which have a consolidated ECU. So no matter it is a consolidated ECU or distributed ECU, no matter it is what kind of a SOC type and even it is cloud, so all the same software can be there and you can develop your software first and then deploy it to the optimal hardware. As also Dan has mentioned, we in several early months, we have a big changes in the AGL that we combined the original virtualization expert group and the container expert group to this new SDV expert group. So unfortunately, we haven't yet studied, haven't yet started the container orchestration related activities. Actually, we are also really desperate to see if anyone would like to join the CG and to work together with us to have this kind of a container related technology so more develop the rapidly or say software or say code first in the AGL community. So last but not least, as I mentioned, we for the SDV there are a lot of technologies, a lot of things we have to do for the virtualization, for the containerization, for this kind of micro services, all this kind of power walls and we definitely hope if anyone interested to join the EG discussion and to see if we can collaborate with each other to achieve this kind of software first approaches in the future world of automotive. And thank you.