Is there a protocol definition document for GM vehicles available of use in creating diagnostic VI's

[Hummer1]

I am considering authoring applications using the data available from the automotive computers in todays GM vehicles.  Is there a basic set of parameter lists and or methods documented that is available for doing such development?

Thanks

Hummer1

[EEsRULEtheWORLD · Accepted solution]

Hi, Hummer1.

Today, in-vehicle networks are controlled via an electronic control unit with the CAN (Controller Area Network) interface.  Each device on the network will have a CAN controller chip.  A really great tutorial in understanding this interface can be found here.  

There are two CAN APIs that are used with the NI-CAN driver:

1. Frame = This is the original API for CAN programming.  It provides low-level access to the CAN network.  
2. Channel = This provides access to the CAN network in simple physical units that are easy to use.  Here is a great DevZone article that explains the NI-CAN Channel API in greater depth.

Let me know if you need any more information.  Happy Holidays!

[Hummer1]

Guess I was too quick on the "solution button".  What I need is not the CAN stuff, but the code definitions and protocol for working with the ECU through the diagnostic port.  I don't want to work on the "net" but develop applications using the ECU and the diagnostic port.

Thanks

Hummer1

[O_Proulx]

Hello Hummer1,

You may be looking for something like the Automotive Diagnostic Command Set?  This "abstracts" the CAN out and only lets you focus on the diagnostic part of it.  This should help you communicate with OBD-II to the GM ECU.  You'll also need an NI CAN Interface.  You will only have access to the diagnostics parameters of the cars.  For more on OBD-II, you can see this website to get started.  Note that different manufacturers provide different parameters through this protocol, so you might have to do some research on your particular vehicle.

I hope that helps get you started.      

[Bill_in_Detroit]

Hummer1:

I hope you have a lot of time on your hands as much of what is available at the OBDII diagnostic port is documented (mandated by act of Congress) but what is otherwise available on an automotive CAN network has started to be somewhat obfuscated by the manufacturers in an effort to protect their intellectual property.  There doesn't seem to be any "clearing house" or public place that I know of where you can readily come by the CAN databases (.dbc file) that describe the messages (what NI calls "Frames") and signals (what NI calls "Channels") involved which you would typically come by via an agreement with one of the OEMs or their suppliers.  There are some good reverse engineering tools available that can help you in your quest (and even some that work with LabVIEW - I have written some myself) but it will take you some time to put what you are attempting together.   The Automotive Diagnostic Command Set that O. Proulx points to may be helpful in getting you started, but as far as I know it is limited to what is available at the OBDII port, which is the public minimum that OEMs provide for the repair shops to use in emission control related efforts (the basis for the Congressional act) so it is only a starting point in getting you up and running.   

I don't want to discourage you as what you seem to want to do is a necessary thing.  I woud start by searching your connections for people in the automotive industry and see if you can get some help obtaining the crucial database files.  Failing that, you may be able to get the service manuals for the vehicles of interest.  The manufacturers often define their message sets for some of the low level diagnostics in their publications.  Even if you do not obtain the data base files, decide on a physical interface to use to connect to the network (this depends on your target vehicle - high speed, low speed, single wire [GMLAN uses this], fault tolerant) and which language to use.  I prefer LabVIEW (obviously) for it's ease of use and the support from equipment manufacturers.  NI's USB CAN interfaces are reasonably priced and NI supports their products pretty well.  Also, if you know anyone in one of the many aftermarket "Car customization" shops you may want to ask them how they reverse engineer the signals they need to install their aftermarket accessories.  Although much of this is a black art, you may get pointed in some useful directions by asking.

Besides the NI products, others that manufacture CAN interfaces which are supported with LabVIEW drivers include:

Intrepid Control Systems - NeoVI Fire

KVaser - KVaser Leaf Light

Vector - CANcardXL 

You may want to look at some of these for the free drivers they offer (some of them offer free tools that work with their products) and additional information about CAN, etc. you may glean from ther websites.  I have found that nobody has the whole pie.  However, when you take a slice from here and a slice from there, you can put together an entire pie over time.  I wish you luck and will be here to provide what help I can as time allows.

Bill

[Hummer1]

Thanks, Bill.

I don't want to get beyond the ODBII stuff for all the very well stated reasons you provided.  I just want to find or make something that does a good job of managing all the resourcess that are available through the ODBII port...any links in that direction would be appreciated.

Hummer1

[Bill_in_Detroit]

Hummer1:

I suggest you review everything at http://www.obdii.com/ in addition to the references I gave you in my prior note.  In addition, the Automotive Diagnostic Command Set (ADCS) that NI sells is a quick way of getting a leg up on the subject matter.  Once you are reading what is available on the CAN bus at the OBDII connector it is only a matter of effort before you are ready to move on to messages that are not included in the ADCS or reading messages on the other vehicle busses.  

Bill

"In the land of the blind, the one-eyed man is king"

[Hummer1]

Thanks again, Bill. (or should I say "one eye".)

I'll do that.

Hummer1 (surely part of the blind crowd...! and have been for years)

[Nike_]

Hi, all

To: Bill_in_Detroid

Please I have a question:

1. Using NI Automotive Diagnostic Command Set and interface hardware that NI sells is possible to log onto cars that run under OBDII?

2. There are limitations for realizing this conversation between Personal Computer and Car On Board Computer? (all time using NI hardware and software)

[Bill_in_Detroit]

Nike_:

I'm not sure what you mean by "...log onto cars..." via OBDII, but what is possible is the monitoring of a subset of vehicle CAN frames and the querying of specific information related to vehicle emission controls and processes.  There are ways to read and write to specific electronic control modules in the vehicles over CAN, but they almost exclusively entail the use of proprietary software including handshaking and passwords that are not in the public domain. Also, I have not used the NI Automotive Diagnostic Command Set but I understand it is a good tool for retrieving emissions related vehicle information.