<timeless> scribe: Josh_Soref

<timeless> scribenick: timeless

Greeting

Philipp: Good morning
... and welcome
... in front of you, you have a printed sheet
... unfortunately, the times on it are all wrong
... the right program is online
... as some of you may have noticed, it's hard to get online
... please use the WiFi lightly
... capacity is apparently quite limited, we're working on that
... amy is the person to talk to

Introduction

[ Technical issues w/ slide advance ]

ph: why are we here?
... the motivation
... we see the open web platform
... moving from the PC to "devices"
... mobile, television,
... and we think automotive is next
... we thought: let's do a workshop, let's get started
... let's see the needs of the automotive community from the web platform
... we started working with tv 2 years ago
... we see using web technology as a way to overcome fragmentation
... for mobile, you don't need different code for different targets
... same for TV
... cross OS, cross platform

ph: Web tech works cross devices
... you can take something from a Mobile device to a Tablet
... FT moved from Mobile to HTML5
... today you can't get a native app on the apple store, it's just html
... and they just did a Windows version, they found it easy to port HTML5
... the TV industry is interested in using HTML5 for TVs and tablets
... Web Tech: more developers, cheaper
... looking at your papers, these advantages seem to apply to automotive as well
... About W3C
... our mission is to "Lead the Web to its Full Potential"
... Directed by Web inventor Tim Berners-Lee
... Standards: HTML5, XML, SOAP, RDF, VoiceXML, ...
... Mission: "One Web": Desktop, Mobile, TV, Automotive (?)
... W3C -- C for Consortium
... Whole Web ecosystem: Browsers, IT, ...
... - ever expanding: Mobile companies, TV companies, ...

.. New Platform - New Requirements

ph: Mobile: Smaller screen size, Geolocation, device APIs
... TV: Content protection, Video streaming
... Automotive: Context awareness, Vehicle APIs, Tactile input/output, ...
... Workshop goal: complete list (of requirements) for automotive
... Workshop Working Rules
... Talks
... - 20 minutes talk
... - 10 minutes for questions
... - mix questions and talk
... Conclusion discussion at end of each day
... Agenda Day 1
... Topics

ph: - Safety, situation awareness, mitigating driver distraction
... - Multiple displays and integration with phone or tablet(s)
... - Vehicle APIs and Security
... Invited talk: Audi (OEM perspective)
... [... see agenda ]
... Agenda Day 2
... Topics
... - HMI, speech, multimodal, HUD, spatial audio,
... - Cloud-based services
... - M2M
... - Research perspectives
... [... see agenda ]

<marie> http://www.w3.org/2012/08/web-and-automotive/agenda.html

... Right Participants
... OEMs: Audi, BMW, Honda, Hyundai, Renault, Mitsubishii,, Volkswagen, Toyota
... Operators: KDDI, Vodafone, Orange/France Telecom, ...
... Workshop Goals: Technical
... Vehicle APIs
... Context management
... What is not a good idea?
... What is missing?
... Workshop Goals: Social
... Where is consensus?
... Get to know each other
... Learn from each other
... Thanks to :
... Intel for hosting the workshop
... Our sponsors: QNX and Webinos
... Our programme committee members

Announcements

ph: [Agenda needs to be updated]
... [WiFi - please use sparingly]
... Chairs: Adam and Dave

adam: Practical things
... ph talked about WiFi
... amy is the planner
... if you see her, thank her
... she said folks may be using multiple devices on WiFi
... try not to
... marie said there are people taking photos
... if you're uncomfortable, please speak to marie, adam, dsr, ph
... at 5:30pm, we had a bit of budget left, so we'll have a reception - down one floor
... maybe in preparation for a nice dinner
... My involvement with this on the W3C side
... I used to work for Sun Microsystems (now Oracle)
... I was involved in Java Community Process
... I was the product manager for J2ME when it was in its infancy
... I've done JCP, but i've never been involved with W3C
... this is a great opportunity for the automotive industry to have a voice to w3c
... what's unique about automotive
... so automotive UCs are taken care of
... this is your opportunity to tell W3C what is unique about automotive
... marie has a memory stick that we'd like to get all the presentations for this afternoon
... if you could find marie and put your presentations on that stick, it makes things much easier
... W3C would also like to put the presentations on the public web site after the workshop
... I believe it was mentioned in the invitation to the presenters

Presentations

ph: If we could switch to the first presentation
... by Audi

[ Audi connect ]

nils: Good morning
... my name is Nils Oppermann, from Audi Electronics Venture
... a 100% daughter company [of Audi]
... we're doing predevelopment
... I've been doing matlab toolchain before 2010
... embedded software driver assistance systems
... since 2010 i've been in the web world
... a feature launched last year at Audi: Online traffic information system
... a web based client which downloads web based traffic information
... larger bandwidth than radio systems
... I brought 3 colleagues
... Matthias
... Thomas
... Burkhard
... I'll give you an overview of how Audi evolved
... the goal is to integrate the digital world into the car
... so if you enter the car, you don't feel disconnected
... I'm going to talk to infotainment
... and attached devices

[ Audi connect Motivation ]

nils: We didn't know the hotel name; we had to google the location in our smart phone
... to tell the taxi driver
... The information is personalized
... in the future, the service around the web might integrate the car
... I expect the car to give me the best routes
... and locations around

[ Audi connect - Key requirements ]

nils: Usability & Safety
... driver distraction / joy of use / Daily drive
... Security & Privacy
... User data / Accounting
... Cost & Business Model
... Development / Maintenance
... Our services somehow need to be voice activated
... and deliver voice feedback
... and need to avoid driver distraction
... functions we want to do
... ... need sort of integrated apps
... a google maps/earth client
... that integrates with the entertainment system
... If Usability doesn't kill the UC, Security probably does
... User data needs to be safe+secure -- transparent to the user
... what data is used, how it is used
... the traffic information we use
... it downloads information, but also uploads anonymized information
... we authenticate our vehicles, we authenticate our users
... we will have multi user systems
... e.g. the rental car UC
... we don't want the next user to have your credentials
... Facebook accounts, etc.
... Cost / Business model, it's still unclear
... we're a really small platform
... we're competing w/ Consumer Electronics companies who launch quarterly
... we have to support devices for a long time
... the Android ecosystem has year old devices that don't get updates
... our vehicles from production - produced 7 years
... for another 7 years, we have to provide services
... at least if they have paid for that [warranty/etc.]
... last point
... to be competitive, and offer unique features
... in the vehicle-web world
... we have to rely on established technology
... the entertainment system today is built w/ similar technology as smart phones
... ARM, QNX/Linux
... high use of Java
... communicating with the outside we use W3C HTML/XML/HTTP
... APIs are a big issue
... if a service has to run for 15 years
... we have to plan and modularize our apis

[ Audi connect - General architecture ]

nils: left to right
... Vehicle client (Services, UMTS module, SIM)
... Protocol stack (XML, HTTP, TCP/IP)
... Audi Backend (Services, Authentication, App. Management, Accounting)
... Content Provider (Services, APIs)
... Today we use customer SIM card
... in the future it may be an MTM SIM
... for backend interfaces, we've used XML
... it allows for a nice way to structure interfaces
... and provides a way to do them in a tools supported way on the backend
... App. Management: which vehicle receives which version of which service
... we have to control which users receive which version of data/content apis
... we rely on third parties to provide us apis
... at a considerable cost today - because we're a small platform
... standardization will enable automotive industry to impact providers and reduce cost

[ Audi connect - Since 2010 models: 1st generation services ]

nils: Tightly coupled w/ native user interface, dependent on vehicle life-cycle
... today it's flashed, and might receive an (one) update
... You don't notice that it's web, except branding ... e.g. Google POI Voice search
... we also have browser based online services
... Audi-styled websites, unpersonalized, location-based
... everyone gets the same content
... integrated with system so you could call from the car
... Browser Look and Feel drawbacks

[ Audi connect - Today: 2st generation services ]

nils: we still do integrated online services
... tightly coupled w/ native user interface
... SMS dictation/picture destinations - in the new A3
... we use native widget screens which ... Remote-HMI - we parametrize to dynamic content
... Facebook, twitter ...

[ Audi connect - Today: 2st generation services ]

nils: Remote-HMI key facts
... dynamic use of native user interface
... native widgets, animated transitions, anchors into native HMI dialogs
... Audi MMI Touch-Wheel & Speech dialogue system integration
... we don't have a Touch screen... our friends at YY do
... Strong re-use of native user interface
... we have limited space to test
... we know how our native widgets behave regarding driver distraction
... we have ergonomics
... studies
... by reusing these for our web services we guarantee web services don't distract the driver more than a normal element
... we have an integrated web browser
... to display general web content
... embedded in remote-HMI framework
... if a detail view of a POI service
... wanted to display customer reviews
... we could still switch to an HTML browser based UI
... same language for mobile device and app integration
... built on W3C web standard SCXML
... "Why do we do this instead of HTML?"
... we describe look and feel transitions

