實時監控程序的實驗室快速調試開發

蔡文齋

（中國電子科技集團公司第三十九研究所 陜西 西安 710065）

實時監控程序的實驗室快速調試開發

蔡文齋

（中國電子科技集團公司第三十九研究所 陜西 西安 710065）

提出了航天測控工程中實時監控類應用軟件開發中的仿真調試幾種方法，該文主要展示了一種內嵌在監控程序本身的窗口調試法，該方法使用一個獨立的十六進制編輯窗口發消息方式代替某接入計算機的硬件傳感器，在實驗室內可完全仿真出硬件通訊時的環境，可靈活地按協議給出硬件傳感器發送給計算機的定長信息，從而可無硬件環境下調通整個監控系統，一旦硬件配件接通，協議級的通訊亦隨即完成。

復雜控制系統 仿真調試 測控工程 線程 事件

1 引言

航空、航天和電子等領域內實時監控系統通常由若干計算機，一大堆相關板卡構成一個硬件環境，通常在Win32環境下編制相關的監控軟件，假定已知了相關的硬件需求和相應的軟件通訊協議后，可否在實驗室內無硬件設備時完全開發出全套監控系統軟件，文章提供的方法即為此目的而設計[1]。承研單位的監控軟件在Windows xp環境下使用C++或者Delphi開發。通常的做法是，開發人員等到買到各種相關板卡后再逐個調試各端口，當設備全聯在一起時統一聯調，通常聯調時很費時費力，要求各設備或者分機配合一塊調。文中提出的方法是：在實驗室內，無需連接各板卡，同樣可以仿真出這些硬件設備開發出整個監控軟件，等到各種板卡到位后，再添加這些板卡的設備初始化及I/O函數。這樣，在實驗室內，整套監控軟件在無硬件環境下可以提前編制完成。作者在組織項目中監控軟件開發時，工程中使用的板卡因為種種原因未能夠及時到位，但工程任務時間要求緊，如果等到各板卡到位再編制監控軟件時，那么整個進度將無法保障。作者使用監控程序內加調試支持方法巧妙解決了這類問題。

2 工作原理

假定不考慮接入計算機的某板卡接口形式，不考慮具體的某硬件傳感器的特性，僅從抽象的角度考慮，那么可以將接入的任一硬件傳感器都視為一流設備，這些硬件設備通過相關板卡與計算機聯在一起，計算機與這些板卡的通信就是一串十六進制碼字的交換，任一硬件的讀入形式經抽象化后都是一樣的。比如如下的某航天測控類應用項目：該項目是一雷達測控站，控制計算機要外接的硬件具體設備，如圖1所示，計算機經接口板卡與硬件設備的連接示意圖如圖2所示。

圖1 工程硬件結構圖

圖2 數字計算機接口圖

任一接入控制計算機的硬件設備與計算機通訊本質上是一定長的十六進制字符碼字的雙向信息交流，在程序中即為讀寫函數Read與Writ函數[2]，無論硬件接口形式是什么,最終抽象的讀寫參數是一樣的：設備號、讀寫緩沖區數據內容、讀寫長度、實際讀入或者寫出的長度及回送的狀態碼字。例：

Ret=ReadAny(HardNum:integer;設備號

Const Buffer;緩沖器

ReadLength);欲讀入的長度

Ret為實際讀入的長度，也表示回送的狀態碼字，寫出函數同理。姑且不論某一硬件傳感器是怎樣初始化及怎樣使用的，一般相關板卡均帶有驅動程序，在Win32環境下通常是通過驅動程序提供的API函數訪問硬件，雖然各硬件的訪問形式有所差異，但計算機訪問的機制卻是相同的。

該法的要點為：在監控程序端加入用戶讀硬件消息機制，加消息調試機制；再使用某方法設計一個十六進制編輯器作為仿真器使用，發出這些消息，并且將這個十六進制編輯器的內容復制為你的欲調試的某硬件讀緩沖區內容，這樣使用該仿真器即代替了某具體硬件設備。

監控軟件一端加接收消息機制，首先定義用戶消息，這些消息為：某硬件傳感器讀到數據的消息，例如你的系統共有6路接口的硬件設備，定義6個讀用戶消息，消息函數功能為：將讀到的硬件數據緩沖區解碼，抽象化這樣傳感器將其視為一組緩沖區，監控軟件本身就是對某硬件傳感器緩沖區的加工處理，假定這個緩沖區內容已經具備，相當于你已經讀到了硬件內容，仿真的方法就是構造這個你欲想得到的緩沖區內容。監控軟件一端加調試支持機制，在某個用戶讀消息中（調試接口，例如上例中6個消息之1），加如下代碼：如果調試A硬件，則復制由仿真器傳來的緩沖區內容到A讀入緩沖區，再發送A硬件讀完成消息給你的監控程序窗口。

