-
Notifications
You must be signed in to change notification settings - Fork 68
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
Comments
Here's my opinion:
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 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:
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 ? |
Hello Magnus and Peter, 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. |
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. |
[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.
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
...
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.
Any input on this would be much appreciated.
Sincerely,
/Magnus F.
mfeuer1 a t jaguarlandrover.com
Expert Group Lead - Remote Vehicle Interaction
GENIVI.
The text was updated successfully, but these errors were encountered: