See also: IRC log
<inserted> scribenick: kaz
starting with Paul
Paul Boyes, Ted Guild, Shinjiro Urata, Tatsuhiko_Hirabayashi
Kaz_Ashimura, Qing_An
Volker_Fricke, Wonsuk_Lee
Soumya_Kanti_Datta, Peter_Winzell, Powell_Kinney, Rudi_Streif
Klaus_Birken from Genivi, Osamu_Nakamura
Hiro_Hayashi
Kevin_Gavigan
rudi: there are various OSs/platforms, and no standard APIs
urata: made some slides on pros/cons of each approach
peter: IDL could be used for either approach
rudi: the question is where do you implement the API
paul: what level of API do we as the WG want to expose?
klaus: we have built a prototype
implementation
... if we manage to specify protocol, we can define APIs on both
the W3C side and the Genivi side
... protocol and serialized data should be separately defined
rudi: we focus on the upper layer interface
paul: would discuss what APIs would be used which interface using Kevin's architecture
urata: (shows his slides)
kaz: slides to be distributed later
urata: Pros and Cons
... Questions
... and Web and Automotive Hackathon in Tokyo
... [ Vehicle API (polyfill) structure
... KDDI/ACCESS implemented polyfill-based Vehicle API
processor
... what is done by the polyfill
... manages queues for subscribe() API and get() API
... Data matching, JSON parsing and WebSocket I/F
... Data Broker translates OBD-II data into JSON
... another possibility is Data Broker directly handles
get/subscribe APIs but it's not the case here
... call backs will be queued on the subscribe queue and the get
queue
hira: Web Apps don't specify URLs (or IP addresses)?
urata: no
kevin: are you really subscribing the
data?
... what's the purpose of having subscribe and get?
urata: depends on the property
... get for vehiclespeed
... and subscribe for engineSpeed
rudi: this is the model I was describing, we can define the WebIDL piece and leave the websocket server and databroker to the underlying auto manufacturer
wonsuk: how much data could be handled at the same time?
urata: there is no limitation
wonsuk: concerned since we have a lot of data properties
urata: the vehicle api polyfill keeps working
hira: you'll improve the mechanism. right?
urata: yes
wonsuk: why did you use this model?
urata: wanted to implement an actual prototype system asap
klaus: share the concern with
wonsuk
... should avoid making the JS processor keep work
... the communication flow between the OBD2 side and the data
broker side
urata: there is a set method
within the spec
... using OBD2 dongle to communicate with the OBD2
network
... in this system, it's impossible to implement set
method
... we focused on get/subscribe for this model
ted: websocket approach may be
bi-directional
... you used OBD2 for this model, though
... Rudi's comment is that the green Data Broker part may be
provided by OEMs
rudi: blue part should
concentrate on the existing APIs
... and we could use websocket approach for the I/F between the
orange part (vehicle api polyfill) and the green part (data
broker)
kevin: the orange part is in charge of data transfer to the green part
paul: we have Adam Croft online
(gotomeeting)
... can share the screen using Gotomeeting
kevin: another question is how to use websocket for multiple APIs
powell: could have 2 separate socket connections for get and subscribe
kaz: how many sockets did you use, Urata-san?
urata: one socket for both get and subscribe
<klausbirken> I understand there is a goto meeting for screen sharing, could someone share a URL, please?
ted: one of my reasons I like the websocket approach is that it could have access control granularity
<AdamC> Hi All - go to meeting https://global.gotomeeting.com/join/134321333
ted: developers could use both
the vehicle apis and websocket depending on their need
... AGL does websocket approach
... agnostic from the presentation layer, e.g., Qt
... vehicle apis might be convenient for developers but
websocket would provide another layer
rudi: I myself am neutral
... inside of the IVI system, there could be various
presentation layers
... possible to have another web browser who talks with web
servers outside the vehicle
<ted> scribenick: ted
kaz: you can connect for talking to the outside world as well in the vehicle api layer
rudi: you can still do websocket
approach from a webidl and expose other lower level system
(c++) apis that way
... speaking to platform specific apis would require browser
vendors to implement and they might once platforms like genivi
are more established
<Zakim> ted, you wanted to ask who would likely produce and maintain vehicle api layer
<kaz> ted: we may see one or more browser vendors implement for this market but there will likely be a time gap we would need to cover. we would need to get genivi or someone to implement browser extension. it would be easier to have a js only lib implementation as it can work in multiple runtimes
<inserted> scribenick: kaz
klaus: how do we handle smartphones attached a car? they are less likely to have webidl component but could do websocket
urata: you can use vehicle apis on the smartphone
<ted> volker describes the kid in the backseat "are we there yet?" use case :)
volker: might want to use bluetooth, etc., as well
hira: implemented this system on
smartphones for taxis as well
... including bluetooth I/F
paul: Kevin also has his presentation
urata: coexistence of high-level
I/F and low-level I/F would be possible
... [ Vehicle API (native) structure ]
... peter implements similar model
kaz: have you already implemented this native model?
urata: partially
... implemented get method but not subscribe yet
... [ Vehicle API Impl ]
... same things are done within both the polyfill version and
the native version
... [ Vehicle API (native) structure; again ]
... [ Vehicle API Impl; again ]
... [ Pros Cons ]
... we had many opinions already
ph: can you do both the approaches?
urata: that's possible
... and one possible option
paul: want to have explicit discussion on this
urata: [ Web and automotive
hackathon in Tokyo ]
... Japanese OEMs attended, Tier1 companies as well
... there were 11 teams
hira: please talk about the development environment
urata: created some emulation
environment for the developers
... (shows some video)
... video image hosted on Youtube and vehicle data on the
display using the vehicle api polyfill
... highways, mountain roads, etc.
... wanted to detect ABS information but couldn't handle
that
... in this system we implemented 20 features or so
... [ diagram of AWS, YouTube, Synchronize, Vehicle API
polyfills ]
... vehicle api polyfill requests data and AWS sends the
data
hira: recorded data could be used for testing
ph: wondering if it's possible to
make this more publicly to W3C so that more people can be aware
of this work
... maybe other Members are interested in this work
urata: someone has to drive the
car to collect data
... because of security reason, we've not published the URL
yet
paul: this is the link to the AWS site
urata: right
klaus: what is important from the
GENIVI viewpoint is clear mapping between the IDL and the
implementation
... we could transform FrancaIDL to WebIDL
... automatically
... the key point is how to adapt to this
(Klaus leaving for another GENIVI session)
paul: Kevin also has his presentation
(we can come back to the Pros/Cons discussion later)
[ morning break ]
<ted> scribenick: ted
Kevin's architecture diagram
kevin: left hand side is vehicle
modules - display, gps, cameras etc.. list is much more
extensive and these are just examples
... along the bottom are CAN signals with their secure
gateways
... glossing over the networking components as they can be
bridged a number of different ways
... the top layer is the different types of clients that could
consume the vehicle api, again not exhaustive
... web runtime is what we call a browser instance without an
address bar but to run html5 apps available on the
vehicle
... loaded from a local webserver and file store
... you can have a multiple of different information available
to your apps
... if it wants to consume vehicle signals it would need to go
through an application server, imagine a nodejs instance that
can return json
... between the application server and vehicle interface we can
attach security tokens. not everyone (app) should be able to
get and set attributes
... in a typical vehicle there can be more than one CAN bus
with different gateways
... client might also want to combine signals from off-board
(internet) service
... those would go through a firewall to externals data
services, portals etc
... getting traffic, weather and other information
... OEM may have a specific data provider, vehicle identifies
itself via PKI
... all communication over TLS
... another potential client is where the user can have a
browser and retrieve html, css, etc from the internet directly
and we permit some access to local application server
... given the security concerns this is a less common
scenario
... also may be Qt/C++ and headless(managed runtime) apps
... as we do not intend to expose a public IP address the cloud
data provider will control what gets passed back to the
vehicle
... off vehicle clients can be a browser - follow vehicle
activity
... or external applications and services
paul: why have separate web server and application server?
kevin: they are performing
separate roles
... they don't have to be separate
soumya: it seems you are using a
number of web standards/technologies already
... if there is some time from WoT perspective we have a
presentation that would be worth sharing
paul: hopefully yes
<Soumya> thanks Ted
kevin: in terms of security if we
stay with http web service base, are there issues with
hijacking websockets or other concerns
... there are scenarios where you may want to expose off
vehicle advanced access like to emergeny responders who want to
disable airbags after crash so they do not engage as they are
helping people
[kevin describes token passing]
kevin: you will want various off
vehicle information about driver, preferences for seat
position, music stations etc
... people will want this to be able to follow them across
vehicles and will likely have different subscriptions (content
and service) they will want to use
... number of reasons you will want to identify the driver and
it is rather complex since they may not be the owner and you
want to protect driver information, clear it from vehicle
... user can be registered with oem portal which stores their
information, they identify themselves with a sso auth and
retrieve that information
soumya: do you have guidelines
for how we access the CAN bus?
... I have a basic demo for transferring basic data from the
vehicle to the cloud
kevin: it won't be the same even from the same vehicle manufacturer across different models
soumya: there any standards for that?
paul: you can buy some tools that try to synthesis the varied signals more consistently
rudi: there are common denominators and been some attempts to expose more consistently
paul: you referring to the bosch project? it helps you decode the various signals, i haven't used it though
rudi: no, I'll look for the name of it
<rstreif> http://openxcplatform.com/
kevin: it is a big piece of
work
... an oem cannot just expose signals
<Zakim> kaz, you wanted to confirm "Off vehicle clients" could be include smartphones of the driver within the car
kaz: I was wondering if your off vehicle client could include the driver's phone?
paul: yes
kaz: they would be firewalled from the vehicle
kevin: yes
kaz: including bluetooth connections and the phone can then combine with internet information
kevin: off vehicle can be any one of a number of things, including other vehicles or anything connected to the internet
Bart van Leeuwen http://netage.nl/en/ - useful contact for emergency service interests and use cases - he is an emergency responder and software engineer involved in w3c
ted: i would recommend oem portal does poll & pull of updates instead of push as is generally more secure. i think a portable user profile that span different manufacturers is more useful for the consumer, handle borrowing or renting cars, mixed corporate fleets etc.
kevin: @@external and profile
powell: you need to be concerned during the http handshake but once wss socket is established it should be safe
<Paul> Vehicle Spy - http://www.intrepidcs.com/VehicleSpy/index.html Vector - http://vector.com/vi_can_solutions_en.html Busmaster - https://rbei-etas.github.io/busmaster/ OpenXC - http://openxcplatform.com/
[JLR video]
wonsuk: can you elaborate on the type of application is your 'web runtime'?
kevin: it is a browser but
supresses address bar and can only run selected apps from a
homepage
... it will be a managed environment
wonsuk: will you be creating apps for the phone as well that resembles an application and not a browser?
kevin: yes, we have some already
from JLR
... there is code in the downloaded app to act as an authorized
external device that can be used as an touchscreen for the head
unit
wonsuk: do you presently have a web runtime in your vehicles?
kevin: we have a supplier that provides a web runtime
paul: you see this model used elsewhere like checkin kiosks at the airport
wonsuk: role of web runtime is to
provide a more secure environment potentially with access to
additional privileged apis
... you mentioned security tokens to access different
modules
... will an app need to use different tokens to access
different modules?
kevin: you don't have to but will want to if that is being shared with different [external] services
soumya: @@2
wonsuk: have you looked at FIDO?
kevin: there are a number of
interesting mechanisms, more on the way, for increasing
security including hardware models
... it is an evolving area
... some things, like entertainment, are not as critical
... but anything coming from off vehicle is a possible attack
vector
<Soumya> Ted - my question was on provisioning the security keys
[attempt to get a understanding of webidl, websocket or both]
rudi describes the francaidl (genivi) would be used by the websocket server to communicate to the underlying vehicle and there is a clear benefit to web app developer to have the higher level api
[in the case of genivi as more francaidl that want to be exposed, they would only need to follow the coupling in websockets layer]
how we might want to do the REST https://github.com/OAI/OpenAPI-Specification
different developer audiences (lower level C++ automotive and web developer) but it would be worth seeing if franca generated js is viable as the higher level js api
RESOLUTION:
We'll do both the WebIDL-based API and the Websocket-based API
... work with Genivi for VSS to align with the W3C Vehicle API
... FrancaIDL is used for system level API by Genivi
<kaz> [ Lunch ]
<inserted> scribenick: kaz
volker: [ Agenda ]
... EU Green Vehicles Project
... Project IBM Research an Energy Producer EKZ
... EU Green Vehicle Project "NeMo"
... Requirements for EV In-Vehicle Data Access
... [ The "Green eMotion" Project
... [ What are the end-user's requirements about
electromobility services? ]
... charge EV anywhere; only one bill; finding charging points
from any station provider; intelligent and smart at any station
provider; park&ride
... [ The Green eMotion Project Consortium ]
... industries, utilities, EV manufacturers, Municipalities,
Research Institutes
... [ Who are the stakeholders around electromobility? ]
... EVSE, Utility, EVSP, IT Provider - End User
... [ Operating EVs with many stakeholders is becoming very
complex, costly and impractical
... quite complicated data flow
... [ Green eMotion Building Blocks ]
... Municipalities/Government: Policies, Legislation,
Standards
... EVSP: EVSP Backend
... MP Provider: Clearing House, EVSE Search, Marketplace
... OEM/Fleet Operator: EVMS
... APIs between MP Provider and OEM
... [ Mass market adoption of EVs is enabled by a B2B
Marketplace that will interconnect all stakeholders... ]
... [ Motivation for EV Smart Charging ]
... nice to get charge plan loaded automaticall into my
EV
... [ Pilot architecture for ubiquitous smart=charging of EVs -
2014-2015 ]
... information automatically downloaded into the car
... prototype implementation
... [ European Union Call for Green Vehicle GV8 extends IBM
contribution from EU Project "Green eMotion" towards transport
and smart grid integration and services ]
... interaction with ICT platform
... [ IBM has demonstrated "Open Marketplace" ICT solution
which allows new innovative business services... ]
... [ Information and Communication Technology (ICT) plays ...
]
... [ Source: NeMo Proposal, chapter 1, figure 2 ]
... this project is about to start
... lasts for 3 years
... [ Nemo environment interconnect all stakeholders ICT
systems... ]
... only one marketplace
... also network of e-mobility
... [ Initial Draft of EV Data Requirements for In-Vehicle Data
Access ]
... Table of "Draft by Robert Sharpe & Volker Fricke"
... Table of "C-ITS EU Platform Workgroup..."
... this is our first input
... data needed for EVs
... don't see OEMs want to have standard framework for
EVs
... so would propose Web-layer framework
... will send the PDF to the group
paul: questions?
wonsuk: did you see the W3C Vehicle Data spec?
volker: quickly skimmed
wonsuk: already some
overlaps
... we need to add requirements from this work to the Vehicle
Data
paul: there was some background discussion as well
wonsuk: we should create a new GitHub issue for this topic
peter: there was already some issue, wasn't it?
paul: something, but we should add another issue for EVs
volker: yellow part of the table
on the right side is partly available
... Daimlar, VW, BMW who participate in C-ITS
ted: can we talk with C-ITS guys?
<ted> (get review of spec addition of ev attributes)
volker: we had this initial idea
from some of the vendors
... not mandated
wonsuk: there are some mismatching between this work and our vehicle data
<ted> Missing electric vehicle functionality
paul: suggests you and Robert work on that
volker: it's not a
standardization body but a EU working group
... on the ISO level, we have Web service I/F
... mandated by European Commission, so European car
manufactures have to do
paul: can you send information on
tesla api standards, Robert?
... you could post the information
robert: of course
... will send it
... the other thing is
... any motivation...
(lost connection?)
paul: he created a group, and send a link
hira: question
... sometimes EVs act as a power supply
... but don't see that feature in the list here
... switching time/voltage, etc.
... were your taking about that point within C-ITS?
volker: no
... so far manufacturers think about just storing electricity
and use it for vehicle itself
... Mitsubishi Motors is interested in using electricity for
other purposes
ted: safely reuse the electricity?
volker: yes
... feeding electric power to the home
... we IBM have some project on energy management
... use EVs as electric power buffer
... only Mitsubishi provides that capability
hira: Toyota may also
ted: I have seen Prius where I live as a generator when there is a power outage from storms
paul: looking at the Google spreadsheet above
Robert: there are commercial
entities
... this is a remote API
kevin: promote competition
... there are a number benefits
<paul> https://www.linkedin.com/groups/8469823
volker: some proposal :)
paul: if we have a standard, would be beneficial to reduce the cost
robert: have to talk within the company
volker: this kind of position paper would be useful to convince OEMs
kevin: JLR is very keen on opensource
volker: this work is done to convince OEMs
kevin: OEMs take care of user information
kaz: wanted to suggest we talk with JP OEMs and ask them for opinions on EV features
robert: It is probably better to set standard then let manufcaturers follow
soumya: working on discovery,
etc., for Web of Things topic
... would present to highlight what is the role of W3C in the
WoT space
... also how WoT could be useful for the automotive
industry
... [ Internet of Things - Landscape ]
... various industries
... [ IoT Challenges ]
... everybody has to implement their platform
... wide range of technologies
... vertical domains
... uniform data representation and processing
... [ Web of Things ]
... open markups
... [ Web of Things - Motivation ]
... WoT concept is becoming more popular
... web standards to interconnect devices
... open, flexible, scalable and interoperable
... [ Problem to be addressed ]
... Fragmentation in IoT platforms and technologies
... High cost of integration into an existing solution
... Barriers for semantic interoperability
... [ How to Solve ]
... many ways to solve the issues
... open standards for Web-based abstraction layer
... [ WoT - Clean Separation of Concerns ]
... application developer (WoT focus): Application,
Things
... platform developer (IoT focus): Transfer, Transport,
Network
... [ W3C WoT Interest Group ]
... workshop in Berlin (June 2014)
... launched IG in 2015
... 4 technical TFs and Communication TF
... WG charter is under preparation
... [ W3C WoT Interest Group (cont.) ]
... Strong emphasis on practical implementation -
Plugfest
... interoperability and understanding
... compiled document on current practices
-> http://w3c.github.io/wot/current-practices/wot-practices.html current practice doc
scribe: [ Thing Description and
Metadata ]
... what kind of data do you serve?
... how can I access the data?
... [ Thing Description Overview ]
... the Thing Description TF working on three objectives
... 1. minimal vocabulary
... 2. extension for domain-specific context
... 3. resource description
... current working odel: semantic metadata, resources,
communication, @@@
... [ Scripting APIs and Binding to Protocols ]
... discussing the guideline for the possible scripting
APIs
... [ Scripting APIs for WoT ]
... possible model
... WoT Client API: discover things, access things, considering
Thing Description
... [ Resource Discovery ]
... discover Things and their Metadata
... 6 mechanisms: search around ME, search on a network, search
in a directory, search across peers, search for metadata,
search using semantics
... [ Provisioning ]
... includes several aspects
... [ Security, Privacy and Resilience ]
... also work on security, privacy and resilience
... [ Communications and collaboration ]
... reaching out to industry alliances and SDOs
... [ Deliverables ]
... Current practices:
http://w3c.github.io/wot/current-practices/wot-practices.html
... Architecture:
w3c.github.io/wot/architecture/wot-architecture.html
... Use Cases and Requirements: http://w3c.github.io/wot/wot-ucr.html
... Survey of current tech landscape: https://w3c.github.io/wot/landscape.html
... will send the slides to the group
... tomorrow I'll have another presentation on Eurecom's
automotive work and demo video
hira: what is the
scope/definition of WoT?
... Web browser for IoT?
soumya: Web standards for
IoT
... so many physical things
... they can communicate with each other and expose capability
using the Web standards
hira: many
companies/organizations have developed protocols for IoT
... wondering about the relationship between W3C and those
orgs
soumya: a lot participation from
the industry
... e.g., Fujitsu and Panasonic
... this is the list of participants
... (shows "Members of the Web of Things Interest Group")
hira: discrimination on the role of other SDOs
soumya: we can put WoT on the top of their own approaches
kaz: Soumya explained WoT as the background for his talk on "Web of Things for Connected Vehicles" tomorrow
(discussion on the agenda)
paul: can show you what we do
peter: have some codes
paul: maybe Urata-san as well
<ted> scribenick: ted
<kaz> [ afternoon break ]
<Soumya> * soumya thanks kaz for his explanation on WoT
<PowellKinney> https://github.com/pkinney/w3cag-simple-server
<PowellKinney> Caveat: just threw this together this morning, so may not be the prettiest, most idiomatic implementation
powell: quick prototype based on
this morning session
... here is a server with a data backend. vinli has a socket
server
... this is pure js using jquery in nodejs
... start off with storage, open port, wait for connection,
examine message type - get/set/subscribe
... on subscribe we set a listener to the store. when it is
updated we send back the json
... looking at whether to sub/unsub by path
... finally when the client disconnects there is a garbage
collection
... the local data store is just a big hash
... vinli has some similarities in its model
... i have a dummy account that does routing information
... on the screen you can see the data being streamed
... that is the data being fed
... bottom half you see the web methods (request log)
... in this front end mockup you can subscribe or get, see the
data coming through, unsubscribe after
... websockets are easy to work with, what makes it complicated
is hoops to go through
... we are going to have to look at path based subscription,
having multiple apps requesting overlapping and different
data
... having as many different examples of this as possible
... i want to turn this into a mocha script so we can
validate
... feel free to play with it, there is a docker container if
you want to run it that way
... now showing the frontend side code
... there is a bit of awkwardness and would be nice to have a
higher level api (as discussed this morning)
... at some point in time i expect a value back
peter: what do you mean when you
subscribe to vehicle.door?
... does that return the json for the door or changes to door
data?
powell: you may want to subscribe
to everything available from the front right door
... and see all individual messages underneath, open, lock,
close messages
... you will get the same messages if you subscribe higher up
in the tree
... rabbitmq has a good model and pattern
... when we get some kind of model i would like to have some
sort of drop down and work on the visualization
... ask for the model available and traverse it
paul: what is the protocol on websockets here?
powell: this is just a strawman and needs to be spelled out, heartbeats and handoff are taken care of for us
paul: i can show our
(opencar/inrix) system
... it follows w3c dataset
[scrolling through attributes for an actively changing one]
paul: this is from a mazda3
wonsuk: that websocket also?
paul: yes
... the json is very similar to what you just showed
magnus: we need to be able to
share the vehicle state with off-vehicle entities
... there is no standards that fully fit the bill, w3c's is
close
... one format does not suit all
... vss is standardizing signals information under genivi
banner
... we are keeping it simple and evolving quickly, lightweight
mailing list and pull request process to add new signals
data
... we hope to be the feed data signals to w3c and other
organizations
... signals is standard tree structure, branches and
signals
[sample body.mirrors.left.heated...]
magnus: we are currently
scrubbing internal documents to make available
... volvo (at least) is interested in the same thing
... branches have descriptions. signal is an attribute with
unit, type, min, max
... if a subsignal is updated the entire branch gets sent
... yaml does not have an include directive but #comments
work
... we can include the same subspec for door for example. you
can have door or upstream the entire body
... if the door vspec is later added we can regenerate and
updated files will have it
... even if you have proprietary signal information you can
include that vehicle specific information easily
[sample has anti-gravity and teleportation as example :) ]
magnus: if someone is using an electric vehicle and they want to standardize their model we can accept as a pull request
ted: we had that earlier (possible ev contributions) today from volker and robert
magnus: it is one line of code to
generate the json, francaIDL, markdown documentation and we are
open to new target generations
... parser is open, again submit a pull request
... pull requests prompt mailing list thread discussion. if no
objection and backwards compatible a new version is
released
[demo]
magnus: i took the latest
version, run make on the yaml files and here is the json
produced
... we still need to agree on how to name doors, presently
using 0 based index
ted: when you gave some of us a tour before i thought you mentioned overriding index labels eg door 0 to front left
magnus: yes, you can do so in
your proprietary vspec
... you can weigh your values
kaz: so you can override branches?
magnus: yes, supported but not implemented
kaz: i say this because we were looking at a picture of Veyron earlier
magnus: yes, different number of
cylinders
... this is just a naming scheme
<kaz> fyi: https://en.wikipedia.org/wiki/Bugatti_Veyron
[we need to stop talking about cars none of us can afford :) ]
[unless they want us to help with testing...]
powell: no access layers?
magnus: no, this is on
vehicle
... question is can this be mapped (or integrated) into w3c
standard and wrapped with an api
powell: what about signal frequency?
magnus: yes but implementation specific, frequency varies by signal and bus
[i think i heard top practical signal speed of 10ms - can someone confirm?]
paul: we have a big flat table of
these things, you build a profile of what you want
... you name the signals you want
... a debate here is flat vs hierarchical?
... what happens when an attribute falls into multiple
branches?
powell: aliasing?
magnus: yes
... that is going to be a lovely argument and different oem
will have different structures
... we are going to put out an initial proposal and not going
to be religious about it
... are you proposing aliases or?
paul: just asking
magnus: your speed signal example belongs under transmission imho
powell: you might just get speed not wheel speed and not know where it came from
magnus: it can even be gps derived
paul: maybe you are sending data
offboard for product development and want all three different
speeds
... an app developer just wants one value
magnus: in that case it probably
will be in three branches and you want to decide which you want
or we present a generic one
... i don't have answers but you are asking the right questions
:)
powell: you will want to know which you can read, write or if you cannot read it that it exists
paul: when you subscribe to a
value and get a string or id, the upper level api will likely
pass the full string but you may want to map to an id
... that would be useful for many
magnus: we want a library that injests this spec, can traverse the tree and let you know what is actually available on the vehicle to subscribe to
[that would be extremely useful to app developers]
powell: whatever is published right now is what we assuming
<Zakim> kaz, you wanted to ask if signal freq depends on the class/type of vehicle
paul: you'll need to know a bit
about what you are looking for
... JLR (Paul Wheller) and others did an exercise where they
looked at earlier data spec and what they could expose
magnus: we are not sure yet how
apps in the head unit will use this data
... it is not going to be a dump of signals but i want a low
barrier for being able to share them
paul: you would hope for hmi you can expect these common set of signals
powell: can we have a baseline?
ted: no unfortunately, eg in some cases oem do not have licensing rights to some ecu signals to give to hmi
paul time check and ota on agenda
magnus: next step is to integrate from existing w3c vehicle spec
kaz: we might want to have a spreadsheet with two columns, 1 for VSS another for W3C Data spec like the following.
joonhyung: it would be nice if genivi and w3c developers were using the same
paul: that is a possibility but would impact whoever has started implementing
shinjiro: we knew we were using an early spec
paul: precision and floating
points in js might be an issue
... you cannot control precision at the source
magnus: you may also want an average and lower frequency
ted: interest in ditching data spec instead of mapping, adopting vss adding ev and work on ipr concerns (nil?) between orgs and w3c snapshotting or doing external references to snapshots. this is genivi specific and a very open submission process but concerned people may come to w3c with proposals/objections - will want to avoid forking/conflict resolution
magnus: feel free to fork
ted hopes we don't need to but yeah that was what we thought might be the outcome
paul: we had pushback earlier. i would argue with them heavily on differences to eg tree structure
ted: people who show up late have less of an argument
paul: plus you have an override
mechanism
... i can see arguments from auto side on diagnostics
magnus: there will be some that
will want it changed to suit their existing architectures
... we might get people coming out of the woodwork with their
counter proposals
paul: almost a good problem to have
magnus: we are trying to abstract this as much as possible
shinjiro: i am concerned about
the timeline/roadmap
... we are suppose to be shipping this rather soon...
ted: no problem
... actually we have rechartering on agneda for tomorrow
shinjiro: we will need two reference implementations for lower and higher level apis?
ted: we will likely split the specs and can move separately
shinjiro: also test suite
kaz: yeah. two test suites should be also generated separately
jerry: for creating vheicles we have vin as identifier
PUT /vehicles/:vin/...
<kaz> GENIVI SOTA project
jerry: component path returns
list of all the components that are on that vehicle
... and how you get the underlying part number
... same thing with [software] package
... packages are distinguished by name and version
... includes vendor and description
... version is major.minor
... to associate a package as installed you use PUT
... you can PUT many packages on the system
... where that is interesting is with GET /filters which takes
a unique name and expression
... expression is string with regex, AND or OR logic...
[see link to filter syntax within the doc]
jerry: you can do a POST
/validate/[filter]
... GET /resolve/:name/:version is useful for knowing what is
currently installed and need to be updated
... POST /updates
... resolve comes up with vins that will be affected
paul: this is the sota server
side, this is a web server api
... what is the core api?
jerry: for the oem to provision the vehicle and initiate upgrades
rudi: rvi doesn't know the
vehicle IP address
... sota runs on top of rvi
<paul> http://pdxostc.github.io/rvi_sota_server
[sota client is on the vehicle, sota server is backend]
<kaz> SOTA Architecture
<paul> http://pdxostc.github.io/rvi_sota_server/dev/architecture.html
volker: are these packages signed?
rudi: another piece of infrastructure handles package management and checks keys etc
wonsuk: can you describe the usual process? the vehicle sota client checks with the server need to update
jerry: i have been going through
the admin and oem interfaces
... rvi is json rpc not rest
rudi: sota server is run by oem
and initiates a software update campaign
... what happens next is the campaign goes out to resolver to
know which vehicles it applies to
... legacy parts management system figures out the components
(ecu) dependencies
... there is a mix of hardware and software dependencies
... server figures all this out, comes up with list of vehicles
affected
... the core server schedules the campaign telling the client
(vehicle) the package is available not sending the actual
package
... client acks it receives update notification, potentially
alerting the owner that there are pending software updates.
there may be policies about when the notices and updates take
place, eg not while going 100mph on the hiway
... user can accept or decline some types of updates, security
and critical ones may not even be sent to the user but required
by policy
... client will tell server when it it ready for the software
update
... chunking it up and sending over rvi (logical protocol)
which does address resolution
... rvi on the client side lets the server know where it is
(how it is available to connect)
... this is different than debian or rpm packages, squashfs and
can carry out various different types of operations
... it doesn't just update the packages on the head unit itself
but can relay onto the vehicle network to underlying ecu
paul: where do we think this should go within w3c?
rudi: that is a good
question
... not sure how this conversation initially started
paul: john cain from arynga
reached out to us probably based on this work
... what i am trying to ascertain is how we fit in. you already
did all the work and this makes sense
rudi: agree, this is like amazon trying to standardize their ec2 cloud services
paul: if there are multiple implementations and you want to get people involved
volker: this is also a topic for iot
jerry: what we would like to do is approach different oem to adopt this for their fleet management
paul: the left side presumably (sota server in diagram)
jerry: exactly so genivi based client systems
wonsuk: who would maintain the packages
rudi: oems (or designated
operator)
... the package is a squashfs image that contains the manifest
and installable components
ted: @@on genivi+rvi vs eg qnx.
rudi: yes, it might want to wait based on quality of carrier signal to wait until a better wifi upstream is available
paul: this is a great starting
point and makes it easy for us to get our heads around it
... we have one implementation, if someone else is likely to
implement then we have a recommended candidate
... the big challenge is who that other person will be
rudi: standardization has great
benefits for certain economies of scale and that is clear with
vehicle signals
... it is more limited (focused) in this case
paul: you (volker) bring up a
good point that this is useful for iot as well
... soumya... we're talking to you and kaz...
rudi: OMA and Samsung
paul: and we are talking with Samsung tomorrow who is in w3c
rudi explains some of the other non-ota use cases of rvi like sending an unlock door signal to a given vehicle vin with certificates and tokens to proove it is allowed to unlock xyz
ted: will this be the only way to do updates including to the ivi os?
rudi: you can handle os updates with debian/rpm
paul: this resembles iot/wot provisioning and updating?
soumya: i'm listening
... maybe the server side yes
paul: client can be any piece
volker: is the device management work taking place at OMA relevant?
rudi: we are looking at that,
vehicle is not a single thing and it does not fit that
well
... those that see cars as a smartphone on wheels
oversimplifies and doesn't understand how it is a complex
distributed computing system
paul: joel hoffman approached us
(paul, philipp, ted) about how to make oma more relevant in
automotive
... there seems to be a very urgent timeline for rvi
rudi: yes, we want to have wider
adoption of rvi
... it handles 3 macro use cases ota, big data and vehicle
interaction and status information from external devices
(smartphone and other)
paul: to me those use cases could
fall into the BG
... like ted said unless there are additional parties
interested (outside of genivi) we will just slow you down
... also you may want to talk with WoT folks more on the
discovery and provisioning
rudi: agree standards alone don't
work and you need implementations to proove their work
... people look at the specification and wonder if they have to
implement it all themselves or if there is something tangible
they can use
ted: all three of your macro use
cases and waiting for better (alternate) connectivity are
pertinent to WoT as well
... without requiring you to wait or refactor it might be
something they want to examine and then find what to generalize
at a more abstract layer
paul: the BG is designed to explore potential work so this is in scope
wonsuk: i think there is clear we
want to pursue this further
... i will investigate more
qing_an: we can set up a different task force
like media tuner
... i need to check internally what alibaba is doing
wonsuk will reach out to samsung
Soumya you and Kaz will check if WoT people want to look at this too