 Hello everyone, my name is Jerry Zhao and I'm from Panasonic Corporation Automotive R&D Center. Today, on behalf of AGL Virtualization Expert Group, I would like to talk about VertiO, a common and standard device virtualization framework which we believe to be a key technology to achieve software-defined vehicle. First, let me give a brief introduction about Virtualization Expert Group under the Automotive Grid Linux. This EEG started activities from 2017 and mainly in charge of design and implement virtualization solutions for AGL. We have a bi-vickly call and members from different fields are joining. Our expert group has a wide range of interest points around virtualization of automotive and nowadays our EEG is focusing on applying and extending VertiO for diverse AGL use cases. In our today's presentation, I will talk about the following three topics, why device virtualization is important for software defined vehicle, how VertiO can be served as a common device virtualization framework, and what current progress and future activities of AGL device virtualization are. First, let's talk about some background. As shown in this picture, it is an era of change in the automotive industry that cockpit is transforming toward fully digitalized. Cockpit instruments are going to be filled with various digital instruments will be in controlled by fewer ECUs, probably by only one single ECU. This concept is called ECU consolidation. In such consolidated ECUs, the virtualization with hypervisor technology is one of the mainstream approaches to realize the partitioning between various applications diverse in function safety and security. Now let's have a look at the overall history of virtualization. In the historical trend of general computing architecture, it has been going back and forth between centralized and distributed architecture driven by the fluctuation of constant performance of processing, memory, and communication. This means there is no constant optimal answer. This slide shows a similar concept with the previous page, but focusing more on the processor hardware and software. As you may find, physical architecture also keeps changing and physical system scale stays diversified even in the same architecture. In such variable situation, virtualization has been constantly the key technology to preserve our most expensive asset, that is, of course, software. This is exactly the one of the primary mission of software defined vehicle. The virtualization technology include both CPU and device virtualization as shown in the bottom picture. I would like to stress that for preserving software assets, device virtualization is critically important, possibly more than CPU virtualization. In the automotive computing architecture, there are some specific necessities or needs for device virtualization in addition to the general ones which I mentioned in the previous slides. The first necessity is simple, depending on car grade or car model, equipped devices may vary. For example, even for the same car OEM, there are a variety of displays for different car grades or car models. Number, size, or aspect ratio of displays can be different. Thus, we need common abstraction for such diverse devices to preserve software asset. The second necessity is rather complex. Automotive computing architecture is currently a pretty much distributed one, consists of a lot of ECUs. In this environment, education policy of a particular application software to a specific ECU and education policy of a particular device to a specific ECU are different. Optimal location of application could be decided by cohesion of functionalities or information or by load characteristics of application such as vector heavy or neural network heavy and so on. On the other hand, optimal location of devices could be decided by physical distance to ECU or by specific peripheral interface channel of ECU and so on. So, application software and relevant devices do not necessarily located on the same ECU. Furthermore, it varies among car model or vehicle generations. Even in such environment, we need to preserve our software asset. So, from application point of view, location transparency is another critical issue. Thus, we need device virtualization technology that satisfies these two necessities. But someone might think the necessity could be mitigated when the centralized architecture is deployed. However, the same necessity is still there because a single centralized system still consists of multiple virtual machines and, as shown in this figure, logical architectures stay similar. This example depicts the general notion of device virtualization from application point of view, which I have explained so far. In this example, virtual display and virtual storage are defined. The application software can treat them as if it is on dedicated devices. Those virtual devices are physical location agnostic and highly abstracted. For instance, a part of this virtual display is mapped to a specific part of a specific display connected to a specific ECU in the distributed case. Or a specific virtual machine in the centralized case. The mapping can be changed by some management program. Application software is not involved to the specific details of physical world. Application just needs to treat virtual display model, and the virtual display is mapped to physical world by the device virtualization software behind the scene. Thus, application software asset is preserved among various physical configurations, and this makes a software-defined vehicle a reality. In the previous session, I have explained the necessity of device virtualization for software-defined vehicle. Luckily, we can take advantage of standard and popular word.io as this kind of common device virtualization framework for automotive. Let's look at the previous situation around agl virtualization first. Para virtual device driver layer and even part of the application platform layer, such as agl, depended on both hypervisor and SOC. This was because most of previous hypervisor solutions had proprietary para virtual device implementation and thus had incompatible para virtual device interfaces for upper layer software. It was undesirable fragmentation so that OEM and Tier 1 would not have enough freedom of choice in virtualization solutions. It was unhealthy from ecosystem point of view. Agl virtual eG solved these pain points by introducing virtual as the standard framework for device virtualization into agl. Virtual is an open source implementation of para virtual device framework and has been utilized extensively in cloud servers in a region. By introducing virtual, there will be a common interface and implementation for para virtualization devices. Thus, enhanced freedom is guaranteed to choose optimal hypervisor and SOC for automotive needs without modifying upper layer software significantly. When we talk about virtualization in agl, this is critically important. Moreover, virtual can be applied beyond virtualized agl. Virtual can be utilized as a well-defined device hardware abstraction layer even for non-vert agl, which may further help reduce fragmentation across the SOCs and encourage agl-ready BSP. On the other hand, when we're thinking about cloud native development, which means developing and testing in cloud and then deploying in the real hardware, using virtual as common interface with cloud-based agl will further enhance interchangeability between cloud agl and native agl. Hence, recognizing virtual as a common device interface will maximize the commonality of agl software among SOCs, virtual environment and non-virtual environment, and even cloud and non-cloud environment. That's not all for virtual, not only limited to single issue architecture with the well-defined front-back architecture of virtual. It can also be applied to multi-use case to realize a virtualized device across different ECUs, and from the application point of view, it just utilize the virtual device without needs to care about detailed location and logic of physical devices. In general, device virtualization with virtual benefits in establishing a complete and healthy ecosystem for agl to enhance interchangeability and interoperability in various scenarios, no matter it is hypervisor environment, non-hypervisor environment, cloud environment, or even multi ECU environment. Next, after introducing all these concepts of device virtualization, I would like to explain about the current progress and future activities of agl device virtualization led by VertEG. First, regarding the virtual work for hypervisor environment, starting from agl Coquicoid, VertEO was officially supported as a common agl device framework for virtualized agl with basic device support like block, input, display control, and extra. During this year, VertEG then extended the virtual support to more multimedia devices to enhance the automotive use cases, such as sound, SCMI, video decoder and encoder, and camera. Next year, we will start discussion and development for more advanced multimedia features such as camera control, Vulkan support GPU, Bluetooth, and extra. Our EG member company, Linero and Open Synergy will give two demos related to VertEO from different angles. In Linero's demo, they will use the same agl image to port across different platforms with the help of standard device interface VertEO and standard firmware interface UEFI. Their demo highlights portability, which is essential for the software defined vehicle. On the other hand, in Open Synergy's demo, they will show the latest agl version lucky lamprey with latest VertEO multimedia features like sound, SCMI, video, and camera on the top of agl reference hardware. Their demo highlights easy software updateability and feature extensibility brought by VertEO, which is another important perspective for software defined vehicle. Now, let's watch Linero's demo first. Hi, my name is François Faderi Kozog and I work for Linero. Linero is a non-profit organization that orchestrates collaborative engineering for ARM silicon providers and software providers. We now have five minutes to explain platform virtualization and make a demo. To become a full cloud native solution, agl needs device virtualization and platform virtualization. Let's dive into platform virtualization and start with VertEO IOMMU. After verifying that SMMU emulation in a VM was not the best approach, VertEO IOMMU was implemented to allow device assignment to VMs in a secure manner. It also presents an abstract interface that makes it available across processor architectures. The same pattern can be applied to SCMI, which deals with frequency scaling and access to sensors. Rather than emulating an SCP, let's create an abstract virtual device that has the potential to be used in different architectures and shield VMs from the evolution of the SCMI interface in the ARM world. For trusted execution environments, we can apply a similar pattern. A mediator in the hypervisor plays the role of a VertEO backend for the TE. The most robust cloud-native environments rely on secure boot, kernel-addressed space randomization, or even uncoring signatures checking in the VM to the hardware root of trust. For the boot part, the simplest way to implement this is to adopt system-release standard. System-ready fully decouples OS from the firmware implementation by adopting the UV interface. So in this context, the boot functionality and behavior is the same regardless if the HGL kernel is booted through your boot or EDK2 with device tree or SCPI description on real hardware or in a VM. To implement system-ready in a virtual platform, a number of VertEO devices are necessary. VertEO IOMMU to perform device assignment and projects against DMA attacks. VertEO TPM for measured boot implementation. VertEO R&D to address randomization. VertEO Watchdog to protect against non-booting kernel. VertEO RPMB to write UV secure variables and trusted application secrets, for example the Netflix DRM. Or VertEO SCMI for frequency scaling. I guess it's now time for the demo. We will be booting the same kernel on a Raspberry Pi with Uboot plus UV and in a VM with EDK2 plus UV. Raspberry Pi has been powered on, video buyers brings in Uboot and Uboot starts HGL according to the UV standard. Now the system has booted successfully and we can see the HGL demo running. Let's check the SD card characteristics. This is a 128 gigabyte card in three partitions, mountainous MMC. We'll try to check that when we will be booting the server side. So let's power down and move the SD card to the SATA adapter. We will boot the social server in Ubuntu 20.04. Now that's operating. Let's check the SD card. It is mounted as a SDA. You can see the 128 gigabyte, the three partitions. This is going to be mapped directly into a virtual disk. So we can see a SDA in the drive definition. Let's launch the VM. So we can see this is also booting UV. The HGL kernel reports the EFI stub. And now the HGL demo is successfully running in the VM. This concludes the demo where we saw that system ready effectively allows abstraction of the boot process. There are still a few missing virtual devices for full platform virtualization, but they are in the works at Linaro. Thank you very much. Then it comes to Open Synergies demo. Hello, I'm Marcel, Marketing Manager from Open Synergy and today I'm going to tell you about Open Synergy setup with two automotive grade Linuxes running on top of the Cocoa Cybervisor SDK, which is running on top of the automotive grade Linux reference platform based on the Renzas ARCA H3. So you can see we have an instrument cluster on the left running an automotive grade Linux, and we have an infotainment or IVI system on the right also running an automotive grade Linux. The automotive grade Linux on the left is also serving up the word.io devices to the infotainment automotive grade Linux. Here you can see the software architecture with two VMs at the top, the IC and the IVI, all the word.io devices, which are part of the setup, the hypervisor, and of course the HL reference hardware. So what's new about this demo? The first thing is that we are using the latest version of automotive grade Linux. It's called LL or Lucky Lamp Ray. And we have of course some other new word.io features that I'm going to show you one is for example word.io sound, which allows you to use audio being served up by the Linux over here. So it can start the navigation, click destination, and you can hear that you have audio guidance. Let's have a look at some other features. One is word.io video. So this allows the IVI system to use the video decoder and encoder on the hardware again using word.io video. For example I can stop and play a video and you can see it's quite smooth. So again the system uses the video decoder from the hardware. Another feature we have is sensor supporting using word.io SCMI. So we have virtualized the sensors on the platform. So if I click this application, then you can see that the board, if I shake the board, you can see X and Y movement on the top and the vertical movement at the bottom. So that means we have given the IVI system access to one of the sensors namely the accelerator. The last feature I'm going to show you today is camera input. So now the IVI system has access to camera, which you can see, click here and we have the camera connected to the HMI port. So I can swipe my hands here. Thank you for joining me today for the description of the newest cockpit controller demonstrator using the latest version of automotive grade linux lucky lamprey. See, as these two demonstrations from our expert group members have proved, with word.io as a common device framework in agile, we have achieved a virtual agile, which is supportable across different platforms and easily upgradable and extensible across different generations, which are critical to software defined vehicle. As you might know, agile has already had the reference hardware for the omen purpose. The agile reference hardware has quite modular structure as shown in the bottom picture where the sock modules and various peripheral modules can be easily replaced using this agile reference hardware together with word.io already in the agile unified code base. We can establish a healthy ecosystem around both software and hardware where we can choose various hypervisors socks and peripherals. In other words, we can obtain the freedom to choose the most competitive virtualization solutions. For more details about agile reference hardware, please refer to panasonic's ALS session getting close to real automotive product with agile reference hardware today. In the previous session, we have explained a lot about our eGIS work on word.io for hypervisor environment. Now let's see our word.io work beyond hypervisor environment. Our eGIS has already done some concept level design to use either the upper part of word.io or the complete word.io front and back end framework to serve as a hardware abstraction layer to satisfy different devices and use cases. We are planning to start the detailed design reference implementation and performance evaluation from beginning of next year. We will start to work from the high ranked device for example input device which was decided by the agile architecture team by voting. During the activities, we will also take the production ready IVI requirements proposed by agile IVI eG such as sensitivity settings for touch panels into account to have a more close to product implementation. Furthermore, we think developing and testing agile in cloud and deploying native may greatly boost the future automotive development cycle and cloud native is a critical path to achieve software-defined vehicle. However, there are still some challenges around device virtualization for cloud native. For example, a streamlined cloud native development needs standard device interface to absorb BSV differences. Also, cloud native development for non-hypervisor environment needs device interface standardization. We believe virtual is the best solution to handle with these challenges. Virtual was originated from cloud but extended quite a lot in the automotive world, especially for multimedia devices and automotive specific devices. And now, these devices needs in turn porting back to the server and the cloud world. agile vert eG will lead further discussion and collaboration across different agile eGs to handle with these challenges around device virtualization in order to enable a smooth transition to cloud native development for IVI PR, IC, and other agile profiles. We also definitely appreciate more cooperation and contribution from anyone interested in this topic. As introduced in the previous session, vert iO is also applicable to multi-issue environment. For example, a unified virtual display based on vert iO GPU, which is a unified HMI technology proposed by Panasonic, can be established to have integrated control of multiple displays no matter of system architecture. From application point of view, one unique single virtual display device will be used based on this technology. This technology will be open sourced by Panasonic in GitHub next spring, and then we will apply unified HMI to agile with QT and Flutter supported in next summer. We will then release a reference pork in next year agile AMM or ALS. The below diagram shows a detailed use case and software architecture of unified HMI technology. ECU-A is the main ECU where the UI application is running. The open GLES command generated for UI graphic processing will be translated to vert iO GPU commands, and these commands will be looped back to the user space and sent to ECU-B and C. Then the command receiver of the ECU-B and C will translate the vert iO GPU commands back to open GLES commands, and thus the GPUs on the ECU-B and C will be able to render the graphic from ECU-A to the display attached to ECU-B and C. The location, size and layer of graphics on different displays will be controlled by distributed Windows Manager. Hence, the application on ECU-A can have its graphics rendered remotely on ECU-B and C with a control of all the displays attached to the whole multi ECU system. If you are interested in this virtual display technology, feel free to join our EEG for further discussion. In summary, AGL-Vert IG has a steady progress in supporting word dial devices for hypervisor environment in AGL by completing most of basic and multimedia devices for common use cases. Regarding non-hypervisor environment, we have finished the concept design and plan to start actual development soon. In terms of future activities, we plan to start discussion across EEG for future work to apply vert iO to cloud native AGL. On the other hand, Unified HMI, which is an example of display virtualization based on word dial GPU across multiple ECUs, will be planned to be open soon and we will come further discussion and contribution. That's all for our expert groups of presentation. We hope anyone interested can join our EEG and work together with us. Together with our EEG members, we will be online today to answer your questions if you have any. Please feel free to tap in the chat box. Thank you.