I assume it should be called DriverPosition.

Furthermore, I am not 100% sure that I understand this variable correctly? Should it be interpreted as seat number from left?

https://github.com/GENIVI/vehicle_signal_specification/blob/222bbc6d1900e2c82dc15138da2266dcdae3c53e/vss_rel_1.0.fidl#L306

In general the selection of datatype is not always easy to understand, for example temperature (celsius) can be found with int8, int16 and float. I know there might be historical reasons in some cases, or that datatypes form other standards have been used, but that is difficult to know as a reviewer. I assume that altitude is defined as ground level

Maybe there have been

https://github.com/GENIVI/vehicle_signal_specification/blob/222bbc6d1900e2c82dc15138da2266dcdae3c53e/vss_rel_1.0.fidl#L2859

JLR may have a need to define a set of command signals to modify the behavior of the vehicle.

One example would be Signal.Cabin.Door.Row1.Right.Window.Position, which reports the current window position.

This signal would be paired with with Signal.Cabin.Door.Row1.Right.Window.SetPosition, which is picked up by the door/window controller to start rolling the window up and down. During the operation the [...].Window.Position would be continuously published with new values.

With this in mind I have a few questions for the VSS stakeholders:

1. Is this a good idea, or should we define commands via some other, non-VSS specification?

2. Assuming that the idea is not garbage, do we want to group all commands in their own top-level branch or closer to the leaf?
   
   Command.Cabin.Door.Row1.Right.Window.SetPosition
   vs.
   Signal.Cabin.Door.Row1.Right.Window.SetPosition

3. Are there other things to take into consideration?

/Magnus F.

The current VSS contains about 1100 signals in total, but only about 300 if we remove the position-related redundancy. The data model would also benefit from an udate of how positions are described, to make a clearer difference between what branches physically represent (composents, domains) and there position branch (Front, Left, Row1...).

Currently we have for instance
Signal.Chassis.Axle.Row1.Wheel.Left.Tire.Pressure
to describe the tire pressure on the front left tire.
The metadata of this signal, and of its hosting branch is the same as in
Signal.Chassis.Axle.Row1.Wheel.Right.Tire.Pressure, Signal.Chassis.Axle.Row2.Wheel.Left.Tire.Pressure, Signal.Chassis.Axle.Row2.Wheel.Right.Tire.Pressure

In addition, there is no fix rule about position modeling, and in the same example, there is the branch Wheel between 2 position branches.

Proposal
We could dedicate a branch type to positions, and add a dedicated symbol (for instance "-") in a similar way as URI parameters. So for instace the previous example could become:
Signal.Chassis.Axle-Row1.Wheel-Left.Tire.Pressure
Where the branches Chassis and Wheel are parametrized with their position.
Or even
Signal.Chassis.Axle.Wheel.Tire.Pressure-Row1.Left
Where the signal is parametrized with the position.

This could be a way of not only remove redundant concepts, but also allow access on multiple positions at once with a wildcard, as proposed in #48

Right now we have different notations for enums. Some examples:

Underscore Vehicle.Drivetrain.FuelSystem.HybridType: unknown / not_applicable / stop_start / belt_ISG / CIMG / PHEV

Space Vehicle.Drivetrain.Transmission.DriveType: unknown / forward wheel drive / rear wheel drive / all wheel drive

Camel case Vehicle.Cabin.RearShade.Switch: Inactive / Close / Open / OneShotClose / OneShotOpen

I think it would make sense to agree on a notation, so that it's easier and more intuitive for the developer. I'd go for lower camel case, as we have many lower case enums already. Opinions?

Hi,

Is there any specification describing the error handling and relaying of error information back to the client?

e.g. as per the vehicle signal specification, the Cabin.HVAC.IsFrontDefrosterActive is a boolean. And if the client sends the data as

{
    "action": "set",
    "path": "Cabin.HVAC.IsFrontDefrosterActive",
    "value": 1
}

In this case the value is an integer (1) while the expected value is boolean. So the server should respond with an error back to the client.

Is there any documentation which states this?

