PROPOSED Automotive Working Group Charter

The mission of the Automotive Working Group is to develop specifications for exposing information services for in-vehicle and cloud based uses.

Join the Automotive Working Group.

This proposed charter is available on GitHub. Feel free to raise issues.

Start date TBD
End date TBD + 2 years
Chairs Peter Winzell (Volvo)
Team Contacts Ted Guild(0.2 FTE)
Meeting Schedule Teleconferences: weekly and topic-specific calls may be held as needed
Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year.

Scope

This group will develop information service specifications for exposing vehicle telematics data, other data following similar taxonomies as well as exposing vehicle centric functions.

Members of the Working Group should review other working groups' deliverables that are identified as being relevant to the Working Group's mission.

Services may include but are not limited to

Out of Scope

This Working Group will not define or mandate implementation details including vehicle, network or sensor protocols for sharing data between the vehicle data network and sensors. The vehicle data bus network and protocols are OEM specific and vary from vehicle to vehicle.

However, to facilitate interoperability among vehicle OEMs and encourage adoption of the specifications, the group may informatively reference existing suites of protocols, either directly in the deliverable(s) or in a non-normative companion Note.

Deliverables

Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.

Normative Specifications

The Working Group will deliver the following W3C normative specifications:

Vehicle Information Service Specification

VISS is a lightweight API for accessing vehicle signals information via WebSocket. It is currently in production vehicles.

Draft state:Candidate Recommendation

Expected completion: [Q3 2021]

Adopted Draft: Vehicle Information Service Specification 13 February 2018

Exclusion Draft: Vehicle Information Service Specification 13 February 2018, W3C Candidate Recommendation
Exclusion period began on 06-Mar-2018 ended on 05-May-2018.

Other Charter: https://www.w3.org/2014/automotive/charter-2016.html

Vehicle Information Service Specification (VISS) version 2 Core

Successor to the first version of the Vehicle Signal Server Specification which defined the semantics of exposing vehicle information through the WebSocket protocol. The second version is adding a REST interface, supporting additional protocols, providing access control along with additional functional improvements. This specification is dependent upon the Vehicle Signal Specification, as defined by GENIVI. VISS CORE addresses the messaging layer.

Draft state: Editor's Draft

Expected completion: [Q1 2023]

Vehicle Information Service Specification (VISS) version 2 Transport

Successor to the first version of the Vehicle Signal Server Specification which defined the semantics of exposing vehicle information through the WebSocket protocol. The second version is adding a REST interface, supporting additional protocols, providing access control along with additional functional improvements. Privacy considerations concerning use of data will be addressed. This specification is dependent upon the Vehicle Signal Specification, as defined by GENIVI. VISS Transport addresses the transportation protocols.

Draft state: Editor's Draft

Expected completion: [Q1 2023]

Vehicle Remote Procedure Calls

This specification will follow the pattern established by VISS, separating out the service protocol from a data dictionary developed in collaboration with the GENIVI Alliance. Instead of vehicle signals, the data taxonomy for RPC will define functions available on a vehicle.

The Automotive Working Group performed some preliminary evaluation of various RPC protocols suitable for connected vehicles, created initial requirements and is developing use cases to define explicit functions for the service catalog. These example functions will be used in order to inform selection of RPC protocol. The Working Group will document the overall RPC architecture, including its authorization mechanism.

Draft state: No draft

Expected completion: [Q4 2022]

Vehicle Signals Specification Ontology (VSSo)

This specification creates an ontology based on GENIVI Vehicle Signals Specification, leveraging ontologies created by the SDWWG, specifically Time Ontology in OWL, Semantic Sensor Network Ontology (SSN) and contained Sensor, Observation, Sample, and Actuator (SOSA) "core" ontology.

Draft state: Member Submission

Expected completion: [Q3 2022]

Other Deliverables

The Working Group will deliver the following W3C non-normative documents:

  • Use case and requirement documents
  • Test suite and implementation report for the specification
  • High level architecture for information flows to facilitate understanding of the different standard and proprietary solutions being used within the industry and to further discussions on data privacy considerations throughout
  • In-Vehicle Application Best Practices to address many of the issues arising from allowing applications to reside and run on vehicles including but not limited to security, privacy and safety considerations beyond the confines of specifications being delivered.

Timeline

  • April 2021: First teleconference
  • June 2021: First face-to-face meeting
  • June 2021: Requirements and Use Cases for Vehicle Remote Procedure Call
  • June 2021 Information Flow Architecture document
  • April 2021: FPWD for VISS version 2 Core and Transport
  • April 2021: Publish In-Vehicle Application Best Practices
  • August 2021: FPWD VSSo

Success Criteria

In order to advance to Proposed Recommendation, each normative specification is expected to have at least two independent implementations of every feature defined in the specification.

Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them, and recommendations for maximising accessibility in implementations.

There should be testing plans for each specification, starting from the earliest drafts.

Each specification should contain sections detailing any known security or privacy implications for implementers, Web authors, and end users.

