综合兵要信息服务关键技术研究

Vol.46，No.2

Feb，2021

1002-064002-0133-06

文章编号：（

2021

）

火力与指挥控制

FireControl&CommandControl

第46卷第2期

2021年2月

综合兵要信息服务关键技术研究

丁昊

1

，段晓沛

1

，高昂

1

，赵玲瑜

2

，康晓华

1

（

1.解放军95806部队，北京100076；2.空军参谋部档案馆，北京100076

）

摘要：综合兵要信息是作战指挥综合信息库的组成部分，是军事测绘数据应用于作战指挥的桥梁。根据我军

目前综合兵要信息的应用模式越来越不满足现在战争数据保障模式的需求为背景展开讨论，分析了目前综合兵要

信息保障模式的弊端，设计了综合兵要信息逻辑模型与服务架构，针对模型设计实现了原型展示系统，旨在对综合

兵要服务应用方面做一点简单探讨。

关键词：综合兵要信息，UML，关联规则，地理信息系统

中图分类号：TP391.9文献标识码：ADOI：10.3969/.1002-0640.2021.02.023

引用格式：丁昊，段晓沛，高昂，等.综合兵要信息服务关键技术研究［J］.火力与指挥控制，2021，46（2）：133-138.

TheResearchonKeyTechnologyofInformationServiceof

ComprehensiveStrategicPassandTopography

DINGHao

1

，DUANXiao-pei

1

，GAOAng

1

，ZHAOLing-yu

2

，KANGXiao-hua

1

（

1.

Unit

95806

ofPLA

，2.

ArchivesofAirForceStaff

，

Beijing

100076，

China

；

Beijing

100076，

China

）

Abstract

：

TheinformationofComprehensiveStrategicPassandTopographyiscomponentsofbattle

commandintegratedinformationdatabase

，

anditisthebridgeformillitarysurveyingandmappingdate

nthebackgroundthatthecurrentapplicationmodeof

integratedmilitaryinformationinourarmycannotmeetingtheneedsofcurrentwardatasupportmode

，

thedisadvantagesofthecurrentComprehensiveStrategicPassandTopographysupportmodeare

analysed

，

thelogicalmodeandservicearchitectureofComprehensiveStrategicPassaredesigned

，

and

accordingtotheabovemode

，

theprototypedemonstrationsystemisdesignedandrealizedinorder

，

to

makeasimplediscussionontheapplicationofComprehensiveStrategicPassandTopography.

comprehensivestrategicpassandtopography，UML，associationrules，Geographicinfor-

Keywords

：

mationsystem

DINGH，DUANXP，GAOA，earchonkeytechnologyofinformation

Citationformat

：

serviceofcomprehensivestrategicpassandtopography［J］.FireControl&CommandControl，2021，46（2）：

133-138.

0引言

综合兵要信息是基于地理信息技术，对多源战

场环境信息整合和空间描述的数字化军事测绘保

障产品，从20世纪90年代开始，我军逐渐建设关

于综合兵要信息的应用系统，其数据的获取、整合

与加工、数据质量控制、数据存储与管理、信息服务

等须以数字地图、地理信息、网络等现代技术为支

撑。基于数字地图的兵要信息可以快速定位兵要实

体的空间位置，便于指挥员迅速建立空间概念关

兵要信息源自于中国在吏制时代关于戍边和

海防的资料

［1］

，随着我军大力推进军队信息化建设，

传统的兵要信息概念已不能涵盖目前兵要信息所

包括的内容和涉及的技术。为适应信息化作战环境，

由兵要地志发展而来的综合兵要信息成为描述陆

［1］

上、海域、空中多维战场环境特征的一种数据集。

收稿日期：2020-01-05

作者简介：丁

修回日期：2020-03-07

昊（1984-），男，湖北鄂州人，博士，工程师。研究方向：地理信息工程，军事情报。

·133·

（总第46-

0318

）火力与指挥控制2021年第2期

系，为研判态势、作战指挥决策、部署兵力火力等提

供基本依据；能够形成覆盖各种作战区域、联通各

类要素信息的战场综合态势，便于迅速形成对战场

环境的全面认知与综合掌控

［2］

。

随着我军信息化程度的提高，服务化逐渐成为

我军信息化建设的主要方向，目前，我军正在大力

推进服务化、国产化的信息集成平台，目前基于单

机的综合兵要信息构建技术已经不能满足我军系

统建设发展的需要，需要针对综合兵要信息服务展

开研究。

1目前综合兵要信息应用存在问题

目前综合兵要信息应用主要存在两个方面的

问题，一是系统设计方面，综合兵要模型设计二次

