Difference between revisions of "Web and Automotive"

From W3C Wiki
Jump to: navigation, search
Line 1: Line 1:
 
'''The below is historic material'''
 
'''The below is historic material'''
  
'''Please check out [http://www.w3.org/2012/08/web-and-automotive/ W3C Web and Automotive Workshop page] for most news on this topic'''
+
'''Please check out  
 +
 
 +
'''[http://www.w3.org/2012/08/web-and-automotive/ W3C Web and Automotive Workshop page]'''
 +
 
 +
for up-to-date news on this topic'''
  
 
''Electronics and software represent a substantial and increasing part of a car's cost. How can automakers and their OEM's keep control of the costs whilst satisfying demands for differentiation, and fulfilling user demands for up to date applications and services that work seamlessly across all of the devices they own? An increasing number of people believe that HTML5 and open Web standards will be an important part of the solution.''
 
''Electronics and software represent a substantial and increasing part of a car's cost. How can automakers and their OEM's keep control of the costs whilst satisfying demands for differentiation, and fulfilling user demands for up to date applications and services that work seamlessly across all of the devices they own? An increasing number of people believe that HTML5 and open Web standards will be an important part of the solution.''

Revision as of 12:28, 15 February 2013

The below is historic material

Please check out

W3C Web and Automotive Workshop page

for up-to-date news on this topic

Electronics and software represent a substantial and increasing part of a car's cost. How can automakers and their OEM's keep control of the costs whilst satisfying demands for differentiation, and fulfilling user demands for up to date applications and services that work seamlessly across all of the devices they own? An increasing number of people believe that HTML5 and open Web standards will be an important part of the solution.

This page is intended to describe the potential for Web applications in cars, and what kinds of Web standards are needed to realize this potential. This will be used to support email discussions on plans for initiating standardization work at W3C on autotmotive Web APIs, and for scoping the Web and Automotive Workshop. We invite discussion on the public-automotive mailing list.

Web Applications in the Car

The Web took off on desktop computers first and from there, it has spread to all portable devices like mobile phone, PDAs, tablets, etc. and, more recently, to television and home entertainment devices. The entertainment systems in the vehicle is expected to be the next big market for Web applications.

Web technologies have a significant edge over proprietary application development technologies.

Advantages of Web Applications

  • It is comparatively easy to adapt Web-based applications to work across different devices, so ideally speaking, applications initially developed for mobile phones can be easily adapted to work on PDAs, tablets, TVs and cars.
  • There is huge knowledge base already available on Web technologies.
  • In addition to that, since Web technologies are based on open standards, developers are not held hostage by particular vendors.

Challenges to adopt Web Technology in the Car

There are many challenges to overcome before exploiting the potential of web technologies from in-car entertainment systems.

  • Driver Distraction - One of the biggest issues in automotive domain is driver distraction, with the fear of accidents if drivers are distracted at crucial moments, along with concerns over legal liability. This can be addressed by standardization of HMI guidelines for web applications, especially web application shall exhibit different behavior based on current vehicle condition, e.g. turning off features based on vehicle speed, like scrolling.
  • Cost - Web technologies require some of the basic infrastructure to be available in the system, e.g. Connectivity Stack (Bluetooth, Wi-Fi or Cellular), TCP/IP Stack, Embedded Browser with support of various web technologies (e.g. HTML5), increasing software and hardware costs

Road map

Initial feedback suggests that the first priority is to initiate standards work on automotive Web APIs to avoid needless differences in these APIs across vendors as HTML5-based solutions are deployed in the market. These APIs would allow authorized applications to access a variety of in-car subsystems. Driver distraction can be dealt with through only allowing Web applications to run when the car is parked, except for a few carefully designed applications chosen by the automaker. As experience is gained, we expect the deployment of more sophisticated approaches to mitigating driver distraction, necessitating further work on standards for the context, notification management, and the means for Web run-times and applications to adapt to changes in the context.

We invite stakeholders to subscribe to the public mailing list (see next section) and to contribute to discussions on the scope of work on automotive Web APIs, and to the plans for a W3C Web and Automotive workshop later this year. We look forward to your help in preparing a draft charter for a new W3C automotive Working Group, in parallel with the preparations for the workshop. Use cases and proposals for automotive Web APIs would be particularly helpful in guiding the drafting of the Working Group Charter.

How to get involved

Please subscribe to the public mailing list public-automotive@w3.org. See the link on that page for details. If you have a W3C Account, you will also be able to edit this wiki. To get a W3C account, fill out the account request form.

In case of further questions, please contact the following:

  • Dave Raggett <dsr@w3.org>
  • Bernard Gidon <bgidon@w3.org>

Note: anyone making a substantive contribution to W3C specifications will be required to commit to the requirements of the W3C Patent Policy.

Recent meetings

Some relevant topics

This is probably incomplete, and we welcome your comments and suggestions.

Use Cases and Ecosystems

Technical work on standards depends on a shared understanding of the use cases. This makes collecting and refining a suite of exemplar use cases an important task. In addition, it is valuable to understand the nature and roles of the different players in the ecosystem that will be needed for a thriving market of applications.

Example Applications

This is a sampling of some of the applications we may expect:

  • Media player for local and streamed media
  • News and weather -- local, national, international, sports, business, arts, ...
  • SatNav with live traffic data and parking information
  • Location based search and advertising
  • Games -- for passengers
  • Social network apps -- tweets, posts, photos, location, ...
  • Mobile office apps -- contacts, email, phone, to-do lists, calendar, ...
  • Custom enterprise apps
  • Car status -- fuel efficiency, servicing info, ...

HTML5

With HTML5 developers have rich opportunities for Web applications. One challenge is the risk of variations in which features are supported on any given head-unit, leading to increased development and testing costs that then acts as a brake on innovation. Which features of HTML5 (including the respective JavaScript APIs) are important for automotive Web applications?

Application Packaging

The success of Apple and Google with app stores has focused attention on app stores for Web applications. New work is being considered at W3C for application packaging using a JSON based manifest format. This presents a timely opportunity for revisiting other aspects relating to security and privacy. At the same time, there is interest in being able to sign hosted Web applications that are dynamically downloaded at run-time rather than being locally installed.

Foreground Applications and Background Services

In the car, it is likely that there will be a need to run multiple independent services at the same time, e.g. music player, satnav, news bulletins and tweet feeds from friends. How can the Web run-time support this? Web browsers commonly support multiple tabs, and HTML5 has introduced the notion of Web Workers that act in the background. Is this adequate or even appropriate in the automotive context? Android provides an alternative model where the display is controlled by the foreground application, and applications are suspended when another takes their place. This is supplemented by services which run continuously in the background. Yet another approach is taken by node.js where services are defined in terms of event driven JavaScript modules and libraries of APIs. A related challenge is what is the most effective way for users to switch between applications?

Multi-Device Applications

In the car, people are likely to want to be able to use the car's head unit together with their other devices, such as their smart phones, tablets, and even their notebook computers. At home, people may want to synchronize the car with their home network, e.g. to download trip information, music, or even movies and games to keep the kids occupied during the drive. What are the key use cases for multi-device applications, and what are the implications for Web standards?

User input controls

Touch screens are very popular for smart phones and tablets. For cars, there is value in providing input devices that can be operated without the need for looking directly at the display. You can reach out and operate the control guided by tactile feedback from grasping it, and without having to take your eyes from the road. What changes if any are needed for web run-times to support such controls? Likewise for novel output controls in the car?

Vocal and multimodal interfaces

Using your voice to drive the application allows you to keep your eyes on the road and your hands on the steering wheel. W3C has been working on standards for vocal interaction for many years, e.g. VoiceXML, and more recently there has been work on integrating vocal interaction with HTML5 as a basis for multimodal interaction. Accurate large vocabulary speech recognition, and sophisticated task oriented natural language understanding is easier to accomplish in the Cloud. What kinds of standards are needed to support this and to enable a thriving market for value added third party services?

Local speech recognition and synthesis will be valuable when the car isn't able to connect to the Cloud, and can be perfectly adequate for a range of command and control use cases. What standards are needed to allow for a mix of local and remote handing of speech for Web applications?

Context Awareness

How can applications be made aware of the context and adapt effectively to changes? One aspect is the distinction between the car being parked and in motion, but there are many others, for instance the level of background noise, whether the driver is fully alert or seems to be on the verge of falling asleep, the external environment including time of day, road conditions, and the need for the driver to take actions at upcoming junctions, or when another car is pulling out in front of you. In addition to applications voluntarily adapting to the context, how could the Web run-time impose changes? This would be necessary for untrusted applications.

We expect that the browser/web run-time will evolve to support a mechanism whereby applications can be forced to adapt to match changes in the context. Applications designed for the car will have greater control over the user experience in different contexts.

Notifications

How should notifications be handled, and how should this change depending on the context? For instance, the context could de-prioritize certain classes of notifications, and use different aural, visual and tactile cues for easy recognition of various kinds of notifications. Notifications would be provided from a number of sources, including the foreground application and services running in the background. A better understanding of this could feed into new work items for the W3C's Web Notification Working Group.

The browser/web run-time will need a notification manager, that adapts notifications according to the current context, see the previous section.

Automotive Specific APIs

What use cases are there for exposing different aspects of the car to Web applications through automotive specific APIs? Information from car sensors for road conditions and nearby vehicles. Information on fuel efficiency and need for servicing. There are many car subsystems, but how much information do end-users really want? What new standards are needed for this?

Security, Privacy and Trust

The Web run-time will need to run regular Web applications in a secure sandbox that limits what they can do. W3C has gained considerable experience in how to design browser safe APIs that give users control over whether or not to grant access to an application for a specific capability, and which minimize the ability of applications to finger print users. Current work on Web Intents promises a clean model for giving users control over which service providers to fulfil particular application intents, avoiding the need for applications to hard wire their relationships with service providers.

Applications that want access to system level APIs, require a higher level of trust. How can this be provided effectively? One approach is via digital certificates, e.g. signed by the automaker or a trusted third party. Application stores provide another approach where applications are carefully vetted for compliance to the appstore's security and privacy policies before being made available. Both approaches raise the issue of trust revocation and the challenge of checking in a timely manner whether an application should be upgraded or disabled. A related challenge is supporting system software updates when security flaws are uncovered. What role is there for federated approaches to trust based upon reputation and independent assessments of applications from a security and privacy perspective?

One important feature for privacy is the ability to clear the history and private data, e.g. when returning a rental car. Another is the means to set the preference to not be tracked by applications and Web sites.

User Preferences

Cars may be shared by several members of the same family. What is needed to implement personal preferences in a seamless fashion? This implies some means for the car to recognize each person. This can't be quite as simple as detecting which "key" is being used, as people are likely to share keys. Do biometric techniques offer any promise here? For instance, face, finger print or voice recognition? Identifying the user could also provide the means to sandbox user preferences, browsing history and personal data.

Advertising

What are the challenges for context based advertising in the car? This could be based on the car's location, the trip plan as registered with the satnav applications or deduced based upon observed driving patterns, the time of day, amount of traffic, and so forth. This is likely to be impacted by user preferences, as different people are likely to respond to different advertisements. One opportunity is for personalized context based advertisements inserted as part of media streams.

Payments

There are many different kinds of payment solutions extant or in development, for example, embedded wallets, or network based solutions such as the GSMA OneAPI. When an application is seeking payment for a service, the user should be free to select whichever means of payment he or she prefers. Web Intents provides part of the solution, but would still need agreement on how the Web application communicates with the payment solution after users have made their choice. Support for payments would be valuable to the growth of automotive Web applications, and a standards based solution would be more effective in that respect than proprietary solutions specific to given appstores and necessitating additional work by application developers. Further information is available on the W3C Payments Task Force wiki.

Web and Automotive Workshop

W3C holds workshops to provide advice on whether it is timely and appropriate for W3C to initiate standards work in a particular area. Workshops last from one to three days and can have anything in the range of twenty to one hundred participants. The starting point is the formation of a program committee to advise on the scope and aims of the workshop, and to help with finding volunteers to chair the workshop, as well as the location and venue for the event. The call for papers is then announced, and the responses reviewed by the program committee to see who should be invited to attend the workshop. The program committee also helps with the preparation of the workshop agenda, including the possibility of inviting people to give keynote presentations. The deadline for responses to the call for papers needs to be sufficiently in advance to allow for the review process, and time for people who are selected to make their travel arrangements. In some cases, sponsors are sought to defray the costs to W3C for organizing the workshop.

At this time, the workshop is now expected to be during the 2nd half of November 2012, but the location and venue are still undecided. We welcome suggestions for these, especially offers to host the workshop at a location that is convenient for the expected participants. We recognize that companies have restricted travel budgets, and it may be practical to hold follow on workshops in different parts of the World if the demand is sufficient. Note that W3C already has limited funding for hosting the workshop in Europe should we choose to hold it there.

Program Committee Members

  • James Ausmus, Intel
  • Diana Cheng, Vodafone
  • Virginie Galindo, Gemalto
  • Matthias Goebl, BMW
  • Andy Gryc, QNX
  • Wolfgang Haberl, BMW
  • Christopher Hilton, Harman
  • Nobuhide Kotsuka, KDDI
  • Roger C. Lanctot, Strategy Analytics
  • Håkon Lie, Opera Software
  • James McGinley, Intel
  • Maximilian Michel, BMW
  • Christian Müller, DFKI
  • Scott Pennock, QNX
  • Youngsun Ryu, Samsung
  • Ryuji Wakikawa, Toyota ITC