Introduction

<abramski> hello all!

<sam> hi

<Tsuguo_Nobe> Hi all

<tripzero> hi

<Hirabayashi> OK

<bgidon> Adam's introduction

Adam's slides

<bgidon> Practical items

<bgidon> IRC usage

<bgidon> Scribing volunteers

<bgidon> We need volunteers to scribe sections

<bgidon> Agenda review by Adam

<bgidon> Intros

<bgidon> Public VS Private

<bgidon> Vehicle Data Web API Specs

<bgidon> Scope of Spec

<bgidon> Roles and Responsibilities/Process/Organization of a Spec

<bgidon> Sample Specs

<bgidon> Next Steps

<bgidon> We need interaction between the participants

<bgidon> Introductions

<bgidon> Chair candidates: Andy Gryc (QNX), Adam Abramski (Intel)

<bgidon> Introduction from participants

<bgidon> Adam Abramski

<bgidon> Strategy Analytics

<bgidon> QNX

<bgidon> Magnetti Marelli

<ph> scribe: bgidon

LG

W3C

KDDI

JERI Mr. Ito

Intel

Continental

Visteon Software Technologies

PSA

VW Research Center

BMW

<ph> max -responsible for bmw internet browser

On wednesday, W3C presentation part of the Genivi event

Adam: Business Group Status

32 companies represented, 70 people

<ph> 8th largest of 124 w3c business/community groups

scribe: 5 new Members per week
... a lot of potential development

Adam: Public vs Private subject
... Meeting AGenda
...
... Meeting minutes

Technical/Use Case conversations

scribe: Reports
... Discussion
... Potential confidential items could be introduced on a case by case

<ph> public ml archive http://lists.w3.org/Archives/Public/public-autowebplatform/

<ph> member-only ml archive https://lists.w3.org/Archives/Member/internal-autowebplatform/

discussion about private/public items resulting BG activity

potential next steps for BG spec/use cases

Collaboration with existing W3C WG or new WG to work on the BG requirements

Philipp: W3C WG API info

Adam: Charter Goals

<ph> scribe: ph

needed to be very specific with intel legal what we will work on in this group

felt that vehicle data was sth that a lot of groups were working on

knew QNX was already working on web platform exposing apis

so seemed vehicle api was right place to focus on

gives the group initial focus

my goal is to come up with common set of data that all oems are comfortable exposing to javascript api, third parties etc. using web technologies

would like to have draft spec done by end of the year

will be first success for group

but there are other topics interesting for automotive

where we want to influence other groups

e.g. voice

there are important gaps there I see

initial spec gives us credibility in those discussions

"show me the code"

can add to/change charter once vehicle api is stabilizing

andy: we also had a lot of discussion to join ... was restriction in charter important to others?

michel: interested in broader topics as well

adam: interested as well - originally had broad charter, but legal had "heartache" about not being specific enough

always had assumption we would tackle more

than vehicle data

anssi: helpful to start with stricter scope - gain confidence - then expand

seen groups loose focus when they had broad scope

marius: ok for us - there are lots of apis that have to be defined - not sure we could define these here, e.g. access to media data - could come from tv industry

anssi: start with use cases and requirements, and see if web platform already addressing or there are gaps

andy: spoke to pandora - not able to come - they feel a lot could be standardized to make their application run a lot easier among different systems

do a lot of html5 works

roger: running into more and more app developers that are simultaneously doing tv and auto - multiscreen proposition

adam: oem's very interested in bringing in that ecosystem

aldric: bg not for specs? seen a mail on that

adam: yes we can - will officially be called report

difference between bg and wg is that wgs does "final standard"

anssi: we can copy way WGs work - WGs have more process

not clear on report versus specification

needs to be clarified

should not assume a WG would rubberstamp our spec

but if we do good work probability of big changes is smaller

aldric: deployment phase in WG as well, right?

anssi: we're doing "background work" here - web speech did solid work on API in CG

see w3c process for how WGs work

adam: if we produce high quality spec no reason why oem could not implement against that spec - could become de-facto standard even if we don't make it a full standard

w3c generally doesn't do verticals

what is w3c's expectation? what is our interest? do we want to do a wg?

