w3c / automotive Goto Github PK

There is "6.23 YawRate Interface" but no Pitch, Roll interfaces.
I guess, pitch and Roll are useful information for passenger comfotability.

6.26 DrivingMode Interface
8.6 DriveMode Interface

I felt similar name and may be confusing.
If DrivingMode is not commonly used name, how about DrivingStatus or some other name?
(I'm not sure about suitable naming.)

We need to decide if we should do this and what the content of the demo should be. The goal and purpose needs to be defined.

I have started a on a description on:
https://www.w3.org/auto/wg/wiki/Main_Page#Oct_20_-_21_.2C_2016_.2CGenivi_AMM.2C_Burlingame

For making automotive specs with REST-ful model, one of important thing is to define the endpoints for resources for vehicle.
Definition of endpoint is below from Principles of good RESTful API Design
Endpoint: An API URL on a Server which represents either a Resource or an entire Collection.

As a first step I suggest below stuffs for the 5. Configuration and Identification Interfaces of the vehicle data spec.

5.2 Identification Interface

vehicle.id.vin
vehicle.id.wmi
vehicle.id.vehicletype
vehicle.id.brand
vehicle.id.year

5.3 SizeConfiguration Interface

vehicle.size.width
vehicle.size.height
vehicle.size.length
vehicle.size.doorscount
vehicle.size.totaldoors

5.4 FuelConfiguration Interface

vehicle.fuel.type
vehicle.fuel.typevariant
vehicle.fuel.position

5.5 TransmissionConfiguration Interface

vehicle.transmission.geartype

5.6 WheelConfiguration Interface
vehicle.wheel.radius
vehicle.wheel.zone

5.7 SteeringWheelConfiguration Interface

vehicle.steeringwheel.location
vehicle.steeringwheel.positiontilt
vehicle.steeringwheel.telescopingposition

At the moment we only have 4 power modes in the spec. Engine cranking (start ignition) would be a useful addition to this enum.

enum VehiclePowerMode {
    "off",
    "accessory1",
    "accessory2",
    "running"
};

E.g. here are BMWs powermodes:
KL 0 = OFF (ignition off position)
KL R = ignition position 1 ("run" - some electronics & modules are powered up)
KL 15 = ignition position 2 ("accessory" - all electronics & modules are powered)
KL 30 = ignition position 3 (where the ignition defaults after starting the engine - running)
KL 50 = ignition start position (engine cranking)

There seems to be some inconsistency over which data types we use when it comes to smaller numbers.

• In the WebIDL specification a "byte" is signed, where an "octet" is unsigned. Therefore we shouldn't use "unsigned byte", as in 10.3.1.
• "unsigned short" is probably overkill for a 0 - 10 value as in 5.3.1.
• As for the difference between octet and byte for small unsigned values it may be arbitrary, but maybe should be consistent.

5.3.1 Attributes
totalDoors of type unsigned short, readonly , nullable
must return total number of doors on the vehicle (all doors opening to the interior, including hatchbacks) (Min: 0, Max: 10)

6.10.1 Attributes
gear of type octet, readonly , nullable
must return transmission gear position. Range 0 - 10

7.4.1 Attributes
wear of type octet, readonly
must return transmission clutch wear (Unit: percentage, 0%: no wear, 100%: completely worn)

10.3.1 Attributes
rain of type unsigned byte, readonly
must return the amount of rain detected by the rain sensor. level of rain intensity (0: No Rain, 10:Heaviest Rain)

In going over new use cases with a security and privacy focus, several would potentially be when the vehicle is off. It is unlikely that the whole head unit would be running but the vehicle may be able for instance to accept a remote signal over cellular network to wake the IVI OS from suspend mode. While aspects of that are clearly outside the spec scope itself, we potentially want to include some.

For remote controle and wake-up signal, we may need some mechanism to identify the state and the mode of the car, the web runtime and the application.

[irc excerpt]
paul: i imagine the web runtime will not be active when the vehicle is off but cannot say that definitively, some may want to keep some background, low power capabilities
ted: there could be a signal sent (oem specific) to wake from suspend mode after which things can be queried
kaz: in that case, we need to identify the state/mode of the car and the web runtime
... so we need some mechanism to manage the state and mode
(regarding wake-up signal)
We may want to consider not only the mode of the car, but also the mode of the app. There may be things you want to allow the app to do in the background vs. foreground.

After Robert from Evergreen Consulting reviewed the specs from the WG, he proposed below items are required to be added. It makes sense to me. @acrofts84 @aShinjiroUrata @QingAn @djensen47 @paulboyes @tobie What do you think?

1. Charger info (rather than battery info)

• charger_pilot_current
• charger_actual_current
• charger_power
• fast_charger_present

2. Charging control

• Set Charge Limit
• Get Charge Limit
• Start Charging
• Stop Charging

3. Fuel temperature by zone (to cover battery temperature)

http://www.wired.com/2015/07/senate-bill-seeks-standards-cars-defenses-hackers/

We will need to account for this development in any spec.

Currently the API works on this signature pattern:

vehicle.dataPoint.method

But dataPoint is, in a sense, just data, i.e, meta-data, itself.

Since we are dealing with many dozen data points some of which may or may not be implemented, something the following this seems cleaner.

vehicle.method(dataPoint, params…)

Now it doesn't appear as if there are dozens or hundreds of APIs, now we have 3 or 4. It also leaves some flexibility to the implementation. Maybe, it's not a 1-to-1 mapping to the clib implementation but I don't think it should be. This is JavaScript/ECMAScript not C.

• vehicle.get(data, options)
• vehicle.set(data, value, options)
• vehicle.subscribe(data, options, callback)
• vehicle.unsubscribe(data, handler)
• vehicle.availableFor...(data)

data is simply a String, the name of the data point like 'vehicleSpeed'
options include information like zone, event period

This also avoids the issue where vehicle.vehicleSpeed.get() could result in a Cannot call method 'get' of undefined if vehicleSpeed is not implemented.

In http://www.w3.org/2014/automotive/data_spec.html#use-cases the summary of use-cases is not consistent with the interfaces defined.

For example, Use Cases for Vision interfaces, http://www.w3.org/2014/automotive/data_spec.html#use-cases-for-vision-interfaces It says that:

• To warn when the vehicle goes on another lane (Lane departure warning function)
• To warn in case of an danger (vehicle, pedestrian, animals, stop sign, red light, ...)
• To record the scene before and after an accident (for insurance or testimony)
• To improve vision in the dark

However, in http://www.w3.org/2014/automotive/data_spec.html#vision-parking-interfaces

• the LaneDepartureDetection Interface http://www.w3.org/2014/automotive/data_spec.html#lanedeparturedetection-interface can just return current status of Lane departure warning function;
• the Alarm Interface http://www.w3.org/2014/automotive/data_spec.html#alarm-interface can just return current status of In vehicle Alarm System

Source: http://www.w3.org/TR/2015/WD-vehicle-information-api-20150616/#set-1

Set
Unsubscribe to single value.

should be

Unsubscribe
Unsubscribe to single value.

1. Parameter of availableFor() doesn't need. Let's remove it.

    Availability availableForRetrieval ();
    Availability availableForSubscription ();
    Availability availableForSetting ();

2. Methods name should be consistent to the related methods. Let's change the name to:

    Availability availableForGetting ();
    Availability availableForSubscription();
    Availability availableForSetting ();

3. They doesn't need to be methods. Let's change them to attributes.

    attribute Availability gettingAvailability;
    attribute Availability subscriptionAvailability;
    attribute Availability settingAvailability;

Then the example 5 will be shorten to

if( ( var a = vehicle.vehicleSpeed.getttingAvailability ) === "available" )
{
  // we can use it.
}
else
{
  // tell us why:
  console.log(a);
}

[Sorry for long introduction, please see end of issue for concrete questions]

Hello,

I am heading the GENIVI Remote Vehicle Interaction expert group, creating technologies and standards to connect the vehicle to the outside world.

A part of this effort is to create a vehicle signal specification (VSS), providing a common nomenclature for components inside and outside the vehicle.
Our current work is available at: https://github.com/PDXostc/vehicle_signal_specification

The difference between VSS and the current W3C Automotive vehicle data specification is that GENIVI intends to provide a much higher resolution and frequency data stream to be consumed and processed inside the vehicle. At the same time, many of those signals will be exported to a backend server.

When talking to Paul Boyes about VSS he expressed an interest in joining our efforts, something which we are very interested in as well.

A first step in that integration process would be for GENIVI to adopt the signals of the existing W3C spec into the VSS signal tree. We have two options on doing this.

1. Retain naming nomenclature.
   In this case we would create a VSS w3c branch and tag on the existing W3C signals directly under it:

external.w3c.VehicleSpeed
external.w3c.ThrottlePosition
external.w3c.DoorOpenStatus
...

1. Integrate W3C signals into the core VSS tree.
   In this case the W3C signals would be used to populate the tree. We would, at the same time, change the naming syntax from underscore (vehicle_speed) to camelcase (VehicleSpeed):

DriveTrain.VehicleSpeed
Engine.ThrottlePosition
Body.Doors.0.LeftFront.DoorOpenStatus

So, with the above in mind, I have three questions.

1. Is it a good idea to integrate the GENIVI and W3C signal definitions?
2. If the answer is "yes", which of the two adoption strategies above should we go with?
3. Are there any requirements that GENIVI can take in from W3C as the spec work continues?

Any input on this would be much appreciated.

Sincerely,

/Magnus F.
mfeuer1 a t jaguarlandrover.com
Expert Group Lead - Remote Vehicle Interaction
GENIVI.

Hi Everyone,

1. In the current spec we allow for subscriptions to an interface and not to an attribute within an interface. For example, the trip interface contains multiple attributes:

interface Trip {
    readonly    attribute unsigned long   distance;
    readonly    attribute unsigned short? averageSpeed;
    readonly    attribute unsigned short? fuelConsumption;
};

// does not allow distinction between distance, averageSpeed, fuelConsumption
var tripInterface = vehicle.trip.subscribe(callbackFunction, desiredZone, period);

2. The main criticism received from the Generic Sensor API WG was that the current spec was "not very web", and they suggested implementing a DOM Events style, as per their API, in order to make the spec more usable and intuitive to a web developer. I think it is a valid point, but maybe someone with more web development experience could advise.

In order to alleviate both of these issues, we could use the following:

interface VehicleSignalInterface : VehicleInterface {
    Promise        set (object value);
    attribute EventHandler onchange;
    attribute EventHandler onerror;
    attribute EventHandler ondata;
    attribute DOMString attributeName;
    attribute unsigned long? period;
    attribute Zone? zone;
};

//this could then be implemented as:
var averageSpeedSubscription = vehicle.trip
averageSpeedSubscription.attributeName="averageSpeed"
averageSpeedSubscription.onchange = function(){ 
    //do something
};
averageSpeedSubscription.onerror = function(error){ 
    //flag error
};
averageSpeedSubscription.period=100;
//if zones where applicable
averageSpeedSubscription.zone="left"

var distanceSubscription = vehicle.trip
distanceSubscription.attributeName="distance"
distanceSubscription.onchange= function(){ 
    //do something else
};
distanceSubscription.period=100;

The unsubscribe function would then be obsolete.

Let me know if there are any glaring errors or disadvantages to this approach. If not, I'm happy to make a full proposal for review.

Thanks,

Adam

Vehicle Information Access API - Test plan.

How to test: w3c.github.io/testing-how-to
Look for conformance requirements in the spec:
"In the simplest case, a conformance requirement is any single statement that uses RFC 2119 language (MUST, MUST NOT, SHOULD, SHOULD NOT, MAY), that specifies required behavior for a particular conformance class defined elsewhere in the spec (e.g., a Web browser or other user agent).”

Ex 1:
From the spec“ Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings defined in the Web IDL specification [WEBIDL], as this specification uses that specification and terminology"

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Web Storage IDL tests</title>
<link rel="author" title="W3C" href="http://www.w3.org/" />
<link rel="help" href="http://www.w3.org/TR/webstorage/#storage"/>
<script src="/resources/testharness.js"></script>
<script src="/resources/testharnessreport.js"></script>
<script src="/resources/WebIDLParser.js"></script>
<script src="/resources/idlharness.js"></script>
</head>
<body>
<h1>Vehicl Access API  IDL tests</h1>
<div id="log"></div>
<pre id='untested_idl' style='display:none'>
[PrimaryGlobal]
interface Window {
};
interface Event {
};
interface EventInit {
};
</pre>
<pre id='idl'>
interface Vehicle {
 readonly attribute VehicleSignalInterface vehicleSpeed;
 readonly attribute VehicleSignalInterface wheelSpeed;
 …    
        };
...
<script>
(function() {
    var idl_array = new IdlArray();
    idl_array.add_untested_idls(document.getElementById("untested_idl").textContent);
    idl_array.add_idls(document.getElementById("idl").textContent);
    idl_array.add_objects({Vehicle: ["navigator.vehicle"]});
    idl_array.test();
})();
</script>
...
</html>

Ex 2:
From spec: "driver of type Zone, readonly must return physical zone for logical driver"
So, test that the driver is either front right or front left (any of the valid logical driver positions…)

...
 Assert_equal(driver.value,leftfrontzone) || Assert_equal(driver.value,rightfrontzone)
…

Suggestion to follow the Test the Web Forward: http://w3c.github.io/testing-how-to/#(11)

Why follow Test the Web Forward?

• They know how to test the Web
• They want the Web to work, no exceptions
• A growing number of browser vendors are running the TTWF tests
• They have a lot of test infrastructure ready to use
• Your lifespan is too short to reinvent it
• They have happy and cool dinosaurs on their landing page

Next step
http://testthewebforward.org/docs/
So, basically fork the test repository and submit our tests Vehicle/xxx.hmtl using pull requests.

Who will contribute ?
Actions ?
Next meeting ?

The steeringWheelLeft attribute name feels very ambiguous to me. Would this be better off as a Zone? Or a less ambiguous term e.g. leftHandDrive or driverSideLeft. Although I don't know how well these translate.

5.7.1 Attributes
steeringWheelLeft of type boolean, readonly , nullable
must return true if steering wheel is on left side of vehicle

Hi All,

I've had a look at the JSON Schema idea instead of WebIDL:
http://json-schema.org/
https://openconnectivity.org/resources/specifications

Taking the authorize messages as my examples, I have written the following schemas. JSON Schema allows the use of references, but it is traditionally either within an interface or within a separate JSON document, not within a larger document. I believe we can still however provide these definitions separately to make our documentation more readable, as in the example below.

I'm happy to elaborate on this idea if this is appropriate.

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "Authorize Request",
    "description": "Enables the user to set access controls for the vehicle signals",
    "type": "object",
    "required": ["action", "tokens", "requestId"],
    "properties": {
        "action": {
            "enum": [ "authorize" ],
            "description": "The identifier for the authorize request",
        },
        "tokens": {
            "description": "Name of the product",
            "type": "object",
            "properties": {
                "authorization": {
                    "description": "The user token, for the user that the client is making requests on behalf of",
                    "type": "string"
                },
                "www-vehicle-device": {
                    "description": "The device token for the originating device that is making the request to the server",
                    "type": "string"
                }
            }
        },
        "requestId": {
            "description": "The unique identifier as specified by the client",
            "type": "string"
        },
    },
}

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "Authorize Success Response",
    "description": "The response sent from the server upon a successful authorization request",
    "type": "object",
    "required": ["action", "TTL", "requestId"],
    "properties": {
        "action": {
            "enum": [ "authorize" ],
            "description": "The identifier for the authorize request",
        },
        "TTL": {
            "description": "The time to live of the authorization token",
            "type": "integer"
        },
        "requestId": {
            "type": "string"
        },
    },
}

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "title": "Authorize Error Response",
    "description": "The response sent from the server upon an unsuccessful authorization request",
    "type": "object",
    "required": ["action", "error", "requestId"],
    "properties": {
        "action": {
            "enum": [ "authorize" ],
            "description": "The identifier for the authorize request",
        },
        "error": {
            "$ref": "#/definitions/error"
        },
        "requestId": {
            "type": "string"
        },
    },
}


