DAWN: Data Acquisition With In-Vehicle Networks
HEM Data Products

HEM Data eNews

Converting Cryptic Network Messages to Engineering Parameters
DAWN text
Rick Walter Acquiring data from the in-vehicle network can be a tedious process, since network data are coded values that are buried inside cryptic messages. In some cases the messages need to be requested, and other cases not. In contrast, the tester thinks in terms of scaled engineering parameters, and desires isolation from network messaging details. In short, the user wants to acquire data from the in-vehicle network as easily as acquiring data directly from sensors.

The solution is the database. An effective database unburdens the user from messages and lets the user select parameters to acquire by name. A database stores all the parameters’ details –including the request header, scaling and message info – and the information only needs to be entered once.

The most challenging issue in acquiring data from the in-vehicle network is obtaining a database that relates the parameters of interest to acquired messages. This is vital for acquiring data from the in-vehicle network.

So where do we obtain this critical database that we need to acquire scaled engineering data? And how do we know how fast we can acquire the data?

There are four database sources, each with their own capabilities and drawbacks.

The simplest database is OBD-II Legislated Diagnostics. This database is an SAE standard, but is limited to 96 parameters concerning emissions. Vehicles typically have around 40 OBD parameters. An important point is that it has an aggregate sampling rate of 20 samples per second. For example, if 10 parameters are being acquired, each will come at 2 samples per second. The OBD-II database communicates primarily with the engine and transmission controllers only.

Next there is Enhanced Diagnostics. This database is targeted to service scan tools, but has significant benefits for data acquisition since it communicates with all controllers on the vehicle, has many hundreds of parameters to acquire, and has an optional high speed test mode where data can be acquired up to the controllers’ maximum sample rate of 250 samples/sec.

The third database option has real-time vehicle data in the form of Normal (a.k.a. Standard) messages. However, the information to decode these messages is kept confidential by the OEM and is generally stored in a .DBC database format. A tester must have an affiliation with the OEM in order to receive this type of database. The major benefit of these messages is that they are the actual data that the controllers use during the operation of the vehicle. In this way, they are unlike the two diagnostic messages described above and come in real-time. This is also the only message type that does not require request messages.

For heavy duty applications, the SAE J1939 database lists both the diagnostic and normal messages. It contains almost 2000 parameters and most of them are normal messages which make it easier to acquire data from heavy duty vehicles. A typical vehicle has hundreds of parameters.

The fourth database source is Direct Memory Reads (DMRs) of each controller. This database is quite complete, however it is even tougher to get than the one for the Normal messages.

The most challenging issue is to have access to the database that has the parameters you need. HEM Data has the ability to acquire data using all four database types. It also merges various databases into one. For example, Normal Messages, DMRs and Enhanced Diagnostic data can all be acquired at the same time. DAWN acquires data from multiple controllers simultaneously up to the maximum rate of the controllers’ data output. It also determines the messages that are actually on the vehicle, so you don’t have to conduct a trial-and-error process to determine the active parameters. DAWN makes data acquisition from the in-vehicle network a much easier process.

Click here to learn more about DAWN.

© 2009 HEM Data Corporation. All Rights Reserved. 1 800 436 4330