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

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.

joeljfischer on 19 Aug 2020

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.

JackLivio on 24 Aug 2020

@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 on 25 Aug 2020

@theresalech -san,

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

Akihiro-Miyazaki on 25 Aug 2020

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

theresalech on 25 Aug 2020

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.

kshala-ford on 25 Aug 2020

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.

theresalech on 26 Aug 2020

@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?

Akihiro-Miyazaki on 27 Aug 2020

@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.

kshala-ford on 27 Aug 2020

@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.

Akihiro-Miyazaki on 28 Aug 2020

@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.

JackLivio on 31 Aug 2020

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.

joeljfischer on 31 Aug 2020

@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.

Akihiro-Miyazaki on 1 Sep 2020

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.

joeljfischer on 1 Sep 2020

@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.

JackLivio on 1 Sep 2020

@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.

joeljfischer on 1 Sep 2020

👍1

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.

theresalech on 2 Sep 2020

@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.

Akihiro-Miyazaki on 4 Sep 2020

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.

joeljfischer on 4 Sep 2020

@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 on 7 Sep 2020

@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"?

Akihiro-Miyazaki on 8 Sep 2020

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.

joeljfischer on 8 Sep 2020

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

theresalech on 9 Sep 2020

@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.

Akihiro-Miyazaki on 11 Sep 2020

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?

joeljfischer on 11 Sep 2020

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)

theresalech on 14 Sep 2020

@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.

Akihiro-Miyazaki on 15 Sep 2020

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.

kshala-ford on 15 Sep 2020

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.

theresalech on 16 Sep 2020

@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.

Akihiro-Miyazaki on 18 Sep 2020

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 on 21 Sep 2020

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.

theresalech on 23 Sep 2020

@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.

Akihiro-Miyazaki on 24 Sep 2020

@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 on 29 Sep 2020

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.

theresalech on 30 Sep 2020

@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.

Akihiro-Miyazaki on 1 Oct 2020

@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 on 6 Oct 2020

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

theresalech on 7 Oct 2020

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

jordynmackool on 11 Nov 2020

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?

joeljfischer on 16 Nov 2020

@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.

Akihiro-Miyazaki on 17 Nov 2020

@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.

JackLivio on 17 Nov 2020

@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
    }
}

Akihiro-Miyazaki on 18 Nov 2020

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

jordynmackool on 18 Nov 2020

@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.

JackLivio on 23 Nov 2020

@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.

Akihiro-Miyazaki on 24 Nov 2020

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
    }
}

jordynmackool on 24 Nov 2020

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
    }
}

JackLivio on 24 Nov 2020

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 on 25 Nov 2020

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

jordynmackool on 9 Dec 2020

Restarting numbering.

1. In the motivation, you state:

Management of RPC conflicts with OEMs may increase the difficulty of implementing middleware.

What kind of middleware are you envisioning here?

2. In the motivation, you state:

Since there is no guideline for RPC conflicts, implementations vary for each OEMs, thus, it is hard to standardize.

Is this a needed goal? Also, this proposal doesn't seem to solve this problem. After all, implementations will still vary by OEM and there won't be standardization since this is all customizable.

joeljfischer on 10 Dec 2020

The number ranking for rpc_priority and hmi_status_priority starts at 1, while the number ranking for app_priority starts at 0 for emergency?

Is this because emergency is considered a higher priority than all other attributes? Maybe we should just remove the configuration of app_priority:EMERGENCY since we designate those apps as the highest possible priority.

JackLivio on 14 Dec 2020

@joeljfischer -san,
Thank you for re-numbering.
1.
We think the word "middleware" is wrong, correct is HMI.
Therefore, we think we would like to modify the Motivation like below.
(We will use the figure 1 as it is.)

When multiple apps operate, ON-screen (ONS) messages and text-to-speech (TTS) RPCs are requested together. However, the current SDL Core does not have the function to manage these conflicts. Thus, all requests are notified to HMI and managed by the OEMs themselves. For instance, ONS and TTS conflicts are managed by prioritizing the latter RPC. The figure below demonstrates the sequence process when PerformAudioPassThru occurs during ScrollableMessage.

The example above shows that the latter RPC PerformAudioPassThru is displayed and aborts ScrollableMessage. However, this kind of method has the following problem that management of RPC conflicts with OEMs may increase the difficulty of implementing HMI.

To solve this problem, we propose to add a new RPC conflict management function to SDL Core.

