[思考] Hard Realtime Fail：工程師的責任與韌性設計
從個人信念出發，延伸至系統韌性設計的必要性。
在對的時間產生對的結果
我們是否能提出一個最小資源需求，來滿足你整套軟體設計？
一個好的 Realtime System，不是「從不摔下台」，而是即使摔了，也知道怎麼站起來、怎麼通知其他人、怎麼保護整體秩序不受影響。
關於 Hard Realtime Fail 的心得與思考
我近期對於軟體系統中出現 Hard Realtime Fail 的現象，有一段深刻的思考。
一、Hard Realtime 的基本認知
Hard Realtime 的設計原則，是要求在一定的時間內完成預定的軟體行為。當這個條件無法滿足時，所造成的結果可能是：
- 軟體狀態出現錯亂；
- 軟體控制的硬體未被正確地操作；
- 引發一連串難以收拾的錯誤。
若我們要讓這種錯誤「可以被接受」，往往就需要在硬體中加入額外保護機制，或在軟體中加入狀態回復機制。但這些處理本身就代表「已經來不及了」，卻還要耗費額外時間來進行復原，是一件本質上非常違反直覺與效率的做法。
因此，我的立場是：Hard Realtime Fail 不應該發生。
二、工程上的拉鋸與思辨
面對這個問題，工程上會有兩種方向：
-
接受它的存在：
- 但若接受，就必須進一步思考：「那它可以失敗幾次？是不是可以一直這樣下去？」
- 這將導致系統可靠性的根本質疑。
-
拒絕它的發生：
- 若採取這條路，則必須重新審視：
- 我們是否在這段時間裡做了太多事情？
- 是否使用了效率極差的實作方式？
- 是否有其他模組（不論已知或未知）消耗了過多資源，間接導致我們超時？
- 若採取這條路，則必須重新審視：
三、一個比喻：舞台劇與演員
我用一個舞台劇的比喻來形容這整件事：
- 寫軟體就像是在寫一齣舞台劇的劇本；
- 執行這些行為的，是硬體或者系統中的變數，它們就像是舞台上的演員；
- 每位演員（模組）照著劇本與其他角色互動，一切都已經被規劃好。
當 Hard Realtime Fail 發生時，就好比某位演員突然從舞台上摔了下去，重傷不能動。這時候就出現了一個抉擇：
- 如果整齣劇的劇本設計本來就考慮到「有人可能會摔下台」，而所有與之互動的其他演員也都已經設計好對應的反應，那麼這個「摔下台」雖然是異常事件，但仍屬於可預期、可接受的一部分，因為整個舞台系統具備這種容錯能力；
- 但這樣又會引出下一個問題：那麼，這樣的異常狀況可以被接受幾次？ 頻率與容忍度該如何定義？
若沒有良好的限制與控制，整體系統最終仍會走向混亂。
四、我個人的信念
我相信：必須在正確的時間，讓正確的事情發生。
如果事情沒能在預期時間內完成，那就代表我違背了自己的工程信仰。這是必須改變的。為此，我會追查為何會發生 Hard Realtime Fail：
- 是否有人搶走了我的資源？
- 是否我自己寫得太慢、效率太差？
- 是否我對系統的理解不足，低估了所需資源？
最終回歸到一個問題： 我們是否能提出一個最小資源需求，來滿足你整套軟體設計？
AI 用嚴格的標準評論後，改寫一版
作為一位長期參與嵌入式系統與實時控制系統開發的工程師，我對於「Hard Realtime Fail」這個議題有一些反思與技術角度的梳理。
一、Hard Realtime 的定義與風險
在硬體控制、工業自動化、通訊協定控制、醫療或安全關鍵系統中，「Hard Realtime」意指系統中某些任務必須在特定時限內完成。 違反此約束的結果，不是效能下降，而是功能失效或災難性後果。
因此，Hard Realtime Fail（以下簡稱 HRF）並不單純是「跑太慢」，而是代表：
- 任務未在預期期限內完成
- 系統行為變得不可預測或失控
- 下游硬體行為或安全流程失效
這類失敗常見於以下情境：
- 競爭資源（如 CPU 或記憶體）被其他高負載任務耗盡
- IRQ latency 波動或無法預期
- 缺乏對 WCET（Worst Case Execution Time）的掌握
- 不當使用動態記憶體、blocking call，造成任務卡住
- Scheduler priority 配置錯誤，導致任務饑餓（starvation）
二、現實世界中，HRF 不是「是否發生」，而是「如何處理」
從理論設計角度來說，我們當然期望 HRF「絕對不會發生」，但從工程實務出發，這種絕對要求是不負責任的設計邏輯。 因為在任何複雜系統中，都會存在：
- 不可預期的硬體抖動（如電磁干擾、溫度飄移）
- OS jitter 或中斷 nesting 導致延遲
- 資源競爭（Memory bus、DMA channel、I/O）
成熟的實時系統設計不是只追求「永不失敗」，而是設計出：
- Fail-aware（失敗可偵測）
- Fail-safe（失敗後安全）
- Fail-recovery（失敗可回復）
- Graceful degradation（平滑降級）
這些才是真正反映「韌性」的設計思維。
三、舞台劇式比喻：具象但必須嚴格對應技術語境
有時我們會將系統比喻成一場舞台劇：
- 程式碼是劇本
- 模組與硬體是演員
- 系統執行流程是演出節奏
如果其中一個演員突然「摔下台」（即任務 fail），那整場演出是否要暫停？其他演員要怎麼反應？
這個比喻有其教育性，但若未加邊界限制，就會模糊技術語義。工程上的「摔下台」需對應具體狀況，例如：
- 任務是否 timeout？
- Scheduler 是否有監控機制？
- Watchdog 是否能 reset？
- 是否存在 fallback plan 或 redundancy？
若整個系統架構已設計為「知道有某些角色可能會 fail，並能在不干擾整體節奏下自動調整」，那麼這個 fail 就屬於設計內的一環，是被控制的「受限錯誤」。
但若沒有這層容錯設計，只靠演員「不要摔」作為信仰，那整場演出遲早會混亂。
四、HRF 發生的根因分析：數據、工具、證據
當系統出現 HRF，工程師的任務不是先責怪誰做得太多，而是要立刻展開技術分析：
- 是否完成了 WCET 測量？
- 有使用 trace 工具對任務行為進行觀察？
- 是否進行系統負載測試（Stress/Overload Test）？
- Priority assignment 是否合乎 RMS/EDF 準則？
- 是否正確配置中斷優先順序與 preemption 邊界？
- Memory access pattern 是否導致 cache thrashing？
所有這些，都要以資料為依據，而不是憑「直覺」或「覺得太慢」。
五、最終信念與工程邏輯的融合
我仍堅持一個原則：在時間要求內讓正確的事發生，是實時系統工程師的責任與榮譽。
但這個信念不能轉化為「拒絕錯誤存在」的硬性要求，而應該成為：
- 對系統負載與邊界條件的完整理解
- 對異常情況的模擬、預測與回應策略的規劃
- 對資源配置的最小化與優化
- 對系統錯誤行為的自動監控與自癒能力建構
一個好的 Realtime System，不是「從不摔下台」，而是即使摔了，也知道怎麼站起來、怎麼通知其他人、怎麼保護整體秩序不受影響。
這才是工程的專業與成熟。