At some point I was given to understand that the CAN IDs map
either to individual ECUs, or to a "broadcast" type of thing
that I believe is that 7DF id. There was some fairly defined
set of ECU types, something like 7E0 for engine, 7E1 for trans,
etc -- but I don't know if that's standard or how rigidly the
manufacturers have to adhere to it. And in the answers, the ID
winds up with another bit turned on so if the engine ECU is
queried at 7E0 the answer comes from 7E8 [don't quote me on that,
I'm just parroting some stuff I read somewhere]. And that's
just in the CAN layer -- these extra query/response differentiator
bits happen elsewhere too, such as in the OBD-II layer where
a query for PID 00 goes in as 00 and comes out as 40 with a
bit to indicate "this is a response".
.
The protocols involved in all of this have been a *nightmare*
in the industry since their inception, and there are some groups
vigorously trying to standardize this to the point where any
independent auto tech can use off-the-shelf tools to get all the
diag info they need, and also re-flash firmware into ECUs when
needed via something called J2534 "passthrough" protocol. See
the
NASTF website for a glimpse of what they're up against. The
car manufacturers grudgingly allow for a minimum set of standard
data exchange [such as generic OBD-II to carry emissions info]
but over and above that they just arrogantly assume they can
do whatever they want and either not document it or make some
of it available at a very dear price. It really sucks.
.
_H*
Linear Mode
