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

RE: Using OBD-II as a base-data set.

From: Abramski, Adam M <adam.m.abramski@intel.com>
Date: Fri, 3 May 2013 03:15:06 +0000
To: Balwinder Kaur <bkaur@aptina.com>, Andy Gryc <AGryc@qnx.com>, Cindy Lewis <cindy.lewis@me.com>, "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
Message-ID: <6AB32C125D193D47AE66073666ED3B5E2AA2836A@FMSMSX153.amr.corp.intel.com>
Hi Balwinder,

Yes it'll be a 1 day meeting.

Sincerely,
Adam

From: Balwinder Kaur [mailto:bkaur@aptina.com]
Sent: Thursday, May 02, 2013 6:36 PM
To: Andy Gryc; Cindy Lewis; public-autowebplatform@w3.org
Subject: RE: Using OBD-II as a base-data set.


I would like to confirm that the Tokyo Meeting is a single day meeting from 9:00 a.m. to 5:00 p.m. as indicated here before I book my flights and hotel.

Thanks,
Balwinder


-----Original Message-----
From: Andy Gryc [mailto:AGryc@qnx.com]
Sent: Thu 5/2/2013 7:48 AM
To: Cindy Lewis; public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>
Subject: Re: Using OBD-II as a base-data set.

I'm not sure we need all the low-level data from OBDII as the point of the API is to abstract that, but I completely agree that we can use the data in the spec as a starting point for what the APIs should deliver.

P.S. I'm booking my flights, and looking for the Tokyo hotel information. Is it available on the Wiki somewhere for those of us who aren't already going to the GenIVI meeting?

--Andy

From: Cindy Lewis <cindy.lewis@me.com<mailto:cindy.lewis@me.com>>
Date: Wednesday, 1 May, 2013 10:19 PM
To: Andy Gryc <agryc@qnx.com<mailto:agryc@qnx.com>>
Subject: Re: Using OBD-II as a base-data set.

Greetings~

Is it possible we could compile all the possible data points and their source, including the SAE J1979 standard Kevron mentioned? Perhaps we could then more easily find the overlapping data points.

Here are the data headers from OBDII:
Mode
(hex)   PID
(hex)   Data bytes returned     Description     Min value       Max value       Units   Formula
Are these headers relevant to other suggested data points? If not, could we agree on some headers and begin compiling the data point suggestions?

Cindy Lewis



On Apr 30, 2013, at 6:04 PM, Andy Gryc wrote:

Hi Kevron,

Exactly right.

I don't think it's necessarily a bad idea to pull in OBDII, but I also think it will be far short of what's ideal. This is why I was pushing us to provide a commonized view of all the "vehicle data" bits that will be in all four proposals. The union of all of the vehicle data would include lots of juicier tidbits that aren't just diagnostic in nature. I know we've all got actions to look at the diffs-I think a reasonable goal would be to have a first draft of this available by the May 29th meeting in Tokoyo.

--Andy

From: <Rees>, Kevron <kevron.m.rees@intel.com<mailto:kevron.m.rees@intel.com>>
Date: Tuesday, 30 April, 2013 5:36 PM
To: "public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>" <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>
Subject: Using OBD-II as a base-data set.
Resent-From: <public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>>
Resent-Date: Tuesday, 30 April, 2013 5:37 PM

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


Aptina, LLC / 3080 North First Street, San Jose, CA 95134.

This e-mail and any attachments contain confidential information and are solely for the review and use of the intended recipient. If you have received this e-mail in error, please notify the sender and destroy this e-mail and any copies.
Received on Friday, 3 May 2013 03:15:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:51 UTC