本發(fā)明涉及一種支持分布式機器人控制的開放式系統(tǒng)結(jié)構(gòu)，具體涉及基于軟件總線的面向服務(wù)的機器人開放式控制系統(tǒng)。

背景技術(shù)：

機器人控制系統(tǒng)是機器人的核心，傳統(tǒng)的機器人控制系統(tǒng)大多采用封閉式結(jié)構(gòu)，這種結(jié)構(gòu)的優(yōu)點是結(jié)構(gòu)簡單，能實現(xiàn)高效的控制。但是，隨著機器人技術(shù)的發(fā)展以及控制系統(tǒng)的整體復(fù)雜性提高，封閉式的控制系統(tǒng)的局限性日益顯現(xiàn)。主要表現(xiàn)為：擴展性差，可移植性差，容錯性差，難以維護和升級。由于存在以上的局限，開放式機器人控制系統(tǒng)是一種解決以上問題的可行方案。開放式控制機器人控制系統(tǒng)具有可擴展，可移植，服務(wù)化，可重用等特性，可以大大減低控制系統(tǒng)二次開發(fā)的成本和維護成本，具有很大的實用價值。

國內(nèi)關(guān)于開放式控制系統(tǒng)的工作主要有，中國科學(xué)院自動化研究所的“開放式工業(yè)機器人視覺控制平臺”（公開號：CN1417006）、深圳市中科睿成智能科技有限公司的“開放式機器人系統(tǒng)”（公開號：CN102431023A）。國外日本及歐美一些國家在相關(guān)領(lǐng)域開展大量工作，如NASA和NBS提出的NASREM機器人控制系統(tǒng)，日本AIST研究所開發(fā)的OpenRTM-aist機器人控制軟件開發(fā)平臺。國內(nèi)外現(xiàn)有的開放式機器人控制系統(tǒng)，雖然已經(jīng)取得了一系列的研究成果，但層次化的開放式控制系統(tǒng)仍存在組件耦合度高，不能實現(xiàn)組件的運行時配置等問題。

對于自動化控制領(lǐng)域的應(yīng)用，系統(tǒng)功能的擴展導(dǎo)致帶寬的需求越來越高，并且該領(lǐng)域的對系統(tǒng)的實時性與確定性有嚴格要求。因此，控制系統(tǒng)網(wǎng)絡(luò)必須滿足如下要求：1、提供高帶寬2、控制的數(shù)據(jù)流必須具備實時性與確定性。針對以上要求，實時以太網(wǎng)成為一種新型的、有前景的候選技術(shù)。其中，以時間觸發(fā)以太網(wǎng)（Time-Triggered Ethernet）技術(shù)為比較成熟一種。

技術(shù)實現(xiàn)要素：

本發(fā)明的目的在于克服現(xiàn)有技術(shù)存在的上述補助，提供基于軟件總線的面向服務(wù)的機器人開放式控制系統(tǒng)及方法。

本發(fā)明的目的至少通過如下技術(shù)方案之一實現(xiàn)。

基于軟件總線的面向服務(wù)的機器人開放式控制系統(tǒng)，其按層次結(jié)構(gòu)劃分為五個層，分別是：應(yīng)用服務(wù)層，總線消息層，服務(wù)總線代理層，傳輸層和總線管理層；其中，

應(yīng)用服務(wù)由開發(fā)者根據(jù)統(tǒng)一的服務(wù)定義描述服務(wù)并實現(xiàn)服務(wù)功能，或者通過已有的服務(wù)組合而成；由于消息層對服務(wù)的消息進行封裝，所以應(yīng)用服務(wù)并不需要考慮通信細節(jié)，只需專注于服務(wù)的功能邏輯即可；

總線消息層為應(yīng)用服務(wù)提供對外請求的消息作為接口，不同的消息對應(yīng)不同處理邏輯；由于系統(tǒng)對傳輸?shù)南⑦M行序列化進程，使得消息能夠?qū)崿F(xiàn)跨平臺傳輸；

服務(wù)總線代理層作為應(yīng)用服務(wù)層和傳輸層的中介，為總線提供了一層封裝，主要功能是處理服務(wù)與軟件總線之間的通信細節(jié)；

傳輸層的功能是實現(xiàn)應(yīng)用服務(wù)與軟件總線之間的消息傳遞，任務(wù)是保證消息可靠的，有序的，準確無誤的和實時的在服務(wù)與軟件總線之間進行傳輸；

總線管理層是控制系統(tǒng)的核心，系統(tǒng)中的各個服務(wù)通過軟件總線進行連接并進行統(tǒng)一管理，服務(wù)之間的消息傳遞都需要經(jīng)過軟件總線進行轉(zhuǎn)發(fā)和路由，并且處理服務(wù)組合、服務(wù)注冊等重要邏輯。

進一步地，所述軟件總線由以下部分組成：服務(wù)總線代理，總線節(jié)點，總線管理器和存儲節(jié)點；為了實現(xiàn)控制系統(tǒng)中服務(wù)之間的松耦合關(guān)系，采用自定義消息，通過消息序列化技術(shù)使消息能夠在服務(wù)和軟件總線之間傳遞，能夠提供跨平臺、跨語言的消息傳輸機制，服務(wù)的開發(fā)無需關(guān)注如何與軟件總線通信的細節(jié)。

進一步地，所述系統(tǒng)傳輸層中支持分布式控制系統(tǒng)的開發(fā)的方法，由于服務(wù)之間的松耦合關(guān)系，控制系統(tǒng)中服務(wù)可以部署在不同的物理節(jié)點上，提高了系統(tǒng)的靈活性；為確保系統(tǒng)能夠滿足機器人控制的實時性與確定性，在傳輸層上引入時間觸發(fā)以太網(wǎng)來保證控制系統(tǒng)的實時性與確定性，對于實時性與確定性要求較高的服務(wù)使用時間觸發(fā)流量傳輸數(shù)據(jù)，確保該服務(wù)的實時性與確定性；此外，為避免單一總線節(jié)點出現(xiàn)熱點訪問問題成為系統(tǒng)的瓶頸，通過分布式總線節(jié)點及總線節(jié)點的負載均衡來提高整個分布式控制系統(tǒng)的效率。

