正文 開放式機器人智體(2 / 3)

圖3中:HostSoftMan為根節點,表示機器人係統中的宿主“軟件人”,由知識庫KnowLedge Base和行為集Behaviors組成;InitROT、Node Data、Message Buffer、和Host Abstract作為KnowLedge Base的第一級子節點,分別表示宿主“軟件人”初始化機器人平台時需要的知識以及節點數據層、消息緩衝層和宿主抽象層所涉及的信息; AppendSM表示活動的附體“軟件人”信息;Context表示“機器人”端的環境資源信息;Hardware Abstract和Beh Abstract表示機器人硬件抽象和行為抽象信息。

LifeCycleCtrl、ResCtrl、CommBehs、CognBehs和SrvBehs作為Behaviors的第一級子節點,分別表示宿主“軟件人”的生命周期、係統資源控製行為、交互行為、認知行為和服務類行為。LifeCycleCtrl、ResCtrl、CommBehs、CognBehs屬於“軟件人”本體行為,在此不再贅述。宿主“軟件人”特有的服務類行為SrvBehs可劃分為社區初始化行為InitBeh、遷入登記行為MigInBeh、硬件抽象層調用行為HALCallBeh、節點容錯行為FaultToleranceBeh、信道建立行為CreateChannelBeh、對動態附體“軟件人”控製行為AppendSM ctrl和環境資源感知行為CxtCtrl。其中, AppendSM ctrl可分為對附體“軟件人”的生命周期及狀態控製AppendLifeCycle和任務協調行為TaskCoordinate。

1.2.1 宿主“軟件人”知識模型實現研究

“軟件人”知識模型(SoftMan KnowLedgebase Model,SMKM)定義為一個三元組[14]:

SMKM=〈Data, Type, Relation〉。

1)Data為“軟件人”知識的數據部分,表述為一個三元組:Data=〈DataType, DataContent, DataLen〉其中: DataType表示數據類型,DataContent表示數據內容,DataLen表示數據長度。

2)Type為本“軟件人”知識節點的邏輯類型,即資源類型知識節點或屬性類型知識節點。

3)Relation用於描述本知識節點與其子節點之間的模糊關聯,表示為:

Relation=∪〈SubSKMi, tValuei, fValuei〉;0≤i≤n其中:tvaluei表示第i個子知識節點相對於本節點的隸屬度, fvaluei表示第i個子知識節點相對於本節點的假隸屬度[14]。

“軟件人”知識模型SMKM主要是由以下4個數據結構來構造和實現的。

1)枚舉類型SMKMType表示“軟件人”知識Data部分的DataType,其成員包括:無數據類型smkm_no_type, 整數類型smkm_int_type, 浮點類型smkm_float_type,字符串類型smkm_str_type, 結構體類型smkm_struct_type, 鏈表類型smkm_list_type。

2)枚舉類型SMKMLogicType表示“軟件人”知識Type部分的邏輯類型,其成員包括:資源類型smkm_logic_res_type, 屬性類型smkm_logic_attr_type。

3)結構體smkmTerm表示“軟件人”知識的基本構造元素,其成員包括:smkmType表示“軟件人”知識Data部分的DataType,*p表示“軟件人”知識Data部分的DataContent,len表示“軟件人”知識Data部分的DataLen,logicType標明“軟件人”知識的邏輯類型Type,wMs和wUnMs表示本知識節點與其父節點的模糊關聯 。

4)結構體smkmStructType為軟件人”知識基本構造元素提供了一種靈活的組裝方式。

根據以上對“軟件人”知識模型與其數據結構的定義與說明,對圖3左邊宿主“軟件人”的知識庫Knowledge Base部分進行實現,其實現示意圖如圖4所示。行為集Behaviors的實現邏輯與此類似,不再詳細贅述。

圖4頂層方框表示要描述的是知識Data部分的DataType為結構體類型smkm_struct_type的知識節點“HostSoftMan”。第二層左分支方框描述的是“軟件人”名稱,名稱的數據類型為字符串類型smkm_str_type;LogicType=smkm_logic_res_type表明該“軟件人”知識的邏輯類型為資源類型;*p表示名稱的數據內容為“HostSoftMan”;len=11表明名稱的數據長度為11個字符;wMs=1、wUnMs是否應為wUnMs,圖中表述為wUnMs將wUnM改為wUnMs=0表明與其父節點隸屬度為1、假隸屬度為0。第二層右分支方框枚舉了圖3宿主“軟件人”知識庫Knowledge Base的下層組成要素名稱及個數。由*p可看出組成知識庫要素的數據名稱分別為Node Data、Message Buffer、Host Abstract 和InitROT, 枚舉類型SMKMType的數據類型為字符串類型smkm_str_type;len=4表明組成要素數據個數為4;wMs=1、wUnMs=0表明與其父節點隸屬度為1、假隸屬度為0。對圖4中第三層與第四層的理解可分別參照對頂層和第二層的解釋,不再贅述。

1.2.2 宿主“軟件人”行為規範及算法實現

服務類行為集SrvBehs是與宿主“軟件人”的職能所對應的,因篇幅有限,本節選取其服務類行為集SrvBehs中典型的信道建立行為CreateChannelBeh和節點容錯行為FaultToleranceBeh進行相關設計規範及算法的參考實現。

1) 信道建立行為CreateChannelBeh。

