Automotive Working Group and Automotive and Transportation Business Group Remote Meetings

Agenda review

Intros for George Percival, OGC and Jay Hum, Autonomics

Architecture

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

Routing API and Ontology

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

VSS layering

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]