<urata_> Sorry, I'm reconnecting from my phone
<urata_> connected
<ted2> W3C Auto issues list
[Review of issues list in github for VISS specific]
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
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
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
<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]
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
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!
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