https://www.w3.org/auto/wg/wiki/VISS-RSI-convergence-framework#Feature_Discussion_Topics
Laurent: there is sometimes
tension between internal needs and thinking of the third
parties who would be writing applications
... to me it is very valuable to keep them in
consideration
... in the past as part of the CCC I worked to define an API
for third party developers on smartphone
... we were thinking of a typical Android developer and giving
them access to car data
... in that case OEM developers were third parties as
well
... do most of us have a third party in mind or a
collateral?
Adam: from our perspective would
be to allow app developers how they can access signals to ease
onboarding them
... so they can work across different manufacturer vehicles
Laurent: when we spoke with AGL
people awhile ago, we still were focused on the people creating
IVI system
... this brings me back to profile topic from last week
... we can have a profile on datasets and capabilities
... maybe this notion of profile can relate to the type of
application being developed
... does a smartphone need fast, current access to signals? i
don't think so
... in every case I come back to a common single understanding
of a dataset. it is very important to me
Kevin: one of the things we have
come up again is that the VISS spec is how applications may
hand off aspects to the cloud
... we are very aware that connectivity and subsequently IP
addresses can change
... as such VISS is not something that can be invoked from
internet
... you don't know if a vehicle is active and connected until
it first calls out
... as such VISS focused on-board
<CarrierJohn> help
Kevin: this increases potential
delay with respect to signals, you won't have realtime
... different vendors will want access to different sets of
signals
Ted: besides the connectivity issue having us be more on-board centric, worth noting from security perspective it is generally a safer model to push data to cloud than to allow cloud (even firewalled) to connect to vehicle
Kevin: valid point, that
gets us into privacy concerns as well
... there are many sensitivities around this data requiring
care in handling
Laurent: notion of cloud is
interesting. as you said VISS was designed with onboard in
mind
... ViWi was intended for both on-board and paired devices in
the car. we know cloud considerations need to handled as
well
... again consistent data model is highly useful in cloud
interactions
... both have authentication and maybe security. I want to
learn more from the Web of Things group in that area
... the work we have been doing, especially Ulf, has been very
important
... we don't want to work with three different models even if
there are different access methods
John: what has been described is
very important in IFSF world, we need consistency in
communicating to off vehicle services
... I see close analogy with fueling/parking etc dispensers.
there are a number of proprietary models for the different
service dispensers
... we have been working on elements and objects in a data
dictionary. we are putting this in a public github to increase
awareness
... there is a notable difference between on and off-board
interfaces
... it is probably more important to have consistency for
off-vehicle
Kevin: the protocol spec
(separate from model) could apply to any data graph
... get, set, subcribe and could be applied to petrol
... it helps us if these can be logical instead of
physical
... we do not want to have to handle minor differences in
physical equipment but common conceptions
... we would not want to have different object graphs with
different structures
John: necessary for regulating eg recharging rate. a charging station needs specific data and doesn't want to have to know different OEM
<magnus> https://github.com/CarrierJohn/Fuel-Retailing-Data-Dictionary
Laurent: with regard to different
protocols, I don't think the internal ones are going to be
differentiators
... if I have a better internal one than yours it won't matter.
working together so information can be exchanged easily within
and external to the car is what matters
... solutions built on top of these is what will matter. we
want to expand this ecosystem. interop is key
Gunnar: I have been working on interop for a decade now
<CarrierJohn> Here is latest link.... https://gitlab.com/Fuel-Retailing/API-Data-Dictionary
<CarrierJohn> without my name
Ted: one of the developer friendly
things we do in VISS is getmetadata
...having consistent data model and means to access across
vehicles is important
but also what subset of data is available to an application on a
given vehicle will still vary
Glenn: we are after market fleet
management
... we are partnered with a few hundred other app developers
who work with us and collectively have a large global
fleet
... we appreciate what has been shared so far
... comment I would make, our customers large fleets and
leasing companies, would put more value and ephasis on vehicles
that make this available
... enable ability for third parties to write applications for
it
... for our purposes is not so time sensitive and can reduce
cybersecurity risks as mentioned about realtime access to the
vehicle
... the direction of the conversation is going in the right
direction as is the data format
Ted:we understand legal and business complications where certain
signals will not be exposed
...I would like us in the data tf to maybe come up with different
audiences and categories of signals they should expect reasonable
access to
...I can imagine regulators will not be patient with multiple data
models and protocols in seeking information they will require
Laurent: if a regulator cannot find a standard that suits their need, they will come up with something on their own and we don't want that
Ted: I think we are all in agreement that we do not want politicians defining protocols
Laurent: they can influence the
rest of the industry to adopt a standard
... we made progress on data set and now just need to work on
protocols
John: what do you mean by
protocol? for fuel retailing API we are building steam with
Connexus and Association for Parking Data Standards and talking
with OMG for a global retailing data model
... we are just publishing APIs
Laurent: the dataset is the
payload, "the what" about car or fueling station. "how" I
access is the protocol
... it might be HTTP, WS or MQTT
... there may be multiple ways but a common data model is
key
John: we are coming firmly down on HTTPS
Laurent: we are discussing signal
profile - sometimes a specific protocol is better for certain
needs
... HTTPS sounds like the right thing to do for your needs
John: IFSF is in the payment work
around AF256
... we are telling all the petroleum retailing to have to
support multiple payment encryptions, AES192 and others
... interop is key. supporting multiple standards is a mess
Kevin: reason we are passionate
about VISS is because we want commonality in as many places as
possible since we already have to deal with regional
differences
... we see creating commonality opens up interop
John: we call things like a pricing agent, handling authorization of a fueling point
Ted:
I want to circle back to Kevin's earlier point, what we are
working on can be used for other data models as well
...today's call has been focused on our developer audience,
writing applications on-board vehicles
...this is the same audience IFSF wants writing applications. I
encourage IFSF to follow our work and consider it for your data
model
...that way these same developers can mix both, consistently and
intuitively instead of learning a new paradigm
John: there is also opportunities
for service stations to provide other services and better
bandwidth to the vehicle
... we are in agreement and why we are attending these
calls
... unsure what future services will exist but we need to be
flexible
Wonsuk: in my point of view, if
we want to support more signals we need to define default
protocol and dataset
... after that the client can understand what protocols are
available and supported by the vehicle
... for doing this we need to define the default format and
protocol. client may need to use the default to get more
information
... OCF is one standards body for IoT and they have a default
protocol and can change after based on the different server
capabilities
... there are pros and cons of supporting multiple protocols.
on the downside it complicates things and can make interop less
efficient
John: agree with Wonsuk, you need
to keep the data separate from the protocol. we support
different communication protocols
... we support five different at present
https://lists.w3.org/Archives/Public/public-automotive/2018Sep/0007.html
[adjourned]