丁 昊，段曉沛，高 昂，趙玲瑜，康曉華

（1.解放軍95806 部隊，北京 100076；2.空軍參謀部檔案館，北京 100076）

0 引言

兵要信息源自于中國在吏制時代關于戍邊和海防的資料［1］，隨著我軍大力推進軍隊信息化建設，傳統(tǒng)的兵要信息概念已不能涵蓋目前兵要信息所包括的內容和涉及的技術。為適應信息化作戰(zhàn)環(huán)境，由兵要地志發(fā)展而來的綜合兵要信息成為描述陸上、海域、空中多維戰(zhàn)場環(huán)境特征的一種數據集［1］。

綜合兵要信息是基于地理信息技術，對多源戰(zhàn)場環(huán)境信息整合和空間描述的數字化軍事測繪保障產品，從20 世紀90 年代開始，我軍逐漸建設關于綜合兵要信息的應用系統(tǒng)，其數據的獲取、整合與加工、數據質量控制、數據存儲與管理、信息服務等須以數字地圖、地理信息、網絡等現代技術為支撐?；跀底值貓D的兵要信息可以快速定位兵要實體的空間位置，便于指揮員迅速建立空間概念關系，為研判態(tài)勢、作戰(zhàn)指揮決策、部署兵力火力等提供基本依據；能夠形成覆蓋各種作戰(zhàn)區(qū)域、聯通各類要素信息的戰(zhàn)場綜合態(tài)勢，便于迅速形成對戰(zhàn)場環(huán)境的全面認知與綜合掌控［2］。

隨著我軍信息化程度的提高，服務化逐漸成為我軍信息化建設的主要方向，目前，我軍正在大力推進服務化、國產化的信息集成平臺，目前基于單機的綜合兵要信息構建技術已經不能滿足我軍系統(tǒng)建設發(fā)展的需要，需要針對綜合兵要信息服務展開研究。

1 目前綜合兵要信息應用存在問題

目前綜合兵要信息應用主要存在兩個方面的問題，一是系統(tǒng)設計方面，綜合兵要模型設計二次開發(fā)接口不完善，與地理信息平臺耦合度大；二是保障模式方面，單機版系統(tǒng)部署與數據綁定，信息互聯互通困難。

1.1 目前綜合兵要信息系統(tǒng)應用設計存在的問題

目前的綜合兵要信息系統(tǒng)設計主要是基于局域網C/S 部署模式，支持主流的商用關系數據庫和文件訪問模式。具體實現方法為：依托某一地理信息系統(tǒng)平臺，由于綜合兵要信息數據的結構特點（一個兵要實體數據包括一條屬性數據，多條幾何數據以及若干條媒體數據），將某類兵要實體抽象為關系數據庫中的三張表（同理，文件存儲方式也是分成不同類別的文件分開存儲），一張表用來存儲幾何數據，一張存屬性數據以及一張表用來存儲多媒體數據，不同表間的同一兵要數據通過ID 相關聯，這也是綜合兵要數據與傳統(tǒng)的基礎地理數據組織方式略有區(qū)別的地方［3］。因此，目前的綜合兵要信息系統(tǒng)的數據結構設計僅僅是基于地理信息系統(tǒng)的模型結構進行簡單擴展。

圖1 目前綜合兵要信息訪問引擎架構

基于以上結構特點，圖1 描述了目前主要兵要應用引擎的架構設計，該引擎是基于原有的地理空間數據引擎適配設計，具有綜合兵要信息查詢、統(tǒng)計分析、報告制作以及用戶權限控制等多個功能，同時支持文件以及多種商業(yè)關系數據庫的數據存儲方式，具有一定的靈活性和可擴展性。存在的主要問題是：一是二次開發(fā)層面提供的開發(fā)接口不夠友好，用戶進行二次開發(fā)時需要了解兵要數據的底層存儲細節(jié)；二是兵要數據引擎設計與地理信息平臺緊密耦合，一旦底層平臺發(fā)生改變，引擎需要重寫。

1.2 目前綜合兵要信息保障模式存在的問題

1.2.1 基于單機版的查詢應用模式缺乏多樣性

綜合兵要信息具有空間特征多樣、結構復雜、屬性結構不一、關系復雜等特點，其數據之間不僅存在空間拓撲關系和屬性關系，同時還包括空間關聯關系以及大量的媒體信息。目前的綜合兵要信息訪問主要是通過屏蔽數據存儲、查詢、分析和管理的復雜性，將兵要信息的屬性、幾何與媒體信映射為數據庫中的若干關系表，并抽象訪問接口，進行統(tǒng)一訪問。展現方式主要包括空間關系展示（在基礎地理信息圖層上疊加專題兵要信息）、二維圖表類結構化展示（網頁或者表單）、統(tǒng)計圖表展示（統(tǒng)計圖表）。

基于單機版的查詢應用主要問題在于：一是無法整合多源數據進行聯合分析，由于數據在單機預裝，無法對其他來源數據進行聯合分析；二是查詢分析功能固化，展示界面與分析功能綁定，一旦研發(fā)完成后，無法針對不同的應用案例定制可視化方案。

