4、狀態(tài)與工作流類設計模式

4.1 狀態(tài)與事件

行為隨條件變化而改變，這里狀態(tài)切換的模式也稱為狀態(tài)機。有限狀態(tài)機 (Finite State Machine，F(xiàn)SM) 是由3 個主要元素組成的有向圖: 狀態(tài)、轉換和動作。

狀態(tài)是系統(tǒng)或者元素的狀態(tài)；轉換是從一個狀態(tài)到另一個狀態(tài)的路徑，通常通過感興趣的事件初始化，當元素處在前驅狀態(tài)中，并且收到觸發(fā)事件，它將連接前驅狀態(tài)與后續(xù)狀態(tài)。如果事件發(fā)生，然而狀態(tài)中的元素沒有對這個特定的事件做出響應，事件就“靜靜丟棄”沒有任何效果，也就是狀態(tài)機僅做肯定的陳述 (“當我在這個狀態(tài)中并且這件事發(fā)生，我才會做” ) 。

狀態(tài)機本身不關心事件如何到達，但是必須避免競爭條件。同步狀態(tài)機必須阻塞調用者 （守衛(wèi)調用模式或者臨界區(qū)模式) ，異步狀態(tài)機必須使用排隊（隊列模式）來存儲它們的事件，直到它們得到處理。如果狀態(tài)機正在執(zhí)行動作的過程中產(chǎn)生新事件， 狀態(tài)機會立即停止去處理事件? 答案當然是否定的。狀態(tài)機在處理一個新事件之前，必須確保前一狀態(tài)的處理完成。后續(xù)幾個狀態(tài)-事件模式都需要遵循這個原則，而且具體模式實現(xiàn)中不再贅述。

4.2 單事件接收器模式

單事件接收器狀態(tài)機 (以下簡稱 SERSM) 簡單說就是觸發(fā)狀態(tài)切換的事件接收入口只有一個，單事件接收器模式依賴于單一事件接收器在客戶與狀態(tài)機間提供接口。在內部，這個單一事件接收器必須接收事件數(shù)據(jù)類型，不僅識別哪個事件已經(jīng)發(fā)生，并且識別任意伴隨事件的數(shù)據(jù)。

事件接收器模式必然有事件，事件類型event_type和事件攜帶的數(shù)據(jù)event_data，前者可以是個枚舉值，后者是一個結構體struct，為了識別不同的事件數(shù)據(jù)屬性，可以選擇union共用體更貼切。

如果是同步處理，狀態(tài)執(zhí)行比較簡單，可以直接調用event_receptor，按傳入的事件類型和事件數(shù)據(jù)執(zhí)行并切狀態(tài)；異步版本則建議組合使用隊列模式，將事件按FIFO的方式入隊，事件執(zhí)行函數(shù)被動觸發(fā)從隊列中取出事件，用輪詢的機制尋找新的事件和單事件接收器再執(zhí)行，最終也是調用event_receptor。具體實現(xiàn)有兩種方式：

1、分支邏輯法

利用 if-else 或者 switch-case 分支邏輯，按狀態(tài)轉移圖，將每一個狀態(tài)轉移原模原樣地直譯成代碼，對于簡單的狀態(tài)機來說，這種實現(xiàn)方式最簡單、直接，是首選；缺點所有的狀態(tài)邏輯封裝在單一事件接收器內(一個大型 if-else 或 switch-case 結構)，限制了狀態(tài)變更和擴展性。

//微信公眾號：嵌入式系統(tǒng)
//代碼只是表意，無法編譯
//enums1s2s3狀態(tài)枚舉值
//state表示當前狀態(tài)
voidevent_receptor(event_type,event_data)
{
switch(state)
{
cases1:
state_handle1(event_type,event_data);
break;
cases2:
state_handle2(event_type,event_data);
break;
cases3:
state_handle3(event_type,event_data);
default:
break;
}
}

state_handle1/state_handle2/state_handle3執(zhí)行后，按執(zhí)行情況切換狀態(tài)到新的state。下次即使同樣的事件，因為state不同，也會產(chǎn)生不同的效果。

2、查表法

對于狀態(tài)很多、狀態(tài)轉移比較復雜的狀態(tài)機來說，查表法比較合適，也稱表驅動法。通過二維數(shù)組來表示狀態(tài)轉移圖，能極大地提高代碼的可讀性和可維護性，擴展狀態(tài)只需增加表即可。