anssi: may be too early to tell

in tv, requirements went to other WGs

ph: very interested in getting automotive involved in W3C - separate WG or integration with other WGs

bernard (continental): what about testing? are you planning testfest?

adam: kept test suites in to be able to do them - most W3Cs don't have tests

ph: not quite - we have feature tests
...

anssi: testing is a bit different in automotive
... needs to be discussed

andy: somebody from the group needs to create a test

anssi: guys who are implementing the spec are contributing the tests

bernard (continental): sounds like functional testing

anssi: we have some automated testing tools for interfaces but functional testing needs to be looked into more carefully

kaz: would like to add another item - cooperation with other groups - TPAC in China coming up

probably this group should meet there - can hold joint meetings there

anssi: like the idea of cross-pollination

can ask for joint meetings

with other groups

Tatsuhiko: so are tests in or out?

Adam: up to the group

to this business group

Tatsuhiko: i think it's not necessary for this group

security policy, relationship with HMI guidelines is basic requirements - they need to be clarified

understand specification is needed

but generic requirements very important

scribe:

anssi: sysapps also has lot of security issues

good to collaborate with this group on that

w3c sysapps group: http://www.w3.org/2012/sysapps/

Tskguo: ... (missed)

Bernard (Continental): there is security and safety (driver distraction)

Tksguo: meant hacking into the car

Anssi: there is what regulators enforce (driver distraction) and how to expose API, whether it is trusted, signed etc.

sysapps having same issues and addressing them - not automotive specific

should share security model with sysapps

tkkguo: important to delineate .... how to make well-behaved applications - security, policy

for developers: how to make well-behaved applications

anssi: performance?

tkkguo: when to provide what information - define policy

at what speed? etc.

what can you use when parked? when driving?

context dependent

check conformance that applications are well behaved wrt these aspects

ph: that's a whole different topic

kaz: do you want to add this to the goals?

ph: sounds like a whole new spec

adam: should talk about other topics indeed

can have subteams

tsuguo: could be good to have study group on well-behaved applications

andy: maybe we can mark that clearly as optional (testing)

(break)

Vehicle Data Web API Specs

John (Ford): to introduce myself: here as individual - completed applink on friday - focussing on similar issues it seems so here to learn

QNX Vehicle Data API Presentation

Andy's slides

Andy: still working on contribution for this group we hope to have ready very soon

getting feedback from qnx car customers on our html5 product

lessons learned with qnx car 2.0

lot of js frameworks expect REST APIs

sync calls not performance optimal

solution: dual APIs (procedural and REST) and 100% async/callback apis

use JSON to get multiple values with one single call to handle high latency

must design for expansion

use enumerators

still see html5 activity in all car companies very high

roles of html5: built-in hmi, app container, mobile/car integration

accessing the cloud

interest for html5 for hmi waning

because of performance and memory use issues

also not leveraging HTML5 developers for HMI

other environments gaining traction (EB, Qt)

html5 for app development looking better, should be focus

work we're doing needs to support broader mobile development community

(eb = electrobit)

html5 for mobile integration

roger: how do you compare mylink and mirrorlink?

max: mirrorlink gives you direct screen access, mylink does not, gives you interface

ph: sounds similar to "second screen" issues

andy: in addition you have safety concerns in automotive

cordova

came out of phonegap

purchased by adobe opensourced to cordova

focussing on cross-platform html5 apps

deploying to iphone, android etc. with one click of button

if automotive wants to get in line leverage cordoba

anssi: cordoba is involved in sysapps - they also follow some DAP APIs - they are actively involved in W3C

andy: great news

good to hear they are pursuing standardization in w3c

our strategy: converging QNX car 2.1 to cordova

qnx 2.1 will eventually become part of adobe cordova

John: what does that mean?

andy: our APIs will become one of the possible deployment targets

not our code

we will remove redundant APIs if there are already cordova solutions

scribe:

(andy goes through API example)

(andy shows how enumerations are extensible)

will contribute things that are missing from cordova to w3c

anssi: there are some things that you listed that are in scope for sysapps, e.g. bluetooth

andy: will make sure they are aware of it

