海爾熱水器溫控功能改進探討與嵌入式軟體領域分析

上篇（海爾熱水器遙控功能改進探討與嵌入式軟體需求開發）談到海爾某款熱水器的水溫控制在每次重新開水點火的時候，會經歷高溫與低溫上下波動幾次最後才穩定到設定溫度的過程。在此期間，忽冷忽熱的水溫會讓人感覺不適。

分析其間的緣由，筆者認為可能是熱水器採用的溫控演算法自身限制所造成的。為了讓熱水器出水溫度穩定在設定溫度，熱水器通過溫度感測器實時監測水溫，如果水溫偏離設定值，則利用火力調節器來調整燃氣的供應量，以改變火力大小，從而控制水溫回到設定值。

一般熱水器會採用簡單的負反饋閉環控制演算法來實現上述控制程式——當水溫偏低時，調高火力，水溫隨之上升；然而增高的火力幅度往往矯枉過正，水溫很快超過設定溫度，於是反過來又調低火力，使得水溫下降；同樣降低的火力幅度也常常超出需要，水溫很快又低過設定溫度。如此反覆多次，隨著火力調節的幅度不斷減小，水溫與設定值偏差越來越小，直到進入允許的精度範圍內，火力與水溫才最終同時被穩定下來。

要改進熱水器的水溫控制功能，歸根結底就是要改進水溫控制的演算法。實際上，嵌入式軟體開發中的重頭戲，除了上篇所討論的人機互動設計外，就是各類控制演算法或服務演算法的設計了。而要設計一種好的演算法，缺乏相關領域（即演算法要解決的問題域）的知識是不可想象的。在嵌入式軟體開發過程中，最上游的核心環節是領域建模或分析。我們將通過領域分析來剖析嵌入式系統所要面對的問題域，並收集相關的領域知識，以便開發者據此設計出合適的解決方案（演算法）。要強調的是，領域建模的成果除了供設計環節使用外，需求開發環節同樣也離不開它們。

嵌入式系統之領域建模的內容主要包括：識別領域概念（實體元素）、領域關係（元素與元素間的關係，例如關聯、聚集、泛化等），歸納各種領域規律（例如相關規則、力學原理、數學方程式等），並抽象主要的主動元素（指非實體元素，例如系統的操作者——使用者、控制執行緒、網路節點、處理器或具備處理能力的晶片等）的典型行為（例如可用狀態機表述的激勵與響應過程），以及相關被動（功能）元素的典型行為特性等。

注意：對於應用軟體而言，在需求開發之前的環節是業務建模，業務建模的範圍比領域建模大，在領域建模之外還包括諸如識別執行者、描述業務流程等內容。嵌入式系統中的領域概念在業務建模中對應為業務物件；領域規律則主要對應為業務規則等；主動元素的典型行為對應為業務工員（business worker）的典型工作行為。

針對燃氣熱水器展開領域建模，我們可以識別的領域概念有：燃氣、水、溫度、單位時間出水量、單位時間供氣量、單位時間發熱量、（水的）比熱容（俗稱比熱）、（燃氣的）燃燒值、熱轉換率（或熱吸收率）等。相應的，識別的領域關係例項有：“水”組合下列屬性元素——“溫度”、“體積”；“水”與“比熱容”關聯；“燃氣”與“燃燒值”關聯等。

經過深入分析，可以歸納若干領域規律，例如，水溫與單位時間供氣量成正比例，與單位時間出水量成反比例等。

實際上，在這裡我們可以直接應用物理熱學定理，例如：

溫度（變化增量）=熱量÷（質量×比熱容）

（發）熱量=燃燒值×（燃氣）質量

經過推論，可以得到：

溫度（變化增量）＝燃燒值×單位時間供氣量×熱轉換率÷（單位時間出水量×比熱容）

接下來，我們還可以抽象得到若干主動元素，例如洗浴使用者、水溫控制執行緒；抽象的被動元素則有燃燒室、熱水器出水環路等。燃燒室的某個關鍵典型行為特性是，燃氣點火時，會出現一次發熱峰值；這是因為出氣閥門先開啟，等燃燒室積存了足夠多的燃氣後才點火，而點火後將瞬間燒盡這些燃氣，這會產生大量的熱量。

我們回過頭再研究上述的負反饋閉環控制演算法，理論上講，此演算法以一種震盪收斂的模式將水溫糾正到設定值，應當能夠較好地實現我們要求的溫控功能。然而，正是由於上段所述燃燒室點火時出現一次發熱峰值的行為特性，使得此演算法的實際工作效果難以令人滿意。點火後的發熱峰值使得水溫急劇升高，往往大幅度超出設定水溫，於是負反饋演算法會在實際供氣量正好甚至不夠的情形下，仍然計算得到一個較大的供氣減少量；此後較大的供氣減少量又使得水溫急劇降低，大幅度地低於設定水溫；雖然之後負反饋演算法將確保溫度曲線逐漸收斂到設定水溫，但起始的過寬曲線振幅，使得這個收斂過程的時間被拖長，當然更要命的還是造成大熱大冷的水溫讓人感覺不適。

