Automotive Working Group Teleconference

Introductions

<urata_> Sorry, I'm reconnecting from my phone

<urata_> connected

VISS Issues

<ted2> W3C Auto issues list

[Review of issues list in github for VISS specific]

Test cases review issue

Wonsuk: ETRI has implemented VISS and I have been using Urata's test cases and finding some issues
... missing some constant variables and need improvements to getmetadata
... I discussed with Urata-san yesterday and sent a pull request which will address

Ted: are you inclined to provide an implementation report?

<wonsuk> implementation report: https://w3c.github.io/automotive/implementation_report/implementation_report.html#title

Wonsuk: for CES 2017 we did a proof of concept with Samsung, ETRI and Korean car companies to show VISS
... we were running dashboard components and showing an interactive demo including interactions from watch
... we have enhanced our implementation to ensure it passes the test suite
... remaining test to pass is mixed filters but otherwise complete
... I will be adding this to test report soon
... Urata used a template from W3C specifications. we have some basic informations about what the report is in an abstact
... we have 31 test cases now and provided a table to report implementation results on their test
... I hope others go through the tests for their implementations and provide results

<scribe> scribenick: ted

Urata: Wonsuk thank you for the explanation. basically I wrote in the implementation report about our VISS implementation. we had 22 pass and 9 failures
... that is because we have not implemented some functions such as wildcard path in ours
... the filter function is not fully implemented either
... we are not using wss but insecure ws in our setup for now
... about implementation status for the test cases. i sent an excel sheet about that to Ted and Wonsuk yesterday
... I hope you can share that document

Urata's email with spreadsheet

spreadsheet on test cases

Urata: some tests are not implemented
... 0310 and 0320 have comments from Wonsuk and modified but not yet done
... 0220,0230 and 0270 not implemented
... it might be ok to not implement these tests

Ted: i understand why 0220 would be hard to implement a test for but should still be tested and we should leave as defined
... implementers should ensure a subscription cannot be hijacked or closed by id

Urata: should 0230 be left or removed?

Adam: a high level authentication token could be revoked after a subscription started and we can test if this error is generated
... it could mean a traffic/load issue or authentication revoked

Ulf: another interpretation of this test case is loss of access to underlying ECUs

Urata: yes I think this is a good one
... this test suite is executed automatically and the framework doesn't have access to VISS server making it difficult to realize certain tests

Ulf: maybe one could use a unique path that always fails so we could conduct this test

Ted: understand the issue, test framework is external to VISS but the tester could manipulate the server during the tests ideally while stepping through like in a debugger

Wonsuk: we want to match an error to a client, maybe use magic path like Ulf suggested
... when that is requested it triggers an error message

Urata: I can do that in my implementation but not sure how others will

<wonsuk> I can do that too ;)

Magnus: one way or another people should test it but maybe we should not implement as a test. leave it as defined and up to implementer

Peter: we did a tool at Melco for conducting concurrent tests etc
... it is available and linked from our implementation report

Magnus: that was just a tangent. we have a performance test client as part of our Qt implementation

Urata: filter mixed condition as a subscription is difficult to test as well
... that is why I wrote I didn't find a good test case for it

Ted summarizes CR steps and we are awaiting TAG review still

Joakim: are there guidelines on errors for passing test suite?

Paul: half of the web platform tests fail for example

Ted: are there areas, we heard possibly wildcards, being too difficult to implement. is the value there? is there an alternate from RSI we should consider?

Ulf: I find wildcards very useful and would not want to drop. it can be used in elaborate ways which can make implementation harder, maybe some reasonable restrictions could be imposed

Peter: as I recall when we implemented it was not very clear in the specification but do not remember the details
... we discussed with Adam and Kevin and made some modifications

Adam: I can see two examples, one where we use a branch node for VSS tree and other is using a leaf node
... you raise a point about partial strings (eg o*) and agree that would be difficult on the server
... it is not clear to have this restriction but we provide two clear use cases to support

Ulf: I am in the process of pushing a tool to github of yaml to native formats
... using C .h file
... in that push is also code that can select within a tree that are get/set and supports wildcards

Ted: we should clarify in the spec these examples are how this feature is implemented - either leaf or node w/o characters
... the other feature we heard difficulty with mixed filters

Wonsuk: I think we will be able to write code to handle that in our implementation
... wildcard and filters would be complicated
... for leaf node mixed filter is easier
... I agree we should have restrictions on wildcard use
... we need to provide more information in the spec

Ulf: regarding the mixed filters is it "or" or "and" that we support? I think we want both

Ted: let's ask our clients across the table

Ulrich: you need to support real world use cases. for instance i need to know the mileage only on trips over 500 miles
... I think in the end you would need multiple, independent filters

