RE: Vehicle Information API Draft Now Published

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

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?

CruiseControlStatus. Should apps be able to subscribe to "+" and "-" events?

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

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

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

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.