利用所述的控制系統(tǒng)的控制方法，其包括如下步驟：

S1、服務(wù)注冊；

在本控制系統(tǒng)中，包含三個角色，分別是服務(wù)請求者，服務(wù)提供者和服務(wù)注冊中心；服務(wù)請求者發(fā)送請求服務(wù)消息，通過查詢服務(wù)注冊中心，獲取服務(wù)信息并綁定服務(wù)，再根據(jù)服務(wù)所提供的接口執(zhí)行任務(wù)；服務(wù)提供者提供了服務(wù)的具體功能實現(xiàn)；通過注冊操作在服務(wù)注冊中心中發(fā)布服務(wù)的接口和描述信息，使得服務(wù)請求者可以查詢和訪問該服務(wù)；服務(wù)注冊中心提供并維護了一個可用服務(wù)目錄，允許服務(wù)請求者查找感興趣的服務(wù)的接口；

S2、服務(wù)組合；

每次客戶的請求都是以業(yè)務(wù)流程的形式進行請求，而業(yè)務(wù)流程可以分解為若干服務(wù)的有序組合；一個業(yè)務(wù)流程信息以有向無環(huán)圖的形式表示，其中每個節(jié)點表示一個服務(wù)組件；此步驟是應(yīng)用服務(wù)層為用戶提供一個方便的接口來實現(xiàn)具體的任務(wù)要求；

S3、用戶向軟件總線請求相關(guān)服務(wù)或流程；

請求/應(yīng)答模式是服務(wù)消息主要交換模式，用戶以業(yè)務(wù)流程形式請求組合服務(wù)，在同一流程中，服務(wù)A需要服務(wù)B提供服務(wù)并返回應(yīng)答消息，就此服務(wù)A需要通過總線消息層選擇合適的消息，并通過服務(wù)總線代理向總線發(fā)送消息；

由于采用適應(yīng)分布式總線節(jié)點的架構(gòu)，因此在服務(wù)轉(zhuǎn)發(fā)消息之前需要通過負載均衡模塊來確定需要轉(zhuǎn)發(fā)的總線節(jié)點；負載均衡首先根據(jù)消息的信息，通過負載均衡算法選定目標總線節(jié)點的節(jié)點號；服務(wù)總線代理層根據(jù)這個節(jié)點號查找服務(wù)的總線表，并將表中的信息填入消息中轉(zhuǎn)發(fā)消息到對應(yīng)的總線節(jié)點；

S4、軟件總線的調(diào)度；

以系統(tǒng)丟包率和響應(yīng)時間比的多目標函數(shù)作為測量標準，通過調(diào)節(jié)任務(wù)的優(yōu)先級及傳輸周期對總線資源進行優(yōu)化分配；調(diào)度主要涉及對傳輸?shù)南⑦M行合理的調(diào)度，滿足系統(tǒng)的實時性要求；調(diào)度方法主要在總線管理層里實施；

S5、軟件總線的消息處理；

一個服務(wù)通過請求消息向其它服務(wù)發(fā)起請求；接收到相關(guān)請求消息的服務(wù)會做出應(yīng)答，并發(fā)送一個或多個應(yīng)答消息；發(fā)送請求消息的服務(wù)不需要知道目標服務(wù)的具體位置，只需按照預(yù)先定義好的消息協(xié)議向總線發(fā)送消息；

發(fā)送到軟件總線的消息類型有：結(jié)果消息、狀態(tài)消息、注冊消息、請求消息和應(yīng)答消息，此步驟主要在軟件總線管理層中完成；

S6、被請求的服務(wù)的消息處理；

被請求的服務(wù)根據(jù)接收的信息提取相關(guān)的調(diào)用函數(shù)及調(diào)用參數(shù)，然后將調(diào)用參數(shù)傳遞給服務(wù)的內(nèi)部函數(shù)進行調(diào)用，得到的處理結(jié)果通過服務(wù)總線代理API返回到軟件總線上；

S7、軟件總線處理返回消息；

軟件總線接收到來自服務(wù)的結(jié)果消息，從消息的內(nèi)容判斷是單個服務(wù)請求結(jié)果還是業(yè)務(wù)流程中的一個中間結(jié)果；若是單個服務(wù)請求結(jié)果，直接將結(jié)果消息轉(zhuǎn)發(fā)到請求服務(wù)上；若是業(yè)務(wù)流程的中間結(jié)果，則將中間結(jié)果轉(zhuǎn)發(fā)到業(yè)務(wù)流程當中給的下一個服務(wù)當中。

與現(xiàn)有技術(shù)相比，本發(fā)明的優(yōu)點和效果有：

本發(fā)明相對于已有的控制系統(tǒng)，具有兼容性，開發(fā)效率高，支持分布式控制系統(tǒng)的開發(fā)等優(yōu)點。用戶可以通過服務(wù)的添加、組合及替換來完成系統(tǒng)的升級和重新配置，并且用戶只需要將精力集中在服務(wù)的功能構(gòu)造上，降低了系統(tǒng)開發(fā)成本和提高系統(tǒng)開發(fā)效率。另外，服務(wù)可以部署在不同的物理節(jié)點上，通過時間觸發(fā)以太網(wǎng)來確保實時服務(wù)數(shù)據(jù)傳輸?shù)膶崟r性與確定性，并且對于具有分布式總線節(jié)點的控制系統(tǒng)，提供了負載均衡功能來解決熱點訪問問題。

附圖說明

圖 1為分布式機器人控制系統(tǒng)結(jié)構(gòu)。

圖 2為控制系統(tǒng)層次結(jié)構(gòu)。

圖 3為軟件總線的組成。

圖 4為總線節(jié)點包含模塊。

圖 5為總線管理器示意圖。