{
    "definitions": {
        "error": {
            "description": "Server response for error cases",
            "type": "object",
            "properties": {
                "number": {
                    "description": "HTTP Status Code Number",
                    "type": "integer"                   
                },
                "reason": {
                    "description": "Pre-defined string value that can be used to distinguish between errors that have the same code",
                    "type": "string"                    
                },
                "message": {
                    "description": "Message text describing the cause in more detail",
                    "type": "string"                    
                },
            }   
        },
    }
}

The README needs to be fleshed out:

• Brief introduction about the group and the spec
• Repo layout: where do files live. This was discussed in a recent meeting but should be documented in the README
• Style and/or code guidelines. Links are good enough.
• Contribution guidelines: any instructions on how to contribute and who is allowed to contribute (e.g., members), and CLA requirements, etc.
  • It might be a good idea to have a separate CONTRIBUTORS.md file with a list of folks who have and can contribute. It might make lief easier on the editors.
• Tools used. E.g., a link to Respec

interface Zone {
                attribute ZonePosition[] value;
    readonly    attribute Zone           driver;
    boolean equals (Zone zone);
    boolean contains (Zone zone);
};

interface Zone uses Zone itself inside the definition.
To think straight forward, constructor of Zone need to construct another Zone inside and it is recursive. I suppose this is problematic.
To avoid this recursion, one idea is to use getDriverPosition() method.

