何用輝

(福建信息職業(yè)技術學院機電工程系，福建福州350003)

許多嵌入式環(huán)境下的分布式系統(tǒng)是基于進程間的顯式消息進行信息交換的，其發(fā)送和接收過程無法隱藏通信過程.這種方式的缺點是開發(fā)者需要了解網絡接口及使用方式，通信過程對開發(fā)者來說不透明，必須親自關心數據的發(fā)送和接收，極大影響了程序的開發(fā)效率.鑒于CAN總線在嵌入式系統(tǒng)中的廣泛應用，設計并實現(xiàn)了一種可運行于嵌入式CAN網絡的RPC協(xié)議及其實現(xiàn)方法，通過使用一致的協(xié)議和提供基礎性的底層服務，使得開發(fā)人員不必為如何實現(xiàn)通信而煩惱，從而可以把注意力集中到如何解決問題上，有效地改進現(xiàn)有工業(yè)控制系統(tǒng)的開發(fā)效率.

1 RPC原理及其在CAN總線上的實現(xiàn)

1.1 RPC實現(xiàn)原理

RPC可分為異步RPC和同步RPC，在調用方發(fā)出RPC請求后，調用進程會被掛起的為同步RPC，反之為異步RPC，這里所描述的RPC為同步RPC.RPC通過如下基本過程實現(xiàn)對開發(fā)者隱藏通信細節(jié)的目的.節(jié)點A調用節(jié)點B上的進程時，節(jié)點A上的調用進程將被掛起，而B上被調用的進程開始執(zhí)行.調用方使用參數將信息提供給被調用方，然后被調用方用返回值的形式將結果傳回調用方.

在這種方式下，客戶端的開發(fā)者可以以正常的方式調用某個函數.當這個函數的實現(xiàn)被放在遠程服務器時，在本機的函數體中放入RPC調用的實現(xiàn)版本，稱之為客戶存根(client).這個客戶存根首先阻塞源程序，同時對接口函數的參數類型和字節(jié)數進行統(tǒng)一封裝，調用網絡接口函數，發(fā)送RPC請求包到遠程服務器.遠程服務器接收到這個數據包后，將它傳遞給一個稱作服務器存根(server stub)的進程.服務器存根對這個包進行解析并提取需要的參數，同時調用相應的函數實體，并返回相應的執(zhí)行結果.然后，服務器存根返回這個結果給客戶端，客戶端重新喚醒相應的進程，使原程序繼續(xù)運行.這樣，對開發(fā)者來講，整個過程就好像是本地調用一樣.

RPC的另一個關鍵是設計一個通信綁定過程.圖1所示為基于TCP/IP協(xié)議棧的RPC協(xié)議所采用的方法示意圖.首先，服務進程向本機守護程序注冊一個端口號，然后服務進程向目錄機器的目錄服務進程注冊一個服務名稱.之后，客戶進程就可以調用服務進程了.客戶端首先把需要的服務名稱傳給目錄服務器，目錄服務器返回具有此服務的服務器網絡地址，客戶進程隨后向該機器的守護進程(它具有公開的端口號)發(fā)出請求，目標服務器守護進程查詢端口表并返回相應服務的端口號，客戶進程最后通過獲得的網絡地址和服務端口號進行RPC連接.

圖1 RPC服務綁定過程

1.2 嵌入式環(huán)境下的分層RPC模型

通過上面分析可知，在嵌入式環(huán)境下(特別是在非以太網的網絡環(huán)境下)，由于系統(tǒng)對資源有著嚴格的限制，用上述一般方法實現(xiàn)RPC是很困難的，甚至無法實現(xiàn).因此，設計了一個適用于嵌入式環(huán)境下的簡單、分層RPC協(xié)議，根據RPC協(xié)議原理，將RPC協(xié)議的嵌入式實現(xiàn)分成了如下3個部分:客戶存根處理模塊、服務器存根處理模塊和協(xié)議數據格式.

1)客戶存根處理模塊.模塊處理過程如圖2所示.

圖2 RPC客戶存根處理模塊