开发接口不完善，与地理信息平台耦合度大；二是

保障模式方面，单机版系统部署与数据绑定，信息

互联互通困难。

1.1目前综合兵要信息系统应用设计存在的问题

目前的综合兵要信息系统设计主要是基于局

域网C/S部署模式，支持主流的商用关系数据库和

文件访问模式。具体实现方法为：依托某一地理信

息系统平台，由于综合兵要信息数据的结构特点

一个兵要实体数据包括一条属性数据，多条几何

数据以及若干条媒体数据），将某类兵要实体抽象

为关系数据库中的三张表（同理，文件存储方式也

是分成不同类别的文件分开存储），一张表用来存

储几何数据，一张存属性数据以及一张表用来存储

多媒体数据，不同表间的同一兵要数据通过ID相

关联，这也是综合兵要数据与传统的基础地理数据

组织方式略有区别的地方

［3］

。因此，目前的综合兵

要信息系统的数据结构设计仅仅是基于地理信息

系统的模型结构进行简单扩展。

图1目前综合兵要信息访问引擎架构

基于以上结构特点，图1描述了目前主要兵要

应用引擎的架构设计，该引擎是基于原有的地理空

·134·

间数据引擎适配设计，具有综合兵要信息查询、统

计分析、报告制作以及用户权限控制等多个功能，

同时支持文件以及多种商业关系数据库的数据存

储方式，具有一定的灵活性和可扩展性。存在的主

要问题是：一是二次开发层面提供的开发接口不

够友好，用户进行二次开发时需要了解兵要数据

的底层存储细节；二是兵要数据引擎设计与地理

信息平台紧密耦合，一旦底层平台发生改变，引擎

需要重写。

1.2目前综合兵要信息保障模式存在的问题

1.2.1基于单机版的查询应用模式缺乏多样性

综合兵要信息具有空间特征多样、结构复杂、

属性结构不一、关系复杂等特点，其数据之间不仅

存在空间拓扑关系和属性关系，同时还包括空间关

联关系以及大量的媒体信息。目前的综合兵要信息

访问主要是通过屏蔽数据存储、查询、分析和管理

的复杂性，将兵要信息的属性、几何与媒体信映射

为数据库中的若干关系表，并抽象访问接口，进行

统一访问。展现方式主要包括空间关系展示（在基

础地理信息图层上叠加专题兵要信息）、二维图表

类结构化展示（网页或者表单）、统计图表展示（统

计图表）。

基于单机版的查询应用主要问题在于：一是

无法整合多源数据进行联合分析，由于数据在单

机预装，无法对其他来源数据进行联合分析；二是

查询分析功能固化，展示界面与分析功能绑定，一

旦研发完成后，无法针对不同的应用案例定制可

视化方案。

1.2.2数据保障模式越来越不满足军事应用的需求

我军目前的兵要信息保障基本上是以指挥所

和武器平台为中心的数据分散部署模式，满足局域

网和单机使用环境，用户在哪里、指挥所开设到哪

里，兵要数据就要部署到哪里，并且不支持以服务

化的方式提供兵要信息应用，难以满足作战指挥和

武器应用实时性要求，不能实现分散部署的兵要信

息数据的同步更新共享和一致性维护；同时，非服

务化紧耦合的兵要信息系统技术体制，仅能满足预

先定义用户和功能的应用案例研发方式，无法满足

我军多样化任务对兵要信息应用的需求。

2综合兵要信息服务应用总体设计

基于以上存在问题，本文主要从综合兵要信息

模型设计与应用架构两个层面，对目前的综合兵要

信息应用系统进行重构，主要解决模型设计层面上

与地理信息平台耦合度大、移植性差、开发接口设

（

丁昊，等：综合兵要信息服务关键技术研究

（总第46-

0319

）

图2结构化展示

图3统计图表展示

计不完善等问题，和应用层面上兵要信息的保障模

式落后的问题。

2.1综合兵要信息模型设计

本文设计的综合兵要信息应用总体定位是可

重用、可扩展，并具备可移植等特性。通过参考目前

各种商用地理信息系统和军事地理信息系统的架

构设计，抽象中间层并设计综合兵要信息模型。该

模型具备在各平台之间移植，具备松耦合的特点。

本文设计的综合兵要数据模型是基于地理信息系

统提供的接口进行二次开发，因此，总体目标是在

模型设计上对地理信息系统中的对象进行封装与

聚合，使设计的兵要对象具备良好的封装性和重用

性，同时提供给应用层接口要粒度恰当，便于使用。

兵要数据的主要组织方式是目录树，大类里面

