1. 引言
1.1 工控軟件的一般問題
工控軟件設計可分為基于控制環和基于實時操作系統兩大類。控制環是把各個功能模塊連接成首尾相接的環狀結構。其特點為任何一個功能模塊都不能出現死循環，甚至循環次數太多的循環語句都應避免出現。以保證能夠在實時意義上盡可能快地遍歷各功能模塊，從而滿足實時多任務的需求。在各功能模塊中一般用狀態機來描述模塊所處的狀態。而實時操作系統則可以通過一套底層機制根據優先級和各任務狀態調度各功能模塊。此時各功能模塊就以“任務”作為表現形式。但是在每個任務內部仍然為一個獨立的控制環結構，仍然需要用狀態機描述。本文將結合工程實踐論述狀態機在工控中的應用，給出通用模型和注意要點。
1.2 有限狀態機
有限狀態機是一種重要的思想方法。從數學的角度看，它實際是一個五元組M = （I, O, S, δ, λ），其中I，O分別表示輸入輸出，S為狀態向量，δ為次態方程（δ: S×I ->S）， 表示輸出方程（λ: S×I -> O）。有限狀態機從結構體系上有層級狀態機，并發狀態機等。層級狀態機類似于軟件中的子程序調度：更高層的一個狀態對應于較低層的一個狀態機。這個高層的狀態處于底層狀態機的某個狀態中。這個低層狀態稱為子狀態。與子程序調用受到系統堆棧深度制約不一樣，層級狀態機可以由開發者根據控制對象的層次性運動規律任意指定深度。與子程序的目的一樣，層級狀態機也是為了提高控制軟件的模塊化程度，降低狀態分析的復雜度。并發狀態機偏重于描述狀態機的調度。狀態機本身不能實現什么并發功能，并發的實現是通過軟件調度的。如果把狀態機理解成一個任務，那么就能理解并發的實現。在控制環中，一個“任務”就是一個功能模塊，我們只需要把多個狀態機串聯在環中，也就是實現了多輸入多輸出的并發控制。此時，多個狀態機在空間上是并存的，然而卻是分時調用的，調用的周期等同于控制環掃描一周的時間。不過如果CPU運算速度足夠快，這個周期將會足夠的快，達到“實時”的程度，從而這多個狀態機也就實現了“并發”運行。同理，在多任務操作系統中，“并發”的實現就更容易理解了，除了在單個任務內存在控制環的并發控制外，在任務之間也同樣存在多狀態機的并發運行。當然，從CPU的角度而言，只要是單核的，也就從來不存在真正的“并發”，它在任何一個特定的時間點都只能處理某個特定狀態機。不過多任務操作系統卻提供了一套底層機制來調度原來僅靠控制環來調度的任務。
2.有限狀態機在前后臺信息交互中的作用
工控系統一般都具有人機對話界面。其通常的操作模式為用戶進入某個頁面，選取某項操作并執行。人機對話界面通常被設定為一個獨立模塊。該模塊軟件結構為一個消息控制環。用戶在硬件接口的操作會通過接口的驅動程序封裝成消息加入到專屬界面模塊的消息隊列中。消息控制環循環掃描該隊列，如有新消息則提取并解釋然后封裝成新消息發往后臺執行。前后臺軟件的接口模塊負責分發界面消息到各個執行模塊。消息應包括目標模塊的編碼，命令編碼以及命令參數。前后臺接口模塊的軟件結構多采用以下兩種模式。
圖1 兩種消息分發結構
模式一的輸出結構根據消息數據的目標模塊編碼直接分發消息到各模塊中。模式二則是根據當前系統所處的狀態再分發消息到各模塊中。也就是說模式二在模式一的基礎上增加了一個系統級的狀態機。下面我們看看兩種不同的輸出結構會帶來何種影響。
工控軟件設計者通常會碰到兩種情況。一是在研發階段，界面任務與控制任務聯調時，雙方均有可能出錯。對于界面任務而言，有可能自身原因誤發消息;而對控制任務，也有可能輸出時序出錯。此時需要在聯調中快速定位故障，縮短研發周期。二是在產品運行中由于惡劣工況的影響，導致緩沖區數據發生異常。比如消息頭的模塊編碼發生位翻轉，則會直接導致控制任務接收到錯誤的界面消息。對于模式一，如果界面消息出錯則會出現全局的混亂。比如模塊1收到消息后開始輸出一個控制時序，期間界面層又發來一個錯誤的消息，使其分發到模塊2，于是模塊2馬上開始輸出時序。這個不希望輸出的時序在工控中有可能會導致災難。而在聯調時出現這種現象，則無法立刻判斷到底是模塊1還是界面層出的問題。但如果采用模式二則可以屏蔽這種混亂。如下圖
圖2 不同分發結構對錯誤消息的處理示意圖
我們可以看到由于模式二采用全局狀態機標定當前軟件所處的狀態，消息首先會到達相應的狀態處理程序，然后才進行分發。此時分發語句可以根據當前的狀態屏蔽不應該被調用的模塊。即使消息出現錯誤，也會過濾掉，等待正確消息的到來。而且可進一步優化為當收到錯誤消息可以通知界面層。可見在控制軟件前后臺的接口層增加一個標記后臺狀態的全局狀態機有助于增強軟件的健壯性。
3.狀態機的錯步問題
工控軟件本質上是根據一定的邏輯條件給出有序的輸出。根據輸出的次序可以劃分不同的狀態。邏輯條件在嵌入式領域中就是用戶的輸入和傳感器的狀態。正是這些條件決定了狀態的躍遷。在這里我們探討的是根據傳感器輸入而建立的狀態機。很明顯，它的運行速度比前述系統級狀態機高很多。這種狀態機分布在軟件的控制層中，正是它們使得受控對象能夠有序精確高速的運行。對于這樣高速運轉的狀態機，如果考慮不周全，會使其產生失步或者跳步，即高速狀態機中的錯步現象。由于控制層的狀態機的躍遷條件來源于傳感器信號，如果不能完全跟蹤到傳感器信號的變化，則躍遷條件將被遺漏，導致狀態機不能躍遷到新的狀態。這就會導致失步。有兩種情況會導致傳感器信號的檢測遺漏：一是采樣頻率不夠高，漏掉了一些保持時間較短的信號。這可以通過硬件上提高采樣頻率得到解決。二是狀態機設計的缺陷，詳見以下例子。
圖3 出現失步的狀態機
由圖3可以看出，狀態1根據傳感器a信號躍遷到狀態2，狀態2根據傳感器b信號躍遷到狀態3。如果b信號在a信號前發出了一個完整的脈沖，由于根據狀態圖在狀態1時并不需要檢測b信號，因此當躍遷到狀態2以后，狀態機就出現失步了。解決這個問題需要預先分析好a，b信號的關系。如果是b信號一定出現在a信號前，那不妨把狀態1和2的條件判斷對調，如果兩個信號是并發關系的，那就要合并狀態機1，2，把a，b信號作為躍遷到3的綜合條件。因此解決失步問題的要點在于仔細考察受控對象處于此狀態時所可能出現的傳感器信號變化及其變化關系。
在處理“輸入-輸出對”時要注意防止狀態機跳步。“輸入-輸出對”是嵌入式領域中經常遇到的控制模式，類似于應答機制。控制層給出一個輸出，使得傳感器信號產生變化并反饋，過一段時間后，控制對象運動完成，傳感器信號恢復初態，此時控制層可以撤消原輸出并給出相關處理。設計者會有意無意的把注意力放在“什么時候撤消輸出”，因此設計出如圖4（a）所示的有潛在問題的狀態機。
圖4 出現跳步的狀態圖
可是控制對象在收到控制層輸出的驅動產生運動，傳感器感知運動并給出信號變化是需要時間的。根據圖4（a）的狀態機，很可能跳過傳感器信號變化的狀態，而直接到達“撤消輸出”的狀態。結果導致控制層的輸出僅僅是一瞬而過甚至是無法輸出，這就是跳步。為解決跳步問題，就需要設計者仔細分析所有的“輸入-輸出對”，把狀態細分。如圖4（b）所示，增加一個等待對象運動的新狀態，確保上一狀態的輸出驅使對象真正運動以后才判斷對象運動停止。然而在細分狀態的同時也要注意防止失步。狀態分得越細，越要注意分析此狀態中所有可能出現的信號變化。