RE: Vehicle Information API Draft Now Published

-----Original Message-----
From: Rees, Kevron [mailto:kevron.m.rees@intel.com]
Sent: Friday, May 23, 2014 9:26 AM
To: Vadim Draluk
Cc: Paul Boyes; public-autowebplatform@w3.org; internal-autowebplatform@w3.org
Subject: Re: Vehicle Information API Draft Now Published



Hi Vadim,



On Mon, May 19, 2014 at 6:14 PM, Vadim Draluk <vadim.draluk@gm.com<mailto:vadim.draluk@gm.com>> wrote:

> Team,

>

>

>

> Below please see some questions and thoughts on new documents, mostly

> to be considered as something to discuss at our F2F.

>

>

>

> 1.      The Vehicle Information API paper

>

>

>

> Security. I’ve had some extensive written and verbal discussions with

> Dave Ragget, chair of the Apps WG that is covering security. My

> impression is that the group is right now focusing on defining a

> common security model specifically for Web apps, not necessarily

> embedded ones (where they believe there’s little chance to reach a

> consensus between existing platforms). This is the opposite of at

> least GM priorities, which are right now firmly with variations of the

> embedded variety (including ones running in the IVI unit and, albeit with lower priority, ones deployed in mobile devices).

>

>

>

> Hope we have time to talk about it during our F2F. We will probably

> have to settle for some wording that delegates permissions to two

> layers above, the JS app FW layer (Tizen, QNX, whatever else) and the

> OS layer (after all, permissions have to be generated into, say,

> Android manifest, and these are likely to be based on ones defined for underlying native functions).

>

>

>

> Availability. I think the current proposal is quite good as it stands now.

> I’d like to clarify couple of things, such as:

>

> -        Do we need a return code indicating that user consent dialog has to

> be displayed? Not saying it’s really required, as it can be made part

> of the implementation as APIs are asynchronous – still would like to

> talk it through

>

> -        Do all the “negative” codes in Availability correspond to

> permission_denied in VehicleInterfaceError?

>

>

>

> 2.      The Vehicle Data doc

>

>

>

> UnitsOfMeasure. The interface does not fully reflect the proposal I’ve

> written up and adjusted according to quite a few comments I have received.

> It is missing quite a few units that are in the proposal. Elsewhere in

> the document I only see SI-based values returned. So looks like this

> interface is not completely incorporated into the doc in its full and

> most comprehensive form

>



You are correct.  I haven't merged in your proposal yet.  If you could submit your proposal as a pull request on github, it'd speed up the process of merging it in.



No need, in F2F the decision was made to go back to SI, and to eliminate UnitsOfMeasure altogether



>

>

> DriverIdentification. IMO this one has to be substantially

> generalized. Key fob is only one method of identification, and there

> are already other methods deployed, announced or implemented: face

> recognition, Bluetooth, eventually fingerprint and whatever else. A

> good overall approach would be to separate ID type (one of the above)

> and the actual ID whose semantics is determined by the type.

>

>

>

> TransmissionConfiguration. Should “dsg” not be a separate value if

> “cvt” is one?

>

>

>

> TripMeter. Is there an event that resets the trip meter? If so, it

> would be meaningful to have an API that supports callback upon this

> event, so that apps can do their own adjustment.

>

>

>

> TransmissionMode. Should we account for modes like “Sport”, “Winter”

> and such?

>



This is called "DrivingMode" in the spec.  I don't know if I like the name... but it is what it is for now.



Got it, we had a discussion around it at F2F. “Winter” is probably a value to be added there



>

>

> CruiseControlStatus. Should apps be able to subscribe to “+” and “-“ events?

>



Please elaborate on what you mean by "+" and "-"?  Do you mean button events when the user hits the "+" button to increase the cruise control speed?  When would it be useful to get that event rather than the speed change event?



Please disregard, this was silly



>

>

> DeadReckoning. Looks too low-level to be exposed to apps, usually

> calculated into location info, often in a separate ECU, not available

> to IVI at all

>



This has already been proposed to remove.  I will do this soon.



>

>

> Odometer. Many vehicles have support for at least two parallel trip

> counters – should we account for that?

>







>

>

> Tire. How does one get readings for a specific tire? Not saying it’s

> not there, just can’t find it. Or is it Zone-based? If so, should be

> made explicit

>



Agreed.  It should be explicit.  I'll make that change.  Do we also want to combine wheel tick here or should we make that an independant type?



Yeah, there’s been interest expressed in salvaging that one from DeadReckonong, and this interface is as good as any



>

>

> DriveMode. This one looks very confusing. Not clear whether it

> pertains to transmission or suspension, and looks like it has

> components of both (“comfort” looks like a suspension setting, “sport”

> can apply to either one whereas “eco” looks very much like

> transmission related. Not sure what “manual” has to do with any of it).

>



I suppose it's up to the implementation what it pertains to.  I can see "sport" applying to suspension, transmission and engine/fuel profiles, throttle responsiveness, etc.  I'm not sure "manual" makes much sense here either.



>

>

> VehicleSound. Wondering what can one do with

> engineSoundEnhancementMode, especially given that it’s marked as

> OEM-specific from the get-go

>

>

>

>

>

> From: Paul Boyes [mailto:pb@opencar.com]

> Sent: Friday, April 25, 2014 9:33 AM

> To: public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>; internal-autowebplatform@w3.org<mailto:internal-autowebplatform@w3.org>

> Cc: Vadim Draluk

> Subject: Vehicle Information API Draft Now Published

>

>

>

> The Vehicle Information API draft is now published in the reports

> section

> here:

>

>

>

> http://www.w3.org/community/autowebplatform/


>

>

>

> Please review and send your questions and comments to the group.

>

>

>

> Thanks to everyone who has helped get the specification to this point.

>

>

> Paul J. Boyes

>

> --------------------------------

>

> Mobile:   206-276-9675

> Skype:  pauljboyes

>

>

>

>

>

>

>

>

>

> Nothing in this message is intended to constitute an electronic

> signature unless a specific statement to the contrary is included in this message.

>

> Confidentiality Note: This message is intended only for the person or

> entity to which it is addressed. It may contain confidential and/or

> privileged material. Any review, transmission, dissemination or other

> use, or taking of any action in reliance upon this message by persons

> or entities other than the intended recipient is prohibited and may be

> unlawful. If you received this message in error, please contact the

> sender and delete it from your computer.


Nothing in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.

Confidentiality Note: This message is intended only for the person or entity to which it is addressed. It may contain confidential and/or privileged material. Any review, transmission, dissemination or other use, or taking of any action in reliance upon this message by persons or entities other than the intended recipient is prohibited and may be unlawful. If you received this message in error, please contact the sender and delete it from your computer.