2.
Since you are correct, we think we would like to remove this sentence like No.1 above.

@JackLivio -san,
3.

Is this because emergency is considered a higher priority than all other attributes?

Yes, That's right.
We specify the EMERGENCY as the highest priority than all other attributes according to this comment No.12.
As you say, maybe the EMERGENCY is not needed on the app_priority.
However, if the EMERGENCY is removed from the app_priority list, anyone ask us why there is not the EMERGENCY in the app_priority.
Therefore, we decided to remain the EMERGENCY as the highest priority in the list.

Akihiro-Miyazaki on 15 Dec 2020

👍

JackLivio on 15 Dec 2020

The Steering Committee voted to keep this proposal in review on 2020-12-15 to allow for the conversation to continue on the open items.

jordynmackool on 16 Dec 2020

2. To be clear then, given that this goal is now removed, the only motivation for this proposal is to decrease the difficulty of implementing an HMI?

joeljfischer on 7 Jan 2021

@joeljfischer -san,
2.
As you say, by implementing and sharing this function onto SDL Core, to reduce the defects and the difficulty of HMI implementation is the one of purposes.
In addition, by to store the priority table to policy table, to be easy to understand the behavior and to be able to set the priority order are also purpose.

Akihiro-Miyazaki on 8 Jan 2021

2. I don't know that "to be easy to understand the behavior and to be able to set the priority order are also purpose." is a good motivation. App developers can't understand the behavior from the policy table, so this isn't helpful. Being able to set the priority order can already happen in the HMI.

Given all of that, it's my opinion that the benefits here do not outweigh the downsides, which I see as very large.

joeljfischer on 12 Jan 2021

1. I'm sorry, I missed responding to this one.

For instance, ONS and TTS conflicts are managed by prioritizing the latter RPC.

This isn't always true right? This is dependent on the HMI implementation?

The example above shows that the latter RPC PerformAudioPassThru is displayed and aborts ScrollableMessage. However, this kind of method has the following problem that management of RPC conflicts with OEMs may increase the difficulty of implementing HMI.

While true, it's just shifting the burden to the HMI development on the policy server / Core setup side. It may be less burdensome, but it's certainly not no burden. HMI developers will still have work to do here.

joeljfischer on 12 Jan 2021

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

Open Items (author to respond):

1. [Livio] See comment here.

2. [Livio] I don't know that "to be easy to understand the behavior and to be able to set the priority order are also purpose." is a good motivation. App developers can't understand the behavior from the policy table, so this isn't helpful. Being able to set the priority order can already happen in the HMI.
Given all of that, it's my opinion that the benefits here do not outweigh the downsides, which I see as very large.

No action required:

3

jordynmackool on 12 Jan 2021

The Steering Committee voted to keep this proposal in review on 2021-01-12 to allow for the author to respond to the open items, summarized in this comment.

jordynmackool on 13 Jan 2021

@joeljfischer -san,
1.

This isn't always true right? This is dependent on the HMI implementation?

I think what you say is correct.
It depend on the HMI implementation.
However, we assume that almost of HMI implementation are managed by prioritizing the latter RPC.

To reduce the burden of HMI implementation is the one of aims of this proposal.

HMI developers will still have work to do here.

What's the work to do here? Please teach us.

2.
Certainly, since app developers may not know the policy table itself, I don't think they can understand the behavior from the policy table.
However, this proposal is for OEMs.
For OEMs, to be able to share priority order method will reduce defects.
We also assume that to be able to customize the priority order can be more close to OEM specification.
Therefore, we assume this proposal has merits.

Akihiro-Miyazaki on 15 Jan 2021

1.

However, we assume that almost of HMI implementation are managed by prioritizing the latter RPC.

I don't know that that's true; in fact, I'm fairly sure it is not. I would recommend removing this from the proposal.

HMI developers will still have work to do here.
What's the work to do here? Please teach us.

The HMI developers will still have to setup the policy table and determine how they want the conflict resolution to work. There's still a lot of configuration that needs to be done. They will still have work to do. It's less work, but it's still work and decisions to be made.

2.

For OEMs, to be able to share priority order method will reduce defects.

OEMs can already create a document that describes the priority order they have created. Sharing the policy table implementation probably won't be as helpful as a clearer description they can share. HMI developers will already be using version control to share the exact code with the priority order algorithms. I don't think that "being able to share priority order method" will reduce defects.