To promote interoperability, all changes made to specifications should have tests and working prototype code examples.

Coordination

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review.

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

W3C Groups

Automotive and Transportation Business Group
This group developed the initial version of the Vehicle Information & Vehicle Data APIs and continues to explore various automotive and broader transportation topics, some of its chartered work is transitioning into the Automotive Working Group.
Device and Sensors Working Group
The Device and Sensors Working Group defines the Network Service Discovery API that addresses some of the use cases that are in scope of the Automotive Working Group.
Privacy Interest Group
The Automotive Working Group will organize an open discussion with the Privacy Interest Group to explain standards it is creating, ecosystem it will be utilized in and seek input on its deliverables for protecting personal information.
Accessible Platform Architectures Working Group
To ensure the Vehicle Information and Data APIs support accessibility requirements, particularly with regard to interoperability with assistive technologies, input to use cases and inclusion in the deliverable of guidance for implementing the group’s deliverables in ways that support accessibility requirements. The APAWG will also coordinate review from the Mobile Accessibility Task Force.
Web Application Security Working Group
The Web Application Security Working Group is developing security and policy mechanisms to improve the security of Web Applications and enable secure cross-site communication.
Spatial Data on the Web (SDW) Interest Group
The Spatial Data on the Web Interest Group maintains the core Time and Sensor ontologies used by VSSo and is creating extensions to both. The Automotive Working Group will provide feedback on the developing extensions and solicit input on their application within VSSo. The Automotive Working Group will follow and provide input on SDW group's unpublished Responsible Use of Geospatial Data, potentially drawing from it in the In-Vehicle Best Practices document for some of its privacy considerations.
Linked Data for Accessibility Community Group
The Linked Data for Accessibility Community Group’s mission is to make accessibility information about buildings, services and routes easier to find — everywhere where people need it. The Automotive Working Group will seek expertise from this Community Group and others on extensions to VSSo for accessibility needs and services.

External Organizations

GENIVI Alliance
The GENIVI Alliance is an automotive initiative that uses Linux and open source technology to define an automotive infotainment system that would adopt the APIs developed in this Working Group.
Automotive Grade Linux (AGL)
Automotive Grade Linux is a collaborative open source project developing a common, Linux-based software stack for the connected car and part of The Linux Foundation.
AUTOSAR (AUTomotive Open System ARchitecture)
AUTOSAR is an open and standardized automotive software architecture, jointly developed by automobile manufacturers, suppliers and tool developers.
SAE
SAE International is a global association of more than 128,000 engineers and related technical experts in the aerospace, automotive and commercial-vehicle industries.
ISO TC204 Intelligent Transportation Systems
[specific nature of liaison]
ISO TC 22/SC 31 Extended Vehicle
ISO Extended Vehicle and Neutral Vehicle standards establish means for extracting telematics data from vehicles and serving it from the internet but lacks a common, unified data model. Intent is to coordinate on common data model, namely VSS, to normalize data in order to make it more readily disseminatable.
ITU-T SG13 Focus Group on AI for autonomous and assisted driving
The FG-AI4AD supports standardization activities for services and applications enabled by AI systems in autonomous and assisted driving. Intent is to establish the vehicle signals ontology VSSo as the premier ontology for machine learning and other uses around autonomous vehicles.
Automotive ISAC
An industry-driven community to share and analyze intelligence about emerging cybersecurity risks to the vehicle, and to collectively enhance vehicle cybersecurity capabilities across the global automotive industry. The W3C Automotive Working Group will seek contributions to its In-Vehicle Application Best Practices and promotion within the industry.

Participation

To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the (Working|Interest) Group. There is no minimum requirement for other Participants.

The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.

The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.

Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics and Professional Conduct.

Communication

Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on a public repository and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.

Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Automotive Working Group home page.

Most Automotive Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.

This group primarily conducts its technical work on the public mailing list public-automotive@w3.org (archive) and on GitHub issues. The public is invited to review, discuss and contribute to this work.

The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.

Decision Policy

This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period of one week, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs or the Director.

This charter is written in accordance with the W3C Process Document (Section 3.4, Votes) and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis. For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.

Licensing

This Working Group will use the W3C Software and Document license for all its deliverables.

About this Charter

This charter has been created according to section 5.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

Charter History

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3):

Charter Period Start Date End Date Changes
Initial Charter 3 February 2015 31 December 2016 none
Rechartered 8 December2016 31 December 2017 The Auto WG switched from a WebIDL based specification to a service specification.
Charter Extension 1 January 2017 31 March 2018 none
Charter Extension 7 March 2018 30 April 2018 none
Rechartered 1 May 2018 30 June 2020

Inclusion of Restful Service Interface (RSI) as an extension of Vehicle Information Service Specification (VISS) and the discontinuation of Vehicle Information API Specification (VIAS).
Charter Extension 1 July 2020 31 December 2020
Rechartered 1 January 2020 31 December 2022

Inclusion of Vehicle Signals Specification Ontology, Vehicle Remote Procedure Calls and In-Vehicle Application Best Practices.