//微信公眾號：嵌入式系統(tǒng)
//代碼只是表意，無法編譯
typedefstruct
{
intstate;//狀態(tài)enum
pFunstate_handle;//對應狀態(tài)下的函數(shù)指針
}state_event_table_struct;

state_event_table_structtable[]={
{s1,state_handle1},
{s2,state_handle2},
{s3,state_handle3}
};

voidevent_receptor(event_type,event_data)
{
for(i=0;i<(sizeof(table)/sizeof(state_event_table_struct));i++)
{
//根據(jù)當前狀態(tài)state查表選擇對應的事件接收器，并進行狀態(tài)切換
if(current_state==table[i].state)
{
table[i].state_handle(event_type,event_data);
//current_state內部更新
}
}
}

4.3 多事件接收器模式

多事件接收器有限狀態(tài)機 (MERSM) 通常僅用于同步狀態(tài)機，這是因為業(yè)務層通常關心狀態(tài)機的事件集合。在這個模式中，每個事件都有一個單一的事件接收器，每個事件接收器本身僅考慮處理單一事件以及執(zhí)行相關動作。可以理解為單事件接收器是多個事件進入一個固定的接收器處理，而多事件接收器是多個事件組分配給多個接收器處理。

前者可以比喻為多個領導給一個員工安排任務，后者是多個領導同時給多個員工安排任務。在事件處理上可以復用處理機制，假設員工employee有A/B/C三人，任務task集有t1/t2/t3三種，其處理接口有多種實現(xiàn)方式。

1、拆分為單事件接收器模式內再嵌套一個單事件接收器

//微信公眾號：嵌入式系統(tǒng)
//代碼只是表意，無法編譯
voidemployee_task_handle(employee,task)
{
switch(employee)
{
caseA:
{
switch(task)
{
caset1:
//dosomething
break;
caset2:
//dosomething
break;
caset3:
//dosomething
break;
default:
break;
}
}
break;

caseB:
//同上
break;
caseC:
//同上
break;
default:
break;
}
}

對于兩層switch-case，也可以先按task分，再嵌套按employee分類執(zhí)行。

也可以直接將employee_task_handle 函數(shù)的參數(shù)拆分，例如 employee_A_handle/ employee_B_handle /employee_C_handle 三個函數(shù)體，可調用的事件接收入口就有3個，需要調用者自行區(qū)分，選擇合適的事件接收接口，這也是多事件接收器字面意思的效果。

2、組合事件再按單事件接收器模式

employee三人與task三種，有9種組合方式，直接將有限的9種方式定為枚舉值，就是個簡單的單事件接收器模式了，只是代碼處理上，每個case內重復的代碼比較多而已。這只是適合組合類型比較少的情形，將多事件接收器模式降維度，簡化為前一節(jié)的單事件接收器模式。

3、建立二維表

這種實現(xiàn)方式就是下一節(jié)的狀態(tài)表模式。通過將狀態(tài)邏輯分組，降為單事件接收器模式處理。例如MTK方案的鋰電池脈沖充電管理，因為充電狀態(tài)有很多狀態(tài)，每個狀態(tài)下充電是間歇性脈沖充電，充或者不充再分2個子狀態(tài)，采用的正是這種方案。

本質上多事件接收器模式，可以采用單事件接收器模式或者狀態(tài)表模式實現(xiàn)，這樣的前提是事件參數(shù)類似，結構相同。如果不同事件傳入的參數(shù)格式差異很大，很難統(tǒng)一；例如事件1需要2個int參數(shù)，事件2需要3個char數(shù)組為參數(shù)，直接按參數(shù)類型劃分多個接口，不必強行參數(shù)封裝統(tǒng)一。不同的事件處理分不同的接收器接口，也就是多事件接收器模式的特點。拆分為多個事件接收有利于傳參，但要求使用者從多個接口中選擇正確的。

4.4 狀態(tài)表模式