Peter: from a logical point of view I agree but would prefer to not have to implement on the server
... in our reference implementation as I recall we did not implement mixed filters yet

Joakim: if there are production implementations and we get demands from users we might need to support

Prokop: can you provide specific examples of these complex filters?

Peter: we had a good example, unsure it is in the specification
... typical in a subscription scenario you may want to monitor specific signals and act as a trigger on change

Prokop: it is also useful for limiting signals you don't want to see
... in Sensoris we have conditions that would warrant collection new signals, if the wipers are turned on then we want more information
... you could have a filter with conditions if all true that you want to hear about it otherwise no

Ulrich: does a condition like minimum change mean your subscription send results only when that criteria is met?

Ted: yes

Hira: how will the wildcard work on the Genivi VSS tree?

Urata: wildcard function as an example is wanting to get status of all four doors without having to do four, separate subscriptions
... if I use a wildcard I can subscribe to all of them vehicle.*.door.*
... that would give me all the signals for doors in one stream
... wildcard function is not originated from Genivi VSS specification
... the idea of wildcard came from our Working Group discussion

Hira: I want to know about the stability of VSS architecture from Genivi

Ted describes next steps on VISS exiting CR, seems we will only have one new issue - to clarify wildcard usage

Ted we agreed earlier we should do snapshot for VSS when we get to REC and state intended goal of forward compatibibilty

RSI authentication and nested types

PatrickB: nested types would let us better integrate VSS data model in RSI
... it comes with certain limitations, they will not be filterable
... RSI is more of a graph, its own path
... there would be a JSON structure within a class
... you get a structure but entirely as a blob instead of being able to be selective on that struct

Ulf: would you be able to do get and set on socket?

PatrickL: no, you will get a stream on socket and do simpler get/set on http

Ulf: sockets are more efficient when it comes to sending bytes / bandwidth

PatrickB: we thought initially bandwidth isn't as big a problem as processing power
... there is more bandwidth than you need and progress on capabilities. complexity of services and linking of them is more our problems
... internal not an issue, over the air is separate

VW submission

<paul> https://www.w3.org/Submission/2016/

Magnus: one of the use cases was vehicle to IVI as mentioned but not necessarily limited to that

PatrickB: initially we wanted to be able to attach a smartphone to head unit to the car to be able to run apps on phone against these signals with http and web sockets
... we already have a [n unminuted] number of vehicles that provide that capability from their head units
... we have moved entire ECUs to this interface
... first design was to combine head unit and devices such as tablets and phones, then ECUs

Joakim: what about the outside world?

PatrickB: possible but there are security, privacy and bandwidth concerns

Ted: back to filtering, question is where the crunching takes place. clearly on vehicle to avoid off-board bandwith restrictions
... would be nice to have on server instead of more crunching in client apps as there will be competition on head unit

PatrickB: there are various parameters that can be applied similar to VISS filters, frequency of sampling, on-change
... some of the more complex filters described this morning we don't have

PatrickL: bear in mind we have multiple services underneath and difficult to impose filtering capabilities on them
... you cannot search for everything in a service

PatrickB: you need to know you are looking for a radio station

Ulrich: if you have a certain inventory of data for a given vehicle, client applications will want to be able to know what is available?

PatrickB: the protocol only describes how to transmit the data. the different services limit what is available, example being media library service and a given version describes what is available

Ulrich: is there a way to query the metadata to see what is available?
... as a fleet manager I can be handling data from many vehicles across brands and need to know what I can access

Ted: VSS data model has versioning and app tokens are used to enforce access control

<Prokop> a complex filter could be - if vehicle is within a bounding box AND it is Monday through Friday AND the time is between 8 and 10 AND if the AntiBlockingBraking System is enabled, then collect last 30 second positions, the maximum acceleration of the last 10 seconds, the brake pedal pressure, the air temperature, the rain intensity.

PatrickB: we have same concept, application always brings a JWT
... token validity can be checked and access restriction imposed
... tokens can be issued by OEM, by the car itself for a specific device to be trusted, by the car for a limited use - current car boot session or time limitation, PSK is the 4th option (eg an Audi ECU talking to another Audi ECU)
... in all those cases you get a JWT that you send to service for access

Ulrich: this is similar to how we handle consent at Caruso which we will look at later
... what does a GDPR compliant token permit access to

PatrickB: we share the JSON structures and what you will see from $spec
... services will tell you what access rights you have
... eg vehicle information read

Paul: how much of this is new compared to the submission?

<paul> https://www.w3.org/Submission/2016/

PatrickB: we will make the authorization/authentication available after this week

<paul> https://github.com/wzr1337/rsi.server

PatrickB: I created a mock server for people to play around
... there is an application called rsi.demo that plays around with components
... there is also a guy using this already for an OBD2 dongle

