 Welcome to this session. In this session, we'd like to talk about AGL Production Radiance Profile that is new AGL IVI activity focusing on the product adoption. This presentation consists of the following six parts. I'll start with the background and then talk about the issue when adapting AGL to actual products. And I'll talk about Production Radiance Profile. That is the activity for the purpose of putting the gap between current AGL and IVI product. Then I'll introduce some automotive requirements and functions that are included in Production Radiance. I'll also introduce the roadmap of this activity next. And finally, I'll wrap up my presentation with call to action. By the way, a call to present Nishiguchi-san looks like Nishiguchi-san can you hear my presentation? Someone can hear my voice that Nishiguchi-san can't hear what I'm not sure what's going on. Let me continue. This session is co-hosted by Toyota and Denso. And I'll hand it over to Nishiguchi-san from Denso during the section 4. So Nishiguchi-san, I'll continue my presentation and please prepare your setting. By the time I hand it to you. So before starting the content, please let me introduce myself briefly. My name is Mitsuo Date. I'm a software engineer in Toyota. My background is not always automotive. Rather, I have more experience in the depth center side, such as data storage and cloud orchestration. But currently I'm in charge of developing a Toyota system and AGL in Toyota. Oh, looks like Nishiguchi-san is on me. Yeah, hello. Hello, can you hear me? This is live session, as you can see. As a background of production readiness profile, I'd like to introduce how Toyota has been working with AGL. And current state of AGL from OEM point of view. To improve the presence of AGL, Toyota have been developing VOCs and demonstrating applications such as window manager and home screen. And we have presented them in areas and CES last year, for example. Thanks to the contribution from many companies and community members, AGL membership have been grown to more than 140 companies now. That is great, however. When we look at the status of product adoption by OEMs, only a few cases are publicly announced. As far as we know, there are three announcements from OEM, one of them is Toyota's announcement in 2017. So we think AGL membership is growing, but product adoption is still raw. From Toyota point of view, OEM cannot use AGL for their product easily. The main reason is because current AGL doesn't meet OEM's product requirements, such as automotive specific requirements or quality of codes and so on. On the other hand, AGL cannot meet such product requirements because they are not well defined nor contributed by OEMs. So to break this situation, we think the contribution of product requirements from OEM side or tier one side is necessary. Toyota started disclosing our product source code and started the activity to discuss what the product requirement is for IVI. This activity is called production readiness and the source code is disclosed to production readiness profile. So what is production readiness profile? It's a part of IVI project inside many AGL projects. And it's a new platform where product level IVI requirements and the implementation are disclosed. And this profile can be used as product level reference. After the discussion within the community, selected source codes and requirements from production readiness will be merged into mainline AGL. That is called IVI profile. Then from this slide, I'd like to introduce some examples of requirements and functions in the production readiness profile. Currently upstream the profile only includes modules in platform layers such as health monitoring, life cycle management, pass data management, portion management and so on. However, automotive requirements or product level use cases are important to understand why these function modules are needed. So in this section, I want to introduce function modules that is included in production readiness profile and related product requirements or use cases. The first topic is health monitoring. Typical product requirements related to this module is when the navigation system stops abnormally, the system shall restore the original running statement. For example, think about the situation when error occurred while driving and using navigation. The system platform should arise and restore it to the normal state. During this recovery, the system should display a consistent view to the driver and should not require a reset operation by the driver. So the system platform should detect service abnormality and recover to an operating state with a delay duration. And also, the platform should detect memory leak and restore to the normal state. Also should load in these abnormalities. So health monitoring is a function module to meet these requirements. Second topic is life cycle management. This case related to this module is managing application starting order. Requirements is, for example, the service which was active when system shut down, charge startup areas and other services at the next system start. For example, if radio was running when the driver get out of the car yesterday, the driver can start listening to radio again quickly today when getting in the car. To meet this requirement, system platform should system start other resident services according to the order set in the configuration file. So life cycle management modules controls this order of starting other services and applications. And this order has to be changeable in the run back. Another example related to life cycle management is loading. Every shutdown logs and error logs shall be saved for free. So for example, when multiple services service ABC are running and shutting down, every shutdown logs must be saved for free. To meet this requirement, logout service should be the last service to shut down. So from system platform point of view, life cycle management module has to control the shutdown order to shut down logout services. Third topic is power management module. One typical use case is quick startup. Product requirements usually define startup time target. Either operation can be started within X second, for example. So system shall allow users to operate quickly when getting in the car. Without any support from power management modules, the system cannot start the boot process before across it. It sounds normal. But if the target is less than 10 seconds, for example, it's difficult to meet this requirement in this manner. So if the power management supports standby state and can receive the dual open signal, the system can start booting process before actual state. And the user can start operation on power quickly. So the power management module should be able to keep standby state and should be able to start services on the signal that is dual open signal in this example. Another use case related to power management is the alert. System shall alert when the sensor detects a dangerous situation. Even when the driver or even when the system is in a cone state, alerting function should be activated from other issues. So power management module supports this functionality in some implementation. Similar to the previous example, remote parking is also related to use case of power management module in some implementation. To be controllable from outside a car, the power management module keeps communication services even in ACOG state again. And enable communication with other issues. Fourth topic is rule-based arbitrator. This part will be presented by Nishibuchi-san from there. So I'd like to hand it over to Nishibuchi-san. Can you see my slide? Yes, I can. Okay, thank you. So today I'd like to explain about the rule-based arbitrator and the rule-based arbitration. And agenda is here. At first I'd like to explain what the rule-based arbitration is. And next, so we'll explain the background of the rule-based arbitrator and arbitration. Then, third corner. And the third, so what can be defined as a rule. And the last, we'll explain the rule-based arbitration software. Okay, then first, so what can be the, what is the rule-based arbitration? So when there are several information for driver, the content needs to be notified, simulated, so rule-based arbitrator called RBA decides which content is prioritized. So in case of the IVI or cockpit system, such a feature is important to facilitate the driver to detect the important information. Here is the, sorry, this picture is an example. So left side, in the left side, the navigation guidance and the phone call, some warning information event occurred at the same timing. So we need to decide which one should be notified to the driver. Therefore, RBA will decide this prioritized. This, based on the rules, describe the product specification. And the next is about the background of the rule-based arbitrator. So in the legacy, following the program, what they are, therefore, we want to develop or establish the HMM manager for these purpose. However, so the display arbitration will be more complex. So because of, there are many scenes, or content, and such scenes or contents are increased. For the example, the autonomous driving case. And also, flexible arbitration logic is needed. As a base technology for realizing consolidation cockpit and HMM manager concept. So in order to solve the above, these issues, and to realize the HMM manager case. So then so developed a rule-based arbitrator called RBA, and using this software in the real product. So we decide to upstream this to Agile. And the next is about the rule-based arbitration rules. So we can specify the basic rules and exceptional rules as a rule-based RBA rules. So for example, so as a basic rules, we can specify the area for policy based on the priority and also some contents. And regarding to the exceptional rules, so we specify the constraint formula like AND or implication or something like that. And in the details, so we are making some document for the contribution. And the last is about the RBA software, especially the how to integrate the RBA into Agile. So currently, so Agile has Agile compositor to composite the graphics and the manager to manage the services from the application. Therefore, we are considering how to integrate or how to combine the RBA and Agile compositor. So in order to minimize the impact of the application, so we want to adopt this approach shown in this picture. So first application will request something to the Agile compositor. Then RBA will request and execute the arbitration based on the rules specified by the specification from OEM. And so such a book mechanism or a book mechanism or the book mechanism, we are considering how to return the result of the arbitration so using the policy default in the Agile compositor. And now we are working according to this approach. And as a current plan, so we can start the code review from the beginning of the next January. So that's all about the RBA from my end. So I would like to hand over to Date-san again. Thank you. Thank you, Nishihisa-san. Another topic for production readiness is quality requirement. Contributed source codes are fully tested for actual products. For example, these codes achieve 100% of CZC1 coverage and past integration tests and system tests. Those tests are not usual in OSS because each OSS project is independent. And also contributed source codes conform to industry standard development such as MISRA and SAAD. So the maintenance of the past committees under discussion. We plan to comply with Agile's test framework for the continuous test. And we also want to follow Agile's release cycle and update source codes if needed, provide security patches and so on. But it's under planning. Although our approach of production readiness is called part, but it doesn't mean documents are not important. We think specification document is very, very important, especially for OEMs. But the past version of Agile requirements specification was released in 2015 and not updated. When there are gaps between this spec and current source code, then we'd like to keep on contributing the spec specification document through this production readiness activity. But in the short term, the specification for production readiness is also under development. The current version is 0.10 draft version and it's maintained in Agile components page. We'll keep the consistency between the source code and the specification as far as possible. Then I'd like to talk about the current state and the roadmap for production readiness profile. This block diagram is the architecture diagram from Agile specification. The function module we have contributed. We have introduced a map look into the red circle module in this diagram. As you can see, they are mainly in the platform services area and REA is categorized as part of Agile application. They are the current module in production readiness profile now. This slide shows our current ground of contribution to production readiness. We are in the trial operation phase now and we have disclosed the modules mainly in the platform areas and the RPA from so forth. For the next year, we plan to disclose application manager, window manager and so on. After that, we also plan to disclose other services and HTML framework related module but it's not determined yet. This is our current roadmap but if someone could contribute more, more module could be available or implemented earlier. So as the final topic of this presentation, I'd like to ask for your contribution. Production readiness is not Toyota specific activity. Toyota is just ticking off for now. Everyone who wants to fill the gap between current Agile and Agile product is welcome. Please contribute to your product source code or product requirements and we plan to have bi-weekly regular meeting named Agile EG. Please bring your requirements or discussion topic to Agile EG. The first meeting will be held next week and any other review comments and discussion are always welcome. And then we have conference pages for production readiness and RVA and Agile pages. So please really drop your comments there. Thank you for joining our presentation. We'd like to answer questions from Joandre if you need. Thank you for question about storage life management. I think there is no implementation specific to this storage life management but some related module is closed. In this slide, persistent storage related module are included and health monitoring modules check devices failure. But the detail will be disclosed in document or source code so please check that. By the way, as a Toyota member is joining in this chat other members might answer to this question if I'm wrong. Thank you for your question. The timeline is presented in showing this slide, I think. We plan to comment. As you know, we are disclosing past comments and during trial operation we will commit some health monitoring, farm management, RVA, and in the next phase we will continue to contribute more other services including application manager, window manager, and so on. This is a rough timeline of our contribution. And as for the demo image, currently we don't have not decided yet. We don't plan to focus on some demonstration image or complete set of full system IVI. But we are trying to enable some demonstrate, I think, that is working some application on this production readiness profile. But again, the demonstration is just mainly for testing these platform-related modules. Thank you for your question. As for SMAC policy, I'm not sure. I think there's no plan about that policy contribution, SMAC policy contribution. And we'd like to discuss what kind of security policy is the best for IVI and the IVI-EG. So I think it's a currently discussion topic. Yes, as Hoshien-sen is following up, Toyota product is currently using SVR in apps. I think it's no. Is that correct, Hoshien-sen? Please wait for some we are discussing a little bit. Yes, it's true. Thank you, Yanshima. There are some great working groups for IC, and actually we are the IVI team and IC team and it's time to close the session. Now we can start. Can I just close the session? Maybe we can stop the broadcast. Yeah, okay. Thank you for joining us. Hope you all enjoy the conference. Thank you, everyone. And see you in the next butter workshop. Bye-bye.