Re: Vehicle Information API Draft Now Published

Hi Vadim,

On Mon, May 19, 2014 at 6:14 PM, Vadim Draluk <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.

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

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

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

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

Received on Friday, 23 May 2014 16:26:02 UTC