But another thing I think is, if we need driver position inside Zone definition or not.
It looks we can get driver position from interface steeringwheelConfigutation.
So I guess it would be no problem to remove driver position from Zone definition.

interface Zone {
                attribute ZonePosition[] value;
    boolean equals (Zone zone);
    boolean contains (Zone zone);
};

Through the Web application running on IVI or user’s mobile device, user can access the vehicle data defined in http://www.w3.org/2014/automotive/data_spec.html. Before that, it is necessary to discover which vehicle data interfaces are accessible to the Web application. This would be essential if the access control policy is implemented, since the accessible vehicle data interfaces may vary from application to application.

One suggested Discovery API design is as follows:

enum APITypeEnum {
"FuelConfiguration",
"Identification",
"SizeConfiguration",
"SteeringWheelConfiguration",
"TransmissionConfiguration",
"WheelConfiguration",
"Acceleration"
}; //This is just an example. We can add more according to the definition in data_spec

[NoInterfaceObject]
interface AvailableAPIs : VehicleCommonDataType {
readonly attribute unsigned short? count;
readonly attribute APITypeEnum[]? APIType;
};

APIType of type array of APITypeEnum, readonly , nullable
must return type of API available to access. If the vehicle provides multiple APIs, APIType returns an array of API types.

count of type unsigned short, readonly , nullable
must return total number of APIs available to access

