- From: Björkengren, Ulf <ulf.bjorkengren@volvocars.com>
- Date: Mon, 18 Feb 2019 14:41:39 +0000
- To: "klotz@eurecom.fr" <klotz@eurecom.fr>
- CC: Harjot Singh <harjotsingh@geotab.com>, "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
Hi Benjamin, >> The fleet manager would also specify somehow a sampling frequency and a minimal data quality. How should we specify data quality? Looking at the Good practises at the link you provide below, it seems rather complex. Too complex for me to directly envision how it could be used in our context. VISS/Gen2 provides aa mechanism for specifying sampling frequency (https://www.w3.org/TR/vehicle-information-service/#server-side-filtering). >> "GEN 2" would provide a means to specify it when interacting with individual vehicles and fleets. GEN 2 is per vehicle, so interacting with fleets requires a layer on top of GEN2 that understands the concept of 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, independently from the brands/models/generations... Rather, these technology-dependant metadata should be specified somewhere else. Regarding sampling frequency that is already supported in VISS/GEN2. Regarding data quality, I think we need to boil down the details of how to express it before we can come up with a proposal on how/where to incorporate it in our solution. >> I especially have in mind that several signals could be queried in with the same sampling configuration. I think that shall have a good chance to be feasible, once we have solved the above. Ulf Björkengren Ph. D. Connectivity Strategist M +4553562142 ulf.bjorkengren@volvocars.com VOLVO CAR CORPORATION 94014 Lund R&D Tech Center Frederikskaj 10A Copenhagen, Denmark volvocars.com -----Original Message----- From: klotz@eurecom.fr [mailto:klotz@eurecom.fr] Sent: den 15 februari 2019 12:48 To: Björkengren, Ulf <ulf.bjorkengren@volvocars.com> Cc: Harjot Singh <harjotsingh@geotab.com>; public-autowebplatform@w3.org Subject: 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fdwbp%2F&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7Cb5ff93ae009f4ed4ff0d08d6933b769e%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636858280938562240&sdata=FyHn7%2FbDiN5CnLbPOLIA%2BpZlwAAmzrXLUk%2B3%2BeGr8WY%3D&reserved=0). 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%7Cb5ff93ae009f4ed4ff0d08d6933b769e%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636858280938562240&sdata=XzeaKhj0IM165VLo8K9%2FpwGzAtgdd4NaFle%2BPVH%2B3Ss%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%7Cb5ff93ae009f4ed4ff0d08d6933b769e%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636858280938562240&sdata=il4AlMXY%2Bv5CRy8GzMLF6y3FvH3JtCQL6V5GrvrV%2BDw%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%7Cb5ff93ae009f4ed4ff0d08d6933b769e%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636858280938562240&sdata=XBdDbD1N7vgSmVGfOCB%2BWRCb6nH%2F54n1AWdwTp2Ge68%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%7Cb5ff93ae009f4ed4ff0d08d6933b769e%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636858280938572252&sdata=ZaDCXu%2FREQEh1PLOwcxoNmaZWnZ9XClo6msnLO55zvo%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%7Cb5ff93ae009f4ed4ff0d08d6933b769e%7C81fa7 > 66ea34948678bf4ab35e250a08f%7C0%7C0%7C636858280938572252&sdata=651 > oU8Juz%2BWCJX6LALfZ26QrZoaoypC0Z7QWhBn82JU%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: https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwebmail.eurecom.fr&data=02%7C01%7Culf.bjorkengren%40volvocars.com%7Cb5ff93ae009f4ed4ff0d08d6933b769e%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C636858280938572252&sdata=oz%2FTk81V%2FWWYE%2FXi05RVfrldY5MTfqyQOi2yEPlYhmQ%3D&reserved=0
Received on Monday, 18 February 2019 14:42:04 UTC