狀態(tài)表模式是沒有嵌套狀態(tài)機創(chuàng)建的模式，其效果類似表驅動法，狀態(tài)表模式使用二維數(shù)組來存儲狀態(tài)轉換信息，通常用狀態(tài)--事件構建表格。狀態(tài)表模式的狀態(tài)間不存在邏輯關系，屬于并行的扁平化狀態(tài)，也就是任意狀態(tài)在任意時刻的表現(xiàn)一致，狀態(tài)切換與當前狀態(tài)無關。

狀態(tài)表模式的執(zhí)行，直接通過當前的狀態(tài)和事件組合來索引，調用前必須先初始化狀態(tài)表。它也比其他模式更易于擴展，因為擴展只是按規(guī)則添加新元素到狀態(tài)表。畢竟嵌入式設備，狀態(tài)的類型必然是有限的，狀態(tài)表可以使用靜態(tài)方式存儲，雖然浪費但實現(xiàn)簡單。

//微信公眾號：嵌入式系統(tǒng)
//代碼只是表意，無法編譯
typedefvoid(*pfun_task_handle)(void);

pfun_task_handleemployee_task_table[3][3]={
{employeeA_task1,employeeA_task2,employeeA_task3},
{employeeB_task1,employeeB_task2,employeeB_task3},
{employeeC_task1,employeeC_task2,employeeC_task3},
};

//employee和task定為枚舉值
//做好函數(shù)指針非空校驗
voidtask_allocation(employee,task)
{
employee_task_table[employee][task]();
}

這種模式非常適合同步狀態(tài)機切換，如果是異步場景，最好使用隊列模式組合處理。

4.5 分解與狀態(tài)模式

前面的狀態(tài)機中，元素始終正好處于某個狀態(tài)之中，而且是一個確切的狀態(tài)，這樣的狀態(tài)稱為或狀態(tài)。但實際場景也存在復雜的，例如交通信號燈，它有兩個獨立的屬性：

顏色 ：紅Red、黃Yellow、綠Green 三種

顯示樣式 ：熄滅off 、長亮Steady、快閃Flashing quickly 、慢閃Flashing slowly 四種。

這個燈有10種(10=3x3+1)狀態(tài)，因為off關閉狀態(tài)，燈的顏色屬性已經(jīng)沒必要參考了。這種獨立狀態(tài)乘到一起，形成一個可能巨大的狀態(tài)集合很常見，解決這類問題的方法一一與狀態(tài)。這里僅僅作閹割版介紹，狀態(tài)機的狀態(tài)，并不一定只是一個屬性或枚舉值解決，也可以是多個正交屬性組合，這種狀態(tài)需要多個參數(shù)來描述，可以在單事件接收器模式上增加狀態(tài)參數(shù)。

理論與實際的差距，一直做GPS衛(wèi)星定位器，設備含RGB三顆LED，3顆燈除獨立工作指示特定狀態(tài)外，還有組合狀態(tài)，例三顆共同閃亮多次后恢復先前獨立的閃亮狀態(tài)，代碼維護其實很復雜，擴展性并不好。關于狀態(tài)機，如果狀態(tài)之間有關聯(lián)，存在優(yōu)先級或者組合，不管什么模式代碼都會比較難維護；只能說結合產(chǎn)品通用需求做個偽標準化接口?？梢娎碚摵蛯嶋H還是存在較大差距的。

4.7 小結

狀態(tài)機實現(xiàn)的模式，每一個都有優(yōu)點和缺點，使用哪一個完全依賴于需求。

單事件接收器模式使用單一事件接收器，并且內部用大的 switch - case 語句實現(xiàn)狀態(tài)行為。它需要創(chuàng)建并傳遞給接收器事件相關聯(lián)的類型，最簡單易用。

多事件接收器模式為每個事件使用單獨的事件處理程序，以便事件類型不用明確指出，適合不同的參數(shù)類型匹配不同的事件接收器。

狀態(tài)表模式可以擴展到大型的狀態(tài)空間，并且提供與狀態(tài)空間大小獨立的性能，對較大狀態(tài)空間支持較好。

分解與狀態(tài)模式提供簡單的實現(xiàn)與狀態(tài)的方法（難通用待學習）。

5、安全性與可靠性類設計模式

安全性是指不會引起人或者設備危險的系統(tǒng)，即危險的嚴重性后果，和發(fā)生的可能性；可靠性用于衡量系統(tǒng)的“可服務時間”或者“可用性”。沒有所謂的“安全軟件”，因為嵌入式系統(tǒng)是電子、機械、軟件在不同操作下的復合體 ，安全、穩(wěn)定只是特定場合的運行結果。