<PatrickB> https://vimeo.com/264608788

<PatrickB> Find a demo application here: https://github.com/wzr1337/rsi.demo

<PatrickB> I will opensource an example lcient in HTML5 soon

Ted: back to differences on VISS...

PatrickB: the main difference on filtering is as a client you cannot specify the change difference you want to be notified about, implementation may have certain number of specific units or how it handles change iterations

Ulf: would it be feasible to add?

PatrickB: no but it becomes problematic with the underlying ECUs who will be supporting this protocol

Ted: I am hearing inquiries about exposing ECUs as services which is possible in VISS and RSI
... including for after market use cases

PatrickB: some of our suppliers may have leaked their intentions in this regard

Ulf: I hadn't thought about the ECU aspect earlier
... it could introduce complexities

PatrickB: it does introduce complexity in general
... it would be fair for an ECU to implement 90% of the protocol

[discussion of individual ECUs controlling access vs a clearing house service]

RSI roadmap

RSI editors

Ted reviews modules and framework, seeing if we can settle on which besides framework as starting off point

Paul: a fundamental question first, are we in agreement on convergence or are we planning on v2 being a replacement?

Ted: stated goal has been convergence. sockets and signals structure being the two major pieces. VW has expressed willingness to bend as has JLR

Ulf: you will need to have client be able to tell which it is accessing

PatrickL: I wanted to evaluate what advantage each have, see what their strengths are
... ideally without people being entrenched in either, arguing an existing solution

Paul: it is useful to have varied perspectives, with the developer and embedded engineer in mind

PatrickL: it is worth bringing forward solutions we want to have

Ted: it is an opportunity, the data model is a big piece. we also have HERE, Caruso and desire to at least do mapping

Magnus: we need commonality and want to avoid multiple models

Peter: we have a data model within Volvo as well, making it available for Android
... I was having difficulty on convincing people to move forward on VISS, starting to and now need to figure out RSI
... people realize we need standards

Ulf: we should also discuss whether this is accessible from both on and off board uses. I see VISS supporting both

Paul: it was a goal to do both

Ulf: I heard previously you were considering HTTP REST in VISS which now RSI provides

[quick recap of history from Paul and Peter]

Ulf: I am hearing in RSI you cannot do get and set on individual signals but should use HTTP

Ted: pros and cons for both. not mixing protocols encourages sticking with sockets. i like audit trail and ability to inspect PUT requests more carefully for security

PatrickB: I think the principals are more important than the protocol

Ulrich: a standard that ends where the car ends isn't useful. we need some higher level use cases. data model should be applicable everywhere
... we have a flexible way to add flexible attributes
... we will have periods where bandwidth is a problem or ways to use a different transport to be more efficient

Paul: we have to get on the same page

[reads VISS abstract]

Paul: you can view everything as a signal although disagree that is the right approach
... enabling client applications to consume signals

VISS

Benjamin: WoT is having the same discussion and have some abstractions above the protocol
... you could have it hidden from the developer. it might be worth looking at their solution. they are looking at HTTP COAP and as far as I know not sockets

Adam: I think it is important to consider different views of the same information
... you can have for instance a second screen and want it to dynamically want it informed of change
... you need ability to be informed without having to do constant polling
... latency is important

<paul> https://rawgit.com/w3c/automotive/gh-pages/vehicle_data/vehicle_information_service.html

Paul: one of the reasons we kept VISS limited to web sockets was to make an initial release as quickly as possible

PatrickB: there are times you want stability more than reducing latency

Urata: VISS has been focused on signals and I have viewed RSI as more suited for things like media files
... you can think of a media file like a document that does not change and HTTP is more suited there
... VISS hasn't thought about handling these other uses but more load balancing and efficient responses
... sockets and http have different advantages
... I wanted to point out the differences in scope of the solutions RSI and VISS were trying to solve and differences between sockets and HTTP

PatrickB: except for header information web sockets and http interactions are similar

Paul: I've been capturing comments and my thoughts in a wiki during this

<paul> https://www.w3.org/auto/wg/wiki/index.php?title=VISS-RSI-convergence-framework&action=edit

Ted: I am concerned we are moving to much into the abstract. engineers inclination to reengineer, regularly
... we should stick with RSI with its HTTP and sockets, define something concrete based on that and then come up with an appendix that describes how to allow for the same solution that optimizes for other protocols (that sound like they are still HTTP even w/o TPC overhead)

<paul> https://www.w3.org/Submission/2016/SUBM-viwi-service-car-20161213/#car.info

PatrickB: (earlier) on windows there is a way to interpret a localhost request and remap it

<paul> https://www.w3.org/auto/wg/wiki/VISS-RSI-convergence-framework

