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.
|End date||TBD + 2 years|
|Chairs||Peter Winzell (Volvo)|
|Team Contacts||Ted Guild(0.2 FTE)|
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.
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
- Vehicle Telematics Data
- vehicle brand, model, year, fuel type, transmission type, steering wheel position, tire pressure, oil level, wiper position, lights, doors, windows and seat settings as well as navigation, trip computer data, climate control data, speed, RPMs, acceleration, gears, …
- A named remote procedure API with accompanying functions to be defined collaboratively in GENIVI's Vehicle Service Catalog (digital key, remote delivery, electric vehicle charging, geofencing)
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.
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.
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]
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.
- 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
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.
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:
- 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.
- 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 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.
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.
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 firstname.lastname@example.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.
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.
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.
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.
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.