We also assume that to be able to customize the priority order can be more close to OEM specification.

This is simply false. Reducing the flexibility an OEM has to implement priority ordering does not help it be closer to their ideal specification.

joeljfischer on 19 Jan 2021

The Steering Committee voted to keep this proposal in review on 2021-01-19 to allow for conversation to continue on open items 1 & 2.

jordynmackool on 20 Jan 2021

@joeljfischer -san,
1.

I would recommend removing this from the proposal.

OK. We will remove this sentence.

The HMI developers will still have to setup the policy table and determine how they want the conflict resolution to work. There's still a lot of configuration that needs to be done. They will still have work to do. It's less work, but it's still work and decisions to be made.

Please let us know the details if need to show on this proposal.
We will maintain this proposal unless your advice.

2.

I don't think that "being able to share priority order method" will reduce defects.

Since the system has a stable method of priority order if there is no defect in this method, we assume the defects are overwhelmingly fewer than creating a new one.

Reducing the flexibility an OEM has to implement priority ordering does not help it be closer to their ideal specification.

At least, we assume it is useful for OEMs which wants to reduce the amount of code or wants to reduce the man power for bug handling this method.

Akihiro-Miyazaki on 21 Jan 2021

2.

Since the system has a stable method of priority order if there is no defect in this method, we assume the defects are overwhelmingly fewer than creating a new one.

I would object to the word _overwhelmingly_ here. It should also be noted that because this feature is in Core, it becomes must more difficult and will take much more time to fix any bugs that do exist, compared to with the HMI implementation. I'm not arguing that implementing this proposal wouldn't reduce defects, it would, but I am arguing that it's less so than you're claiming, and the loss of flexibility to OEMs to implement this feature is significant.

You can continue with the proposal as is, I simply believe the proposal should be rejected because the feature that is offered isn't worth the downsides. Others may disagree.

joeljfischer on 21 Jan 2021

@joeljfischer -san
Thanks for your comments.

We will wait your response.
2.
We will discuss how to proceed with this topic internally.
If no conclusions have been reached by the next meeting, I think this proposal should be deferred.
Also, our basic idea / opinion is that it is good to standardize the parts that can be shared and concentrate on the parts that the developer should originally decide or implement.
By the way, this proposal is flexible because it has a common mechanism and can be customized in terms of behavior.
I think it will be a point of what layer you want flexibility.

Shohei-Kawano on 22 Jan 2021

1. Nothing to do here beyond what was already noted. I was just noting my objection to the proposal.

joeljfischer on 25 Jan 2021

@joeljfischer -san, @jordynmackool -san

2.
We have discussed how to proceed with this proposal internally.
We believe that at this point we should vote on whether or not to proceed with this proposal.
I think Joel-san's comments are unfair because they are implicitly perceived as withdrawing the proposal.
I feel that it is unfair and a violation of etiquette to express opinions for or against the thread because it can be regarded as guidance.
Also, this proposal has been reviewed since the end of August, but if there is any disagreement with the content of the proposal, it should be discussed at an early stage.
We have made several revisions and are taking the time to consider them.
At this stage, Joel-san's comments are trying to make our time meaningless. I'm wondering about the review process in the first place. If you don't first discuss and vote on what the proposal is and whether it's meaningful for your motivation, and then move on to technical discussions, the time you spend like us may be meaningless.

Shohei-Kawano on 26 Jan 2021

Hello @Shohei-Kawano, I’m truly sorry that you feel that I am wasting your time. I want you to know that I take that seriously. However, I believe that there are some misunderstandings of the evolution review process that are leading to your frustration.

It is my opinion that while this proposal is helpful, the downsides of it are too great to outweigh the benefits. I think there is a misunderstanding of what evolution reviews are. They are fundamentally opinions, especially when referencing the motivation or how best to accomplish the task. Evolution reviews are intended to persuade the proposal author and SDLC that their opinion is correct. The reviewers, which can be anyone, the maintainer or otherwise, can express their opinions of support or opinions of what should change, but the proposal is still the author's. The author may choose to reject or ignore any review point that is offered to them and request that the proposal be put to a vote. The reviewers may then speak up against the proposal and it is up to the SDLC to decide what to do with it.

Deciding to take a point to SDLC vote can be done at any point you feel you don't want to make a suggested change or wish to move the proposal forward because there is a disagreement of opinion that you don't feel will be resolved, you can ask to take the point or proposal to an SDLC vote. The only changes that _must_ be made are SDLC requested revisions.

