 Okay. Okay. Hi, folks. This is Walt Minor here. I'm the AGL Community Manager. I'm just going to give people another minute here to finish joining the session. But welcome to our Automotive Grade Linux Instrument Cluster Birds of the Feather session. So the Instrument Cluster Expert Group was formed almost two years ago. It's being led by Harakisan from Suzuki Motor Company. He and the team have been working on putting together a, we'll say a production ready version of the Instrument Cluster that they can bring to production fairly quickly. And so we'll start off. There's a number of slides we want to present here. Let me start off by introducing Harakisan from Suzuki Motor Company. And he'll present the first set of slides here. And as we go through the slides, there'll be plenty of opportunities for everybody to ask questions as we go along here. So Harakisan, take it away. Okay. Thank you, Walt. I'm Harakisan. So I'd like to introduce briefly Instrument Cluster Birds of the Feather group over here. So please go next. So this is the introduction over view of the Instrument Cluster EG, it's called ICEG. So it started from the 2019 Apple. So as Walt mentioned already two years, we work for this expert group. Next. So easy member, you can see the OEM member Toyotta, Honda, Matsuda and Suzuki. Other member are Denso, Panasonic, Continental, Porsche, Nippon Seiki, Denso 10, ICNW. So now we are all waiting for a new member to join. If you're interested in our expert group, please contact me. Please next. So applying an agent to a cluster. So it should achieve the functional safety that cannot be avoided. Like in the many systems, cluster are required to comply with the ASLB. Target functions such as the tail tails and the buzzers, very depending on the OEM. But application to functional safety is necessary. Please next. However, at the present condition, it is difficult to realize ASLB by AGO. Therefore, it is separated into ASLB and QM. AGO becomes QM and the safety mechanism for ASLB implementation is installed outside ASLB. A company have the various safety mechanisms that can be realized, for example, by a hypervisor or another microprocessor. Please next. This works on code creation based architecture, a performance requirement for the mass production, requirement specification, reference hardware, and the reference design. As a reference hardware, we will use and the reference design will be used to create a software that achieves a target performance. In order to utilize ASL for the production, it is necessary to satisfy the same quality and performance as the current mass product, mass market product. And we believe that we can achieve it through the ASL ecosystem. So ICZ came to complete the source code of the DRMDIS manager, sound system, first of all, and others. So our target is the next April, or May. So this is a brief introduction of the ICZ activity and overview. Thank you. Great. Thank you, Haraki-san. Does anybody have any questions about that overview that Haraki-san just gave? If not, we can go to the next section. Okay. I talk to the next section. So next section, I share the big issue for the instrument cluster expert group. So currently, we define the three big issues. So first is how to create azure instrument cluster. So this means we don't have existing Linux-based architecture and we should create a Linux-based architecture. It's our first big issue. Next issue is how to qualify azure software stack. So existing azure distribution don't have a quality management rule similar to existing Linux distribution. So we should create a quality management rule. It's a second big issue. Third issue is the collaboration work. So because we can discuss how to realize functional safety with azure committee only. So this means we should be collaborating with other communities. So at first, we share how to create azure instrument cluster architecture. So this slide shows a function block assignment for the instrument cluster and IVI combination systems. So this system dividing the safety and the real-time function and the cluster IVI and other main functions. So cluster container has cluster main functions such as speed meter, tachometer, temperature, and any functions. And the IVI container has radio, audio, and other IVI functions. So these software stack are isolated by the Linux container technology. So previously Harajisan was talking about the DR-Levelies. DR-Levelies is a display sharing mechanism with the containers. So it's our main function side architecture. And the other side is the real-time side. Currently, the real-time and the safety function side is not working inside the instrument cluster. We define the architecture only. So this side has a safety monitoring mechanism. This safety monitor is realized to the territorial A-shilvy certifications. And another is real-time functions. This function is difficult to realize as running on the Linux. But this side only real-time functions. Main function is inside the cluster container. It's our overview of the architecture. So next is the communication mechanism. So this slide shows IC COM. This means intercommunications. So IC COM is responsible for the vehicle signal handling which is transferred from the MCU. This example shows the CAN message handling. So Global Canvas directly connected to the MCU site. So MCU site receives the CAN message and the transfer to the main function site. This communication mechanism is IC COM. This IC COM mechanism will develop inside the instrument cluster. So on the other side, IC COM has an intercontainer mechanism. We call VX IC COM the same as VX CAN. So IC COM mechanisms connect to the container host and each guest container. And the IC COM mechanism can communicate each application and each service with the MCU site. This is the IC COM architecture. This example is a speed meta example. So microcontroller receives the speed from CAN bus. IC COM sends the speed value to the cluster container using the IC COM. IC COM is a transport layer. So it assigns to port 123 to the CAN message. So this mechanism uses IC COM sockets. It's our example of IC COM architecture. So next is window management. So multiple container DR sharing shall be done by introducing DR manager. DR manager is this. So GPU rendering and composition shall be done in application container, not container host. This side. Each RO application container to render directly the DRM device. This line. So it ensure other container can still display the HMI via Western. And each RO host type of the container to render to the DRM device in parallel. It's a basic window management mechanism. So it's an example of the use case. So one of the intercontinental communication type of the architecture. So at first, AV and container have a card navigation system. So AV and container send to turn-by-turn information using the intercontinental communication mechanism. Send to the cluster container. Cluster container side drawing the turn-by-turn icons. Compositing and output using the DRM release and DRM mechanism. It's one of the display sharing mechanism. This slide shows another type of the display sharing mechanism. So this type is hardware composition mechanism. So AV and container have one real display and one virtual display. And the cluster container have one real display. So this resource sharing by the DRM manager. AV and container drawing the cluster side information for the virtual display. Example of this. So cluster side drawing the cluster user interface. Example of this. So finally hardware composition by the two image. Final output is this. It's another type of the architecture. That's all for our cluster architecture. So it's one of the examples. We have, we already discussed another part of the architecture such as input management and sound management and any more. So if everyone send to a fine, send to interesting, please join to our community. Thank you. So can we start Q&A please? Absolutely. Go ahead. So if there's any questions, please put them in the chat section or in the Q&A section of the session. So best way. So please send by the Zoom chat. So there is a question. Are all ICCOM mechanisms subject to ASIL design? So currently open source development not subject to the, not adapted to the ASIL design, only QM design. So because it's only a communication mechanism for the Linux side. So please wait. I'm back to the slide. So my, our approach. So safety monitor and the operating system have to certifies ASIL. That's another part. So typically not need to certifies ASIL if it's isolated by safety monitor. So current open source side approach is not, will not certifies ASIL in the ICCOM mechanism. Are there any other questions? Please enter them in the chat window, in the chat box. Maria-san and Zatak-san have more information? No, no from my side. Do you want to go? Is there another section I don't remember? So okay. We migrate to the next topic. Yeah, let's do that. Next topic is how to qualify ASIL software stack. So this topic what we aim. So we want to create workflow from open source development to the product development. So this means we want to be able to certify that it has a quality control. So industry. So trust and the certify ASIL committee rule. It's only a QM world. So ASIL committee certifies the existing OSIS. So for example the ZLC and the live DRM and the other existing OSIS. It's an ad-using case. And the monitoring and certify to the ASIL development OSIS. And the ASIL committee assembles to each open source software into ASIL instrument cluster distribution. It's our approach. So industry trusts and certifies this distribution. And industry can reuse this distribution. So it's our approach and our goal. So I share the current ASIL issue. So I need ASIL instrument cluster development process. So IVI and the cluster are different in terms of the requirement. In IVI side, maybe typically required to the innovative and quickly a bug fix. On the other hand, so cluster side required to the code quality and the software quality at first. So many automotive industry are using famous OSIS in infotainment system. So this mean part of existing OSIS development process is already accepted by the automotive industry in infotainment system quality requirement. Such as we already use a Linux kernel and the ASIL-BC and the open SSL and the Genevieve DLT and the Etocetra. This mean already accepted the infotainment use case. But the automotive industry use only limited OSIS in instrument cluster system. So this mean existing OSIS development process is not much in instrument cluster quality requirement. So this slide shows the adapt to the S-Python model with ASIL current rules. So S-Python defines the SWE to SW6 by the software development rules as a standard. So currently, requirement spec is only partially in the infotainment case. The architecture design and detailed design case already defines the GELIT code only. And the mechanism is so good, such as the HGL-Zera as a GELIT mechanism. But it's a half AFU rule. And the automated testing infrastructure is currently valid. So this slide shows the instrument cluster group final goal to each rule or defines the work. So first step is the requirement spec for the software stack. It's only a platform requirement, not a product requirement. And the need to development rule defines the change request. This mean if I need to change this OSIS version, it's one of the example. And software stack documents. So another phase is the need to design rule and the document rule and the coding rule. And the most important point, so the existing OSIS reusing strategy. It's a very important point for our approach. So in more detail, we already described the HGL conference. So if you think fine, please check these documents. So today I share the URL and the topics. So one of the development process drafts. Currently, we are completing the first draft description. Next step, we start trial development based on this process. That's only a section two only. If you think fine, please check it. So another point is the document defines the criteria. First is the architecture criteria of the reusing existing OSIS. So this document, so how to assess the existing OSIS. For example, we check code quality using the Krang static analysis tool. So this talk, Jean Simon talking another session, how to use the open source static analysis tool. Another one is the document template. It defines the HGL development design document. It's an overview of our work for the quality management. Starting this Q&A session. Please question using the chat. When we go to the next section, Yamaguchi-san. Okay. So final topic is a collaboration with another community. So automotive-grade D-NUX already joins the EDISA community. And each instrument cluster member company already joins the EDISA project. So currently, so HGL member worked with HGL automotive working group. So this topic shares these work. Sorry, please wait. Sorry. This slide shows HGL and EDISA collaboration. So currently, HGL has a demo instrument cluster software stack based on the RBS software stack. So currently, so EDISA community creating the HGL instrument cluster extension. For example, extended by the telltale functions by the HGL demo instrument cluster. Another software is a safety monitor. It's a current under developing. So EDISA community already created the meta EDISA layer. So because of HGL using the Yacht build systems. So it is a site creating the additional layer for the HGL software stack. So currently, it is a site starting the development of the meta EDISA. So this meta EDISA can check the EDISA GitHub. URL is this. So this meta layer having the additional function, adding the functional safety demo to the latest HGL releases. Currently, jellyfish. And it will be adding a functional safety stack to latest HGL release. So this, that's all for the EDISA collaboration topics. So have a question or comment for the collaboration topic. So finally, so we can answer to overall question. So if everyone have overall or another topic question, you can ask to committee member. Thank you, Yamaguchi-san. Thank you. And thank you, Haraki-san as well. Thank you. So are there any questions? If there's no questions, we'll end the session, I guess. So what? Yeah. Can you share the meeting time with the instrument cluster expert group and the another HGL talk and the next SAT meeting in this process? Sure. Do you mean the calendar? Yeah. I'm going to do that. I have it right here. So here's the calendar for the HGL developer community. You can always go to this. If you're already on the mailing list, you can subscribe to the calendar. These times are all Chicago time, which of course is the proper time for everything. But you can, in the calendar itself, you can change the calendar time to, let's say we switch it to Japan time. So the instrument cluster meetings, expert groups meets every other Monday at 10 p.m. in Japan time. There's also the weekly developer call on Tuesdays at 11 p.m. And then other expert groups like the system architecture team meet the connectivity expert group. It would be of interest to the instrument cluster folks and possibly the application framework. Virtualization is also of interest. Virtualization, you may have seen the talk yesterday from Panasonic and Lunaro. So is there any other questions today before we end the session? So I will, can you share this automotive, this automotive Dinox ORG URL by the chat? Yes. Calendar is here. I hope to discuss with each person in this call. I will, I guess I'm the person on the, so I can, Damien, I can upload these slides to SCAD. I'll upload it right after this. Please, please. Thank you. Yeah, I'll upload these slides. I forgot that I was the person who was named, so I could do that. And we'll send you to hosting for our expert group both. Oh, no problem. Thank you, Dr. Yamaguchi. Thank you. Thank you. So one last chance to ask a question. So, okay, I guess that's it then. Dave, let's go ahead and end the session. Bye everybody.