前言

上篇我們介紹了ISDU的典型編碼格式和應用案例，本篇我們就來詳細介紹下，ISDU的狀態機，并把EVENT事件的邏輯，給大家好好解析下。

01 主站ISDU狀態機

如上圖所示，ISDU的狀態機的核心是請求，等待和響應。

如果主站請求的是DPP參數，即ISDU 0x00，0x01的參數，從AL層還是走的ISDU邏輯，但底層走了DL_Read/WriteParam的邏輯，即走的是Page通道。也就是好端端的ISDU愣是被它拆分了兩個通道，增加了復雜性。

因為通常讀寫ISDU的命令都很長，一個循環放不下，都是多個循環來拆包，組包。具體的幾個狀態如下：

??T2：觸發OD.req開始請求ISDU；

??T3：持續觸發寫請求，請求ISDU數據；

??T4：開始計時器（ISDUTime），查看是否會超時；

??T5：開始讀請求，對之前寫命令的讀請求；

??T6：如果從站開始回應，則停止定時器；

??T7：持續的讀取ISDU數據；

??T8：全部讀取后，FlowCtrl為IDLE狀態；

??T11：如果ISDU錯誤，則觸發ISDUAbort命令，并向DL層確認ISDU錯誤；

??T13：通過OD.req來獲取相關參數；

??T14：在正常PD交互中，采用IDLE的FlowCtrl進行OD交互

??T15：如果通信中斷，消息處理通知DL_Mode處理模塊，需要把ISDU模塊去激活。

02 從站ISDU狀態機

從站ISDU的狀態機和主站的狀態很類似，請求、等待和響應三個狀態缺一不可。

??T1：收到激活事件，從非激活狀態遷移到Idle狀態，等待ISDU的命令

??T2：開始接收ISDU數據，遷移狀態到Request_2

??T3：持續接受數據，因為OD的數據大，而每次循環一般就傳遞1~2個OD數據，需要幾個循環才能傳輸完，每次接收的OD數據需要緩存，等待接收完畢

??T4：所有ISDU接收完畢后，觸發RecComplete事件，進入wait狀態，該狀態下尚未解析完成，如果主站查詢數據，則回應busy

??T5：從站回應busy

??T6：從站做好準備，遷移狀態到Response

??T7：等待主站的read命令，開始讀取數據，調用OD.rsp來回應主站

??T8：發送完成，觸發SendComplete事件，回到idle狀態

??T9：接收到ISDUAbort命令

??T10：接收ISDUAbort命令

??T11：接收ISDUAbort命令

??T12：SM模塊通知ISDU模塊，去激活，回到非激活狀態

??T13：收到ISDU Error消息，回到Idle狀態

??T14：在Idle狀態下，從站回應no service的命令

??T15：如果ISDU Error觸發ISDU Abort

??T16：如果ISDU Error觸發ISDU Abort

03 Event事件解析

介紹完ISDU之后，我們來看一下事件。

事件有時候又稱為診斷，它也是通過OD字段來傳輸，它的發起端雖然是主站來發起請求，但是最初的發起還是從站，從站會在每次傳輸時，在最后字節的一個bit置位，告訴主站自己有事件。

就好像小學生要回答問題，不能自己直接回答，得先舉手示意?????♀?。這時候老師（主站）會問學生（從站），你有什么事情或者你想回答什么問題（事件）嗎？這時候學生（從站）就會把自己的事情（事件）告訴老師（主站）。

Event在協議棧中以16 bit的EventCode存在，每個EventCode表示一個事件的定義；而所有的EventCode又可以分為三類：Error、Warning和Notification。

Error/Warning:簡單歸結為錯誤，故障類，比較嚴重，該類事件以出現/消失成對出現，如果出現了Error/Warning，需要維護人員去關注，直到它消失為止；

Notification：僅僅是通知，不是很嚴重，可能并不需要關注，它沒有出現/消失這種機制，就是見到的SingleShot。

事件上報

如上圖所示，上報事件通過查看從站的內存里的數據來上報，規范規定了一次性最大臨時存6個事件，共占用18個字節，加上一個狀態字節，共19字節。

事件的狀態機

最后看一下事件的狀態機，這個就比較簡單了，主站狀態機如下：

主站的狀態機基本就是Idle和讀事件，讀完確認就結束了。

從站也很簡單，就是觸發事件，讀取事件的時候，要凍結內存，不能讓新事件寫入內存，導致干擾。

結語

好了，本篇總結了ISDU的狀態機以及EVENT事件的業務邏輯，內容有點多，希望大家慢慢消化。