如果調試B硬件，則復制由仿真器傳來的緩沖區內容到B讀入緩沖區，再發送B硬件讀完成消息給監控程序窗口等。仿真器構造這個緩沖區內容ComBuffer，并且發特定的消息給監控程序窗口，這樣無需要硬件傳感器本身接入，只要知道通信協議即可開發出全套監控軟件。

3 純軟件仿真方法的實現

仿真器可以使用多種方法構造：①使用串行口調試器作為仿真器[3]；于使用網絡調試器作為仿真器[4]；③使用進程通信方法作為仿真器[5]；④單進程方法[6]，在監控程序中，內嵌一個單獨的窗口，在該窗口內編寫一個十六進制編輯器作為仿真器[7]。

第①和于方法就是開發出一套仿真硬件調試器，比如串口調試器和網絡調試器等，這樣在實驗室內可快速調試出整套監控系統。這些調試器網絡上已經有下載的程序了，或者自己寫這些調試器，無論怎樣，在監控程序中要寫接收代碼。

第③種方法為：設計一款基于進程通訊技術的綜合調試器，該調試器實際是一款十六進制輸入編輯器。代表一串硬件信息流，比如com2口讀入的信息，再使用進程通訊技術使該調試器將這一串信息傳給監控軟件。在監控軟件一端，程序同樣要使用進程通訊技術接收由調試器發來的信息，達到仿真某硬件傳感器讀入信息的目的。進程通訊方法有多種形式，作者使用多種技術手段曾寫出了這款綜合調試器，使用多種進程通訊技術傳出數據，亦使用多種內核技術通知數據的變化，效果頗佳。該法的優點是你可以深入到WINDOWS內核級編程，學習到高深的進程間通信方法[4]，缺點是這一大堆內核對象技術及進程之間的通訊方法對初學者有一定難度。

第④種方法為：直接在監控軟件本身內置一個仿真器，同樣可以達到無硬件環境調試出全套軟件的目的。

其中任一款調試器都可以作為通用調試器使用，關鍵部分在改造監控程序本身部分，你的監控軟件需要具備調試支持功能，在任一硬件的設備讀完成語句后加讀完成消息機制。

4 監控程序改造，使之具備可調試功能

首先將監控軟件本身稍作改造，使其具備調試支持功能。無論具體硬件傳感器是什么形式，比如是一款GPS導航設備通過串行口往計算機送出位置信息，形式化的硬件訪問函數一般為幾句：①設備打開；于設備讀；③設備寫；④設備刷新；5設備關。這些函數一般由商用板卡廠家依DLL形式提供，但串行口和網絡通訊用的函數卻由Windows API提供。該文重點在于調試方法，在監控程序內，設計一種通知機制，當每種硬件傳感器讀語句執行完成，發一用戶定制的消息給主窗口，告知該主窗口由線程或者回調函數業已完成硬件信息讀。在對應的消息處理函數中，完成信息解碼，表示該設備讀完成并且在該消息函數中加工數據。有了這樣一種機制在后臺工作后，假定需要調試COM12串行口，只要從什么地方能夠發出COM12對應的消息就相當于COM12讀到了數據。如果將調試器的輸入內容作為比如com12口的讀入內容，而由該調試器發這一用戶消息給主窗口，主窗口分不出到底是由具體的com12口硬件設備發出或者由調試器發出，這樣就達到了以假亂真的效果。

無論監控程序使用什么語言編寫，無論讀入時序怎樣安排，為了達到仿真調試目的，將監控程序改造如下：設計若干讀入完成消息，在每個硬件傳感器讀入函數完成后，發一用戶特定的消息給前臺窗口，告知該設備讀已完成；讀入完成消息處理為：對讀入緩沖區解碼,將緩沖區某某位置的十六進制碼字按照通訊協議變換為監控程序使用的變量，提供給監控程序使用。設監控程序為A窗口，仿真硬件程序為B窗口。