If you’d like to discuss the motivation and topic of a potential proposal, you may bring it up for discussion in the SDL Slack. However, I disagree that the evolution process should be broken up into parts. Understanding the technical side of the discussion brings to light the limitations and drawbacks of any proposal. Almost every motivation is worthwhile to fix, but the fundamental issue to be discussed is the way it's fixed or the drawbacks of fixing it. Still, if that is a change you wish to see, you could propose a change to the SDLC process by making a PR in the sdl_evolution repo that changes the PROCESS.md document.

Please know that I'm sorry if it was not clear that the proposal could be moved to steering committee vote despite reviewers having a difference of opinion about the proposal. If you wish to do so, tag @jordynmackool that you wish to bring it to a vote. Please understand that I will be voicing my opinion in opposition of this proposal, though it is only my opinion as somebody with experience in this project. It will be up to the SDLC to decide on the result of the proposal.

joeljfischer on 26 Jan 2021

@jordynmackool -san,
We want to defer this proposal. Because we want to more discuss how to proceed internally.

Shohei-Kawano on 26 Jan 2021

@joeljfischer -san,

Do the shortcomings you're talking about fit in with "Off switch"?
If "Off switch" features are added to this proposal, will your stance for or against it change?

Shohei-Kawano on 27 Jan 2021

The Steering Committee voted to defer this proposal on 2021-01-26 at the author's request in this comment, asking for additional time to discuss internally how to proceed.

The proposal will remain deferred until the author has acknowledged (via email to [email protected]) that they are ready to continue the conversation on the issue.

jordynmackool on 27 Jan 2021

The authoring company of this proposal has advised that they are now ready to respond to comments on this review issue. The Steering Committee can vote to bring this back into review when time allows.

jordynmackool on 2 Feb 2021

The Steering Committee has voted to bring this proposal back into review. The review will take place until our next meeting on February 09, 2021 (2021-02-09).

jordynmackool on 3 Feb 2021

@joeljfischer -san,
Thank you for your advice on slack.
We will modify the proposal like below.

1.
We will remove the following sentence from Motivation.

However, we assume that almost of HMI implementation are managed by prioritizing the latter RPC.

2.
We will modify to add the off switch feature like below.

(1) Add below description of ON/OFF switch feature between HMI status priority table and RPC Conflict Management Module in Proposed solution.

Adding ON/OFF switch feature of RPC Conflict Management function

The following parameter described in SmartDeviceLink.ini are explained below.
The parameter of UseCoreRpcConflictManagement shows whether to use the RPC conflict management method implemented on SDL Core. For example, if the UseCoreRpcConflictManagement is set to Disable, SDL Core sends RPCs to HMI as it is without using the RPC conflict management method implemented on SDL Core. The system needs to manage the RPC conflict by using OEMs own method. The default value is Disable. Thus, it also can handle the existing system.
Also, if the UseCoreRpcConflictManagement is set to Enable, SDL Core sends only one RPC to HMI specified according to the priority tables above by using the RPC conflict management method implemented on SDL Core.

Below shows the example of UseCoreRpcConflictManagement parameter:

[RPCConflictManagement]
; Set whether to use the RPC conflict management method implemented on SDL Core.
; Disable means SDL Core throw out RPCs as it is. (SDL Core do not use the RPC conflict management method implemented on SDL Core)
; Enable means SDL Core throw out only one RPC according to priority tables in policy table by using the RPC conflict management method implemented on SDL Core.
UseCoreRpcConflictMamagement = Disable

(2) Removing 1 and modifying 2 like below in Potential downsides.

Implementing this feature will force only one modal RPC to ever be displayed for every OEM implementing SDL.
As a result, the system can not support multi ON-screen(ONS) and text-to-speech(TTS) RPCs notification.
However, by using the parameter of UseCoreRpcConflictManagement with Disable, since SDL Core can correspond to multi ONS and TTS RPCs, the system can support multi ONS and TTS RPCs notification.

Akihiro-Miyazaki on 4 Feb 2021

Hi @Akihiro-Miyazaki,

1. Looks good

2. A few notes on this:

a. I like the UseCoreRpcConflictManagement parameter. The only change I might ask for there is to use true / false instead of Enable / Disable. @JackLivio do you know what's most common in the ini file?

b. See my revised change to (2) downside:

