丁 昊，段晓沛，高 昂，赵玲瑜，康晓华

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

0 引言

兵要信息源自于中国在吏制时代关于戍边和海防的资料［1］，随着我军大力推进军队信息化建设，传统的兵要信息概念已不能涵盖目前兵要信息所包括的内容和涉及的技术。为适应信息化作战环境，由兵要地志发展而来的综合兵要信息成为描述陆上、海域、空中多维战场环境特征的一种数据集［1］。

综合兵要信息是基于地理信息技术，对多源战场环境信息整合和空间描述的数字化军事测绘保障产品，从20 世纪90 年代开始，我军逐渐建设关于综合兵要信息的应用系统，其数据的获取、整合与加工、数据质量控制、数据存储与管理、信息服务等须以数字地图、地理信息、网络等现代技术为支撑。基于数字地图的兵要信息可以快速定位兵要实体的空间位置，便于指挥员迅速建立空间概念关系，为研判态势、作战指挥决策、部署兵力火力等提供基本依据；能够形成覆盖各种作战区域、联通各类要素信息的战场综合态势，便于迅速形成对战场环境的全面认知与综合掌控［2］。

随着我军信息化程度的提高，服务化逐渐成为我军信息化建设的主要方向，目前，我军正在大力推进服务化、国产化的信息集成平台，目前基于单机的综合兵要信息构建技术已经不能满足我军系统建设发展的需要，需要针对综合兵要信息服务展开研究。

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

目前综合兵要信息应用主要存在两个方面的问题，一是系统设计方面，综合兵要模型设计二次开发接口不完善，与地理信息平台耦合度大；二是保障模式方面，单机版系统部署与数据绑定，信息互联互通困难。

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

目前的综合兵要信息系统设计主要是基于局域网C/S 部署模式，支持主流的商用关系数据库和文件访问模式。具体实现方法为：依托某一地理信息系统平台，由于综合兵要信息数据的结构特点（一个兵要实体数据包括一条属性数据，多条几何数据以及若干条媒体数据），将某类兵要实体抽象为关系数据库中的三张表（同理，文件存储方式也是分成不同类别的文件分开存储），一张表用来存储几何数据，一张存属性数据以及一张表用来存储多媒体数据，不同表间的同一兵要数据通过ID 相关联，这也是综合兵要数据与传统的基础地理数据组织方式略有区别的地方［3］。因此，目前的综合兵要信息系统的数据结构设计仅仅是基于地理信息系统的模型结构进行简单扩展。

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

基于以上结构特点，图1 描述了目前主要兵要应用引擎的架构设计，该引擎是基于原有的地理空间数据引擎适配设计，具有综合兵要信息查询、统计分析、报告制作以及用户权限控制等多个功能，同时支持文件以及多种商业关系数据库的数据存储方式，具有一定的灵活性和可扩展性。存在的主要问题是：一是二次开发层面提供的开发接口不够友好，用户进行二次开发时需要了解兵要数据的底层存储细节；二是兵要数据引擎设计与地理信息平台紧密耦合，一旦底层平台发生改变，引擎需要重写。

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

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

综合兵要信息具有空间特征多样、结构复杂、属性结构不一、关系复杂等特点，其数据之间不仅存在空间拓扑关系和属性关系，同时还包括空间关联关系以及大量的媒体信息。目前的综合兵要信息访问主要是通过屏蔽数据存储、查询、分析和管理的复杂性，将兵要信息的属性、几何与媒体信映射为数据库中的若干关系表，并抽象访问接口，进行统一访问。展现方式主要包括空间关系展示（在基础地理信息图层上叠加专题兵要信息）、二维图表类结构化展示（网页或者表单）、统计图表展示（统计图表）。

基于单机版的查询应用主要问题在于：一是无法整合多源数据进行联合分析，由于数据在单机预装，无法对其他来源数据进行联合分析；二是查询分析功能固化，展示界面与分析功能绑定，一旦研发完成后，无法针对不同的应用案例定制可视化方案。

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

我军目前的兵要信息保障基本上是以指挥所和武器平台为中心的数据分散部署模式，满足局域网和单机使用环境，用户在哪里、指挥所开设到哪里，兵要数据就要部署到哪里，并且不支持以服务化的方式提供兵要信息应用，难以满足作战指挥和武器应用实时性要求，不能实现分散部署的兵要信息数据的同步更新共享和一致性维护；同时，非服务化紧耦合的兵要信息系统技术体制，仅能满足预先定义用户和功能的应用案例研发方式，无法满足我军多样化任务对兵要信息应用的需求。

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

