top of page
搜尋

無形的守護者：軟體功能安全（Class B）的邏輯架構、失效檢測與自我診斷

在過去的電氣時代，安全是由堅硬的物理實體構成的：雙金屬片溫度開關、熔斷絲、機械微動開關。這些元件看得見、摸得著，其失效模式遵循明確的物理定律（如金屬疲勞、接點沾黏）。


然而，隨著物聯網與智慧家電的普及，微控制器（MCU）接管了統治權。現在，決定一個加熱器是否過熱、一個高壓馬達是否該緊急停機的，不再是物理開關，而是一段燒錄在矽晶片中的軟體代碼（Code）。


這引入了一個令傳統安規工程師不安的問題：如果程式碼「當機」了，或者記憶體中的一個位元（Bit）被宇宙射線翻轉了，設備會變得危險嗎？


這就是功能安全（Functional Safety）的領域。本文將依據 IEC 60730-1（Annex H）及 IEC 60335-1（Annex R）的架構，深入解析安規軟體的分類哲學、針對 CPU/RAM/ROM 的關鍵診斷技術，以及「看門狗（Watchdog）」背後的工程邏輯。



軟體失效的本質：從磨損到系統性錯誤


首先，我們必須釐清軟體失效與硬體失效的根本差異。


  • 硬體失效通常是隨機的（Random）或老化的（Wear-out）。電容會乾涸，繼電器會磨損。我們可以預測其平均故障間隔時間（MTBF）。

  • 軟體失效則是系統性的（Systematic）。軟體不會「生鏽」或「磨損」。如果軟體有 Bug，它從出廠的第一天起就存在。此外，軟體極易受到硬體異常（如電磁干擾 EMI 導致的暫存器數值跳動）的影響而進入未定義狀態。


因此，安規對軟體的要求，側重於「避免設計錯誤」以及「偵測運行時的硬體異常」。


軟體的分級哲學：Class A, B, C


並非所有程式碼都需要保護。標準根據軟體失效後對安全的影響程度，將其分為三類：


Class A：功能性軟體

  • 定義： 軟體的失效不會導致產品不安全。

  • 範例： 房間燈光的調光控制、洗衣機的洗滌模式選擇。如果它壞了，頂多是燈不亮或衣服洗不乾淨，不會有人受傷。

  • 要求： 基本無需特殊的安規措施。

Class B：防止不安全操作的軟體

  • 定義： 軟體的失效可能會導致設備失去保護，進而產生危險（如過熱、起火）。這是絕大多數帶有電子控制的家電與 IT 設備所屬的類別。

  • 範例： 電子鍋的溫度控制（防止乾燒）、馬達的過載保護、微波爐的門鎖監控。

  • 要求： 必須導入「故障檢測」與「容錯設計」。例如，當溫度感測器讀數卡死時，軟體必須能偵測到並切斷電源。

Class C：特殊危害防護軟體

  • 定義： 用於防止特殊危險（如爆炸）的軟體。

  • 範例： 瓦斯熱水器的燃燒器控制（防止瓦斯洩漏爆炸）。

  • 要求： 需要極高可靠性的雙重冗餘設計（如雙 MCU 架構）。


Class B 軟體的核心防線：自我診斷技術


對於 Class B 軟體，標準要求 MCU 必須在運行過程中，不斷地進行「自我體檢」。這不是為了效能，而是為了確認「大腦」是否清醒。


1. 腦細胞的檢查：暫存器與 RAM 測試 (Variable Memory)


隨機存取記憶體（RAM）存放著程式運行時的關鍵變數（例如：Current_Temp = 100）。如果因為強烈的電磁干擾（ESD/Surge），導致儲存該數值的電晶體翻轉，將 0 變成了 1，溫度數值可能瞬間變成極大的錯誤值，導致誤動作。


診斷邏輯：走動位元測試 (Walking Bit Test) 為了檢測 RAM 是否損壞或被黏滯（Stuck-at fault），軟體會定期執行一種特殊的寫入讀取測試：


  • 原理說明： 想像一排燈泡（代表記憶體位元）。我們不只是全部打開或關閉，而是讓一個「亮點」從第一個燈泡移動到最後一個。

  • 過程： 寫入 00000001，讀回確認；然後寫入 00000010，讀回確認...直到 10000000。

  • 目的： 這確保了每一個記憶體位元都能獨立地被寫入 0 和 1，且相鄰的位元不會發生短路干擾（Coupling fault）。