圖 6為實施例基本控制流程圖。

圖 7為一種基于時間觸發(fā)以太網(wǎng)的分布式控制系統(tǒng)拓撲結(jié)構(gòu)。

圖 8為服務(wù)的注冊示意圖。

圖 9為服務(wù)流程的拓撲結(jié)構(gòu)實例圖。

圖 10為配置服務(wù)組合流程圖。

圖 11為反饋調(diào)度模塊框架圖。

圖 12為請求與應(yīng)答的執(zhí)行流程圖。

具體實施方式

下面結(jié)合實例對本發(fā)明作進一步詳細的描述，但本發(fā)明的實施方式不限于此。

本實例的基于軟件總線的面向服務(wù)的機器人開放式控制系統(tǒng)，如圖1所示，不同類型的機器人以及其它設(shè)備節(jié)點能夠通過軟件總線進行相互的消息通信。軟件總線是整個分布式控制系統(tǒng)的核心組件，主要功能是為不同節(jié)點提供透明的傳輸機制，解除了用戶與消息協(xié)議的耦合。本發(fā)明通過引入面向服務(wù)的軟件架構(gòu)，將傳統(tǒng)機器人控制系統(tǒng)的功能服務(wù)化，通過提供服務(wù)注冊、服務(wù)的組合及替換等功能，使得整個系統(tǒng)可以直接通過服務(wù)的新增及組合來大幅提高系統(tǒng)二次開發(fā)的效率，并且服務(wù)的替換能夠為系統(tǒng)帶來額外的冗余性。此外，針對分布式機器人控制系統(tǒng)的通信的實時性問題，本發(fā)明提出一種基于時間觸發(fā)以太網(wǎng)的分布式機器人控制系統(tǒng)，保證控制系統(tǒng)的實時性及確定性。本發(fā)明主要內(nèi)容包括：

1）面向服務(wù)的開放式控制系統(tǒng)體系層次模型

控制系統(tǒng)按層次結(jié)構(gòu)劃分為五個層次，分別是：應(yīng)用服務(wù)層，總線消息層，服務(wù)總線代理層，傳輸層和總線管理層。下面將對每一層的功能進行介紹，如圖 2所示。

應(yīng)用服務(wù)層：應(yīng)用服務(wù)層中的實體為服務(wù)，所有系統(tǒng)用戶所需要的功能和資源都被封裝成服務(wù)。應(yīng)用服務(wù)層主要是面向開發(fā)者的一層，開發(fā)者只需按照服務(wù)的標準定義來生成服務(wù)配置文件即可。服務(wù)在啟用前，必須首先向總線進行注冊，以使總線獲取服務(wù)的信息，并對系統(tǒng)中的所有服務(wù)進行統(tǒng)一管理。服務(wù)信息由用戶在服務(wù)配置文件中進行設(shè)定，主要包含服務(wù)ID，服務(wù)名，服務(wù)描述，服務(wù)中提供的函數(shù)等信息。服務(wù)在啟動時，首先從服務(wù)配置文件中讀取服務(wù)配置信息，并將特定信息包含在注冊請求中，提交給軟件總線。當軟件總線接收到服務(wù)的注冊請求并對請求做出回應(yīng)后，服務(wù)才能開始正常工作。

總線消息層：總線消息層是向應(yīng)用服務(wù)層提供各種消息封裝。應(yīng)用服務(wù)根據(jù)自身需求，向總線發(fā)送特定的消息。分別有：注冊消息、訂閱消息、發(fā)布消息、狀態(tài)消息和心跳消息等。

服務(wù)總線代理層：服務(wù)總線代理層作為應(yīng)用服務(wù)層和傳輸層的中介，為總線提供了一層封裝，主要功能是處理服務(wù)與軟件總線之間的通信細節(jié)。在發(fā)送消息時，用戶可以將封裝好的消息通過API 傳遞給服務(wù)總線代理層，服務(wù)總線代理層將通過傳輸層最終將消息發(fā)送到軟件總線上；服務(wù)總線代理層也從傳輸層獲取軟件總線轉(zhuǎn)發(fā)過來的消息，并通過API傳遞給應(yīng)用服務(wù)層。消息的序列化工作將由服務(wù)總線代理中的序列化模塊完成，不再由用戶負責(zé)，用戶無需再了解消息協(xié)議的使用細節(jié)。對于具有分布式總線節(jié)點的控制系統(tǒng)，服務(wù)總線代理層向服務(wù)提供負載均衡功能，使服務(wù)的消息能夠轉(zhuǎn)發(fā)到合理的總線節(jié)點上。

傳輸層：傳輸層的功能是實現(xiàn)應(yīng)用服務(wù)與軟件總線之間的消息傳遞，任務(wù)是保證消息可靠的，有序的，準確無誤的在服務(wù)與軟件總線之間進行傳輸。另外，傳輸層也需保證消息能夠?qū)崟r地響應(yīng)用戶的實時應(yīng)用。為了滿足上述要求，本發(fā)明通過在傳輸層上支持時間觸發(fā)以太網(wǎng)來保證整體系統(tǒng)的實時性能、可靠性與確定性。

總線管理層：總線管理層是控制系統(tǒng)的核心，系統(tǒng)中的各個服務(wù)通過軟件總線進行連接并進行統(tǒng)一管理，服務(wù)之間的消息傳遞都需要經(jīng)過軟件總線進行轉(zhuǎn)發(fā)和路由。

2）軟件總線功能平臺

軟件總線由服務(wù)總線代理，總線節(jié)點，總線管理器和存儲節(jié)點四部分組成，如圖 3所示。下面分別介紹這幾個組成部分。

