于興晗,蓋優普,侯 煜,郭 易
(中國水利水電科學研究院水情水調事業部,北京市 100038)
一種三層協議定制機制模型的設計與實現
于興晗,蓋優普,侯 煜,郭 易
(中國水利水電科學研究院水情水調事業部,北京市 100038)
本文介紹了一種可以現場修改協議和增加新協議的三層協議定制機制模型的設計與實現,詳細闡明三層協議定制機制模型的各種相關原理和關鍵技術,介紹了兩種編程實現結構,適合匯編和C語言的多表分析結構和適合C++、C#和Java等高級語言的單表映射結構。同時,詳細介紹了在實際工程上使用單表映射結構在嵌入式系統Windows Ce上開發三層協議定制機制模型的過程,在一定程度上解決了解決水利信息化系統中多源設備的整合以及不同代產品的混合使用的問題。
協議定制;嵌入式;多表分析;單表映射
在我國現行的水利數據檢測領域,數據采集器都是采用單片機+程序的硬件開發技術來實現的,整個水利數據采集系統的工作過程是,數據采集器通過傳感器收集現場數據,一部分數據存儲在本地,大部分數據需要通過無線通信技術(GSM/GPRS/超短波/北斗衛星/Inmarsat等)或者是有線(PSTN/internet等)發送到中心站,中心站在將接收到的數據進行處理、為洪水預報、防洪調度和水資源合理開發利用決策提供原始數據[5][6]。為節省傳輸信道的帶寬,減少數據誤碼率,保證數據的可靠性,大部分的水利數據在信道中傳輸時都采用協議編碼,將原始數據按照規定的協議進行編碼,將編碼后的數據包經由信道傳輸給中心站,中心站接到數據后按照協議的規定進行解碼還原成原始數據再進一步處理。
大部分水利數據采集系統安裝完成以后,只支持一種協議數據傳輸,當需要修改協議(包括增加數據類型、增加數據傳輸種類、添加新型數據采集器等)或者是增加新的協議時,整個水利數據采集系統(數據采集端—遙測站,數據接收端—中心站)軟件都需要重新開發,整個程序編碼都需要重頭編寫,所有的工作流程都需要重新實現,不但開發的周期長,效率低下,而且使整個系統繼承困難,不利于產品更新換代。
目前,我國許多早期搭建的水利數據采集系統都到了需要更新換代的時候,隨著生產水利數據采集器設備的廠家增多,通信協議也越來越多,每個廠家都有自己的獨有的通信協議,不同廠家之間的設備不能替換,結果就導致用戶在選擇水利數據采集器時,對協議的支持就成了重中之重,只有支持原協議的設備才能更換原設備;在搭建新的水利數據采集系統時,由于通信信道種類的增多,用戶對于支持多協議的數據采集系統的需求也越來越多,比較常用的都是雙協議,目前大部分的水利數據采集系統的中心站都是采用使用多個數據采集軟件,共享數據庫來實現的;這種實現辦法雖然在一定程度上解決了多源設備所導致的協議增多問題,但是隨著數據采集器設備種類的增多中心站的負擔將越來越重,最終會導致多個數據采集軟件互相沖突,中心站阻塞丟失數據。
針對上述弊端,大部分廠家采取了簡化協議結構或單獨設計協議子程序的做法,在更改協議時只需修改協議子程序即可,盡量減少二次開發的工作量,這種方法極大地減少了當協議變化或者是增加新元素時修改程序的工作量,但是這種方法主要還是依靠開發者來實現不支持第三方開發,不利于技術的推廣。本文描述了一種協議定制機制模型——三層協議定制機制模型,該機制使我們的產品具有使用其他廠家協議的能力,只需要簡單地設置和編寫少量的代碼即可實現第三方協議的加入,讀者只需按照編程指導操作就可以開發出自己的協議。
三層協議定制機制模型是在充分了解協議棧工作原理和水利數據采集系統工作流程的情況下,所抽象出來的協議定制模型,這種模型結構清晰,易于實現,當用戶需要修改協議時只需要通過簡單地設置就可實現,而不需要修改整個程序。
三層協議定制機制模型是在充分了解水利數據采集系統工作流程的基礎上實現的,該機制的加入不會影響整個水利數據采集系統原有的工作流程。用戶只需按照用戶編程指導手冊經過簡單地設置和編寫少量的代碼,就可將第三方協議加載到水利數據采集系統。
三層協議定制模型的建立,采用兩種編程分析模型:表格化編程模型,支持匯編和C語言編程,非嵌入式的數據采集器可以使用此模型;對象化編程模型,支持C++、C#和Java等高級語言,嵌入式數據采集器和中心站均可使用此模型。
隨著嵌入式開發技術的發展,將嵌入式開發技術應用到水利數據采集系統也成為必然,在嵌入式開發技術當中,C、C++、C#和Java是嵌入式開發編程主要使用的開發語言,三層協議定制機制模型可以使用這些語言來實現,因此三層協議定制機制模型可以很容易在嵌入式操作系統上實現,本文所介紹的實現就是在嵌入式操作系統Windows Ce[1-4]上實現的。
三層協議定制機制模型指的是,協議定制機制模型的結構主要分為三層,標簽行為層、標簽數據層和標簽影射層,結構框圖如圖1所示,通過標簽數據、標簽映射和標簽行為的對應關系來實現對原始數據的編解碼,從而實現對協議的定制。

