運動控制最常見的及最簡單的狀態機應當就是報警狀態機了。報警狀態機模型如下：
圖表 1報警狀態機狀態轉換圖
上圖是系統報警狀態的簡化模型，共分為兩個狀態：
n：在該狀態下，系統處於正常狀態，沒有報警
w:系統處於報警狀態
輸入符號，共有兩個：
true:
報警觸發訊號，表示系統當中有故障
false:
該訊號來時，表示系統正常，沒有報警，可以執行
狀態轉換**如下：
圖表 2報警狀態機轉換**
動作觸發**如下：
圖表 3報警狀態機動作觸發**
運動控制裝置當中，報警型別可能有幾種，或者幾十種，甚至上百種，可能來自上位也可能源自下位，對於報警的處理，其大部分處理方式是相同的，既一旦有報警，則裝置停止，並告知使用者。一般還需要對該過程建立日誌。所有的過程對於程式實現來說都並不困難，很容易實現，似乎建立模型有些多此一舉。實際不是的，原因如下：
1)報警是分型別的
按照嚴重程度分：有警示性報警，這類報警不影響使用者操作和裝置執行，但是可能預示著會發生某一類故障或起到提示性作用；有故障型報警，這類報警常常會引發裝置停止。
按照報警源分：有資料報警或者軟體引發的報警；有外圍裝置的報警。
2)報警的處理方式不同即其有目的針對性
系統內的報警，處理方式並不相同。有的僅僅告知報警，之後不做任何處理，如一些畫面報警。有些不可以執行裝置的某些功能，但其它功能可以執行，比如手動操作。但有的要求將裝置進入鎖死狀態，除非報警解除，任何操作都不被允許，比如急停報警。有些報警只在終端顯示，在終端做記錄。有些報警需要上報伺服器，伺服器通過報警可以判斷裝置的狀態，使伺服器能對裝置做出一些合理的響應及處理。
採用狀態機模型對報警過程進行分析，主要是希望能把這個過程抽象出來。針對其每乙個部分，進行抽象的封裝，從而可以達到即使系統是不同的，但是也可以採用同乙個報警程式框架，進而減少**重複開發工作量。
從上文當中的幾個圖可以看出，設計這種需求的框架，分兩塊即可以，一塊是報警模組管理器，另外一塊就是報警模組。其中模型模組包含訊號發生器和動作觸發器兩種行為。
管理各個報警模組及管理一些輔助模組，如日誌系統
主要包括：
1） 報警資訊
2） 訊號發生器
掃瞄輸入訊號，或根據各種條件在邏輯處理或綜合計算以後產生輸入訊號3） 動作觸發器
動作觸發器對應的既是圖示3所對應的**,執行相應的報警觸發動作。
QT狀態機框架
qt的state machine framework是在qt4.6中引入的，其理論基礎是harel的statechart，通過定義一系列的可能狀態，以及系統如何在這些狀態中進行轉換 transitions between states 來描述整個狀態機的執行。qt的狀態機體系主要包括三部分模組 光有...
GPON接入 狀態機分析
gpon接入 狀態機分析 在g984.3和g987.3中定義了onu啟用的步驟。其狀態分別是 o1 初始狀態 o2 3 序列號處理 o4 時間調整 o5 正常操作狀態 o6 間歇的下行失步狀態 o7 緊急停止狀態 onu在上電以後，或者onu收到deactivationploam訊息以後，或者從o7...
設計模式（三）狀態機
狀態模式 主要解決某個物件具有不同的狀態，根據狀態的不同具有不同的行為。狀態的變化影響這物件的行為的問題。例如航空訂票，機票有不同的狀態，根據不同的狀態 已登機，未登機，起飛前24小時 決定機票的行為 可退票，可改簽等 又例如銀行卡的餘額流水決定者使用者可存款，可借款，可借款金額。又例如工作流審批過...