1. InputOutputControlByIdentifier (0x2F)----通过ID对输入输出进行控制

   2F的03子功能是"暂时接管控制权"

2. ReadDataByIdentifier(0x2A)—通过ID读取数据或特定器件状态

3. ClearDiagnosticInformation(0x14)—清除故障诊断信息

   UDS规定用FF FF FF表示所有种类的DTC

4. RoutineControl (0x31)—例行程序控制服务

   $31服务是调用ECU内置的一些操作序列的接口

5. RequestDownload （0x34）：诊断仪向ECU请求下载数据

6. **RequestUpload （0x35）**诊断仪向ECU请求上传数据

7. TransferData（0x36） 诊断仪向ECU传数据（下载），或者服务器向客户端传数据（上传）

8. **RequestTransferExit（0x37）**数据传输完成，请求退出

9. RequestFileTransfer（0x38） 传输文件的操作，可以用于替代上传下载的服务。

10. ECUReset (0x11) 请求ECU重启

    ECUReset 这条指令的用途是通过诊断请求使ECU重启。

    01 硬件复位

    02 模拟点火开关复位

    03 软件复位

11. SecurityAccess(0x27) 安全访问

12. **ControlDTCSetting (0x85)**该服务用于控制ECU的DTC（diagnostic trouble code，故障诊断码）存储，这个服务常常和前面提到的28服务一起使用

13. **ResponseOnEvent (0x86)**尽管诊断通信过程是问答式的，诊断仪发请求，ECU给响应

14. **LinkControl (0x87)**这个服务用于转化ECU数据链路层和物理层的状态，验证ECU是否支持要调整到的目标波特率

15. 详细服务ID
    
    否定响应码:
    

Positive response肯定响应的格式是由三部分组成，其中的response SID这个字节作为诊断请求的echo，回复[SID+0x40]，例如请求10，响应50；请求22，响应62，回复的是一组数据。后面的两个字节分别为子功能及其他，视具体的诊断服务而定。

Negative response否定响应的格式固定为3个字节，回复[7F+SID+NRC]，第一个字节为0x7F，第二个字节是被拒绝掉的SID，第三个字节是NRC否定响应码。比如，若ECU给出7F22 13这个negative response，则说明SID=22这个服务因为诊断请求数据长度不对（NRC=13）的原因而无法执行。

举例:
对该片段报文进行解析

10 表示连续帧的第一帧(First Frame),FF_DL表示第一帧数据长度，N_data表示报文数据

Byte1:
30 表示流控帧
FS(Flow Control):
FS=0:表示允许发送方继续发送连续帧;

FS=1: 表示发送方需等待下一条流控制帧[1]，该流控制帧称为等待流控制帧;

FS=2: 表示报文长度超出接收方的网络层缓存大小，此流控制帧将迫使发送方中断多帧报文的发送，并且发送方网络层使用N_USData.con向应用层报告N_Result = N_Buffer_Overflow。FS = Overflow的流控制帧接收方只能在接收到第一帧后发送。

Byte2：
BS(Block Size)—块的大小(允许连续传输帧的数目,下一次需接受方发送流控制帧)

BS=00: 表示允许发送方连续发送连续帧，而不需要等待接收方发出的流控制帧;

BS>=01||BS<=FF: 表示允许发送方连续发送连续帧的数目，发送完成相应数目的连续帧后，发送方必须等待接收方发出的流控制帧;

BS为当前接收数据的数据长度,通过控制数据长度来防止通道堵塞;

Byte3:
STmin(Separation Time minimum),最小间隔时间

---

20一定跟在2F之后的一帧，并且20也带有数据

---