概述#

軟體透過 致動器（Actuator） 連接硬體與外部世界，將數位值轉換為機械動作。但「連接外部世界」不一定意味著機械臂或飛彈發射器——僅僅是向螢幕顯示錯誤資訊就可能造成災難性後果。

書中列舉了多個歷史案例：

• 1983 年蘇聯飛彈誤報事件：衛星系統誤將罕見的陽光條件判讀為美國發射的飛彈。Petrov 中校選擇不相信電腦，避免了核戰爭。
• 2009 年法航 447 號班機：空速感測器因結冰失效，自動駕駛脫離。飛行控制軟體的失速警告邏輯在低空速時會失效——做對的事（推桿增速）反而觸發警告，拉桿（錯誤動作）時警告反而消失。飛行員在整個 3 分多鐘的墜落過程中都在做相反的操作。228 人罹難。
• 波音 737 MAX：MCAS 軟體僅依賴單一感測器（儘管飛機上有兩個可用感測器）決定行為，在錯誤時機壓低機鼻。波音從未在感測器故障條件下測試該軟體，且飛行員甚至不知道 MCAS 的存在。兩起墜機共造成 346 人死亡。

安全性（Safety）關注系統 避免進入導致損害、傷害或生命損失的狀態 的能力。不安全狀態可由以下因素引起：遺漏（Omission）、誤動作（Commission）、時序錯誤（Timing）、系統值問題（粗略或細微的不正確值）、序列遺漏與誤動作、以及順序錯誤。

安全性同時關注 偵測並從不安全狀態恢復，以防止或至少最小化傷害。系統的任何部分——軟體、硬體或環境——都可能以非預期的不安全方式運作。一旦偵測到不安全狀態，系統的回應選項包括：

• 從不安全狀態恢復後繼續運作，或將系統置於安全模式
• 關機（Fail Safe）
• 轉換為手動操作模式（例如：動力轉向失效時改為手動轉向）

此外，不安全狀態應被 立即回報 和/或 記錄。

架構安全性設計始於識別系統的 安全關鍵功能（Safety-critical Functions），使用以下技術：

• 故障模式與效應分析（FMEA / Hazard Analysis）：系統性地分析每個元件可能的故障模式及其對系統的影響
• 故障樹分析（FTA）：一種由上而下的演繹方法，從不想要的頂層事件（如系統進入不安全狀態）向下追溯，識別可能導致該事件的故障組合

一旦故障被識別，架構師需要設計機制來偵測和緩解故障（以及最終的危害）。

Safety General Scenario#

安全性通用情境的組成部分：

• 來源（Source）：感測器、軟體元件、通訊通道、裝置（如時鐘）
• 刺激（Stimulus）：
  • 遺漏：值從未到達、功能從未執行
  • 誤動作：功能執行錯誤、裝置產生虛假事件或不正確資料
  • 不正確資料：感測器報告錯誤資料、軟體元件產生錯誤結果
  • 時序故障：資料過早或過晚到達、事件以錯誤的速率或順序發生
• 環境（Environment）：正常運作、降級運作、手動操作、恢復模式
• 製品（Artifact）：系統的安全關鍵部分
• 回應（Response）：辨識不安全狀態，並執行避免、恢復、以降級或安全模式繼續、關機、切換手動操作、切換備用系統、通知相關方、記錄不安全狀態
• 回應量測（Response Measure）：
  • 避免進入不安全狀態的數量或百分比
  • 系統可自動恢復的不安全狀態數量或百分比
  • 風險暴露的變化：損失規模 x 損失機率
  • 系統可恢復的時間百分比
  • 系統處於降級或安全模式的時間
  • 系統關機的時間量或百分比
  • 進入和恢復（從手動操作、安全或降級模式）的經過時間

具體情境範例：病患監控系統中的感測器在 100 毫秒後未回報生命關鍵值。故障被記錄、控制台亮起警告燈、備用（較低保真度）感測器啟動。系統在不超過 300 毫秒內使用備用感測器繼續監控病患。

Tactics for Safety#

安全策略可分為四大類：不安全狀態避免（Avoidance）、不安全狀態偵測（Detection）、遏制（Containment） 和 恢復（Recovery）。這些策略的邏輯前提是能夠辨識什麼構成不安全狀態——這意味著在完成架構設計後，應執行自己的危害分析或 FTA，因為設計決策本身可能引入需求分析時未考慮到的新安全漏洞。

安全策略與可用性（Availability）策略有大量重疊，因為可用性問題經常導致安全問題，且許多修復方案是共通的。在應用安全策略之前，應先執行 危害分析（Hazard Analysis） 或 FTA，以識別系統的不安全狀態。

Unsafe State Avoidance#

• 替代（Substitution）：以保護機制（通常是硬體型）替代潛在危險的軟體設計特性。例如使用硬體看門狗（Watchdog）、監視器和聯鎖裝置取代軟體版本。硬體裝置提供並控制自己的資源，不會被軟體的資源匱乏影響。此策略通常僅在被替代的功能相對簡單時才有效。
• 預測模型（Predictive Model）：透過監控狀態來預測系統程序、資源或其他屬性的健康狀態，不僅確保系統在正常運作參數內運行，還能提供潛在問題的 早期警告。例如：某些汽車巡航控制系統會計算車輛與前方障礙物的接近率，在距離和時間過短之前發出警告。通常與狀態監控（Condition Monitoring）結合使用。

Unsafe State Detection#

• 逾時（Timeout）：判斷元件的操作是否符合時序約束。可偵測遲到的時序和遺漏故障。在即時系統、嵌入式系統和分散式系統中特別常見。
• 時間戳記（Timestamp）：偵測不正確的事件序列，主要用於分散式訊息傳遞系統。在分散式系統中，也可使用序列號取代時間戳記以避免不同處理器間的時鐘不一致問題。
• 狀態監控（Condition Monitoring）：檢查程序或裝置中的條件，或驗證設計中的假設（可能使用斷言）。監視器應盡量簡單且理想上可證明其正確性，以避免引入新的錯誤。為預測模型和健全性檢查提供輸入。
• 健全性檢查（Sanity Checking）：檢查特定操作結果、元件的輸入或輸出的有效性或合理性。通常在介面處使用，用於檢查特定的資訊流。
• 比較（Comparison）：透過比較多個同步或複製元素的輸出來偵測不安全狀態。當複製體數量達三個或以上時，不僅能偵測不安全狀態，還能指出是哪個元件導致的。比較不一定導致投票——另一個選項是在輸出不一致時直接關機。

Containment#

遏制策略旨在限制進入不安全狀態後的損害，包含三個子類別：

冗餘（Redundancy）：

• 複製（Replication）：最簡單的冗餘策略，擁有元件的複本。對隨機硬體故障有效，但無法防護設計或實作錯誤（因為缺乏多樣性）。
• 功能冗餘（Functional Redundancy）：透過 設計多樣性 解決 共模故障（Common-mode Failures）——即複製體因共享相同實作而同時出現相同故障的問題。功能冗餘的元件在相同輸入下應產生相同輸出。仍易受規格錯誤影響，且開發和驗證成本更高。
• 分析冗餘（Analytic Redundancy）：允許元件層級和更高層級的多樣性（在輸入輸出層級可見）。可使用獨立的需求規格來容忍規格錯誤。通常將系統分為 高保證（High Assurance） 和 高效能（High Performance / Low Assurance） 兩部分——前者設計簡單可靠，後者更複雜準確但較不穩定。

限制後果（Limit Consequences）：

• 中止（Abort）：若操作被判定為不安全，在造成損害前中止。廣泛用於確保系統安全失效。
• 降級（Degradation）：在元件故障時維持最關鍵的系統功能，以受控方式丟棄或替換功能。例如：汽車導航系統在長隧道中失去 GPS 信號時，改用較不精確的航位推算法。
• 遮蔽（Masking）：比較多個冗餘元件的結果，在不一致時採用投票程序。投票器必須簡單且高度可靠。

屏障（Barrier）：

• 防火牆（Firewall）：限制對特定資源（通常是處理器、記憶體和網路連線）的存取，防止問題擴散。
• 聯鎖（Interlock）：透過控制對受保護元件的所有存取（包括正確的事件順序），防止因不正確的事件序列而產生的故障。

Recovery#

恢復策略將系統置於安全狀態：

• 回滾（Rollback）：在偵測到故障時，將系統恢復到先前已知的良好狀態。通常與 檢查點（Checkpointing） 和 交易（Transactions） 結合使用，以確保回滾的完整性和一致性。
• 修復狀態（Repair State）：修復錯誤的狀態，然後繼續執行——有效地擴展了元件能正確處理的狀態集。例如：車輛的車道維持輔助功能會監控駕駛是否保持在車道內，並在車輛偏離時主動將其導回安全位置。此策略不適用於恢復非預期的故障。
• 重新配置（Reconfiguration）：透過將邏輯架構重新映射到仍在運作的資源上，嘗試從元件故障中恢復。理想情況下可維持完整功能；否則可與降級策略結合以維持部分功能。

Tactics-Based Questionnaire for Safety#

在開始安全性策略問卷之前，應先評估專案是否已執行 危害分析 或 FTA，以識別系統中的不安全狀態。沒有這項分析，安全性設計的效果會大打折扣。

問卷涵蓋以下主要領域：

Unsafe State Avoidance：

