 Hello, everyone. My name is Jerry Zhao, and I'm from Panasonic Corporation Automotive R&D Center. Today, on behalf of AJL Virtualization Expert Group, I would like to introduce why and how we support a standard virtual device framework, VertIO in AJL. 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 AJL. We have a bi-weekly call, and on average 10-20 members from different fields are joining. Our expert group has a wide range of interest points on automotive virtualization, but in 2020, our focus is to make VertIO available for AJL. Before going to the main topic, let me introduce some general backgrounds of automotive. 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, while being controlled by fewer ECUs, possibly by only one single ECU. In such environment, the virtualization with hypervisor technology is one of the mainstream approaches to realize the partitioning between various applications in terms of functional safety and security. Now, let's take 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 the cost and the performance of processing, memory, and communication. This means there is no constant optimal answer. This slide shows a similar concept with the previous one, but focusing more on the process hardware and software. As you may find, physical architecture also keeps the changing, and the physical system scales are diversified even in the same architecture. In such a variable situation, virtualization has been constantly the key technology to preserve our most expensive asset, that is, of course, software. The virtualization technology includes 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 automotive computing architecture, device virtualization is similarly important for the identical reason. From next slide, I would like to discuss on device virtualization technology, specifically in automotive. In 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 slide. The first necessity is simple. Depending on our car grade or car model, equipped device 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 diverged devices to preserve software assets. 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 characteristic 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 architecture stays 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's own 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 measurement program. Application software is not involved to the specific details of physical world. Application just needs to treat virtual display model and then the virtual display is mapped to the physical world by the device virtualization software behind the scene. Thus, application software asset is preserved among various physical configurations. This is the concept of a device virtualization proposed by Panasonic in this year all-member meeting of AGL. In the previous session, I have explained the necessity of device virtualization for automotive. Next, I would like to explain why the standardization of virtual device interface is critically important for a healthy ecosystem and also talk about VertiO which is a device virtualization framework recently chosen by AGL as a common virtual device framework. Let's look at the current situation first. There are serious pain points around virtualization in automotive, parallel virtual device driver layer and even part of application platform layer such as AGL depend on both hypervisor and SOC. This is because most of current hypervisor solutions have proprietary parallel virtual device implementation and thus have incompatible parallel virtual device interfaces for upper-layer software. It is undesirable fragmentation so that OEM and Tier 1 will not have enough freedom of choice for virtualization solutions. It's unhealthy from ecosystem point of view. This slide illustrates a proposal to solve the pain points by utilizing VertiO as the standard framework for device virtualization. VertiO is an open-source implementation of parallel virtual device framework and has been utilized extensively in cloud servers in our region. By introducing VertiO, there will be a common interface and implementation for parallel 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. Panasonic has been proposing this idea and this year, AGL officially decided to support VertiO as the common virtualization framework. On the other hand, when we apply VertiO to automotive systems, we need some more efforts. As I mentioned, VertiO is readily used in cloud servers. In comparison with servers, automotive systems need various additional shared devices as shown on the right-hand side including GPU, video, audio, sensors, can, and so on. So, together with us, many companies which also joined AGL virtualization EEG later have been jointly working and contributing to support more parallel virtual devices for VertiO in the open-source community. Study progress has been made consistently. As you might know, AGL has already had the reference hardware for development purpose. The AGL reference hardware has quite modular structure as shown in the bottom picture where the SOC modules and various peripheral modules can be easily replaced. Using this AGL reference hardware, together with VertiO already AGL Unified Codebase, we can establish a healthy environment for the industry where we can choose arbitrary hypervisors, SOCs, and peripherals. In other words, we can obtain the freedom to choose the most competitive virtualization solutions. To realize the big picture of VertiO in AGL, we have started to serve as the leader of AGL Virtualization Expert Group from this April. Thanks to the active contribution from many AGL member companies and individuals across the industries, great progress has been achieved. I'm glad to announce that in the next AGL version, KokeiKoi, to be released in next February, VertiO will be officially supported for all the devices already standardized. Next year, for our EEG, we will continue to enlarge the scope of devices supported in AGL and discuss more about real automotive use cases of VertiO and even think about standardization of VertiO back end. If we assume the VertiO porting as the region, there will be two dimensions for the future EEG activities. One is application of VertiO and the other is extension of VertiO. In terms of application, the ECU consolidation, for example, consolidation of IC and IVI can be easier to be achieved. On the other hand, with the power of VertiO, an ECU abstraction can be even achieved. For example, a unified virtual display across multiple ECUs. Regarding the ECU consolidation and abstraction, our EEG member companies will show some demonstrations later. The second dimension is extension of VertiO. As I have mentioned, we are going to support more VertiO devices in AGL. Now, let's go to the demo of our EEG works. First, we will show demos for IC IVI consolidation with the latest AGL version jumping jellyfish. Our EEG member company, OpenSynergy and Linaro, will give two demos respectively. Their demos highlight two significant features of VertiO. In OpenSynergy's demo, they upgraded the AGL IVI from two-generation older happy halibut to the latest version jumping jellyfish in short time with only few changes, which highlights the easy updateability with VertiO. In Linaro's demo, they switched between different hypervisor and hardware environment with the same AGL UCB, which highlights the switchability of hypervisor and SOC with VertiO. Thanks to the VertiO's uncommon interface and framework independent from hypervisor and SOC, the portability of software is enhanced. Now, let's watch the demo video from OpenSynergy. Hello. Today I'm here to tell you about OpenSynergy's setup with two automotive grade Linux's running on top of the COCOS hypervisor running on top of the automotive grade Linux reference platform for the Renesys RCAR H3 SOC. Looking at the architecture of the setup, you can see the AGL meter or instrument cluster guest on the left. On the right, you can see the AGL IVI guest. The AGL meter guest on the left serves up physical devices to the AGL IVI guest using VertiO. VertiO offers a very big advantage in that we can easily upgrade the AGL IVI guest because it is independent of actual physical devices. In this setup, the AGL meter guest is running AGL HH or happy halibut, whereas the IVI guest is running AGL jumping jellyfish. Because of VertiO, it only took OpenSynergy about two weeks to port the jumping jellyfish version to the setup. Not only are we using the hypervisor so that both of these AGLs can run on top of a single SOC, we also are using VertiO technology so that both of these AGLs can share many of the devices provided by the platform. For example, VertiO block to share the block device, VertiO RNG for the random number generator, input for touch, 2D GPU to share the display controller as well as net so that the two guests can communicate via IP. Let's have a look at the HVAC setting so you can see that input and display are working. You can say we can touch and you see the display works fairly well. For the 3D acceleration, we are using the hardware assisted virtualization provided by Renesys. In a future version, we plan to move also to VertiO 3D GPU, which would allow us to be totally independent on the IVI side of the vendor BSP. Let's have a look at the navigation. The navigation is using VertiO network to access the internet. The actual Ethernet device provided by the platform is owned by the instrument cluster Automotive Grade Linux. The IVI Automotive Grade Linux is getting to the internet via VertiO network so by accessing first the instrument cluster Linux which then routes the request to the Ethernet interface and out into the internet. Let's have a look at the version that's running here on the IVI, AGL, and you can see in fact it is the newest version, 10 Jumping Jellyfish. Thank you for joining me today for the description of our AGL cockpit controller demonstrator on the AGL reference platform. Next, let's have a look at Linaros demo. So my name's Alex Benet, I'm a senior virtualization engineer at Linaro, and I'm also the tech lead for Project Stratus. You can find me fairly easily on the internet, but on the IRC channels I either go by the handle ST Squad or AJB Linaro depending on the channel. So just a little bit about Linaro for those of you that aren't familiar. We're a membership driven organization, we draw our members from all over the ARM ecosystem. And our mission statement is basically to drive open source development for the ARM platform. We've got our fingers in a lot of pies so we work with things all the way from the smallest IoT embedded devices through your bog standard enterprise server type setups all the way up to high performance computing and supercomputing environments. We're also an upstream first engineering organization, so generally we tend to work directly on the upstream projects, and you'll find that the Coby Wright ends up there. Let's talk about the demo. The aim of this demo is to show a single software stack running on multiple hypervisors and also on multiple pieces of hardware. So let's talk about the KVM deployment first. So here's what KVM looks like running with virtualization. So you have firmware boots in to the host Linux kernel. Because of the way KVM is designed, it's sort of all one blob. But what's actually happening on ARM is we've got the host kernel mostly sits in EL1, but then we have a little trampoline that runs in EL2, which is the hypervisor layer. And then for user space, we've got Kremu, and then on the guest side, it's the HL user space. So the demo platform that I'm doing the KVM demo on is a Marvel Macchiato bin. So it's basically an ARM development board. It's got four A72 cores, 62 gigabytes of RAM, and an NVIDIA GK208 running the Nuvo driver stack. And this is on top of a Debian Buster OS. So let me just switch across to my camera. There you go. It's an ARM64 machine, maybe LSPCI, and then you can see hardware. So I think we'll get Kremu up and running on this. This is the sort of pseudo air conditioning system, and we can turn things on and off, enable the seat warmers. There's obviously no real hardware that we're attached to. So now let's talk about Zen deployment. So the Zen system looks broadly the same at the top end. So it's the same AGL kernel, the same AGL user space. But this time we've got the Zen hypervisor. The design of Zen is the hypervisor is much thinner. Usually it leaves the hardware emulation to something else. So in this case, in a DOM zero deployment, the guest has direct access to the hardware, and the hardware is a fully emulated M-vert board. And I'm doing this with Kremu's ARM64 emulation. So as far as the Zen hypervisor is concerned, all this hardware really exists. And that's perfectly fine for Verte.io. In fact, having real hardware for Verte.io is one of the things you can do. Right, let me just talk about the host platform. So it's a Core i7, actually a 664 machine. I'm emulating the ARM64, so it will run a little bit slower. I've got 32 gig of RAM in this machine, and I've got Intel graphics instead of Nvidia. So let's just switch across to the demo. There we go. So we'll just bring it up. So there you go. You can see that's the Zen hypervisor as it detects the hardware and loads the guest kernel into position. And there you go. And there you can see it all pops out. And then we'll just click the same buttons as before. It takes a little bit longer for the actual software to run, but as you can see the graphics respond pretty quickly. There you go. And then again, I'll turn up the fan speed. What are our next steps? So the next steps for this particular example that we want to get up and running is running as a DOMU guest. So Zen's traditional deployment model is to have a DOM0 kernel that is the kernel of most privilege and accesses the actual hardware of the system, which is what we were doing in the last case. And then for the guests themselves run in a less privileged mode called DOMU. And then the hardware accesses that they make get passed to the DOM0 to be handled. So that's what we hope to demonstrate later. All right. Just a quick reminder, Project Stratus. We do all our development in the open. So there's a link to our home page. There, search for Stratus. Then I'll just find it. We also have a mailing list. And you can also find me on the IRC channels on Lunaro Virtualization on FreeNode. See, as these two demonstrations from our expert group member, OpenSynergy and Lunaro have proved with WordTile as a common framework in AGL, we have achieved a virtual AGL, which is easily upgradable across different generations and switchable across different hypervisors and socks. Thus, a healthy ecosystem around device virtualization has been established. In the previous demo session, we have showed the consolidated architecture actualized by Vertile. Let's look at another magic of Vertile that is even for distributed architecture. Vertile can also be used as device virtualization framework. By extending Vertile, abstraction of ECU can be achieved, and the device can be shared across different ECUs. In Panasonic's demo, a unified HMI technology based on Vertile was utilized to achieve a virtual display across multiple ECUs. Let's watch the demo video from Panasonic. Hello, everyone. I'm Takashi Tsubone from Panasonic. Today, I'm going to talk about an actual use case of Vertile technology that a unified HMI can be achieved across different displays. In the previous session, we have talked a lot about importance of device virtualization and how to achieve it with Vertile. Now, let's look at another important aspect of device virtualization that is location transparency. That means, first, application can render information on arbitrary displays. Second, mixed contents can be rendered to a single display from application running on different ECUs. Last, application are independent from number, size, location, and or aspect ratio of displays. This slide shows the design overview of our unified virtual display to realize the concept of previous slide. Though each ECU runs different type of operating system, each has a common design for virtual display and shares a unified virtual frame memory. Application on each ECU can access to it. Thus, distributed mixed rendering is realized. It does not only work in purely distributed system with separate ECUs, but also in same distributed system or centralized system with virtual machines in a single ECU. However, without realizing interoperability between ECUs, it doesn't work. Each ECU from different suppliers needs to exchange rendering information to each other by common protocol. It can be theoretically realized either by some standardization process of a unified protocol or by the open source development. From our perspective, the latter one is much better than the other in terms of both quality and speed. In this chart, I would like to explain what is needed as the implementation to realize the unified HMI technology. The key components are highlighted in red. We use VATIL GPU to acquire OpenGL ES command in application site and send them to Remote Note. Remote Note receives those commands and renders with its GPU. Also, we need to implement DWM. Distributed Window Management. By implementing this component, we can realize very flexible and interoperable integrated cockpit HMI while preserving software asset. Don't you think it's quite exciting? Before sharing the real demonstration of unified HMI technology, I would like to illustrate the demonstration system first. There are five ECUs, formators, heart, IVI, passenger system, and VTX respectively. Each ECU expects VTX has its own display. Now, here we go. In the first demonstration, parking information is received by VTX ECU. Without any display attached, VTX ECU can render the parking information to any displays using unified HMI technology. You can see parking information can be rendered even across two displays. The second demonstration is just for demo purpose. The application can treat these multiple displays as a single virtual display, as you can see. Thank you for watching a demo video from Panasonic about unified HMI technology based on Badayo. That's all for our expert group's presentation. We hope everyone interested can join the agile virtualization EEG to discuss and contribute virtualization architecture for automotive 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.