圖1 三層協議定制模型結構框圖
在水利數據采集系統中,傳輸的數據必須包含傳感器名、站號、時間和采樣值,只有包含這些信息的數據我們才認為是有效的數據,針對不同的功能(標簽行為),所傳數據所包含的內容也可能不同,在實現時使用不同的開發語言所形成的編碼也不同,為解決這一矛盾,在設計三層協議定制機制時我們引入了標簽概念。標簽指的是水利數據采集系統所傳原始數據與協議描述語言之間的一一映射關系,包括數據、映射和行為。通過該映射來實現原始數據與功能、協議和代碼之間的一一對應關系,如圖2所示。
數據名:指的是水利數據采集系統中所使用的原始數據描述符(助記符),如水位1/Water1、雨量/Rain和電壓/Volt等。

圖2 標簽、傳感器名和傳感器名之間的關系框圖
點號:指的是原始數據名在協議編碼中所對應的映射值,該值是由協議唯一確定,如短信協議用83表示水位1,用84表示雨量;SSP協議用20表示水位,用1、21表示雨量等。
協議:指的是對原始數據編碼時所采用的協議,當協議確定后其他元素都是唯一的,如短信協議用SMS表示,sutron公司的協議用SSP表示等。
行為:指的是傳輸數據所對應的水利數據采集系統的行為,如定時報,平安報和閥值報等,由水利數據采集系統的硬件功能唯一確定。
操作碼:指的是協議所規定的與水利數據采集系統行為一一對應數據,如時段報用03表示,當前報由02表示等,由協議唯一確定。
數據類型:指的是原始數據值與協議描述語言所表示的類型之間的一一對應關系,如水位用浮點數表示,當用SMS協議時用02表示,SSP協議用03表示等。
標簽數據,本文所提的標簽數據指的是在水利數據采集系統中,所有可以被指定協議描述所包含的數據;標簽數據的內容與協議的規定有關,不同協議所指定的標簽數據可以相同,標簽數據與協議所描述的數據必須要一一對應;如當我們增添的協議只要求傳輸一組雨量數據時,那么該協議所指定的標簽數據就只包含一組數據雨量數據。
標簽映射指的是標簽數據在協議中所對應的編碼,一般用數值來表示,標簽映射與標簽數據和協議相關,在指定協議的情況下,標簽映射與標簽數據是一一對應的。如針對SMS協議標簽數據水位1所對應的標簽映射是83。
標簽行為指的是水利數據采集器的具體功能與指定協議所描述的操作碼之間的映射關系,不是一一對應,如針對SMS協議,水利數據采集器的平安報可能需要時段報和當前報兩個協議操作碼,而數據采集器的閥值報就需要當前報一個操作碼。
整個機制的運行主要分兩個過程,發送數據時的標簽數據編碼和接收數據時的標簽數據的解碼過程,編碼原理框圖如圖3所示。