• 是否採用替代機制（如硬體看門狗）取代危險的軟體設計？
• 是否使用預測模型提供潛在問題的早期警告？

Unsafe State Detection：

• 是否使用逾時來檢測元件是否符合時序約束？
• 是否使用時間戳記來偵測不正確的事件序列？
• 是否採用狀態監控來驗證設計假設？
• 是否使用健全性檢查驗證輸入輸出的合理性？
• 是否透過比較同步或複製元素的輸出來偵測不安全狀態？

Containment — Redundancy：

• 是否使用複製來防護隨機硬體故障？
• 是否使用功能冗餘來解決共模故障？
• 是否使用分析冗餘來容忍規格錯誤？

Containment — Limit Consequences：

• 系統是否能在不安全操作造成損害前中止？
• 是否提供受控的降級機制？
• 是否使用遮蔽與投票程序？

Containment — Barrier：

• 是否透過防火牆限制對關鍵資源的存取？
• 是否使用聯鎖控制事件的正確順序？

Recovery：

• 是否能回滾到先前已知的良好狀態？
• 是否能修復錯誤狀態後繼續執行？
• 是否能在故障後重新配置資源？

Patterns for Safety#

意外停止運作、錯誤運作、或進入降級模式的系統都可能對安全產生負面影響。因此，可用性模式 是安全性模式的首要參考來源。

Redundant Sensors#

若感測器產生的資料對判斷安全狀態至關重要，該感測器應被 複製。獨立的軟體應監控每個感測器——本質上是可用性中冗餘備用策略在安全關鍵硬體上的應用。

• 優點：防護單一感測器故障
• 權衡：增加系統成本；處理多個感測器的輸入比處理單一感測器更複雜

Monitor-Actuator#

此模式使用兩個軟體元素——監視器（Monitor） 和 致動器控制器（Actuator Controller）——在向實體致動器發送命令前進行檢查。致動器控制器執行計算以確定要發送的值，監視器在發送前檢查這些值的合理性。這將 值的計算 與 值的驗證 分離。

• 優點：監視器作為致動器控制器計算的冗餘檢查
• 權衡：需要開發和維護監視器；但因為計算與監控的分離，可以靈活調整監視器的複雜度

Separated Safety#

安全關鍵系統通常需要由權威機構認證為安全。認證整個大型系統非常昂貴，但將系統劃分為 安全關鍵部分 和 非安全關鍵部分 可以降低成本——只需認證安全關鍵部分。同時，分離本身也需要被認證，以確保非安全關鍵部分不會影響安全關鍵部分。

• 優點：降低認證成本；集中資源在與安全直接相關的部分
• 權衡：分離工作本身可能昂貴（例如安裝兩套不同的網路）；說服認證機構分離正確性有挑戰，但遠比讓整個系統都以最嚴格的標準認證來得容易

設計保證等級（Design Assurance Level, DAL）：在航空領域，DO-178C 定義了從 A（災難性——可能導致死亡）到 E（無影響）的五個等級。DAL 幫助決定在哪裡投入有限的測試資源。相似地，安全完整性等級（Safety Integrity Level, SIL） 在 IEC 61508 標準中定義了四個等級。隨著自動駕駛的發展，ISO 26262 和 ANSI/UL 4600 等新標準正在因應軟體掌控方向盤的挑戰。

安全性與可用性的關係#

安全策略與可用性策略有大量重疊。這是因為：

• 可用性問題（系統停止運作或錯誤運作）經常直接導致安全問題
• 許多用於修復問題的設計解決方案在兩個品質屬性之間是共通的
• 意外停止運作、錯誤運作或進入降級模式的系統都可能對安全產生負面甚至災難性的影響

因此，第四章中描述的 可用性模式 都適用於安全性。安全性在此基礎上增加了更多針對性的策略，如替代（用硬體取代危險軟體）、分析冗餘（用獨立規格容忍規格錯誤）和聯鎖（控制事件的正確序列）等。

總結#

安全性關注防止系統進入可能導致損害、傷害或生命損失的狀態。架構師必須透過 FMEA 和 FTA 等技術識別安全關鍵功能，並運用 不安全狀態避免（替代、預測模型）、不安全狀態偵測（逾時、時間戳記、狀態監控、健全性檢查、比較）、遏制（冗餘、限制後果、屏障）、恢復（回滾、修復狀態、重新配置）四大策略類別來設計安全機制。實務上，冗餘感測器、Monitor-Actuator 和分離安全性等模式提供了經過驗證的架構解決方案。安全性設計的代價通常是額外的成本和複雜度，但從蘇聯飛彈誤報、法航 447 到波音 737 MAX，歷史上的慘痛教訓一再提醒我們：安全性是不容妥協的品質屬性。