Re: comments on basic framework draft

I concur.  Zones in array seems reasonable to me as well.

Paul J. Boyes
--------------------------------
Mobile:   206-276-9675
Skype:  pauljboyes




On Jan 20, 2014, at 9:08 AM, Rees, Kevron <kevron.m.rees@intel.com<mailto:kevron.m.rees@intel.com>> wrote:

Having zones represented as an array seems reasonable.  In my own use
cases, code would only have to modified slightly but ease-of-use is
still preserved.  For example, instead of checking the  bitfild if the
attribute is in "Front", you can use indexOf() with the same effect.

If Justin is okay with using an array, I'll make the change with the
other changes and push it for additional comment.

-Kevron



On Mon, Jan 20, 2014 at 8:12 AM, Andy Gryc <AGryc@qnx.com<mailto:AGryc@qnx.com>> wrote:
Thanks so much Stephen, I'm very glad that you helped fill out the
discussion we had on Tuesday.

I completely agree with your comments regarding bitfields and how they may
not work for the purpose of extendability—I mentioned the same concern on
the call. The concept of lists will be needed elsewhere too, so I think it's
important that they are supported. For example, in the QNX piece that I
added types & ranges too, the same need for lists came up in describing door
configurations. I'll have to leave it up to Kevron, Justin and anyone else
WebIDL-expert who wants to chime in (Paul? Aldric?) on precisely how we
would implement it.

I'm not sure what the right representation of zone would be, but thank you
so much for your use cases. They will greatly help us in figuring out a
proper representation.
--Andy

From: <Gerken>, Stephen <sgerken@jaguarlandrover.com<mailto:sgerken@jaguarlandrover.com>>
Date: Friday, 17 January, 2014 4:29 PM
To: "public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>" <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>
Subject: comments on basic framework draft
Resent-From: <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>
Resent-Date: Saturday, 18 January, 2014 5:17 PM

Hi all,

Below please find comments on the basic framework draft as found at
https://raw.github.com/tripzero/automotive-bg/master/vehicle_spec.html as of
17th January 2014.

The general appearance of the document is consistent with expectations for a
W3C standard.  The document is well laid out and well organized.

The concept of "zone" as presented in the draft appears to be an attempt to
capture the concept that multiple sensors on a vehicle will report data of
the same data type, and that within a group of such sensors reporting on a
common data type, it may be useful to distinguish individual sensors from
one another on a basis of physical location.  While the underlying concept
is sound and worthwhile, the particular implementation of "zone", as
detailed in the draft, is incomplete.

As drafted, "zone" is a solely planar distinction, with bitfielded values
for front/mid/rear, left/center/right.  For some vehicle equipment, this
division may be sufficient; many passenger car models have four wheels, four
seats, and four or five doors, which can be adequately described as a wheel
in the front right zone, a seat in the rear left zone, or a door in the
center rear zone (a hatchback).  However, even with these mundane examples,
zones as currently described do not adequately disambiguate equipment.  Some
full-size pickup trucks have dual rear wheels; for such models, "tire
pressure on wheel in right rear zone" describes two pressure sensors, one
for each of the dual right rear wheels.  We should not assume that no future
vehicle with dual wheels will be a passenger car.

Additionally, other equipment types will not disambiguate easily in a planar
zone concept.  For example, existing JLR models have up to 24 camera views.
Some cameras may be front-mounted but side-facing, while others may be
front-mounted but rear-facing.  There may be camera clusters in which many
cameras share a common mount point, for example in the rear right quadrant,
and for which the cameras are distinguished from one another by view angle,
view direction, spectrum of sensitivity, resolution, or other factors not
contained in a planar zone concept.  Generally, equipment types for which a
planar zone does not adequately locate a single sensor include:
+ microphones, which may have multiple vertical placements within a given
planar zone;
+ microphones, again, in that two mics in close physical proximity may have
different sensitivities;
+ audio speakers, which may have multiple vertical placements within a
given planar zone;
+ audio speakers, again, for which woofers and tweeters may share a planar
zone;
+ tire pressure, in the case of dual wheels mentioned above;
+ accelerometers, which in addition to physical location, also have axes of
sensitivity;
+ cameras, which may have differences of view angle, view direction,
spectrum, and resolution as discussed above;
+ airbags, for which a right front zone may have multiple airbags located
in a body pillar and in the roof, collectively forming a side curtain, and
also an additional airbag located in the front of the right front zone in
the dash.

In light of the above examples of the diversity of sensors in modern
vehicles, and bearing in mind the creativity of current and future
automotive engineers, it would seem prudent to permits manufacturers to
specify bases for disambiguation of equipment which are not restricted to a
purely physical planar location, or even to a predetermined set of bases of
which we are currently aware.

As a technical point on the specific implementation of Zone, the current
implementation is as a bitfield.  This means Zone exists as a single field
within the interface, which is masked against predefined constants in order
to extract information from that field about which specific zones are on or
off.  Effectively, the Zone field carries information as a fixed-length
array of boolean values, where the array length is either 16 (for a short,
as currently defined) or 32 (if altered to a long). With either 16 or 32
maximum possible masks, it is entirely possible that the number of actual
useful bases of disambiguation would exceed the array length, leading to an
awkward overlaying situation; if this data type is for microphones, 0x80
means speech spectrum, but if this data type is for speakers, 0x80 means
tweeters.  While subtyping the zone masks based on the data type is a
possible means of extending the zone space beyond 16 (or 32) values, this
approach is awkward to document and difficult to code correctly, and should
be avoided if possible.

It would be preferable for Zone to be an actual array, not a bitfield.  If
Zone were an actual array, it could still be an array of ints, but since
masks wouldn't be necessary, the number of meaningful values of those ints
could be 2 ^^ 16 instead of 16.  So for example:
const short Front = 0x0001;
const short Middle = 0x0002;
const short Rear = 0x0003;
const short Left = 0x0004;
const short Center = 0x0005;
const short Right = 0x0006;
const short Xaxis = 0x0007;
const short Yaxis = 0x0008;
const short Zaxis = 0x0009;
....
const short MfgBase = 0x8000;
const short JLROuter = MfgBase + 0x0040;
const short JLRInner = MfgBase + 0x0041;
....
VehicleCommonDataType{ ... readonly attribute Zone[] zone; ... }...
such that a returned instance tpres of VehicleTirePressureDataType has
tpres.zone[0] == Rear, tpres.zone[1] == Left, tpres.zone[2] == JLRInner.

Also, as a minor copyediting detail, the word "information" in the draft is
variously misspelled as "inforomation" and "Infomration".

Generally however it's clear that a lot of effort and thought has gone into
bringing the document to it's current draft state, and there is good
material here which is worth building upon as the scope of the document is
fleshed out.

Regards,
Steve Gerken
-------------------
Linux Developer
MSX, as broker for Jaguar Land Rover

One World Trade Center, 121 SW Salmon Street, 11th Floor, Portland, Oregon,
97204
Email: sgerken@jaguarlandrover.com<mailto:sgerken@jaguarlandrover.com>