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>
Date: Wednesday, 1 May, 2013 10:19 PM
To: Andy Gryc <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>
Date: Tuesday, 30 April, 2013 5:36 PM
To: "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
Subject: Using OBD-II as a base-data set.
Resent-From: <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