包括小类，最底层的叶子节点表示具体的兵要类

别。大类与小类的父子隶属关系主要通过兵要编码

来标识，因此，在兵要引擎的设计上，要体现目录树

的组织方式，用户通过目录树访问某一类兵要实

体，通过目录树某一类兵要节点和兵要ID访问具

体的兵要实体。

图4综合兵要信息模型设计

·135·

（总第46-

0320

）火力与指挥控制2021年第2期

图4中，综合兵要模型设计主要包括两个部

分，上半部分为兵要数据访问部分，下半部分为兵

要目录树部分，兵要数据访问部分与各地理信息系

统平台耦合度比较大，可针对各种地理信息平台实

现，针对各类主流地理信息平台编译动态库，向上

层兵要数据目录部分提供抽象的访问接口。当需要

在不同地理信息平台间进行移植时，只需要替换兵

要数据访问动态库即可实现。兵要数据目录访问部

分是兵要数据查询检索的核心模块，根据综合兵要

信息的树状结构，以及兵要数据的分类编码进行查

询检索。

系统启动时，根据兵要数据配置文件，通过

CBY_SSTree全局静态变量在内存中初始化目录树

结构。数据访问部分入口是BY_LayerAdapter，针对

不同的地理信息平台，实现不同的BY_LayerAdapter，

并向外提供IBY_LayerAdapter接口，对上层屏蔽不

同平台的差异。需要提取某类兵要实体时，先通过

CBY_SSTree获取某类兵要实体的编码信息，然后通

过兵要数据访问接口到数据库中查找数据，并构造

数据树CBY_Dtree，最终获得的BY_Entity是兵要实

体对象的封装。通过以上结构设计，以面向对象的

方式访问兵要实体，保证功能的封装与重用

［4］

，同

时也兼顾了各地理信息平台间的移植性

［5］

。

2.2服务架构设计

兵要信息的单机应用是制约综合兵要信息保

障效率提升的主要原因，基于服务化的综合兵要信

息系统改造是提升综合兵要信息保障效率的关键。

综合兵要信息服务架构设计主要包括综合兵要信

息数据服务和综合兵要信息功能服务两大模块，数

据服务是通过对兵要数据引擎模块进行调用，将关

系数据库或者文件系统中的数据封装适配成抽象

的兵要实体，通过服务层将兵要实体序列化为XML

或者JSON格式返回给用户；功能服务是将兵要数

据应用的相关功能，根据不同的业务需求封装若干

功能服务接口提供给应用层。本系统在实现上，兼

顾了不同层次、不同粒度的开发用户的需求。开发

用户既可以直接针对兵要引擎进行二次开发，也可

以通过应用层提供的兵要信息服务进行兵要数据

的获取和展现，具体细节如图5所示。

图5综合兵要信息服务架构设计

兵要信息访问引擎部分在技术实现上采用的

是C++语言。由于java在网络应用中的优势地位，

以及各种开源web服务器都广泛对java语言支持，

本系统在服务发布模块采用java语言编写，因此，

在中间层需要实现两种语言的互相调用功能。本系

统采用的是jna第三方库，jna库支持java语言直接

调用C++对象的方式。

针对某类需要查询的兵要实体，本系统流程如

图6所示：

1）获取某个兵要实体唯一编码，调用兵要信息

查询服务接口。

2）j2ee平台的java对象调用jna包装的C++

接口。

3）jna对象调用兵要引擎接口。

4）兵要引擎接口调用地理信息平台数据访问

图6查询兵要实体流程图

·136·

丁昊，等：综合兵要信息服务关键技术研究

（总第46-

0321

）

接口。

5）平台返回组成兵要实体的三大类信息（属性

对象、几何对象集、媒体对象集）给兵要引擎。

6）兵要引擎将三大类对象组装成兵要实体

（BY_Entity）。

7）调用jsonlib将兵要实体序列化json文本并

调用jna对象。

8）jna对象调用j2ee平台的java对象。

9）j2ee平台返回给用户兵要实体的json文本。

3综合兵要信息过滤关联规则的实现

兵要数据结构复杂，属性丰富，而且还包含大

量的媒体信息，客户端的定制化设计中不需要展现

给用户与其无关的信息。精炼的信息表达能让用户

一目了然，并且使用户迅速掌握数据的要点并进行

决策。

系统研发人员往往对数据结构比较了解，可以

针对数据进行信息过滤，而系统用户只知道需求是

什么，但不知道如何实现信息过滤，因此，系统研发

人员需要和用户反复沟通，协商需求。往往系统研

发定型后再进行修改是非常麻烦的，因此，本文在

