Being able to talk to the vehicle over standard OBD does not by itself complete a fault diagnosis. On this 2009 W204 C63 we wanted information from SAM, EIS and ESP in addition to what standard OBD gave us. So we prepared manufacturer-specific diagnostics using the OBDLink EX we already had.

What is finished so far is the read software and its offline verification. We have not yet read SAM, EIS or ESP on this vehicle.

SAM is the signal acquisition and actuation module, EIS the electronic ignition switch, and ESP the vehicle's electronic stability program. The aim is to check the state of these systems, which the standard OBD capture did not examine.

Where the preparation stands #

Adapter capability versus vehicle-specific definitions #

The first thing we sorted out was the difference between what the adapter can do and how a particular vehicle is diagnosed. Even with hardware that can connect to CAN, you still need to know which destination to address, over which protocol, and what to request. You also have to understand the format and meaning of what comes back. "The device supports CAN" alone does not let you conclude that a particular model year's SAM can be diagnosed.

The official OBDLink documentation describes ISO-TP, which carries segmented messages over CAN, as well as receive filters and flow-control settings. These are the foundation for building the read process. On the other hand, ECU address tables for each vehicle and descriptions of fault codes are not something that documentation provides. Here too, we kept checking the hardware specification separate from researching the vehicle's communication definitions. (OBDLink official specification)

Preparing candidates from another vehicle's data #

For the EIS and ESP candidates we used communication records from a 2011 C207, published by the original developer. They contain specific transmit and receive routes, diagnostic sessions and responses to fault-code requests. However, that is a different vehicle from our 2009 W204 C63. That the material contains measured values, and that its settings fit the car in front of you, are two separate things to verify. The implementation keeps the label "candidate" and does not run these routes by default. (MBLINK published definitions, C207 response record)

The format of the published record also had limits. What it holds are tidied diagnostic messages, not raw CAN frames. From that record alone you cannot determine the segmentation control information or whether extended addressing is used. Next time we need to save the actual responses and check not only the destinations but the frame format as well.

For SAM, we have found no confirmed route usable on this vehicle, front or rear. Rather than assigning another model's addresses as they are, we added a stage that first obtains identification. The design uses the rule for candidate routes found in public material and checks a small number at a time. Normally it targets six slots at once, and it does not automatically sweep all 47 routes. The number of candidates does not mean the number of modules that have been measured.

Only a fixed identification request is sent to unidentified routes. Even if a response comes back, the software does not automatically go on to read fault codes or change session from there. Only after checking the returned identification string and further evidence is the route added to the vehicle's definitions. If there is no reply, the destination, protocol, power state and so on still need checking. A lack of response alone cannot establish that SAM is faulty.

Distinguishing response states #

Even when something is received, how the result is classified matters. We separated a fault-code list that correctly comes back empty from one that could not be obtained. NO DATA, a negative response, response pending and a truncated response are each recorded as what they are.

UDS (Unified Diagnostic Services) is the diagnostic service through which ECUs and diagnostic tools exchange information. In its fault-code responses, we check by length that each code is paired with its status information. Even if something that looks like a code is visible, if the final status byte is missing it is not accepted as a completed result.

This distinction also helped when reviewing the processing that AI generated. Using a simulated response in which a CAN error is mixed into an otherwise normal empty list, we verified that it is not judged as zero. Communication errors are checked first, and the capture stops while keeping the raw data. Before producing a readable summary, the response has to be confirmed as valid. Manufacturer-specific codes whose meaning we could not confirm are not given guessed descriptions.

Run conditions and offline verification #

Note that even "read-only" operation sends requests to the vehicle. Standard OBD is also communication in which information is requested and responses received. When receiving segmented responses, the necessary flow-control messages are sent as well. In this design the read requests are fixed, and clearing DTCs, ECU reset, security access, writes, actuator tests and the like are not on the allow-list. Changing the diagnostic session requires a separate explicit option and is limited to the EIS and ESP candidate routes for which there is documentation.

The next on-car mode requires key on and engine off, a stable power supply, and an explicit instruction to run candidates. It matches the connected device and the target vehicle, and keeps checking voltage during the run. The default minimum voltage of 12.0 V and the 30-second limit for additional requests are stop conditions decided for this software, not values that can be quoted as manufacturer service specifications. Even when conditions are not met, the design keeps the evidence gathered up to that point.

The 51 tests that passed so far are offline verification using a simulated device and responses in memory. Zero requests were sent to the car in this manufacturer-diagnostic preparation. We checked handling of segmented responses, wrong targets, voltage drops, forbidden requests, truncation and more, but these are not tests that prove real Windows port I/O or successful manufacturer diagnostics on the W204.

What AI helped us move forward was organising the documentation, implementing the candidates and verifying behaviour including abnormal responses. Next we need to confirm whether the candidate routes work on the real car, which ECU is answering, and whether the responses can be assembled correctly. Only items for which those results are in place will be adopted into the vehicle's configuration; anything unconfirmed will continue to be treated as unconfirmed.