ThomasS: I am very interested and raised this with my manager
Adnan: we will be interested in following up
Peter: interested in seeing what will come out of this, working with Android for entertainment system and how to utilize that platform
task forces: VSSo, BP, TOCC
Ted: imagine Autonomic well understands need for custom on-board data sampling
Jay: that is correct, they have a
number of vehicles and related devices, some using same
protocol
... in terms of signals sent to us, we have no control nor
types of events, alerts or thresholds
... eg harsh braking event is preconfigured
Ted: pet peeve wrt harsh braking
Jay: also doesn't take into
consideration geography, hills require more braking and
acceleration for example
... agree more situational data would be useful to collect when
criteria met
... UBI is a main use case
Ted: UBI data points vary widely by carrier actuary from what a telematics provider told me. sounds like you will be interested in participating in Best Practices based on your experience
Jay: you can infer possible inebriated driver if tunes are blaring and windows down...
https://www.w3.org/2020/03/auto/draft-policy.pdf
https://www.w3.org/auto/wg/wiki/Vss_data
Summary on GENIVI CCS
Breakouts - Routing use cases
Adnan: what I'm doing is taking
the tooling for VSS and came up with a good tree view
... I took dgts library and some visualization functions
... now I have to take a closer look and can then push to
public repo
Ulf: it would be very useful
Adnan: could put instance on web somewhere
Ted: we can publish to www.w3.org
Peter: it would be a great reference
Gunnar: code is better, hosting is cool too
[Ulf slides]
Ulf: I have two different ideas,
one came up in GENIVI meeting a couple weeks ago and another
myself
... instead of only providing latest signal, you may want to
store a time series of data
... we should be able to use Gen2 to get it to client apps and
cloud
... client must know if a given leaf has stored values in
addition to latest
... if a client knows it exists, how to request it
... suggesting stats for the key for name/value on the
node
... max number of samples should be there
... sample frequency could be conveyed too
... average would be useful
... it is possible to request all or portion of stored
signal
... avg, max and min could be there
... my next question is how to support it in request
... also describe #fragment uris
... as an example using EV signals on battery status
... this is meant for only historic data, current and future
handled by subscriptions
... frequency is needed
... if client asks for large number of leaves, it gets an array
of objects with timestamp as distinguisher
... questions?
Peter: I think it is a good proposal
Thomas: would be useful for my ebike demo
Ted: contrasting capabilities to subscriptions
Ulf: I see support and should make an issue to discuss further
Gunnar: not sure you've seen the wiki I've created since we discussed it
Ulf: not yet
Gunnar: after yesterday, I want
to update it based on presentations such as using
'observations'
... need to review what is out there already
... agree with Ted there may be conditional jobs
Ted: jobs and server logic@@
Gunnar: this can cause it to get more complicated and should discuss further
Ulf: next idea is related to
OBD
... we have some partial support for OBD in the tree already,
they are far from covering everything available to OBD
... I think to try to build out that branch to cover everything
makes it too large
... I was thinking it could be done in some other way
... all the signals accessed with a service number and pid
number
... you get a freeze frame for example for DTC
... we want to do a GET in Gen2 which can't take parameters for
service and pid
... my idea then is to introduce a new type, extra sensor and
add pid leaf on obd
... this is how it would look in yaml
... this introduces new query options
Ted: what is missing in VSS that
we care about and available in OBD?
... also OBD signals are OEM specific not
common/standardized?
Ulf: we have most of them already but not all service/pid combinations
MagnusF: do you also propose way to do diagnostic routines this way?
Ulf: I cannot answer, any service/pid combination could be covered
MagnusF: also limited in
diagnostics procedures, there is interest in diagnostic over IP
for example
... a procedure will query a number of different signals and
request DTC
Ulf: cannot answer but will look into it
Adnan: a good 70 or so (via webex chat re #signals not in vss tree)
MagnusG: my comment is similar to Ted's, many are already in VSS tree
MagnusF: there are a number of
OBD signals that are standardized, mostly around emissions,
o2
... they're even defined on the wikipedia page
... most signals are available in the standard tree
... OBD is kind of a parallel tree
MagnusG: there are quite a few tools that use OBD, Gen2 could support an OBD api of sorts
Adnan: this is more interface implementation than data model
Gunnar: as for the standard OBD information, it could be mapped into VSS tree and access it that way
Adnan: it is more than 70 attributes
https://en.wikipedia.org/wiki/OBD-II_PIDs
Adnan: we have most in the tree
Ulf: this was idea to access entire set available from OBD, sounds like there might not be as much need for it
Gunnar: I could see wanting a
part of the array. if the number of pids is finite and
reasonably few then VSS instantiation could work pid1,
2...
... another thing to consider
MagnusG: your encoding was similar to how OBD does
Ulf: yes, it relays the data as
already defined. up to the client to understand and
decode
... it is transparent to Gen2
Adnan: I think current VSS branch can handle this
Ulf: seemed there are a number of signals not there yet and want to avoid growing the branch too excessively
Adnan: you proposed two elements
and those can be the leaves under the branch
... you can have one x/y and pass through parameters you want
to get back
... you don't want to have to decode but get back the 'real
information'
MagnusG: the idea to add new leaves to the tree?
Ulf: one extra leaf
MagnusG: so you provide the
parameters and it would be transparent
... ok, I like it more than before
Adnan: you have a way to get data in generic way has higher value instead of needing to decipher
Ulf: I'm fine for now and will send slides to list
[break]
Magnus Feuer: Overview RPC
Magnus F: Extend
signals with RPC
... what is RPC used
for
... Gauge
interest
... rpc Neds itself
to states
... lends
...BYOD use case
...remote access
...deploying 3rd
party apps communicates with server, fleet management etc
Peter W: The Volvo
Signal Broker open source project example of RPC
Thomas S:
Bosch
interest
Magnus F: Security a
big thing
...
Daniel
... connection
lost
... integrate to
specific nodes or thru a gateway ?
Magnus F:
Idea define a
service interface within the vehicle. abstract the underlying
communication with a gateway not directly.
... publish a flat
service tree
... to do not publish
entire vehicle apis
Thomas S: How far down do you go. Limited depth approach aggrement
Magnus F security and
role based security will be important
... Layered accèss to
domain
Gunnar: Another ECU use web protocol within the vehicle
Magnus F: Use web
world extension to the vehicle ?
... or other route
using an ip and bringing that to the web world
Gunnar: Android
strattles in car and consumer device
... ECU to ECU extend
SOME/IP is needed
Magnus F:Third party : Against using native protocol
Gunnar: agrees
Ulf: Non issue. Not
design anything depending
... on technology
Gunnar: we want some coordinate
with SomeIP
... there is already pubsub and events
... you may want same interface description language and have
certain bindings that already exist and influence
protocols
... there will be gaps
MagnusG: we do not want to do
things dramatically different
... requirement is to align on conceptual level, internal and
external protocols
Philippe: reminder to consider distributed data services (dds)
MagnusG: will capture that
... do people agree this is needed? JLR does, what about the
other Tier1s and OEMs?
Ulf: I think this is absolutely
interesting and more than JLR would be interested and ned
it
... not sure it should be implemented in Gen2 but perhaps on
top of it
... this is a different abstraction layer
... actuation can be carried out by Gen2 and should make sure
it has the features needed to implement
... we are signals oriented and shift to service paradigm
MagnusF: I can see it along side instead of necessarily on top
Gunnar: WAMP supports both :)
Peter: do we see this as Gen3 or different specification?
MagnusF: I see it as a separate
one
... it is a one way dependency
Daniel: we have
read/write/execute
... I see service more for when you cannot use simple
functionality, turn on single service
Gunnar: earlier you mentioned
writing signals and also actuating a function like opening
window
... most likely your gateway will need to go to another ECU and
something can fail
... the return code on web protocol is not a strong instrument
to use
... if gateway is in charge of the data, this can be changed
from within or outside the system
Daniel: you can do quite a bit with direct setting of signals but more complex would fit better in RPC
MagnusF: is there interest in defining a service catalog?
Gunnar: there is definite
interest
... the industry is starting to get ready on standardizing
services to the vehicle
Peter: is there already start of a service catalog, seems like it would be a daunting job
Gunnar: it is
MagnusF: 2 motivators for auto industry at present are regulation and generating revenue
Ted: catalog can grow over time and business case@@
Gunnar: SOTA is another obvious one that has failed to be standardized
MagnusF: that gets complicated yet with all the suppliers...
Ted: SOTA will be legislative
MagnusF: coming down soon in Japan but more process
Discussion on rechartering and WG focus@@
Next steps
Thomas: my personal opinion is Bosch needs to be a part of this, this is kind of what we're trying to do in VAPP