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
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?
[adjourned]