Ulrich: we took our data structure from tech alliance
... first we realized there are many legitimate ways to construct the tree
... we separated the leaves from the structure and then created mechanism to list all the signals that could be assessed
... they you can apply your desired hierarchy structure, it just requires a mapping

Prokop: this is similar to what we do in Sensoris
... we just consider it on atomic parts
... it doesn't matter where you put it in the structure

Ulrich: I would like to see a list of signals and their attributes defined and accessible

PatrickB: that is just the first step

<urata> Sorry, I have to leave today. See you tomorrow!

VSS Ontology

Benjamin's slides

Daniel: I am coming from the research department at BMW
... my master thesis was on connecting web services and spent some time researching ontologies
... if you think about the car and bringing domains together it is not worth doing it manually
... Benjamin looked at different data models and it is a really good start to get your opinion on whether or not it makes sense
... semantic meaning makes it far greater

Benjamin: we looked at VSS for this project
... we wanted to avoid the problem in this example [slide 2] where you get an arbitrary number without enough meaning about it
... you want contextual information
... the common basis is signal data model. without it described you can't do anything with it
... if you don't have semantics you have quite a bit of manual work

[slide 3]

Benjamin: how can we enable interoperability with a single data model
... I focused on VSS given its use within Genivi and W3C
... in terms of semweb solutions for providing signals, I looked at OGC Semantic Sensor Network SSN ontology
... currently being used in several industries, industry, healthcare
...
... sosa/ssn observeration and sensor pattern
... physical device attached to vehicle, making an sosa:observation
... you can define signal, sensor, well defined units etc
... there is a need to define the car components as done in VSS
... vss:Speed can define its observable signal along with multitude of signals that are part of the drive train
... one thing missing from vss was attributes
... vss had some inconsistencies with type and definition. added sensor and actuators
... for all entries we were provided units to map to their formal definition
... we applied some new consistency policies to vss
... most important was adding unique identifiers. you want to be able to identify a single signal
... all signals are either observable, actuable or both
... all branches are part of the top vss:Vehicle
... unique names needed for unique concepts
... there is one vehicle speed but different sensors capable of presenting it (gps, speedometer etc)
... you could potentially query for all instances of speed to query

Daniel: in some cases the frequency of signal availability is more important that the quality

Joakim: there is nothing in the model that prevents multiple statements

Ulrich: you can have three or more ways of measuring speed with conflicting values

Prokop: when you have a crowd sending sensor data. when you need accuracy you choose the authorative eg from speedometer
... the user chooses which they want

Laurent: can you have consolidated sensors?

Benjamin: yes, some are doing that

Ulrich: there could be multiple sources and they need to be distinguished so you can select which
... there should be enough information like frequency of updates, accuracy so you can choose which to trust

[slide 12]

Benjamin: ssn only defines what is a signal, attached to sensors
... another (4th) modeling choose is all branches are vss:partOf vss:Vehicle
... when abstracting all those branches, everything is a part. a complete vehicle has subdomains
... modeling choice 5 postion not equal in branches. left, right, row1

Ted: we struggled with that given the variation on vehicles, current and future for instance one may have two lidar sensors on front and another three.

Benjamin: you will need to make vehicle specific graph
... example of safe and unsafe driving

[using step: ontology for trajectory etc]

Benjamin: what about oem-specific concepts?
... VSS is meant to be extensible by different manufacturers
... instead of 500 branches. came up with 84 formally defined parts, 300 signals, 40 formally defined attributes

PatrickB: what we released for small vehicle, we are representing properties not parts in RSI

[slide 18, various vss tools including vsso cookbook to generate ontology from yaml view]

Benjamin: you will end up with an opem specific/private ontology cookbook
... you can use the existing yaml tool on the custom vss
... you should validate your ontology after, check you are not overriding an existing concept with another incompatible one
... in the end create your custom namespace

Ted: before Paul left he wanted to point out the auto ontology community group at W3C
... they are inactive, having completed some rudimentary ontology for vehicles. schema.org will welcome more from us.

Benjamin: you can specify various features mostly for things like trying to sell a car
... they took a step back when trying to think of trying to define all these sensors in a flat way

<Zakim> Paul, you wanted to point out the auto ontology cg

<Zakim> ted, you wanted to give bg on semweb

Benjamin: agree we should get in touch with those people

Ted: semantic web can seem off putting to some initially. it is widely used in AI, intelligence agencies, healthcare and life sciences, aerospace to name a few. [rambles on benefits]

Joakim: schema.org is Google and a handful of other companies

Benjamin: how does RSI handle multiple windows?

PatrickB: we have one resource for eg doors or windows
... we add rows and seats/position
... locking all doors in RSI you would GET all doors and then use your results list to POST

Ulrich: it doesn't necessarily makes sense to limit the hierarchy, more important is the proper name