 Hello everyone, I'm Masashige Mizuyama, City of Panasonic Automotive Systems. Today I'd like to talk about software-defined legal trend and key technologies. Last overall, I'd like to introduce myself very briefly. As Fukuyasha mentioned, my technical background is operating system and architecture, including software and hardware. Before I came to automotive business, I had been involved in mobile phone business for about 10 years. Today, I'll touch upon the relationship between the ongoing drastic changes in automotive area and the SDV software-defined legal. What we can learn from the history of other industry about that and the direction we should take, including virtualization technology and how to act with open source. At first, I'd like to talk about the drastic changes happening in the automotive industry. In this decade, technologies for automotive are drastically changing. For example, EE architecture is rapidly changing toward large-scale central computing from distributed 100 small control units called ECU. Hypervisor is being introduced to the software platforms. Technologies from consumer or communication products such as Android are brought into vehicles. Open source is becoming quite popular among various functional domains and attempts to establish defect standard are becoming very active. Most new vehicle are always connected natively and massively powered by AI technologies. Big IT players entering. Thus, various changes are observed and sometimes they seem random and individual to each other when we don't understand the root driving force property. For instance, if we assume that consolidation with ECU is driven just by constant weight reduction, I believe we will misunderstand the future direction because it's true but not essential. I believe that all those changes are mostly driven by a common root driver. It's a shift toward SDV. They say most part of future innovation in automotive will be brought by software. In other words, SDV is a game changer to the new game where those who can advance their software more rapidly will gain crucial competitive advantage and I think it's inevitable. I think that is the only way we can understand the essential reason why all those changes happening and where those changes heading for. But this game is not as simple as just to make, just to maximize line of code per month, per month, nor just to possess even larger software team. Rather than just a single volume factors at the previous page, there are far more important factors such as sophisticated architecture which makes the software set more valuable for longer term. Ecosystem of complementary products which makes value of your product higher and faster speed of product discovery as well as product development. We can find insights to identify key success factors of the game in the history of the computer industry and mobile phone industry which has shifted to be software defined way ahead of automotive. So I'd like to discuss about the history and the insights from here. The computer architecture has been going back and forth between distributed and centralized. Every generation, the hardware architecture drastically changed driven by the evolution of semi conductor technology. In such situation around 1970, IBM introduced a very unique strategy. They introduced hardware virtualization technology to make the software work over several generations of hardware because software was most expensive asset. This strategy gave IBM the crucial competitive advantage against formidable contemporaries. This is a typical case which showed the critical importance of architecture of competitive advantage, importance of architecture for competitive advantage in software defined products. The next case is the mobile phone industry. The major competition of the mobile phone in the early time was done in size, weight, battery life, and communication performance. Quite hardware defined world, but it has shifted towards software defined. The major trigger was obviously the internet connection. While this shift progressing, digital and software ecosystem has been growing so rapidly, many, many legacy players failed to adapt to the changes, and unfortunately the failure was fatal. However, what they did was not just to keep wondering. In fact, they formed a bunch of standardization bodies to create ecosystems. But most of them aimed a kind of gradual and painless changes, I think. As a result, as you know, well, newcomers set the dominant standards and gained enormous power. During this process toward software defined product, mobile phone industry became quite horizontal by the emergence of specialized key technology play vendors because this is the best efficient way for the industry. The ecosystem grew larger and larger and the handhole of dominant platform vendors became the leaders of the ecosystem. Moreover, immediately after the hardware connected to the internet, massive agile service providers jumped in and occupied very large part of the customer value as the right-most figure. The size of value provided by the terminal manufacturer, except for a few, got relatively smaller and smaller. Panasonic at the time was one of them, and they became pretty much substitutable. This is a typical case which showed that the positioning in the ecosystem for software defined product world critically affect the player's fate. As a summary, those are insights from the history of preceding industries. Hardware changes more drastically than software in general. In such situation, preserving software asset beyond those drastic hardware changes critically strengthens competitive advantage. To realize that virtualization technology plays a key role. Shifting to the software defined product will inevitably transform the industry structure towards efficiency optimization, and your positioning in the structure will have large impact to your future. I think those insights can be applied to the ongoing changes in automotive industry. With this viewpoint, I'd like to discuss about how we should act and how open source can help the healthy evolution of SDV. In 2020s, the electronic architecture will change drastically to adapt to SDV. ECU are rapidly going to be consolidated through generations toward one or few central high-performance vehicle computers called HPC. And each software will be assumed to be updated continuously even after shipment now over many generations of all car lines. But the consolidation of ECU is not aim that means. The true aim is to establish the optimal environment for the fastest software evolution for SDV. So, one of the most important points here is to realize a sophisticated logical architecture for vehicle generation, for the vehicle system which can endure over vehicle generations, and on which software can evolve very efficiently. Like the computer industry, virtualization technology will play the key role. However, there are some critical issues to apply virtualization technology to automotive systems. I will touch upon them from here. To consolidate multiple ECU to vehicle HPC, we need to introduce the key technology component, its hypervisor, because of different levels of functional safety requirement or different ecosystem affinities among various functional domains. We need multiple different operating system running on a single processor. The virtualization of processor core and memory system is basically quite standardized and there's no serious issue. But for the virtualization of peripheral devices such as graphics, audio, video cameras, and so on, each hypervisor has different proprietary interface to other layers in the system, and it causes a kind of lock-in situation. In such situation, if you choose a particular hypervisor once, it makes your software asset depend on it. It's unhealthy ecosystem. We want to keep the freedom of choice of the best technology anytime, as much as possible, by eliminating such lock-in situation. Actually, with Panasonic Automotive and Open Synergy, a hypervisor technology company, have been playing the leading role to solve this issue. To eliminate the dependency to specific hypervisor, we deploy the IO virtualization framework to provide a common interface, especially for IO devices. The framework can be applied to any hypervisor and communize the device virtualization interface. In reality, an open source, standard IO virtualization framework, called VataIO, already existed for server virtualization. Then, we significantly extended it to cover various devices needed for automotive systems through the activity in the open source project. But just by the existence of such framework software, it will not become standard. So, we collaborated with Google to make Android Automotive Employee VataIO as its standard hypervisor interface because we thought it strongly attracts other parties to follow, and no one need to worry about the dominant control from other parties because it's open source. I think this is an interesting case that shows the power of open source, not only to create excellent software, but also to lead the industry to healthy ecosystem. Additionally, I'd like to point out here that VataIO standard interface is useful for non-hypervisor environment as hardware abstraction to realize freedom of choice of hardware. We are also working on this as Dan previously mentioned. As a result, the new versions of both AJL and Android for automotive has been released based on VataIO since 2020. Also, Sophie, the project for cloud native architecture development is going to be based on VataIO. But still today, the support level of VataIO by each existing hypervisor seems considerably different. If you are to choose hypervisor for your automotive systems, you need to be very careful about that. Anyway, VataIO development is still on the way to cover more peripheral devices in vehicles. Let's make it progress together in AJL. When SDV is fully deployed, frequent software update will take place. In this situation, similarly with modern IT industry, not only speed of product development, but also the speed of product discovery will be the important key success factor of new game. So I believe DevOps practice will spread over automotive industry as well as data analytics and brand new recording type of business model. To make them work efficiently, cloud native development will become in practice. At that time, most part of the development, including testing, will be done in the virtual environment in the cloud server. And software will be deployed to real vehicle very frequently. In this use case again, VataIO will play the key role to realize the compatibility between the real hardware in the vehicle and the virtual hardware in the cloud. Next topic is the display system virtualization. In vehicle cockpit environment, there are a number of heterogeneous displays in various locations, including head up display, digital mirrors, instrument clusters, and so on. It should work as an integrated display system. The basic display unit level virtualization is already covered by VataIO. But the display system level, we need a higher level virtualization to realize location transparency. But in today's most popular vehicle, each display is controlled by the dedicated function ECU. This means informations generated by each ECU is rendered to only its own display. If you want to render some information to other display, you need to define or develop ad hoc coordination between ECUs for such every information. With such ad hoc scheme, we can't realize such a rich cockpit experience as this slide. We need much further flexibility and freedom. To solve this, we developed display system virtualization technology called unified HMI by which any ECU or functional module can render its information at any place of any display. This page shows the concept of unified HMI technology. Unified HMI presents a single unified virtual display to application programs on any unit instead of multiple physical display. By this mechanism, each application programs can render its information to anywhere of any physical display technically. Of course, rendering permission of each application is controlled by unified HMI systems according to the system policy. Unified HMI software is already up and running. This slide shows the architecture of unified HMI. Application programs rendered through virtual GPU and then the request transferred to other ECU by unified HMI. And then the receiver at the receiver of the request generates the rendering images and the right to the appropriate display. The distributed wind manager which is a part of unified HMI controls the location of image to be rendered. Of course, interoperability between each control unit is critical to make this work. But each unit is provided by different suppliers quite usually. So we need some industrial mechanism to ensure the interoperability. We thought open source is the best way of choice for this case also. It's faster, it's efficient and perfectly interoperable because of the code first approach. As a matter of fact, we published the current version of unified HMI source code on GitHub in this September and also we are making effort to include it on the next Azure UCB release. These days software defined vehicle became buzzword but AGL has been working on it since many years ago before this world became popular as Dan mentioned. AGL has been developing software platform but it goes far beyond that. AGL has been playing a significant role as the place for various collaborative innovation to promote SDV. In reality, the collaboration for the VATIO and relating cloud-native development has been done through the activity for relevant AGL expert groups involving various players among the industry. I so much appreciate the existence of AGL and all its participants. This is the last page of my presentation. Of course, open source is obviously the finest source of technologies. And at the same time, I really feel very strongly from my experience as I shared today that open source is a very powerful scheme for industrial harmonization. I look forward to your participation for making the world progress together. Thank you very much for your kind attention. Thank you.