Auto Data task force

# Harjot's Data Contract document

Wake events and heartbeat issue raised

Ted: I introduced the topic of wake/heartbeats we discussed previously from Harjot's document to the Auto WG, no responses so far

VSS issues list

Ted: previously we discussed signal accuracy and Daniel indicated precision could belong on VSS level

Harjot: quite happy to, are there additional threads we want to raise right now

Ted: sampling methodology is perhaps the most important topic for adding value to data for offboard usage but unsure where we would address it, likely in a separate spec for offboarding. I was thinking we can tackle some of the other simpler pieces from data contract document that could apply to either spec
... for today perhaps we can focus on Data Frequency

Glenn: OK with that but perhaps discuss Ulf's response to Harjot's message
... for data contracts he wanted us to flush out to develop specific use case[s] whereas I think it applies to all
... I would be interested in Benjamin's comments

Benjamin: basically we listed what we want to include in VSS wrt data contracts
... first there was interest in creating the data contract attributes on indidivual nodes
... looking further and with the different OEM solutions I think it could be too challenging
... vehicle capabilities will vary. we can define this somewhere else
... we would want it compatible with VSS and merged with the data being consumed

Glenn: if I understand correctly, then a vehicle manufacturer could implement VSS but not necessarily the data contract attributes
... that could be problematic. previously we mentioned placeholders (optional attributes)

Ted: it would be better in single spec as optional. in many cases OEM or Tier 1 won't implement or may not include for some underlying ECUs. higher quality data might be a differentiator in vehicle market to large fleet operators. applications running on vehicles and accessing their data want to know how useful that data is

Glenn: exactly. if there isn't even a placeholder then there will be no market forces

Benjamin: for accuracy attribute for example, it would be on each node?

Glenn: yes on the individual nodes. it might be desireable to have coarser/higher tree wide attributes as well for data contracts

Benjamin: would we override on individual leaf level?

Ted: if an ECU has known precisioin from its specs it can be represented in VSS, some OEM or Tier 1 might not expose in their solutions and the attribute could be optional., unsure where sampling will belong
... belongs with consent as a probable separate spec for offboarding data from vehicle

Glenn: see your thinking as it is separate from the service and data model specs

Benjamin: it comes back to implementation dependent metadata, it is just another aspect of metadata we need from vehicles
... to my mind VSS specifies considerable information but makes sense to keep complimentary pieces close for when streaming the data, ensuring you are allowed to use it how
... it makes sense to keep together

Glenn: if I'm understanding Benjamin for GDPR we also need per signal granularity

Benjamin: we need to provide proof for every single leaf we have permission for GDPR

Armin: agree the attributes do not need to be specified on leaf level. you can have different purposes, frequencies in which the data is collected
... you could think of introducing metadata objects that describe rules for a set of data elements
... to increase usability for the developer
... a set of rules could apply to eg the entire engine

Benjamin: thank you, yes you can deal with things easily in VSS based on entire branches
... you want that information available on individual leaf node in some manner so you do not have to look at a broader representation

Armin: difficult to disagree with you. you could have inheritance and individual settings

Benjamin: within the discussions we have had on data contracts, we haven't yet seen good practices for representing these attributes

Ted: this sampling and consent may fall within scope of broader data transportation group mentioned, should know later today if workshop is going to form for June
... what to do with remaining time, focus on one of our smaller eg freq

Magnus: when we discuss on-board information versus off-board, you may not need all these
... in the car it tends to be more event based
... some will have a cadence for sure

Ted: agree things like brakes being appied are event not cadence but back to our engine temp example that will likely be on a regular frequency
... for in-vehicle it will be mostly be event or cadence, for what is collected and sent off it could be either of those, curve or other

Magnus: different cellular network capabilities will also influence sampling

Harjot: regarding Ted's question about different sampling per signal
... it is primarily event based logging. we use delta differences as the event

Ted: earlier I was saying sampling might belong elsewhere in a spec about metadata for offboarding but given how signal frequency for in-vehicle is also needed we should reflect on whether it might make sense to have in VSS for both scenarios

Glenn: agree, to Benjamin's earlier comments on terminology I'll draft something to share

Benjamin: sounds good to me

[adjourned]