The first part of all this is understanding UDS layers. Lets assume underlying transport is CAN bus. In UDS transport layer over CAN, ISO 15765 standard defines the CAN frame timing and structure. In ISO 14229, UDS application layer over CAN, the UDS services are defined. These are 30+ services that operate on request-response basis. The services are defined by a 1-byte identifier like 0x22 ReadIdentifierByID or 0x2E WriteIdentifierByID.
UDS stands for Unified Diagnostic Standard. It's a diagnostic standard used for Vehicle diagnostic and is part of both Autosar architecture and OBD(OnBoard Diagnostics).According to 7-layer ISO OSI networking stack, UDS application and transport layer is defined in ISO 14229 and 15765 documents. Integrating UDS in a firmware means you develop UDS transport and application layers over base transport layer like CAN/LIN/ FlexRay etc.
A tyical UDS transaction looks like a request with service ID and respected data. To this request UDS server responds with response ID and response data.
There are couple of specific terms in use here. One is Tester or Diagnostic Tester. This is the UDS client. The UDS server component is integrated into the vehicle firmware. Lets call it the UDS Server.
A typical UDS transaction on CAN looks like:
Request: 03 22 F1 95
Response: 07 62 F1 95 04 03 02 01
Here this response is positive response. The four bytes after F1 95 is the response. First byte always contains the length of the UDS frame. For a positive frame the request service identifier is added 0x40 and sent in response.
This is basic of UDS. Lets take a deeper look in further posts.