At various meetings the W3C Automotive Group has discussed the possibility in Gen2 of using JSON-LD instead of JSON for a variety of reasons, not the least for easier integration with WoT Thing Descriptions. JSON-LD is generally considered a suitable replacement that won't confuse web developers use to regular JSON.

This is a topic listed on our agenda list, serving as a partial roadmap.

https://www.w3.org/auto/wg/wiki/Agenda_Planning

Happy to add as an agenda after initial discussion here.

The signal Cabin.HVAC.isAirConditioningActive should be renamed to Cabin.HVAC.IsAirConditioningActive to be consistent with other names.

The signal is having small case letter i instead of capital letter I

The spec file Signal/Cabin/AllWindows.vspec is never included.

As a result, the only window signals available are the ones defined outside this file.

Would you consider adopting YAML, rather than JSON, as the default format for the structured data? In general I think humans find yaml easier to read, and computers are happy with either.

Also, would it make sense to consider establishing a schema for this early on, so that the schema can be used to validate actual files (eg http://json-schema.org)? And versioning of the schema?

@rstreif What's the branch policy?

develop is way ahead of master, which has not been updated since 2016.
Not sure what master is for now. I'd suggest simply merging develop into master (it's a fast forward) and then delete develop and keep master. OK?

The Signal/Vehicle.vspec contains information which would be better placed in the Attribute/Vehicle.vspec. These properties tend to be quoted as attributes of new cars, and whilst some of them could change over time I do not expect this information to be available on an in-vehicle network.

• RoofLoad - may change due to tyres, but unlikely to be measured
• accelerationTime - will change, but needs specific circumstances to be measured
• cargoVolume - may change due to seat configurations, but unlikely to be published on a vehicle network

I would also suggest capitalising the following to be consistent with other signals/attributes:

• accelerationTime -> AccelerationTime
• cargoVolume -> CargoVolume
• emissionsCO2 -> EmissionsCO2

Today, vspec2c.py generates a source and header file that encodes the signal spec. These files embeds both static code, that doesn't change regardless of the signal spec, and a dynamic part that is generated from the signal specification.

The static part of both files need to be move to their own .c and .h files that are checked in as regular files in github, leaving the app programs to include the dynamically generated files.

This lets us build a vss library that is independent of the spec file, pushing the linking of the dynamically generated files and the vss library to the application.

I think the VSS root directory README needs a refactoring to more clearly explain what this repo contains, which in my view is three separate, but related parts:

• A data model specification,
• An instance of this data model ,
• Tools to transform theYAML based instance into other formats.
  The README should have a layout presenting each of these parts.
  Further, I think the specification part should reside in a separate document (mirrored in the README) to that it can easily be handled separately.

Hi @rstreif,

could you let me know, which commit you want to use for branching off VSS 1.0 so that we could prepare that one?

Cheers,
Daniel

Hi,
It's great that JLR is leading this work, but would you consider downgrading the copyright claim?

Alternatively, if JLR intends to assert copyright, maybe guidelines for third-party contributions need to be stated?

Hi,

I have noticed 2 branches called Steering Wheel:

• Attribute.Cabin.SteeringWheel: https://github.com/GENIVI/vehicle_signal_specification/blob/develop/spec/Attribute/Cabin.vspec which contains the attrobute of the position of the steering wheel
• Signal.Chassis.SteeringWheel: https://github.com/GENIVI/vehicle_signal_specification/blob/develop/spec/Signal/Chassis/Chassis.vspec which contains the angle/tilt/extension of the steering wheel.

I believe these 2 branches should be merged as they represent the same part of the vehicle, and it should be under the "Cabin" branch.

In order for data to be useful, knowing how accurate it is can be helpful. For OEM in-vehicle purposes they may be satisfied with eg engine temperature sensor being accurate within +/- 5C. Anyone who wants to make use of that data would appreciate knowing with what degree of precision it is being provided.

This could be represented on the leaf node itself, if known. We expect in some cases implementations may not know (as parts get swapped out within year for a given model sometimes) or otherwise will not provide. In those cases the attribute could either fall off or be null.