A窗口要接收B窗口數據，并且B窗口數據變化時應立即通知給A窗口，那么問題變為：通知和復制變化數據。A窗口的調試方法：假定要調試串行口12，首先假定已經編寫了com口讀寫線程（注意此時無硬件，com12打不開，無法跟蹤[6]），假定你的監控程序已經具備了調試支持功能（用戶消息），當每個硬件傳感器讀完成后都會發一對應的讀完成信息的。那么只要在什么地方發出該消息，就相當于已經讀入了該硬件數據。試設想一下，如果讀入緩沖區的每一位都可控制輸入，那么在實驗室內就仿真了所有實際的通訊情況，將節約大量時間在設備聯調階段，因為在聯調時，只有對方開機運行他或者她的程序時你才能調程序。

假定開發者設計的監控程序需要調試16個串行口，2個網絡設備，4個A/D設備，48路I/O設備等等，此時假定需要的多串行口卡，A/D卡等等還沒有買到，那么使用一款網絡調試器來調試整個監控程序：注意只有一個輸入，網絡讀，監控程序首先要完成網絡讀部分，下面介紹怎樣調試串行口12，在網絡讀函數完成后，將網絡讀入的緩沖區內容復制到串行口12的讀緩沖區中，網絡讀中再加一句代碼，發送串行口12讀完成消息給主窗口，這樣就騙過了串行口12的讀完成語句；此時，串行口12可能還不能夠使用（設備未到位），但開發進度并不受影響，串行口需要的數據來自于網絡調試器，通知來自于網絡讀消息，在網絡讀函數中，改造上2句代碼成其他設備，將順次調試完你所有連入系統的硬件設備。假定監控程序已經具備了上文中的調試支持功能，那么可以在實驗室無硬件環境下完全調試處整套監控軟件。形式化的偽代碼為：

MemoryCopy(ComBuffer12,NetBuffer,Ret);//將網絡緩沖區內容復制到串行口12的讀緩沖區；PostMessage(窗口句柄，WM_COM12_READ,0,0);//發送串行口12讀完成消息給前臺窗口；}，到此為止，相當于網絡讀到的數據已經復制給串行口12的緩沖區，發送消息表示串行口12讀到了數據，將內存復制與發送消息語句改為其他緩沖區和其他消息則可以調試其他任一設備。}

5 硬件緩沖產生器設計

硬件緩沖產生器的設計方法為：在開發控制程序時，設計一款內置的小型調試器，該調試器實際就是一個小型的十六進制編輯器，在加發送特定消息的功能。使用軟件開發一個十六進制編輯器代替硬件，在這個編輯器界面上使用消息通知機制告知監控程序硬件讀數據已經準備好。

下面使用Delphi展示這個調試器設計[7]。在監控軟件工程文件中，設計一Form，該Form內設計兩部分輸入：一部分允許十六進制輸入，一部分允許浮點數輸入，十六進制輸入使用Stringdrid組件，浮點數輸入使用Edit組件即可，下面主要介紹十六進制編輯器及調試方法具體實現。

設計一StringGrid，兩行256列（0～255），調整格子大小及相應組件屬性：重載該StringGrid的CellEdit消息，該消息用于檢查是否為十六進制輸入，這樣就編寫了一款十六進制輸入的簡易編輯器，

設計一按鈕組件，該按鈕方法為：（界面中需要加一組RadioButton組件用于控制發送什么消息，例如COM1，COM2，…,A/D,…）,依據控制開關發送不同的消息。

將十六進制的字符串格子內容Copy到某具體預調試的讀入緩沖區內，發用戶定制的某具體硬件傳感器讀已完成消息。這樣監控程序就誤以為讀到了某具體硬件傳感器數據了，而且每一位都可以編輯，按通訊協議就可以很快調試出監控程序到底編寫正確與否，調試方法示意圖如圖3所示。

6 動態數據的仿真調試方法

上述各仿真器給出的方法特別適合于調試通信中每一位的變化這種情況（假定從緩沖區第2子節到第12字節每一位表示不同的物理硬件設備狀態，設想一下，你的程序將有80種判斷要處理，10 Bytes，每字節8位），實際工程中另一種情況為浮點數的表示，浮點數常使用以下幾種表示法(通信時都是一串十六進制的數據)：

A:通信雙方自己規定表示方式

B:直接使用計算機本身規定的方式放置數據

對A表示法，需要通信雙方寫置碼，解碼函數；對B方法，通信雙方將這幾個字節使用內存對齊技術引用即可，delphi語言中使用Absulute技術[8]，C++語言中使用聯合Unite技術[9]；這樣不用編寫轉換函數；注意Windows系統與UNIX系統放置數據通常是倒置的，高低字節調整即可；

