W3C home > Mailing lists > Public > public-autowebplatform@w3.org > April 2013

Using OBD-II as a base-data set.

From: Rees, Kevron <kevron.m.rees@intel.com>
Date: Tue, 30 Apr 2013 14:36:36 -0700
Message-ID: <CAFW5wYaAD1WYwcQk3wzcf1MVZPckevDr13BkUqZen0CGT=5AXA@mail.gmail.com>
To: public-autowebplatform@w3.org
Hi all,

There was a suggestion at the face to face in Barcelona about using the
OBD-II standard as a base to start the vehicle data api.  The reasoning
behind this is that OBD-II support is mandated in the US for 1996 vehicles
and beyond.  Other countries have similar standards (ie, EOBD in Europe)
thus it is a universal standard set of data.  I have a few reasons why this
isn't the case and other reasons why we should not look at only OBD-II data.

First, OBD-II is an SAE standard (J1979) that is used primarily for
diagnostic purposes.  If you look at the list of "pids" (
http://en.wikipedia.org/wiki/OBD-II_PIDs) you will notice that primarily
diagnostic data is addressed.  From my personal experience working with
OBD-II and developing applications that use OBD-II data, I can tell you
that not all of these pids are interesting to developers.  For example, pid
0118 is a sensor for Oxygen sensor voltage.  This may not be very
interesting to developers.  Furthermore, there are bits of data available
on CAN that are not available in the OBD-II standard that would be very
interesting to developers for example, geolocation data (latitude and
longitude).  It'd be really hard to write a navigation app without access
to that kind of data.

In short, I think OBD-II has interesting data and we should include those.
 But I think there enough uninteresting pieces of data that would make
using the entire spec as a starting point excessive.  I think the starting
point should be at least backed by some number of use-cases.  The API is
deficient if some of the most popular automotive applications (navigation,
music, etc) can't be written using it.

Received on Tuesday, 30 April 2013 21:37:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:34 UTC