anssi: what are your must haves from this list?
... (missed)

andy: audioplayer, audiomixer, navigation

anything that has to do with the media

anssi: how many of those can you do get/set on?

andy: not all of them for sure - lots have procedural elements to them

cordova already provides a model and we should use that model

anssi: that model is being standardized in sysapps

andy: we have to do the work anyway since we're building a product, and we'll open it up

expect to have contribution in June

maybe earlier

then should have stable APIs and working code

would be part of 2.1

andy: said don't focus on hmi - is that ok for everyone?

anssi: yes, good direction - create third party ecosystem

Tizen Vehicle Information Web API Specification (Kevron Rees)

[Kevron's slides]

[slide1]

(contents)

[slide2] Overview

kevron: purpose

[slide3] Use cases

kevron: tachometer using HTML5

[slide4] Tachometer use case

- get() API

kevron: returns an array
... callback to actual data
... can access vehicle speed

[slide5] HVAC system

- set()

kevron: pretty basic
... air flow direction

[slide6] vehicle info from last week

[slide7] Data Types

kevron: three members
... X, Y and Z
... subset of potential pieces available

[slide8] Events

kevron: listen to get events

[slide9] Future

- Transfer from WAC-style callbacks to W3C style

<ph> planning to use dom futures

<ph> moving from WAC style to futures

[slide10] Resources

<ph> public draft spec available

- Tizen Vehicle API draft spec

- Draft WebIDL

<ph> work in progress

(kevron shows demo)

speed meter and tachometer

kevron: using websocket
... questions?

ph: publicly available?
... feedback from outside

<ph> kevron: API was published a week ago without much fanfare, no feedback yet

anssi: getting consensus slowly
... have you know performance for the retrieval?

kevron: don't have filter object
... not sure about performance constraint

anssi: question for QNX: method for history?

(Julius and Ken have joined)

(break)

GENIVI Vehicle Web API (Justin)

Justin's slides

[slide1] Who am I?

justin: self introduction

[slide2] Agenda

[slide3] Web Technologies for Automotive

justin: IVI system is the first target
... GUI framework for HMI
... accessing big data

[slide4] Use Cases for Web API for Vehicle Data

justin: 3 types
... home, installed and OEM
... home UI, HMI App framework and Middleware

[slide5] Use Cases contd.

justin: mobile app
... and market app

<thecorconian> afternoon all. john ellis from ford.

justin: insurance app

[slide 6] How to Make Standard Vehicle Web APIs

justin: characteristics of vehicle data

<jmtemmos> disagree on the "only the latest value is meaningful" statement :)

[slide 7] How to Select Data Types to Support

justin: scope of standardization
... wide variation of OEM
... two approaches
... select only common data types
... or select all the possible data types

[slide 8] How to Overcome OEM Variations

justin: APIs must be flexible

[slide 9] Overall IVI Architecture for Vehicle Data API

justin: layered architecture
... vehicle network manager
... vehicle network stack
... vehicle network driver

[slide 10] Web Vehicle API Project in GENIVI

justin: data types and APIs

[slide 11] API Description - Common Interface

(skipping)

[slide 15?] GENIVI Reference Implementation (1/4)

justin: Web Runtime and Vehicle Network Manager
... many ways to implement Web Apps
... exchanging big data

(screen shot)

justin: 3 subdirectories

ph: what's the Web runtime?
... webkit?
... mozilla?

justin: all

[slide 16] Reference (2/4)

justin: download, build/install and run

[slide17] 3/4

justin: screen shot

[slide 18] demo

s#demo#4/4#

demo

[slide 19] Conclusion

justin: how to standardize Web Vehicle API successfully?
... flexibility, generality and timing
... need to be standardized soon

anssi: what was your architecture?

justin: using Webkit

anssi: which port?

justin: Qt
... no specific dependency, though

kevron: modifying the Webkit code?

<ph> firebreath

bernard: is GENIVI willing to provide the draft spec for W3C?

justin: yes
... ready for collaboration

<ph> firebreath - http://www.firebreath.org/display/documentation/FireBreath+Home

justin: Web API is an area which need collaboration