The units of the vehicle speed vary within the spec. The average speed from the trip clock, the top speed limit and the cruise control speed are in kilometers per hour whereas the vehicle and wheel speeds are given as meters per hour.

I can see why it has been done this way for usability, but I feel consistency may be beneficial. This then gives an argument for the use of SI units. I think this is a point that has been debated before, although regardless of whether SI units or not I would argue units should be consistent for the same measurements.

6.2.1 Attributes
speed of type unsigned short, readonly
must return vehicle speed (Unit: meters per hour)

6.3.1 Attributes
speed of type unsigned short, readonly
must return wheel speed (Unit: meters per hour)

6.9.1 Attributes
averageSpeed of type unsigned short, readonly , nullable
must return average speed based on trip meter (Unit: kilometers per hour)

6.11.1 Attributes
speed of type unsigned short, readonly
must return target Cruise Control speed in kilometers per hour (Unit: kilometers per hour)

9.5.1 Attributes
speed of type unsigned short, readonly
must return vehicle top speed limit (Unit: kilometers per hour)

A couple of points on the Fuel Configuration Interface (5.4):

• Fuel Type Array - I agree that this need to be an array, but we may also have to consider refuelPosition as an array as well, such as in the case of plug-in hybrids which will have both a refuelPosition for electricity and a petrol/diesel
• FuelTypeEnum - There are two commercially available hydrogen fuel cell cars on the market (Hyundai Tucson FCEV and the Toyota Mirai). The Toyota is being released in the US in October. It may be worth distinguishing between battery electric vehicles (BEVs) and hydrogen fuel cell electric vehicles (FCEVs).

I'd like to get the conversation started on using a service-based approach.

• The API to get/subscribe to the data will be lower-level and simple
• The data will be returned as JSON or JSON-LD but will otherwise remain as defined in the current data specification.

The idea is to use WebSockets) or an API that resembles WebSockets and, if needed, something that resembles REST. (A REST-ish approach might be required for one time "get" requests or "set" commands).