如果更深入地分析此領域，我們還可以抽象出一個的被動元素——出氣閥門，並識別出其一典型行為特性——出氣閥門在短時間內做大幅度調整時，出氣量並非即時達到目標值，而是會出現一個波動峰值，之後才逐漸收斂到目標值。顯然，此行為特性會對上述溫度曲線的收斂過程帶來負面作用。此行為特性與燃燒室點火發熱峰值特性一樣，都會讓負反饋演算法在計算控制變數時出現誤判，因為當前實際（穩定後的）供氣量對應實現的水溫與當前取樣水溫發生背離。

根據領域分析的結果，我們不難得到一個結論，就是簡單的負反饋閉環控制演算法對燃氣熱水器的水溫控制效果不佳。在領域分析結果的指導下，我們完全可以設計出更佳的水溫控制演算法。針對燃燒室點火和出氣閥大幅度調整的行為特性，我們可以改進負反饋演算法計算控制（供氣）增減量的方法。例如，在點火後第一次進行負反饋控制時，並非簡單地依據當前取樣水溫與設定值的偏離值來確定（供氣）增減量，而是要綜合點火前的水溫取樣值、點火後水溫的最高峰值、以及水溫增高的速率和隨後的回落速率等，再對比目標設定值來決定（供氣）增減量。這個（供氣）增減量還要加上限制，即其絕對值不能太大，即使可能與最終穩定供氣量偏差很大，我們也要在後續的負反饋控制過程中小步收斂到最終值。

另外，如果能儲存歷史資料的話，還可以進一步利用歷史溫控收斂曲線資料來計算最佳的（供氣）增減量控制值序列。這是因為我們做領域分析時會發現，熱水器本次的進水原始水溫與上次工作時遇到的入水溫度差別不會太大，出水量的設定往往也類似，因此利用上次的工作溫控收斂曲線資料是可行的。針對洗浴使用者這一主動元素進行分析，我們又可以發現若干典型行為——頭一次開水點火；和在洗浴過程中，暫時關閉水閥並隨後再次開水點火；在持續燒水過程中改變水溫設定值。對於第二種行為，利用歷史資料的實用價值就更高了，因為暫停後再次開水時的當前水溫與設定值偏差通常較小，而且出氣閥當前的供氣量應當正好就滿足設定水溫的要求（除非使用者在暫停期間改變了水溫設定值）。

筆者不是燃氣熱水器相關領域的專家，這裡例舉的只是演算法改進的一些初步思路，並不具體，甚至本身可能都是錯誤的。但不管怎樣，這些論述應能印證領域建模在此的重大意義。

正常的嵌入式軟體開發，應當經歷領域建模與分析、系統需求開發、再到分析與設計、編碼實施、測試、部署等的環節過程。國內開發團隊，很少有明確的系統需求開發環節的，更不用說領域建模環節了。不同的嵌入式軟體，其面對的應用領域紛繁複雜，普通的程式設計師一般開始都不具備相關領域的知識背景，因此委派領域專家將領域知識表達為程式設計師可理解的領域模型，是決定開發專案成敗的關鍵。可傳閱的領域模型同時也能供大家評審，這樣還有助於我們及時發現領域認知上的錯誤與偏差。

另外，要得到一個優秀的演算法，很多時候僅僅依靠理論上的分析是遠遠不夠的。為了測試演算法的實際效果，需要進行大量的試驗，這時候，演算法要被具體編碼實施出來，並要執行它們，同時收集相關的測試資料。那麼這些工作應當歸結於哪個開發環節呢？是設計還是實施環節？

國內開發團隊對專案管理的認識還是不夠深入的。作為工程性的開發專案，其成功要素包含三個——質量、成本與工期。一些核心演算法的研究往往需要投入大量的資源和時間，而且還充滿各種不確定性（有可能失敗）。如果將這些演算法的試驗和研究放到專案的設計或實施環節來完成，專案的成本特別是工期將很難得到保證。工程性專案管理的一個核心原則就是不要引入任何高風險的因素。為此，慣用做法是專門安排一個預研專案，在此專案中準備相關模擬環境，以開發這些演算法等關鍵技術。而在工程性專案中，演算法的優化還是會有的（但不宜進行革命性的改進）。實際上，那些預研專案的性質通常也帶有濃厚的領域分析色彩，演算法的模擬環境是對領域的模仿，演算法的研究歸根結底是對領域問題解決的研究。總之，領域建模與分析既是普通工程性專案的最上游開發環節，也是預研性專案的最上游研發環節。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/17007506/viewspace-664189/，如需轉載，請註明出處，否則將追究法律責任。