[Accepted with Revisions] SDL 0315 - Add RPC Conflict Management

theresalech commented 4 years ago

Hello SDL community,

The review of the third revision(s) of the proposal "SDL 0315 - Add RPC Conflict Management" began on February 23, 2021, and continues through March 09, 2021.

The original review of this proposal took place from August 19, 2020 - to October 6, 2020.
The review of the first revisions took place from November 10, 2020 - November 24, 2020.
The review of the second revisions took place from December 08, 2020 - February 09, 2021.

The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0315-Add-RPC-Conflict-Management.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

https://github.com/smartdevicelink/sdl_evolution/issues/1068

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

Is the problem being addressed significant enough to warrant a change to SDL?
Does this proposal fit well with the feel and direction of SDL?
If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you, Theresa Lech

Program Manager - Livio theresa@livio.io

joeljfischer commented 4 years ago

In the first diagram what are SDLManager and Web App supposed to represent, they're just passing the same data; are they supposed to represent parts of your HMI?
Why are you adding a new config file instead of using the existing ini file? a. It appears that this should be a JSON file, but is only implied later based on an example. This should be made explicit.
What about two of the same RPC? e.g. What if the same app sends two Alert RPCs back to back?
Is the RPC priority table supposed to override the AppHMIType table, or visa versa? e.g. If an app with lower priority sends an RPC with higher priority, will it be shown or not?
What about apps with multiple AppHMITypes? Is their "highest" one supposed to be used?
What about head units that want to show multiple ONS RPCs at the same time?
Why do multiple RPCs have the same priority (3) in the default table.
It appears that an ONS like DialNumber cannot happen at the same time (and would override) a Speak, this seems pretty odd. It seems that they should both be able to be used at the same time.
You note in Table 4.*2 that only one app can be in FULL, which is true, but apps in LIMITED also may have the ability to show UI, and apps in BACKGROUND can sometimes show UI as well, such as Alert and SubtleAlert.
I think that putting "None" for "Potential Downsides" is disingenuous. This would a complex system that takes control of RPC conflict management out of the HMI's current hands and puts it into a different system. At the least that means that OEMs will have to do quite a bit of HMI work to remove those old systems. This also adds new config files that are not updatable outside of a firmware update (e.g. it's not a policy change). Those are just two potential downsides I came up with in a minute, and I'm sure there are more.

Jack-Byrne commented 4 years ago

I think the policy table should be used instead of a new config file or the existing ini. Then we are able to add some flexibility for updating these priorities via policy updates. This also adds complexity and will involve the sdl server as an impacted platform.

Akihiro-Miyazaki commented 4 years ago

@joeljfischer -san, 1. We are very sorry. The "Web App" is wrong. The correct is "HMI". We will modify it.

3. (* 3): For the app types with the same priority, the first RPC will be prioritized.

As described above, the first RPC will be prioritized.

4. We assume the RPC of the app with lower priority will be discarded.

5. We assume to use the highest appHMIType. But, we think it is out of this proposal.

6. We are very sorry. Since out of the scope, we have not considered about this matter. Just in case, could you teach us your assumed case.

7. In the current SDL specification, we think all RPCs have the same priority. Our aim is to prioritize the RPC "BC.DialNumber", "UI.Alert" and "UI.PerformAudioPassThru" against other RPCs. Therefore, Other RPCs is seting the same priority. As an example, we have set the list order, OEMs can change if needed.

8. In Japan, the user prioritizes the DialNumber usually. lso, there are so many case that other interruptions do not occur during the phone call. As an example, we have set the list order. If it is different the oversea case, the OEM can modify the priorities.

9. In the case of navigation app, we believe if a navigation app is FULL status, other navigation apps are BACKGROUND status. Not LIMITED. Is our understanding wrong? We do not say no, but we think the possibility is low.

10. Certainly, we understand that moving the processing from the HMI to the SDL Core makes it more complicated. However, if the processing can be executed in the SDL Core, the risk of future development will be reduced because the parts where bugs can be easily created are shared. For old systems, we think that there is no problem if the priorities are kept as they are.

We will modify to add the comment above to the Potential downsides. Does this modification match with your comment?

@joeljfischer -san, @JackLivio -san, 2. Thank you for your advice. There is no problem to add the existing policy table file. Therefore, we will add the configuration data to the policy table file. Also, we will add the policy server.

Akihiro-Miyazaki commented 4 years ago

@theresalech -san,

The table 4 does not show. Could you confirm it?

theresalech commented 4 years ago

@Akihiro-Miyazaki, I've fixed table 4 to display as expected.

kshala-ford commented 4 years ago

I am truly sorry to say that I have not been able to review this proposal before. I only took a brief look but it looks like an SDL side approach to specify how to behave depending on RPCs being received. Ford might have some knowledge we can share regarding HMI/RPC matrix.

I will just keep enumerating from the other items:

