工程中，隨著CAN FD的使用越來越普及，隨之而來的問題，也越來越多。本文討論一個問題：CAN總線既支持Classical CAN格式報文，也支持CAN FD格式報文，診斷的過程中，可以混合使用Classical?CAN格式和CAN FD格式的診斷報文嗎？

1、N_AI定義

找到這個問題的答案之前，我們先理解一下N_AI（Network Address Information）的概念。

15765-2的規范中，這樣解釋N_AI，如下所示：

解釋：意思是說，N_AI這個參數用于識別診斷通信過程中的源地址和目標地址。

解釋：N_AI的另一種作用解釋就是標識網絡層的對等實體（peer entities）。什么是對等實體？

答：個人理解，特定的信息只有到達指定的模塊，才能被解析。也可以將其看作特定協議的解析者，比如：15765，CanTp層才能解析，如下所示：

2、N_AI在CAN報文中的位置

一個N_PDU包含三個部分：N_AI、N_PCI、N_Data。N_AI位于N_PDU中，具體位置如下所示：

具體到CAN Frame，N_AI位置示意如下所示：

這里可以看出：Classical CAN和CAN FD的不同，意味著N_AI的不同。N_AI信息會映射到網絡傳輸層（CanTp），N_AI的不同，意味著尋址方式的不同，即使Classical CAN和CAN FD的CANID相同，CanTp層建立的Connection也不同。

3、相同CAN ID（不同N_AI）的非預期幀處理策略

之前我們聊過：診斷處理過程中，收到非預期診斷報文（Unexpected PDU）的處理方式，可以回顧前文Uds診斷：Unexpected N_PDU處理策略。這個策略適用于相同CANID，但是N_AI不同的診斷報文嗎？看一下15765給出的解釋，如下所示：

解釋：Unexpected N_PDU的處理只適用于相同N_AI的診斷報文。Classical CAN和CAN FD的N_AI本就不同，所以，互不干擾，可以并行處理；單個Message中不要混用Classical CAN和CAN FD。

提示：工程開發中，即使CAN ID相同，也可以既支持Classical CAN，也支持CAN FD。

綜上，Classical CAN和CAN FD的CAN ID相同，但是Format不同，構成的N_AI不同，所以，在CanTp層建立的peer entity不同，工程使用過程中，可以并行使用，但是不能交叉混用。

（一）完整的診斷請求時序中，獨立使用Classical CAN或者CAN FD均可，示意如下：

（二）完整的診斷請求時序中，不能混用Classical CAN、CAN FD，示意如下：

審核編輯：劉清