• W3C WebSocket Spec
• Mozilla Docs for WebSocket

For the WebSocket approach the idea would be to use a constructor to start listening to a signal using a URI. I'm not sure what the protocol and host should be so I will leave them off for the time being. The example below does not diverge from the WebSocket spec.

Update (2016-03-03): This approach would require many sockets for many different signals, which might be a problem.

var doorSocket = new Vehicle.Socket('/door/front/left');
doorSocket.onopen = function() {
  console.log('Front left door socket is open');
};
doorSocket.onmessage = function(message) {
  // message.data is the data requested and would be a JSON or JSON-LD
  console.log(message.data);
  console.log(message.origin);
  console.log(message.source);
  console.log(message.lastEventId);
  console.log(message.ports);
};
doorSocket.onclose = function(event) {
  console.log(event.code);
};
doorSocket.close();

There is also a send() method but I think we would use that approach for setting values.

If we want to grab data just once or set data, then the WebSocket approach may not be ideal. The old XMLHTTPRequest approach is also antiquated. I am not aware of any other spec for APIs make REST calls in the browser but if there is one we should follow it. In the meantime, here's a thought on what we can do.

var doorClient = new Vehicle.Client();
doorClient.get('/door/front/left')
  .then(function(result) {})
  .catch(function(error) {});
doorClient.post('/door/front/left', {'state': 'lock'})
  .then(function(result) {})
  .catch(function(error) {});

We can either use promises or callbacks. In the above example, I used promises.

The details still need to be worked out but I think this is a good starting point for a discussion.

8.2 Language Configuration Interface
http://www.w3.org/TR/2015/WD-vehicle-data-20150616/#attributes-49
BCP47 should be used to identify languages instead of ISO 639-1.
See https://tools.ietf.org/html/bcp47
One of the problems with using ISO 639-1 2 letter codes is that it does not adequately address the handling of Chinese. For example, in ISO 639-1 Chinese is represented as zh. This code cannot indicate whether the writing system is Simplified Chinese or Traditional Chinese. The BCP47 standard clearly indicates which writing system is in use. In this case if Simplified Chinese was being used the code would be zh-Hans and for Traditional Chinese it would be zh-Hant.

10 Vehicle Interface Error
http://www.w3.org/TR/2015/WD-vehicle-information-api-20150616/#idl-def-VehicleInterfaceError
Which languages may be used in the error message? If languages other than English are permitted then you may want to add an attribute to the interface to clearly indicate the language of the message.
You may want to consider modifying this interface to permit an array of messages tagged with their language so that the interface could return messages in more than one language. This would enable an end-user to select from a list of possible languages to see messages in.
If you add a language tag then you should follow the BCP47 recommendations https://tools.ietf.org/html/bcp47
Do not use the ISO639-1 2 letter codes for languages.

This is the endpoint proposal for 6. Running Status Interfaces. Any comment or question is more than welcome.

6.2 VehicleSpeed Interface

vehicle.speed.status

6.3 WheelSpeed Interface

vehicle.wheelspeed.status

6.4 EngineSpeed Interface

vehicle.enginespeed.status

6.5 VehiclePowerModeType Interface

vehicle.powermodetype.status

6.6 PowertrainTorque Interface

vehicle.powertraintorque.status

6.7 AcceleratorPedalPosition Interface

vehicle.accelpedalposition.status

6.8 ThrottlePosition Interface

vehicle.throttleposition.status

6.9 Trip Interface

vehicle.tripmeters.distance
vehicle.tripmeters.averagespeed
vehicle.tripmeters.fuelconsumption

6.10 Transmission Interface

vehicle.transmission.gear
vehicle.transmission.mode

6.11 CruiseControlStatus Interface

vehicle.cruisecontrol.status
vehicle.cruisecontrol.speed

6.12 LightStatus Interface

vehicle.lightstatus.head
vehicle.lightstatus.righturn
vehicle.lightstatus.leftturn
vehicle.lightstatus.brake
vehicle.lightstatus.fog
vehicle.lightstatus.hazard
vehicle.lightstatus.parking
vehicle.lightstatus.highbeam
vehicle.lightstatus.autoheadlights
vehicle.lightstatus.dynamichighbeam

Q: what is a meaning of "zone" attribute in LightStatus interface?

6.13 InteriorLightStatus Interface

vehicle.interiorlightstatus.zone

6.14 Horn Interface

vehicle.horn.status

6.15 Chime Interface

vehicle.chime.status

6.16 Fuel Interface

vehicle.fuel.level
vehicle.fuel.range
vehicle.fuel.instantconsumption
vehicle.fuel.averageconsumption
vehicle.fuel.fuelconsumedsincerestart
vehicle.fuel.timesincerestart

6.17 EngineOil Interface

vehicle.engineoil.level
vehicle.engineoil.liferemaining
vehicle.engineoil.temperature
vehicle.engineoil.pressure
vehicle.engineoil.change

6.18 Acceleration Interface

vehicle.acceleration.x
vehicle.acceleration.y
vehicle.acceleration.z

6.19 EngineCoolant Interface

vehicle.enginecoolant.level
vehicle.enginecoolant.temperature

6.20 SteeringWheel Interface

vehicle.steeringwheel.angle

6.21 WheelTick Interface

