基於CAN匯流排實現的UDS診斷（DoCAN）

來自專欄汽車控制器(ECU)網路診斷技術交流

之前寫的UDS系列的文章介紹的都是應用層的診斷服務，不涉及下層的傳輸機制，本篇文章簡要介紹一下基於CAN匯流排實現的診斷協議的傳輸層。本文以classical CAN為例，CAN FD原理類似，不單獨講述。

UDS定義的是診斷服務，屬於應用層的內容，實現診斷通信的底層匯流排技術有很多，比如CAN，LIN，Ethernet，Flexray等，由於法規強制的OBD介面是CAN匯流排的，所以絕大多數場景中診斷都是基於CAN實現的。這就帶來了一個問題，classical CAN匯流排物理層的每一幀只能傳輸8個位元組，CAN FD第幀最多能傳輸64個位元組，那麼如果UDS產生的一條診斷命令超過了8個位元組，在CAN匯流排上一幀是承載不了的，就需要進行分包，這也是DoCAN(Diagnose over CAN)要解決的最主要的問題。

為了實現診斷命令的分包傳輸，15765-2總共定義了4種類型的幀結構，每種幀結構以數據域的前兩個或一個位元組來標識（取決於幀類型）。這四種類型分別是：

1. SingleFrame
2. FirstFrame
3. ConsecutiveFrame
4. FlowControl

其中SingleFrame用於長度不超過7個位元組的診斷命令或響應。FirstFrame，ConsecutiveFrame，FlowControl用於傳輸長度大於7個位元組的診斷命令或響應。每個診斷幀的第一個位元組的高4bit用於描述該幀的類型，即該幀屬於上述四種中的哪一種。

SingleFrame用於下面這種簡單的場景：當診斷報文長度小於等於7時，再加上一個位元組的PCI控制信息就是小於等於8，可以在一幀CAN報文上傳輸，所以不需要進行分包。此時數據域的第一個位元組高4bit值為0000，標識這是一個幀SingleFrame，低4bit是SF_DL，即DataLength，描述後面有幾個位元組。如果有沒有使用的位元組，通常要用0x55或0xAA來填充，因為這兩個值的二進位表述其實就是01010101和10101010，這樣在CAN匯流排上可以讓信號跳變得更頻繁一些，不會出現長時間電平不變的情況。

如果一幀CAN報文無法承載一條診斷報文，則需要按照下面的流程進行分包發送：

首先，發送端要以一個FirstFrame開啟通信，告訴接收端還有後續的內容要發，FirstFrame使用前兩個位元組作為PCI信息，第一個位元組高4bit為0001，標識這是一個FirstFrame，低4bit加上第二個位元組用於描述總共發送的數據長度是多少（包括在FirstFrame中和在ConsecutiveFrame中的所有位元組數）。

之後接收端發送FlowControl，告訴發送端能以什麼樣的速度來發送數據，FlowControl第一位元組的高4bit為0011，低4bit為FS，即FlowStatus，第二個位元組為BS(BlockSize)，第三個位元組為STmin（SeperateTime）。FlowControl有0，1，2三種狀態，分別命名為ContinueToSend (CTS)，Wait (WT)，Overflow (OVFLW)。如果允許發送端繼續發送ConsecutiveFrame，則FlowStatus=0；若要求發送端等一會再發送ConsecutiveFrame，則FlowStatus=1，再下次允許sender發送ConsecutiveFrame時，receiver再發一個FlowStatus=0的FlowControl。如果receiver因為資源問題無法接收sender發送的數據，則發送一個FlowStatus=2的FlowControl。

BS指示sender一次可以發送多少個ConsecutiveFrame，當發送ConsecutiveFrame數量達到BS時，需要receiver再次以一個FlowControl開啟下一波的ConsecutiveFrame發送。

receiver根據自身的接收和處理能力使用STmin指示sender在發送ConsecutiveFrame時最小的時間間隔是多少，從而實現流控制。

ConsecutiveFrame就是承載FirstFrame無法完全承載的剩餘數據了，它使用第一個位元組用作PCI，高4bit為0010，低4bit用於標識ConsecutiveFrame的序列號，從1開始，每發送一次ConsecutiveFrame增加1。

不分段傳輸的診斷服務舉例：

request 02 10 03 55 55 55 55 55

response 06 50 03 00 32 01 F4 AA

這是一個請求進入extended session的最簡單的診斷服務，請求和應答都是SingleFrame，加粗的0標識了SingleFrame，後面的2和6表示了這條診斷報文擁有幾個位元組的數據。

分段傳輸的診斷服務舉例：

這是一個讀取DTC的命令和應答。

03 19 02 08 55 55 55 55 （診斷儀發送的SingleFrame的request）

10 33 59 02 19 01 00 07 （ECU以FirstFrame開始傳輸的response）

30 00 00 55 55 55 55 55 （診斷儀發送的FlowControl）

21 09 03 05 02 09 05 04 （ECU發送的ConsecutiveFrame）

22 07 09 05 06 06 09 05 （ECU發送的ConsecutiveFrame）

23 08 03 08 07 01 05 08 （ECU發送的ConsecutiveFrame）

24 07 01 06 08 07 01 0C （ECU發送的ConsecutiveFrame）

25 08 07 01 0D 08 07 03 （ECU發送的ConsecutiveFrame）

26 07 09 08 01 01 09 09 （ECU發送的ConsecutiveFrame）

27 01 07 09 AA AA AA AA （ECU發送的ConsecutiveFrame，此時傳輸結束）

在這裡我把所有傳輸層相關的PCI信息都用粗體標識了。

需要提一下的是，BS和STmin等於0時，表示接收端可以以最快的速度來接收數據，發送端可以一次發送的ConsecutiveFrame數量不受限制。