服務(wù)總線代理：每一個應(yīng)用服務(wù)都包含自己的服務(wù)總線代理，服務(wù)總線代理負責(zé)服務(wù)與總線的交互，包含服務(wù)接口模塊，網(wǎng)絡(luò)通信模塊，請求管理模塊等功能模塊。服務(wù)接口模塊包含總線 API 和消息序列化模塊。總線 API 為總線提供了一層封裝，是服務(wù)與總線交互的接口，服務(wù)通過總線 API 將自身產(chǎn)生的消息傳遞給總線，總線采用的消息協(xié)議和消息的傳輸方式等細節(jié)對服務(wù)用戶而言是透明的；消息序列化模塊根據(jù)總線的消息協(xié)議對總線 API 接收到的用戶消息進行序列化，再由網(wǎng)絡(luò)通信模塊將消息傳遞給軟件總線。請求管理模塊，是負責(zé)本地服務(wù)之間消息傳遞的邏輯模塊。對于實時性要求較高的流程，一般會將流程中包括的服務(wù)部署在本地節(jié)點。因此每當服務(wù)需要發(fā)送消息時，都先經(jīng)過請求管理模塊處理，若目標服務(wù)就在本地節(jié)點，就無需發(fā)送至總線上，直接到達本地服務(wù)。這樣處理的既滿足實時性較高的應(yīng)用場景，也進一步減輕總線上的負載。網(wǎng)絡(luò)通信模塊主要負責(zé)服務(wù)與軟件總線的通信細節(jié)，包括消息發(fā)送隊列的管理，軟件總線連接池的管理，網(wǎng)絡(luò) I/O 模式，網(wǎng)絡(luò)通信協(xié)議的選擇等。負載均衡模塊負責(zé)在總線代理發(fā)送消息之前選定某個總線節(jié)點。

總線節(jié)點：總線節(jié)點是整個總線架構(gòu)的核心，主要負責(zé)流程消息的轉(zhuǎn)發(fā)調(diào)度，以及流程和服務(wù)信息的管理。軟件總線由一個或者多個總線節(jié)點組成?？偩€節(jié)點都包含請求管理模塊，訂閱發(fā)布管理模塊，網(wǎng)絡(luò)通信模塊，實時調(diào)度模塊，如圖 4所示。請求管理模塊是總線節(jié)點的核心，主要負責(zé)流程消息的轉(zhuǎn)發(fā)和路由，從消息接收隊列中獲取服務(wù)消息，并根據(jù)消息的流程信息查找轉(zhuǎn)發(fā)路由表，更新消息的目標服務(wù)，再將消息加入消息發(fā)送隊列中。轉(zhuǎn)發(fā)路由表是請求管理模塊的重要組成部分，存儲著系統(tǒng)中常用的流程信息，轉(zhuǎn)發(fā)路由表的命中率對總線節(jié)點的性能有很大的影響。訂閱發(fā)布管理模塊負責(zé)服務(wù)或總線節(jié)點的消息訂閱和消息發(fā)布。服務(wù)或總線可以通過訂閱方式來接收某些類型的消息，同時地，能夠提供這些類型消息的其他服務(wù)或總線會把這些消息發(fā)布到總線上。一般而言，服務(wù)或總線會通過訂閱時所設(shè)置的參數(shù)來過濾消息。例如，總線之間通過發(fā)布自身的心跳消息，并訂閱其它節(jié)點的心跳消息來互相傳遞各自的狀態(tài)（如出錯、超負載等），并由各自的總線管理器進行合理的處理。實時調(diào)度模塊主要負責(zé)根據(jù)消息的優(yōu)先級對消息接收隊列和消息發(fā)送隊列中的消息進行調(diào)度， 主要目的是提高總線的實時性，因為控制系統(tǒng)的實時性有著比較高的要求。網(wǎng)絡(luò)通信模塊主要負責(zé)總線節(jié)點與服務(wù)之間的通信細節(jié)管理，包括服務(wù)連接池的管理，網(wǎng)絡(luò) I/O 模式，服務(wù)消息的解析等。網(wǎng)絡(luò)通信模塊從服務(wù)獲取消息，解析后放到消息接收隊列中，當消息處理完畢后，再從消息發(fā)送隊列中取出消息，封裝后根據(jù)路由信息發(fā)送到目標服務(wù)。

總線管理器：總線管理器負責(zé)總線節(jié)點的管理，維護總線節(jié)點的狀態(tài)。總線節(jié)點周期性地向總線管理器報告自身狀態(tài)，超過一定期限沒有發(fā)送狀態(tài)的總線節(jié)點將被當作出現(xiàn)故障。服務(wù)總線代理周期性地向總線管理器獲取總線節(jié)點狀態(tài)，以更新自身的總線狀態(tài)列表，如圖 5所示。

存儲節(jié)點：存儲節(jié)點包括數(shù)據(jù)存儲和流程管理兩個模塊。數(shù)據(jù)存儲模塊負責(zé)系統(tǒng)中服務(wù)信息和流程信息存儲?？偩€節(jié)點在接收服務(wù)的注冊請求時，需要將服務(wù)信息存儲到數(shù)據(jù)存儲模塊中；當總線節(jié)點處理流程請求時，若出現(xiàn)轉(zhuǎn)發(fā)路由表不命中的情況，需要從數(shù)據(jù)存儲模塊中獲取對應(yīng)的流程信息。流程管理模塊主要負責(zé)系統(tǒng)中服務(wù)組合配置（流程配置）以及服務(wù)狀態(tài)的管理。

3）分布式機器人控制系統(tǒng)開發(fā)框架

由于服務(wù)之間的松耦合關(guān)系，控制系統(tǒng)中服務(wù)可以部署在不同的物理節(jié)點上，提高了系統(tǒng)的靈活性。本發(fā)明提供了一種區(qū)別于傳統(tǒng)機器人控制系統(tǒng)集中式控制的開發(fā)框架，由于面向服務(wù)的框架屏蔽了服務(wù)與總線之間的通信細節(jié)，因此只需要服務(wù)根據(jù)已定義的服務(wù)描述向軟件總線注冊，服務(wù)就能部署在不同的物理節(jié)點中，提高整個控制系統(tǒng)的靈活性。-