[ this sounds like WML ]

nils: we do support html
... and once we solve the issues
... security, distraction, ...
... [we'll transition to html]

[ Audi connect - Outlook: 3rd generation services ]

nils: issues regarding mobile device support
... HTML5 support in embedded browser
... performance might be an issue
... Vehicle data abstraction (API)
... we need an api to the functionality of the infotainment system
... We're looking into JavaScript/WebGL for high performance rendering of remote content
... A service provider which implements things needs something that works over many vehicles
... even multiple manufacturers
... Our application looks 90% like a web application
... tooling is a big issue
... integrated tooling for the developer
... so he can see in short iterations what he's doing
... if the application is hosted on a smart phone/back-end system
... we need an abstraction of the platform for a developer
... to achieve time to market efficiency
... cheaper time to market/developers
... we still need to guarantee quality

[ Audi connect - Summary ]

nils: biggest issue is standardized tooling
... there's a conflict
... between up-to-date
... and roaming
... if the web content percentage increases
... we have to ensure product works where-ever user goes
... have to enable testing
... "iPhone issue"
... if you make something for "iPhone" and they change the connector
... you're left standing there
... you're left explaining to your customers why you have to use old iPhones in your latest and greatest cars
... Mobile web technologies being platform independent
... offers the opportunity to achieve this over several vehicles

Josh_Soref: Hi, I'm Josh Soref, from RIM, your scribe for today
... please introduce yourself
... and speak loudly

<marie> Let's take the opp to warmly thanks Josh for the great scribing!

[ Applause ]

ph: you said you wanted to use APIs and reduce costs
... what did you mean?

nils: it's a small platform
... we're still involved on our side
... the bottleneck is development resources
... we don't have a standardized way to develop web services
... the experiences that content providers
... once they hear a big name
... "audi is the big name of vehicles"
... content providers think they can send them big bills
... with a standardized way to develop
... we can reduce the cost
... with Android, I have 100 apps installed
... I've paid for maybe 1
... If you want Weather for your Car, you have to pay a lot
... it's a small market, maybe growing
... but compared to daily activations of Android, we're very small
... we can't afford
... we don't have the market throughput of Android/Google
... on an economic basis, we have to work out how to pay for these services+content

sakazawa: Sakazawa, KDDI
... question about interoperability
... you mentioned it's important
... how do you differentiate your service
... Head Unit can be replaced
... how do you differentiate your service/equipment?

nils: separating the concerns from application logic from UA
... which the web does using Style Sheets/similar tech
... if you do a Video based solution
... you have to make it look like your HMI
... you have to test it -- very difficult

maximilian: Maximilian, BMW
... in the latest generation, the application logic is running in the backend servers?

nils: basically, yes
... it's a web site
... for performance+security, we use very little client logic

ph: one last question

WooChul: Jung Woo Chul, Hundai
... Audi is connecting user data?
... for potential services

nils: there are predevelopment activities
... "customer is king - as we say in Germany"
... we don't want him to have security/privacy concerns
... we don't want to ruin our reputation
... for traffic, we separate the data
... the traffic system gets the data about cars in general w/o information about which
... the car gets traffic, but we don't get information about their location

WooChul: i think the OEM should know about the customers

WooChul: we could figure out which softkey is used

kaz: Kaz Ashimura, W3C
... activity lead for Multimodal WG
... interested in your slides on SCXML
... do you think there's the possibility to use the MMI architecture
... and integrate the 2nd generation Remote-HMI approach and the 3rd generation JavaScript approach?

nils:there is a possibility

HTML5 standardization in auto

andy: hello
... Andy Gryc, QNX
... Why HTML5 for the car?
... What can QNX contribute?
... Where should W3C go?

[ Consumer vs OEM lifecyle ]

andy: my colleague from Audi spoke about this
... 1 year Android life cycle.
... 7+7 for Vehicle
... this is the key thing that drives wanting to use HTML5
... if you use HTML5, you aren't reinventing the wheel
... that comes along with Quality and Process
... that niels mentioned

[ Increasing cconsumer demand ]

andy: consumers say they spent $XXXXX for a car
... they expect more from it than from their phone
... personalizing experience
... pick how the car looks
... what the car does
... how the car behaves

[ HTML5 is a natural choice ]

andy: you've got a big echosystem of devleopers, tools
... that's something car makers don't get easily
... for a car maker to traditionally
... they have to find someone, then work with them
... how the modules work together
... explain the requirements
... if the company is using the same platform, that simplifies things
... Standards is about avoiding Vendor lock in
... people say "you guys are building that, why would you want to avoid Lock in?"
... at QNX, we've been doing a lot around standards
... companies can differentiate on QoI
... our ability to support POSIX, Eclipse, ...
... HTML5 is a way to allow that interoperability
... Flexibility is something that HTML5 really provides
... in nils's example, the consumer didn't know which was native
... things coming in from mobile, cloud, embedded
... lets you deploy things differently
... not everything needs to be baked into the car when it ships
... Branding
... this is something that CSS provides
... every car maker wants to have branding
... from a developer's PoV
... without standards
... each vendor would build a different app for each manufacturer
... but CSS allows them to make one app
... Lifespan
... I expect HTML5 to be around for a long time
... Time to market... HTML5 has this, other things do too, but HTML5 really does this
... "cheap engineers", well HTML5 developers aren't all cheap
... they're using technology which provides a lot more capability built in
... which goes to Powerful
... finally, Cross-platform
... the ability to take apps from mobile and deploy them to the phone and car
... HTML5 is supported across every model of phone
... iPhone, Android, Windows, BlackBerry
... easier transition

[ What? ]

[ QNX in automotive ]

andy: a bunch of logos

[ QNX CAR 2 applicaiton platform ]

andy: BB10 software stack
... taking what we've done for PlayBook and BB10
... and then adding on what Automotive needs
... I can show this at our demo booth
... it's adding an HTML5 environment to an infotainment stack
... we're not saying you should build it with html5
... but we're saying it's powerful enough to do it
... for actual implementation
... car makers could say they'll do it with Electropic Eye
... or Qt
... But we want to show that the outside world content can be HTML5 driven

[ QNX CAR 2 feature hightlights ]

andy: a key thing to understand
... where standardization will happen in W3C
... things will be below the standardization

[ QNX CAR 2 Applications - Sample HMI Designs ]

andy: these are done in HTML5
... to show we've been able to duplicate most of the features
... using standards
... even coverflow can be done in HTML5

[ QNX CAR HTML5 framework ]

andy: HTML5 environment w/ front-end + apps
... allows entire Ui to be easily reskinned
... launcher
... We use Sencha Touch Mobile and jQuery
... a mix for widget sets
... we created our own QNX-designed infotainment skin
... App store integration
... we have designed a way to download application bundles
... and I want to talk about that

[ HTML5 app packaging ]

andy: most developers use a Text Editor
... along with the web browser and Web Inspect
... you create aspects in one place
... HTML5, CSS, JS, Images, Icons
... from packaging perspective, you need to take those objects and deploy them
... for packaging, we use a derivative of WebWorks
... it's on GitHub
... and will be contributed to Apache Cordova
... i'm not sure how much of that is Standards org or Open Source
... but if you want to bring applications between car makers, you'll need some sort of standard there
... How do you guarantee it doesn't access certain features of the vehicle you don't want it to
... how does an OEM allow the OEM to deploy certain features but not allow other apps to access them
... we have a manifest
... which is signed
... and have something which checks that
... there's some debate
... different capabilities to OEM/general dev
... this "breaks the standard"
... there will need to be some greater level of capability for OEM sanctioned apps than general apps

[ Ripple for QNX CAR ]

andy: Ripple is RIM's emulator for doing HTML5
... generally for phone
... but we've adapted this for CAR
... just like Ripple is part of GitHub
... our intent is to release [Ripple CAR] as well
... it provides the underlying pieces
... to allow you to mimic the underlying vehicle bus
... HVAC, multimedia
... enough capability to test it
... without having a car
... average developers need a way to develop
... they can't need to buy panda boards
... and custom head units
... they need a way to test their app before giving it to an OEM
... we see the OEM as a broker
... but this gives developers the way to create Apps without heavy overhead

[ QNX CAR and native access ]

andy: providing access to vehicle bus
... we think standardizing on Apple related things to W3C standard is probably not appropriate
... but allowing a way to control multimedia probably is
... but adding things underneath for Apple/DLNA

[ JavaScript access to platform services ]

andy: we have PPS, Persistent-Publish Subscribe
... in the HTML5 layer, we wrap those instances with a JS class
... which lets an app interact with those apis without caring about PPS
... you could replace PPS with DBUS and this picture would be the same
... so applications built for a car could rely on this

[ Example JavaScript components ]

andy: Framework classes
... get messages from car
... control settings / theming
... provide access (Bluetooth, Audio Player, Phone)

[ Example audioplayer methods ]

andy: setTrackSession(config, index)
... play()
... playAt(index)
... ...

andy: the Implementation from the JS side is just application Look and Feel
... no business logic, just presentation

[ Needed areas of W3C focus ]

andy: 1. Application packaging
... ability to move app develpoment across platforms
... not sure if Cordova is this
... it's an Open Source thing
... maybe packaging isn't necessarily where W3C focuses

ph: we do have something on Packaging
... it's called Widgets
... I believe Cordova is based on it
... the issue is that Browser people don't like it
... there's work on it

andy: OT: If there's an industry adopted thing
... if you created a standard
... and browser people went with JSON

ph: we have a Recommendation, it's not a standard
... we're still looking at it
... if there's more push...

andy: excellent

[ Needed areas of W3C focus ]

andy: 2. Native access APIs
... the intent of the browser is to protect the underlying system
... that gives a level of consistency for app developers
... need to allow ability to adapt to what's present

[ Needed areas of W3C focus ]

andy: 3. Mobile + car integration
... for ability to run/host on mobile and display in car
... MirrorLink / iPod out
... i think having a server on the phone
... and html application running in the car
... CCC has had proposals to go from VNC protocol to HTML5 based
... but it could be addressed by standardization

[ Needed areas of W3C focus ]

andy: 4. Distraction prevention and OEM skinning
... if you want to have an application
... unless you want to target just one OEM
... certainly OEMs want that
... but developers want to target multiple platforms
... the best way is to reskin with CSS
... need a consistent way to reskin
... mobile developers as a whole don't understand Car / Driver Distraction
... part is education
... part is addressable by providing templates
... List picking
... gives ability for OEMs to differentiate with CSS

[ Needed areas of W3C focus ]

andy: 5. App devleopment guidelines
... most developers i've spoken with
... "i've got this great idea"
... "why don't i take this video recording app and bring it in the car"
... -- yeah, i don't think that's appropriate
... Guidelines
... I see this as a Tech Note / Whitepaper
... HTML5 is opening that door a crack
... I think we should explain why we're opening that door a crack and not swinging it wide open

[ Applause ]

ph: time for one question

takahashi: Tatzaki Takahashi, Mitsubishi

takahashi: we have been trying to propose W3C widgets for OEMs
... so far, they're not welcomed
... i'd like to know your opinion about packages
... some seem to prefer online without installation

andy: that's a good question
... packaging is ... giving the car maker the flexibility to run that app embedded v. cloud
... we don't have ubiquitous coverage/guaranteed connectivity
... may be tethered, may run out of power
... bringing flexibility to bring app from cloud to running on the head unit
... that's where packaging comes in
... and also for an app store context
... if you don't want all apps to be tied to some mobile device strategy
... an app store in the car needs to deal w/ packaging
... where's the store, ...

takahashi: thank you

Next Speaker

ph: next speaker

Harman

roman: I'm Roman Steiger and my colleague is Peter Gaus, from Harman
... we deliver head units
... for a wide range of cars

roman: from high class through middle to low end cars
... handsfree phone, bluetooth, wifi
... UPnP, MirrorLink
... PIM / Calendar ... access to exchange/mail
... Contacts/Notes/Email
... w/ UMTS we have LTE demos available
... we're responsible for bringing browser tech into the car for headunits from Harman
... that's the one side of connectivity
... other side is interface to car itself
... entertainment
... comfort systems (position)
... climate control, etc.
... Harman has already introduced an IDL called "Franka"
... in the area of "Genivi"
... those interfaces in the car between car components
... it's an Open Source project

roman: it will be used in Genivi
... with those interfaces, we come to the browser side
... we played around with it

roman: how could we fit browser interfaces, maybe WebIDL with car interfaces
... what we'd like to contribute in that area
... is standardized interfaces in the browser
... to get access to the interfaces in the car/head-unit
... from that point of view

roman: it'd be essential for applications written in HTML/JS to provide such interfaces in a standardized form
... for third party applications
... or applications developed for car manufacturers
... if we have these standardized interfaces
... then it's much easier to port these applicationss
... and for these applications to control the car
... if we do this standardization as we have in Genivi
... then it's easier to get acceptance
... Harman
... it would be good to applications portable, not just to different cars, customized by style sheets
... but to get an application that does nothing else than provide functionality to control Radio/Heating
... but where does it run?
... in the car?
... i.e. in the HMI
... Where does the browser run? in the browser? in the mobile phone? in a tablet?
... standardized interface to use apps, not just in the car, but also in Android phone/Tablet
... so it'd be possible to have a remote control using the same control logic
... Look and Feel may differ, but control logic would be the same
... so, it should be possible that these interfaces
... could be satisfied by browser in different ways
... for HMI host, manufacturer provides one way
... if browser is in mobile device, how to get access to real components in car?
... a way to overload, implement as plugin/...
... a way to have access everywhere

peter: for guys in this room
... to have a way to provide feedback on interface transformation
... everyone in this room already has interface definitions
... I think it'd be good to be able to transform them into WebIDL
... as gryc said
... and we need security as niels said

roman: thank you

[ Applause ]

ph: any questions?
... and it'd be good to have a packaging mechanism
... you want to translate existing APIs to WebIDL?
... do you want to keep APIs as is? or standardize?
... two steps, find a mapping, and then standardize api?
... or go straight?

roman: both is possible
... the interfaces between car components
... may be different
... depends on OEM/head-unit
... there might be a chance to have a better standardized interface between car components than what we have now
... looking forward w/ Genivi
... I could imagine second step being first
... it'd be much easier to have standarized api for browsers
... but if we get standard api specification for browser
... we could get Adaptation layers for cars

ph: ok, interesting.
... other questions... to Harman, or general comments?

andy: one observation
... when I was talking about APIs to the car, I was talking about running in the Car
... but having the APIs be client-server
... so you could run them from user's Phone/etc.
... but security would be crucial
... another interesting application
... being able to run applications when you're nowhere near the car
... remote unlocks, check car status
... an entire class of applications you could enable
... Good

peter: we have the chance to do low level
... or existing
... or do native in browser

ph: ok

kaz: Kaz Ashimura, W3C, again
... I'd like to ask all the presenters from these sessions about Time Synchronization
... what sort of mechanism should be used?
... maybe precise time management is needed?

andy: i don't think the Time Synchronization that accompanies video playback
... I think responsiveness of the UI is a bigger consideration
... it's a latency/responsiveness issue
... not something that can be baked into a spec
... just a requirement for the Car
... maybe 250ms for the car
... up to the platform to meet that

nils: when we're talking about UI today
... we don't have Time Synchronization today
... it's best effort
... architecture is Event based
... based on middleware
... system native components, there are timing constraints
... but we're talking about non native components
... timing isn't our biggest issue

ph: ok
... let's thank all speakers

[ Applause ]

ph: Break until 11:30am
... demos over there, coffee outside

marie: you're welcome to get one of these workshop goodies
... a safety jacket
... in europe, it's mandatory to have one of these in your car
... since this workshop is about safety
... here's a safety jacket

Safety situational awareness / driver distraction

dsr: before I start, we apologize about the networking
... if you're using WiFi on your phone, please turn it off
... if you really need a network, we have a small number of cables
... talk to the people outside
... let's start with the people from ACCESS

marcin: Marcin Hanclik, ACCESS
... we specialize in Browser+ DNLA solutions

marcin: from the standardization perspective
... I take part in W3 and other SDOs

[ Agenda ]

marcin: Trends and Scenarios (Connectivity, Remote access)
... HaaP -- the Apps (nBox, REST API + JS Lib v JS APIs, Integration
... Demonstration

[ Trends of IVI platform evolution ]

marcin: we install application on Mobile phone
... able to access IVI
... e.g. using MirrorLink
... use smart phone for communication/commands

[ The standards ]

marcin: W3C, CEA, UPnP, DLNA
... Vehicle API as part of Device APIs
... - Mobile: OMTP BONDI, WAC, GSMA, Webinos
... - W3C: DAP, SysApps
... - Ca. 6 attempts to standardize Calendar API
... many people want to contribute to w3c
... but standards exist
... we introduced topic of apis
... take another example ... a device API
... I participated in OMTP BONDI
... there was a standard defined for Calendar
... it was brought to W3C for standardization
... people said "we can do this differently"
... it was brought to WAC, and GSMA
... it was brought to Webinos
... it's part of 2 w3c WGs
... Device APIs and System APIs
... no standard today after 3-4 years of standardization
... it's not a technical problem
... it's a NIH (Not Invented Here) problem
... this is a work of standardization
... for TV
... everyone ended up in Web and TV IG
... this body can only make Notes
... work has to be sent to WG
... W3C works under FRAND principles
... everything is royalty free

[ Connectivity: UPnP ]

marcin: we have Terminal Mode
... from MirrorLink
... it isn't an open standard

[ Remote UI - Remote access ]

marcin: a car, or a device in a car becomes another gadget
... UPnP defines a network
... you can access your resources from home
... or your car/whichever way
... W3C has a draft specification of Network Discovery (Opera)
... to let devices discover each other
... we have competing standards for discoverability
... we have CA 2014
... we have Web Intents

[ HTML5 as a platform ]

marcin: we'd like to discuss HTML5 as a Platform (HaaP)
... for some, HTML5 is <video>
... for some, HTML5 is (CSS)box-shadow:
... some want a collection
... which is the highest value

[ HaaP - why? ]

marcin: one of the solutions is to
... create web applications using HTML5/CSS/JS to share application between multiple devices
... we have multiple devices in a car
... and need a way to interact between them

[ nBox - the framework ]

marcin: we have the need to access the car
... from inside
... and also from outside
... we need a bridge from car to mechanics
... this is the platform

[ nBox goals ]

marcin: it's important this is Cross-Browser
... purely browser based solution may not be a good solution
... it's better that it be a separate module
... nBox is an embedded web server
... it generates HTML documents for the UI
... or JSON data
... extensibility
... we're pushed by marketing guys
... to be better than the competition
... it must be extensible
... must be part of the framework

[ REST APIs v. JS APIs ]

marcin: Application management
... Install, Uninstall, Get+Install Apps

[ Applications and Services ]

marcin: we distinguish between applications and services
... applications have a UI
... services provide functionality
... here, what's the API?
... is it JS?
... is it REST?

[ Integration models ]

marcin: Embedded; Separated

[ Demonstration ]

marcin: Connect IVI and Smartphone
... Operate IVI menu from smartphone
... Install an application
... -- important that you can take a mobile phone and play a game in the IVI

[ Demonstration ]

marcin: this is what we'll demo
... start the video

[ Video ]

marcin: this is the potential ivi screen
... here we have a mobile device

[ Firefox Mobile ]

marcin: similar solution to web intents
... need user's consent to access service
... here we can control IVI via remote terminal
... protocol is XHR+WebSockets

[ User is driving IVI w/ browser on phone ]

marcin: there's no feeling of network latency

dsr: is this going through a local server
... or cloud?

marcin: this is two browsers connected via nBox
... that's it

[ Applause ]

dsr: questions?

woochul: are you using graphics acceleration?

marcin: yes, but it's part of the display
... we have WebGL/CSS transformations
... but the information sent between devices is just commands

woochul: so nothing special?

marcin: no

dsr: you told us about the difficulties in the mobile world of Calendar APIs
... what advice for Automotive?

marcin: gather as many people as possible
... adopt the work done by others
... maybe tune it

Josh_Soref: WebGL from Khronos is a good example of a disaster
... they just ported the C api and called it JS
... which causes incredible pain for Browser vendors
... it violates models

marcin: there were other 3D proposals
... we just need to adopt something and use it
... WebGL it's used on all devices?

Josh_Soref: it skipped the standards process

dsr: who we need to involve to have effective standards
... thank you

[ Applause ]

Web and Automotive Shopping List

[ Authors Profile ]

magnus: Magnus Olsson, Ericsson

[ Web and Automotive ]

magnus: Introduction (Bare bones architecture, Leverage Open Web Platform)

[ Bare bones architecture ]

magnus: people are fairly familiar w/ the web stack already
... I don't see that problem
... you understand those challenges
... challenge to go to an extensible framework
.. APIs could come from multiple sources
... not just the car, but also phones
... the QNX/ACCESS presentations
... could be useful for everyone

[ Leverage the Open Web Platform ]

magnus: no one has mentioned that already
... the W3C maintains a web stack
... what belongs in the web stack
... at a point in time
... we need to keep fragmentation at a minimum
... we need a number of administrative features
... Configurability, Capability, Upgradeability
... - w3c doesn't necessarily need to develop these, but they need to be there
... Connectivity, HTTP/WebSockets
... - Wire/Bluetooth/WiFi/Cellular
... this needs to be abstracted
... creating APIs that don't care about underlying medias
... Responsive User Interface
... manufacturer brand+style sheet
... to look like Audi/BMW
... but from a developer PoV
... you don't necessarily need every pixel well designed
... Responsive UI is good, you focus on the data
... developer doesn't care about L&F...
... they care about data
... UI some screens are bigger, some smaller
... you don't need to focus on every pixel
... we can use 3D transitions
... physical controls / abstract events
... car manufacturers are used to building these
... if those controls could be mapped back to the web in a good way
... to control more than just volume level
... Future Proof
... there needs to be a business model
... but if players could reach a level field ecosystem, we could then grow the ecosystem

[ Challenges ]

magnus: a multiverse of ecosystems

[ Connected Eco Systems]

magnus: Service Delivery Aspects introduced to various vehicles
... Walled Gardenn; App Stores; Bundled Service; Cloud Services; Connected Industries
... Facebook was mentioned
... how could you leverage that in automotive space as well?
... Existing App Stores could be attached to the car app store
... Map and Navigation
... - easy to charge for

[ Sensors want to be heard ]

magnus: automotive, you have a lot of sensors
... you could create great applications with them
... Challenges
... sharing data, possibly anonymized
... so developers could build crowd sourced applications based on data from cars

[ User in the driver's seat ]

magnus: Privacy
... Avoid intrusive behavior
... ability to get logging
... roaming
... - important to Ericsson
... roaming is preventing a lot of UCs
... if we could produce things which don't use much data
... aggregating Push traffic

andy: on End User Auditing
... do you see that as something
... that is an actual User Concern
... or a Required for B2B
... or Fleet operations
... or Accessibility
... or ?

magnus: for end users
... to know what features are activated
... how much data is being used
... Fleets already have that data in the cloud
... this is more end user perspective

[ Developer Proposition ]

magnus: Enable as many APIs/Sensors as possible with good quality
... Consider safe mash-up techniques
... Web Intents/
... Keep cost and overhead (time) down
... based on experience in WAC community
... you need to be engaged in Genivi
... you have on your agenda to make things effortless
... Separate roles of application provider, security provider and payment provider
... it could be a benefit, it isn't so easy to do
... avoid discrimination of OS platforms
... If we can design solutions
... based on HTTP Clients
... we don't close solutions to specific platforms

[ W3C Innovative ideas ]

magnus: we had a Plenary (TPAC) two weeks ago in Lyon

magnus: Indie UI and Pointer Events
... if that could be controlled around the car
... how can you describe a control system in a way that a web app can understand
... since you don't have a keyboard
... Challenge of automated testing
... there's a project in W3C called Web Driver
... for testing
... so you can do automated testing using JS
... and I mentioned Web Activities/Intents

[ Ample power, comfy seats ]

[ Cool use case, Web HUD ]

magnus: a number of concepts in W3C
... Service Discovery - Web Intents
... I haven't implemented yet
... how a Web HUD could look
... abstracting controls could be real interesting
... Interesting things - Google Glasses

[ Use case - Social Fleet ]

magnus: it's important
... it highlights UCs
... don't limit to UCs where web app is running in the car
... have a way to send data to the cloud
... for crowd sourced data
... requires car to be somewhat connected
... over time, that will be the case

[ Use case - Zombie drive ]

magnus: developers could come up w/ interesting uses

[ Conclusions and Q&A ]

magnus: lots of sensors in automotive
... if we can reach a point where that data can be shared in a safe way
... that will be important
... it will take time
... personal integrity must be in front of our mind
... re-cycle the open web platform
... think about other roles
... Connect with other ecosystems

dsr: questions?
... you talk about apps going across multiple screens
... what's needed for developers?
... hooking into the cloud
... what might we want to explore there?

magnus: you could envision one browser per screen
... smaller devices have an extra screen
... in that, you have a JS api
... depends on the size of the ui
... just need a way to discover that display
... need a manifest

dsr: thanks

[ Applause ]

dsr: last talk of the session

Gemalto - How can web apps EEE

pierre: Hi, I'm Pierre Girard from Gemalto

[ Agenda ]

[ Gemalto at a glance ]

pierre: 50 government programs and customers
... identity card, electronic passports, drivers licenses
... 490 telecoms with services for 2.5 billion subscribers (sims)
... also banking cards

[ The need for digital security and trust is booming ... ]

[ Machine to Machine Communications ]

pierre: we provide wireless modules
... in several MTM verticals
... including automotive
... we already have automotive/car manufacturers as customers
... and we provide digital security

[ Hardware factorization in cars ]

pierre: you used to have Navigation in car
... and radar detector
... multimedia
... and eco driving

pierre: as separate modules
... now they're integrated
... and services are apps

[ Car as a programming platform ]

pierre: we need a rich API to attact developers
... to have apps on this platform
... case study "RelayRides app on OnStar"
... peer to peer car rental
... vehicle owner rents car to system
... before now, it wasn't convenient
... they developed an application for OnStar
... which this application on your car
... the system is easier
... you declare you're working from 8 am to 6pm
... your vehicle is available in the parking lot
... they can be directed by GPS on their phone to the car
... they click on the mobile phone
... which tells the app in the car to unlock the car
... and let them drive the car
... you drive the car
... and return it
... and the app can log how much you drove and how much fuel you used
... and the application reports back where the car is
... you know if the car drove correctly
... it's still a native App
... but to avoid the native app fragmentation problem
... we should design a platform so you could deploy this on a web platform

ph: how successful is this?

pierre: the service is pretty popular
... the app was released in july this year
... i'm not using the app right now
... for this you'd need a large number of deployed cars
... fragmentation hurts

[ How to protect ... ]

pierre: Safety
... how to prevent access to CAN bus by malicious in-car apps ?
... opening the car involves an order on the CAN bus

pierre: how to prevent malicious firmware update?
... Privacy
... how to selectively disclose location/driving patterns
... big data/local aggregation/inference
... when rented you don't want full tracking
... but when it's returned, you do

s|... big data/local aggregation/inference||

pierre: big data/local aggregation/inference
... you could process data locally, aggregate data before sending
... - discount to insurance if you drive less than X/Y km / yr
... company has the right to know how many miles you drove this year
... but this needs to be aggregated at the car level
... no point to show daily use
... same thing, if you rent a car
... and aren't allowed to drive it outside Italy
... rental company has no right to track you
... but maybe an alert if you cross a border
... aggregate and process data locally
... anonymous authentication and payment
... you may need to prove you have a valid driver's license
... but no need to show the full name
... in Germany you can prove you have a German license w/o disclosing your name
... Security
... we want to prevent car stealing by hacking
... which exists nowadays
... prevent mileage modification
... and prevent DoS

[ Which threat model ? ]

pierre: UCs and lifecyle is more complex than an electronic appliance
... i can attack my mobile phone
... i can download an app
... also lost and found UCs
... for a car
... the attacker could be
... one or many drivers
... passengers
... car owner
... car dealer
... maintenance operator
... thieves
... remote hackers
... it may not be an attack as such
... people may want to jailbreak just because
... is this an attack?
... distinguish: remote and physical attacks
... car life cycle will be longer than electronic device

pierre: think about wiping personal data
... send to maintenance, lock personal data/credentials
... upgrade system, need to back up data? and then restore it?
... UCs: renting/sharing/company fleet
... neighborhood cars

[ Is this an attack? ]

pierre: these are examples of hacks
... theming
... adding usb key
... replace cd player w/ usb stick
... directory was limited to 12 entries, now bigger
... these are techno enthusiasts
... but this has security ramifications
... what about opening the door to malicious hackers?

[ Software security v. Hardware security ]

pierre: PC/servers
... considered for software security
... you trust your users
... direct access to data
... you could open pc and remove disk
... on the other side
... you take SIM card
... PoS terminal
... hardware security
... can be deployed in unprotected environments
... no direct access to data
... tamper resistant devices
... -- what about cars?
... some parts fall into software security, some into hardware security

[ A security framework will be needed ]

pierre: of course we need permissions on API
... but it's not so simple
... avoid the "click I accept" syndrome
... Permissions need to be managed based on
... - service provider/developer identity
... -- good, but just being able to sign doesn't mean you don't have bugs
... - certification status
... -- additional signature to say this application has been tested against some guidelines
... - user authentication
... -- fleet owner may have different rights
... - car life cycle state (e.g. in maintenance)
... - real time context (e.g. speed)
... Apps and services will also need
... - user/car authentication
... -- if you subscribe to a service, your subscription may follow you as you switch cars
... -- service could be linked to a car not a user
... - billing framework

[ Identification and authentication ]

pierre: management of identities and roles
... - roles = owner, driver, passenger, shift manager, fleet manager, maintainer, ...
... Flexible authentication methods
... - biometrics
... -- maybe you have fingerprints
... --- possibly not relevant in some areas
... - cryptography
... - hardware based
... -- needs to be flexible in mechanism
... -- blue/pink isn't the same as door open v. who pays for electricity
... --- seemless integration for car-charging -- billing

i/blue/Flexible security levels/

pierre: Various form factors

[ dsr: time check ]

[ App life cycle management ]

pierre: Actors
... developer, service provider, car platform manager
... evaluation and certification

[ Recommendations ]

pierre: technical
... standardize powerful+attactive car API
... design safety - security - privacy model
... - permission based, role based, with flexible authentication
... Method
... work with W3C (SysApps, DAP)
... reuse e.g. from OMTP Bondi
... connect with Genivi OneM2M
... ETSI

[ Applause ]

dsr: time for a quick question.
... W3C is already doing work on Security
... we have WebAppSec
... DAP is working on Security
... SysApps
... what's the best way for W3C to work on Security?

pierre: my personal recommendation would be for Automotive to submit requirements to e.g. SysApps
... maybe they're considering a model that's too simplistic

dsr: thanks

[ Applause ]

dsr: break for lunch
... it's on the house

adam: the room will be locked

kaz: Group Photo?

dsr: kaz is volunteering to take a group photo
... who would like to have a group photo?
... smattering of hands

[ underwhelming ]

dsr: maybe we can do it after lunch

ph: Start again at 2pm

marie: don't forget the safety jackets

Vehicle APIs and Security

adam: I have four companies
... LGE, BMW, Intel and AKQA
... to talk to you about these topics

Genivi Web Vehicle API

JongSeon: Justin (JongSeon) Park, LG Electronics
... our lab provides solutions for TV, Mobile, and even cars
... automotive is the fastest growing field in LGE
... we deliver IVI and Telematics to cars

JongSeon: I'm also involved in Genivi

[ Agenda ]

JongSeon: Why we selected this topic
... Characteristics of Vehicle Data
... Considerations
... - Suggested Architecture
... - Principles to define Vehicle APIs
... Introduction of Genivi API

[ Web Technologies for Automotive ]

[ How to Make Standard Vehicle APIs? ]

JongSeon: We have to understand and consider characters of vehicle data
... Data characteristics
... - so many kinds of vehicle data and data types
... - a few persistent data - car type, vin, model, wmi, ...
... - most data are transient; status at a moment
... - Only the latest value is meaningful (except GPS)
... Vehincle Natwork Characterstic (usually CAN)
... - Real data exist somewhere else - not in IVI
... - Data is broadcasted rather than query

JongSeon: OEM Variations
... - Unit, Accuracy, Frequency

[ Overall IVI Architecture for Vehicle APIs ]

JongSeon: Layered architecture according to characterstics of vehicle network
... Vehicle Network Manager
... - call it from application
... - subscribe/publish mechanism should come from it
... the Vehicle device API is a thin layer on it
... it's the difference with other device APIs
... this is good for supporting apps in the same way

[ How to Overcome OEM Variations ]

JongSeon: we try to define as many data types as possible
... - gather OEM requirements
... - define data types as optional
... define small number of methods
... use less structured interface

[ Web Vehicle API Project in GENIVI ]

JongSeon: We categorized 129 data types
... in 9 groups
... the 9 groups were formed into interfaces
... we defined two methods (get, set)
... since data is optional, we defined a way for web apps to find out if a type is supported

[ API Description - Common Interface ]

JongSeon: we defined 9 interfaces, each inherit from Event

[ scribe: [NoInterfaceObject] is misplaced ]

[NoInterfaceObject]

interface VehicleEvent : Event {};

interface RunningStatusEvent : VehicleEvent {

scribe:

readonly attribute unsigned short speedometer;

readonly attribute unsigned short? enginespeed;

scribe:

}

scribe:

[ API Description - Multiple Data Access (1/3) ]

JongSeon: well-structured interface
... this example shows a relation between datatypes

[ Graphic ]

[ API Description - Multiple Data Access (2/3) ]

JongSeon: we tried things a different way

Interface A : Event {

attribute Type /*missing name*/;

attribute A_1_a /*missing name*/;

attribute A_1_b /*missing name*/;

attribute A_1_c /*missing name*/;

scribe:

};

const A_1_a = "A_1_a";

scribe:

[ API Description - Multiple Data Access (3/3) ]

JongSeon: then code uses if .type=A_1_.... to guard access to the attribute that has data
... if the type is not a given type, then that attribute's values can be garbage

[ API Description - Example (1/6) ]

scribe:

[ API Description - Example (2/6) ]

JongSeon: Getting a single vehicle data
... to get tire pressure
... first argument is attribute, second is the callback for success, the third for error

[ API Description - Example (3/6) ]

JongSeon: let's get the tire pressure for each tire
... normally, you'd need a handler for each tire
... instead you can use a group id
... instead of "maintenance_tire_pressure_status_front_left" ...
... use "maintenance_tire_pressure_status"
... of course the plugin would have to support this
[ API Description - Example (4/6) ]
... using event listener (publish-subscribe mechanism from the web)

[ API Description - Example (5/6) ]

JongSeon: position ...

[ API Description - Example (6/6) ]

JongSeon: the set method is similar to the get method
... but it has an additional argument for the data
... let's see how to set multiple properties at a time
... to set all values at a time, one should set all the related values

[ Pros and Cons ]

JongSeon: many strong points of Genivi WebIDL
... there's the bit that it's confusing
... if you set a listener on the root
... you can get many unrelated events
... since data is changed as an untyped structure, there are tens of bytes overhead
... we're considering investigating these issues and trying to find a better way

[ Conclusion ]

JongSeon: Flexibility
... vehicle api depends on rigid factors such as network protocol and oem's policy
... Generality
... should fit many oem's requirements

JongSeon: limited coverage will cause additional work and fragmentation
... Timing
... once oems use their own apis, it's not easy to convince them to adopt standard apis

adam: Thanks justin

[ Applause ]

adam: questions?

Enabling Rich Web Applications For In-Vehicle Infotainment

simon: Simon Isenberg, from BMW
... we're structured like Audi Electronic Ventures

[ Agenda ]

simon: Motivation - Why Web & Automotive
... Background - What is webinos
... Our Approach - Vehicle Data for Web Apps
... Live Demo - webinos Automotive Apps
... Open Questions

[ Motivation: Current Landscapes of IVI Systems ]

Simon: it's really hard to get new services/applications to the market
... it's really hard to personalize the experience while driving

[ Motivation: Ubiquity of the web and the browser ]

Simon: QNX, Tizen, Firefox, ...
... it's our view that Web is the future

[ Background: What is Webinos? ]

Simon: webinos funded by European Commission
... 30 partners
... Samsung/Sony
... BMW
... Telefonica
... research institutes
... standardization bodies

[ Background: Say hello to webinos! ]

Simon: this is about making apps available
... as a runtime, we're using the browser

[ Background: Say hello to webinos! ]

Simon: today, we're focusing on IVI

[ Key question: How to get access to vehicle data? ]

[ Our APIs: Design approach ]

Simon: Standardize APIs instead of duplicating
... GeoLocation API already exists
... speed/position is in GeoLocation
... latitude/longitude orientation is in DeviceOrientation
... we use async model to expose data
... we took a different approach than LG
... try to minimize resource overhead
... get a CAN message
... this led to two automotive apis
... - Vehicle API
... - Navigation API
... we originally had Navigation in Vehicle
... but navigation could be on a smart phone

[ Vehicle API: General Concept ]

Simon: Solely read access
... distinction between static (transmission type) and dynamic (e.g. gear) vehicle data
... register callback handlers
... dynamic data can be retrieved once or registered for updates

[ Vehicle API: Which dynamic data is provided? ]

Simon: we provide data is packages
... parking sensor all bits together
... tripcomputer all together
... window data all windows at once
... door data
... tire pressure

vehicle.get('tripcomputer', triphandler);

vehicle.addEventListener('tripcomputer', triphandler);

[ Vehicle API: Which static data is provided? ]

Simon: brand, model, year, fuel, hybrid, ...

[ Navigation API: General Concept ]

Simon: simple api
... request guidance
... get POI
... set destination

[ Navigation API: Code Example ]

var destinations = [];

webinos.navigation.findDestination("BMW Welt", destinationCB, errorCB);

function destinationCB(pois) {

}

webinos.navigation.requestGuidance(...);

[ How to integrate webinos into the vehicle? ]

[ Webinos Core Concept: Separating Application runtime from data access ]

Simon: we separate browser
... we have a second system on the IVI system
... vehicle data provider
... it's a Node.js application
... we use a WebSocket connection between the browser and the Node.js application
... (JSON-RPC 2.0)
... we created two Node.js addons
... one for MOST bus and one for CAN bus
... the system works on ubuntu

[ Webinos Vehicle Evaluation Platform ]

Simon: it's based on the Panda board
... iDrive controller
... demonstrator box

[ Webinos vehicle demonstration platform ]

Simon: two weeks ago we were in Munich and demod it
... with webinos on the head unit and the rear seat entertainment systems

[ Live demo ]

Simon: we have two demo applications
... Browser based trip computer for in-car head units
... in the picture, the browser based trip computer can be used both on the car and on mobile/tablet

Simon: trip planning
... i could have my POIs on the smartphone and then use the navigation api to pass it to the nav system

[ The road ahead of us ]

[ the sign said HTML5 - 1000km ]

[ The road ahead of us ]

Simon: we are using XAML
... how will we make it safe?
... to enable write access
... we have to do access-control to enable write access
... and then how do we adapt a web app to be used safely in a vehicle?
... for driver distraction
... adapt input controls
... and also OEM adjustment
... Can we agree on a common interface for vehicle data?

[ Take home message ]

Simon: i've tried to show a proof of concept
... at this stage, read-only
... security+safety needs to be solved
... UI constraints need to be addressed

adam: thanks

[ Applause ]

Simon: http://webinos.org

dsr: SimonI, will you put the demo up over hear?

s/hear/here/

Simon: yeah, sure
... maybe tomorrow

ph: we've seen two apis for vehicle data
... can you contrast your approaches?

Simon: our API was a starting point for the Genivi work
... they optimized it
... from our perspective
... if i want the information, i probably want it all
... if tire pressure changes
... do i want just one, or all?
... webinos is a research project
... we need to optimize it
... i don't think webinos will survive

[ laughter ]

Simon: we could have some success

steiger: the api is JS?
... where does it come from?

Simon: webinos.js is a bootstrapper
... it's injected into the runtime when the application is launched

steiger: either the functionality of webinos.js needs to be added to the browser

Simon: it's open source
... webinos is under the Apache license
... the CAN/MOST modules aren't
... but the webinos.js is open source

andy: you would bundle webinos.js with each webapp
... or is it assumed to be part of the platform?

Simon: it's part of the platform, and injected

andy: you pass the name
... it's sort of a reflective api
... is there a way to get the list of possible apis?
... i'm assuming it's done so you could change it from the oem level

Simon: you have different services which are api implementations
... you do discovery to get the vehicle api
... and get an object back
... if you request doors and get an error, then it isn't supported

adam: other questions?

[ None ]

adam: thank you SimonI

[ Applause ]

adam: next presenter is a colleague of mine from Intel
... Mikko

Tizen IVI Vehicle Data

mikko: Mikko Ylinen, Intel Open Source Technology Center

[ Agenda ]

mikko: Position Paper Highlights
... the api
... demo setup and architecture

[ Position Paper Highlights (1/2) ]

mikko: we think
... in order to be able to provide automotive rich applications
... an access to IVI system data is needed
... ideally through a standardized web api
... different car manufacturers/car models have different data sets
... we have our own api in Tizen
... but i think we should work together to come up with a standardized api

[ Position Paper Highlights (2/2) ]

mikko: some design principles
... api - lightweight provides getting/setting
... api - minimal set of data items that are base set required for compliance
... api - mechanism for event based updates
... api - implements method to query supported data types for graceful degradation
... Power management is not always critical
... but it makes sense to only ask for updates to data the application needs

[ The API ]

get(eventlist, successCB, errorCB)

set(eventlist, valuelist, successCB, errorCB)

getSupportedEventTYpes(type, writeable, successCB, errorCB)

subscribe(eventlist, successCB, errorCB)

unsubscribe(eventlist, successCB, errorCB)

mikko: this morning, i put a Draft label here
... we're working on improving the API all the time

[ Example code - events ]

function engineSpeedEvent(data) {

var newRPMs = data.value;

}

function onLoad() {

vehicle.subscribe(["speedometer", "engine_speed"], ...

[ Example code - set ]

[ API FIXME ]

[ Demo Description ]

mikko: in the demo, we access logitech steering wheel
... if you sit on the seat, you can see the instrumentation cluster
... and see how the values change on the UI
... the values come from the hardware

[ Tizen IVI Web API Prototype ]

mikko: Web Applications - "GhostCluster app"

mikko: any web application
... we have a websocket connection to the automotive message broker
... the automotive message broker has Sources and Sinks
... this allows you to connect multiple AMB together
... you could have the joystick data connected to another instance in the cloud
... to another IVI in the car network

[ Tizen IVI Web API Final Architecture ]

mikko: Web Applications - "A Web app"
... Tizen Web Runtime - WebKit+ JS Core, Vehicle API Plugin
... WRT sink
... AMB core

[ Performance View ]

mikko: environment: from HW to AMB core

mikko: wheel plug-in: 2000+ properties per second, <5% CPU
... OBD-II plug-in: 80-100 properties per second

roman: what cpu?

mikko: i don't know
... i propose you see the demo
... change the gear, and follow the gear number on the screen
... it feels instant
... no delays

[ the Code ]

mikko: we're using GitHub
... the API and web app are available
... that's the end of my presentation

adam: thanks mikko

[ Applause ]

woochul: data comes from car and realtime action
... what about ECU data?

woochul: like engine data

mikko: we can access any data provided by the system
... if we have a source plugin for AMB, AMB can relay the information further

woochul: just want to know the limitation
... how many ECUs could be connected?

mikko: i see no limitation in how many ECUs could be connected
... the AMB abstracts this

woochul: question to the LGE, BMW, and Tizen
... do you plan to define interfaces, e.g. in WebIDL?

peterG: I think we're the only one missing WebIDL
... Genivi is written in WebIDL
... Webinos has it in WebIDL
... we're the only ones misbehaving
... it's on my todo list

ph: how does your approach differ from the other two approaches, and why?

mikko: our subscribe/unsubscribe apis are different

ph: but the data model is similar?

mikko: it's the same
... the data definitions date to MeeGo
... we categorized the data that cars could provide
... and now we've just taken that into web space

adam: other questions?
... we have 3 sets of APIs, we could start a WG
... thanks mikko

[ Applause ]

adam: we have one last presenter

The InCar API

alex: Alex Ajao, from AKQA
... my colleague Paul Slattery
... we're interested in building applications on top of the technology
... a few slides about where we come from

alex: and then pass to Paul for where we go in the future

[ The future inspires us. we work to inspire. ]

alex: we've been around for 18 years

[ Ideas and innovation ]

alex: we have 10, now 11 offices with 1200 employees
... we pick people focussed on innovation
... starting on the left, web design builds
... example w built for Ferarri
... we have an html configurator
... this is a fake (jpeg)
... we're interested in how html apps can make communication for end users
... we worked w/ Fiat to make an ecology index for drivers
... to "improve their eco score"
... we were one of the first companies to do this

[ Connected Car ]

PaulS: alex spoke about AKQA
... we're interested in standards
... they allow people to build things
... to not have to build products on a fragmented industry
... we do standards approach for where we work
... we did it for Volkswagen
... i'm working on MMI
... we do this for standards
... i've worked for a lot of different companies globally
... been w/ AKQA for a couple of years
... we want to take the idea of the car to the next level, the Internet of Things

PaulS: the connected car is our vision
... we assume there will be a standard
... the amount of data being produced is massive
... more data than seen before
... Quantified Self wants an API for the Person
... car creates physical journeys
... which can be related to physical journeys

[ Why standardise? ]

[ Benefits for the driver ]

PaulS: the car is an extension of the digital life

[ Benefits for the industry ]

PaulS: there's an ability to share costs
... research and development costs
... we can stand on shoulders of giants
... webinos speaker said it may not make it into the car itself
... but things will be stronger for it
... being able to create alliances across industries
... will open up businesses
... maybe gryc said
... having standardization lets you build on top of things and differentiate there

[ 2018 Workday ]

PaulS: this is part of a story

PaulS: 2018; i'm a member of a mobility service
... i don't own a car
... i drive a different one each day
... i use my device/google glasses
... i book a car
... i get 15 minutes to get to the car

[ Digital Key ]

PaulS: maybe the car lights flash before i get in

[ Cloud settings ]

PaulS: my profile is downloaded from the cloud
... apps download to the car dashboard
... before that, there's a message from the OEM about a new carpack
... "do you want to download it" -- it's more efficient
... I say "yes"
... i have a dashboard that reflects how i want to drive the car

[ Integration with digital life ]

PaulS: i have to travel 100km to a meeting outside Berlin
... a suggested journey becomes available via HMI
... taking into account traffic+weather
... update says you'll make meeting on time
... i set off on my way w/ nav system guiding me
... there's a context aware trigger when i reach the autobahn (where the car thinks it's safe to show me the update)
... my outlook application shows me an update
... your meeting will be delayed for an hour

PaulS: the system asks me if i want to take a scenic route near a POI
... I do
... I take a voice note
... I listen to the voice note later
... I take the meeting

[ Become a better driver ]

PaulS: when I get home

PaulS: the car wipes my profile off
... because the car updated, i'm curious and check to see if the update improved my eco footprint
... i discover that it did
... if we can bring an industry standard
... our target shouldn't just be music
... but better drivers
... standards can enable that

[ AKQA: Connected Car Partner ]

PaulS: that example was 2018, but maybe it could be 2015
... thank you

[ Applause ]

adam: do you think it'll be really 2018 before we get a standard out?

andy: 2018 before the standard gets into cars

ph: in your paper, you mentioned apis you defined/worked on?

PaulS: on ecodrive, we did a lot of work using USB
... speaking direct to CAN bus
... we're looking for an API to do that in the real world
... a lot of this i proposal driven
... when customers come to us, they want a product to go to market
... we had a proposed api
... we've done prototype work for companies
... you want a layer of abstraction
... it's important to come up w/ an abstraction
... it frees up things to improve
... our goal is to take things from W3C and do cool stuff

Ryuji: Ryuji Wakikawa from Toyota
... we have a similar video on youtube

Ryuji: instead of 2018, we said 20XX
... we have to agree on which data to open to the developer

Ryuji: it's very different to define the dataset
... we use different units in different regions
... MPH v. km/h
... this may be out of scope for W3C
... maybe for some other SDO
... this is a question for OEMs
... can we agree on this dataset?

adam: any OEMs want to comment?

andy: not an OEM, but i have an opinion
... comparing Get/Set
... it's the most flexible
... but it basically isn't a standard
... you could adapt to that
... and each car vendor could do their own things
... there's value in coming up w/ a compromise
... it seems like it's possible to define properties
... and define a way to extend it
... coming to a common understanding about what specific times of data
... is different, but valuable
... so you don't have to make every interface 100% generic

kaz: Kaz Ashimura, W3C MMI WG
... we're now working very hard for extending the data format
... it'd be great if you could give us feedback

PaulS: we'd love to
... one challenge is contextualization
... we should get together

kaz: thank you

adam: last questions?

[ None ]

[ Applause ]

adam: back at the top of the hour

Day 1 Summary

dsr: goal is to come up with rough consensus
... adam and myself will write up a report

[ Extending the Web Platform to Automotive ]

dsr: there's issues of Safety
... and what that means
... there's a risk of liability for OEMs
... which could trigger legistlation which dampens the marketplace
... while W3C focuses on technical standards
... we need to be conscious of legistlation
... I was at a conference talking about situational awareness
... rather than "web applications are dangerous"
... "can we make safer/better drivers"
... issue of privacy of user data
... - not holding data in shared vehicles
... even users in the same family
... also for authenticating data in the cloud
... is authenticating users specific to models of a car
... or cross vendor?
... Gemalto discussed security/threat models
... there's issue of permissions
... there's XACML
... there are other approaches
... do we have agreement on how to proceed?
... what does it mean to authenticate applications?
... is it just signatures?
... how do you enable differentiated services
... end user v. OEM perspectives
... users have phone, tablets, tvs
... they want some consistent way to manage applications/services
... and how they interact w/ friends + colleagues
... what are the technical implications
... personalization v. branding
... individuals want car start to be personalized
... app developer wants to write an application that runs on multiple cars
... how is that managed?
... templates/css/js libraries?
... multi-screen interfaces
... head-unit, phone, rear-seat, heads-up
... multi-modal: speech, spatial audio, visual, tactile
... how to minimize cognitive load

[ Further considerations ]

dsr: talks about web apis
... seems like a lot of interest
... hoping we can agree on the details
... perhaps it's time to start work on standardization
... - to avoid market fragmentation
... high enough level to insultate developers from low level variations
... security considerations
... different places to run apps
... cloud/remote ui
... fallback for network brownout
... application runs in phone/tablet
... nBox
... local server
... talk about sensors in car/roadside
... crowd based sources?
... M2M?
... Driver distraction/context management
... which applications run in foreground/background
... if you approach a junction and want to focus driver on it
... could nav system lower volume on audio system?
... having the car observe you?
... gaze tracking
... to assess driver alertness
... logging information
... are users willing to accept logging?
... application packaging

[ Effective Standardization ]

dsr: there wasn't appropriate engagement between browsers and telcos
... several attempts were made
... ensuring all stakeholders are involved
... it's less costly in the long run
... focus on low hanging fruit
... simple enough data models?
... make progress and build momentum
... and maybe market will clarify
... avoid premature standardization
... how to achieve best practices
... Genivi - W3C
... joint partcipiation
... formal liaisons
... - joint participation is very effective
... W3C WG would require companies to be members
... if you join W3C, it's important to have engineers in multiple WGs
... for Vehicle APIs, what are the easy interfaces?

andy: i think there are some areas where there are pretty common things
... access to media player is an area
... there's some set that are going to be common
... some will have extensions required
... that model will apply everywhere
... some will have some things, some will not have everything
... breaking it down into the basic categories
... and then having extensibility

Josh_Soref: surely gears are easy? only 10?

[ lots of complaints that it isn't that simple ]

dsr: what are the UCs for these APIs?
... are there lots of UCs for specific APIs?

pavel: Pavel Konopelko, Visteon
... afaict, the guys from LGE will know better
... in this case, the approach was trying to generalize the data
... it was not UC driven
... using the Gears example
... it was very enlightening
... it's a never ending story
... 3 column table
... name, data type, description
... what it means when it's read/written
... updates, how to handle, how to fire events
... another thing is how to group multiple rows
... mentioned some vehicles will have, others will not
... data needs to be modular
... so an app can know what can be used
... what data would be useful for webapps to use
... how to make it modular, and how to access this data

marcin: I would like some experiences from W3C and other orgs.
...We just finished a standard that was started 4 years ago.
... Started with a set of requirements that were brought forward.
... Some other orgs are using other tools where people bring ideas and they get a lot of proposals.
... People are thinking they can maybe get this done in a year.

marcin: Participants get to look at it for four weeks then vote on what they want to implement.
... Here we have three proposals. What would people say / vote.
... See if we have consensus here. If there is none we need to work on that or we won't succeed.
... People need to be openminded and do trade off to see how we come together.

yyyyyy: I just want to add that when you take an action across the three approaches that the Webinos is a subset of Genivi.

dsr: It could be a case of subsetting as well.

<timeless> s/that simple/that simple - some have no gears, some have 4wd also/

dsr: typically the processes allow you to control work and scope.
... Use cases are very important and allow you to say we're doing this and not that.

andy: The value in having the use cases and going back to the gear boxes, most applications have some core things like am I moving or am I still.
... That one simple bolean decision could be very complex.
... I think figuring out the use cases we want to tackle is not a bad idea.

adam: What I'd really like to understand is do the OEMs in the room agree that this is important to them either now or in the future?

adam: Without the OEMs help we're not going to get very far.
... We'll need them involved to make this all work.

nils: I quite like Andy's approach of Use Case based. It shows that it may be complex discussion and on the other you may have useless functions.
... Maybe the Use Case approach is far better because you can see if it's possible.
... We can find a similar extraction of the API.

nils: It's not easy or a problem we can solve at the top level. There are abstraction levels below.
... What I'm saying is there are architectural issues that need to be resolved first.
... Start with Use Cases and go from there.

[Gives several examples]

nils: Stuff that's inside the QNX similator.
... If we spend three years and can't get the data to the API it has no benefit for anyone.

maximilian: I think a Use Case approach is good, but what about Use Cases you don't envision now?
... In our case it's getting them into the browser and available in an easy way.

Dan: Not to challenge you, but why does it have to be in a browser?
... You're making an assumption it has to be a browser, why not some other user agent?

maximilian: It's just a model and opinion for now.

Dan: The current BMW apps are based on a platform. So just wondering why you're going from a platform model to a browser model.

maximilian: Some are running in a browser, some are integrated into the native HMI.

ryuji: I think there are some specific applications like these APIs. I agree on these Use Cases, I prefer to start there.

ryuji: I don't know how we can proceed this activity, I don't know what the risks are, but maybe we start with the data that's available and public?
... We can probably start from basic activity and converge on API.

nobe: Before this March I was working for Nissan and implemented many solutiosn.
... OEM Vendors may not want ot open their data to the public.

nobe: They may not want to open transmission data.
... But some of the other things they might want to. Areas where they don't compete.
... We can take data like wipers or outside data.
... Those are of benefit to the market / customers. Generally the vendors would agree they can open this data.

nils: As I said, there are two different worlds. There is the canvas world which only has data on the CAN bus.

nils: Mixing these three Use Cases which bring Web data to the vehicle is a problem as there are two different architectures.
... Some we can solve (entertainment systems) others we can't.
... Some data is not so easy to open up because of complexity.

Jean-Marc: What we are trying to do with standardization of the API is quite different.
... First we have to ensure that the APIs we're talking about are very flexible.
... We shouldn't target the standardization of everything.
... Than might frighten people away.

<bgidon> Jean Marc Temmos (Visteon)

dsr: That's why I said focus on places where consensus is possible.
... Another aspect is security. In what cases do you give applications to which APIs.

dsr: Do we have any chance of coming together on that or is it something we shouldn't approach.
... I suspect we may have to put something about security in a Working Group charter.

[crickets]

Josh_Soref: Of the car vendors, how many want to have their own appstore?

nobe: Maybe a different kind of appstore around downloading the applications.
... Some OEM vendors may want to go that way.

<naomi> Tsuguo Nobe, Intel

Josh_Soref: The reason I ask is that if people were going to have their own apps store security wouldn't be an issue.

dsr: You might start with a small set of applications that are very hard to put together.

<timeless> pierre: Renault has some plans to launch their App store

<timeless> s/app store/app store -- and if a company doesn't have an app store, people will find a way to install apps anyway/

dsr: That might be a second phase. The question is how do we keep the applicactions refreshed. Different users have different requirements.

nobe: OEM vendors have to take the responsibility to check their apps.
... They have to check the source to make sure it's safe.

ludovic: I want to add something about a link between the API definition and security. If we share the same API then it would run for every OEM.
... So maybe it's a way to manage a stardard API for applications.

dsr: One topic we haven't discussed is integration of the head unit with the phone.
... Is this an area where we have some interest? We talked about MirrorLink as example.
... It seems there is some tension and I'm wondering what we might do there.

kazkkitagawa The mobile apps are cheaper than the car apps. If the user gets a new car and wants to integrate the handset.

scribe: The development of the Web Technologies with the automotive may take years. Due to security, etc. Not an easy upgrade.
... Safety is key.

nobe: Two factors - how to integrate with smart phone and definitions.
... Communications company may embed a module which is quite expensive.
... It may be included to deliver collision reporting systems, etc.
... Used for safety and security point of view.

nobe: If there is some big module embedded then upgrading is a problem. The reality is that embedded phone module be included for certain apps.
... OEM Vendors have obligation to update module.
... This is a feature we have to care about - to embed or not.

nobe: Other isssue is how to make connection? Wifi or bluetooth. OEM vendors need to think what is technology that will last 10 years of someone buying the vehicle.

dsr: It's possible that different companies have different opinions.
... M2M communications may drive these prices down.

andy: I think there are several head unit to phone conversations going on within other areas.

andy: We should focus on other areas where there is more passion.

sakazawa: We should separate the technology issues.
... If an application needs to communicate to head unit then certain application should be run.

dsr: What I was wondering is if an app is running on the phone how does it have presence awareness.
... It may not be solved by W3C but it should be addressed.
... Thanks for your time, the meeting starts tomorrow at 0845.

adam: We're going to have the networking event that will start at 5P and will be up here.