這個模塊實現(xiàn)了客戶端的RPC處理過程.在每個RPC客戶機器上實現(xiàn)一個客戶存根處理進程，這個進程負責處理本機的各個RPC調用，維護一個全局的消息隊列.當用戶進程調用一個RPC函數時，本地函數的實現(xiàn)部分會打包相關消息(這個消息包含有RPC調用號、創(chuàng)建的接收郵箱地址、參數組編等信息)，然后發(fā)送到這個消息隊列中.客戶存根處理進程將提取、解析這些消息包，然后通過網絡發(fā)送詢問幀以查找具有相應服務的主機.找到后再將這個消息包打包發(fā)送到對應主機，并接收主機的返回結果.最后將結果發(fā)送到用戶進程的郵箱中，從而喚醒用戶進程.同時，客戶存根處理進程還維護一個RPC處理狀態(tài)表，以方便客戶處理這些消息包.這個狀態(tài)表保存有RPC調用處理過程的一些狀態(tài)信息(比如狀態(tài)表保存了RPC調用的開始狀態(tài)、調用主機查詢狀態(tài)、消息返回、處理成功、超時時間等狀態(tài)).

2)服務器存根處理模塊.模塊處理過程如圖3所示.

圖3 服務存根處理模塊

這個模塊實現(xiàn)了服務器端的RPC處理過程，本機的RPC服務均在這個模塊中實現(xiàn).首先，客戶機器的一個RPC調用將會觸發(fā)服務器的RPC中斷，RPC中斷處理函數將網絡消息放到服務器存根的全局消息隊列中.服務器存根處理進程進行消息提取、消息解析、調用服務函數表中的相應服務函數、發(fā)送RPC結果等操作.同時，類似于客戶端處理進程，服務器存根處理進程也維護一個RPC處理狀態(tài)表，用以標志處理過程的相應狀態(tài).

3)協(xié)議數據格式模塊.這個模塊分2個部分，一部分是用戶進程向客戶端處理進程發(fā)送的處理消息格式，另一部分是網絡傳輸的數據格式.

1.3 CAN總線鏈路層協(xié)議

CAN總線是一種有效支持分布式控制或實時控制的串行通訊網絡，其總線規(guī)范已被ISO國際標準化組織制定為國際標準.根據國際CAN 2.0B的技術規(guī)范，CAN2.0B含有標準數據幀和擴展數據幀，兩者區(qū)別是幀的仲裁長度不一樣，其格式如圖4所示.此設計采用標準數據幀格式，以減少網絡傳輸量.

圖4 CAN鏈路層協(xié)議格式

CAN總線的應用范圍遍及高速網絡到低成本的多線路網絡，并廣泛應用于車載系統(tǒng)、控制系統(tǒng)等領域，在工業(yè)控制領域占據著主導地位.此處只介紹與本設計密切相關的仲裁字段、控制字段和數據字段的格式.仲裁字段包含一個數據幀的幀ID，和以太網不同，CAN總線的數據包是面向幀消息的，而以太網是面向節(jié)點的.因此，CAN數據包只包含一個幀ID，而不包含目的地址和源地址信息，控制字段包含由數據字段的長度信息(數據字段長度只能為0－8B)，數據字段則包含相應要傳輸的數據.

1.4 基于CAN的RPC機制的協(xié)議模塊

如上所述，RPC數據協(xié)議模塊包含2個部分.一部分是用戶進程向客戶存根處理進程發(fā)送的處理消息格式;另一部分是網絡傳輸的數據格式.基于CAN總線的RPC協(xié)議格式如圖5所示.

圖5 RPC數據格式

數據幀的幾點說明:

1)郵箱地址.RPC客戶存根處理進程收到遠程服務器的返回結果后，將獲得的數據放入這個郵箱地址，以便喚醒相應用戶進程.

2)唯一調用號.這是一個全局唯一的調用號，占據1個字節(jié).系統(tǒng)必須保證所有的服務在全局僅有唯一的一個調用號碼.

3)參數組編.設計中對參數和返回值有如下規(guī)定.

①假設在函數參數列表中的參數從左到右分別是param l，param2，…，paramN，它們對應地放在調用數據包的“參1…參數N”，那么，參數組編格式為“參數數目+參數1組編+參數2組編+…參數N組編”.參數的組編則有2種形式:非指針型和指針型.非指針型參數的組編方法為“類型編號(4 bit)+實參數據”;指針型參數的組編方法為“類型編號(4 bit)+長度(12 bit)+實參數據”.本設計參數組編方法詳見表1和表2所示.