Related issues:
#41
#44

Hi, I was under the impression, that the different formats should contain the same info, however at least for .csv and .json that does not seem to be true

$ cat vss_rel_1.0.json | grep -A 5 ConsumptionSinceStart
              "ConsumptionSinceStart": {
                "description": "Fuel amount consumed since start in milliliters.", 
                "type": "UInt32", 
                "id": 82, 
                "unit": "ml"
              }, 

$ cat vss_rel_1.0.csv | grep ConsumptionSinceStart
Signal.Drivetrain.FuelSystem.ConsumptionSinceStart,"81","UInt32","ml","","","Fuel amount consumed since start in milliliters.",""

One is id82, but the other is id81. Is this intended (why?), or a bug?

Under the root node Vehicle there is now, besides the Media node and the Private node, also also all the nodes like DriveTrain, Cabin, Body, ADAS, Chassis, and OBD.
I think these should be pushed one level down, under a branch node that may have the name Car (from VIWI), or something else. The nodes mentioned above belong to the same logical domain, and should reside under a domain name node for these. It will be more comparable to the Media domain node, and further new domain nodes that might be added later.

Change to m/s^2 ??

The signal IsRearDefrosterActice has a typo and should be IsRearDefrosterActive

Can you please confirm my concern, For temperature the unit is mentioned as Celsius, say example, if UI display expects the temperature to be displayed in Fahrenheit, but the respective vehicle data is in Celsius. The conversion can happen in native code before transmitting to browser (or) in the browser itself.

Is there any W3C standard such that always the temperature unit is realized as Celsius.Means the data transfer from native software to browser should always happen in Celsius?

Can this be used with an OBD2 plug to pull info from a vehicle?

The following VSS IDs are duplicate (on master)

1103
Attribute.Vehicle.VehicleIdentification.ACRISSCode: 1103
Signal.OBD.FuelRate: 1103

1178
Signal.OBD.O2WR.Sensor8.Current: 1178
Vehicle.VehicleIdentification.VIN: 1178

2300
OBD.FuelRate: 2300
VSS-Root.Vehicle.VehicleIdentification.VIN: 2300

3422
VSS-Root.OBD.FuelRate: 3422
Vehicle.VehicleIdentification.vehicleinteriorColor: 3422

I will fix this by deleting one of the duplicates in each instance and re-run the build system to assign them new IDs.

Most cars, at least in Europe, use millimeters to represent tirewidth, e.g. 195/60-R15, typically with 10 mm increments, e.g. 185,195, 205, ... So is Inch as unit requested by OEMs, especially if it does not support fractions of inches?

https://github.com/GENIVI/vehicle_signal_specification/blob/222bbc6d1900e2c82dc15138da2266dcdae3c53e/vss_rel_1.0.fidl#L163

" client -> {
"action": "set",
"path": "Signal.Cabin.Door.*.IsLocked",
"value": [ {"Row1.Right.IsLocked": true },
{"Row1.Left.IsLocked": true },
{"Row2.Right.IsLocked": true },
{"Row2.Left.IsLocked": true } ],
"requestId": "5689"
}
o This could be quite a lot for example Seat. Row.Pos.heating would be about 20 entries. Some of these might even not exist and would need then additional error handling.

Maybe something like this