基于以上存在问题，本文主要从综合兵要信息模型设计与应用架构两个层面，对目前的综合兵要信息应用系统进行重构，主要解决模型设计层面上与地理信息平台耦合度大、移植性差、开发接口设计不完善等问题，和应用层面上兵要信息的保障模式落后的问题。

图2 结构化展示

2.1 综合兵要信息模型设计

本文设计的综合兵要信息应用总体定位是可重用、可扩展，并具备可移植等特性。通过参考目前各种商用地理信息系统和军事地理信息系统的架构设计，抽象中间层并设计综合兵要信息模型。该模型具备在各平台之间移植，具备松耦合的特点。本文设计的综合兵要数据模型是基于地理信息系统提供的接口进行二次开发，因此，总体目标是在模型设计上对地理信息系统中的对象进行封装与聚合，使设计的兵要对象具备良好的封装性和重用性，同时提供给应用层接口要粒度恰当，便于使用。

图3 统计图表展示

兵要数据的主要组织方式是目录树，大类里面包括小类，最底层的叶子节点表示具体的兵要类别。大类与小类的父子隶属关系主要通过兵要编码来标识，因此，在兵要引擎的设计上，要体现目录树的组织方式，用户通过目录树访问某一类兵要实体，通过目录树某一类兵要节点和兵要ID 访问具体的兵要实体。

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

图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 查询兵要实体流程图

5）平台返回组成兵要实体的三大类信息（属性对象、几何对象集、媒体对象集）给兵要引擎。

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

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

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

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

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

兵要数据结构复杂，属性丰富，而且还包含大量的媒体信息，客户端的定制化设计中不需要展现给用户与其无关的信息。精炼的信息表达能让用户一目了然，并且使用户迅速掌握数据的要点并进行决策。

系统研发人员往往对数据结构比较了解，可以针对数据进行信息过滤，而系统用户只知道需求是什么，但不知道如何实现信息过滤，因此，系统研发人员需要和用户反复沟通，协商需求。往往系统研发定型后再进行修改是非常麻烦的，因此，本文在某些规则的设计上采用了模板配置的方式，把具体的配置工作交给用户，一旦用户需要修改界面显示，只需要针对某一兵要类别规则进行修改即可，不需要重新修改软件。

在规则设计上，采用规则继承方式。每类兵要数据都有相应的规则文件（通过类别码标识，也称子类），而所有兵要类别都继承一套共同的规则（也称基类），所有规则文件都放置在一个公共配置文件中，如某类兵要数据需要特别的规则设置，则特别设置的规则会替换公共规则，这种规则继承的方式方便用户扩展。比如图7 中的flm 为000000 的规则为基类规则，而下面为具体某一类兵要层的显示规则。

综合兵要信息规则控制主要包括两大类：显示规则与关联规则。针对显示规则类，图7 中规则文件的多媒体数据表达规则段，是针对不同类别媒体文件的后缀判断其是否显示，有些没有意义的媒体文件可以隐藏显示；多要素属性数据表达段规则是针对兵要数据属性字段比较丰富，全部显示会造成信息量与媒体载负量的失衡，通过规则控制可以筛选出用户比较关注的字段予以显示，方便用户对信息的全局把握。

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

关联规则配置在空间关联规则段中，主要目的是为了实现兵要实体的关联查询，实现各类兵要实体的网状态势关联展现。每一条关联规则主要包括3 个配置项：集合类型、空间关联关系类型（如下页表1 所示）以及关联的另一个兵要类别码。这种配置方式是让用户针对自己感兴趣的专题，配置空间关联规则。如下页图8 所示，当用户查询重要城市时，在关联规则中可以配置流经重要城市的河流段有哪些，实现定制化的显示配置。

表1 空间关联关系列表

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

4 结论

综合兵要信息系统是作战指挥综合信息库的组成部分，是军事测绘数据应用于作战指挥的桥梁。以数字化战场为基础，综合兵要地理信息系统在各级各类指挥自动化系统中起着将数字化战场信息转化为指挥人员所需要的形式，或指挥自动化系统所需要模式的重要任务。

本文根据我军目前综合兵要信息应用模式越来越不满足现在战争数据保障模式的需求分析了目前综合兵要信息保障模式的弊端，设计了综合兵要信息逻辑模型与服务架构，针对模型设计实现了原型展示系统。目前该系统功能上还有很多地方疏于考虑，比如：如何管理服务，数据安全问题如何考虑，如何实现综合兵要信息全文检索，以及综合兵要信息的可视化展示技术等。这些技术都有待于在今后的工作中继续进行分析与探讨。

图9 重要城市类别查询

图10 多媒体查询