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

4.1 狀態(tài)與事件

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

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

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

4.2 單事件接收器模式

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

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

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

1、分支邏輯法

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

//微信公眾號：嵌入式系統(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。下次即使同樣的事件，因為state不同，也會產(chǎn)生不同的效果。

2、查表法

對于狀態(tài)很多、狀態(tài)轉(zhuǎn)移比較復(fù)雜的狀態(tài)機來說，查表法比較合適，也稱表驅(qū)動法。通過二維數(shù)組來表示狀態(tài)轉(zhuǎn)移圖，能極大地提高代碼的可讀性和可維護性，擴展?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)的事件接收器，并進行狀態(tài)切換
if(current_state==table[i].state)
{
table[i].state_handle(event_type,event_data);
//current_state內(nèi)部更新
}
}
}

4.3 多事件接收器模式

多事件接收器有限狀態(tài)機 (MERSM) 通常僅用于同步狀態(tài)機，這是因為業(yè)務(wù)層通常關(guān)心狀態(tài)機的事件集合。在這個模式中，每個事件都有一個單一的事件接收器，每個事件接收器本身僅考慮處理單一事件以及執(zhí)行相關(guān)動作?？梢岳斫鉃閱问录邮掌魇嵌鄠€事件進入一個固定的接收器處理，而多事件接收器是多個事件組分配給多個接收器處理。

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

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

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

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

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

3、建立二維表

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

本質(zhì)上多事件接收器模式，可以采用單事件接收器模式或者狀態(tài)表模式實現(xiàn)，這樣的前提是事件參數(shù)類似，結(jié)構(gòu)相同。如果不同事件傳入的參數(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)建的模式，其效果類似表驅(qū)動法，狀態(tài)表模式使用二維數(shù)組來存儲狀態(tài)轉(zhuǎn)換信息，通常用狀態(tài)--事件構(gòu)建表格。狀態(tài)表模式的狀態(tài)間不存在邏輯關(guān)系，屬于并行的扁平化狀態(tài)，也就是任意狀態(tài)在任意時刻的表現(xiàn)一致，狀態(tài)切換與當(dāng)前狀態(tài)無關(guān)。

狀態(tài)表模式的執(zhí)行，直接通過當(dāng)前的狀態(tài)和事件組合來索引，調(diào)用前必須先初始化狀態(tài)表。它也比其他模式更易于擴展，因為擴展只是按規(guī)則添加新元素到狀態(tài)表。畢竟嵌入式設(shè)備，狀態(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)。但實際場景也存在復(fù)雜的，例如交通信號燈，它有兩個獨立的屬性：

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

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

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

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

4.7 小結(jié)

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

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

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

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

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

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

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

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

5.1 二進制反碼模式

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

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

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

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

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

數(shù)據(jù)流校驗?zāi)Ｊ浇鉀Q各種原因?qū)е碌淖兞繐p壞的問題，如環(huán)境因素 (EMI、熱量、輻射) 、硬件因素(電源波動、內(nèi)存單元故障、地址線短流路) 或者是軟件故障 〈其他修改內(nèi)存的軟件錯誤) ，針對大型數(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ù)存儲，如果只是單純的內(nèi)存數(shù)據(jù)塊校驗，可以簡單粗暴的增加魔數(shù)標記。例如一個大結(jié)構(gòu)體，首尾增加字段，正常情況下將其賦一個特殊值，如果使用中存在內(nèi)存覆蓋或者操作越界，導(dǎo)致首尾標記的數(shù)據(jù)出現(xiàn)變化，則表示內(nèi)存出現(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ā)生變化說明內(nèi)存操作出現(xiàn)問題

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

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

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

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

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

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

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

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

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

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

5.5 單通道模式

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

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

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

5.6 雙通道模式

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

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

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

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

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

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

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

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

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

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

5.7 小結(jié)

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

6、總結(jié)

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

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

PS

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