為保證整體系統(tǒng)分布式節(jié)點的數(shù)據(jù)傳輸實時性與確定性，本發(fā)明引入時間觸發(fā)以太網(wǎng)來滿足要求。時間觸發(fā)以太網(wǎng)是基于時分復(fù)用(TDMA)的實時以太網(wǎng)之一,在所有節(jié)點通過時間同步算法維持一定的時鐘精度下，保證時間觸發(fā)流量能夠嚴格按照時間調(diào)度表來進行消息的發(fā)送與接收。時間觸發(fā)以太網(wǎng)定義了時間觸發(fā)流量(TT traffic)、速率限制流量(RC traffic)及盡力而為流量(BE traffic)來滿足不同應(yīng)用的流量需求。時間觸發(fā)流量具有周期性特點及在每個周期有預(yù)先定義好的傳輸窗口，一個TT幀的發(fā)送從發(fā)送節(jié)點到接收節(jié)點的路徑已經(jīng)在預(yù)先定義好。因此，在TT幀的發(fā)送窗口的時間內(nèi)，該TT幀便獨占此時數(shù)據(jù)傳輸?shù)逆溌?。這樣就確保了時間觸發(fā)流量的低時延及低網(wǎng)絡(luò)抖動。在時間觸發(fā)以太網(wǎng)中，時間觸發(fā)流量是最高優(yōu)先級。速率流量控制流量，定義連續(xù)兩個RC幀之間的最小傳輸時間間隔，來控制該RC流的速率。盡力而為流量利用之前兩種流量剩余的帶寬，處于最低優(yōu)先級。

基于時間觸發(fā)以太網(wǎng)的分布式機器人控制系統(tǒng)的一種拓撲結(jié)構(gòu)如圖 7所示，機器人節(jié)點及其他設(shè)備節(jié)點連接在TTEthernet交換機中，調(diào)度表存儲在交換機和需要實時服務(wù)的節(jié)點當中，全局的時鐘由高精度時鐘及時鐘同步算法維護。對于實時要求較高的服務(wù)，如機器人控制服務(wù)、基于傳感器的碰撞檢測服務(wù)等，可以在相應(yīng)的節(jié)點上部署實時性最高的時間觸發(fā)服務(wù)。該服務(wù)根據(jù)用戶定義的調(diào)度表按照確定的時間發(fā)送數(shù)據(jù)到相應(yīng)的節(jié)點，每個節(jié)點按照在預(yù)定義的時間窗口接收時間觸發(fā)消息數(shù)據(jù)并轉(zhuǎn)發(fā)，使在調(diào)度表定義的時間下，該服務(wù)可以獨占鏈路的所有帶寬。除了時間觸發(fā)流量以外，還可以用速率限制流量來傳輸如監(jiān)控視頻流。一般來說，控制信號及傳感器信號的周期固定，幀長較短，并且實時性要求最高，因此可用時間觸發(fā)流來發(fā)送。而對于速率固定的實時性要求較高的應(yīng)用，可用速率限制流來發(fā)送。其它非實時的業(yè)務(wù)用盡力而為流來傳輸數(shù)據(jù)。

此外，為避免單一總線節(jié)點出現(xiàn)熱點訪問問題成為系統(tǒng)的瓶頸，本發(fā)明通過分布式總線節(jié)點及總線節(jié)點的負載均衡來提高整個分布式控制系統(tǒng)的效率。

本發(fā)明的控制系統(tǒng)的功能模塊以服務(wù)的方式進行封裝，使其能夠被組合和應(yīng)用，因而具有開放式、可擴展、服務(wù)松耦合等特點。本發(fā)明機器人控制系統(tǒng)利用服務(wù)的松耦合性來實現(xiàn)機器人的控制，并且可以在一定程度上擴展控制系統(tǒng)，應(yīng)對不同的任務(wù)環(huán)境。

以下進一步舉例說明。

本實例應(yīng)用于固高六自由度機器人(GRB3016型)的控制系統(tǒng)上，發(fā)明設(shè)計一種通用的開放式結(jié)構(gòu)控制系統(tǒng)，如圖 1所示，不同類型的機器人以及其它設(shè)備節(jié)點能夠通過軟件總線進行相互的消息通信，總體架構(gòu)的分層結(jié)構(gòu)如圖 2所示。軟件總線由服務(wù)總線代理，總線節(jié)點，總線管理器和存儲節(jié)點四部分組成，如圖 3所示。每一個應(yīng)用服務(wù)都包含自己的服務(wù)總線代理，服務(wù)總線代理負責(zé)服務(wù)與總線的交互。總線節(jié)點是整個總線架構(gòu)的核心，主要負責(zé)流程消息的轉(zhuǎn)發(fā)調(diào)度，以及流程和服務(wù)信息的管理。軟件總線由一個或者多個總線節(jié)點組成。總線節(jié)點都包含請求管理模塊，訂閱發(fā)布管理模塊，網(wǎng)絡(luò)通信模塊，實時調(diào)度模塊，如圖 4所示?？偩€管理器負責(zé)總線節(jié)點的管理，維護總線節(jié)點的狀態(tài)?？偩€節(jié)點周期性地向總線管理器報告自身狀態(tài)，超過一定期限沒有發(fā)送狀態(tài)的總線節(jié)點將被當作出現(xiàn)故障。服務(wù)總線代理周期性地向總線管理器獲取總線節(jié)點狀態(tài)，以更新自身的總線狀態(tài)列表，如圖 5所示。本實例應(yīng)用服務(wù)由：人機交互服務(wù)，軌跡規(guī)劃服務(wù)，反解服務(wù)，機器人運動控制服務(wù)，正解服務(wù)，軟件總線配置服務(wù)。服務(wù)部署在一臺PC機上，軟件總線部署在兩臺PC機上。

