RE: comments on basic framework draft

Hi Kevron, Stephen,

Personally, I prefer the array type attribute which Stephen suggested.
It's simple but has enough expandability.

Only one thing not quite clear to me is whether X, Y, Z axis are proper as attributes of 'zone'.
It looks a matter of preference and hard to say or prove the other way is wrong.

Unfortunately, I still believe it would be more clear to assign a separate attribute to the disparate concepts.
>From what I understand, zone is the location of the vehicle.
And sensing direction of accelerometer or collision detector looks a different attribute.
It's an attribute of the sensor rather than a location in the vehicle.
So, my suggestion is as below.

interface Acceleration {
     readonly    attribute Zone    zone;
     readonly    attribute byte    sensingDirection; // ["X_AXIS","Y_AXIS","Z_AXIS"] or ["HORIZONTAL","VERTICAL"]
     readonly    attribute double  value;
};


In addition, I remember we have already agreed on using 'Driver' and 'Passenger' additionally.
So, it'll be good to have those in zone.

interface Zone {
    const DOMString Front = "Front";
    const DOMString Middle = "Middle";
    const DOMString Rear = "Rear";
    const DOMString Right = "Right";
    const DOMString Left = "Left";
    const DOMString Center = "Center";
    const DOMString Driver = "Driver";
    const DOMString Passenger = "Passenger";
}

Users can use both zone=["Driver"] and zones=["Front", "Left"].
And the system will determine whether the driver seat is left or right.

Anyhow, it's not a roadblock for our work, so we can keep the ball rolling.
It will not a big deal to apply/update the result in any conclusion.

Regards,
Justin


-----Original Message-----
From: Rees, Kevron [mailto:kevron.m.rees@intel.com] 
Sent: Thursday, January 23, 2014 12:48 PM
To: Gerken, Stephen
Cc: jongseon.park@lge.com; Andy Gryc; public-autowebplatform@w3.org; Grant Courville; Tina Jeffrey
Subject: Re: comments on basic framework draft

Another way to do zones suggested by a Sys Apps editor would be something like this:

enum Role {
  "driver",
  "passenger",
  ...
}

interface Zone {
  attribute unsigned short row;
  attribute unsigned short col;
  attribute Role role;
  readonly attribute Zone driver;  //returns instance of zone for logical driver
  readonly attribute Zone passenger;
  readonly attribute unsigned short rows; // returns number of rows in the vehicle.

  unsigned short cols( unsigned short row); //returns number of columns in a given row.
}

rows and cols can be 0...n and thus can be extended by a lot.  I know we have implicitly thought about passenger cars, but this kind of model avoids the awkwardness of arrays, is not a foreign w3c pattern, and is also quite extensible.  Further, I'm not sure if it would be appropriate to use the "role" attribute for the further designations that Steven is suggesting, but it seems like it could be a possibility.  Here are a few examples on how it would be used:

        var zone = new Zone;

        var value = {};
        value["acStatus"] = true;
        vehicle.climateControl.set(value, zone.driver ).then(function(){
           console.log("successfully set acStatus");
        },
        function(error) {
          console.log("there was an error");
        });