Enabling this feature will force only one modal RPC to ever be displayed for every OEM implementing SDL. As a result, the system can not support multi ON-screen(ONS) and text-to-speech(TTS) RPCs notification.

However, by using the parameter of UseCoreRpcConflictManagement set to Disable, SDL Core can continue to pass through ONS and TTS RPCs to the HMI as happens now.

3. Upon further reflection, I think that SubtleAlert should be noted as exempt from this proposal and always sent the HMI. I don't see any case where SubtleAlert should not be presented alongside another ONS / TTS RPC. This gets a little tricky since the SubtleAlert has a TTS component, but that is something the HMI would have to manage if there's another TTS going on (e.g. from a PerformInteraction). I think that when this proposal feature is enabled, SubtleAlert becomes much less useful. It's not useful to display a notification if a choice set has to be dismissed to see it.

I'm okay with this proposal going through without this, but I do think it's a downside that really hurts SubtleAlert.

joeljfischer on 4 Feb 2021

@joeljfischer -san,
Thank you for your a lot of advice.

2a.
We will follow the common.
@JackLivio -san,
Please let us know the rule of .ini file.
Thank you.

2b.
Thank you so much for your advice.
We will modify the Potential downsides according to your advice.
Also, if the common is True/False, then modify it.

3.
To remove SubtleAlert from RPC priority table means to become lower priority than other RPCs written in RPC priority table. Because the following is shown in this proposal.

OEMs can delete any RPC priority. For example, if the priority of UI.Slider is deleted as shown below, its priority will be the same as a normal RPC and will be lower than any RPC in the RPC priority table.

Therefore, we will modify to add the sentence below.

Basically, it is possible to add or remove RPCs from RPC priority table.
If RPC is removed, its priority is lower than other RPCs written in RPC priority table.
However, regarding SubtleAlert, it becomes out of scope of this proposal due to the characteristics of this RPC
and works as before.

Akihiro-Miyazaki on 9 Feb 2021

3. For clarification on this point, you note that if Slider is removed from the table, it will be lower priority than other RPCs and will therefore be dismissed or not appear if another ONS RPC from the table is presented or already present. I understand this part.

However, you also note that SubtleAlert will not function that way? Are you saying that it will still appear alongside other ONS items if it's not on the table and will not function like Slider does? Or will it function like you noted for Slider and be dismissed / not appear if another ONS RPC is already displayed. If possible, could we add to the proposal the following language?

Because SubtleAlert is designed to work alongside other ONS RPCs, it it exempted from this proposal and will be sent to the HMI alongside any other ONS RPC. It will be up to the HMI to determine if the SubtleAlert contains TTS data and whether or not to play that TTS data alongside showing the SubtleAlert UI based on whether other TTS data is currently playing from another RPC.

Is this acceptable? It does put slightly more work on the HMI developer to handle TTS conflicts with SubtleAlert but allows SubtleAlert to continue in its primary function.

joeljfischer on 9 Feb 2021

👍1

2a.

https://github.com/smartdevicelink/sdl_core/blob/master/src/appMain/smartDeviceLink.ini#L106

If it is singular parameter it can be added to the main section

; description
param = value

Suggesting:

EnableRPCConflictManager = true

JackLivio on 9 Feb 2021

👍1

@joeljfischer -san, @JackLivio -san
Thank you for your advices.
There is no objection to both 3. and 2a.

Shohei-Kawano on 9 Feb 2021

The Steering Committee voted to return this proposal for revisions on 2021-02-09 to allow the author to update the proposal to include the agreed-upon revisions for items 1, 2, and 3.

Revision summary:

Remove the below sentence from the "Motivation" section of the proposal:
>However, we assume that almost of HMI implementation are managed by prioritizing the latter RPC.

2a. Make EnableRPCConflictManager = true

2b. Modify the "Potential downsides" section in the proposal to include the below sentences:

Enabling this feature will force only one modal RPC to ever be displayed for every OEM implementing SDL. As a result, the system can not support multi ON-screen(ONS) and text-to-speech(TTS) RPCs notification.
However, by using the parameter of UseCoreRpcConflictManagement set to Disable, SDL Core can continue to pass through ONS and TTS RPCs to the HMI as happens now.

Remove references to SubtleAlert from tables and other comments about implementation and add the below sentence to the "Proposed solution" section of the proposal:

