[Rejected] SDL 0065 - SDL Remote Control

[theresalech]

Hello SDL community,

The review of "SDL Remote Control" begins now and runs through May 30, 2017. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0065-remote-control.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/190

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

[shoamano83]

Hi, I don't have strong opinion about the RC feature itself (it sounds cool). But I was curious why HMI level is influenced by this feature. I guess SDL core needs to treat RC app's HMI level in a different way, which may be somewhat complex.

By the way, does passenger's RC app still have controls in BACKGROUND HMI level?

(Please excuse me if the documents already cover these. I didn't have enough time to go through all of them.)

[shengbi]

It would be great if authorized SDL app can control in-car systems, in addition to climate and volume, I am thinking window (upper/lower) and wiper (start/stop) as well.

[yang1070]

@shoamano83 Yes, the passenger's application do have controls in BACKGROUND or LIMITED HMI level. In the example workflow in the attached document (https://github.com/smartdevicelink/sdl_evolution/blob/master/assets/proposals/0065-remote-control/0065_SDLRC_HMI_Guidelines_v1%201.pdf ), the application goes to LIMITED HMI level directly. The current design has two factors for controlling app's behavior regarding the HMI level. The first factor is policy table, which defines what RPCs are allowed in what HMI levels. (this applies to all RPCs, it is not remote control specific. )The second factor is the control resource management, that says at any time at most one application can control the target RC module. Once an application gets the control right, it will hold the right until it exits, no matter in what HMI levels.

[yang1070]

@shengbi More remote control targets or modules can be added later. We are also considering power seat controls, lights, HMI settings, audio sources and more. However, this proposal is limited to what we have in the remote control feature branch developed by Luxoft. Once the foundation is laid out, adding new control targets is simply adding new parameters to the RC RPCs in SDL point of view. More heavy work is in the SDL integration with the vehicle.

[theresalech]

Due to being a large feature, discussion is open and we urge the Steering Committee to review, comment and ask questions in preparation for next week’s (2017-06-06) Steering Committee meeting.

[Toyota-Sbetts]

Overall we are highly supportive of the idea behind this proposal and think it's a unique feature for SDL. From Toyota side, we want to ensure the proposal is able to cover the base requirements for each of the initially supported systems outlined here (Radio and HVAC). We've been reaching out to our internal teams and departments to gain feedback but I think it's unlikely we'll have enough information from our side to vote on this by 6/6/2017.

[stefanek22]

@Toyota-Sbetts We agree that some use cases are not covered in the existing code / design. Our purpose here is to agree that this assessment is an accurate representation of the feature as it is currently being merged for a v4.4 release. Only then can we actually enter further proposals to close any gaps, etc., and hopefully address before the initial release of the feature. We are not intending for a vote here to represent approval of the final feature.

[Toyota-Sbetts]

@stefanek22 I understand your point, but this seems against the usual requirements for proposals. So I guess from Toyota's side we would like to understand the requirements for being able to accept proposals more thoroughly. Why is it acceptable for this feature to be accepted while also being incomplete while other proposals are not?

We also are looking more deeply into the app control use cases (Driver vs Passenger devices) as we're not sure this is the best way to handle this. Due to travel for TUD, we may not complete our investigation by tomorrow. I'm just trying to give a heads up before the meeting that Toyota may not be prepared to vote due to the scope of this proposal.

[joeygrover]

@Toyota-Sbetts as discussed in the workshop this specific feature is a grandfathered feature as it was designed before the actual forming of the SDLC (2015 initial time frame). Most of the work has already been completed in regards to this proposal. Taking it through this process is more so all members can understand it. This is not common practice and will not continue to happen.

[theresalech]

The Steering Committee has voted to keep this in review and allow members additional time to fully evaluate the proposal.

It was also noted that the purpose of this proposal is to educate members on what's included with this feature, which has existed for quite some time and is currently being targeted for the SDL Core 4.4 Release. This proposal should be viewed as a baseline, with the expectation that once accepted, additional proposals can be entered for enhancements to the feature. However, if there are any concerns with this baseline, those should be brought forward by members during the review of this proposal, to ensure that future "enhancements" don't become complete overhauls of the original feature.

[Toyota-Sbetts]

Hi All,

Sorry for the delay. Toyota would like to request to vote on this in the 6/20 SDLC meeting. Please let us know if there are any concerns with this request.

[mfoedisch]

Hi all,

in the proposal so far, each data item is explicitly specified - its existence and parameters. This would probably work well for most very common items. But the approach is always limited to what is currently in the protocol and might not well support very specific OEM requirements.

Would it make sense to use something like a SystemRequest RPC that would take encrypted binary data as payload? This would be generic and allow for very OAM specific solutions in terms of encryption as well as parameters. Generic Notifications and Responses would still need to be defined though.

Maybe this could be an addition to the described approach - maybe even a fallback approach for whatever is not (yet) in the protocol.

[theresalech]

The Steering Committee has voted to defer this proposal to next week (2017-06-20), and have a workshop to discuss the proposal in more detail before voting. During the workshop, the Steering Committee will work to solidify the base mechanisms of Remote Control and identify enhancements (extending RC functionality) that can be brought as proposals after the base functionality is agreed upon.

[theresalech]

The Steering Committee has decided to defer this proposal, and break up its components into smaller proposals to allow representatives to vote on more specific parts of the Remote Control feature. Once those smaller proposals have been entered and voted upon by the Steering Committee, this proposal can be addressed.

[theresalech]

The Steering Committee voted to reject this proposal, as the following have been accepted in its place:

• SDL 0071 - Remote Control Baseline
• SDL 0099 - New Remote Control Modules
• SDL 0105 - Remote Control - Seat
• SDL 0106 - Remote Control - OnRC Status Notification

This closed proposal may still be referenced as additional proposals regarding enhancements to Remote Control are entered.