vehicle.wheeltick.zone

6.22 IgnitionTime Interface

vehicle.ignition.offtime
vehicle.ignition.ontime

6.23 Gyro Interface

vehicle.gyro.yawrate
vehicle.gyro.pitchrate
vehicle.gyro.rollrate

6.24 BrakeOperation Interface

vehicle.brake.pedaldepressed

6.25 ButtonEvent Interface

vehicle.button.event

6.26 DrivingStatus Interface

vehicle.driving.status

6.27 NightMode Interface

vehicle.nightmode.status

6.28 StartStopMode Interface

vehicle.startstopmode.active
vehicle.startstopmode.enabled

5.5, 5.7 information information – repeated word. Multiple times.
5.7.1 Extra commas where readOnly may have been (copy and paste error)
6.17.1 Missing a couple of close brackets. "(Unit: percentage, 0%: empty, 100%: full"
6.25.2 ‘Simultanious’ spelling error
7 ‘(e.g., engine)’ extra comma
7.3.1 Add percentage symbols
7.3 7.5 Apostrophe “maintenance state of a vehicle’s ______” a few occurrences
8.4 mirrorPan “%0” instead of “0%”

Frequently throughout the document JavaScript coding guidelines are not used. For instance, curly braces are found both at the end of the line and also on it's own line.

There is no current JS style guidelines that uses curly braces on a new line.

Options for coding guidelines:

• https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
• http://javascript.crockford.com/code.html
• JavaScript Standard Style https://github.com/feross/standard
  • This one is new and maybe controversial because it says not to use semicolons.

The only change I would make it for 2-space indentation instead of 4. Those extra spaces might push code samples out of view, which is annoying to say the least.

http://www.w3.org/2014/automotive/vehicle_spec.html#vehicleinterfacecallback-callback
callback VehicleInterfaceCallback = void(object value); ();

There is an unneeded semicolon after the first right parenthesis

In Vehicle Spec. section 7, suggest augmenting the existing ZonePosition values which currently define longitudinal (front/back) and horizontal (left/right) position with additional values that define vertical position in vehicle.

Suggested new values would be:

top: top layer of vehicle in vertical-axis
middle: middle layer of vehicle in vertical-axis
bottom: bottom layer of vehicle in vertical-axis

This would allow us to distinguish the ZonePosition for cameras fitted 'top', 'rear', 'centre' from one fitted 'bottom', 'rear', 'centre'

Also suggest following the same naming system used by CSS for vertical and horizontal alignment.

So in the vertical-axis : top, middle, bottom
In the horizontal-axis : left, center, right
In the longitudinal-axis: front, central, rear

Suggested enumeration Descriptions would then be:

top: top layer of vehicle in vertical-axis
middle: middle layer of vehicle in vertical-axis
bottom: bottom layer of vehicle in vertical-axis
left: left area of vehicle in horizontal-axis
center: center area of vehicle in horizontal-axis
right: right area of vehicle in horizontal-axis
front: front of vehicle in longitudinal-axis
central: central area of vehicle in longitudinal-axis
rear: rear area of vehicle in longitudinal axis

Some example Zone values could then be:

zone.ZonePosition[0] = 'left' // denoting the whole left plane of the vehicle
or
zone.ZonePosition[0] = 'left', 'front' // denoting the left, front area of the vehicle
or
zone.ZonePosition[0] = 'left', 'front', 'bottom' // denoting the left, front, bottom of the vehicle
or
zone.ZonePosition[0] = 'front', 'left' // denoting the front, left and
zone.ZonePosition[1] = 'back', 'right' // back, right areas of the vehicle
or
zone.ZonePosition[0] = 'front','top','center' // denoting front, top, center and
zone.ZonePosition[1] = 'back', 'bottom', center' // back, bottom, center areas of the vehicle

Combined with the recent proposal to ensure that Zone contains an array of ZonePositions, suggest that this would enable the existing approach to cover all three physical axis in the car

On approximately line 101 a for-in loop is used incorrectly. It should be a standard for loop or use the forEach function on Array.

        var zones = vehicle.climateControl.zones;
        for(var i in zones)
        {
           if(i.equals(zone.driver))
           {
              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");
             });
           }
        }

for-in is for iterating over properties in an object

In new charter,
https://w3c.github.io/automotive/charter-2016/

"2.1 Normative Specifications" part, the word "Vehicle Information Access API"
is used but this is not meaning current Vehicle Information Access API
https://w3c.github.io/automotive/vehicle_data/vehicle_spec.html
and this is misleading.

So the name "Vehicle Information Access API" should be changed
to other name.

Determine the format to use for specifying the Vehicle Information Access API:

• WebSocket protocol
• HTTP API routes

interface Zone {
    attribute ZonePosition[] value;
    readonly    attribute Zone        driver;
    boolean equals (Zone zone);
    boolean contains (Zone zone);
};

It looks value can hold many items.
But also it looks zone's usage is just to specify X dimensional value(right, center, left) and Y dimensional value(front, middle, rear).
If so, it is enough by setting only two values and feel there is too much freedom in current value.

Is this for future expandability ? (I just like to know the reason.)

I think that w3c/automotive-bg#49 raises potentially valid concerns about the the API design. The API technically achieves the requirements of the spec but does it fit common (or future) JavaScript usage patterns?

