Automotive Working Group Teleconference

11 Dec 2018


Benjamin, Ted, Glenn, Jeorg_Tessmer, Mike, Ryan, Don, Laurent, Marco_Wagner, Ulf, Harjot, Hira, Magnus, Tim, Gerald, Daniel, PatrickL, Ulrich, Gunnar


Bosch presentation


Marcos: we are currently working on an implementation of VISS that is part of a larger project
... others from the product team (get names mentioned from Guru) are with me
... we are working on an EU research project called APPSTACL which is about 5G enablers and an open source ecosystem for the connected vehicle
... we started an Eclipse project called Kuksa
... first part is a cloud platform, IoT connector, device rollout...
... we want to be able to handle receiving, sending data and SOTA
... this is currently running under AGL where we have a sandbox system
... we have APIs to inner parts of the vehicle and one of them is VISS
... the three parts are cloud, in-vehicle and IDE
... as to the different layers on the vehicle we have AGL, Yocto as a middleware layer and actually using quite a bit of it
... on top of that we have several APIs including VISS and Sensoris
... we have another for direct CAN interactions
... you can use AGL's sandbox or Docker as a container
... the overall goal is to have a complete system in open source to be available to a broader developer community
... any questions? if not we can move onto the implementation

Pratheek: we have a basic web socket API and using a third party library for it
... we have a command processor, authenticator which checks tokens and then an access checker
... we use the VSS JSON for getting and setting and a subscription model
... the token received by the command processor is sent to the authenticator and if your app is authenticated access to the signals
... requests are sent to access checker to ensure you can see specific signals
... we check access is valid, if token has expired, etc.
... subscription does the same checks as get/set

Pratheek: the access checker is a work in progress
... this is already available in a git repo, links available in slides
... we also have a small test client

Magnus: do you support getMetaData?

Pratheek: yes, also supported

Daniel: are you using the same data model for cloud usage or just in the vehicle

Marco: not sure yet but if you are interested can introduce you to the people potentially involved with it

Daniel: that would be great

Marco: one thing we are working on right now and having problems with is the authorization part
... as we have shown our main focus is to bring apps to in-vehicle and be able to retrieve data from VISS
... not all should be able to retrieve arbitrary data. we have a security expert working with us
... we want an app certificate generated from the store for specific vehicle. app can then ask for tokens to be generated in-vehicle or on the cloud for in-vehicle use
... JWT are created and given to the app to be able to authenticate itself
... the last part is VISS is either able to validate the tokens itself or hand off to an access server. the validation procedure may be in either, unsure which yet
... we have a few things we are not clear about. the specification is vague on the type of token used and how PKI is handled for vehicle local network
... we would be open to further discussions on these topics

Ulf: one answer is we don't really know yet either but we are in a phase of development of a second version of the standard

Ted: we were purposely vague on tokens being used, leaving that to OEM and avoid being locked down as alternatives emerge. JWT was certainly discussed. for the next version as Ulf mentioned we may decide to be more explicit
... one candidate might be Decentralized IDs (DID) which is being used in various industries already and to be standardized at W3C
... as you heard at the start of the call we are working on a next generation of the spec with expectation of having an accompanying open source implementation. we might want to fork this

Marco: last slide has all the various links for more details or following up

Open Source Project

PatrickL: how we should start the open source project was brought up including frameworks such as Go or C++

Magnus: my 2 cents is we should choose something where we can leverage extensive libraries
... it should be a good test ground for this specification
... Python, NodeJS or Go would have the libraries we need

Ulf: should we start a survey to get group preferences?

PatrickL: it could work

Gunnar: there is another way to gauge this and that is to see who starts writing the code
... in the end those who are inclined to do the work should get their preference
... I have started a C++ to look at the complexities of wildcard searches

PatrickL: I find it sensible to let someone start

Gunnar: if there are competing efforts it will be clear which will run in the long run

PatrickL: it is important to remember the purpose is to tinker and want to avoid investing in lengthy debate without results

Ted: agree with the comments made and have no strong preference
... something to keep in the audiences, content developers who will know nothing about automotive in addition to embedded automotive systems engineers. we will want something easy for them to instantiate and use instead of having to recompile which puts C++ at a disadvantage over eg Python, Node or Java
... Kuksa is written in what language?

Marco: C++, we have some pieces in Python but complications with those libraries

Magnus: I agree with Gunnar, whoever is putting the effort can decide for themselves and we might have multiple and let Darwin run its course
... I sent a link to the Melco github repo and can grant anyone access to make pushes
... where do we start?

PatrickL: I would be inclined to fork yours and send a pull request when appropriate

Magnus: I would like others to be maintainers and handle pull requests
... also fine with it to be somewhere else

Ulf: I am happy to start with what you are offering
... I also think it would be good to have some software architecture drawings to begin with and willing to do so

PatrickL: anything else on this topic?
... or other topics in the last few minutes?


Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2018/12/11 16:41:06 $