Agenda review
Intros for George Percival, OGC and Jay Hum, Autonomics
https://portal.opengeospatial.org/files/91814
GENIVI Cloud and Connected Services (CCS)
Gunnar: overview of GENIVI, on
its 11th year, list of accomplishments
... pushed Linux into auto industry, built collaboration and
created standards
... BMW created first solution based on our IVI standards
... we have been going beyond IVI for a number of years
... one of our key strengths is we have the in-vehicle
expertise and have broad range view throughout stack
... from source of data to the cloud
[trends in vehicle EE]
Gunnar: it is about integrating
systems inside and out of the car
... collaborations with AutoSAR key, we have a special interest
group on Android
... for CCS our goal is to create a data oriented
architecture
... we create software implementations
... controlling access extremely important
... data model representation, protocols, big data
... VSS is just one data model, we have discussed perhaps too
much in the WG others
[diagram of vehicle / cloud architecture]
Gunnar: this demonstrates a way
to create Extended Vehicle marketplace
... in the cloud we are looking at Gen2, GraphQL and
potentially some other protocols
... we are trying to go from source of data to cloud
MagnusF asks about timing of project
Ulf: it is worth mentioning W3C's
graph project
... hope we can synch them on common parts, similar from data
lake and upwards
... instead of using simulated data we intended to use real
data from WG participants
Ted summarizes Graph project, goal to provide real data for graph queries to show VSS/VSSo benefits got stuck in policy since data is sensitive. Worked on policy solution with Harjot (Geotab) and Wendy (W3C counsel)
Gunnar: I heard about this project but haven't seen results yet, agree there are similarities
Daniel: agree it is needed, property graph is a bit different and which schema to use
Gunnar: we started defining the format for storing values, VSS defines signals but need exchange descriptions
Daniel: VSS/VSSo just gives common agreement on what you are talking about and needs to include Time domain
Peter: the various OEMs need to
litigate solutions to open up vehicle data
... key is to get multiple OEMs to work together
MagnusF: agree, legislation is
coming in EU and push in US for third party diagnostic
access
... I would look to participate but unsure our focus short
term
... one recommendation is we decouple each box as possible to
allow each adopter to build their own toolbox
Gunnar: we are on track, expect the fragmentation you described
MagnusF: main driver is to take
control of our own future and decouple from vendors
... standardizing portions of this would be useful
ThomasS: VAPP
... i'll share slides later
... scope for this project is huge, with 1, 5 and 10 year
projections
... Bosch is big on standardization
... we are moving from a hardware company to more of a software
one
... we are trying to make future of connected vehicle
easier
... we have people from these various companies (slide 3)
involved in the project
... we have a vehicle application platform and not trying to
replace what has taken place in AutoSAR or elsewhere
... we are trying to allow easier access to vehicles
... vehicle agnostic is useful
... we are trying to be hardware independent
... we intend this not only for in-vehicle use but could have
applications run there or in cloud
... we are trying to free up where the data is coming from,
could be a digital twin in the cloud
... goal is to reduce fragmentation within the industry that
does not reflect current software development practices
... we see VSS as an enabler
... we are pushing for alignment with efforts discussed
here
... believe Kuksa is very closely linked to work done in this
group
... we are looking to take certain elements from it, want to
have an open source community involvement ongoing
... there is a Kuksa VISS/VSS, some proprietary added on,
JWT
... we have an automotive demonstrator based on adated AutoSAR,
I'm working with an ebike manufacturer here in Lund
... we are trying to demo and show off a number of use cases
such as keyless
... one of the key things that is really important from our
perspective is getting different people to agree
... so far we have some on VSS which has taken awhile to
get
... AV people included
Ted relays possible VSS usage within autonomous vehicles (not naming partnerships)
Gunnar: it is exciting to hear the potential and start of uptake in more corners
Megan: quick background on
SmartCity perspective, we became involved in City Data Model
for ISO
... enable semantic interop across city services
... more about connection of data models instead of specific
architectures
Mark: what we are describing is contained in three work proposals to JTC1, currently out for voting
[City Data Model diagram]
Megan: this is our view of these
applicable data models
... foundations, city and service levels
... part of the focus is on transportation planning
Mark: service level for this
slide was just on transportation, leaving out all the other
city services
... our approach is to look at it from a point of view of types
of information is needed
... the way we like to think of city level is responsible for
data generation
... distinguishing generator and consumer of data is very
important
... we are not doing this in a vacuum, we are working with
TC204, Ken and Tom in particular
... we want to build on what they're doing instead of replace
and point out ommisions and may do our own extensions
... key thing is we are working together with them
https://www.w3.org/2020/03/auto/Information_View.pdf
George: another approach might be
to look for example where the navigation data
... I provided a link for a presentation I made recently
... I think priority ontologies identified is a good example,
taking routing
Clemens: our starting
point/approach is a bit different
... Open Geospatial Consortium OGC is a standards body creating
services/apis sensors standards
... experimental software from innovation leading into
standards
... our trend over the last three years that gets into web
services, RPC/XML were the basis
... comprehensive but difficult for outsiders and modernizing
with web APIs, others would call REST
... sharing data on roads, buildings. work for maps
... most location platforms, we took a look at what Google,
ESRI etc do around routing
... there are various repos, demos and videos and can create a
document to share more readily
... we have a routing API and exchange model
... main sponsor was US Army Corps of Engineers, they had
issues with all the proprietary platforms similar to how we
were discussing vehicle platforms
... they want to be able to bring together different providers
and products around navigation services
... there are three types of data, OSM, NSG, HERE with
different corresponding routing engines
... with their own proprietary APIs
... there were three implementations of same routing API
... multitude of clients in different envornments including web
applications
... goal was interoperability independent of the underlying
routing engine
... OGC approach starts with pilot code and fine tune until it
meets requirements
... we used open API formerly known as swagger
... we fine tuned it using SwaggerHub
... there are different conformance classes so a client can
know what it can get from an API
... you can create, fetch route, get status and always get back
to the defining parameters
... the most simple starting point is start and end points,
then additional criteria such as shortance, weight restrictions
etc
... you could also choose the underlying engine eg HERE's
... we have webhook callbacks
... this was not intended to solve all the issues/needs for
routing
[route exchange model slide]
Clemens: you can get segment by
segment, for route representations we use GeoJSON
... different features per segment, long/lat, turn
instructions
... GeoJSON is broadly supported
... there are a number of clients that can use it readily
... there was interest in route ontology from the W3C Palo Alto
workshop
... basically from the GeoJSON I created UML. it is not
complete but addresses the use cases we created in our
pilot
... I come more from web development point of view, want to
make it easier for developers to use an ontology or
vocabulary
... we can enrich the GeoJSON with annotations that link to the
ontology
... I created a github repository for such a vocabulary
... JSON-LD can provide RDF view and a simple route
ontology
... you have the same data with semantic annotations. there are
a number of open issues but that is where we are
... pilot was successful and there is interest in forming a
group
... nearby is Spatial Data on the Web Best Practices. there
should be an OGC Working Group formed and worth seeing if there
is common ground
Mark: just wanted to mention we are working with ESRI Canada on transportation ontology work, it has been underway for five months
Clemens: any public material available?
Mark: I'll look for slides from ESRI conference
Clemens: I know some of them
Ted @@ SDWIG etc
Gunnar: understand your comments
on VSS structure and what it can represent compared to more
semantically rich routing
... we have done work within GENIVI on navigation apis
... my perspective is it was more active a few years ago
Phillippe Colliet, Peugot
Gunnar: goal was similar to have a common routing API regardless of underlying engine
ThomasS: I will take it back to Bosch
https://github.com/GENIVI/vehicle_signal_specification/wiki/VSS-Layers-Concept
Daniel: this is a summary of the
email thread
... I tried to put it together succintly and collect the
arguments
... by using VSS there will always be a part you don't want to
make public or availible to applications in-vehicle
... bringing private branches together with main branches and
merging with tooling concepts
... Gunnar wanted supplimentary metadata
... deployment requirements, you have the tree and want to take
it into usage, instantiated
... out of experience we found we needed additional
metadata
... bigger is adding metadata. we are adding via YAML
... saying where the data is coming from
... you may have metadata that is ECU specific and expose it
here
... defining a subset of nodes as access control, most straight
forward example is EV
... supplimentary metadata already covered in individual
deployments
... you could continue using the tree structure or have
unrelated signals supported
Gunnar: a small addition, the
data categories... why it is useful for different signals for
different markets and different versions
... there may be additional needs for adding data we haven't
explored yet
Daniel: I added a number of
questions we have discussed
... as to what to standardize is the use cases but not in
detail, we should recommend how to do it
... people may use different authorization schemes
... we can use layers as a way to do that
Gunnar: it could be added in VSS repo or separate
Daniel: yes, we can define how to add layers and leave it open
Gunnar: we have other projects
that want to expose VSS signals within the car
... may want different permissions
Daniel: I think we can agree on
continuing with YAML instead of using something else
... one proposal is to follow specification files or use a tool
to create a skeleton (example) that people can add their
metadata layer
... why we chose that... on the one hand you have everything
clearly separated from tree itself
... final branch with dot notation and all its instances, the
file structure will resemble the tree at the end
... if you remove one leaf you may still want the
metadata
... you can just add your additional structure for neo4j
etc
... you can add metadata at each part of the structure
Gunnar: as for tool support,
people can create whatever they like
... we need to be careful what is allowed in VSS syntax and
this is already allowed
... both would be supported
Ulf: are we not going to implement tools in github repo? if not we need one alternative
Gunnar: both are valid, any tool that processes VSS data should be able to handle either structure (same or separate file)
Daniel: should we come up with a convention to identify the layer against the core
Gunnar: VSS structure already allows with import statements
MagnusF: yes, it would be added on top of original file
Gunnar: I think we should support both and question then becomes what W3C approach supports
Daniel: with tools you can add
metadata vspec files now, question is how to guide people to do
it
... allowed is one thing and common guidelines / best practices
on how is worthwhile to reduce the pain of adopting VSS to
start with
Gunnar: we can do that, we need
to define the syntax rules first and then we can recommend what
we think best within different groups
... unsure why the files can't be together
Daniel: you may have additional
metadata for a single (eg driver) seat
... you can follow the file structure to a point
Gunnar: instantiation causes
difference across the different VSS
... surprised you may define seats so differently
... you can define things once and instantiate information
after
... I want to allow for flexibility and agree to creating
conventions
[VSS & a11y equip, additional sensors]
Ted: there is a clear need for best
practices for in-vehicle applications using VISS/Gen2
...governing signal access, cpu/memory, bandwidth if even allowed
outside connection, what data is transmitted to who, etc
...we can
coordinate some with W3C Miniapps Community Group for things like
packaging and manifests
[additional elaboration of potential BP scope and efforts to align]
Gunnar: yes, we should develop those use cases and see how to handle
Daniel: aftermarket issue is pretty political
[discussion of legislation, diagnostics and aftermarket]
Gunnar: we looked at these things as part of our gap analysis of CCS report
Daniel: I read it
Gunnar: I could see a feeder where things start as a layer and later get proposed to VSS itself
MagnusF: we can try a different format and expand tooling to have more YAML compliance
Gunnar: I am supportive
Gunnar: Next formal rules for VSS including layers
Gunnar: private branch is a layer
Gunnar: Two different approaches to the filestructures
Gunnars: details should adhere to vss syntax rules
Magens Feuer: add to tooling
Gunnar: update to be fully YAML comp
Magnus F: Get rid of # include statement
Thomas: agree to that
Magnus Feuer: Who does what ?
Magnus F: Two asks
Daniel: can get started to do this
Daniel: Adnan could help out
Magnus F: reformat the tooling once we are out of the corona tunnel
Daniel: Who could go through the VSS issues to get a base
Daniel: Calls for frequent work on VSS issues
Daniel 2.0
Daniel: 10 minutes VSS work structure meeting
Gunnar: VSS future topic
Gunnar: make a feature list for 2.0
Gunnar: Kanban board ? project management
Gunnar: Weekly call 10 minutes after the WG call
Gunnar: Magnus maintains tooling part of VSS
Magnus F : no time now
Thomas could contribute
Thomas Visualization of the VSS tree
Ulf: discussions of ev signals ?
Magnus F: Have list of internal signals
Magnus F: are we looking for anything special
Ulf: Geotab sent out a proposal of ev signals
Magnus F: Thursday will check Geotab proposal
Magnus F: will get us a original set
Gunnar: separate mailing list
Magnus F: use w3c public
Gunnar: Genivi internal vs W3C
Gunnar: Ask TED to use public for VSS communications
Daniel: use GitHub usseus
Adnan: Best practices for enums
Magnus F: limit the space , nothing to do with formst
Magnus F: Need to think about for the features for 2.0
Magnus F: Defiances needs to be correted
Magnus F: Call it day
Magnus F : slack channel
Gunnar: Genivi use maiks
mails
Isaac: Email list vs slack channel
Peter: create slack topic
[slack more informal and regular, was useful for coordinating with sanjeev for example]