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

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

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

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

因?yàn)橥ǔＷx寫ISDU的命令都很長，一個循環(huán)放不下，都是多個循環(huán)來拆包，組包。具體的幾個狀態(tài)如下：

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

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

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

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

T6：如果從站開始回應(yīng)，則停止定時器；

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

T8：全部讀取后，F(xiàn)lowCtrl為IDLE狀態(tài)；

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

T13：通過OD.req來獲取相關(guān)參數(shù)；

T14：在正常PD交互中，采用IDLE的FlowCtrl進(jìn)行OD交互

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

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

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

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

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

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

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

T5：從站回應(yīng)busy

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

T7：等待主站的read命令，開始讀取數(shù)據(jù)，調(diào)用OD.rsp來回應(yīng)主站

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)下，從站回應(yīng)no service的命令

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

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

3 Event事件解析

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

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

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

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

Error/Warning:簡單歸結(jié)為錯誤，故障類，比較嚴(yán)重，該類事件以出現(xiàn)/消失成對出現(xiàn)，如果出現(xiàn)了Error/Warning，需要維護(hù)人員去關(guān)注，直到它消失為止；

Notification：僅僅是通知，不是很嚴(yán)重，可能并不需要關(guān)注，它沒有出現(xiàn)/消失這種機(jī)制，就是見到的SingleShot。

01事件上報(bào)

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

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

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

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

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

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

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

下圖先看一下主站應(yīng)用層的OD模塊：

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

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

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

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

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

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

5應(yīng)用層的OD傳輸序列

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

01 ISDU的傳輸

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

主站AL層調(diào)用DL的DL_ISDUTransport_req函數(shù)

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

從站調(diào)用DL_ISDUTransport_ind函數(shù)對主站的ISDU讀命令進(jìn)行解析；

解析后上送給AL層進(jìn)行數(shù)據(jù)查詢

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

主站接到從站的回應(yīng)，解析報(bào)文，上送APP層。

02 DPP的傳輸

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

主站AL層面調(diào)用DL的DL_ReadParam函數(shù)

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

從站調(diào)用DL_ReadParam函數(shù)對主站的DPP讀命令進(jìn)行解析；

解析后上送給AL層進(jìn)行數(shù)據(jù)查詢

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

主站接到從站的回應(yīng)，解析報(bào)文，上送APP層

03 關(guān)于AL Abort

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

6應(yīng)用層的EVENT模塊

AL應(yīng)用層也有單獨(dú)的Event處理機(jī)制，我們分別看一下主站AL Event和從站的AL Event。

01 主站AL EVENT

02從站AL EVENT

03事件上報(bào)過程

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

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

從站的AL激活EventTrigger服務(wù)，置位EventFlag

主站讀取從站的EventFlag后，開始讀取從站的StatusCode以及相關(guān)EventCode

主站把相關(guān)Event繼續(xù)上報(bào)給網(wǎng)關(guān)，網(wǎng)關(guān)應(yīng)用確認(rèn)事件消息

主站把事件確認(rèn)消息同步給從站，寫入StatusCode信息，即清除事件標(biāo)志，等待下一個事件的上報(bào)

結(jié)語

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