1.2.2 數據保障模式越來越不滿足軍事應用的需求

我軍目前的兵要信息保障基本上是以指揮所和武器平臺為中心的數據分散部署模式，滿足局域網和單機使用環(huán)境，用戶在哪里、指揮所開設到哪里，兵要數據就要部署到哪里，并且不支持以服務化的方式提供兵要信息應用，難以滿足作戰(zhàn)指揮和武器應用實時性要求，不能實現分散部署的兵要信息數據的同步更新共享和一致性維護；同時，非服務化緊耦合的兵要信息系統(tǒng)技術體制，僅能滿足預先定義用戶和功能的應用案例研發(fā)方式，無法滿足我軍多樣化任務對兵要信息應用的需求。

2 綜合兵要信息服務應用總體設計

基于以上存在問題，本文主要從綜合兵要信息模型設計與應用架構兩個層面，對目前的綜合兵要信息應用系統(tǒng)進行重構，主要解決模型設計層面上與地理信息平臺耦合度大、移植性差、開發(fā)接口設計不完善等問題，和應用層面上兵要信息的保障模式落后的問題。

圖2 結構化展示

2.1 綜合兵要信息模型設計

本文設計的綜合兵要信息應用總體定位是可重用、可擴展，并具備可移植等特性。通過參考目前各種商用地理信息系統(tǒng)和軍事地理信息系統(tǒng)的架構設計，抽象中間層并設計綜合兵要信息模型。該模型具備在各平臺之間移植，具備松耦合的特點。本文設計的綜合兵要數據模型是基于地理信息系統(tǒng)提供的接口進行二次開發(fā)，因此，總體目標是在模型設計上對地理信息系統(tǒng)中的對象進行封裝與聚合，使設計的兵要對象具備良好的封裝性和重用性，同時提供給應用層接口要粒度恰當，便于使用。

圖3 統(tǒng)計圖表展示

兵要數據的主要組織方式是目錄樹，大類里面包括小類，最底層的葉子節(jié)點表示具體的兵要類別。大類與小類的父子隸屬關系主要通過兵要編碼來標識，因此，在兵要引擎的設計上，要體現目錄樹的組織方式，用戶通過目錄樹訪問某一類兵要實體，通過目錄樹某一類兵要節(jié)點和兵要ID 訪問具體的兵要實體。

圖4 綜合兵要信息模型設計

圖4 中，綜合兵要模型設計主要包括兩個部分，上半部分為兵要數據訪問部分，下半部分為兵要目錄樹部分，兵要數據訪問部分與各地理信息系統(tǒng)平臺耦合度比較大，可針對各種地理信息平臺實現，針對各類主流地理信息平臺編譯動態(tài)庫，向上層兵要數據目錄部分提供抽象的訪問接口。當需要在不同地理信息平臺間進行移植時，只需要替換兵要數據訪問動態(tài)庫即可實現。兵要數據目錄訪問部分是兵要數據查詢檢索的核心模塊，根據綜合兵要信息的樹狀結構，以及兵要數據的分類編碼進行查詢檢索。

系統(tǒng)啟動時，根據兵要數據配置文件，通過CBY_SSTree 全局靜態(tài)變量在內存中初始化目錄樹結構。數據訪問部分入口是BY_LayerAdapter，針對不同的地理信息平臺，實現不同的BY_LayerAdapter，并向外提供IBY_LayerAdapter 接口，對上層屏蔽不同平臺的差異。需要提取某類兵要實體時，先通過CBY_SSTree 獲取某類兵要實體的編碼信息，然后通過兵要數據訪問接口到數據庫中查找數據，并構造數據樹CBY_Dtree，最終獲得的BY_Entity 是兵要實體對象的封裝。通過以上結構設計，以面向對象的方式訪問兵要實體，保證功能的封裝與重用［4］，同時也兼顧了各地理信息平臺間的移植性［5］。

2.2 服務架構設計

兵要信息的單機應用是制約綜合兵要信息保障效率提升的主要原因，基于服務化的綜合兵要信息系統(tǒng)改造是提升綜合兵要信息保障效率的關鍵。綜合兵要信息服務架構設計主要包括綜合兵要信息數據服務和綜合兵要信息功能服務兩大模塊，數據服務是通過對兵要數據引擎模塊進行調用，將關系數據庫或者文件系統(tǒng)中的數據封裝適配成抽象的兵要實體，通過服務層將兵要實體序列化為XML或者JSON 格式返回給用戶；功能服務是將兵要數據應用的相關功能，根據不同的業(yè)務需求封裝若干功能服務接口提供給應用層。本系統(tǒng)在實現上，兼顧了不同層次、不同粒度的開發(fā)用戶的需求。開發(fā)用戶既可以直接針對兵要引擎進行二次開發(fā)，也可以通過應用層提供的兵要信息服務進行兵要數據的獲取和展現，具體細節(jié)如圖5 所示。

圖5 綜合兵要信息服務架構設計

兵要信息訪問引擎部分在技術實現上采用的是C++語言。由于java 在網絡應用中的優(yōu)勢地位，以及各種開源web 服務器都廣泛對java 語言支持，本系統(tǒng)在服務發(fā)布模塊采用java 語言編寫，因此，在中間層需要實現兩種語言的互相調用功能。本系統(tǒng)采用的是jna 第三方庫，jna 庫支持java 語言直接調用C++對象的方式。