圖3 協議定制機制的編碼原理框圖
系統在發送數據時,首先通過加載標簽庫來確定需要發送的標簽數據,準備好標簽數據后系統在通過標簽行為來確定需要加載的標簽映射模塊,同時,按照協議規定對準備好的標簽數據進行打包,打包后形成協議數據,將協議數據通過通信設備發往中心站。
接收數據時,原理框圖如圖4所示。
系統首先將數據讀入系統,通過標簽庫來確定需加載的協議模塊,按照協議對接收數據進行解析,將解析后的標簽數據送入標簽庫來分析,有對應的行為則按照行為來處理,無則丟棄。

圖4 協議定制機制的接收原理框圖
發送數據時“→加載標簽→準備標簽數據→查找標簽行為→加載標簽映射/協議模塊→按協議對標簽數據打包→協議數據→”,接收數據時“→讀取端口數據→加載標簽庫→加載協議模塊→按協議解析數據/標簽數據→查找標簽行為→處理數據→”;通過三層協議定制機制模型工作流程可以看出整個機制的運行都是依賴于標簽,即標簽是整個協議定制機制模型得以存在的核心關鍵技術,其執行效率決定整個協議定制機制模型的運行效率。
標簽數據成員的確定要能完整表述水利數據采集系統通信協議所需的元素,標簽數據成員的設定對用戶及三層協議定制模型的實現都有著比較大的影響,標簽數據成員過少,則不足以解決原始數據和協議編碼之間的一一映射關系,標簽數據過多則會降低協議層對標簽數據處理的效率。所以,確定適當的標簽數據成員,最終會影響到整個協議定制機制模型的執行效率。
標簽庫是實現三層協議定制機制的關鍵技術,該庫的實現依賴于水利數據采集系統的具體功能和通信協議的規定,是水利數據采集系統具體功能和通信協議規定的組合抽象,是水利數據采集系統具體功能在通信協議上的映射體現,標簽庫的復雜程度將會影響整個機制的運行效率,實現時還與所使用的開發語言有關。標簽庫主要包含6個映射,原始數據名映射,協議映射,操作碼映射,行為映射,數據類型映射和點號映射。
三層協議定制機制模型的實現,主要與水利數據采集系統的具體功能、協議和開發語言有關,可以采用兩種編程結構來實現,適用于匯編、C語言的多表分析結構和適合使用C++、C#和Java等高級語言實現的單表映射結構。由于篇幅有限,本文只詳細介紹了單表映射結構的實現細節。
這個編程模型根據三層協議定制模型的結構圖,將整個協議定制機制模型的實現通過三部分來實現,標簽行為表,標簽數據表和標簽映射表(協議結構表),結構框圖如圖5所示。

圖5 協議定制機制多表分析編程結構
標簽行為表:水利數據采集系統具體功能在協議上的表述,一般為多個操作碼的組合,例如水利數據采集器的定時報功能可以用通信協議中的時段報操作碼+當前報操作碼來表示。
標簽數據表:水利數據采集系統具體功能,在協議規定下所應包含的采集數據,如在定時報下需要上傳水位、雨量、電池電壓等數據。
標簽映射表:根據標簽行為表和標簽數據表的組合將會得到一個由系統具體功能所決定的數據段組合,在按照標簽數據的映射關系將其轉換成協議所規定的編碼,最后形成有系統功能所決定的編碼數據——協議數據。
在編程實現時包含兩個部分,將上述的多表分析編程模型作為一個整體,以系統具體功能作為索引,建立一個系統功能索引表即可實現整個操作;在接收數據時,過程與上述的過程相反。在使用匯編語言或C語言實現時,建立表格應適當保留存儲位置以備系統擴展使用,當上述表格變為動態標格,用戶可以通過設置輸入修改時即可實現協議的修改,增加新的標簽行為表、標簽數據表和標簽映射表即可實現新協議的加入。
這個編程結構根據三層協議定制模型的結構,將整個協議定制機制模型的實現通過兩部分來實現,標簽數據表和標簽解析庫。在這個結構中,以整個三層協議定制模型為對象,可以封裝成一個完整獨立的標簽類,該類以標簽數據作為類中的數據成員,標簽映射和標簽行為作為類中的數據操作,將該類進行編譯形成標簽解析庫。這種編程模型支持面向對象編程語言,特別適合在嵌入式系統上推廣。
與用戶交互的標簽設置界面如圖6所示。

