Charter for the Automotive and Web Platform Business Group

Here's is the proposed charter for the Automotive and Web Platform Business Group:


Automotive and Web Platform Charter



Date: 2013-02-11
Goals

The goal of the Automotive and Web Platform Business Group (BG) is to accelerate the adoption of Web technologies in the automotive industry. In order to achieve this mission, the group will bring developers, automotive manufacturers, automotive suppliers, browser vendors, operators and other relevant members of the industry together to:



1.      Create specifications, starting with the Vehicle Data API Specification.

2.      Create conformance tests to cover new specifications that get defined.

3.      Provide use cases and other reports to identify additional needed standards work and to drive successful automotive web deployments.
Scope of Work

The group will produce the following types of deliverables:



Specifications
The group will develop a Specification for an API to expose vehicle data and information from an automotive network bus(es) (e.g. MOST or CAN) to a Web application.  The  API will expose information like the vehicle brand, model, year, fuel type, transmission type, steering wheel position, tire pressure, oil level, wiper position, lights, doors, windows and seating settings as well as navigation, trip computer data, climate control data, speed, rpms, acceleration, gears, park sensors and other vehicle sensors.  How an implementation obtains this data is not in the scope of the group.



The Contributor License Agreement (CLA)<http://www.w3.org/community/about/agreements/cla/> Patent section does apply to Specifications.



Test suites
High-quality, comprehensive and automated test suites are important interoperability drivers.  The group will endeavor to create test suites for each specification it releases.  Test Code will be contributed under a 3 clause BSD License.



The Contributor License Agreement (CLA)<http://www.w3.org/community/about/agreements/cla/> Patent section does not apply to test suites.



Non-normative Reports
Since participants will reflect diverse interests within the automotive ecosystem, the group plans to document a variety of (non-normative) use cases and other reports. These may serve as input to other W3C (or non-W3C) groups to indicate capabilities that need to be standardized.



In particular, the group will look at the technologies in the Open Web Platform and will determine if they meet the special needs of use in automobiles.  By identifying use cases not satisfied by current Open Web Platform Specifications, this group will attempt to influence WGs in W3C and elsewhere to deliver the capabilities in their Specifications that the Web in autos need.



The group will also determine what future work this group should undertake.



The Contributor License Agreement (CLA)<http://www.w3.org/community/about/agreements/cla/> Patent section does not apply to these non-normative reports.


Deliverables
The group will ONLY produce Specifications listed here.  To add any additional specifications, the Charter must be amended by the process described below.  All deliverables for which the CLA patent section applies must be designated as such here.
Non-Normative Reports - CLA patent section does not apply
The group will produce reports, as described in the scope section, on the use of Open Web Platform technologies in the automotive space.
Specifications - CLA patent section applies
Vehicle Data API - APIs to report vehicle information as described in the scope section of the Charter.
Test Suites - Contributions under BSD 3 clause license
Test suites will be created for each of the Specifications in the previous section.
Dependencies or Liaisons

  *   For the reports produced, including use cases, it may be useful to contact members of W3C WGs such as the SysApps WG, Web Apps WG, Web Apps Security WG, CSS WG and many others.
  *   There are no external specs that must be created before the Specification to be developed here can be completed.

Community and Business Group Process
Anything in this charter that conflicts with requirements of the Community and Business Group Process is void.
Choosing a Chair

This group chooses their Chair(s) and can replace the Chair(s) at any time using whatever means they prefer. However, if 5 participants - no two from the same organization - call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).

Participants announce their candidacies. Participants have 14 days to announce their candidacies, but this period ends as soon as all participants have announced their intentions. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. Otherwise, nothing changes.

Participants vote. Participants have 21 days to vote for a single candidate, but this period ends as soon as all participants have voted. The individual who receives the most votes - no two from the same organization - is elected chair. In case of a tie, RFC2777 is used to break the tie. An elected Chair may appoint co-Chairs.

Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
Decision process
This group will seek to make decisions when there is consensus. When the group discusses an issue on the mailing list and there is a call from the group for assessing consensus, after due consideration of different opinions, the Chair should record a decision and any objections.
Participants may call for an online vote if they feel the Chair has not accurately determined the consensus of the group or if the Chair refuses to assess consensus. The call for a vote must specify the duration of the vote which must be at least 7 days and should be no more than 14 days. The Chair must start the vote within 7 days of the request. The decision will be based on the majority of the ballots cast.
It is the Chair's responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favor or discriminate against any group participant or their employer.
Transparency
The group will conduct all of its technical work on its public mailing list.. Any decisions reached at any meeting are tentative and must be confirmed on the mail list.
Amendments to this Charter
The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass.
The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.



Adam M Abramski
Product Planner
Intel Software & Services Group
503-264-8269 (o)
503-550-7910 (m)
adam.m.abramski@intel.com