Automotive Working Group Teleconference

VISS ViWi comparison

Laurent: how we start off with Fulup's impression and how he reached it, then we can figure out our documentation
... I have seen this happen before

Gunnar: I believe we are also looking at a document that is over a year old and his view may have changed

Fulup: CAN acquisition for us has been driven by our underlying application framework at AGL, it defines a security model
... we were motivated to move away message broker for our security model
... sockets and rest were the same approach for audio
... we differed by starting from lower in the architecture whereas you started from a high level api
... as we were not willing to reinvent. we chose OpenXC provided by Ford
... it was not designed to run on linux but a controller
... we took various existing technology as input. a year ago we only had a low level api for CAN
... in selecting a solution we chose based on what aligned with our architecture better
... we found ViWi a closer fit
... we implemented a signal composer so you can send custom notifications
... we are finding developers readily understand ViWi
... it took us only about two weeks to implement it on AGL
... we didn't implement everything but most of it
... we do not have a clear understanding from OEM in what they want from an app ecosystem
... we received a presentation recently in Japan on signal composer which is different from ViWi and they are fine with it
... we still do not have entirely what a developer would want defined
... I am not sure how much you are looking at efficiency and performance
... DensoTen liked the model and concept but were not willing to give 10% of cpu for composing signals
... on gen3 3% of cpu is acceptable. we know there are improvements to make, too many lookups and not enough hashtables for instance
... we have been focusing more on performance and usability than the semantics
... we are happy to deploy any method that would be used by developers

Gunnar: VSS was a choice back when you chose OPENXC

Fulup: it wasn't doing the decoding yet of the underlying binary messages because that is what we get with openxc

Gunnar: Signal decoding details using CANdb as a field in the VSS database was presented at that time.
VSM (Vehicle Signal Manager) project was also announced before the need for Signal Composer that you described.

Fulup: I was at that presentation, at the time it was written in Python
... ViWi can be distributed across multiple servers

Gunnar: VISS or any other proposal should be possible to spread over multiple servers
... your colleague misunderstood the specs about that possibility, we discussed and agree that should be supported if desired
... very interested to hear your input on optimization or how to bind to lower level parts
... you said you already had a REST like thinking about how you wanted access, hence ViWi would have made more sense

Fulup: the framework already had a sense of verbs for granting priviledges to different areas
... we wanted to leverage as much as possible in our existing architecture
... for monitoring we have a completely different semantic and using graphml(?)

Gunnar: can you elaborate on the move from message broker? it was never a popular choice in Genivi and came from the Tizen days
... the paper dwelled on this implementation detail

Fulup: that perhaps came from Denso
... we could have fixed the issues but not with the cybersecurity model at AGL

Gunnar: you implied we wanted to use automotive message broker at Genivi and we did not

Fulup: the reason we moved to a new model was because of the application framework

Laurent: interested to hear VISS can be run on multiple servers, that is new to me as well
... I want to know more about decentralized VISS explored further and in more detail. I found this a drawback

Gunnar: why wouldn't it be?

Laurent: the query model

Gunnar: same applies to a REST call to a URI not on a given server

Laurent: with a central tree approach, it suggests singular server

Fulup: the composed signal is produced somewhere else and should carry the priviledge down to the component that delivers the signal
... outside of performance that is quite a complexity

Laurent: there might still be some things that are not clear to some of us
... still not clear how the single tree of VSS would be spread across servers, ViWi is distributed but with a registry
... I am not aware of an implementation that does so

Ted: one thing I have been hearing from Tier 2 is that they are considering whether or not they should be implementing VISS on underlying ECU. that might be facilitated with ethernet as OEM are considering alternatives to CAN and other buses.
then a VISS instance can simply aggregate the underlying ECU services, enforce authentication and access
I am wondering if you are seeing others considering such a solution

Fulup: yes and no, most OEM have gateways where they collect from different networks, firewalls etc
... in case of AGL we support different network backends
... today the biggest demand is CAN and LIN since people want a cheaper bus, agree ethernet is desireable
... that is independent of the server
... today in AGL you have to tell the signal composer where the signal is. there is no discovery possible

Gunnar: I proposed before vehicle signals to be a different domain and to be optimized explicitly for them and separate from media and other apis
... I believe we will gain more from optimizing solution for vehicle signals separately instead of trying to fit everything into the same model
... I am not against a common solution but not at the cost of performance
... database based browsing of media is different

Fulup: I agree. what people are willing to do is merge signals for performance analysis
... today we are pushing most of the information into a database to do some deep learning and to do so need to merge everything
... vehicle signals are clearly different than a database

<Zakim> ted, you wanted to ask about developer survey

Fulup: low level CAN is being used by AWS for instance
... Toyota had a demo running recently
... signal composer no, that is more at PoC and research
... we learned of the performance issues from Denso

Ted: we have some customers of this service (developers) in the conversation but can certainly use perspective from more. do you have a developer community using your signal composer?

Fulup: there is ISO work on doing a common model for the cloud
... presently people are simply going with lower level CAN because that is what they have
... we are lacking clear guidance on what developer community would like to have
... we have good lower level adoption but we still need to advance something for higher level

Ted: we might want to come up with something better for distributed services so apps do not have to be customized for a given vehicle, discovery perhaps

Gunnar: that is close to the fixed versus dynamic address, discoverability

[adjourned]