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

1主站ISDU狀態(tài)機

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

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

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

T2：觸發(fā)OD.req開始請求ISDU；

T3：持續(xù)觸發(fā)寫請求，請求ISDU數據；

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

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

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

T7：持續(xù)的讀取ISDU數據；

T8：全部讀取后，FlowCtrl為IDLE狀態(tài)；

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

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

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

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

2 從站ISDU狀態(tài)機

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

T1：收到激活事件，從非激活狀態(tài)遷移到Idle狀態(tài)，等待ISDU的命令

T2：開始接收ISDU數據，遷移狀態(tài)到Request_2

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

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

T5：從站回應busy

T6：從站做好準備，遷移狀態(tài)到Response

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

T8：發(fā)送完成，觸發(fā)SendComplete事件，回到idle狀態(tài)

T9：接收到ISDUAbort命令

T10：接收ISDUAbort命令

T11：接收ISDUAbort命令

T12：SM模塊通知ISDU模塊，去激活，回到非激活狀態(tài)

T13：收到ISDU Error消息，回到Idle狀態(tài)

T14：在Idle狀態(tài)下，從站回應no service的命令

T15：如果ISDU Error觸發(fā)ISDU Abort

T16：如果ISDU Error觸發(fā)ISDU Abort

3 Event事件解析

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

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

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

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

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

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

01事件上報

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

02事件的狀態(tài)機

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

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

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

4 應用層的OD模塊狀態(tài)機

前面提到的EVENT狀態(tài)機和ISDU狀態(tài)機，這倆都屬于OD這個模塊的內容，OD又分為數據鏈路層和應用層兩塊，下面我們就展開聊一下應用層的OD和EVENT部分。

下圖先看一下主站應用層的OD模塊：

從這個狀態(tài)機，我們看到AL應用層的OD部分，僅僅包含了ISDU和DPP兩方面。

對于index 00和01的讀寫，劃歸到DL Param部分，對于其他的劃歸于ISDU部分，當主站發(fā)起AL Service時，協議棧開始構建DL Service，根據index來確定是走左邊，還是走右邊。

當進入await狀態(tài)時，不允許第二個AL Service來訪問，否則就會被禁止，直接告知客戶主站正忙。

再來看下從站AL的OD模塊，如下圖所示：

從站和主站類似，也有await狀態(tài)；對于參數的讀寫分別進入await_AL_Write_rsp_1和await_AL_Read_rsp_2；而對于ISDU的讀寫，則進入Await_AL_RW_rsp_3。

四個狀態(tài)如下：

5應用層的OD傳輸序列

那么主站和從站的ISDU和DPP是如何交互的呢？

01 ISDU的傳輸

主站APP發(fā)起讀取ISDU參數（Index>1）指令；

主站AL層調用DL的DL_ISDUTransport_req函數

主站DL層把命令封裝到消息中發(fā)送給從站

從站調用DL_ISDUTransport_ind函數對主站的ISDU讀命令進行解析；

解析后上送給AL層進行數據查詢

上層的App進行數據讀取，返回給AL層并繼而由物理層發(fā)給主站

主站接到從站的回應，解析報文，上送APP層。

02 DPP的傳輸

主站APP發(fā)起讀取DPP參數（Inde≤1）指令；

主站AL層面調用DL的DL_ReadParam函數

主站DL層把命令封裝到消息中發(fā)送給從站

從站調用DL_ReadParam函數對主站的DPP讀命令進行解析；

解析后上送給AL層進行數據查詢

上層的App進行數據讀取，返回給AL并繼而由物理層發(fā)給主站

主站接到從站的回應，解析報文，上送APP層

03 關于AL Abort

查詢ISDU是有時間限制的，如果查詢從站的ISDU沒有在規(guī)定的時間內返回，則主站發(fā)送一個Abort命令，終止ISDU的查詢。

6應用層的EVENT模塊

AL應用層也有單獨的Event處理機制，我們分別看一下主站AL Event和從站的AL Event。

01 主站AL EVENT

02從站AL EVENT

03事件上報過程

從站的App創(chuàng)建一個事件，并開始發(fā)送請求信息

該請求信息從AL傳遞到DL層，并把事件緩存到內存中

從站的AL激活EventTrigger服務，置位EventFlag

主站讀取從站的EventFlag后，開始讀取從站的StatusCode以及相關EventCode

主站把相關Event繼續(xù)上報給網關，網關應用確認事件消息

主站把事件確認消息同步給從站，寫入StatusCode信息，即清除事件標志，等待下一個事件的上報

結語

好了，本篇總結了ISDU的狀態(tài)機和EVENT事件的業(yè)務邏輯，以及對AL應用層的OD和Event做了介紹，內容有點多，希望大家慢慢消化。