圖6 與用戶交互的標簽設置界面
通過該界面的設置,使系統所用的標簽數據與標簽解析庫對應起來。在本系統中設置界面主要包括三部分,標簽數據列表,顯示系統所有的標簽數據;標簽數據屬性輸入區,主要包括原始數據的“傳感器名”、對應使用協議中的“點號”、傳輸數據時使用的“協議”、協議當中的“操作碼”、發觸發發送數據的系統行為“操作”和傳輸數據所使用的“數據類型”共6個文本輸入框;功能按鍵區,主要包括6個功能按鍵,“添加”增加標簽數據按鍵,通過該按鍵將標簽數據屬性輸入區的數據添加到系統標簽數據列表的最后一行,“修改”標簽數據按鍵,將在標簽數據列表中選中的標簽數據內容按照標簽數據輸入區的內容修改,“刪除”標簽數據按鍵,刪除在標簽數據列表中選中的標簽數據,后一行數據上移,“清除”系統所有標簽數據按鍵,“確定”修改并退出按鍵和不保留修改并“退出”按鍵。
如何對標簽數據進行處理將影響整個機制運行的效率,在本系統中,采用了自定義格式文件的方式來處理標簽數據,由于文件的格式是自己定義的,所以在處理時完全可以采用格式化語句處理,所有的處理語句都是唯一的,既提高了標簽數據的讀和存的速度,又充分使用了Windows Ce操作系統所提供的高效API,提高了整個機制的運行效率。
標簽解析庫的實現主要包括三部分:初始化、數據發送和數據接收。標簽解析庫運行時,首先調用標簽解析庫初始化函數,該函數的主要功能是將系統的標簽數據存成6個映射表,是原始數據名和點號映射關系的N-T映射表,表示數據采集系統行為和數據名的O-N映射表,表示數據采集系統行為和協議模塊的O-P映射表,表示數據采集系統行為和操作碼的O-C映射表,表示操作碼和點號映射關系的C-T映射表和表示原始數據類型和開發語言對應數據類型的映射關系的D-T映射表。
系統在發送數據時,首先通過O-N映射表查找對應的原始數據名,根據原始數據名準備數據,數據準備好后通過O-P映射表查找對應協議并加載協議模塊,模塊加載后通過N-T映射表將原始數據的數據名+數據轉換成點號+數據的形式,通過O-C映射表來確定數據打包所用的操作碼組,通過C-T映射表來確定與操作碼有映射關系的點號組,通過O-C和C-T映射表最終實現行為數據和點號數據的映射O-T映射,之后通過D-T映射來確定數據所使用的數據類型,并按照O-T映射關系來將數據進行編碼,最后將編碼數據通過通信設備發往中心站。
在數據發送的映射邊實現過程中有兩個數組,分別為操作碼組和點號組,它們不但包含元素的個數還決定元素的順序,對于發送一些對數據發送順序和數量有限制的數據非常必要。數據接收與數據發送的過程類似,這里就不在闡述了。
在遙測站端添加新數據Water2,點號設為82,數據是浮點數,通過SMS協議傳送,在平安報和定時報時將數據通過遙測站傳到中心站,按照本文所述方法其設置界面如圖7所示。
點擊添加按鍵,該數據就會出現設備標簽數據表的最下端,點擊確定按鍵,運行整個系統,把系統時間調到平安報或者是定時報時間,在中心站觀察遙測站數據,可以在遙測站上傳的平安報數據和定時報數據中觀察到數據Water2。
在遙測站終端增加新協議PPP,將遙測站終端的Water(點號56,操作碼07,浮點數)和Rain(點號67,操作碼08,整型數)數據在平安報時通過PPP協議上傳到中心站,其標簽設置界面如圖8所示。
點擊確定按鍵,退出標簽設置界面;按照協議規定和本技術方案規定的編程指導編寫PPP.dll,并將其下載到遙測終端Proc目錄下,運行要測站終端系統,將系統時間調整到平安報時間,等待遙測終端數據發送完畢,在中心站觀察數據,可以在遙測站的平安報數據報文中看到按照PPP協議打包的Water和Rain數據。

