Christian: started with interest from Daimler to share data with customers and their communication interfaces
... worked with [redacted] on APIs. we have been part of a European initiative on data streams from a SmartCities' perspective
... worked with a number of other OEMs and Tier1s and a recurring theme is everyone is on slightly different technologies
... some are REST, some streams, some Graph...
... we focus on integration and normalization pain point
... we have proposed some research work to the German government about building open source adapters to different vehicle APIs
... also around data governance for off-vehicle use, from a GDPR perspective but also CA, NV
... we were a founding member of mobi blockchain and still scratching the service
Joakim: is it related to gitbot? you are combining open source data
Christian: it is a data orchestration layer
Glenn: we do quite a few intergrations at Geotab
Christian: we have been in touch with some of your European colleagues
Magnus: your platform on or off the vehicle?
Christian: off
Magnus: sounds like a brokered solution, to normalize from multiple OEMs?
Christian: internal broker, we work with Otonomo for instance
... we do not hold data on our end. the integration components can exist elsewhere
Glenn: you mentioned SmartCity interest, you doing any integration there yet?
Christian: FourSq, Yelp apis, entertainment services and fuel provider apis
Joakim: you mentioned an EU project?
Christian: fiware
... #1 pain point they are trying to address is the cost of each city solving their own solution, desire to have a standard
... it is a rather young initiative 4-5 years, start of adoption
Ted summarizes activity, current liaison efforts etc@@
Christian: do you see AutoSAR focus being extended to cloud?
Ted: we want the same data definitions at IVI/TSU level, in cloud and down closer to signal inception at the ECU. That way your VISS or Gen2 implementation can simply aggregate and proxy signals to requests.
Joakim: can you describe your GraphQL uses?
Christian: somewhat, it does a great job to expose complex expansive data stores
Joakim: someone tried an indexing experiment recently Neo4j
Adnan: it can be heavy on the client side
Ted: we're JSON, streams and REST vehicle side but could
see how Graph queries on local caches of data originating off vehicle
would be useful as well for AI for instance
... There is a new Business
Group forming out of the Graph workshop by
the way
Christian: if you look across the different OEMs some are close to realtime data streaming
[discussion on anonymization]
Glenn: maybe Harjot will elaborate about how we anonymize
Harjot: we make certain data sets available after it is aggregated and anonymized such as weather and pothole detection
... we will take 3 or more fleets worth of vehicle to feed into that
Christian: what is a large enough a fleet to provide your anonymization?
Glenn: we are socializing that at present
[more discussion on GPPR/CCPA]
Harjot: we have blackout periods as well, when employees are off the clock
[more on nuances of privacy and hinderance to making use of this data]
Glenn: one argument is the greater good, increasing road safety
Joakim: There will clearly be instances where regulators will require information and want to see it used for the public interest
Magnus: there is some pending EU legislation along those lines
Peter: I know of an OEM who was sued by government for not providing that information
Christian: cities are requiring data for example in providing permits to the shared scooter providers
<magnus> ecall legislation is already in effect since late 2018
<magnus> in eu...
Glenn: I want to see handling legacy vehicles as well
https://www.w3.org/auto/wg/wiki/Auto-f2f-sept-2019
ISO TC 22 - Extended Vehicle / Neutral Server - liaison request voted on and accepted
ISO TC 204 - Intelligent Transportation Systems - liaison request made, met with their secretariat, will attend their plenary/f2f in Singapore next month where they will vote. also some of the workshop attendees are involved in ITS
AutoSAR - discusssed with GENIVI who is on their advisory board, no update
TC22 - Caruso, Otonomo... Nevada
<Harjot> Nevada link: https://www.vda.de/en/topics/innovation-and-technology/data-security/what-is.html
@@r2r obd2 silos or miscommunication agree all on same model makes sense
Ted: what I need is help from those here is to look internally within their organization for who is involved in these other standards efforts. They can help us with understanding the group dynamic and how best to make a successful proposal.
Adnan, Peter and others agree to reach out internally within their companies
[discussion around ts 21185 - secure vehicle interface]
Ted: willing to be liason for two sides to this issue. The auto distro could help flush out opinions/thoughts regarding topic.
...I should probably go over my call notes from Mark Zachos DGtech
about what groups we may want to try to coordinate with in SAE
...kind of a pain not having liaison worked out with SAE, tried anew
recently with favorable responses but not optimistic yet about resolution
Glenn: J3138 not to interfere with vehicle systems while in use, probably a good starting point
... J3005 telematics and J3005-2 security for telematics
<Harjot> J3138 non-instrusive & instrusive commands defns: https://www.sae.org/standards/content/j3138_201806/
Glenn: Lisa Boran at Ford is a good person to talk with
Ted: Tom Forrest, Mark Zachos and Ira Mcdonald too, figure out which activities would make sense to try to align
<js> There is a record of the liaison at: https://www.iso.org/organization/10143.html
Ted: SAE more a North America and parts of Asia thing, what is the equiv in EU, VDA?
Adnan: yeah probably, I can look into it more
Christian: there is also Mobi blockchain with Renault, VW, BMW...
... Chris Balenger former Toyota is heading that
Ted: need to get more involved with VDA as well [particulars on individuals to reach out to]
Adnan: also Sensoris coordination
... we've been meeting with them in Munich, agree to some data mapping
Ted: we agreed tentatively to same with Prokop re Sensoris in 2018
Glenn: VDA specs are more prescriptive from my experience
Ted: apart from GENIVI, what is a good way into AutoSAR?
Adnan: not sure, I can ask around
Glenn: ACEA is more involved in TC22 than Nevada is my impression
Android widening based on recent news wrt GM
[discussion of GENIVI Android group, summary of past discussions wrt VISS]
Peter: essentially the same for us in 2021
Ulf: Volvo like the other OEMs started building out their own IVI. there were some working on porting Android to our hardware
... it was much better from far fewer engineers, hence the shift in my opinion
Peter: yeah but a much longer story
Adnan: why not just take Android open source and build on top?
Ulf: not sure
Peter: GENIVI was moving too slowly
Ted: personally I liked the banded approach of AGL/GENIVI for long run
... GENIVI model catered to corporate mentality at the time, AGL more open source mindset
... see OEMs falling for the long game of the tech giants...
Joakim: there is no way some of the OEM can come up with the AI capabilities
@@what does this mean for us? daniel, paul, peter, genivi on android relevance
Ted: I still see us useful in the TSU and various devices that may be allowed to communicate with it
Peter: their vehicle api isn't sufficient and don't see it advancing quick enough
Ulf: I think what we are doing is a compliment to Android which I think has a strong future going forward
... there are many external parties interested in this data that don't want to do so in Android, I see two pipes
Adnan: you will need two interfaces, on and off-board
Ulf: yes but I see two on-board pipes
Ted: GENIVI has an Android initiative, figuring out the gaps and what is needed. I attended their workshop at GENIVI AMM in May in Munich but haven't been attending the calls, should see if we can get a summary from Gunnar
Joakim: we should have clear use cases for which make sense
Peter: we have been having the same circular discussion
Adnan's diagrams
Adnan previews his and Daniel's assessment of ViWi data representation vs VSS
Adnan: if we can extend ViWi it could be quite good
Ulf: I think they need backwards compatibility
Adnan: we could provide mapping for their current depth structure
ViWi without depth limitation to better support tree models, backwards support could be ViWi service providing previous uris in parallel
Peter: I think given move towards Android it would be difficult to convince Volvo to go towards ViWi
Ulf: Volvo has shown they can use VISS and Android
Ted: I wonder if some would only want to support subscriptions and sockets. Volvo isn't exposing VISS to Android though, right?
Ulf: ViWi is a piece in AGL's IVI stack
Ted: AGL says they do open source code, not standards. maybe overstating...
Peter: their design was to support broader range of cars
... no wrt VISS to Android
... but possible
Adnan: I know a guy going over to GM from Google
Ted: Peter, can you introduce us?
Peter: yeah but not sure how that would go yet
... depends on who
... they have competing teams internally
... they only have a small number of signals at present
https://source.android.com/devices/automotive/properties.html
Adnan: you would have to extend that to be useful
Wiki of options for how to proceed concerning VSS in ViWi
Ulf: rbranch could help represent ViWi data in VSS
Ted: that might help their forward migration