Because diagnostic data is built on top of a standard Transport Protocol (ISO 15765-2), you can use this knowledge to see which diagnostic service a particular vehicle supports and which parameters or sub-functions it may support.
Step 1. Finding Nodes’ Diagnostic IDs.
We must first have all of the nodes enumerated with Physical IDs and their respective response IDs (Note: sometimes there may be an ID that is a Functional ID. That means more than one node will respond to request sent on this ID). To do this I usually send the Tester Present Request (Service 0x3E) to each CAN BUS ID. If you are working with a 29bit system this may be daunting simply because of how many possible IDs there are; you may have to find a shortcut instead of request each ID. However on 11bit systems this is quite easy.
Start by sending tester present to ARB ID 0x001. This message would typically look like this:
0x001 01 3E 00 00 00 00 00 00 OR 0x001 02 3E 01 00 00 00 00 00. Try them both and see which works. Next simply increment your arbitration ID by one: 0x001, 0x002, 0x003, … 0x7FF. You will know that a node has diagnostics on it because you will see a response from the node after you send your request. You would typically see this: 0x7E8 01 7E 00 00 00 00 00 00. The 0x7E is the positive response to your 0x3E request (tester present). Write down (or log) the request ID AND the response ID and save them for later. Essentially the request ID is how you query the controller and the response ID is data you will get back from that specific controller. Keep in mind that you may get some CAN BUS errors. This is to be expected, but should not cause concern. You may also have some strange affects on the car such as a windshield wiper move or blinker kick in. This is because you are sending data on the bus that is interpreted by other controllers and you may have inadvertently activated another command. Cool, huh?
Step 2. Finding Supported Services.
This can be a bit tricky only because some services may require a certain message length (i.e. you may have to have 0x04 in the first data byte in order to get a positive response from the controller), but this is usually not the case. In order to do this you must remember that the service ID for a diagnostic command is found in the second byte (ARBID, B1, B2, B3, etc). So your first request might look like this: 0x7E0 01 01 00 00 00 00 00 00, where byte 2 contains the service. In this case we are not sending any protocol data. Diagnostic services are broken into ranges. This is because the request IDs and positive response IDs don’t over-lap, and since we are not interested sending the responses, we can remove the positive response IDs from the services we will request. Service request IDs are as follows: 0x01-0x3E, 0x80-0xBE. (0x3F is reserved, 0x7F is for negative responses and 0x40-0x7E and 0xC0-0xFE are reserved for positive responses coming back from the ECU).
Now that we know what our range is, we can simply send a request and based on its response we will know if this is a service that is supported. We send 0x7E0 01 01 00 00 00 00 00 00 and we get back 0x7E8 03 7F 01 12 00 00 00 00. The response is a negative response because there is a 0x7F in the second data byte. This tells us that there was a problem with our request, but does NOT mean that the service is not supported. We have to look at byte 4 to see why our request failed. In this case we got a 0x12 Negative Response Code (NRC). 0x12 means Sub-Function not supported (please see list below for other NRCs). So it’s telling that the service IS support but the sub-function (which we didn’t send one in this case) is not supported. In fact we can ignore all NRCs except 0x11 and 0x78. NRC 0x11 means that the Service is Not Supported. This gives us a definitive NO that we cannot use this service on this controller. NRC 0x78 doesn’t tell us anything, yet. In fact it means Response Pending. It may response later with another NRC or with a positive response. Other than a NRC 0x11, a simple No-Response will tell you that the controller does not support your service. Simply waiting around 100 milliseconds (ms) will be sufficient proof that the particular service is not supported on your controller.
Step 3. Finding Parameters.
This is the most dynamic of steps. It requires some understanding of the service that you are working with. For example, you may be using a service that has a sub-function or a service that has a parameter and this parameter may be 1 byte, two bytes, three, etc. So you will have to prepare yourself for a lot of negative responses (I hope you don’t fear rejection).
So here is what we do now, send our request but increment the bytes,
0x7E0 02 01 00 00 00 00 00 00,
0x7E0 02 01 01 00 00 00 00 00,
0x7E0 02 01 02 00 00 00 00 00, etc..
If you are getting positive responses back from the controller, then you have won. However if the controller is sending back negative responses then you’ll have to adapt. For instance you may get a NRC 0x22, this means “Conditions Not Correct, Sequence Error”. This NRC is particularly vague. It typically means that you must send a Start Diagnostic command first or that the key must be in the ignition, or that Venus and Mars must be in alignments. So you will just have to work with what you have. But if you get a NRC 0x12, you will know right away that this sub-function or this parameter ID is not supported by this controller and you can move on to the next one.
As you can see the trick is to automate this process. To write each message and handle each repsonse can be difficult.
|$11||Service Not Supported|
|$12||Sub Function Not Supported – Invalid Format|
|$22||Conditions Not Correct Or Request Sequence Error|
|$31||Request Out Of Range|
|$36||Exceed Number Of Attempts|
|$37||Required Time Delay Not Expired|
|$78||Request Correctly Received-Response Pending|