圖7 添加新數據設置界面

圖8 增加新協議標簽設置界面
按照本文描述的三層協議定制機制模型,可以很方便地在原有協議數據的基礎上增加新的協議數據,增加新的協議,標簽設置+協議解析庫。整個模型概念清晰、結構簡單,無論是在原有的協議數據上增加新數據,還是在水利數據采集系統中增加新協議都可以通過第三方實現,讀者只要熟悉本文提供的概念和本文提到的編程指導就可以很容易地在使用了本文提到的三層協議定制機制模型的設備上開發出新協議,增加新數據。
本文在描述三層協議定制機制模型的原理和結構時,所使用的數據結構和描述方法都是基于標準C實現的,因此本文提到的實現方法可以在任何支持C語言的硬件設備或者是終端上實現,非常適合在其他領域推廣;本文實現的二元協議定制機制運行可靠、擴展性強、加入新協議時開發周期短、指導性強、代碼復用率高、開發模式先進,非常適合在一些需要團體開發的大型項目中應用。本文提到的方法已經在實際產品中使用,取得了非常好的效果,很好地解決了水利信息化系統中多源設備的整合以及不同代產品的混合使用問題。
[1] 王兵,李存斌,陳鵬,等.EVC高級編程及其應用開發.北京:中國水利水電出版社,2005.
[2] 華清遠見,嵌入式培訓中心.Windows CE嵌入式開發標準教程.北京:人民郵電出版社,2010.
[3] (美)微軟公司,著;希望圖書創作室,譯.Microsoft Windows CE設備驅動程序開發指南.北京:北京希望電子出版社,1999.
[4] 張冬泉,譚南林,王雪梅,焦風川. Windows CE實用開發技術.北京:電子工業出版社,2006.
[5] 孫增義,吳躍.水情自動測報技術基礎及其應用.北京:中國水利水電出版社,1999.
[6] 毛學工,安波,蹇德平,陸玉忠.雅礱江流域梯級電站水情自動測報系統.北京:中國水利水電出版社,2012.
于興晗(1975—),男,碩士,工程師,主要研究方向:檢測技術及自動化裝置,32位嵌入式數據采集器,WIFI智能傳感器。E-mail: 13601009217@126.com
Design and Implementation of a Multi-protocol Switching System
YU Xinghan,GAI Youpu,HOU Yu,GUO Yi
(China Institute of Water Resource and Hydropower Research,Beijing 100038,China)
This paper introduces the design and implementation of a three layer protocol customization mechanism model can modify the protocol and add new protocol,clarify the relevant principles and key technology of three layer protocol customization mechanism model in detail,introduces two kinds of programming structure,single table mapping structure of multi table analysis structure and suitable for C++,C# and Java high level language for the compilation and C language.This paper introduces in detail the process of mapping using single table structure development of three layer protocol customization mechanism model in embedded system Windows Ce in practical engineering,to a certain extent solved solve mixed integrated multi-source equipment water information system and different generation product use problems.
protocol customization;embedded;multi scale analysis;single table mapping