實施例的基本流程如圖 6所示，人機交互服務(wù)為用戶提供與機器人控制的接口，用戶可以根據(jù)自己的需求來操作機器人。例如機器人示教過程或稱自定義的組合服務(wù)。在此例用戶在人機交互服務(wù)中導(dǎo)入示教文件，示教文件的坐標位置根據(jù)流程的信息轉(zhuǎn)發(fā)到下一個服務(wù)，即軌跡規(guī)劃服務(wù)中，在此例為直線插補服務(wù)。直線插補服務(wù)根據(jù)上一服務(wù)提供的位置信息，生成中間的軌跡，并將軌跡信息轉(zhuǎn)發(fā)到下一個服務(wù)當中，即反解服務(wù)中。反解服務(wù)根據(jù)上一服務(wù)提供的中間軌跡，生成機器人六關(guān)節(jié)的角度數(shù)據(jù)，然后將此服務(wù)轉(zhuǎn)發(fā)到機器人運動控制服務(wù)中，該服務(wù)負責(zé)機器人的運動控制。然后，運動控制服務(wù)將機器人反饋的關(guān)節(jié)信息生成機器人末端位姿并返回到機器人交互服務(wù)。其中，在整個流程的運作過程當中，軟件總線配置服務(wù)都參與了其中，為各個服務(wù)提供總線必要的信息以及對服務(wù)發(fā)送到總線的消息進行轉(zhuǎn)發(fā)等功能。在消息的轉(zhuǎn)發(fā)過程中，請求消息、應(yīng)答消息及心跳消息是以時間觸發(fā)流量進行傳輸，服務(wù)的注冊消息和狀態(tài)消息等非實時消息以速率限制流量進行傳輸。為保證整體系統(tǒng)分布式節(jié)點的數(shù)據(jù)傳輸實時性與確定性，本發(fā)明引入時間觸發(fā)以太網(wǎng)來滿足要求?；跁r間觸發(fā)以太網(wǎng)的分布式機器人控制系統(tǒng)的一種拓撲結(jié)構(gòu)如圖 7所示，機器人節(jié)點及其他設(shè)備節(jié)點連接在TTEthernet交換機中，調(diào)度表存儲在交換機和需要實時服務(wù)的節(jié)點當中，全局的時鐘由高精度時鐘及時鐘同步算法維護。對于實時要求較高的服務(wù)，如機器人控制服務(wù)、基于傳感器的碰撞檢測服務(wù)等，可以在相應(yīng)的節(jié)點上部署實時性最高的時間觸發(fā)服務(wù)。該服務(wù)根據(jù)用戶定義的調(diào)度表按照確定的時間發(fā)送數(shù)據(jù)到相應(yīng)的節(jié)點，每個節(jié)點按照在預(yù)定義的時間窗口接收時間觸發(fā)消息數(shù)據(jù)并轉(zhuǎn)發(fā)，使在調(diào)度表定義的時間下，該服務(wù)可以獨占鏈路的所有帶寬。除了時間觸發(fā)流量以外，還可以用速率限制流量來傳輸如監(jiān)控視頻流。一般來說，控制信號及傳感器信號的周期固定，幀長較短，并且實時性要求最高，因此可用時間觸發(fā)流來發(fā)送。而對于速率固定的實時性要求較高的應(yīng)用，可用速率限制流來發(fā)送。其它非實時的業(yè)務(wù)用盡力而為流來傳輸數(shù)據(jù)。整個系統(tǒng)的時間調(diào)度表已根據(jù)需求離線生成，供控制系統(tǒng)的調(diào)用。本實例的控制基本流程包括以下步驟：

1、服務(wù)注冊

在本控制系統(tǒng)中，包含三個角色，分別是服務(wù)請求者，服務(wù)提供者和服務(wù)注冊中心。服務(wù)請求者發(fā)送請求服務(wù)消息，通過查詢服務(wù)注冊中心，獲取服務(wù)信息并綁定服務(wù)，再根據(jù)服務(wù)所提供的接口執(zhí)行任務(wù)。服務(wù)提供者提供了服務(wù)的具體功能實現(xiàn)。通過注冊操作在服務(wù)注冊中心中發(fā)布服務(wù)的接口和描述等信息，使得服務(wù)請求者可以查詢和訪問該服務(wù)。服務(wù)注冊中心提供并維護了一個可用服務(wù)目錄，允許服務(wù)請求者查找感興趣的服務(wù)的接口。

在本系統(tǒng)當中，服務(wù)注冊中心部署在總線節(jié)點上，服務(wù)提供者需要將服務(wù)描述的文件發(fā)布到總線上，總線在本地維護一個可用服務(wù)目錄，供服務(wù)請求者查詢使用。注冊中心需要返回有關(guān)服務(wù)、服務(wù)的工作方式、所使用的參數(shù)及其返回值等信息。服務(wù)請求者根據(jù)這些信息，向總線節(jié)點發(fā)送調(diào)用的消息，進行服務(wù)的請求?？偩€節(jié)點需要檢查當前注冊服務(wù)是否為實時服務(wù)，若是實時服務(wù)，則需要根據(jù)實際更新時間調(diào)度表或者拒絕該服務(wù)注冊。

服務(wù)在初始化時，需要完成服務(wù)的注冊過程。向總線發(fā)送服務(wù)描述文件，里面包含了服務(wù)中可調(diào)用的接口、服務(wù)從屬的機器人ID、服務(wù)的QoS等信息，過程如圖 8所示?？偩€接收到這些初始化信息后，存儲在總線節(jié)點的數(shù)據(jù)存儲模塊（數(shù)據(jù)庫）中，方便以后查詢。另外，總線為服務(wù)的分配ID并將ID及它的地址添加到路由表中。服務(wù)注冊成功后，由總線返回一條注冊成功的消息到服務(wù)上，這樣就完成了服務(wù)的注冊過程。在此之后，服務(wù)可以正常的向總線發(fā)送請求服務(wù)。

2.服務(wù)組合

