任 娜 郭 鍇
(江蘇省交通技師學院信息系,江蘇 鎮江 212006)
基于有限狀態機的人機交互界面軟件設計方法
任 娜 郭 鍇
(江蘇省交通技師學院信息系,江蘇 鎮江 212006)
本文基于嵌入式系統并運用模塊化思想,設計了一種相對獨立的通用化的工業分析儀表人機交互界面系統。程序設計基于事件目標驅動模型,以有限狀態機的方式,在實時操作系統μC/OS-II中,用狀態機把目標和事件聯系起來,實現OA(Object-Action)行為模式完成人機交互的過程,開發出符合工業分析儀表應用要求的人機交互界面軟件系統,并實現軟件與硬件的低耦合性,提高代碼的重用率,降低開發周期并提高軟件設計的可靠性。
有限狀態機;人機交互界面;uC/OS-Ⅱ
隨著國民經濟的高速發展,工業過程分析儀表的應用越來越重要及廣泛,對工業分析儀表的性能的要求也越來越高。作為工業分析儀表的重要組成部分的人機交互界面,對工業分析儀表的性能有著重要的影響,由于目前CPU的處理能力已不是制約工業分析儀表系統應用和發展的主要障礙,所以人機交互界面的設計水平已經成為決定整個儀表系統性能的主要制約因素。
工業儀表軟件開發的一個重要問題是與硬件的耦合過強。本文針對前工業分析儀表人機界面設計現狀和問題,提出了一種“基于小型化實時操作系統(μC/OS-II)+狀態機的人機界面設計方法”;能夠較好地降低工業儀表設計過程中人機交互界面軟硬件過度耦合的問題,提高代碼的重用效率,降低開發周期并提高軟件設計的可靠性。
2.1 有限狀態機。有限狀態機(Finite State Machine,簡稱FSM)是一種具有離散輸入輸出系統的數學模型,它以一種“事件驅動”的方式工作,可以通過事件驅動下系統狀態間的轉移,來表達一個控制系統的控制流程[1]。
2.2 層次式有限狀態機。對于像工業分析儀表HMI系統這樣較為復雜的系統而言,傳統的有限狀態機是無法對系統進行清晰的建模,因此在這里采用一種層次式的FSM表達方法。層次式FSM類似于軟件工程中結構化分析方法中的數據流圖,如圖1所示,其組織原則是:建模對象是一個復雜的系統,將控制系統劃分為多個相互協作的超狀態機(S1,S2,包含有子狀態機),每個超狀態機根據要求又被劃分為多個相互協作的子狀態機(S11,S12,S21,S22),不能被細分的子狀態機被稱為基狀態機(S11,S12,S21,S22)。

圖1 層次式FSM示意圖
在層次式FSM中,每個基狀態機都對應著一個父級的狀態機,多個基狀態機的相互協作的狀態機子群構成一個低層次的FSM。這樣子群內狀態機間的層次和邏輯關系構成了相應FSM間的層次和邏輯關系。復雜系統的控制流程就可以由這樣一組FSM來表達:{一個頂層FSM,若干個一層FSM,若干個二層FSM,…}。
超狀態機至少包含了一個子狀態機,父狀態機對子狀態機的包含關系實質上體現了子狀態機對父狀態機控制行為的繼承。這種繼承類似于面向對象程序設計模式的類繼承特性,有了這種繼承特性,在編程的時候可以按差異性進行,只需要定義子狀態機和父狀態機行為的不同之處,而其它的則可以重用在父狀態中的定義,這便極大地優化程序的結構和提高了程序的可維護性。
2.3 界面化的FSM。有限狀態機FSM(Finite State Machine)由狀態、事件、轉換和活動組成。每個狀態有1個狀態進入動作(entryaction)和1個狀態退出動作(exit action),每個轉換有1個源狀態和目標狀態并且與1個事件相關聯。另外當初始化時,我們定義了一個初始化信號量;以及界面的刷新,我們定義了一個復位信號量。當在源狀態時,該事件發生且觸發轉換的監護條件為真,則順序執行下列一些動作:①源狀態的退出動作;②轉換動作;③目標狀態的進入動作。
對狀態定義的信號量如下:

用軟件實現有限狀態機有兩種方法:表格法和過程驅動法。表格驅動法利用一個二維數組[2],該數組中的短一行與一個狀態相對應,每一列與一個輸入事件相對應,每一項則與某一狀態下對事件的處理相對應。表格驅動法適用于具有結構規則、操作簡單的有限狀態機。
過程驅動法為每一個狀態都定義一個處理過程,處理過程實現在此狀態時對事件的響應,包括輸出處理及對當前狀態值的轉換。這個過程可以用case語句區分事件,并采用相應的處理。無論采用何種方法實現FSM,當FSM收到一條消息時必須知道當前的狀態。為此,對應每一個狀態機必須能夠保存當前所處的狀態。過程法適用于實現一個具有幾種轉換和復雜操作的有限狀態機。
基于消息驅動的程序設計思想,為了保證系統的實時性,在中斷中只負責發送消息到相應的任務的消息隊列,由應用級的任務來處理,保證各個處理的時間是可確定的。主程序在消息循環中不斷地判斷各個任務的狀態,執行進入就緒態的任務。這就允許采用異步方式處理各種中斷及任務。
3.1 狀態機的軟件實現。本系統程序中采用了兩組有限狀態機,運用消息驅動的方式來驅動狀態的變更。一組是通信任務中以串口接收數據驅動為事件對象的有限狀態機,另一組是以用戶按鍵和命令碼驅動為事件對象的有限狀態機。
3.1.1 通訊的有限狀態機。為了保證通信的可靠,系統中采用停止等待協議。在發送數據前要對數據打包,接收到數據要先解包,處理器在接收主系統發過來數據包的后需要去掉通信協議字段,然后對有效數據進行正確的處理。為此,定義了一個Frame-FSM類型的數據結構,用來對接收到的數據進行處理。

利用主機發送過來的消息驅動有限狀態機,串口接收數據驅動的有限狀態機包括以下幾種狀態;(1)任意狀態。(2)任意狀態(除了INIT_STATE之外)。(3)INIT_STATE,初始狀態。(4)AA_SYN_STATE,收到同步字符狀態。(5)SRC_ADDR_STATE,收到源地址狀態。(6)DEST_ADDR_STATE,收到目的地址狀態。(7)DATA_LEN_STATE,接收數據長度狀態。(8)DATA_STATE,接收正常數據狀態。(9)CHECKSUM_STATE,接收校驗和狀態。
對應的狀態轉換圖(state transition diagram)如下圖所示。

圖2 狀態轉換圖
3.1.2 鍵值和命令碼驅動的有限狀態機
這組有限狀態機主要依靠用戶對菜單的操作進行狀態轉換,即把鍵值和命令碼作為FSM的激勵源,其中鍵盤消息是最主要的激勵源。應用層的FSM具有多種主狀態,用戶未按鍵或者是沒有接收到新的數據幀時,狀態處于IDLE_STATE;接收到消息后,轉入對應的主狀態。然后,根據按鍵的不同或者是接收命令碼的不同,轉入對應的子狀態進行處理。任務處理完畢,再將狀態置為IDLE_STATE,按取消鍵,可回到上一級狀態。
以用戶控制儀表調零,系統開始處于IDLE_STATE(選中調零菜單選項)。若用戶按確認,則進入調零參數設置頁面,并顯示當前設置的調零參數.選擇確認鍵,進入確認當前調零狀態;選擇確認件后儀表進入調零狀態,在該狀態執行向上命令操作后,狀態重新轉入IDLE_STATE,并伴隨著輸出菜單的相應變化,按取消鍵可回到上一級選擇狀態。對于其他按鍵,系統全部過濾掉不作響應,狀態也不進行轉換。儀表調零設置的狀態轉換圖如下圖所示。

