<scribe> scribenick: ted
<urata> I can talk alghough michrophone is not very good.
<urata> listening is clear
<urata> thanks!
Paul: the way we access the data,
whether sockets or REST unsure how to get people on the same
page
... I want them to exist in the same world
Gunnar: we have a world of
signals that exist but doesn't cover everything
... we have version 1 (VISS) based on signals and should look
at adding REST on top of it
... I see a difference between signaling and everything
else
PatrickB: I don't see any difference between a vehicle ECU and a media player
Ulrich: why would we want different mechanisms
PatrickB: the mechanisms rely on
certain properties on the objects to be present since you need
a URI
... it needs an id to be descriptive
Gunnar: that is identical to VSS,
hierarchy of objects, name and type
... in that case RSI and VSS are semantically equivalent
Paul: goals is to converge on
data model and access method
... data elements and concepts are the same
Ulrich: access and structuring
the data, I liked the discussion of abstracting the hierarchy
from the data elements
... the ontology gives much more than the hierarchy view
... we need to focus on the elements and their properties,
finish it
PatrickB: at the end of the day
it is important what the developer sees when facing the
API
... it might help to explain how we expose our structure to
help find the right viewpoint
Adam: one of the reasons we got
these long strings in VSS is knowing physically where things
are coming from in the vehicle
... for example torque left front, you need to think about
handling extensible zones going forward
PatrickL: can you please add to Paul's wiki?
Adam: sure, making some edits if you reload
PatrickL: it would be good to explain where you see value and should be included
example: /car/drivingstates/yawRate (RSI) || Signal.Vehicle.Acceleration.Yaw (VSS)
Gunnar: if you do a get on /car/drivingstates you get JSON of everything else?
PatrickB: correct
Gunnar: doesn't more path depth/hierarchy make sense to be able to get more efficient and pertinent data sets?
PatrickB: I see what you are saying
PatrickL: they look similar but are different
Ulrich: path and parameters is one approach
PatrickL: comparing these two sides doesn't help
Ulrich: the structure we got toward at the end of the day with ontology is to describe it technically
PatrickB: to be clear the data
model in our submission was just an example and we are willing
to agree on the model behind it
... there is value in the common data model
Ulrich: that is the first key statement
Paul: we agree on the data elements and need to clarify the structure
<AdamC> Updated wiki page to encourage zoning discussion
Ted: @@dtf
Benjamin: I have always seen a tree
Gunnar: I would also say VSS is an example structure. there was intention on this being up for debate and refinement
Ulrich: there could potentially be different hierarchies for different purposes
Paul: we're heading in the right direction
Ulrich: if you construct this from an application programmer's point of view you need an API
Gunnar: there are times you get the same signal information from different ECUs and need to know from which
<PatrickB> I cannot update the wiki but I would love to see the table we just talked about to be reprhrased like this for better understanding: https://gist.github.com/wzr1337/56a08b01545f510e2b2a52250afea51b
Ulrich: we came to looking at catalog information, eg maintenance and service plan, separate from signals
<AdamC> Updated as requested :)
[agreement on understanding of http paths and expected behavior, modulo potentially minor changes]
Laurent and Ulrich: XPath could work for handling more complex eg wildcard path requests
PatrickB: there are reasons we might not want such a long path
Ulrich: XPath would give you attributes and nodes, you can go to wherever you want
Gunnar: since XPath is so expressive, how feasible is it to implement
Ted: that was one of the lessons from VISS, complexities of wildcards and mixed filters
<KevG> Imho :-), Both the RSI and VISS API can be used to return any logical object graph
Prokop: I am seeing this as very
detailed within the signals
... from Sensoris perspective I can share how we are doing
it
... we are doing several things with requesting data on a
higher level, groups of information
<PatrickB> Back in via phone
Proposal: subcommittee on data structure
[small list candidates from different perspectives]
<AdamC> Fire alarm my end - will dive out for some minutes :/
Magnus: components ontology, taxonomy, vocabulary and whether to provide different structures for different audiences
Gunnar: I heard concretely working on pull requests for VSS
Magnus: I want to see a
continuation of Benjamin's work
... I would like to see it more central than as a view
Paul updates wiki on proposed work areas
https://www.w3.org/auto/wg/wiki/VISS-RSI-convergence-framework
<AdamC> * Back in the room :)
Wonsuk: for the data model we will compare VSS and ViWi and come up with a consensus on element names and then add structure
<PatrickB> Why don't we just take vss signal names as property names for viwi objects? The list is available already.. Easy catch
<wonsuk> -#1. compare signal/element definition from VSS and RSI
<wonsuk> -#2. to make superset of signal including consensus of name, unit and extra for property
<wonsuk> My summary for data model work is below
<wonsuk> -#3. adding the structure for each model for VSS and RSI
Ulrich: I see two or more columns where we line up the different model's elements
Gunnar: I would like to see us add REST to VISS
Paul: why don't we take the protocol doc from ViWi and use that as our starting off point for REST?
Gunnar: my slides show the mapping/difference
Paul: what about all the status codes and other parts they figured out in ViWi?
Gunnar: good point
Ulrich: place that might be
difficult is attribute access and what that means
... see what we might have to add
Paul: I want to avoid losing the work from the ViWi protocol doc
PatrickL: I try to pull features
out of both that I like
... I want to avoid going back to the beginning and
rearchitect
... I want to have versioning, registry to lookup services,
ability to interlink objects and REST
Gunnar: are all of these important for vehicle signaling?
Laurent: who is the customer for this? the developer and need to keep that in mind
PatrickL: this seems like scope for the framework team to work out
Ulrich: those are good design goals
Kevin: It makes sense to me to
add REST to VISS
... I see as RSI and VISS that could turn any logical graph and
represent any object
... there isn't a big difference in what the systems can do
only in how they're accessed
... I want to avoid a different socket access from RSI
Peter: I want to avoid missing any of the benefits and capabilities from RSI
PatrickL: if we are collecting all the things we like and want to have then there is not a risk of forgeting something
Ulrich: my wish would be an
introspection interface to see what I can access
... something parsable that I can use to configure my access
mechanism
... machine readable, something I can feed into my
application
PatrickL: I want to have that as well since it is helpful
[lunch]
Ted: we are hearing interest
about VISS spec reaching maturity, implementations rolling
out
... a common data model and consistent manner to access the
data enables not just content providers to write applications
for head unit but for data sampling and edge computing before
sending off to silos
... yesterday we heard about Benjamin and Daniel's work on
adding ontology on top of VSS
... semweb technologies (W3C, schema.org and others) are a bit
of a deterrent to some
... as mentioned the proposal is not to have a competition for
on board app developers, most will be web developers and
embedded engin.eers who would be quite content with
VISS/RSI
... this is about enabling automotive data in the cloud
... we have a good start and some big pieces of the puzzle.
VISS/RSI, VSS ontology, ISO extended vehicle & neutral
server specs
... we have heard about Geotab's neutral vehicle proposal
(combination of those two)
... we should hear from Caruso and others here on their
solutions in this space
... WG rechartering on completing VISS and start RSI in
earnest
... we will be forming a task force in the BG to assess the
components, conduct a gap analysis and prototype specs and
solutions
... one clear component we will need is capturing user/owner
consent on collecting data and sharing with third parties
[Sensoris slides will be available on member-automotive mailing list. it will be made public on sensoris' site later
Prokop: we see both types and interfaces as relevant. we are looking into standardizing and aligning the whole data flow
Ulrich: you distinguish the two interfaces (v2c and c2c) since the car is offline more
Prokop: in cloud to cloud you are
not interested in data costs
... more of an issue in v2c
... vehicle manufacturers want limits on volume
... in Sensoris we are just focusing on the content and how to
transport it
... we are not specify encryption being used. if you want a
near realtime communication, you package it and send out
... for insurance use case your data sampling may be once a day
and would contain personalized information
... we are looking into all possibilities on how the data can
be transported, what is transported depends on the use case
Gunnar: what do you mean by packed in Sensoris, that a data format?
Prokop: correct, protobuf
... some information is static and doesn't change over type eg
fuel type
... pathevents is where we start group by structural parts,
vehicle, weather, etc
... we have object data, for instance a pedestrian is
recognized
... you are looking at where does the sensor information come
from
... we started with a broader view, not caring where in the
vehicle the information comes from but what it describes
... we have a strong focus on roads and conditions
Gunnar: what do you mean by path?
Prokop: location over time
... we package relevant information together. for some
information like hazard warnings we collect last 60 seconds up
until that hazard
... in some cases we only need small excerpts of information
for a limited period of time
Gunnar: understand certain
signals information can trigger the sampling
... sampling and submitting are separate?
Prokop: correct. regarding submitted it depends on the information, we do not defer on sending hazard information
Gunnar: can this also be requested on demand?
Prokop: only push, no pull
... OEM are concerned about pull as they loose control of the
data
... timing for submission is part of the job description. jobs
are pulled to the vehicle with data tile layers, some vehicles
may choose not to do jobs
... we are talking to some governments on traffic management.
they are starting to standardize road changes
... we will get these map changes directly instead of having to
wait for capable vehicles to travel that route and assess
... we have created a hierarchy model of how things belong
together
... at the leaf we have elements that describe that atomic
attribute
... we have a flat list of elements we can map to different
standards
Gunnar: can you provide an example?
Prokop: we may identify a sign
and its attribute is an enumeration, eg speed limit sign
... it is not always easy to do this mapping and the uses
vary
[discussion of dynamic signs such as speed sign on autobahn that changes based on congestion]
Prokop: we are looking into
different validity ranges. you can have a mix of static and
dynamic information
... we want to align with the different data structures
... right now it is not about aligning everything but merely
mapping
... in the end we will distribute this model to the various
standards bodies. ADASIS participants only can see their
data
Ulrich: we are a b2b broker,
concerned with the entire life cycle of a vehicle
... field testing, warranty handling, maintenance
... we see three big areas, looking at all the signals coming
from the car itself. catalog information - parts, warranty, vin
etc
... mobility services
... in vehicle data is incredibly important as connected cars
increase
... we look at upstream data. what we see today is highly
proprietary and requires months of negotiation going through
oem
... we are trying to create a more open exchange - b2b
marketplace
... we look at business (price), technical and legal (access
rights)
... data provider does the collection and provisioning, we do
not connect directly to vehicle nor sensor
... we don't host services on Caruso platform. we standardize
left and right sides, creating a data catalog like we have seen
today
... we feel there should be more alignment and why we are
getting involved
... we have two main components a marketplace and brokering
engine
... for the portal we have web interface, ability to drill down
by categories...
... imagine a fleet manager having a number of vehicles they
are responsible for, some may be equiped with dongles or fed
through different means
... we provide a list of vins, we know which vehicle is
serviced by which provider
... permissions are checked. we request data from providers,
handle the brokered results, consolidate and return
... documentation in swagger
[example data model in json]
Ulrich: here is a data model from
BMW representing 79 publicly data points
... they have three categories, unique id, technical descriptor
and more verbose/readable description
Gunnar: that mapping is negotiated between you and BMW and not available to your customers
Ulrich: we need to provide the
different mapping and provide in an adapted
representation
... we are working with 50 different data partners and each are
different
... three categories vehicle information, in-vehicle data,
process data
... you get this information from a telematics service
provider. you can lookup VehicleServiceDue, then proposed
parts, price, location for workshop...
... of these use cases almost none of them are purely
in-vehicle, it is the combinations of different data sets
... we have been talking to TSP, OEMs, data points people can
offer and compare to what people are looking for
... we came up with over 400 data items after survey. >80%
have update frequency requirements
Ulrich: this is basically our
tree and we came up with at the Tech Alliance
... the other domains have their own data trees. repair &
maintenance information, parts supply, trade, fleet management,
roadside assistance, insurance...
... as you all know there is a new privacy compliance
requirement coming into place
... one of the news for us is a data item cannot be looked out
without context
... it has to judged based on the handling party. if a vin is
known to belong to an individual you have to treat it as
personal information, if not you don't
Ted: interesting, so maybe better not to know or to have a non-identifying hash
Stiepan: what are you referring to as anonymised/encrypted
[discussion of data later becoming personally identifiable and how to handle over time]
Ulrich: each party needs to ensure they are lawfully possessing it
Stiepan: it is a challenge to properly anonymize data
Ulrich: it is presently a mine
field and our lawyers are looking at how to handle explicit
consent
... we require a consent token and for it to flow along the
data path to be able to check consent is given and can be
passed on
... we are exploring this with Fraunhofer
... as mentioned everyone in the chain needs to check they can
lawfully posses the data, previously it was responsibility of
the provider
... players do not need to know the full chain, only whether
they can access it and pass along
... a neutral server can separate the providers and consumers
of the data so they cannot deduce business models based on data
access
... extve (iso20078) proposes to use neutral server but since
the consent management goes from provider to data consumer,
unraveling the masking
Fabian: there can be competing business models which can be revealed in this manner
Ulrich: on the provider side, consent needs to be received directly from the user (eg via oauth)
Stiepan: do you go into the specifics how you confirm the user gave consent and not for instance malware?
Ulrich: we specify a way to
authenticate the user
... on top of scenario specific data exchange there is exchange
of consent token
... currently based on oauth
... we have a technical solution, it requires some tweaking
Stiepan: working with ITU on
standard for data encryption
... my focus will be on Android and making it have more privacy
by design
... GDPR or not, privacy needs to be implemented
... issue we have in android when we want to implement
encryption in one of the main tools you need to do so in
C++
... Google strongly discourages using C++ in general,
exceptions not well handled
... we are doing a research project where we are creating such
a library
Gunnar: explain the relevance
Stiepan: you need to higher standards for performance and reliability
Peter: how are you following Google roadmaps and releases in extending android?
Stiepan: we are and are not
... it is a move away from android in the classic sense
... we proposed to standardize our cryptography to ITU for 5G
market and automotive seems like a natural progression
... without I don't see how web payments would be possible
Ted: interesting but trying to understand relation, we are a very different part of the stack. higher abstraction layer
Stiepan: you need to handle periods of poor connectivit
... I will provide an introduction so you can work on an liaison with ITU SG17 q13 relevant to autonomous cars
Paul: android has been increasing within automotive, many aren't using Google services
... interested in hearing in general your experiences, getting our services on android, more about their car apis
Peter: there are applications available based on their car apis
Stiepan: are you looking at alternative to android builds?
Peter: no
Paul: what about extensions?
Peter: we are thinking about how to extend standard auto
[recap of goals for data model work from earlier]