2. 記憶的完整性：Flash/ROM 測試 (Invariable Memory)


唯讀記憶體（Flash/ROM）存放著程式碼本身（指令集）。如果這裡的位元發生翻轉，原本的「關閉加熱器」指令可能會變成「無操作」或「全速加熱」。


診斷邏輯：週期性檢查和 (Cyclic Checksum)

  • 原理說明： 在程式編譯時，我們將所有程式碼的數值進行累加或經過特定演算法計算，得到一個獨一無二的「指紋」（Checksum 或 CRC），並將其存在記憶體的尾端。

  • 運行時監控： MCU 在空閒時，會重新計算一次當前所有程式碼的總和，並與尾端那個預存的「指紋」進行比對。如果兩者不一致，代表程式碼已損壞，系統必須立即進入安全狀態（Safe State）。


3. 時間的守護者：看門狗計時器 (Watchdog Timer)


這是最經典的軟體安全機制。程式可能會因為邏輯錯誤（死迴圈）或外部干擾而「當機」，停在某個指令不動了。


診斷邏輯：餵狗 (Kicking the Dog)

  • 基本原理： 想像一隻惡犬（獨立的計時硬體），它非常餓。程式必須每隔一段時間（例如 100 毫秒）去「餵」它一次（重置計時器）。如果程式當機了，忘了餵狗，這隻狗餓過頭就會「咬」系統一口——強制重置（Reset）整個 MCU，讓系統重新啟動。

  • 進階邏輯：窗口式看門狗 (Windowed Watchdog) 對於 Class B 軟體，僅僅「有餵」是不夠的。如果程式跑飛了，變成一個只會瘋狂餵狗的死迴圈怎麼辦？ 因此引入了「時間窗口」的概念：餵狗不能太慢，也不能太快。必須在特定的時間區間內（例如 80ms 到 100ms 之間）餵食才有效。這確保了程式不僅是活著的，而且是按照預期的節奏在執行任務。


4. 系統時鐘監控 (Clock Monitoring)


MCU 的心跳來自石英振盪器（Crystal）。如果石英振盪器損壞，頻率變快或變慢，會導致所有與時間相關的安全功能（如加熱 10 秒後切斷）失效。


診斷邏輯：獨立時基比對 MCU 內部通常有一個精度較差、但完全獨立的內部時鐘（RC Oscillator）。Class B 軟體會利用這個內部時鐘來計數外部石英振盪器的脈衝。如果計數值超出了預期範圍（例如，原本該數 1000 下，結果只數到了 500 下），就代表主時鐘發生了頻率漂移，必須報警。


安全狀態 (Safe State) 的定義


所有的診斷技術，最終都指向一個問題：檢測到錯誤後，該怎麼辦？


這就是安全狀態（Safe State）的定義。安規工程師必須與軟體工程師共同定義，當上述任何一個診斷（RAM 錯誤、ROM 錯誤、看門狗溢位）失敗時，硬體必須進入的狀態。


  • 對於加熱器： 安全狀態通常是「斷電」（所有繼電器斷開）。

  • 對於門鎖： 安全狀態可能是「保持鎖定」（防止運轉中開門）或「解鎖」（防止人員被困），視風險評估而定。


這個動作必須是確定性的，且優先級最高，不能被其他中斷（Interrupt）所阻擋。


結論：代碼即元件


在現代安規工程中，軟體已經不再是抽象的邏輯，而被視為一個關鍵的安全零部件（Critical Component）。


Class B 軟體的設計要求，迫使工程師正視微控制器的物理脆弱性。從 RAM 的位元翻轉到時鐘的頻率漂移，每一行用於自我診斷的代碼，都是為了在物理硬體不可靠的現實中，構建出一個邏輯上絕對可靠的安全堡壘。


對於安規專家而言，審查產品不再只是看電路圖，更要看軟體流程圖。理解 Walking Bit 測試與窗口看門狗的運作，已成為確保智慧時代產品安全的必備技能。

bottom of page