在嵌入式系統中，任務排程是管理並及時執行多個任務或操作的關鍵過程。嵌入式系統通常具備專用功能（如汽車控制、醫療設備），對效能、可靠性與資源優化有嚴格要求。 由於資源（運算能力、記憶體、電力）有限，排程器必須精確決定處理器執行任務的順序與時間，以維持系統的響應性與效率。整理了最近複習系統設計的一些內容，如果你也在加強自己的系統設計，特別在任務排程這一塊，也可以一起複習一下！
任務排程技術的類型
- 協作式排程 (Cooperative Scheduling)： 任務運行直到完成或自願放棄 CPU。簡單但若某個任務不放權，會導致其他任務延遲。
- 優先權搶占式排程 (Preemptive Scheduling)： 系統可中斷當前任務以執行更重要的任務。確保高優先級任務能立即執行，適合即時系統（Real-time systems）。
- 輪詢排程 (Round-Robin Scheduling)： 每個任務分配固定的時間片，公平競爭 CPU。不適合對時間敏感的任務。
- 速率單調排程 (Rate Monotonic Scheduling, RMS)： 執行頻率越高的任務優先級越高。適合週期性重複的預測系統。
- 最早截止時間優先 (Earliest Deadline First, EDF)： 截止日期最接近的任務優先執行。
- 靜態 vs. 動態排程： 靜態在運行前設定好，具預測性；動態在運行時決定，具靈活性。
- 混合式排程： 關鍵任務用靜態，非關鍵用動態。
即時任務排程概念 (Real-Time Concepts)
- 硬即時 (Hard Real-Time)： 必須在嚴格截止時間內完成，否則會導致系統失效。例如：安全氣囊啟動。
- 軟即時 (Soft Real-Time)： 錯過截止時間會降低效能但不會導致災難。例如：影片串流。
固定優先級 vs. 動態排程
- 固定優先級： 每個任務優先級固定，簡單且可預測（如醫療監控設備）。
- 動態排程： 優先級根據當前需求動態調整，靈活（如遊戲中的操作處理）。
常見排程演算法
- 先來先服務 (FCFS)： 依到達順序執行，簡單但易造成長任務阻塞短任務。
- 優先權基礎排程 (Priority-Based)： 系統始終執行最高優先級任務，但需注意避免低優先級任務發生「飢餓 (Starvation)」現象。
影響排程的因素
- 任務優先級與截止時間限制。
- 週期性： 任務是否需要定期執行（如每秒讀取感測器）。
- 任務依賴性： 某任務是否需等待另一任務完成。
- 系統資源與中斷處理。
- 能源限制： 針對電池供電系統優化。
面臨的挑戰
- 資源有限： 難以同時處理多個複雜任務。
- 即時限制： 確保關鍵任務絕不延遲。
- 任務依賴： 管理先後順序，避免效能瓶頸。
- 中斷處理： 平衡緊急事件與正常任務執行。
- 動態性質： 任務執行時間可能因輸入條件而改變。
最佳實踐 (Best Practices)
- 優先處理關鍵任務。
- 優化資源使用： 減少開銷，如合併小任務。
- 使用時間分區 (Time-Partitioning)： 為複雜任務設定固定時間片。
- 高效處理中斷： 限制中斷處理時間。
- 使用即時作業系統 (RTOS)： 如使用支援優先級排程的 RTOS 來自動化管理。
- 測試與模擬： 在實際上線前進行模擬測試。
未來趨勢
- AI 與機器學習： 自動優化排程決策。
- 邊緣運算 (Edge Computing)： 減少延遲，本地處理數據。
- 多核處理： 同時執行多個任務。
- 容錯機制 (Fault Tolerance)： 確保部分失效時系統仍能運作。
排程機制的哲學——確定性與即時性的權衡
在典型的伺服器管理場景中，微控制器 (MCU) 級別的 BIC (如 AST1600) 必須採用搶占式排程 (Preemptive Scheduling)。這種設計的核心意涵 (Implications) 在於：當緊急硬體訊號（如電源異常或過溫中斷）發生時，系統必須能在微秒等級內強行中斷當前任務。這種「硬即時性」確保了系統行為的確定性，即使在處理低優先級的日誌記錄時，關鍵的保護邏輯也能精準執行。
相對地，運行 Linux 的 BMC (如 AST2600) 則展現了不同的設計思維。Linux 採用分時公平排程，旨在最大化系統整體的吞吐量 (Throughput)。雖然其運算能力更強，能處理 Web Server 或 RESTful API，但在面對高頻率的即時控制時，其非確定性的排程延遲也可能導致控制失敗。
OpenBMC 架構中的現代設計挑戰
OpenBMC 作為一個成熟的 Linux 框架，其最大的系統設計挑戰在於處理間通訊 (IPC) 的效能優化。OpenBMC 以 D-Bus 作為跨進程通訊的中樞，這種高度解耦的架構雖然提升了模組化程度，卻也帶來了明顯的開銷。
在進行 OpenBMC 的效能優化時，工程師必須評估 D-Bus 訊息傳遞對 CPU 造成的上下文切換負荷。例如，在監控數百個感測器數據時，若直接在 D-Bus 上發送原始高頻訊號，極易引發「中斷風暴」。成熟的設計方案會引入緩衝機制或非同步 I/O，確保資料流動不會阻塞核心的管理邏輯。這是一種典型的 Trade-off（權衡）：犧牲了一點數據的即時性，換取了系統整體的穩定與可用。
針對嵌入式系統的嚴苛要求，我們可以透過以下四個關鍵維度來審視並精煉我們的設計：
首先是預測性 (Predictability) 的評估。我們會透過邏輯流程圖嚴格審查每一條路徑，確保系統在面對重複輸入或邊界條件時，能產生一致且可靠的執行結果。這對 BMC 這種需要長期穩定運行的管理系統而言，是排除非預期錯誤（Non-deterministic errors）的基石。
其次是響應能力 (Responsiveness) 的檢測。針對關鍵事件（如緊急斷電訊號），我們需評估系統從硬體觸發到韌體反應的完整路徑延遲。這直接決定了系統在面對災難性故障時的自癒能力，也是衡量一個 RTOS 設計優劣的核心指標。
此外，安全性連帶影響 (Safety Implications) 的考量不容忽視。優良的架構設計應具備故障隔離能力，確保單一任務的失效不至於導致整機癱瘓。透過對設計細節的深度討論，我們能釐清軟體邏輯如何為硬體安全屏障提供關鍵補強。
最後，我們將持續進行效率優化 (Refining for Efficiency)。這不僅是為了追求更快的執行速度，更是為了在有限的處理能力與功耗預算下，擠出更多的系統裕度。透過不斷迭代與精簡邏輯流程，我們能確保系統在極端負載下，依然能維持優異的效能表現。
總結而言，一個卓越的嵌入式系統設計，絕非僅是將硬體與代碼拼湊在一起，而是一場在限制中追求極致平衡的藝術。當我們能從預測性、響應性、安全性與效率這四個維度，對自己的設計進行深刻反思與精煉時，我們才真正具備了應對下一代智慧硬體挑戰的資深架構思維。