嵌入式系統(tǒng)的安全性和可靠性，除去硬件防護方案外，軟件上也可以采用一些防御性編程，實現(xiàn)系統(tǒng)的安全可靠以及異常恢復。主要從數(shù)據(jù)校驗、備份兩方面來入手。這里的解決方案其實也算是軟件開發(fā)技巧，不是嚴格意義上的設計模式。

5.1 二進制反碼模式

二進制反碼模式在檢測由于外界影響或者硬件故障內存損壞時很有用。

可能由 EMI (Electro-magnetic interference ，電磁干擾) 、熱量、硬件故障、軟件故障或者其他外部原因引發(fā)內存位損壞。這個模式將重要存儲兩份，一份以正常形式，而另一份以二進制反碼〈~ 操作符計算位反轉，逐位取反) 形式。讀取數(shù)據(jù)時，二進制反碼格式再次取反，并且與正常形式值比較。如果值完全相同則返回那個值，否則隨之處理錯誤。

該模式提供可靠的方式識別影響單一內存分配的故障，非常適合數(shù)據(jù)量小但非常重要的數(shù)據(jù)存儲，但對于非常大的數(shù)據(jù)結構，復制兩份數(shù)據(jù)浪費硬件資源。在這種情況下使用數(shù)據(jù)流校驗數(shù)據(jù)的正確性更合適。

一些非常關鍵的信息，如使用uint8_t變量表示某個狀態(tài)，一般可設0和非0兩種狀態(tài)，假設原本的非0為1，但因為異常被改為2，軟件是無能為力的。但如果使用二進制反碼模式，使用0x55和0xAA為兩種正常狀態(tài)，其他為異常狀態(tài)，這樣軟件的處理上就更加安全健壯。

5.2 數(shù)據(jù)流校驗模式

數(shù)據(jù)流校驗模式解決各種原因導致的變量損壞的問題，如環(huán)境因素 (EMI、熱量、輻射) 、硬件因素(電源波動、內存單元故障、地址線短流路) 或者是軟件故障 〈其他修改內存的軟件錯誤) ，針對大型數(shù)據(jù)集合中的數(shù)據(jù)損壞問題。

簡單說就是對數(shù)據(jù)進行校驗，計算其和、CRC、MD5或者SHA哈希值等，如果數(shù)據(jù)中間出現(xiàn)異常被篡改，校驗值可以發(fā)現(xiàn)錯誤，但是不能解決錯誤?？紤]到硬件資源限制，一般用CRC16校驗。將原始數(shù)據(jù)和其CRC16值一并存儲。使用前通過校驗值確認數(shù)據(jù)是否被篡改。

5.3 魔數(shù)標記模式

如果前面兩種方式適合數(shù)據(jù)存儲，如果只是單純的內存數(shù)據(jù)塊校驗，可以簡單粗暴的增加魔數(shù)標記。例如一個大結構體，首尾增加字段，正常情況下將其賦一個特殊值，如果使用中存在內存覆蓋或者操作越界，導致首尾標記的數(shù)據(jù)出現(xiàn)變化，則表示內存出現(xiàn)嚴重問題。

//微信公眾號：嵌入式系統(tǒng)
typedefstruct
{
uint16_t magic_head;
int32_timportance1;
uint8_timportance2[5];
uint16_t magic_tail;
}cutomer_data_struct;

//magic_head或magic_tail發(fā)生變化說明內存操作出現(xiàn)問題

對于動態(tài)內存申請也可以采用這種方式，期望申請N字節(jié)時多申請6個字節(jié)（舉例而已），

如果magic_head和magic_tail不是0x1234，說明動態(tài)申請的區(qū)域使用越界?？梢詤⒖紕討B(tài)內存管理及防御性編程。

有些芯片SDK代碼，對flash的寫保護，或者看門狗喂狗接口，其寫法也類似，將一個特殊的值寫給寄存器才算正常，也是基于這類考慮。魔法數(shù)在應用開發(fā)中盡量使用枚舉值來替代，但也因為魔法數(shù)的特殊性，在安全方面可以避免誤操作。

5.4 智能數(shù)據(jù)模式

