Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collaboration W3C - GENIVI #84

Closed
magnusfeuer opened this issue Apr 4, 2016 · 3 comments
Closed

Collaboration W3C - GENIVI #84

magnusfeuer opened this issue Apr 4, 2016 · 3 comments

Comments

@magnusfeuer
Copy link

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

@peterMelco
Copy link
Contributor

Here's my opinion:

Is it a good idea to integrate the GENIVI and W3C signal definitions?

I would think that it would be a great benifit to have GENIVI influencing the W3C data specifications. The data spec should be better prepared to adress specific use cases. Also, from a developers/implementors point of view its better to have a consistent way of adressing the vehicle signal data.

If the answer is "yes", which of the two adoption strategies above should we go with?

If we look at the current W3C spec we are for example heavily depending on a Zone interface which is a bit different from the VSS concept. I think that we should have the goal that we should have a common way defining the data. There are probably more cases like this which we need to review.

Ex:

//W3C
enum ZonePosition {
    "front",
    "center",
    "rear",
    "left",
    "middle",
    "right",
    "top",
    "central",
    "bottom"
};

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

Zone frontleftzone = {front,left,top,central,bottom}
...
aDoor.status = "open"
aDoor.lock = true
aDoor.zone = frontleftzone
...
//VSS
adoor.1.right.locked=true;

So, in my opinion, in order to get a coherent and consistent data spec we could:

  1. Review use cases to see if we are able to change and adapt specifications to make an attractive "merger" of VSS and W3C. I believe that we in the W3C WG could have missed some important use cases where we actually would like to have a higher resolution also for the "web" developers.
    We should strive for a coherent and consistent data spec and try to avoid introducing redundancy while merging.

So, a question for the WG: How should we proceed with the JSON transition of our current spec ? Should we translate the current spec into JSON as we see it and then try to merge with VSS ? or should we coordinate with GENIVI now and make the JSON "spec". Something for the F2F in Paris ?

@as2902b
Copy link

as2902b commented Apr 6, 2016

Hello Magnus and Peter,
I would like to add a few thoughts here, based on my work in the Open Connectivity Foundation.

I spent sometime over the past few months, looking at all the contemporary efforts by different car makers and others, trying to provide an API for the vehicle data and dashboard control (SmartDeviceLink, MirrorLink, Droid Auto, Carplay and the GM Developer Program). As a developer, it puts me in a spot of bother to make my app support all these vehicle platforms as part of my vehicle enabled 'app'.

As part of OCF automotive spec definition, we have been closely working with Magnus, to make sure the OCF automotive spec aligns with VSS. Soohong Daniel Park from Samsung, who is also one of the W3C Working Group chair (https://www.w3.org/2008/WebVideo/Annotations/) is leading this activity. Both of us will be attending the Genivi AMM in Paris this April. So we are open to discussions regarding this.

OCF also follows a JSON based schema which can be accessed via http://www.oneiota.org/. It would be nice to see W3C and VSS unify under a single json spec so that all our efforts are aligned.

@rstreif
Copy link
Contributor

rstreif commented Mar 14, 2017

Yes, the Genivi VSS has been accepted and made part of the new and reworked specification. The First Public Working Draft (FPWD) at the Genivi AMM in Fall 2016.

@rstreif rstreif closed this as completed Mar 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants