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

4.1 狀態(tài)與事件

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

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

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

4.2 單事件接收器模式

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

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

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

1、分支邏輯法

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

//微信公眾號：嵌入式系統(tǒng)
//代碼只是表意，無法編譯
//enums1s2s3狀態(tài)枚舉值
//state表示當(dāng)前狀態(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。下次即使同樣的事件，因?yàn)閟tate不同，也會產(chǎn)生不同的效果。

2、查表法

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

//微信公眾號：嵌入式系統(tǒng)
//代碼只是表意，無法編譯
typedefstruct
{
intstate;//狀態(tài)enum
pFunstate_handle;//對應(yīng)狀態(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ù)當(dāng)前狀態(tài)state查表選擇對應(yīng)的事件接收器，并進(jìn)行狀態(tài)切換
if(current_state==table[i].state)
{
table[i].state_handle(event_type,event_data);
//current_state內(nèi)部更新
}
}
}

4.3 多事件接收器模式

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

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

1、拆分為單事件接收器模式內(nèi)再嵌套一個(gè)單事件接收器

//微信公眾號：嵌入式系統(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 三個(gè)函數(shù)體，可調(diào)用的事件接收入口就有3個(gè)，需要調(diào)用者自行區(qū)分，選擇合適的事件接收接口，這也是多事件接收器字面意思的效果。

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

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

3、建立二維表

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

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

4.4 狀態(tài)表模式

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

狀態(tài)表模式的執(zhí)行，直接通過當(dāng)前的狀態(tài)和事件組合來索引，調(diào)用前必須先初始化狀態(tài)表。它也比其他模式更易于擴(kuò)展，因?yàn)閿U(kuò)展只是按規(guī)則添加新元素到狀態(tài)表。畢竟嵌入式設(shè)備，狀態(tài)的類型必然是有限的，狀態(tài)表可以使用靜態(tài)方式存儲，雖然浪費(fèi)但實(shí)現(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ù)指針非空校驗(yàn)
voidtask_allocation(employee,task)
{
employee_task_table[employee][task]();
}

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

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

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

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

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

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

理論與實(shí)際的差距，一直做GPS衛(wèi)星定位器，設(shè)備含RGB三顆LED，3顆燈除獨(dú)立工作指示特定狀態(tài)外，還有組合狀態(tài)，例三顆共同閃亮多次后恢復(fù)先前獨(dú)立的閃亮狀態(tài)，代碼維護(hù)其實(shí)很復(fù)雜，擴(kuò)展性并不好。關(guān)于狀態(tài)機(jī)，如果狀態(tài)之間有關(guān)聯(lián)，存在優(yōu)先級或者組合，不管什么模式代碼都會比較難維護(hù)；只能說結(jié)合產(chǎn)品通用需求做個(gè)偽標(biāo)準(zhǔn)化接口。可見理論和實(shí)際還是存在較大差距的。

4.7 小結(jié)

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

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

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

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

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

5、安全性與可靠性類設(shè)計(jì)模式

安全性是指不會引起人或者設(shè)備危險(xiǎn)的系統(tǒng)，即危險(xiǎn)的嚴(yán)重性后果，和發(fā)生的可能性；可靠性用于衡量系統(tǒng)的“可服務(wù)時(shí)間”或者“可用性”。沒有所謂的“安全軟件”，因?yàn)榍度胧较到y(tǒng)是電子、機(jī)械、軟件在不同操作下的復(fù)合體 ，安全、穩(wěn)定只是特定場合的運(yùn)行結(jié)果。

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

5.1 二進(jìn)制反碼模式

二進(jìn)制反碼模式在檢測由于外界影響或者硬件故障內(nèi)存損壞時(shí)很有用。

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

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

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

5.2 數(shù)據(jù)流校驗(yàn)?zāi)Ｊ?/h2>

數(shù)據(jù)流校驗(yàn)?zāi)Ｊ浇鉀Q各種原因?qū)е碌淖兞繐p壞的問題，如環(huán)境因素 (EMI、熱量、輻射) 、硬件因素(電源波動、內(nèi)存單元故障、地址線短流路) 或者是軟件故障 〈其他修改內(nèi)存的軟件錯(cuò)誤) ，針對大型數(shù)據(jù)集合中的數(shù)據(jù)損壞問題。

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

5.3 魔數(shù)標(biāo)記模式

如果前面兩種方式適合數(shù)據(jù)存儲，如果只是單純的內(nèi)存數(shù)據(jù)塊校驗(yàn)，可以簡單粗暴的增加魔數(shù)標(biāo)記。例如一個(gè)大結(jié)構(gòu)體，首尾增加字段，正常情況下將其賦一個(gè)特殊值，如果使用中存在內(nèi)存覆蓋或者操作越界，導(dǎo)致首尾標(biāo)記的數(shù)據(jù)出現(xiàn)變化，則表示內(nèi)存出現(xiàn)嚴(yá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ā)生變化說明內(nèi)存操作出現(xiàn)問題

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

magic_head	申請長度	有效堆區(qū)	magic_tail
0x1234	N	實(shí)際可用區(qū)域	0x1234

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

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

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

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

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

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

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

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

5.5 單通道模式

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

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

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

5.6 雙通道模式

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

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

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

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

1. 同構(gòu)冗余模式 不同的通道使用相同的設(shè)計(jì)和實(shí)現(xiàn)，可以有效地解決單一點(diǎn)的錯(cuò)誤，該模式變體有相對較高的生產(chǎn)成本 ，但是有相對低的設(shè)計(jì)成本 〈因?yàn)閮蓚€(gè)通道僅需設(shè)計(jì)一次，復(fù)制一次) 。

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

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

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

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

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

5.7 小結(jié)

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

6、總結(jié)

天下武功，唯快不破。嵌入式設(shè)備因?yàn)槠涮厥庑裕锪细鼡Q、市場先機(jī)、訂單交期、需求變更，都與軟件開發(fā)存在關(guān)聯(lián)，一般情況下，凡是軟件能勉強(qiáng)解決的就不算增加成本，這種思路下軟件開發(fā)就處于試驗(yàn)性開發(fā)、混亂下迭代的惡性循環(huán)，最終導(dǎo)致產(chǎn)品功能看起來都正常，而源碼慘不忍睹。

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

PS

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