Because diagnostics is really just a simple way to interact with an ECU, there are a few very common diagnostic services that you’ll find in nearly every permutation of diagnostics.
Definitely the most common service you’ll find, tester present (typically 0x3E) is used to let the controller(s) know that there is a.. wait for it.. Tester present. I know it was a bit obvious, but the idea is that some services keep the controller in an augmented state or a diagnostic state. When this happens there needs to be some way of maintaining that state while the tool that initiated the state is still connected to the diagnostic connector.
So Tester Present is designed to be a heart beet of the diagnostic tool and in the event that the device stops working or is disconnected from the network, the ECU whose state has been altered will stop seeing the tester present message and thus transition out of its altered state.
So if you want to maintain a diagnostic state you should send the tester present message. A typical timeout for Tester Present is 3 Seconds. So as long as you send the message between 1 and 2.5 seconds, you will be able to maintain the diagnostic state of a controller.
Read Data by PID:
Reading data from a controller is pretty much the reason for diagnostics in the first place. So there is no surprise that there are at least two ways to accomplish this task on nearly every new vehicle on the market today. Services 0x01 and 0x22 are used for this purpose.
Service 0x01 is the OBDII Read data by PID (Parameter ID) where the PID is a one byte number representing the data you want to read. Service 0x22 is the Enhanced diagnostic method for reading data. Service 0x22 is typically a two byte PID that represent the parameter you want to read. In some cases this two byte parameter may also be used in conjunction with another Enhanced diagnostic service to write the data as well (however exactly how this is done varies).
Controllers contain data that manufactures do not want just anyone having access to. This is typically to stop strange people such as yourself writing data to the controller to modify how it performs. So in nearly every controller there is a method to “unlock” the data. To perform this, it is done with service 0x27, the security access service.
In order to “unlock” the controller you must first ask it for a Seed. This seed will be used in conjunction with a proprietary algorithm to generate a Key. Then the key will be sent back to the controller. If the calculation that the controller did is the same as the key that you sent, then the controller will send a positive response indicating that the controller is now unlocked.
There may be several levels of Security Access. This is due because they may want certain features available to one group of people such as locksmiths who may need to add a new key to the vehicle while still keeping the other levels secure. So a typically Security Access transaction will have sub-functions that will essentially be the level that you wish to access, these sub-functions operation in Odd/Even Pairs. So sub-function 0x01 will be the seed request and 0x02 will be the key response. Then it’s 0x03/0x04, 0x05/0x06, … 0x21/0x22, etc.
That’s pretty much all that is very similar across all of the diagnostic protocols. Once you’ve learned these three services, you find that they very similar.