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

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

From: Van der Kroft, Lukas, Vodafone Americas <lukas.vanderkroft@vodafone.com>
Date: Sat, 25 May 2013 13:13:21 +0000
To: "Spika, Marius, Dr. (K-EFFI/A)" <marius.spika@volkswagen.de>, Andy Gryc <AGryc@qnx.com>, Cindy Lewis <cindy.lewis@me.com>, "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
Message-ID: <vpaxcc9di5aiif37rhuilel0.1369487023235@email.android.com>
Is the api effort limited to infotainment?  My understanding was that it is broader.

Question for marius: are there additional obd capabilities oems can access through obd which are not exposed generally today?

If yes, Are there conditions under which oems may allow access to these (eg payment, control)?

It appears to me we should not exclude any data from the api just because we dont see a use case yet.



-------- Original message --------
From: "Spika, Marius, Dr. (K-EFFI/A)" <marius.spika@volkswagen.de>
Date: 05/24/2013 9:56 AM (GMT-05:00)
To: Andy Gryc <AGryc@qnx.com>,Cindy Lewis <cindy.lewis@me.com>,public-autowebplatform@w3.org
Subject: AW: Using OBD-II as a base-data set.


Dear all,

I have discussed the idea of taking the OBD data as a starting point for the standardization with my colleagues.
What I have learnt is that not all PIDs are implemented in all cars. That’s why OBD contains for instance on PID 0 information about supported PIDs. There seems to be a list of mandatory PIDs for the US market that contains less than 10 data values such as vehicle speed, engine RPM, accelerator pedal position, engine load value, engine coolant temperature. Please feel free to correct me.
Our W3C business group argument for using OBD data (even though most of the data is not relevant for the vehicle infotainment) is that all data is already well defined and implemented by all OEMs. As this is not the case for whole OBD data set, it might be reasonable to take the US mandatory OBD data set as a starting point and extend it (also beyond the OBD data set) in the next specification phases. This is something we should discuss.

Best regards,
Marius


Von: Andy Gryc [mailto:AGryc@qnx.com]
Gesendet: Donnerstag, 2. Mai 2013 16:49
An: Cindy Lewis; public-autowebplatform@w3.org
Betreff: 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
Received on Monday, 27 May 2013 10:33:53 UTC

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