簡介

10服務，即 Diagnostic Session Control（診斷會話控制）服務用于啟用服務器中的不同診斷會話，可以通過會話模式賦予不同診斷服務 不同的執行權限。

診斷會話切換

診斷會話轉換以及服務器轉換到另一個會話時其應做出哪些反應。

流程序號	會話切換前	會話切換后	描述
1	默認會話	默認會話	服務器處于defaultSession（默認會話）狀態時，若客戶端要求啟動defaultSession（默認會話），則服務器應完全重新初始化defaultSession（默認會話）。 激活的會話期間，服務器應重置所有已激活的／初始化的／更改過的設置／控制。這不包括已編程入非易失性存儲器中的長期更改。
2	默認會話	默認會話	服務器從defaultSession（默認會話）轉換為defaultSession（默認會話）外的其他會話時，服務器應僅停止已在defaultSession期間通過ResponseOnEvent（基于事件響應）（Ox86）服務在服務器中進行配置的事件（類似于stopResponseOnEvent（停止基于事件響應））。
3	其他會話	相同會話或其他會話	服務器從defaultSession（默認會話）外的診斷會話轉換為非defaultSession（默認會話）的其他會話（包括當前有效診斷會話）時，則服務器應（重新）初始化診斷會話，這意味著： i) 應停止通過ResponseOnEvent（基于事件響應）（Ox86）服務在服務器中進行配置的所有事件。 ii) 應重新鎖定安全性。注意，鎖定安全訪問應重置依存于待解鎖的安全訪問的任何有效診斷功能（例如，DID的有效inputOutputControl（輸入輸出控制））。 iii) 應維護好新會話中支持的且不依存于安全訪問的所有其他有效診斷功能。例如，從一個non-defaultSession（非默認會話）轉換為另一個或相同的non-defaultSession時，任何已配置的周期性調度器應保持活動狀態，且不得影響CommunicationControl（通信控制）和ControIDTCSetting（控制DTC設置）的狀態，這意味著，切換會話時若正常通信為禁用，則其應保持禁用狀態。
4	其他會話	默認會話	服務器從非默認會話的任何診斷會話轉換為defaultSession（默認會話）時，服務器應停止通過ResponseOnEvent（基于事件響應）（0x86）服務在服務器中已配置的所有事件，且應啟用安全性。應終止defaultSession（默認會話）中不支持的任何其他活動的診斷功能。 例如，應禁用任何已配置的周期性調度器或輸出控制，且應重置CommunicationControl（通信控制）和ControIDTCSetting（控制DTC設置）服務的狀態，這意味著，會話切換為defaultSession（默許會話）時，若正常通信為禁用，則應重新啟用正常通信。激活的會話期間，服務器應重置所有已激活的／初始化的／更改過的設置／控制。這不包括已編程入非易失性存儲器中的長期更改。

除了發送請求可以使Server 切換會話，如果您進入了一個非默認會話的狀態，一個定時器會運轉，如果一段時間內沒有請求，那么到時間（S3Server）后，診斷退回到默認會話01(最低權限)。當然，我們有一個$3E的服務，可以使診斷保持在非默認的狀態。

請求和響應

1、請求

基本格式

歸納起來，診斷的request格式無非以下兩種：

<SID> + <Sub-function> + <Parameter>

<SID> + <Parameter>

即有無sub-function的區別。Parameter可以是DID，可以是輸入參數，可以是自定義的值，字節數視具體要求而定。

2、子功能

子功能參數定義（1字節數據）：

• Bit7：抑制肯定響應消息指示位 suppressPosRspMsgIndicationBit
  • 0=False：需要肯定響應
  • 1=True：禁止肯定響應
• Bit6-0：子功能參數值（0x00~0x7F）

3、肯定響應

基本格式：

<SID + 0x40> + <Sub-function> + <Parameter>

<SID + 0x40> + <Parameter>

要注意，第一個字節是由SID和0x40的和構成。這里的Parameter項是optional的，具體要看協議規定。

4、否定響應

基本格式:

<0x7F> + <SID> + <NRC>

看起來比較簡單，格式比較固定，只要是Negative Response，第一字節就是0x7F，第二字節照抄原來的SID，第三個字節是錯誤響應碼，指示具體錯誤響應的原因

5、特殊的NRC

這里提一下一個特殊的NRC——0x78，requestCorrectlyReceived-ResponsePending（RCRRP，請求已被正確接收-回復待定）。

這個NRC表明請求消息被正確地接收，請求消息中的所有參數都是有效的，但是要執行的操作還沒有完成，Server端還沒有準備好接收另一個請求。一旦請求的服務已經完成，服務器應該發送一個積極的響應或消極的響應，響應代碼應與此不同。這個NRC的消極響應可以被Server端重復，直到被請求的服務完成并且最終的響應消息被發送。

https://zhuanlan.zhihu.com/p/37310388?utm_source=com.alibaba.android.rimet

為什么劃分不同會話

因為權限問題。默認會話權限最小，可操作的服務少；擴展模式通常用于解鎖高權限診斷服務，例如寫入數據/參數、讀寫診斷碼；編程模式用于解鎖bootloader相關的診斷服務，即程序燒錄。

題外話，講個故事。這三個會話模式好比普通項目成員（默認會話）、項目組長（擴展會話）和會計（編程會話）的關系，小職員權限最小，小職員有的權限項目組長全有，項目組長還多了些其他的高端權限（如寫數據、例程控制）。會計則不同，它有些自己獨有的權限（刷寫程序），但項目組的很多權限它沒有（讀/擦故障碼），因為它只干會計相關的事，本身不參與項目。

下圖僅供參數：

報文示例

Tx / Rx	Can Data	描述
	Byte 7 - Byte 0
Tx	02 10 02 XX XX XX XX XX	0：單幀 2：2個有效字節長度 10：10服務 02：編程會話 請求切換到編程會話
Rx	06 50 02 00 32 01 F4 XX	0：單幀 6：6個有效字節長度 50：SID + 0x40 00 32：P2server_max = 50ms 01 F4：P2*Server_max = 5000ms 回復肯定響應，并且回復 P2server、P2*Server 時間參數

UDS中常用 NRC

參考

• https://blog.csdn.net/wto9109/article/details/121345955
• https://zhuanlan.zhihu.com/p/37310388?utm_source=com.alibaba.android.rimet
• http://www.360doc.com/content/12/0121/07/30375878_1052846532.shtml