12. The very first thing I found which is different to our appraoch is that SDL policies include a per-app priority. I don't know if this field exist in the open SDL policies or in SHAID but it defines how apps can behave from in the backround in conflict cases. Apps with higher priority can send a push notification (Alert) which causes Alerts from lower priority apps to be aborted. If apps with lower priority try to send an Alert while a higher priority Alert is visible then the low prio Alert will be aborted by the system.

13. The conflict management is important for sure. I have some concerns of making this management configurable causing the app behavior to be different across multiple OEMs.

theresalech commented 4 years ago

The Steering Committee voted to keep this proposal in review until our next meeting, to allow for additional time for discussion on the review issue.

Akihiro-Miyazaki commented 4 years ago

@kshala-ford -san, Thank you for your commnet. 12. "the low prio Alert will be aborted by the system" is as same as our proposal. The different point is whether it includes the HMI Status for priority order. We think there is no problem to include the HMI status. We will consider to include the HMI status to the priority order.

13. We think the priority order are different by each OEM or country. Therefore, to set the default value for commonality, and to be able to customize by the OEMs themselves become a merit. What concerns about different behavior do you have?

kshala-ford commented 4 years ago

@Akihiro-Miyazaki -san,

12. I'm sorry. I meant in SDL there is already an app-priority field which allows us specifying priorities per app. Please take a look at SDL Server - Application Policies where a priority can be specified for application properties. See Policy Table - Module Config which describes how many Alerts an app can send per minute based on the app priority.

The priority doesn't only specify how many Alerts you can send. It specifies which Alert to prioritize independently of the app HMI type. Imagine an OEM app (HMI type DEFAULT) which runs in HMI_BACKGROUND. It should have the permission to show an alert despite other Alerts of other apps. This requires an app specific priority. I will try to get more details to the implementation in SDL and also Ford's HMI implementation.

13. Having an agreed baseline across all OEMs which should be used by default makes sense. I know regulations like NHTSA preventing distraction while driving which would require country specific customization, though this is not relevant to this proposal.

Ford supports apps sending notifications for local hazard (accidents, deer crossing) or catastrophic warnings (earthquake, fire). These apps work fine as they have permission to send Alert from in the background. These Alerts cannot be aborted by other applications due to the app's priority being higher.

Akihiro-Miyazaki commented 4 years ago

@kshala-ford -san, 12 & 13. Thank you for your comment. We understood what you say. We think if the OEMs can understand the behavior of all SDL apps, there is no problem to set priority base on the app priority. However, if not, it is necessary to set priority base on the RPC and appHMIType. We think it is effective to increase parameters for set priority.

Jack-Byrne commented 4 years ago

@kshala-ford I took a look at the logic in SDL core regarding:

The priority doesn't only specify how many Alerts you can send. It specifies which Alert to prioritize independently of the app HMI type

This appears to be implemented on the HMI level, not in SDL Core: https://github.com/smartdevicelink/sdl_hmi/blob/develop/app/model/sdl/Abstract/Model.js#L1131-L1134

A main characteristic of this proposal is to move the prioritization logic to Core and not place the responsibility on the integrator to develop in their HMI

@Akihiro-Miyazaki Please take note of the existing priority categories in the sdl policy table:

HMI_API.xml

<enum name="AppPriority">
  <element name="EMERGENCY"/>
  <element name="NAVIGATION"/>
  <element name="VOICE_COMMUNICATION"/>
  <element name="COMMUNICATION"/>
  <element name="NORMAL"/>
  <element name="NONE"/>
</enum>

These app priority fields do not exactly match the AppHMIType enum but I still think the AppPriority enum should be taken into consideration instead of creating a new field, "RpcAppTypePriority".

Because there are some parameters that already exist in the SDL Core ecosystem for managing rpc priority, I think we should look to expand on the existing functionality.

joeljfischer commented 4 years ago

1. Understood. Can you please specify what SDLManager refers to in this case?

2. Blocked by discussion in #12

3. We believe that it should be the reverse. It would be more intuitive for app developers to have the newest one shown rather than rejected.

4. Okay, thanks for confirming. Can you please update the proposal to specify that the AppHMIType table will override the RPC Priority table?

5. Thank you. Please update the proposal to specify that for apps with multiple AppHMITypes, whichever among the HMI types is the highest priority will be used for the entire app. This seems to be within scope of the proposal.

6. Some examples: If a head unit wanted to display an alert over a perform interaction, a perform interaction over a subtle alert, an alert over a perform audio pass thru, or a subtle alert over any other modal UI element, and many others. We believe that this use-case is in scope because implementing this proposal would make those use-cases impossible.

7. This relates to #6, but the response here is fine, pending the result of 6.

8. Please remember that DialNumber is not the same thing as a phone call. DialNumber just presents UI to the user to ask them if they want to start a phone call. There is a separate API for when a phone call is active (onEventChanged on HMI API / onHMIStatus audioStreamableState on MOBILE_API), so that needs to be handled by the HMI. I don't see why a Speak can't happen while a DialNumber UI is on-screen. This also relates to 6.

9. That is true, and I withdraw the first part of the objection. However, the second part, where apps can send UI from background stands and has not been addressed.