軟件為了正確執(zhí)行功能都有前置條件，但是這些功能并沒有明確地檢查條件實際上是否滿足，在合適的位置使用主動防衛(wèi)的方式來檢查參數(shù)，智能數(shù)據(jù)模式即為標量數(shù)據(jù)元素編寫這種范例。

嵌入式C在函數(shù)層面，運行時對參數(shù)的范圍不會檢查，這是其固有的不安全性，需要使用者主動去對傳入的參數(shù)進行范圍檢查，對函數(shù)的返回值進行結果判斷。

智能數(shù)據(jù)模式簡化就是對數(shù)據(jù)前置條件和規(guī)則的自檢，屬于習慣 （小模式）范圍，創(chuàng)建或者啟動時對參數(shù)自檢，對傳入的參數(shù)值進行范圍檢查，以及多個參數(shù)間的組合合理性檢查，對運行的返回值進行錯誤處理。所有錯誤碼以枚舉類型展示，或者直接字符描述以使意圖理解更加清晰。

智能數(shù)據(jù)模式優(yōu)點是數(shù)據(jù)能自我保護，缺點是執(zhí)行操作的性能開銷 。一般只在針對核心功能、人機交互等，引入的錯誤容易產(chǎn)生嚴重后果的地方處理。

最典型最簡單的應用場景就是對傳入的指針參數(shù)進行非空判斷，這里推薦合理的使用const限定參數(shù)。

5.5 單通道模式

通道模式使用中等規(guī)?；蛘叽笮偷娜哂鄟韼椭R別何時發(fā)生運行時故障，并且可能 (依賴于怎樣實現(xiàn)) 在故障存在時持續(xù)提供服務。

通道是體系結構，包含執(zhí)行端到端處理的軟件（可能有硬件），也就是說通過一系列的數(shù)據(jù)處理步驟，將關鍵部分獨立化。例如數(shù)據(jù)流可以定為數(shù)據(jù)采集-處理-執(zhí)行一條龍服務，基于事件的驅動。安全性和可靠性通過在通道的關鍵點增加檢查得到增強，可能需要一些額外的硬件。由于僅有單一通道，因此該模式將在出現(xiàn)持續(xù)故障時，不能繼續(xù)完成功能，但是它可檢測并可能處理臨時故障。

這里不提供代碼范例，只是提供一種思路，關鍵部分單獨處理，分步執(zhí)行，不要耦合其他邏輯，對各步驟中的中間信息增加范圍校驗，識別異常并盡可能進行自我恢復處理。

5.6 雙通道模式

雙通道模式是一種通過提供多個通道提高穩(wěn)定性的主要模式，從而在架構層解決冗余問題。比如體溫計檢測與顯示，單通道到數(shù)據(jù)采集-處理-顯示，雙通道就可能是2顆傳感器各自獨立采集，再合并處理后顯示。

如果通道是相同的（叫做同構冗余通道），能夠解決隨機故障 (偶爾失效) ，但是不能解決系統(tǒng)故障 (錯誤) 。如果通道使用不同的設計或者實現(xiàn)，稱為異構冗余模式（也稱為多樣設計模式)，能夠解決隨機和系統(tǒng)故障。

雙通道模式對單個點 （失效或者是失效與錯誤，這依賴于選擇的具體子模式) 故障提供保護。系統(tǒng)可能通過與另一個通道比較來檢測一個通道中的錯誤，然后轉換故障到安全狀態(tài)，或者它可能使用其他的手段檢測一個通道的故障，并且 當故障發(fā)生時，轉換到另外一個。

這種雙備份機制，通過復制通道以解決與安全性和可靠性相關的故障，通常也需要大量的硬件復制，以致非常高硬件成本。如果通道是相同的，則所有的復制品包含相同的錯誤，因此將在相同的環(huán)境下出現(xiàn)錯誤。一般是實施策略是兩個通道的管理實現(xiàn)也不相同。兩個通道能夠同時運行，并且互相檢查，如果在臨界值上輸出不同，系統(tǒng)則轉換到故障安全狀態(tài)。另外，一個通道可以運行直到檢測到錯誤，并且開啟另外一個通道，允許故障出現(xiàn)時持續(xù)提供服務。不同模式的變體，有不同的硬件成本和效果。

