Every CAN message has an Identifier. This is referred to as the Arbitration ID or ArbID. It serves two functions. First, it is to help identify the payload or data of the frame. Second, because no two modules are allowed to send a frame with the same ID, it serves as an arbitration method on which frame gets priority on the bus when two or more messages are sent at the SAME TIME (in other words if a low priority ArbID frame is half-way through sending, a higher priority ArbID will not stop that frame from sending).
So if the ArbID is the identifier of the message, what are Extended IDs? The concept is simple, take the ArbID and add data bytes from the frame as the ID as well. For instance, say you have to messages you want to send: Engine Speed and Engine Coolant Temp. A lot of the time you will see them sent in the same message with the same ID and always in their same respective location in that message. However what if you wanted all of your parameters to occupy byte 5 of every frame, and instead you change out the ID to denote the parameter, but because of application rules you are only allowed to broadcast on a single ID? In this case you would use Extended IDs.
For example your only ID you are allowed to send is ID 0x444 (again this is because of rules imposed by a network design committee not by CAN Bus itself). And you have more data than one frame can possibly hold or you want all of your parameters to be in the 5th byte? In this case you may set byte 1 as your Extended ID and for each parameter you would assign a new ID. So Engine Speed would be 0x0C and Coolant Temp would be 0x05 and Engine Parameter X = 0x06, Y=0x07, etc.
Your Engine Speed Frame would look like this: 0x444 0C 03 00 FF 22 00 00 00 00; where 0x22 Is the engine speed. And for Engine Coolant Temp it may look like this 0x444 05 04 00 FF 10 00 00 00 00; where 0x10 is the Engine Coolant value. So you can see that if you have certain limitations on network IDs, Extended IDs can give you more versatility.
Extended IDs can also be seen in Diagnostics messages as well. For instance Toyota vehicles often use Extended IDs for Diagnostic Requests and Responses. A typical Enhanced Diagnostic Request on Toyota vehicles starts with 0x750 and the first data byte is the Destination Controller Address. Compare this with an OEM that does not use Extended IDs, but rather assigns each ECU Destination address its own Arbitration ID (Ford, GM, Chysler, etc.) The more controllers you have the fewer available Arbitration IDs would be available because they would be taken by Diagnostic Identifiers.
Now you know what some applications are for extended IDs and know that you know, it should be easier for you to identify them when reverse engineering data on the CAN Bus.