10. I think that adding that section to the downsides is a good idea. However, I disagree with the part where old systems can continue using the same priorities. I'm not sure what is meant by that. Obviously if old systems aren't updated to use the new version of Core, then they're not running this code. But it seems to me that any system running a version of Core implementing this feature must use this feature and cannot continue to use their current HMI-based RPC conflict management system. Therefore, the implementation of this feature does put a significant implementation burden on HMI developers of already-developed systems.

14. HMI should be an impacted platform because it requires the removal of existing RPC conflict management systems within the HMIs such as currently exist in sdl_hmi.

Akihiro-Miyazaki commented 4 years ago

@joeljfischer -san,

1. Since SDLManager is middleware, just pass throught. Therefore, we will delete SDLManager from this figure.

2. Thank you for your information. But, it takes much time to confirm it. Could you please teach me where to refer?

4. I'm sorry, but I recognized the wrong interpretation. The RPC priority table supposed to use both the RPC priority table and the AppHMIType table. The RPC priority table is used to determine the priority as 1st table. and the AppHMIType table is used as 2nd table. If what you mean the "override" is to replace the table from current table to these tables, that's right. Does this respose match with your opinion?

5. We will modify to add the sentence "to specify that for apps with multiple AppHMITypes, whichever among the HMI types is the highest priority will be used for the entire app".

6. Thank you for your comment. It is necessary to consider internally. So, it takes time. Could you please wait our response for a while?

9. This proposal provides the method to prioritize when RPCs conflicted. Therefore, if there is no message in the App whose status is FULL and there is a message in LIMITED or BACKGROUND, the message will be displayed without any problem.

10. If the new SDL Core is updated to the old systems, the priority is determined by SDL Core, and messege does not conflict in the HMI. Therefore, since the priority process in the HMI is not used, we think there is no problem.

14. We will modify to add the HMI on impacted platforms.

@JackLivio -san,

12 & 13. Thank you for your comment. It is necessary to consider parameters. Could you please have a time to consider it.

joeljfischer commented 4 years ago

2. My original point still stands and hasn't been responded to:

Why are you adding a new config file instead of using the existing ini file? a. It appears that this should be a JSON file, but is only implied later based on an example. This should be made explicit.

4. Are you saying that your original explanation was wrong? If a navigation app sends a PerformInteraction RPC, and a media app sends a DialNumber RPC, what happens? The proposal and your explanation is unclear.

5. The sentence you described is not a complete English sentence. You could add the sentence, "For apps with multiple AppHMITypes, whichever among the HMI types is the highest priority will be used for the entire app" and that would make sense.

9. I'm sorry, but this response doesn't make sense. It seems that you're stating that if an app is in BACKGROUND, it will override any app's UI that is in FULL. I'm sure that is not what you mean. I'm assuming that you believe that apps in BACKGROUND are subject to the same rules as an app in FULL based on this proposal? If so, the proposal should state that. In addition, this may not be sufficient (and this point relates to 12), because some apps in background (like emergency apps) may need to present an Alert overtop any other UI from the BACKGROUND HMI state.

10. I'm sorry, but I disagree. Because this priority ordering occurs before the RPCs move to the HMI, any developer of current HMI systems is unable to continue to use their existing HMI systems' RPC conflict management. Therefore, this proposal will require maintainers of such OEM systems to remove their existing code and implement this feature, potentially with different effects than their original system. This is a major downside of this proposal.

Jack-Byrne commented 4 years ago

@joelfischer We said that we might consider the policy table as the place for storing these priorities instead of the proposed config file. Also we need to resolve point #12 before we know the correct way to include this in the policy table since there are already some app priority related parameters in the policy table.

joeljfischer commented 4 years ago

@JackLivio I remember, I'm just responding to @Akihiro-Miyazaki's request to explain what I was talking about in #2. I agree that #12 takes priority and could supercede #2.

theresalech commented 4 years ago

The Steering Committee voted to keep this proposal in review to allow discussions to continue on the open items provided in comments on the review issue.

Akihiro-Miyazaki commented 4 years ago

@joeljfischer -san, 2. The No.12 referes SDL 0003 - Last Mile Navigation. Does the No.12 mean SDL 0003 - Last Mile Navigation? If yes, my previos comment is also correct. Because the day before vote, we did not have much time to confirm this proposal. Could you please teach us where to refer? If no, my previos comment is wrong. We think this No.12 means @kshala-ford -san's comment. Is it correct?

5. Thank you for your advice. We will modify as you advice.

10. In the new SDL Core, Since the conflict RPC is addressed by the SDL Core, the HMI always receives one RPC. Therefore, we think there is no problem whether HMI has a RPC conflict RPC management.

joeljfischer commented 4 years ago

2. No, 12 refers to point 12 on this issue.

10. I'm sorry, but this doesn't make sense. Because this proposal causes Core to handle RPC conflict management with, as far as I can tell from the proposal, no off switch, you are incorrect to say that this has no effect on HMI-level RPC conflict management.

Akihiro-Miyazaki commented 4 years ago

@joeljfischer -san, 2. Thank you for your respomse. We will discuss in No.12.