圖3 儀表調零設置的狀態轉換
3.2 基于μC/OS-II的模塊化設計
在實時操作系統μC/OS-II下,整個HMI分為四個模塊,三個任務來實現,分別是鍵值處理模塊、與主機通信模塊和時鐘模塊以及界面顯示模塊。(為了結構的清晰,我們把鍵值的處理單獨成立一個任務,實際為了方便和實時性的處理,把鍵盤的處理放在TICK中處理也是很好的一種處理方法)。
3.2.1 鍵值處理模塊
OSTaskCreate(KEYTaskStart,(void*)0,&TaskKey-Stk[],5);
先初始化所有的模塊,然后在循環中接收并處理鍵盤的輸入,Key-Process(char Key Value)根據相應的輸入鍵值和系統所處的狀態,對菜單進行相應的操作。
State_Trans(char RxData)根據鍵值輸入事件負責調度系統的狀態,并在相應的狀態下,根據從主系統收到的信息顯示菜單。
3.2.2 主機通信模塊
OSTaskCreate(UARTTaskskStart,(void *)0,& TaskU-artStk[],4);
OSTaskCreate(CANTaskskStart,(void*)0,&TaskU-artStk[],3);
通過消息隊列OSQPend(OS_EVENT*pevent,INTl6U timeout,INT8U*err),接受串口或者CAN中斷發來的消息隊列,對其中的數據進行處理。在人機交互的過程中,需要大量的與主系統的交互,單獨用一個任務負責與主系統的通信,實現串口和CAN接收數據驅動的有限狀態機。
3.2.3 時鐘模塊
OSTaskCreate(TimcTCk,(void*)0,&TimeTickStk[],2);
時鐘任務,使用處理器的時鐘中斷,可以設置各個任務需要的定時器,通過消息隊列發給需要定時的任務。
3.2.4 界面顯示模塊
OSTaskCreate(Task_HMIRun,(void*)'9',&Task_HMI_Stk[TASK_HMI_STK_SIZE-1],6);
界面顯示任務,初始化狀態機,以及父狀態界面,通過獲取實時狀態,實現界面的切換和事件的處理。
HMI系統的測試采用μC/OS-II V2.52較以前的版本,該版本增加了兩個系統任務:CPU負荷監測任務與堆棧容量檢查任務。這兩個任務給程序的調試帶來很大的方便[3]。
將系統配置常數OS_TASK_STAT_EN設為l,統計任務OSTaskStat()就會建立。它每秒鐘運行1次,計算出當前CPU的利用率,放在一個有符號的8位整數0SCPUUsage中,精確度是l%。μC/OS-II內存是固定分配的,通過0STaskStkChk()可確定每個任務實際需要的最大堆棧空間,根據測得結果合理地分配內存空間。表l是用以上函數測出的系統參數。使用MC9S12XDT512單片機系統相應的調試工具CodeWarrior,可跟蹤程序的運行。通過運行在PC機上CodeWarrior能夠追蹤程序中各種參數的變化,查看處理器內存的使用情況。

表1 系統參數的測量結果
在實際測試中,采用μC/OS-II系統及有限狀態機的HMI系統,比普通前后臺系統的實時性提高35.2%,測試時間縮短14.3天,MTBF≥1440hour,代碼重用率≥75%,整體性能得到了很大的提高
結論。經測試證明,使用實時操作系統前。運用前后臺的程序設計方式。在需要顯示較多數據在屏幕上,同時又需要接收數據時,處理器處理不及時,可以通過調試工具CodeWarrior看到接收緩存接收的數據幀不完整,而不能正確地在屏幕上顯示數據。移植μC/OS-II操作系統之后,工作可靠,同時系統的反應速度,即實時性有了很大提高。本章介紹的HMI系統與嵌入式主系統是獨立的模塊,可以靈活地在處理器上加載控制模塊,適合應用于各種嵌入式系統中。
[1]梁偉晟,李磊.基于與或邏輯的界面關系模型表示方法.計算機科學,2008,35(4):203-204.
[2]劉成玉,李明,陳潔.淺談狀態機的設計方法及應用[J].集成電路通訊,2007,25(1):20-24.
[3]趙楠,王軍政,沈偉.基于uC/OS-Ⅱ的齒輪流量計二次儀表的設計[J].微計算機信息,2006(7):52~54.
TP29
B