- From: Rees, Kevron <kevron.m.rees@intel.com>
- Date: Tue, 30 Apr 2013 14:36:36 -0700
- To: public-autowebplatform@w3.org
- Message-ID: <CAFW5wYaAD1WYwcQk3wzcf1MVZPckevDr13BkUqZen0CGT=5AXA@mail.gmail.com>
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. cheers, Kevron
Received on Tuesday, 30 April 2013 21:37:07 UTC