在此，每次客戶的請求都是以業(yè)務(wù)流程的形式進行請求，而業(yè)務(wù)流程可以分解為若干服務(wù)的有序組合。一個業(yè)務(wù)流程信息以有向無環(huán)圖的形式表示。其中每個節(jié)點表示一個服務(wù)組件。圖 9表示一個服務(wù)流程的結(jié)構(gòu)實例，包括：流程的規(guī)模、每個節(jié)點的編號、每個節(jié)點所代表的服務(wù)ID。從圖中可以看到，整個組合服務(wù)由4個服務(wù)組成，1號節(jié)點服務(wù)先啟動，執(zhí)行完畢后1號節(jié)點的結(jié)果會發(fā)送到總線上，總線根據(jù)流程的拓撲將結(jié)果轉(zhuǎn)發(fā)到下一個服務(wù)節(jié)點上。依次執(zhí)行，最后3號、4號節(jié)點的結(jié)果會由總線負責(zé)返回給用戶使用。當用戶或者服務(wù)向總線發(fā)起請求時，如果該請求被接納，則總線會為該請求創(chuàng)建一個唯一的請求實例信息，負責(zé)維護本次請求的執(zhí)行狀態(tài)。

服務(wù)組合（流程配置）的配置過程如圖 10所示，主要包括以下幾個步驟：

新建一個組合服務(wù)，在已注冊的服務(wù)當中選取一個添加到其中。

根據(jù)前一服務(wù)的輸出參數(shù)及業(yè)務(wù)需求，添加與之匹配的輸入?yún)?shù)的服務(wù)。

如果需要添加新的服務(wù)，則返回繼續(xù)添加。否則完成服務(wù)組合配置。

3.用戶向軟件總線請求相關(guān)服務(wù)或流程

對于本系統(tǒng)來說，請求/應(yīng)答模式是最主要的服務(wù)消息交換模式。服務(wù)A需要B提供服務(wù)并返回應(yīng)答消息。首先服務(wù)A將需要服務(wù)B處理的數(shù)據(jù)封裝為一條請求消息，向總線發(fā)送請求消息?？偩€接收到服務(wù)A的請求消息后，將查詢本地的路由表，并將請求消息轉(zhuǎn)發(fā)到服務(wù)B中。此時服務(wù)A處于阻塞狀態(tài)，一直等待服務(wù)B返回應(yīng)答消息。服務(wù)B接收到請求消息后，根據(jù)消息調(diào)用本地的函數(shù)，并返回合適的應(yīng)答消息到總線上?？偩€根據(jù)應(yīng)答消息查詢路由表，將應(yīng)答消息轉(zhuǎn)發(fā)到服務(wù)A中。

本發(fā)明提供訂閱/發(fā)布消息交換模式來使服務(wù)可以自由向總線發(fā)布和訂閱消息，對于實時性要求不高的服務(wù)可以用這種模式來進行消息交換。例如，服務(wù)A定時發(fā)布心跳消息（消息中包含服務(wù)的當前狀態(tài)和消息隊列長度等）到總線上。服務(wù)B和服務(wù)C向總線注冊訂閱了服務(wù)A的心跳消息來監(jiān)測服務(wù)A的工作狀態(tài)?？偩€根據(jù)服務(wù)A發(fā)布的消息查找訂閱的服務(wù)A心跳消息的列表，逐一向服務(wù)B和服務(wù)C轉(zhuǎn)發(fā)這條消息。引入訂閱/發(fā)布這種機制，是為了減少服務(wù)之間的耦合程度，服務(wù)可以根據(jù)訂閱的消息類型自由得獲取消息，不必每次都向特定服務(wù)請求消息。

由于本發(fā)明可以適應(yīng)分布式總線節(jié)點的架構(gòu)，因此在服務(wù)轉(zhuǎn)發(fā)消息之前需要通過負載均衡模塊來確定需要轉(zhuǎn)發(fā)的總線節(jié)點。負載均衡首先根據(jù)消息的信息，通過負載均衡算法選定目標總線節(jié)點的節(jié)點號。服務(wù)總線代理根據(jù)這個節(jié)點號查找服務(wù)的總線表，并將表中的信息填入消息中轉(zhuǎn)發(fā)消息到對應(yīng)的總線節(jié)點。服務(wù)總線代理軟件總線配置服務(wù)中得到當前軟件總線的節(jié)點數(shù)目及其對應(yīng)的負載情況。

4.軟件總線的調(diào)度

本發(fā)明提出兩級調(diào)度方案，以系統(tǒng)丟包率和響應(yīng)時間比的多目標函數(shù)作為測量標準，通過調(diào)節(jié)任務(wù)的優(yōu)先級及傳輸周期對總線資源進行優(yōu)化分配，調(diào)度模塊框架如圖 11所示。

第一級調(diào)度作用是計算任務(wù)優(yōu)先級。這一級調(diào)度提出一種改進的EDF動態(tài)調(diào)度算法，首先，由模糊反饋控制器預(yù)測每一個控制環(huán)的資源利用率需求值，然后由優(yōu)先級配置器根據(jù)資源利用率需求值、死期、重要性等屬性計算任務(wù)優(yōu)先級，最后根據(jù)優(yōu)先級把任務(wù)消息插入就緒任務(wù)隊列并將優(yōu)先級映射到本地操作系統(tǒng)優(yōu)先級。

第二級調(diào)度作用是調(diào)節(jié)各任務(wù)的傳輸周期。首先，由PID控制器計算出整體總線資源利用率，然后由周期調(diào)節(jié)器根據(jù)總線資源利用率調(diào)節(jié)任務(wù)周期，通過調(diào)節(jié)任務(wù)的傳輸周期對總線資源進行優(yōu)化分配，進一步優(yōu)化系統(tǒng)性能。

5. 軟件總線的消息處理

一個服務(wù)通過請求消息可以向其它服務(wù)發(fā)起請求。接收到相關(guān)請求消息的服務(wù)會做出應(yīng)答，并發(fā)送一個或多個應(yīng)答消息。一般地，發(fā)送請求消息的服務(wù)不需要知道目標服務(wù)的具體位置，只需按照預(yù)先定義好的消息協(xié)議向總線發(fā)送消息，這樣的機制實現(xiàn)了服務(wù)之間的解耦合。