bernard: we have three OEMs here
... you need to publish data
... which should be published?

max: not yet decided

bgidon: GENIVI is one of the W3C Members
... they can provide their spec as a Member to this BG

bernard: they need to define the use cases first

max: don't think we can cover all the data

marius: we need content developer to clarify the use cases
... on which data should be published, etc.

<ph> VW: we also need content providers in this group for use cases

adam: what kind of APIs are exposed?
... that is application specific

<ph> julius marchwicki, ford: we didn't do use cases at all, we just gave developers everything - let them come up with use cases - if we missed some, we add it in next version

<ph> John: also doing public effort plugging into bus

<ph> anssi: from browser side, use cases often important since hesitant to add APIs - expensive, has to be supported "forever"

anssi: how to combine the two approaches?

(use case-based approach and implementation-based approach)

ph: big debate on use cases
... something to think about

julius: we also have very similar mechanism

anssi: if you are a developer, what do you actually do?
... branching your code?
... if you look at the Web Platform, how to define the common ground?

julius: up to the auto makers

anssi: how do you fail if the requested data is not available?

<ph> julius, ford: need to define what happens if data is not available

<ph> anssi: understand, but as developer, won't be very happy with partially implemented apis

<ph> andy: think there is a common subset everybody can agree on

<ph> but even then, not all vehicles will be able to provide the info since e.g. they don't have suitable sensor

kevron: justin, your suggestion is the more, the better?

justin: would be more flexible

anssi: better than Java which has various JVMs

andy: multiple different ways to support
... agree we don't want to have various runtimes

anssi: nothing to prevent vendors to provide proprietary extensions

andy: could be brought back to the standard

kevin: 68% of all the Web servers are Apache
... part of the issues with Java is certification
... not sure if we could explicitly solve the issues

anssi: good background to know

bgidon: this BG has 72 participants now

(break until 5pm)

<ph> scribe: ph

Anssi on Editing W3C specs and working in W3C

andy: is this workflow as in wg?

anssi: yes

andy: is bg workflow same?

anssi: bgs are new ... suggest bg adopts same approach

andy: you mentioned tool - what is it?

anssi: there is respec and ...

up to editor to pick tool - end product is the same

john: what is difference between bg and wg?

anssi: bg's don't do standards
...

(anssi argues that use cases and requirements are important in general)

<kaz> ... 5. Evaluate the proposal

<inserted> ... 6. Write the draft spec

john: is there an auto wg?

ph: no - not yet

anssi: will know at the end

but expecting our spec will serve as input to one or more WGs

<kaz> [slide 3] Top-level Organization of a Spec

<kaz> anssi: Introduction, Conformance, Terminology, Content, Reference and Acknowledgements

<kaz> scribenick: ph

adam: good examples of W3C specs I found - web speech api - came out of community group

has been well received, and implemented by google in chrome

now a WG using that as input

another one: runtime and security model for web apps

another one: geolocation api

picked more recent ones

think about whether you are interested in being an editor or co-editor

tatsuhiko: plan is to have spec by end of this year - right?

adam: yes

for vehicle data spec

seems many of the specs that are out there are very similar as seen from QNX, Intel, Genivi presentations today

Next steps

adam: looking beyond vehicle data, what should we tackle? lots of topics were discussed at rome workshop

all presentations are available on W3C website

http://www.w3.org/2012/08/web-and-automotive/papers.html

ui constraints - driver distraction - looked at this from tizen side - using policy manager - thinking about jquery

could do one for auto

make framework adapt to when car is in motion vs. not in motion

second topic: security and safety

navigation another topic - not sure how many nav companies are interested in using web technology

roger: tesla is using google maps

hyundai wants to use google maps

audi did navtech with google earth overlayed

scribe:

???, ford: all nav companies moving in web direction

adam: geolocation spec is out there

another topic - audio policy management

roger: hybrid voice recognition at bmw with "dragon drive"

(??)

adam: TV group is using task forces

to research particular areas

max: navigation one of the main topics for next steps

(sth) not possible in geolocation

marius: should define what is a web app in a car? not sure we all know what we mean if we talk about this

anssi: we should all review the sysapps wg - think that is highly relevant - should be homework