1. 同構冗余模式 不同的通道使用相同的設計和實現(xiàn)，可以有效地解決單一點的錯誤，該模式變體有相對較高的生產(chǎn)成本 ，但是有相對低的設計成本 〈因為兩個通道僅需設計一次，復制一次) 。

2. 異構冗余模式 使用不同設計或者不同實現(xiàn)的雙通道來解決隨機和系統(tǒng)故障，系統(tǒng)能夠在出現(xiàn)故障時持續(xù)提供服務。該模式變體不僅有相對較高的生產(chǎn)成本，而且有相對高的設計成本(因為兩個個通道需設計兩套方案) 。硬件、軟件方案都不同，但獨立且不同的方案解決隨機和系統(tǒng)錯誤。

3. 三模塊冗余 (TMR ) 模式 使用相同設計的 3 個通道來解決故障，應用的理論是，如果有單一點故障，則通道中的一個將與另外兩個解約，并且丟棄異常值。系統(tǒng)可以在出現(xiàn)故障時持續(xù)提供服務，提供故障在單一通道內適當?shù)母綦x。該模式有很高的生產(chǎn)成本，因為通道必須復制 3 次。如果所有的通道有相同的設計 (很常見) ，則設計成本相對低，如果通道的設計不同，則該模式變體的成本非常高，因為每個通道必須設計 3 次。這種在航空、軍工電子學領域很常見的。

4. 完整性檢查模式 使用兩個同構通道，一個是主執(zhí)行通道，另一個使用低精確計算的輕量級通道，如果低精確檢查通道檢測到主通道有故障，則系統(tǒng)進入故障安全狀態(tài)。該模式有低生產(chǎn)成本并且中等的設計成本，因為它需要額外的設計工作，但是有較低的精確冗余，當出現(xiàn)單一故障時不能繼續(xù)提供服務。

5. 監(jiān)視器-執(zhí)行器模式 使用兩個額外同構通道，第一個就如在完整性檢查模式那樣，是一個執(zhí)行通道，這個通道提供系統(tǒng)服務；第二個通道使用一個或多個獨立的傳感器監(jiān)視執(zhí)行通道的物理結果。如果執(zhí)行通道有故障，并且執(zhí)行不正確，則監(jiān)視器通道識別它，并能夠命令系統(tǒng)進入故障安全狀態(tài)。如果監(jiān)視器通道有故障，則執(zhí)行器通道仍然執(zhí)行正確行為。

多通道模式是個系統(tǒng)工程，不能僅依靠軟件就實現(xiàn)，它是嵌入式設備安全和可靠性風險的最佳解決方案，但是成本也相應增加。一般的民用消費電子不會采納。但是了解這些模式，也可能從軟件方面、需求角度進行一定的優(yōu)化。例如一般車載定位器檢查汽車是否有行駛，可以依靠ACC點火，加速度傳感器信息，GPS定位信息，雖然沒有很明顯的交代這是異構三通道，但設備本身支持這些信息的采集，軟件層面上就可以組合這三種信息，合并分析得出汽車的狀態(tài)。

5.7 小結

前面的模式在應用范圍上 ，通常稱為“設計定式”而不是“設計模式”，但合理的應用可提高設備在操作環(huán)境中的安全性和可靠性。

6、總結

天下武功，唯快不破。嵌入式設備因為其特殊性，物料更換、市場先機、訂單交期、需求變更，都與軟件開發(fā)存在關聯(lián)，一般情況下，凡是軟件能勉強解決的就不算增加成本，這種思路下軟件開發(fā)就處于試驗性開發(fā)、混亂下迭代的惡性循環(huán)，最終導致產(chǎn)品功能看起來都正常，而源碼慘不忍睹。

實際上一個產(chǎn)品系列，開發(fā)很少奇技淫巧，更多的是修修補補、維護迭代，原創(chuàng)性開發(fā)不多；可閱讀性和擴展性才是重點。而設計模式，就是在盡可能在局部采用特定的思路，去兼容不同的需求，讓代碼更好閱讀，讓下一個接手的人可以很容易的去支持更多奇葩需求。

PS

因為時間問題，嵌入式軟件設計模式全文顯得虎頭蛇尾，下半章未使用源碼范例具體說明，但實現(xiàn)的思路有描述清楚，設計模式本身就是重思想而不是套路。