上一篇文章中，我有提到風扇在控制的時候會有Zone的區分。這是為什麼呢？伺服器內部並不是一個均勻的空間，不同的元件（如 CPU、記憶體、硬碟、網卡）分佈在不同位置，它們的發熱特性與耐熱上限截然不同。現代伺服器內部通常有風罩（Air Shroud）或擋板。分區可以對應這些物理隔離，確保風扇產生的風量優先服務於該區域的元件。也可以根據不同熱特性差異：
- CPU/GPU/PCIe switch：發熱量大且變化極快，需要能快速反應的 PID 曲線。
- HDD/SSD：發熱量大但變化慢，耐溫較低，需要平穩、緩慢變動的風量。
設計不同的冷卻控制行為或演算法。當然還有一個很重要的原因是，風扇通常排成一列（Fan Wall）。靠近左側的風扇主要冷卻 CPU0，右側的風扇冷卻 CPU1。如果不分 Zone，為了冷卻過熱的 CPU0 而讓全機 10 個風扇都加速，是非常沒效率的。
因應風扇控制有所謂的Zone，OpenBMC在管理上也變的相對複雜一些。Thermal team需要詳細定義哪些風扇屬於哪個 Zone、哪些感測器該被列入計算，這需要對硬體架構有極深的了解（所以通常也會找硬體部門EE一起討論）。再者，為了確保Thermal team所設計的Fan table，不論是只執行Linear的風扇控制或者含有PID的自動控制公式，都需要近一步的做實驗來確認其穩地性與可行性。在這個過程中，韌體工程師需要預留debug相關的程式碼，以確保有足夠的資料可以分析每個當下的sensor情況與風扇轉速，是否在正確的自動控制中，可以達到很好的冷卻功效。了解了 Zone 的重要性後，回過頭看 DbusPidZone 這個類別。我沒有先從Fan control的main function開始寫起，反而是先介紹一個類別，因為這個類別對我來說包山包海，幾乎你想到Fan control應該要做的事情都離不開他。所以，如果介紹這個類別的時候你對於整個風扇控制的流程還是沒有覺得很清晰，那是正常的。因為我們還在介紹他的功能與實作，我還會在講一下他的流程與main function。接下來，我們分成幾大項來講一下這個類別的職責報告：
- D-Bus Communication
繼承並實作多個 D-Bus 儀表板介面，處理外界指令。處理指令的部分包含manual/auto mode的切換，有時候風扇控制出現異常，或者是機器進到了原本fan table沒有辦法cover的error situation，此時我們會緊急調整成manual mode，可能是手動把風扇全部調整到100轉，也或者是手動調整成某一個固定轉速以確保系統的安全。另外，當風扇控制的處理流程中，出現了異常，可是程式並沒有確切的error handle，需要記錄這個error log或者回報給工程師讓工程師來進行妥善的處理，Fan control會透過Dbus interface把log送出來。最後是addPidControlProcess為每個 PID 控制器（如單獨的溫度或功耗控制器）建立一個專屬的 D-Bus 物件，讓外部工具可以即時監控。這個Function定義該控制器的類別（如 Temperature, Margin 或 Power）並設定預設的目標值（Setpoint），這個目標值決定該自動控制物件何時會開始啟動。也讓外部使用者能透過 D-Bus 介面，在不重啟服務的情況下，動態地啟用或禁用特定的 PID 控制運算。 - Sensor Caching & Management
這裡的processSensorInputs會負責循環讀取感測器、計算超時時間，並用多個 Map 來存放感測器原始值與處理後的值。還有一個很有趣的function是updateFanTelemetry. 我以前沒有想過，為什麼fan的轉速也需要cache?想像一下，如果 PID 運算過程中，算比例 (P) 的時候讀取一次感測器，算積分 (I) 的時候又讀取一次，而這兩次讀取之間風扇轉速變動了，這會導致數學模型產生微小的誤差。另一個原因也是因為讀取硬體（如透過 D-Bus 或 sysfs）通常很慢且有延遲。先一次性把數據全部抓好存進記憶體（Cache），後面的 PID 運算就可以在極短的時間內完成，而不必在計算過程中等待硬體反應。總的來說，這確保了在同一輪迴圈（Iteration）中，所有的控制器（Thermal PIDs, Fan PIDs）看到的數據都是同步的「那一個瞬間」的狀態。這個細節，通常只有相對資深的韌體工程師會注意到。（呵呵 - PID Loop Orchestration
每個Zone會算出自己根據管理的sensor以及對應的公式, 得到一個output轉速。而這些轉速會統一被收集，在determineMaxSetPointRequest裏面做最終的抉擇。抉擇會根據多個不同的條件來決定，每個條件也有他的優先權。總結決策優先順序： - Tuning File (最高優先級，一旦檔案存在則無視其他邏輯，確保manual手動控制永遠可以覆寫自動控制的轉速)
- Ceiling (如果有設定，絕對不能超過，意思是最高轉速不能高於這個天花板值)
- Thermal PID Requests (多個熱感測器的計算結果，有時候是linear+pid疊加才是output風扇轉速，例如：PID_CPU0 + Stepwise_CPU，系統會取最大值)
- Minimum Setpoint (最低保障，確保不低於此值)
- Failsafe Mode
它負責即時監控感測器的健康狀態，一旦透過processSensorInputs偵測到讀值異常，便立即將該感測器標記為失效並列入追蹤清單。此時，系統會強制介入，計算所有控制區塊（Zone）中所需的安全轉速 (Failsafe Percent)，無視常規 PID 運算，直接將風扇拉高至該安全數值，確保在感測器數據不可靠時，硬體仍能獲得足夠散熱以避免損壞。
DbusPidZone 只是「指揮」，而這兩者是真正的「執行」。
- ThermalController: 將感測器溫度轉換為轉速請求。
- FanController: 將轉速請求轉換為實際寫入硬體（或 D-Bus）的 PWM 指令。
之後我們從main function開始往下走，就可以對整體風扇控制有更多認識。