發(fā)送到軟件總線的消息類型有：結(jié)果消息、狀態(tài)消息、注冊消息、請求消息和應(yīng)答消息。總線節(jié)點都包含請求管理模塊，訂閱發(fā)布管理模塊，網(wǎng)絡(luò)通信模塊，實時調(diào)度模塊，如圖 4所示。

請求管理模塊是總線節(jié)點的核心，主要負責(zé)流程消息的轉(zhuǎn)發(fā)和路由，從消息接收隊列中獲取服務(wù)消息，并根據(jù)消息的流程信息查找轉(zhuǎn)發(fā)路由表，更新消息的目標服務(wù)，再將消息加入消息發(fā)送隊列中。轉(zhuǎn)發(fā)路由表是請求管理模塊的重要組成部分，存儲著系統(tǒng)中常用的流程信息，轉(zhuǎn)發(fā)路由表的命中率對總線節(jié)點的性能有很大的影響。

訂閱發(fā)布管理模塊負責(zé)服務(wù)或總線節(jié)點的消息訂閱和消息發(fā)布。服務(wù)或總線可以通過訂閱方式來接收某些類型的消息，同時地，能夠提供這些類型消息的其他服務(wù)會把這些消息發(fā)布到總線上。一般而言，服務(wù)或總線會通過訂閱時所設(shè)置的參數(shù)來過濾消息。例如，總線之間通過發(fā)布自身的心跳消息，并訂閱其它節(jié)點的心跳消息來互相傳遞各自的狀態(tài)（如出錯、超負載等），并由各自的總線管理器進行處理。

實時調(diào)度模塊主要負責(zé)根據(jù)消息的優(yōu)先級對消息接收隊列和消息發(fā)送隊列中的消息進行調(diào)度，主要目的是提高總線的實時性，因為控制系統(tǒng)的實時性有著比較高的要求。

網(wǎng)絡(luò)通信模塊主要負責(zé)總線節(jié)點與服務(wù)之間的通信細節(jié)管理，包括服務(wù)連接池的管理，網(wǎng)絡(luò) I/O 模式，服務(wù)消息的解析等。網(wǎng)絡(luò)通信模塊從服務(wù)獲取消息，解析后放到消息接收隊列中，當消息處理完畢后，再從消息發(fā)送隊列中取出消息，封裝后根據(jù)路由信息發(fā)送到目標服務(wù)。

圖 12示了一個信息包從源服務(wù)（實例是人機交互服務(wù)）經(jīng)由軟件總線轉(zhuǎn)發(fā)到目的服務(wù)的執(zhí)行流程。

主要包含以下幾個步驟：

（1）源服務(wù)通過總線 API 將消息傳遞給服務(wù)總線代理?？偩€ API 由服務(wù)接口生成模塊根據(jù)用戶定義的服務(wù)接口文件生成，為服務(wù)提供了一種與總線的交互方式。消息最終將被存儲在服務(wù)總線代理的發(fā)送隊列中。

（2）服務(wù)總線代理根據(jù)消息協(xié)議對消息進行序列化，服務(wù)總線代理根據(jù)負載均衡模塊的結(jié)果，選定一個總線節(jié)點，并將消息轉(zhuǎn)發(fā)到目標總線節(jié)點。

（3）總線節(jié)點接收到請求消息后存儲到接收隊列中，請求管理模塊將根據(jù)實時調(diào)度模塊的調(diào)度結(jié)果從接收隊列中選出當前優(yōu)先級最高的消息進行處理。

（4）請求管理模塊根據(jù)選出消息的流程 ID，服務(wù) ID，函數(shù) ID 等信息，在總線節(jié)點的轉(zhuǎn)發(fā)路由表中查找該消息目標服務(wù)。如果查找成功，則直接轉(zhuǎn)到步驟（8），否則轉(zhuǎn)到步驟（5）。

（5）總線節(jié)點向存儲節(jié)點發(fā)起請求，獲取消息目標服務(wù)的詳細信息。

（6）存儲節(jié)點接收總線節(jié)點的請求，根據(jù)請求中提供的消息的流程 ID，服務(wù) ID，函數(shù) ID 等信息對數(shù)據(jù)庫進行查詢，獲取目標服務(wù)的信息，并將查詢結(jié)果返回給總線節(jié)點。

（7）總線節(jié)點獲取存儲節(jié)點返回的結(jié)果，使用結(jié)果中的目標服務(wù)信息更新自身的轉(zhuǎn)發(fā)路由表。然后轉(zhuǎn)到步驟（4）。

（8）總線節(jié)點將消息發(fā)送到目標服務(wù)的服務(wù)總線代理。

（9）目的服務(wù)的服務(wù)總線代理接收總線節(jié)點發(fā)送的消息，根據(jù)消息協(xié)議對消息進行反序列化，再通過總線 API 將消息傳遞給服務(wù)的應(yīng)用層進行處理。

6. 被請求的服務(wù)的消息處理

被請求的服務(wù)根據(jù)接收的信息提取相關(guān)的調(diào)用函數(shù)及調(diào)用參數(shù)，然后將調(diào)用參數(shù)傳遞給服務(wù)的內(nèi)部函數(shù)進行調(diào)用，得到的處理結(jié)果通過服務(wù)總線代理API返回到軟件總線上。

7. 軟件總線處理返回消息

軟件總線接收到來自服務(wù)的結(jié)果消息，從消息的內(nèi)容判斷是單個服務(wù)請求結(jié)果還是業(yè)務(wù)流程中的一個中間結(jié)果。若是單個服務(wù)請求結(jié)果，直接將結(jié)果消息轉(zhuǎn)發(fā)到請求服務(wù)上。若是業(yè)務(wù)流程的中間結(jié)果，則將中間結(jié)果轉(zhuǎn)發(fā)到業(yè)務(wù)流程當中給的下一個服務(wù)當中。