“軟件人”之間通過消息傳遞進行交互[21],因此,在機器人平台中擔當守護、信息處理角色的宿主“軟件人”需先創建通信信道。在嵌入式Linux係統中,支持多種進程間通信(InterProcess Communication,IPC),常用的IPC方式有:共享內存、信號量、管道、消息隊列、socket等。本文選取socket作為進程間通信的方式,建立機器人平台上的通信信道。信道建立後,宿主“軟件人”可為機器人端提供消息守護功能。節點內部的附體“軟件人”能通過信道與宿主“軟件人”進行通信,同時,“軟件人”平台上的消息節點也能通過連接該信道與機器人平台上的“軟件人”進行通信。宿主“軟件人”消息守護流程如圖5所示。

2) 節點容錯行為FaultToleranceBeh。

容錯機製是係統可靠性的一種保證。宿主“軟件人”作為機器人係統的守衛者和管理者,關鍵是要保障機器人節點的正常運行。因此,需討論宿主“軟件人”為使係統可靠運行而提供的容錯行為。對於宿主“軟件人”的容錯行為,首先需要能為異常結束的附體“軟件人”提供重新啟動的功能。宿主“軟件人”處理附體“軟件人”進程退出信號過程如圖6所示。

在宿主“軟件人”監聽到附體“軟件人”退出時,通過查看“軟件人”狀態來判斷是否有異常。若已申請退出,則宿主“軟件人”釋放維護的相關信息;否則認為該“軟件人”進程為異常退出,重新啟動附體“軟件人”。當宿主“軟件人”接收到操作係統內核傳來的信號時,附體“軟件人”進程已經結束,且尚未處理的輸入消息也將丟失。若采用直接重新啟動從初始化狀態開始工作,雖然避免了附體“軟件人”異常退出,但並未能保證其對外服務的連續性。因此,為了避免附體“軟件人”服務的中斷,宿主“軟件人”采取了檢查點容錯機製。即宿主“軟件人”定期的保存運行期附體“軟件人”的相關信息(檢查點),當附體“軟件人”因意外終止而重啟時,利用保存的信息初始化附體“軟件人”,使得“軟件人”能從檢查點繼續執行,以此保持“軟件人”對外服務的持續性。

現階段各式各樣不同功能的機器人可謂層出不窮。若把專注點投向機器人嵌入式係統時,不難發現:由於編程環境、實現架構和支撐平台等多種技術因素的製約,涉及機器人功能的更新、修改、升級、維護等工作,隻能采用離線、靜態方式進行。因此,從機器人與PC端“軟件人”係統合一機製(如圖7所示)出發,通過將移動端機器人係統改造成一個以宿主“軟件人”為管理守護中心的平台,使得宿主“軟件人”在自身實現的基礎上搭建附體“軟件人”的運行環境,可使一個機器人實現多個功能。

在圖7所示機器人與“軟件人”合一機製工作場景中,宿主“軟件人”角色功能描述如下:

1)位於機器人平台的宿主“軟件人”加載啟動,完成機器人係統的初始化工作;

2)宿主“軟件人”利用機器人行為功能描述,向“軟件人”平台進行注冊,提供機器人的功能信息;

3)“軟件人”平台依據用戶請求,查詢相關信息,匹配出能完成任務的機器人,並指派相應的附體“軟件人”去執行;

4)宿主“軟件人”接收遷移過來的附體“軟件人”,並為其構造運行環境,執行任務;

5)如果需要機器人繼續執行任務,跳轉到4),否則跳轉到6);

6)宿主“軟件人”結束運行,機器人進入關閉狀態。

本章以由飛淩嵌入式公司生產的型號為OK210A的開發板作為硬件平台的機器人(如圖8所示)為測試實物,與PC上的“軟件人”係統搭建了一個簡單的合一係統,來進行引入宿主“軟件人”後的機器人蜂鳴功能、閃燈功能和截圖功能的實現,以此驗證本文提出的宿主“軟件人”設計和實現方法的正確性和可行性,實現將宿主“軟件人”引入機器人平台的初衷——機器人平台的在線功能動態更替。控製機器人實現蜂鳴功能、閃燈功能和截圖功能的三個附體“軟件人”在初始狀態時,是存在於PC端的,沒有在移動設備上。當移動端需要使用蜂鳴功能時,將聯係PC端,將負責蜂鳴功能的附體“軟件人”通過無線網絡在線下載,並加載到移動設備上,執行任務,測試用例一即驗證其是否成功。以此類推,測試用例二和三測試在同一移動設備上閃燈功能和截圖功能的實現。

由此可見,機器人平台中宿主“軟件人”的引入,使得機器人係統與“軟件人”係統的合一得以實現,實現了同一機器人功能的動態配置與在線重構,在解決機器人應用領域中存在的可擴展性差、軟件移植難、可複用性低等問題方麵做出了努力,與傳統的機器人控製係統開放性差、功能單一或功能隻能離線、靜態更替相比,表現出了其優越性,同時驗證了關於宿主“軟件人”的設計和實現方法的正確性和可行性。

3 結語

本文提出了在機器人平台中引入“軟件人”的思想,目的是與網絡平台中的“軟件人”係統融合,實現機器人功能的在線動態更替。詳細研究了引入機器人平台中作為管理中心的宿主“軟件人”,對其體係結構進行了設計,並基於機器知行學與前期研究的“軟件人”知行模型理論,提出了宿主“軟件人”的知識行為一體化描述模型,給出了知識模型的實現方法,對其行為集進行了相應的行為規範和算法實現。最後搭建了簡單了合一係統測試平台,測試得出經過設計實現的宿主“軟件人”成功地將機器人平台與“軟件人”平台合一,使機器人功能得以在線更替。從宏觀角度來看,以宿主“軟件人”為管理中心的機器人係統,從邏輯上轉變為一個有形的、活動於物理空間的“軟件人”實體(即虛體實物化),使得“軟件人”係統成為一個虛實結合的、規模更大的人工生命係統。