4、狀態與工作流類設計模式

4.1 狀態與事件

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

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

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

4.2 單事件接收器模式

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

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

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

1、分支邏輯法

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

//微信公眾號：嵌入式系統
//代碼只是表意，無法編譯
//enums1s2s3狀態枚舉值
//state表示當前狀態
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執行后，按執行情況切換狀態到新的state。下次即使同樣的事件，因為state不同，也會產生不同的效果。

2、查表法

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

//微信公眾號：嵌入式系統
//代碼只是表意，無法編譯
typedefstruct
{
intstate;//狀態enum
pFunstate_handle;//對應狀態下的函數指針
}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++)
????{
????????//根據當前狀態state查表選擇對應的事件接收器，并進行狀態切換
????????if(current_state==table[i].state)?
????????{
????????????table[i].state_handle(event_type,event_data);
????????????//current_state內部更新
????????}
????}
}

4.3 多事件接收器模式

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

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

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

//微信公眾號：嵌入式系統
//代碼只是表意，無法編譯
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分類執行。

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

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

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

3、建立二維表

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

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

4.4 狀態表模式

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

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

//微信公眾號：嵌入式系統
//代碼只是表意，無法編譯
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定為枚舉值
//做好函數指針非空校驗
voidtask_allocation(employee,task)
{
employee_task_table[employee][task]();
}

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

4.5 分解與狀態模式

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

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

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

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

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

4.7 小結

狀態機實現的模式，每一個都有優點和缺點，使用哪一個完全依賴于需求。

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

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

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

分解與狀態模式提供簡單的實現與狀態的方法（難通用待學習）。

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

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

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

5.1 二進制反碼模式

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

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

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

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

5.2 數據流校驗模式

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

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

5.3 魔數標記模式

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

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

//magic_head或magic_tail發生變化說明內存操作出現問題

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

如果magic_head和magic_tail不是0x1234，說明動態申請的區域使用越界。可以參考動態內存管理及防御性編程。

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

5.4 智能數據模式

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

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

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

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

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

5.5 單通道模式

通道模式使用中等規模或者大型的冗余來幫助識別何時發生運行時故障，并且可能 (依賴于怎樣實現) 在故障存在時持續提供服務。

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

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

5.6 雙通道模式

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

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

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

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

同構冗余模式

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

異構冗余模式

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

三模塊冗余 (TMR ) 模式


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

完整性檢查模式

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

監視器-執行器模式

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

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

5.7 小結

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

6、總結

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

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

PS

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

審核編輯：湯梓紅