get example:

      vehicle.accelerometer.get({"role" : "CollisionDetection"}).then(
fuction(acceleromter) { //does exist! }, function(error) { //may not exist } );

or we can try to determine ahead of time if this role exists:

     var zones = vehicle.accelerometer.zones;

     for(var zone in zones)
     {
         if(zone.role == "CollisionDetection")
             /// we got it!
     }

Thoughts?

-Kevron


On Wed, Jan 22, 2014 at 10:59 AM, Gerken, Stephen <sgerken@jaguarlandrover.com> wrote:
> Hi Justin,
>
> Thanks for your further comments, and for your earlier clarification 
> questions.
>
> Regards accelerometer, I will grant that it's an odd exercise in 
> mental gymnastics to reconcile a "zone" concept with an accelerometry 
> axis of sensitivity.
>
> To me, a relevant question is the question of what API would need to 
> be used, by someone programming to the IDL from the user interface 
> side, in order to effectively group or disambiguate accelerometers.  I 
> expect that Zone is intended to be used for this purpose generally, 
> insofar as Zone contains front/rear/left/right/primary/redundant/etc. 
> designations.  The API already presents the programmer of user-facing 
> systems with a paradigm of querying the Zone to find which 
> accelerometers are in the front right quarter.  Such a programmer, who 
> wishes to further discover whether such a device is a 
> collision-detection device or an active suspension device, will expect 
> to find that information in the Zone as well.  So, a given 
> accelerometer may represent its Zone as, perhaps, new Array("Front", 
> "Right", "CollisionDetection", "Yaxis"); for a side-impact collision detection device.
>
> The same accelerometer may also report data as acceleration.yAxis = 
> -3.14; with other axes in the acceleration interface undefined.  
> However, if the axis sensitivity information is carried only in device 
> data, the programmer of user-facing systems needs to both query a Zone 
> field and also retrieve and query a device datum in order to do device 
> differentiation.  It is simpler for the high-level consumer of the API 
> if necessary device differentiation can be performed entirely with the Zone interface.
>
> Thanks,
>
> 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
>
>
> On 22 January 2014 02:42, 박종선(Justin Park) <jongseon.park@lge.com> wrote:
>>
>> Hi Stephen,
>>
>>
>>
>> I just wanted to clarify those things, and now it’s pretty clear to 
>> me except issue #4.
>>
>>
>>
>> Regarding accelerometer, there is a similar existing work.
>>
>> http://dev.w3.org/geo/api/spec-source-orientation.html
>>
>> It looks very handset oriented, but seems that it can be used for 
>> vehicle also.
>>
>>
>>
>> I expected that we’d have an Acceleration interface as like below.
>>
>> interface Acceleration : VehicleCommonDataType {
>>
>>     readonly    attribute double? X;
>>
>>     readonly    attribute double? Y;
>>
>>     readonly    attribute double? Z;
>>
>> };
>>
>>
>>
>> It means I’m not sure we need to use as like below.
>>
>> acceleration.zones = new Array("Front", "Center", "Xaxis");
>>
>> acceleration.value = -3.14
>>
>>
>>
>> Instead, the following looks fine.
>>
>> acceleration.zones = new Array("Front", "Center");
>>
>> acceleration.xAxis = -3.14
>>
>>
>>
>> If a sensor located in the front center senses only x values, y and z 
>> values must be invalid.
>>
>> The point is that it seems not a zone attribute which direction a 
>> sensor is sensitive. It looks like different attribute from zone.
>>
>> Thus it will be more clear to separate it from zone, and add to the 
>> specific interfaces which requires it.
>>
>>
>>
>> Regards,
>>
>> Justin
>>
>>
>>
>> From: Gerken, Stephen [mailto:sgerken@jaguarlandrover.com]
>> Sent: Wednesday, January 22, 2014 2:08 AM
>> To: jongseon.park@lge.com
>> Cc: Rees, Kevron; Andy Gryc; public-autowebplatform@w3.org; Grant 
>> Courville; Tina Jeffrey
>>
>>
>> Subject: Re: comments on basic framework draft
>>
>>
>>
>> Hi Justin, Kevron, et al,
>>
>>
>>
>> Thanks much for all your additional comments.
>>
>>
>>
>> Kevron, you're quite correct that there is some awkwardness in array 
>> comparisons.  Note further that an array [ Left, Front ] != an array 
>> [ Front, Left ], while for purposes of hardware location they are the same.
>> For such purposes, where I used array, perhaps a better term would be 
>> unordered set, although that is a math term not so much a programming one.
>>
>>
>>
>> Justin, I think:
>>
>> 1) We should certainly allow hardware_device.zone[0] = Rear without 
>> designation of left/center/right. Heating or a/c zones may 
>> differentiate only into front left, front right, and rear, i.e. the 
>> rear zone is not differentiated side to side.
>>
>>
>>
>> 2) What we really want for storage is an unordered set, not an array.  
>> I think Kevron is making IDL changes towards wrapping Zone in an API 
>> so users may treat it as an unordered collection even if underneath 
>> it is implemented in an array.  I have yet to read the updated IDL 
>> but wanted to make sure I put in a reply before comments close.
>>
>>
>>
>> 3) We will not restrict combinations to those we think are valid, 
>> because we trust that implementors may be more inventive than we are 
>> and will find valid useful combinations that we haven't imagined.
>>
>>
>>
>> 4) An accelerometer has both a physical location in the vehicle, and 
>> also an axis along which it is sensitive.  So, a manufacturer may put 
>> accelerometers at multiple locations in the vehicle, perhaps one in 
>> front center and one in rear center.  For each of these, it would be 
>> useful to know both where it is located, and also whether the axis or 
>> axes on which it is sensitive are vertical, horizontal forward/back, 
>> or horizontal side to side.
>>
>>
>>
>> I should note also that if an X/Y/Z coordinate system is used, these 
>> terms need to be defined.  One manufacturer might consider the x/y 
>> plane to be that tangent to the road at the location of the car, with 
>> the Z axis vertical, while another might consider the x/y plane to be 
>> that tangent to the front bumper of the car, with the Z axis 
>> horizontal along the driving direction of the car.
>>
>>
>>
>>
>> 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
>>
>>
>>
>> On 21 January 2014 01:25, 박종선(Justin Park) <jongseon.park@lge.com> wrote:
>>
>> I have no objection to using array.
>>
>> Usually, zones have been defined as complete compound words as like 
>> "FrontLeft", "RearRight".
>> It's much simpler although it has a limitation for extension.
>>
>> If we use a combination of "Front" and "Left" in an array, we need to 
>> consider something more.
>>
>> 1) Do we allow seatPosition.zone[0] = "Front" (without following 
>> 'left', 'center', 'right') ?
>>    In case of 'Setting', users may want the command to take an effect 
>> on whole 'front' seats.
>>
>> 2) Do we allow seatPosition.zone[0] = "Left", seatPosition.zone[1] = 
>> "Front" as an opposite sequence?
>>    If we don't restrict which element can be located in the array, 
>> the code must be much complicated.
>>    So, we may need to make a rule as like that "Front", "Middle", "Rear"
>> must be the first element of the array.
>>
>> 3) We will not care about which combination is possible.
>>    It depends on the implementer, and if wrong or non-existing 
>> combination is used,
>>    the system shall respond that 'It's not supported'. That's all. Right?
>>
>> 4) It's hard to imagine how to use X, Y, Z coordinates to zone with 
>> 'left', 'front' things.
>>     I think it would be more clear to separate x, y, z axis from zone 
>> for the data types fit to those system.
>>
>> Is there any missing things to be considered?
>>
>>
>>
>> -----Original Message-----
>> From: Rees, Kevron [mailto:kevron.m.rees@intel.com]
>> Sent: Tuesday, January 21, 2014 2:09 AM
>> To: Andy Gryc
>> Cc: Gerken, Stephen; public-autowebplatform@w3.org; Grant Courville; 
>> Tina Jeffrey
>> Subject: Re: comments on basic framework draft
>>
>> 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> 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>
>> > Date: Friday, 17 January, 2014 4:29 PM
>> > To: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
>> > Subject: comments on basic framework draft
>> > Resent-From: <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.h
>> > tml
>> > 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
>> >
>>
>>
>
>

Received on Thursday, 23 January 2014 07:01:54 UTC