http://www.w3.org/2012/sysapps/

runtime and security model http://www.w3.org/TR/2013/WD-runtime-20130321/

adam: if we have specific questions, we can invite them to a conference call

anssi: or via mailing list

we should all look at spec and see if this is what we need

adam: webinos has some nav functionality

max: right

adam: happy to send url to that

tsuguo: access to sensor based data related to navigation(?)

<kevron> webinos nav api: http://dev.webinos.org/specifications/draft/navigation.html

camera detecting signs

and provide to application

andy: ui constraints - very challenging area based on my experience in other standards body

hard to agree on

could come up with high level rules that have value

but tackle control issue we'd have a lot of push-back

we use jquery as well

adam: if oems are looking for toolkit, this is one lots of developers are using

andy: agree on toolkit, but hard if we want to get agreement
... another topic is multimedia handling that isn't completely covered by existing w3c standard

application packaging is another important topic

anssi: addressed in sysapps runtime

widget was previous effort

widget were just for packaging, runtime spec is broader

http://www.w3.org/TR/2013/WD-runtime-20130321/#package-format

(pointer to package format in sysapp runtime spec)

andy: should have a place where we have pointers to relevant specs

<scribe> ACTION: max to provide collection of relevant specs on wiki [recorded in http://www.w3.org/2013/04/22-auto-minutes.html#action01]

Tatsuhiko: many users want to bring smartphone into vehicle

needs app to app api

between device and IVI system

is this acceptable?

adam: yes if you are comfortable discussing it with the group

Tatsuhiko: doing mashup applications this way

adam: yes

Next f2f in Tokyo

Adam: colocated with Automotive Linux summit and LinuxCon

there is registration form, please use it

will work with Andy on agenda

might repeat some of today or do something new

meeting minutes/discuss has been captured - discussion should continue in e-mail

ph: another topic could be model-based design

am in discussion with a group of companies interested in that

Scope

Adam: what vehicle data to provide?

John, Ford: why not start with bus data already available? obdii data

(some people nodding)

data has to be there, government regulated

including format

julius, ford: based on an SAE spec

Kevin: there is a subset that is mandated?

John: stuff that's closed - can be seen, but I won't understand what it means - just electrical noise

instead, focus on set of data that is already available

don't use physical port, but do an API

anssi: can you send pointer?

ph: is obdii data interesting for apps?

john: yes - may not be the end of it all, but good place to start

suggest we start with the open data, and add to it

anssi: please send pointers to mailing list
...

Andy: do a master list of what was already proposed

(info on for obdii project http://media.ford.com/article_display.cfm?article_id=35245

scribe:

(discussion on read only and writing only)

???, ford: we definitely need use cases for "write"S apis

anssi: put them on wiki

note wiki is open to public

andy: in qnx car sensor data is read only - any time you can write, there is a separate interface which may or may not be there
...

anssi: so proposed resolution is to start with get API? any concerns?

Resolved: start with get API, do write APIs later

think we should socialize obdii idea on mailing list

john: will send details to adam

???, ford: obdii is what every automaker needs to provide by law - some car manufacturers won't publish fuel level although it's probably the most useful info to provide

anssi: please set expectation on decision you would like to see

andy: would also like to see if we can get agreement on merger of proposals that we have already

anssi: would agree with that - but need to get all proposals into open first

andy: qnx not ready yet, genivi not yet, we do have tizen and webinos
... we do have link to existing api stuff on wiki, webinos already there

adam: maybe qnx and genivi can look at differences between their specs and what is publicly available for now

<scribe> ACTION: andy to provide differences between qnx and what is publicly available [recorded in http://www.w3.org/2013/04/22-auto-minutes.html#action02]

<scribe> ACTION: justin to provide differences between genivi and what is publicly available [recorded in http://www.w3.org/2013/04/22-auto-minutes.html#action03]

adam: don't have regular call schedule yet

anssi: think we need a checkpoint

one month may be late

ph: agree that we should have another call before f2f

adam: agree, will do

current proposal for tokyo meeting is to run through same agenda items

anssi: are we expecting new proposals?

adam: not for vehicle data