Because SubtleAlert is designed to work alongside other ONS RPCs, it is exempted from this proposal and will be sent to the HMI alongside any other ONS RPC. It will be up to the HMI to determine if the SubtleAlert contains TTS data and whether or not to play that TTS data alongside showing the SubtleAlert UI based on whether other TTS data is currently playing from another RPC.

jordynmackool on 10 Feb 2021

The author has updated this proposal based on the Steering Committee's agreed-upon revisions, and the revised proposal is now in review until February 23, 2021.

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/1123

jordynmackool on 17 Feb 2021

Hi, I'm very sorry that I have not been able to review this due to the upcoming release. Could we please keep this in review?

joeljfischer on 23 Feb 2021

The Steering Committee voted on 2021-02-24 to keep this proposal in review to allow for additional review time.

jordynmackool on 24 Feb 2021

@joeljfischer -san
Can you complete the review by this week's steering committee meeting?

Shohei-Kawano on 2 Mar 2021

@Shohei-Kawano I apologize. I've been so busy with this upcoming release that it has been difficult to find time to review this proposal.

I'm going to restart numbering:

1. In the proposed solution you note:

OEMs can modify the App priority table and adjust the priority of application according to their own specifications. In fact, since EMERGENCY is set independently as the highest priority, the priority is determined by the items excluding EMERGENCY. For RPCs with the same priority, the HMI Status priority table, which is described later, will be used to determine the priority.

However, the table above this paragraph and the JSON example below it that contains the EMERGENCY option. Should this be removed or otherwise note that setting it doesn't do anything? Or am I misunderstanding this paragraph?

joeljfischer on 2 Mar 2021

@joeljfischer -san,

1.
Please see JackLivio's comment and my comment.

As you say, maybe the EMERGENCY is not needed on the app_priority.
Since we avoid that anyone ask us why there is not the EMERGENCY in the app_priority, we decided to remain the EMERGENCY as the highest priority in the list.

We hope this comment will be helpful for your understanding.

Akihiro-Miyazaki on 3 Mar 2021

The Steering Committee voted to keep this proposal in review on 2021-03-02 to allow for the conversation to continue on the open item.

jordynmackool on 3 Mar 2021

1. I apologize for missing that previous conversation. Perhaps we could clarify it in the following way?

Table 3. Default settings of App priority table

| App priority (String) | Priority (INT) | Note (String) |
|:-: |:-: |:-: |
| EMERGENCY | 0 | Automatically always the top priority |
| NAVIGATION | 1 | Highest priority |
| VOICE_COMMUNICATION | 2 | |
| COMMUNICATION | 3 | |
| NORMAL | 4 | |
| NONE | 5 | Lowest priority |

OEMs can modify the App priority table and adjust the priority of application according to their own specifications. However, because EMERGENCY is set always the highest priority, the priority is determined by the items excluding EMERGENCY. Including EMERGENCY will change nothing. For RPCs with the same priority, the HMI Status priority table, which is described later, will be used to determine the priority.

Below shows the Json example for the App priority table:

"app_priority":{
    "EMERGENCY": 0, // Does not need to be included, if it is included it will be ignored no matter its assigned priority. See above.
    "NAVIGATION": 1,
    "VOICE_COMMUNICATION": 2,
    "COMMUNICATION": 3,
    "NORMAL": 4,
    "NONE": 5
}

If that is not acceptable, I'm okay with leaving it as is. I think the above changes would just help for clarification in implementation.

joeljfischer on 3 Mar 2021

@joeljfischer -san,
1.
Thank you for your advice.

We think your suggestion is helpful for clarification in implementation.
Therefore, we will modify proposal solution according to your suggestion.

Akihiro-Miyazaki on 5 Mar 2021

The Steering Committee voted to accept this proposal with revisions. The author is to update the proposal to include the agreed-upon revisions in this comment (which include modifying table 3, and the sentence following it).

jordynmackool on 10 Mar 2021

@Akihiro-Miyazaki please advise when a new PR has been entered to update the proposal to reflect the agreed-upon revisions. I'll then merge the PR so the proposal is up to date, and enter issues in impacted repositories for implementation. Thanks!

jordynmackool on 10 Mar 2021

The proposal has been updated and implementation issues have been entered:

Note: HMI issues have not been entered as it is believed that they will only need to be tested against for this proposal. If this is not the case when implementation for this proposal begins then issues can then be entered.

jordynmackool on 18 Mar 2021

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

All 94 comments

Related issues