嵌入式控制系統設計/故障模式和預防
故障模式是指系統故障的方式，或觀察故障的方式。因此，它與故障原因不同，而是描述故障發生的方式。故障模式有三種類型：概念性、技術性和組織性。本文僅討論技術性故障模式，重點關注嵌入式控制系統。本章對於嵌入式系統設計人員非常重要，因為此類系統通常在沒有人工監督的情況下工作，並且在人工糾正故障的執行成本很高的地點工作。因此，設計人員應格外注意系統中可能出現的問題（即識別其故障模式）並對每種故障的風險進行評估（即分析每種故障模式的後果）。很明顯，避免故障比修復故障要好得多，並且從這方面來說，簡單的設計比複雜的系統更容易；但是，製作簡單的設計仍然是一種工程藝術形式，尚未成為一種結構化的工程學科。還要記住，許多故障不會被測試檢測到。
嵌入式系統中的技術故障模式可以分為兩大類：硬體故障模式和軟體故障模式；然而，最難預防的故障是那些由硬體和軟體之間微妙互動引起的故障。
以下是軟體故障模式的一些示例
- 緩衝區溢位：計算機記憶體小於程式設計師預期的記憶體，因此在嵌入式系統執行期間，系統中的某個程式正在訪問計算機記憶體的錯誤部分。
- 懸空指標：此錯誤在非安全程式語言中很常見，在這種語言中，程式設計師負責始終確保每個指標指向正確的記憶體位置。
- 資源洩漏[1]，其中程式設計錯誤導致計算機對某些硬體資源失去控制；記憶體洩漏是最簡單的資源洩漏形式。
- 競態條件，其中系統不同元件的特定相對時間事件導致意外行為。此類競態條件通常難以僅透過測試檢測到。
- 語義設計，例如：視覺軟體環境中兩個子系統之間箭頭的含義應該與硬體對其的解釋相同。
以下是硬體故障模式的一些示例
- 電氣故障：短路、電壓/電流過高
- 機械故障：閥門卡住
- 溫度影響：元件變形
- 材料故障：腐蝕
再次強調，這些示例僅是後果，而不是原因！
以下是軟體故障原因的一些示例
以下是硬體故障原因的一些示例
- 惡劣環境：任何阻止系統正常執行的因素。
- 感測器校準不良
- 選擇錯誤的尺寸
- 製造/裝配工藝缺陷
一些故障不是由硬體或軟體引起的，而是由系統級引起的。
系統故障原因的一個示例
- 執行故障：人工操作員也會犯錯誤。三哩島事故是執行故障的典型例子。
由於嵌入式系統功能和能力不斷增強，很難預防甚至檢測故障模式。確保可靠性的一種方法是使用機率可靠性建模等技術進行大量測試。這些技術的問題之一是它們僅在開發的後期階段使用。最好在開發的早期階段就將質量和可靠性設計進去。
為了在設計過程中檢測故障，重要的是在設計之初對系統（尤其是軟體）進行不同的測試。但測試通常很昂貴，而且也應該提供正確的資訊：測試結果的可用性取決於測試的質量。因此，找到合適的測試並不總是容易的。
軟體領域中的動態分析是透過在處理器上執行程式來測試和評估軟體。在硬體上進行動態分析的一個例子可能是振動和應力分析。
如今，工程師已經為軟體開發了靜態分析，它是一種無需測試的方法：無需開發特定測試，並且可以在無需執行程式的情況下檢查軟體缺陷。
有很多方法可以降低故障發生的可能性。但有些故障需要比其他故障更緊急地處理。首先應該看一下系統發生故障的頻率，這被稱為系統的故障率。希望系統不會發生故障，但如果故障非常罕見，通常沒有必要採取措施。
故障模式的另一個方面是其嚴重程度。短路的電器可能危及生命，而自動售貨機中閥門卡住的危害性則較小。
儘管工程師可以盡一切努力設計一個不會發生故障的系統，但故障總是會發生的。例如：如今一部普通的手機包含多達 200 萬行軟體程式碼。很可能在這其中的一行程式碼中引入了故障。系統變得越來越複雜。例如：預計同一款手機在 10 年內將包含多達 1000 萬行程式碼。因此，設計應該更加健壯。[2] 當系統檢測到出現問題時，它可以發出訊號並進入安全模式，直到使用者採取適當的措施。以自動售貨機中閥門卡住為例：機器可以點亮所有 LED 以發出訊號，表明存在問題，並停止提供蘇打水，直到維修完畢。
當單獨的系統必須協同工作時，也會發生故障，例如：RoboCup中的不同機器人。另一個此類複雜系統的例子是麻省理工學院詹姆斯·麥克萊爾金教授的機器人，它們必須共同演奏《星球大戰》主題曲，但每個機器人只能演奏一些音符。因此，它們必須合作才能正確演奏完整的主題曲。[3]
設計嵌入式控制系統的成本往往隨著可靠性的提高而呈指數級增長：消除系統中 X% 的故障並不一定會使可靠性提高 X%（一項研究表明，在IBM中，消除 60% 的錯誤僅增加了 3% 的可靠性）。在某些情況下，因此可能更具成本效益的是不研究更可靠的系統，而是支付故障成本。但是，必須記住，這種策略會導致公司因銷售不可信的系統而聲譽受損。在不同的設計標準之間始終存在權衡，具體取決於系統。當然，關鍵系統應始終設計得儘可能可靠。
所有這些都強調了在設計過程中消除故障的重要性。幸運的是，工程師已經開發出了一些系統地執行此操作的過程。以下所有過程都可以在所謂的安全工程中使用。故障研究是設計嵌入式控制系統的重要方面，因為它可以節省時間、金錢，甚至生命，並且有助於系統未來的修改。
由於測試不完全，存在許多即時災難的例子。
安全係數用於確保設計能夠正常工作，並防止其發生故障。但是，較大的安全係數並不總是會產生可靠的系統。通常，它們會導致過度設計的系統，這些系統更昂貴，並且製造/組裝時間更長。
為了減少（或更好地防止）系統故障的可能性，工程師們開發了一種名為“故障模式及影響分析”（FMEA）的技術。這是用於識別系統中潛在或實際故障模式並選擇適當的糾正措施的工具。FMEA 提供了一種分析方法來確定哪個風險最令人擔憂，因此需要採取措施來防止問題在出現之前出現。這些規範的制定將確保系統滿足定義的要求。
還可以識別需要特殊控制以防止或檢測故障模式的關鍵或重要的設計/工藝特性。一個關鍵步驟是預測產品可能出現的問題。雖然無法預測所有故障模式，但開發團隊應儘可能全面地制定潛在故障模式的廣泛清單。FMEA 從設計開始，並在整個設計過程中維護和調整。這樣就可以設計出無故障的系統。這樣，FMEA 就包含了用於將來系統改進的重要資訊。
進行FMEA的過程很簡單。它分三個主要步驟完成，需要採取相應的行動。但在開始使用FMEA之前，重要的是要做好一些預備工作，以確保將健壯性和歷史記錄納入分析。重要的是要考慮故意和非故意使用！非故意使用是一種惡劣環境。
- 步驟1：確定嚴重程度
根據使用者感知的功能要求及其影響，確定所有故障模式。每個影響都被賦予一個嚴重程度(SEV)，從1（無危險）到10（重要）。如果影響的嚴重程度為9或10，則需要採取措施來更改設計，如果可能，消除故障模式，或保護使用者免受影響。
- 步驟2：確定機率
在這一步中，有必要檢視故障的原因以及故障發生的次數。故障模式被賦予一個機率(OCCUR)，同樣從1到10。如果發生率很高（對於非安全故障模式，發生率>4，當步驟1中的嚴重程度為9或10時，發生率>1），則需要確定行動。
提示：機率也可以在故障表中實施後使用，以讓操作員初步猜測頻繁發生的故障的來源。
- 步驟3：確定檢測率
當確定適當的行動時，有必要測試其效率。還需要進行設計驗證。需要選擇適當的檢驗方法。前兩步中的每個組合都將獲得一個檢測率(DETEC)。這個數字代表了計劃測試和檢驗消除缺陷或檢測故障模式的能力。
在這三個基本步驟之後，將計算風險優先順序數（RPN）。
RPN 在選擇針對故障模式的行動中並不起重要作用。它們更像是評估這些行動的閾值。
RPN 最高的故障模式應優先考慮糾正措施。
分配完這些值後，會記錄建議的行動、目標、責任人和實施日期。一旦行動在設計/工藝中實施，就應該檢查新的 RPN，以確認改進情況。只要設計或工藝發生變化，FMEA 就應該更新。
一些合乎邏輯但重要的想法浮出水面
- 嘗試消除故障模式（一些故障比其他故障更容易預防）
- 最小化故障的嚴重程度
- 減少故障模式的發生率
- 改進檢測率(!)
與 FMEA 一樣，預測性故障確定(AFD) 的目標是識別和防止潛在故障。 [4] 然而，AFD 的方法正好與 FMEA 相反。AFD 不是尋找故障模式的原因，而是要求開發人員將關注的故障視為預期結果，並尋找方法確保這種故障始終可靠地發生。這樣，AFD 就是 FMEA 的補充方法。使用 FMEA，可以找到風險優先順序數最高的故障，然後使用 AFD 方法重新設計。
AFD 比 FMEA 更適合於複雜故障分析。FMEA 依賴於基於應用程式或他人個人經驗識別故障及其原因。但是，這種方法的問題是“否認現象”。如果試圖考慮正常執行的系統可能出現的問題，就會傾向於抵制思考可能發生的令人不快的情況，除非它們確實之前已經經歷過。有時人們甚至會否認問題，因為他們不會承認在設計中犯了錯誤。透過顛倒問題，AFD 克服了這種“否認現象”，併為故障分析打開了創造性的見解。
- 步驟 1：制定或反轉問題
工程師不應該思考故障的可能原因，而是應該思考如何在相同的環境條件下使故障發生，這些環境條件導致了故障的發生。首先需要識別這些條件。之後，應該考慮導致故障的場景，並嘗試將其定位。
- 步驟 2：尋找解決方案或方法來產生故障
現在，思維過程轉變為尋找產生所檢查故障的機制或方法。功能分析可能有助於識別故障場景中涉及的一系列功能或行動。
- 步驟 3：驗證是否有資源可以導致故障
有七類潛在資源：物質、場效應、可用空間、時間、物體結構、系統功能以及有關係統的其他資料。對於導致故障的每個潛在解決方案，有必要檢查是否有足夠的資源來支援該解決方案。
故障樹分析 (FTA) 是一種第三種故障分析形式，它使用布林邏輯 來組合一系列低階事件，分析系統的非期望狀態。FTA 在設計過程中實施後進行，即在測試級別進行，但如果所有這些故障樹都被收集並維護良好，那麼如果仍然發生故障，它們也將在操作級別提供有用的幫助。這種分析方法主要用於安全工程領域。
FTA 分析包含五個步驟
- 步驟 1：定義要研究的非期望事件
定義不希望發生的事件可能非常困難，儘管有些事件很容易觀察到。擁有廣泛系統設計知識的工程師或具有工程背景的系統分析師是幫助定義和編號不希望發生的事件的最佳人選。然後，將不希望發生的事件用於建立故障樹分析（FTA），*一個 FTA 一個事件*。
- 步驟 2：瞭解系統
選擇不希望發生的事件後，會對所有可能影響該事件的機率原因進行研究和分析。通常不可能獲得導致該事件的機率的準確數字，因為這樣做可能非常昂貴且耗時。
系統設計人員對系統瞭如指掌，這些知識對於避免遺漏任何影響不希望發生的事件的原因至關重要。對於所選事件，所有原因將被編號並按發生的順序排序。
- 步驟 3：構建故障樹
選擇不希望發生的事件並分析系統，以便了解所有造成的影響以及可能的機率，現在可以構建故障樹。故障樹基於 AND 和 OR 門，它們定義了故障樹的主要特徵。
- 步驟 4：評估故障樹
分析樹以發現任何可能的改進，換句話說，研究風險管理，並尋找系統改進的方法。簡而言之，在這個步驟中，我們將識別所有直接或間接影響系統的所有潛在危害。
- 步驟 5：控制已識別的危害
此步驟非常具體，並且在不同的系統之間存在很大差異，但主要點始終是，在識別了危害之後，將採取一切可能的方法來降低發生的機率。
由於組裝 FTA 可能是一項昂貴且繁瑣的體驗，因此最佳方法是考慮子系統，然後將它們整合在一起。