3. We do not think this matter can be made a dicision in here. We think it's good to have OEM members vote on which RPC is choice 1st or 2nd, what do you think?

4. We show some examples below. (1) If a navigation app sends a PerformInteraction RPC, and a media app sends a DialNumber RPC. => This proposal will select DialNumber RPC as described table 1. (2) If a navigation app sends a Alert RPC, and a media app sends a PerformInteraction RPC. => This proposal will select Alert RPC as described table 3. (3) If a projection app sends a Alert RPC, and a navigation app sends a PerformAudioPassThru RPC. => This proposal will select Alert RPC as describe table 4 (*3).

Akihiro-Miyazaki commented 4 years ago

@joeljfischer -san,

9. If the RPCs are same priority, it is necessary to prioritize with HMI status. However, We think that the HMI can display the RPC interruption from the app which HMI status is LIMITED or BACKGROUND, if the HMI has no RPC interruotion from the app which HMI status is FULL. 10. The HMI has a process to make a dicision whether to display about the sending RPC. We think one RPC or multiple RPCs go through the same process. In this proposal, since it uses only one RPC in the HMI, we think there is no concern about it. By the way, could you please teach us the meaning of the word "off switch"?

joeljfischer commented 4 years ago

3. I disagree, I think that leaving it up to a vote of the SDLC is the last resort. We have barely discussed this point, so throwing it to the SDLC without any context will not be helpful. I have made my case for why the last one would be shown (it's more intuitive for app developers), but you have not given a case for why you believe that the first should remain on screen and the second rejected.

4. Thank you. So the RPC priority table overrides the App HMI type table. This is not stated in the proposal and needs to be made clear.

9. So now you are stating that an app in HMI FULL with the same priority will override an app in HMI BACKGROUND? Is my understanding of what you are saying correct? Or is there no difference between apps of different HMI levels?

10. Again, this proposal changes which RPCs get sent to the HMI such that no conflicting RPCs should be sent, therefore, HMI integrators have to rip out their existing RPC conflict management code.

By "off switch" I mean that there is no provision in this proposal to turn off the RPC conflict management this proposal is adding to Core.

theresalech commented 4 years ago

The Steering Committee voted to keep this proposal in review, to allow time for discussion to continue on the review issue.

Akihiro-Miyazaki commented 4 years ago

@joeljfischer -san,

4. Thank you for your comment. We understood. We will modify to add the sentence "the RPC priority table overrides the appHMIType table.".

9. Your understanding is correct. If there is no interruption on the app which HMI status is FULL, the HU can display the comment from the app which HMI status is excepted FULL. However, if there is a interruption from FULL app, the HU will override to the comment from FULL HMI.

10. Thank you for your comment. We understood about the "off switch". Certainly, in this proposal, since the SDL core provides the RPC to the HMI anytime, there is no method to stop sending RPC. Therfore, it is necessary to implement it in the HMI. We will consider to add the sentence above in the potencial downsides.

joeljfischer commented 4 years ago

3. I'm still waiting for this to be addressed.

4. 👍

9. Okay, so my understanding was not correct. It is not clear at all in the proposal that apps in the BACKGROUND will be overridden by apps in FULL. That may be a big issue for existing OEM's RPC conflict management systems.

10. I don't understand your comment and don't see its relevance to this objection. Can you please clarify?

theresalech commented 4 years ago

To provide clarity of the current status of this proposal review, here's a summary of the items in discussion on this review issue:

Author to respond 3. Nexty to provide rationale for why the first app should remain on screen and the second rejected if two apps with the same priority are sent. See https://github.com/smartdevicelink/sdl_evolution/issues/1068#issuecomment-688916520.6. Nexty to review examples provided by PM regarding when head units want to show multiple ONS RPCs at the same time, and advise on how this feature would handle such cases. See https://github.com/smartdevicelink/sdl_evolution/issues/1068#issuecomment-684001859.

6. Nexty to review examples provided by PM regarding when head units want to show multiple ONS RPCs at the same time, and advise on how this feature would handle such cases. See https://github.com/smartdevicelink/sdl_evolution/issues/1068#issuecomment-684001859

9. Nexty to address concern for existing RPC conflict management systems, if proposal suggests apps in the BACKGROUND will be overridden by apps in FULL.

10. Nexty to confirm they will add the following to the "Potential Downsides" section, or provide rationale for not updating the "Potential Downsides" section accordingly:

This would be a complex system that takes control of RPC conflict management away from the HMI - where it is currently located - and puts it into a new, centralized system. At the least that means that OEMs will have to do quite a bit of HMI work to remove those old systems. This also means that re-implementing many current HMI-based RPC conflict management systems will be impossible and OEMs will have to work with this new system.

This also adds new config files that are not updatable outside of a firmware update (i.e. it's not a policy change).

12. Nexty to review additional information provided by PM and advise on expanding existing functionality. See https://github.com/smartdevicelink/sdl_evolution/issues/1068#issuecomment-683892346.

13. Nexty to respond to comment regarding baseline: https://github.com/smartdevicelink/sdl_evolution/issues/1068#issuecomment-681875225.

Author to revise 1. Remove SDLManager from Figure 1.

4. Specify that the RPC priority table overrides the App HMI type table.

5. Add the following sentence: "For apps with multiple AppHMITypes, whichever among the HMI types is the highest priority will be used for the entire app" to "appHMIType Priority Table" section.

14. Add "HMI" to Impacted Platforms.

No action currently required 2. This item is dependent on item 12.

7. This item is dependent on item 6.

8. This item is dependent on item 6.

11. Image fixed on 2020-08-25.

(edited on 2020-09-16 to include Item 6)

Akihiro-Miyazaki commented 4 years ago

@joeljfischer -san,

3. In the current SDL behavior, the newest RPC is prioritized. However, I thought that it would be bad for usability (appearance) to immediately delete what was displayed earlier and display a newest comment. Therefore, we proposed the 1st RPC is prioritized. If there is such as a document that has been decided as an SDL, please let us know the reference. If our concern is solved, we will modify the proposal as like match the current behavior.

9. Although it is under discussion in No. 12, we think that there are not enough parameters to determine the priority, so we would like to consider adding parameters. In here, we think there is not enough parameter, so we would like to consider adding the HMI status parameter. However, the priority of HMI status will be used if the appHMIType priorities are same.

10. @theresalech -san, thank you for your summarization. We understood. Since we can not say there are no concerns about this matter, so we will modify to add these concerns to the Potential downsides.

kshala-ford commented 4 years ago

Hi all, sorry for chiming in late.

Regarding 12. I am okay having the priority logic be part of Core. The proposal should be revised to include this logic. @JackLivio I'm sorry I think I accidentally wrote HMI type but meant priority. The point is that RPCs of a lower priority app should be rejected if another high priority app has actions performed. This logic should not be too complicated for SDL. The opposite might be more complicated where a lower priority action must be aborted due to an RPC of a higher priority app. Core would need to be able to cancel any of the actions like an Alert or Slider etc. in favor of the action of the higher priority app.

theresalech commented 4 years ago

The Steering Committee voted to keep this proposal in review, to allow time for discussion to continue on the review issue. It was noted that the author needs to provide a response for items 6, 12, and 13.

Akihiro-Miyazaki commented 4 years ago

@joeljfischer -san, 6. We are very sorry for delay our response. It took a time to consider about this matter. Though we will have a comment in No.12/13, we assume that the priority order becomes below.

RPC priority
app priority
HMI status Therefore, in this case, all RPCs are passed through the RPC priority We assume that the RPCs narrowed down by app priority and HMI status. At the finally, we assume that the RPCs are choosen the newest or first RPC by the occuring order.

@kshala-ford -san, @JackLivio -san, 12 & 13. Thank you for your suggestion. And I'm very sorry for delay my response. I talked about this matter internally. As a result, we comfirmed threre is no problem to change the priority from appHMIType to app priority. Therfore, we will assume that the priority order becomes below.

RPC priority
app priority
HMI status We assume that the priority order will shift from 1 to 2, from 2 to 3, if the RPCs are same priority.

theresalech commented 4 years ago

Hi @Akihiro-Miyazaki, thank you for your responses! Please find our responses, with an updated summary of discussion items, below:

Open Items (author to respond) 2. We are not considering this blocked anymore since we've agreed in Item 12 to use app priority. Since app priority is an existing policy table field, I believe the RPCPriority field should be added to the policy table. I believe all new fields in the proposal should be contained within the policy table and not in a new/separate config file.

The PM's requested revisions to this proposal would be to include how RPC priority object would be included in the policy table.

3. Thank you for supplying your reasoning. Because the developer will be able get their desired behavior no matter what (e.g. by using CancelInteraction), I believe that a user's point of view here isn't helpful to discuss. Therefore, what is most important is what default is best for the developer. I think that showing the most recent thing they asked to show and not rejecting it makes the most sense from that point of view.

6. I'm sorry, but I don't believe that this addresses Item 6; could you please address this concern:

What about head units that want to show multiple ONS RPCs at the same time?

12. We can agree to the proposed priority order but we have one suggestion to make: apps with priority EMERGENCY should be the highest priority. The new priority would be:

Apps with app priority EMERGENCY
RPC Priority
App Priority (non-emergency)
HMI Status

13. We don't believe 12 and 13 should be combined here. Item 13 still needs a response from the author. Can you please address the below?

Nexty to respond to comment regarding baseline: https://github.com/smartdevicelink/sdl_evolution/issues/1068#issuecomment-681875225.

Author to revise 1. Remove SDLManager from Figure 1.

4. Specify that the RPC priority table overrides the App HMI type table.

5. Add the following sentence: "For apps with multiple AppHMITypes, whichever among the HMI types is the highest priority will be used for the entire app" to "appHMIType Priority Table" section.

9. Given the agreement on 12 and the changes you proposed here (Add HMI status as a parameter taken into account when determining app display priority), I think this use-case is covered.

10. Add the following to the "Potential Downsides" section:

This would be a complex system that takes control of RPC conflict management away from the HMI - where it is currently located - and puts it into a new, centralized system. At the least that means that OEMs will have to do quite a bit of HMI work to remove those old systems. This also means that re-implementing many current HMI-based RPC conflict management systems will be impossible and OEMs will have to work with this new system.

This also adds new config files that are not updatable outside of a firmware update (i.e. it's not a policy change).

14. Add "HMI" to Impacted Platforms.

No action currently required

7. This item is dependent on item 6.

8. This item is dependent on item 6.

11. Image fixed on 2020-08-25.

theresalech commented 4 years ago

The Steering Committee voted to keep this proposal in review, to allow time for discussion to continue on the review issue. It was noted that the author needs to provide a response for items 2, 3, 6, 12, and 13.

Akihiro-Miyazaki commented 4 years ago

@theresalech -san, Thank you for summarization.

@joeljfischer -san,

2. We have already resposed before, we will consider to add the RPC priority list to the existing policy table file. We will not create the new file. By adding the rpc_priority list as a stand-alone property to the default polciy table and the policy table for each OEM, we assume that it will be able to meet the intentions of each OEM. Regarding to the calling order of these parameters, the policy table for each OEM is 1st priority, the default policy table is 2nd priority.

3. We will agree to display the newest RPC.

6. We understood. Since this proposal is to send the only one RPC from SDL Core to HMI, it is unmatch for the HU which wants to display multiplex messages. We do not assume it is good on the usability to display multiplex messages. If the HMI provides the displayable number for once when the system is launched, it will be available. However, the mechanism may be complex.

@kshala-ford -san, @JackLivio -san,

12. We will assume that the priority order becomes below.

Apps with app priority EMERGENCY
RPC priority
app priority(excepted EMERGENCY)
HMI status

We assume that the priority order will shift from 1 to 2, from 2 to 3 and from 3 to 4, if the RPCs are same priority.

13. Is the app priority of the app which supported by Ford the EMERGENCY? If correct, we think there is no problem by corresponding according to NO.12 above. If different, could you please teach us what parameter Ford prioritizes.

theresalech commented 4 years ago

@Akihiro-Miyazaki, thank you! Please find our responses, with an updated summary of discussion items, below:

Open Items (author or commenter to respond)

6. We disagree and believe this is a valid use-case. If the author believes it is not, it must clearly be stated in the proposed solution of this proposal that this is a new requirement. It should also be added as a downside of this proposal that implementing this feature will force only one modal RPC to ever be displayed for every OEM. We would advise OEMs to consider carefully this additional requirement against any possible future UIs they may wish to create.

13. We believe this item has been resolved via our agreed upon revision for Item 12. @kshala-ford , can you please advise if you have any additional feedback on this item?

Author to revise 1. Remove SDLManager from Figure 1.

2. Add RPCPriority field to policy table. All new fields in the proposal should be contained within the policy table. The RPC Conflict Management Configuration File section will be removed from the proposal.

3. Specify that if two RPCs with the same priority are sent, the second RPC sent will be prioritized.

4. Specify that the RPC priority table overrides the App HMI type table.

5. Add the following sentence: "For apps with multiple AppHMITypes, whichever among the HMI types is the highest priority will be used for the entire app" to "appHMIType Priority Table" section.

9. Given the agreement on 12 and the changes you proposed here (Add HMI status as a parameter taken into account when determining app display priority), I think this use-case is covered.

10. Add the following to the "Potential Downsides" section:

This would be a complex system that takes control of RPC conflict management away from the HMI - where it is currently located - and puts it into a new, centralized system. At the least that means that OEMs will have to do quite a bit of HMI work to remove those old systems. This also means that re-implementing many current HMI-based RPC conflict management systems will be impossible and OEMs will have to work with this new system.

This also adds new config files that are not updatable outside of a firmware update (i.e. it's not a policy change).

12. Specify the following priority order:

Apps with app priority EMERGENCY
RPC Priority
App Priority (non-emergency)
HMI Status

Priority order will shift from 1 to 2, from 2 to 3 and from 3 to 4, if the RPCs are same priority.

14. Add "HMI" to Impacted Platforms.

No action currently required

7. This item is dependent on item 6.

8. This item is dependent on item 6.

11. Image fixed on 2020-08-25.

theresalech commented 4 years ago

The Steering Committee voted to keep this proposal in review, to allow the author and any other interested parties to continue to discuss the proposal, especially open items 6 and 13 in this summary comment.

It was stressed that item 6 could have an impact on existing SDL Core implementations, and change the way future UIs are designed, so encouraged that any OEMs who have implemented SDL Core or are in the process of implementing SDL Core review this item carefully and provide feedback on this review issue.

Akihiro-Miyazaki commented 4 years ago

@joeljfischer -san, @theresalech -san, 6. We understood that it needs to add at the potential downsides of this proposal that implementing this feature will force only one modal RPC to ever be displayed for every OEM.

We think that the displaying the multiplex RPCs at the same time is not good for usability because it becames complicated the screen. However, we think it is effective to display the needed RPCs as possible. Regarding to correpondance, the SDL Core creates the stack area for RPCs, and sets the parameters of the priority and the display expiration time for each RPC. After the system finishes to show the 1st priority RPC, if the 2nd priority RPC is within the display expiration time, the system displays the 2nd priority RPC. If NOT, the system discards the 2nd priority RPC and cnsiders the next priority RPC.

theresalech commented 4 years ago

@Akihiro-Miyazaki, thank you for your response. Based on this, I believe we have resolved all open items in the comments and can ask the Steering Committee to vote to return this proposal for revisions. Please find a summary of the resolved open items below.

Author to revise 1. Remove SDLManager from Figure 1.

2. Add RPCPriority field to policy table. All new fields in the proposal should be contained within the policy table. The RPC Conflict Management Configuration File section will be removed from the proposal.

3. Specify that if two RPCs with the same priority are sent, the second RPC sent will be prioritized.

4. Specify that the RPC priority table overrides the App HMI type table.

5. Add the following sentence: "For apps with multiple AppHMITypes, whichever among the HMI types is the highest priority will be used for the entire app" to "appHMIType Priority Table" section.

6. Author to update Proposed solution to state new requirement of only one modal RPC to be displayed at a time. Author to update Potential downsides section to include the following:

Implementing this feature will force only one modal RPC to ever be displayed for every OEM implementing SDL.

9. Given the agreement on 12 and the changes you proposed here (Add HMI status as a parameter taken into account when determining app display priority), I think this use-case is covered.

10. Add the following to the "Potential Downsides" section:

This would be a complex system that takes control of RPC conflict management away from the HMI - where it is currently located - and puts it into a new, centralized system. At the least that means that OEMs will have to do quite a bit of HMI work to remove those old systems. This also means that re-implementing many current HMI-based RPC conflict management systems will be impossible and OEMs will have to work with this new system.

This also adds new config files that are not updatable outside of a firmware update (i.e. it's not a policy change).

12. Specify the following priority order:

Apps with app priority EMERGENCY
RPC Priority
App Priority (non-emergency)
HMI Status

Priority order will shift from 1 to 2, from 2 to 3 and from 3 to 4, if the RPCs are same priority.

14. Add "HMI" to Impacted Platforms.

No action required 7. This item has been resolved by the solution for Item 6.

8. This item has been resolved by the solution for Item 6.

11. Image fixed on 2020-08-25.

13. We believe this item has been resolved via our agreed upon revision for Item 12.

theresalech commented 4 years ago

The Steering Committee voted to return this proposal for revisions. The author will revise to include the agreed upon revisions listed in this comment.

jordynmackool commented 3 years ago

The author has updated this proposal based on the Steering Committee's agreed upon revisions, and the revised proposal is now in review until November 17, 2020.

The specific items that were updated since the last review can be found in this merged pull request: #1086

joeljfischer commented 3 years ago

I'm going to restart numbering:

1. In the proposed solution, you note:

On the other hand, InterruptManager reads InterruptManagerConfig in policy table during the SDL Core startup and builds the two tables mentioned above based on their settings.

However, I don't believe this is correct. Because the policy table can be updated at runtime, we don't want to have this only check the config during startup. It should read it any time the policy table updates or every time if that isn't something that can be done.

2. The RPC priority table is missing UI.SubtleAlert.

3. You only show the layout of the RpcPriority section of the config. Are you planning to allow the AppPriority to be configurable as well? Could you show that layout and an example of the full changes to the policy table?

Akihiro-Miyazaki commented 3 years ago

@joeljfischer -san, Thank you for your comment.

1. Thank you for your advice. We understood. We will modify from "during the SDL Core startup" to "during the policy table updates or every time" like below.

"On the other hand, InterruptManager reads InterruptManagerConfig in policy table during the policy table updates or every time and builds the two tables mentioned above based on their settings."

Is this modification match your suggestion?

2. Thank you for your advice. We will add the UI.SubtleAlert to default RPC priority table like below.

(1) BC.DialNumber 1 (2) UI.Alert 2 (3) UI.PerformAudioPassThru 2 (4) UI.SubtleAlert 3 (5) UI.PerformInteraction 3 (6) UI.ScrollableMessage 3 (7) UI.Slider 3 (8) TTS.Speak w/o ONS 3

3. We are going to use the notifications_per_minute_by_priority of module_config in policy table as the app priority table. Therefore, we did not have no plan to create the table about the app priority table. Also, we will modify to add the description that refers the notifications_per_minute_by_priority of module_config in policy table.

Jack-Byrne commented 3 years ago

@Akihiro-Miyazaki Do you mean you will create a new field similar to notifications_per_minute_by_priority?

notifications_per_minute_by_priority is used for rate limiting notifications and I believe this object should be kept separate from the changes in this proposal.

Akihiro-Miyazaki commented 3 years ago

@JackLivio -san, Thank you for your reply. 3. At first, we was going to use the notifications_per_minute_by_priority as it is. However, currently, we also think it needs the unique table for app priority list. Therefore, we will consider to create the new table for app priority like below.

"AppPriority":{
    "EMERGENCY": 0,
    "NAVIGATION": 1,
    "VOICE_COMMUNICATION": 2,
    "COMMUNICATION": 3,
    "NORMAL": 4,
    "NONE": 5
},

Also, we will consider to add the these tables as the RPC priority table into policy table like below.

RPC_Priority_Table: {
    "RpcPriority":{
        "BC.DialNumber": 1,
        "UI.Alert": 2,
        "UI.PerformAudioPassThru": 2,
        "UI.SubtleAlert": 3,
        "UI.PerformInteraction": 3,
        "UI.ScrollableMessage": 3,
        "UI.Slider": 3,
        "TTS.SPEAK": 3
    },
    "AppPriority":{
        "EMERGENCY": 0,
        "NAVIGATION": 1,
        "VOICE_COMMUNICATION": 2,
        "COMMUNICATION": 3,
        "NORMAL": 4,
        "NONE": 5
    },
    "HMIStatusPriority":{
        "FULL": 1,
        "LIMITED": 2,
        "BACKGROUND": 3,
        "NONE": 4
    }
}

jordynmackool commented 3 years ago

The Steering Committee voted to keep this proposal in review to allow the author to respond to the latest comments on the review issue.

Jack-Byrne commented 3 years ago

@Akihiro-Miyazaki

I think a simple way to phrase this would be

" InterruptManager reads InterruptManagerConfig from the policy table to construct the two tables mentioned above based on their settings."

This proposal does not generally change how core stores and retrieves information from the policy table so it is not necessary to mention information related to updates. That information should be implied by the current behavior as this proposal only adds a new field to the existing policy structure.

Akihiro-Miyazaki commented 3 years ago

@JackLivio -san,

Thank you for your advice. We understood.

We will modify the sentence to "InterruptManager reads InterruptManagerConfig from the policy table to construct the two tables mentioned above based on their settings.".

Thank you.

jordynmackool commented 3 years ago

I believe we have resolved all open items in the comments and can ask the Steering Committee to vote to return this proposal for revisions. Please find a summary of the resolved open items below.

Agreed upon revisions:

1.Update sentence to be " InterruptManager reads InterruptManagerConfig from the policy table to construct the two tables mentioned above based on their settings."

2.Add the UI.SubtleAlert to the default RPC priority table.

(1) BC.DialNumber 1
(2) UI.Alert 2
(3) UI.PerformAudioPassThru 2
(4) UI.SubtleAlert 3
(5) UI.PerformInteraction 3
(6) UI.ScrollableMessage 3
(7) UI.Slider 3
(8) TTS.Speak w/o ONS 3

3.Add a new rpc_priority_table object to the policy table as shown below. Note that key values were updated to match the policy table naming convention.

RPC_Priority_Table: {
    "RpcPriority":{
        "BC.DialNumber": 1,
        "UI.Alert": 2,
        "UI.PerformAudioPassThru": 2,
        "UI.SubtleAlert": 3,
        "UI.PerformInteraction": 3,
        "UI.ScrollableMessage": 3,
        "UI.Slider": 3,
        "TTS.SPEAK": 3
    },
    "AppPriority":{
        "EMERGENCY": 0,
        "NAVIGATION": 1,
        "VOICE_COMMUNICATION": 2,
        "COMMUNICATION": 3,
        "NORMAL": 4,
        "NONE": 5
    },
    "HMIStatusPriority":{
        "FULL": 1,
        "LIMITED": 2,
        "BACKGROUND": 3,
        "NONE": 4
    }
}

Jack-Byrne commented 3 years ago

3, Updated naming conventions

"rpc_priority_table": {
    "rpc_priority":{
        "BC.DialNumber": 1,
        "UI.Alert": 2,
        "UI.PerformAudioPassThru": 2,
        "UI.SubtleAlert": 3,
        "UI.PerformInteraction": 3,
        "UI.ScrollableMessage": 3,
        "UI.Slider": 3,
        "TTS.SPEAK": 3
    },
    "app_priority":{
        "EMERGENCY": 0,
        "NAVIGATION": 1,
        "VOICE_COMMUNICATION": 2,
        "COMMUNICATION": 3,
        "NORMAL": 4,
        "NONE": 5
    },
    "hmi_status_priority":{
        "FULL": 1,
        "LIMITED": 2,
        "BACKGROUND": 3,
        "NONE": 4
    }
}

jordynmackool commented 3 years ago

The Steering Committee voted to return this proposal for revisions. The author is to update the proposal to include revisions 1 and 2 in this comment and 3 in this comment which is updating the naming conventions for the object keys to be lower case.

jordynmackool commented 3 years ago

The author has updated this proposal based on the Steering Committee's agreed-upon revisions. The second revisions of the proposal are now in review until December 15, 2020.

The specific items that were updated since the last review can be found in this merged pull request: https://github.com/smartdevicelink/sdl_evolution/pull/1101

smartdevicelink / sdl_evolution

[Accepted with Revisions] SDL 0315 - Add RPC Conflict Management #1068