It was suggested that the spec be reviewed by [email protected]

Also, as mentioned in the IRC: http://darobin.github.io/api-design-cookbook/#using-attributes

Finally, why use an interface over a dictionary for the data specification? (Maybe this is a separate issue).

In http://www.w3.org/2014/automotive/vehicle_spec.html#zone-interface enum type ZonePosition is defined.

enum ZonePosition {
"front",
"middle",
"right",
"left",
"rear",
"center"
};

But it is never used through the spec.

For battery status in 7.8, some additional data elements that could be considered

• battery purpose (starting, hybrid-traction, electric-traction, other)
• cold cranking amps rating
• battery location (under hood, under seat, trunk, other)
• battery temperature
• battery type (flooded lead-acid, enhanced flooded lead-acid, AGM, AGM/Spiral, lithium, capacitor, other)
• cranking voltage
• charging system voltage

The WiperStatus interface offers the speed interval of the wipers 0 - 10:

10.4.1 Attributes
wiperSpeed of type unsigned byte, readonly
must return current speed interval of wiping windshield (0: off, 1: Slowest, 10: Fastest )

The WiperSetting interface offers the speed setting of the wipers off to fastest and auto mode:

10.5.1 Attributes
wiperControl of type WiperControl,
must return current setting of the front wiper controller. It can be used to send user's request for changing setting.

I would suggest a boolean value for auto mode instead of holding it within the WiperControl enum and then just a single indication of WiperSpeed. It can be used to send user's request for changing setting - if this is the reason for the separate WiperSetting interface then WiperSetting and the WiperStatus should adhere to the same enum.

There are a couple of contentious issues in the current charter:

• Where would we like to place the dependence on the VSS? On both specifications, one or elsewhere in the specification?
• Is a VSS snapshot an other deliverable?
• In the client spec definition we claim it can be implemented without adhering to the server specification. Is this appropriate?
• Do we want to define the Vehicle Signal Client Spec as the Vehicle Signal Client API?

My opinion is that:

• the dependencies should be on both specs
• the snapshot is not a w3c deliverable
• the client spec should not be suggested for usage without the server spec
• Client spec should be the Vehicle Signal Client API

Within the discussion for #72, @tobie and @peterMelco suggest to remove "interface" suffix from the interface's name.

Vehicle Information Access API spec has a below interface list for this issue.

• VehicleInterface Interface
• VehicleConfigurationInterface Interface
• VehicleSignalInterface Interface

After delete the suffix, those name might be replaced with as below.

• Vehicle Interface
• VehicleConfiguration Interface
• VehicleSignal Interface

It makes sense to me.

@acrofts84 @aShinjiroUrata @QingAn, @paulboyes , What do you think?

A quick question as this is an issue I bumped into while working on the generic sensor spec.

Most cars have four proximity sensors on the rear bumper.

How would you target one of them given the current Zone proposal?

From vehicle_spec.html : Abstract, 12
From data_spec.html : 6,6.26,6.27,12.1.2,12.1.3

A specification should not contain etc...either we need to define etc or we need to remove.

To reduce implementation dependency, something like following could be added:

subscribe(optional period) , where period is specified in ms.
Implementor MUST invoke callback function f when the data value v is changed/updated. If period is used, then wait period ms until invoke f.

Ex1:
subscribing to the vehicle speed : subscribe(100)
// "real time" change, frequent
Ex2:
subscribing to the left door being open/closed: subscribe()
// event driven change, not so frequent

For Diagnostic interface in 7.10, some additional data elements that could be considered

• diagnostic trouble codes - array
  • including 213 EPA mandated codes and OEM-specific, as available

Returning an int allows for unsubscribe forgeries. Let's say my app has an ad network and a malicious ad gets onto the network, that ad could potentially brute force unsubscribe.

A better solution would be to return an object. Even better would be for that object to have the unsubscribe call itself.

As discussed in the meeting on Feb. 16

• Discussion on how the service (websocket/rest-ish) approach works with strawman examples.
• Determine the architecture and diagram it. (Look at Web of Things).
• Convert WebIDL in the data spec to JSON or JSON-LD.
• Validate that a higher level API can be implemented using the newly proposed low-level API.
• Close #37
• Close #72

