RE: Discussion Thread: Incorporating Sampling Methodology into VSS

Hi Harjot,

I think this is an important issue that should be accommodated in some way by the solution we are developing, but I am not sure it should be solved by adding anything specifically related to this into the VSS specification.
Instead we should use the generic VSS+GEN2 specifications to solve this “use case”.

It could e. g. be done by introducing a new node in the VSS tree, e. g. at a branch “Vehicle.VehicleServices.SamplingProfile”
Issuing a “Read request on this node, which includes the path to the sensor which the client wants information about:
READ Vehicle.VehicleServices.SamplingProfile?sensorAddress=<path to sensor>
would return a JSON formatted string containing key-value pairs describing the “sampling profile” of the sensor.

An Update request to this node could change the profile accordingly.

Do you think something like this could provide the functionality needed?
It would then of course be up to OEMs to implement this service, as in the above scenario it resides in the car.


Ulf Björkengren Ph. D.
Connectivity Strategist

M +4553562142<>

94014 Lund R&D Tech Center
Frederikskaj 10A
Copenhagen, Denmark

From: Harjot Singh []
Sent: den 14 februari 2019 00:17
Subject: Discussion Thread: Incorporating Sampling Methodology into VSS

Hi all,

As a follow up to our last meeting on February 7th, I wanted to open a thread into whether or not to incorporate sampling methodology into VSS.

I am of the opinion that sampling methodology is a necessary component that should be addressed at some level. My rational being that similar to how we include attributes on data through the spec (description, datatype etc), attributes on how the data was collected play an important role for users of the data down stream. Information on how precise the hardware measurement senors/components are, and how/what process is applied to data before it is stored elsewhere (GPS data comes to mind first and foremost) is directly impacts the value of the data.

On another note, the more demanding the potential down stream request for data - inevitably there is a proportional associated cost with transferring information from a vehicle elsewhere. In other words, more data sent = more costs accrued. The logic used to determine whether or not a every point of data from a vehicle is uploaded / made available or not should be made clearly defined.

For additional information, the 'Data Contract<>' document previously shared can also be used for reference / additional topics of discussion. This is a draft document that Glenn and I put together, it isn't ready perhaps for general public consumption - but contains several points of interest / use cases of note that we have brain stormed.

Thanks for your time.

Harjot Singh


Product Safety Manager | B.Eng.Mgt.

[Cell]  +1 (647) 501-6665

[Toll-Free]     +1 (877) 436-8221


Twitter<> | Facebook<> | YouTube<> | LinkedIn<>

If this email was received in error, please notify me immediately and destroy the message and any electronic or paper copies.

Received on Thursday, 14 February 2019 10:31:26 UTC