在實際工程中，通訊中經常碰到這樣一種情況，讀入某些字段是一組動態數據（比如彈道曲線x、y和z），帶驅動的監控軟件希望由一組動態數據支持程序運行，以便測試程序整個控制過程正常否，下面介紹這樣一種情形的仿真調試：假定彈道由基地中心的網絡傳送，網絡傳送字節長度為64，從第12字節開始，每4 Bytes代表一彈道數據，分別為x、y和z，低位在前，高位在后。

在仿真Form中，設計另一按鈕，按鈕消息為：

圖3 調試方法示意圖

打開某文本文件（該文件代表彈道數據，設計為文本優點在于文本文件可以靈活改變數據，便于置入異常數據測試，測試監控軟件是否具備異常處理功能），讀入文件后將文本中的字符串轉換為浮點數分別存貯在3個數組中XA、YA和ZA中，在仿真界面上，設計一個Timer組件，間隔為100 ms，再設計一cheekbox組件，使用cheekbox設置時鐘組件Timer的開或者關，重載Timer消息：當Timer開時，從數組中取一組值，數據序號設計為全局控制量integer型，每次序號加1，這樣下一個Timer消息到來時正好達到數據下一組數據，當這一浮點數按通訊協議再轉換為DWORD放置在發送網絡設備緩沖區的第12字節開始處（這樣就代表了動態x、y、z），Timer消息最后一句為PostMessage()[10];向主窗口發送網絡讀完成消息，這樣主窗口就相當于接收到了一組動態網絡數據。監控程序運行時只要在仿真界面Form中打開Timer組件開關，就完全仿真了動態數據讀入過程，其他設備調試方法同理。

7 結束語

航空、航天和電子類實時控制軟件因其特殊性，經常由幾個研究單位共同開發各自的監控系統再進一步傳給上一級的監控系統，這種系統可能有多級，控制系統聯調是個很繁雜的工作，既費時間又要求其他分系統人員互相配合，該文提供的方法使得開發者在實驗室內，使用很短時間開發出全套監控軟件，為后續聯試節約大量時間，因為按協議的通訊全提前解決了。如果將該類問題擴展之，任一個業務邏輯都會碰到該類調試問題，開發者使用上文的機制改造應用軟件，再設計自己的調試器在應用軟件內，雖然在初期寫了多余的調試代碼，但在后期聯合調試時將節約大量的時間。

[1](美)溫伯格.完美軟件—對軟件測試的各種幻想[M].北京:電子工業出版社,2009:56-63.

[2]RICHTER J.Window高級編程指南[M].王書洪,劉光明,譯.北京:清華大學出版社,1999:236-243.

[3]趙蘭濤,蘇彥華.DELPHI串口通信技術與工程實踐[M]. 2004:80-87.

[4]王艷平.Windows網絡與通信程序設計[M].北京:人民郵電出版社,2009:153-160.

[5]JEFFREY J,CHRISTOPHE N.Windows核心編程[M].葛子昂,周靖,廖敏,譯.北京:清華大學出版社，2008:270-276

[6]吳天準.Delphi 7程序設計技巧與實例[M].北京:中國鐵道出版社,2003:77-82.

[7]劉山,趙輝.Delphi系統開發實例精粹[M].北京:人民郵電出版社,2005:172-175.

[8]梁冰,李鐘尉,呂雙.Delphi技術方案寶典[M].北京:人民郵電出版社,2008:260-264.

[9]譚浩強.C程序設計[M].北京:清華大學出版社,2005: 153-160.

[10]范文慶,周彬彬,安靖.精通Windows API--函數接口編程實例[M].北京:人民郵電出版社,2009:223-250.

Rapid Debugging and Development of Real-time Monitoring Program in Lab

CAI Wen-zhai
(The 39th Research Institute of CETC,Xi’an Shaanxi 710065,China)

This paper proposes the several simulation and debugging methods of real-time monitoring application software development in Telemetry,Track and command(TT&C)project,and mainly introduces a window debugging method embedded in the monitoring program.This method uses an independent hexadecimal edit window message mode to replace a hardware sensor accessed to the computer,completely simulates the hardware communication environment in the lab,and flexibly gives the fixed length information send by the hardware sensor to the computer according to protocols,in order to debug the whole monitoring system without hardware. Once the hardware components are connected,the communication at the protocol level is immediately completed.

complex control system;simulation debugging;TT&C project;threading;event

TP39

A

1008-1739（2015）02-58-5

定稿日期：2014-12-26