②函數的返回值組編方法和參數組編方法一樣，只不過它是保存在服務器傳給客戶機的數據包中.

③簡單RPC只接收C語言的簡單數據類型(不包含浮點數據類型)，支持1維指針，不支持2維以上的指針，也不支持struct類型.

④數據的存放表示一律使用little endian.

⑤傳遞指針時，需要把指針指向的數據放入報文中.

4)幀類型.占2個位(2 bit)，其中“00”表示RPC結果返回幀，幀攜帶RPC的調用結果數據;“01”表示調用查詢幀，幀攜帶調用請求數據.客戶端用這種幀查詢哪臺服務器擁有相關調用號的服務;“02”傳輸出錯報文幀，用于服務器和客戶端的傳輸信息協(xié)調.這個字段和上面提到的“唯一調用號”字段組成了仲裁字段的ID字段(11 bit).

表1 非指針型組編編碼

表2 指針型組編編碼

5)剩余字節(jié)數(占用1B).如果一個幀無法傳輸完整的數據，那么需要將要傳輸的數據分成多個數據幀來傳輸.這個字段保存剩余需要傳輸的數據字節(jié)數目，用以完成整個數據包的完整傳輸.

6)識別號(占用1B).這個號的作用是區(qū)分不同進程對同一個服務的調用，并標志調用進程.

1.5 重要函數

2 RPC測試與分析

采用ARM 7－Lpc2290處理器(本身帶有CAN接口)，μC/OS－II為底層操作系統(tǒng)，CAN總線網絡為網絡環(huán)境.設定系統(tǒng)所使用的總線速率為125 kbps.一般來說，同步RPC設計目標主要有2個:高吞吐量和低延時，但二者不可兼得.由于在嵌入式環(huán)境下，特別是控制環(huán)境下，節(jié)點間通信的數據量比較小，對實時性有一定的要求，因此在所述的設計中以低延時作為主要目標.

測試主要考察在RPC調用過程中，RPC相關操作對調用時間的影響.測試所使用的過程接口為unsigned char W ritedata1(u8 data，u8 len).該過程中將首地址為data，長度為len的數據從客戶端發(fā)送到服務器端.如果調用成功，服務器返回接收到的數據長度，否則返回0.作為對比，本測試使用了不同大小的數據，并得到所使用的時間.由于嵌入式環(huán)境下數據量比較小，因此規(guī)定最大數據長度為256B，這個長度可以滿足大多數進程通信的要求，具體測試結果見表3.

從測試結果可以看出，RPC相關操作對調用時間的影響較低，基本實現(xiàn)了低延時的設計目標.RPC方式與直接使用消息的傳遞方式在時間消耗方面相差不大.

表3 RPC時間測試ms

3 結語

分層RPC協(xié)議可以在多個嵌入式系統(tǒng)之間順利地完成函數調用，從而提供了一定的互操作性.分層的RPC協(xié)議把進程間調用和網絡連接調用分開，方便了不同系統(tǒng)、不同網絡的編程.簡單的說，這個分層協(xié)議為客戶端和服務器之間建立統(tǒng)一的底層通信機制，使得系統(tǒng)開發(fā)者可以把精力集中到如何實現(xiàn)功能以及解決實際問題上來.

［1］ 袁菲，陸洋，海深.嵌入式環(huán)境下RPC的設計與實現(xiàn)［J］.計算機工程，2007(9):266－268.

［2］ Vinoski S.RPC Under Fire［J］.IEEE Internet Computing，2005，9(5):93－95.

［3］ Dissanaike S，W ijkman P，W ijkman M.Utilizing XMLRPC or SOAP on an Embedded System［C］//Proc.of Distributed Computing SystemsWorkshops.2004:438－440.

［4］ 鄭麗英，李全兵.一種新的基于RPC的分布式開發(fā)模型［J］.蘭州交通大學學報:自然科學版，2004(1):83－86.

［5］ 肖政東.基于CAN總線的RPC遠程監(jiān)控系統(tǒng)的研究與實現(xiàn)［D］.南京:南京航空航天大學，2009.

［6］ 何用輝.基于CAN總線的啤酒發(fā)酵監(jiān)控系統(tǒng)研究與設計［D］.福州:福州大學，2006.