針對某類需要查詢的兵要實體，本系統(tǒng)流程如圖6 所示：

1）獲取某個兵要實體唯一編碼，調用兵要信息查詢服務接口。

2）j2ee 平臺的java 對象調用jna 包裝的C++接口。

3）jna 對象調用兵要引擎接口。

4）兵要引擎接口調用地理信息平臺數據訪問接口。

圖6 查詢兵要實體流程圖

5）平臺返回組成兵要實體的三大類信息（屬性對象、幾何對象集、媒體對象集）給兵要引擎。

6）兵要引擎將三大類對象組裝成兵要實體（BY_Entity）。

7）調用jsonlib 將兵要實體序列化json 文本并調用jna 對象。

8）jna 對象調用j2ee 平臺的java 對象。

9）j2ee 平臺返回給用戶兵要實體的json 文本。

3 綜合兵要信息過濾關聯規(guī)則的實現

兵要數據結構復雜，屬性豐富，而且還包含大量的媒體信息，客戶端的定制化設計中不需要展現給用戶與其無關的信息。精煉的信息表達能讓用戶一目了然，并且使用戶迅速掌握數據的要點并進行決策。

系統(tǒng)研發(fā)人員往往對數據結構比較了解，可以針對數據進行信息過濾，而系統(tǒng)用戶只知道需求是什么，但不知道如何實現信息過濾，因此，系統(tǒng)研發(fā)人員需要和用戶反復溝通，協(xié)商需求。往往系統(tǒng)研發(fā)定型后再進行修改是非常麻煩的，因此，本文在某些規(guī)則的設計上采用了模板配置的方式，把具體的配置工作交給用戶，一旦用戶需要修改界面顯示，只需要針對某一兵要類別規(guī)則進行修改即可，不需要重新修改軟件。

在規(guī)則設計上，采用規(guī)則繼承方式。每類兵要數據都有相應的規(guī)則文件（通過類別碼標識，也稱子類），而所有兵要類別都繼承一套共同的規(guī)則（也稱基類），所有規(guī)則文件都放置在一個公共配置文件中，如某類兵要數據需要特別的規(guī)則設置，則特別設置的規(guī)則會替換公共規(guī)則，這種規(guī)則繼承的方式方便用戶擴展。比如圖7 中的flm 為000000 的規(guī)則為基類規(guī)則，而下面為具體某一類兵要層的顯示規(guī)則。

綜合兵要信息規(guī)則控制主要包括兩大類：顯示規(guī)則與關聯規(guī)則。針對顯示規(guī)則類，圖7 中規(guī)則文件的多媒體數據表達規(guī)則段，是針對不同類別媒體文件的后綴判斷其是否顯示，有些沒有意義的媒體文件可以隱藏顯示；多要素屬性數據表達段規(guī)則是針對兵要數據屬性字段比較豐富，全部顯示會造成信息量與媒體載負量的失衡，通過規(guī)則控制可以篩選出用戶比較關注的字段予以顯示，方便用戶對信息的全局把握。

圖7 兵要數據規(guī)則配置文件（公共規(guī)則上、某類規(guī)則下）

關聯規(guī)則配置在空間關聯規(guī)則段中，主要目的是為了實現兵要實體的關聯查詢，實現各類兵要實體的網狀態(tài)勢關聯展現。每一條關聯規(guī)則主要包括3 個配置項：集合類型、空間關聯關系類型（如下頁表1 所示）以及關聯的另一個兵要類別碼。這種配置方式是讓用戶針對自己感興趣的專題，配置空間關聯規(guī)則。如下頁圖8 所示，當用戶查詢重要城市時，在關聯規(guī)則中可以配置流經重要城市的河流段有哪些，實現定制化的顯示配置。

表1 空間關聯關系列表

圖8 重要城市關聯查詢河流段

4 結論

綜合兵要信息系統(tǒng)是作戰(zhàn)指揮綜合信息庫的組成部分，是軍事測繪數據應用于作戰(zhàn)指揮的橋梁。以數字化戰(zhàn)場為基礎，綜合兵要地理信息系統(tǒng)在各級各類指揮自動化系統(tǒng)中起著將數字化戰(zhàn)場信息轉化為指揮人員所需要的形式，或指揮自動化系統(tǒng)所需要模式的重要任務。

本文根據我軍目前綜合兵要信息應用模式越來越不滿足現在戰(zhàn)爭數據保障模式的需求分析了目前綜合兵要信息保障模式的弊端，設計了綜合兵要信息邏輯模型與服務架構，針對模型設計實現了原型展示系統(tǒng)。目前該系統(tǒng)功能上還有很多地方疏于考慮，比如：如何管理服務，數據安全問題如何考慮，如何實現綜合兵要信息全文檢索，以及綜合兵要信息的可視化展示技術等。這些技術都有待于在今后的工作中繼續(xù)進行分析與探討。

圖9 重要城市類別查詢

圖10 多媒體查詢