RE: Discussion Thread: Incorporating Sampling Methodology into VSS

Hi Harjot and Ulf,

I think this is a important issue we need to address before writing  
any proposal for VISS "gen 2".

To me, there are 2 types of signal metadata we need to have, according  
to last week's discussion:
- attribute/branch/signal metadata
- frequency/quality/sampling metadata

If I take the example we used in the last data TF call, we would model  
an Oil temperature signal for a fleet, with low sampling frequency and  
include a trigger for a need to check something on one specific  
vehicle to do a diagnosis. In this example the fleet manager would  
need to specify the concept of Engine Oil Temperature. In VSS  
..Drivetrain.Engine.EOT has a description, unit min and max values. The  
fleet manager would also specify somehow a sampling frequency and a  
minimal data quality. So only a subset of vehicles (those that meet  
the requirements) would send data. If the same fleet manager wants to  
address the diagnosis job on one specific vehicle (after some trigger  
the vehicle produced), then the manager would update the sampling  
frequency/quality of the signal needed.

In that use case, it seems clear to me that we need to be able to  
provide such frequency/sampling/quality metadata about any given  
vehicle, and that "GEN 2" would provide a means to specify it when  
interacting with individual vehicles and fleets. I think that we  
should not add more out-of-scope properties to VSS, as it is already  
defining a generic model for vehicle signals/attributes/branches,  
independantly from the brands/models/generations... Rather, these  
technology-dependant metadata should be specified somewhere else.

The way I see the "Gen 2" solution interface would then be something  
where you require:
- Signals/Attributes according to VSS.
- A frequency/minimal quality... of available signals, according to  
some other specification or good practices (as in  
https://www.w3.org/TR/dwbp/).

I especially have in mind that several signals could be queried in  
with the same sampling configuration.

Best regards,
benjamin Klotz
> 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.
>
> BR
> Ulf
>
> Ulf Björkengren Ph. D.
> Connectivity Strategist
>
> M +4553562142
> ulf.bjorkengren@volvocars.com<mailto:ulf.bjorkengren@volvocars.com>
>
> VOLVO CAR CORPORATION
> 94014 Lund R&D Tech Center
> Frederikskaj 10A
> Copenhagen, Denmark
> volvocars.com
>
> From: Harjot Singh [mailto:harjotsingh@geotab.com]
> Sent: den 14 februari 2019 00:17
> To: public-autowebplatform@w3.org
> 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<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F15chftyY4WMv4yQ3WlyVlHrG8BcWm-Tyws9-79eqDCgA%2Fedit&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C8f22667d7a1d4fcde39908d69209decb%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636856968419155993&sdata=K7xjZg6Ezd%2FBHbR4uEaXFbExK%2FGwzpmbvcesdUv92j8%3D&reserved=0>' 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
>
> Geotab
>
> Product Safety Manager | B.Eng.Mgt.
>
> [Cell]  +1 (647) 501-6665
>
> [Toll-Free]     +1 (877) 436-8221
>
> [Visit] www.geotab..com<http://www..geotab.com/>
>
> Twitter<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fgeotab&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C8f22667d7a1d4fcde39908d69209decb%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636856968419166006&sdata=xCm7U2V2cXZlS5GzWz0532noN5hua0rZhnaGgT5q3iM%3D&reserved=0> | Facebook<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.facebook.com%2Fgeotab&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C8f22667d7a1d4fcde39908d69209decb%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636856968419176009&sdata=Tc2d0Tlk916lYrAnz5mFMP%2FtcElcSKcxfV1QZcBBD5U%3D&reserved=0> | YouTube<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.youtube.com%2Fmygeotab&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C8f22667d7a1d4fcde39908d69209decb%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636856968419176009&sdata=%2FdvqA%2BQ%2FozY0Kho5s0U8VvDyXuE7WhRfui7Wzq39mvE%3D&reserved=0> |   
> LinkedIn<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fharjotservosingh&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7C8f22667d7a1d4fcde39908d69209decb%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636856968419186013&sdata=LXJ58JfJgblSJ4hYAPuN3q9calr5Wic%2BxxxxPXjiNgk%3D&reserved=0>
>
>
>
> If this email was received in error, please notify me immediately   
> and destroy the message and any electronic or paper copies.
>



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

Received on Friday, 15 February 2019 16:36:56 UTC