某些规则的设计上采用了模板配置的方式，把具体

的配置工作交给用户，一旦用户需要修改界面显

示，只需要针对某一兵要类别规则进行修改即可，

不需要重新修改软件。

在规则设计上，采用规则继承方式。每类兵要

数据都有相应的规则文件（通过类别码标识，也称

子类），而所有兵要类别都继承一套共同的规则（也

称基类），所有规则文件都放置在一个公共配置文

件中，如某类兵要数据需要特别的规则设置，则特

别设置的规则会替换公共规则，这种规则继承的方

式方便用户扩展。比如图7中的flm为000000的规

则为基类规则，而下面为具体某一类兵要层的显示

规则。

综合兵要信息规则控制主要包括两大类：显示

规则与关联规则。针对显示规则类，图7中规则文

件的多媒体数据表达规则段，是针对不同类别媒体

文件的后缀判断其是否显示，有些没有意义的媒体

文件可以隐藏显示；多要素属性数据表达段规则是

针对兵要数据属性字段比较丰富，全部显示会造成

信息量与媒体载负量的失衡，通过规则控制可以筛

选出用户比较关注的字段予以显示，方便用户对信

息的全局把握。

关联规则配置在空间关联规则段中，主要目的

图7兵要数据规则配置文件（公共规则上、某类规则下）

是为了实现兵要实体的关联查询，实现各类兵要实

体的网状态势关联展现。每一条关联规则主要包括

3个配置项：集合类型、空间关联关系类型（如下页

表1所示）以及关联的另一个兵要类别码。这种配

置方式是让用户针对自己感兴趣的专题，配置空间

关联规则。如下页图8所示，当用户查询重要城市

时，在关联规则中可以配置流经重要城市的河流段

有哪些，实现定制化的显示配置。

·137·

（总第46-

0322

）火力与指挥控制2021年第2期

表1空间关联关系列表

空间关联关系字段项

相交GIS_SPATIAL_INTERSECT

不相交GIS_SPATIAL_DISJOINT

相等GIS_SPATIAL_EQUAL

包含GIS_SPATIAL_CONTAIN

在内部GIS_SPATIAL_WITHIN

穿越GIS_SPATIAL_CROSS

叠加GIS_SPATIAL_OVERLAP

边缘相接GIS_SPATIAL_EDGE_TOUCH

在边缘上GIS_SPATIAL_ON_EDGE

边缘叠加GIS_SPATIAL_OVERLAP_EDGE

图8重要城市关联查询河流段

4结论

综合兵要信息系统是作战指挥综合信息库的

组成部分，是军事测绘数据应用于作战指挥的桥

梁。以数字化战场为基础，综合兵要地理信息系统

在各级各类指挥自动化系统中起着将数字化战场

信息转化为指挥人员所需要的形式，或指挥自动化

系统所需要模式的重要任务。

本文根据我军目前综合兵要信息应用模式越

来越不满足现在战争数据保障模式的需求分析了

目前综合兵要信息保障模式的弊端，设计了综合兵

要信息逻辑模型与服务架构，针对模型设计实现了

原型展示系统。目前该系统功能上还有很多地方疏

于考虑，比如：如何管理服务，数据安全问题如何

考虑，如何实现综合兵要信息全文检索，以及综合

兵要信息的可视化展示技术等。这些技术都有待

·138·

图9重要城市类别查询

图10多媒体查询

于在今后的工作中继续进行分析与探讨。

参考文献：

［1］胡丹露.浅析兵要信息［J］.军事测绘，2010（1）：13-16.

［2］申慧群.抓住机遇转变观念积极推动全军兵要信息建设

［J］.军事测绘，2010（1）：4-7.

［3］华一新，吴升，赵军喜.地理信息系统原理与技术［M］.北

京：解放军出版社，2001.

［4］BOGGSW，邱仲潘.UMLwithRationalRose从入门到精通

［M］.北京：电子工业出版社，2000.

［5］ERICHG，RICHARDH，RALPHJ，etal.设计模式：可复用

面向对象软件的基础［M］.李英军，马晓星，蔡敏等，译.北

京：机械工业出版社，2000.9.

［6］曹江，高岚岚.互操作、互理解、互遵循———军事信息系统

的新型能力目标与评估模型［J］.指挥与控制学报，

2015，1（1）：41-45.

［7］李颖，张占月，陈庆华.空间对地观测系统的网络信息服

务建模和仿真［J］.火力与指挥控制，2012，38（10）：67-69.

［8］蔡立平，左燕，王文光.基于半定规划的无源跟踪最佳传

感器选择［J］.火力与指挥控制，2019，44（9）：49-54.