In data spec, http://www.w3.org/2014/automotive/data_spec.html
for the multiple kinds of attributes defined in different interfaces, some attributes are defined as nullable, like fuelType, which is nullable, in FuelConfiguration Interface (http://www.w3.org/2014/automotive/data_spec.html#idl-def-FuelConfiguration), and VehiclePowerMode, which is non-nullable, in VehiclePowerModeType Interface (http://www.w3.org/2014/automotive/data_spec.html#idl-def-VehiclePowerModeType)

We need a clear explanation why such attributes are set in this way.

Here is a list of the current actions on the Vehicle Signal Server Spec, from our review in Lisbon. These have been copied from my notes, so feel free to ask for any clarification.

• ACTION – Table of figures to join table of contents. It looks a bit out of place where it currently is
• ACTION – TTL units – milliseconds
• ACTION – Message structure. Get rid of void and DOMString to make it JavaScript, like onmessage. Vehicle.onmessage, not WebSocket.onmessage
• ACTION – Example 3, make it obvious that it is one of the three, not all three
• ACTION – be explicit that server side filtering is for nodes only, not for branches
• ACTION – move getVSS before the other actions. Authorize, getVSS, then get, set, subscribe, unsubscribe
• ACTION – Add a Subscription notification error message for when the server is overloaded. It returns the following information (timestamp, subId, reqId, error, filter)
• ACTION – the wildcard example needs to be improved. Body.doors.*.something. Result value doesn’t include left, right, etc.
• ACTION – Add unsubscribeAll action instead of using subscriptionId: 0 to avoid use of magic number
• ACTION – getVSS method should be hyperlink (just under Fig 2)
• ACTION - Shorten the abstract to give high level overview, integrate any extra info into the introduction
• ACTION – OCF JSON Schema – use this structure to make the objects consistent. Wonsuk to share
• ACTION – DOMStrings vs strings ?
• ACTION – VSS is minor version, VSSS is major version wvss1.0
• ACTION – unsubscribe all when there are no subscriptions
• ACTION – other data formats may be added in the future. Add a github issue for discussion. CSV, BSON, YAML etc. JSON will be current format
• ACTION – If auth fails during subscription, we need to send a subscription notification error response. Does the subscription continue, or do we need to resubscribe? It should just continue – as discussed.
• ACTION – comments around JSON in examples
• ACTION - wwwivi add note to name server on the LAN has to assign an address
• ACTION – Set engine.rpm cannot be set because its read-only
• ACTION – after 10 (or N) number of requests the authentication will be denied to avoid dictionary attacks. Will return a denied after this. (User / device token error mechanism)
• ACTION – more generic hostname, not just for IVI. Discuss with WoT. Do we want this to be generic? With a different sub-protocol.
• ACTION – add get VSS to example with AUTH section
• ACTION – add getVSS request and receive notes.
• ACTION – potentially add editor’s notes for open issues, such as branches for filters. For where we want input from outside
• ACTION – Strip out some content in the Initialisation section
• ACTION – explicitly state that the tree unsubscribes from an entire subscription, you cannot just do just a subset
• ACTION – add a state diagram for all of the state changes depending on messages sent – get Visio going! Particularly showing auth, and error messages when there are too many requests.
• Provide comment about application level tokens, and protection against replays/spoofing of tokens

Reconsidering the following:

• ACTION – private path error should be a forbidden (private_path instead of not found)
  • Having looked at this further, I think that it should remain as not_found, as knowing that a signal existed could be sensitive data in itself. It is better to err on the side of caution here.
• ACTION – add timestamps to request objects so that only one response is received, the latest. This can be abstracted by the client spec.
  • The adds a lot of overhead for the server each time a request is made. It would have to check that another thread is not dealing with the same request each time it tries to satisfy a request. This means it would increase demand on the server rather than reduce it. The advantage is that the client only receives the data once, but really it should ask for it only once.
  • Agreed on call 20/6/17. 429 error covers this case

1. Inconsistent data type
   • Inconsistent data type for levels
     7.6.1 WasherFluid Interface
     http://www.w3.org/TR/2015/WD-vehicle-data-20150616/#attributes-43
     Across the specification levels use the octet data type while in this case the level uses an unsigned short. The same data type should be used across the specification.
     For example, in 6.19 EngineCoolant http://www.w3.org/TR/2015/WD-vehicle-data-20150616/#idl-def-EngineCoolant The level is an octet.
   • Inconsistent data type for temperature
     10.2.1 Temperature Interface
     http://www.w3.org/TR/2015/WD-vehicle-data-20150616/#attributes-66
     In this interface temperatures use the float data type, while other interfaces in the specification use the long data type. Does this interface specifically require the use of float or should this be made to be consistent with the other uses of temperature?
     For example, in 6.17 EngineOil Interface
     http://www.w3.org/TR/2015/WD-vehicle-data-20150616/#attributes-25 The temperature is a long
     For example, in 6.19.1 Engine Coolant
     http://www.w3.org/TR/2015/WD-vehicle-data-20150616/#attributes-27 The temperature is a short while in section 6.17.1 temperature is a long.
     In section 7.3 TransmissionOil Interface
     http://www.w3.org/TR/2015/WD-vehicle-data-20150616/#attributes-40 The temperature is a byte.
   • Inconsistent use of data type for tilts and pans
     8.4 Mirror Interface
     http://www.w3.org/TR/2015/WD-vehicle-data-20150616/#idl-def-Mirror
     Throughout the specification tilts and pans use different data types. In this particular case the data type is a byte while in other sections tilt is an octet or an unsigned short.
     See section 10.6 Sunroof Interface http://www.w3.org/TR/2015/WD-vehicle-data-20150616/#idl-def-Sunroof
     See section 5.7 Steering Wheel Configuration http://www.w3.org/TR/2015/WD-vehicle-data-20150616/#idl-def-SteeringWheelConfiguration
2. Inconsistent data unit
   • Should units of speed vary in the specification
     6.2 Vehicle Speed Interface
     http://www.w3.org/TR/2015/WD-vehicle-data-20150616/#idl-def-VehicleSpeed
     In the specification the definition of speed is meters per hour in some interfaces and kilometers per hour in other interfaces.
     See 6.9 Trip Interface http://www.w3.org/TR/2015/WD-vehicle-data-20150616/#idl-def-Trip
     Should the definition of speed be consistent across all interfaces?