CAN-bus

[Jens Knickmeyer]

I am not Mr. Dammeyer but...

AFAIK, there is NO standard distribution scheme. When an ECU is developped at Bosch,
ETAS, dSpace or so, they can use whatever IDs they want. Of cource, nobody can
deal with such stuff, so there are other standards. One is CANdb, a file format
by Vector Informatik GmbH. That file works for freerunning ECUs only. It lists every
ID and the encoding scheme of measurement values in the data section of the CAN
message. For example, there are signed/unsigned, data legth, start bit and scaling
information in that file. If you want to measure ECU data, you simply use an application
which can deal with the CANdb format (let's say "Vector CANalyzer"), import your
CANdb file and setup your display or graphic view. That's it. Connect the ECU to power,
start the CANalyzer et voila, there you have your data. CANdb has become a standard
in automotive industry and is used by (e.g.) VW, DaimlerChrysler, BMW, Volvo, Saab,
MAN, Audi etc. CANdb files usually have an extension ".dbc"

Another approach is the ASAP-2 standard. This is a file which also describes ECU data,
but it is suitable for non-freerunning ECUs. The ASAP2 files (extension ".A2L") are much
bigger (8 MB is not quite seldom) and describe nearly everything. An A2L file lists which
protocol is used by the ECU (e.g., CCP and/or KWP2000). For each protocol, the details
are listed. For CCP this would be CRO (command request object), DTO (data transmission
object), DAC-lists and the signals for each list, scaling data for each signal and so on.

When ECUs were mainly using freerunning mode and therefore described by CANdb files,
manufacturers had a company standard for IDs. For example, message identifier 1024
contained engine temperature, air temperature, revs and accelleration, each in 16 bit
signed motorola backward format. Today where ECUs are more and more using the more
sophisticated protocols KWP2000 and CCP, noone really seems to care for such standards.
Engineers expect software to deal with ASAP-2 files and let them chose the signals to be
logged/viewed from a Windows frontend. 

For private use, it is nearly impossible to deal with the new ECUs using CAN and do a few
investigations. When you say "I should be able to identify each identifier just by looking at the data"
then you should be aware of multiplexing being used in CAN messages quite often to reduce
bandwidth. But even for commercial use, there are data aquisition tools missing. There will
soon a device being presented which basically deals with the ECU via CCP or KWP or other 
protocols ) and produces a freerunning output on CAN, thus ensuring that exisiting tools based
on freerunning mode will work even with the new protocols.

Hope this helps more than it confuses...

Jens Knickmeyer

----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org