client -> {
"action": "set",
"path": "Signal.Cabin.Door",
"value": [ {"..IsLocked": true },
],

Few spelling to be corrected in the below topics.

ATTRIBUTE ENTRY - the "specifiation", that never changes

SIGNAL NAMING CONVENTION - the "reaview" mirror

ATTRIBUTES - data that can be specified when the "bspec" file is installed.

EXTENDING AND OVERRIDING SIGNALS - Fig 4. "Overidden" signals
vss_23.vspec and then "oveerriding" the

The Quoted item needs correction.

There seem not be a description on the Signal DB file format, which results in an error and that the id is assigned -1 :

NO SIGNAL DB FILE TO USE!

{

"Vehicle": {
"type": "branch",
"children": {
"VehicleConfiguration": {

Is there a need to support fraction of inches? At least for e.g. buses it is not uncommon with wheel sizes like 22.5" x 8.25". If needed one could consider a representation like "milli-Inches", e.g. "22500" for a 22.5" wheel

Is the standardisation organisation not called ETRTO (ETRO in current spec)
http://www.etrto.org/Home

https://github.com/GENIVI/vehicle_signal_specification/blob/222bbc6d1900e2c82dc15138da2266dcdae3c53e/vss_rel_1.0.fidl#L139

(or whatever unit you feel is reasonable)

https://github.com/GENIVI/vehicle_signal_specification/blob/222bbc6d1900e2c82dc15138da2266dcdae3c53e/vss_rel_1.0.fidl#L224

A modern vehicle is typically equipped with multiple sensors that produces streams of data, such as cameras, radars, and lidars. VSS is currently not able to support these sensors. I propose that VSS shall be extended with metadata that enables a client to find the streaming source, and initiate a streaming session. To enable this the “type” property is extended with a new enum value “stream”, and a new property containing the URL to the streaming server is added, “server-url”:. It needs to be investigated if the URL is sufficient information for a client to initiate a streaming session with at least the most common streaming protocols. If not, possibly one or more properties needs to be added to convey the needed information.
YAML example:
Camera.Rearview.Right:
type: stream
server-url: scheme://path-to-stream-server
description: Right rear view camera.

I commented on a previous issue (#1) but it was already closed. I would like to highlight what the last paragraph mentioned and request:

1. Set a single license for the whole project.
2. Clarify (e.g. in README) that contributions are to be made under that same license.
3. Clarify how contributors can make sure to certify their contribution's ownership and license. The normal convention is by the contributor keeping the copyright themselves and licensing it under the same license and clarifying this by referencing Developer Certificate of Origin -- alt link 1 with explanation -- alt link 2 on the first contribution. Thereafter a sign-off line on each commit.

Rationale:

Reading between the lines it seems you wanted to license code and docs differently. But it's not obvious to me why the YAML defined specification is considered a document (CC-BY) while Franca interface definitions are considered source code (MPL)? The data in this project are of the kind that we should expect everyone to want to freely transform and combine them in various ways. That is much easier with a single license - no worries about license incompatibility or annotating the end result incorrectly.

Current situation:
Right now signals and attributes are modeled in the tree structure itself. Types can be either branch or data types. Some issues resolve from that modeling choice:

• redundancy of tree structure in both branches
• logically combined leafs are separated
• graph type and data type mixed
• private branch doesn't effect attribute tree
• property in graph structure hard to change

Further there is #78 proposing a solution and #70 raising the issue.

Possible solution

1. Taken from #78 Attribute and Signal branch would be removed
2. Type would be changed from ['Branch', DataType1, ... n] to ['Branch','Signal','Attribute']
3. New element datatype would be introduced as element.

@UlfBj, could you check, if I forgot something?

If after cloning rep and running make on Osx
you get:
**make: * No rule to make target vst', needed byjson'. Stop.

The current make file could be replaced with the following on OSx:
**# W3C vehicle data conversions
.PHONY: VERSION

VERSION=$$(cat VERSION)

all:
./tools/vspec2json.py -I ./spec ./spec/Vehicle/Vehicle.vspec > vss_w3c_$(VERSION).json**

I get the following error message when I click on the link in the README;

"Error: Error: url "https://raw.githubusercontent.com/GENIVI/vehicle_signal_specification/develop/vss_rel_1.json" not found"

Using slash (/) as delimiter instead of dot (.) enables direct use of the VSS path in URIs. E. g. in the case of using HTTP as the transport protocol for communication of VSS data, the VSS path naturally becomes a part of the URL. According to the RFC 2396 the path component of a URI must not include the dot character, and the de-facto delimiter for URI path segments is of course the slash.

We are at a situation where we need to atomically transmit an entire signal sub-tree with all signals hosted under a specific branch.
While individual signals can be identified by their signal ID, no IDs are assigned to branches. This means that we have to transmit full path names over the network, which is inefficient.
The proposed solution is that we assign signal IDs to branches as well as signals.
I will branch off master, modify the python tooling to do just this, and then submit a merge request.

Hi,

In the Seat branch spec, there are signals:

• Switch.Lumbar.Inflate:

• Switch.Lumbar.Deflate:

• Switch.SideBolster.Inflate

• Switch.SideBolster.Deflate

There is a duplicate of signals Inflate/Deflate between the branches Lumbar and SideBolster, with the same entries (including description).

Are they supposed to be different signals (in which case we must updated descriptions) or do they represent the same thing (in which case we should remove the extra signals) ?

For example speed and pressure have multiple units definition in list which means that the list is not according to SI units. So, remove that statement.

If you want to use any of these parameters to do automated reasoning - especially for multi vehicle situations - then there's going to be a need to specify ranges of uncertainty or probability density functions.

As the process of generating the id database is not so transparent and fail proof, I would suggest to replace them with uuids, to have them truly unique and having a fixed length. To do so and not having an arbitrary string length as input the namespace system of uuid v5 could be used:

• the root node gets a fixed uuid
• every uuid of a sub-node gets is calculated by the root node uuid (namespace) and the name of the node

That can be done recursively to the leafs. I think it offers some advantages over the old system as mentioned above. Any opinion on this?

For a server to provide access restriction functionality on the nodes of a VSS tree there must be aq way of tagging the nodes with the appropriate level of access restriction. I propose that this is done by introducing a new property, that could be named “restriction”, or alternatively “access”, that informs whether access to the node require an authorization verification before access is allowed. In order not to have to tag all nodes of the tree, a mechanism of inheritance from ancestor nodes could be applied (“if no explicit tag, a child inherits from parent”).

I proposed this in the W3C automotive WG, with the following discussion found below under “Gen2 ideas”.
https://lists.w3.org/Archives/Public/public-automotive/2019May/

VSS does not support that a single node represents an array of data. This could be mitigated by the addition of a new property with e. g. the name “elements”. See the example below where a randomly selected (by me) node is first defined as a single value node, and then in the following definition is an uint8 array with five elements.
UPDATE: See a more relevant example in comment #110 (comment), and an improved terminology in comment #110 (comment).

RearviewMirror.DimmingLevel:
datatype: uint8
type: actuator
unit: percent
description: Dimming level of rearview mirror. 0 = undimmed. 100 = fully dimmed

RearviewMirror.DimmingLevel:
datatype: uint8
elements: 5
type: actuator
unit: percent
description: Dimming level of rearview mirror. 0 = undimmed. 100 = fully dimmed
I proposed this in the W3C automotive WG, with the following discussion found on link below under “Gen2 ideas”.
https://lists.w3.org/Archives/Public/public-automotive/2019May/

vss_get_sha256_signature() declares an external reference to const char* vss_sha256_signature.

This symbol is defined in the vspec2c.py-generated vehicle signal spec include file that is included by the main app.

The end result is that libvss.so (which contains vss_get_sha256_signature() refers to a symbol defined in the main app. Figuring out how to resolve that is harder than just moving vss_get_sha256_signature() over to the generated signal spec file.

Signal.Body.Windshield.Front.Heater.Status
Front windshield heater status
String : off on NA

Can we make this a Boolean ?

Hi,

the datatypes defined in the sample json file (vss_rel_2.0.0-alpha+003.json) is inconsistent. The datatype in some place is Int8 and in other places int8 ( also Uint8 and uint8). Could this be made consistent? Which format is correct?

"Temperature": {
"min": -50,
"datatype": "Int16",
"max": 200,
"type": "sensor",
"id": 3446,
"unit": "celsius",
"description": "The current gearbox temperature"
}

EOP": {
"description": "Engine oil pressure.",
"min": 0,
"datatype": "int16",
"max": 1000,
"type": "sensor",
"id": 3434,
"unit": "kpa"
},

Regards,
Pratheek