基于交互规则建模的信息系统实时状态监测技术研究

李 俊，李峰纲，高兴利

(西安泛华科技开发有限公司，西安 710075)

0 引言

现代舰艇复杂度和集成优化程度日益提高，信息系统[1-2]作为舰艇信息流转和控制的核心，能够实现警戒、跟踪、目标识别、数据处理、威胁估计、武器控制及对敌作战等功能，其运行状态正常与否直接决定了舰艇的战备完好性和遂行任务的成功率。

目前，舰艇信息系统大多采用以太网作为通信总线[3]，信息系统总体单位制定的任务流程和通信协议中规定了系统中各分系统、设备间的信息交互时序、逻辑和数据约束。信息系统是一个庞大且错综复杂的系统，系统交互流程的多样性、复杂性对系统实时状态监测提出了更大的挑战。信息系统涉及分系统、电子装备和相关专业较多，系统内部交互关系复杂，其中任何的通信传输或设备故障，均可导致系统整体任务功能丧失或系统效能下降。

系统出现故障时，仅通过分系统及设备自检、机内测试(BIT)、分散的数据记录、零散的状态信息显示等手段，或借助简单的测试仪表和工具，依靠人工和历史经验进行监测和保障的方式[4]，具有难度大、成本高、周期长、要求高、监测粒度粗、实时性差、自动化程度低等缺点，直接影响系统故障的快速定位，无法保证系统的战时可用性。

因此，结合某型信息系统预定的使命任务和工作流程，开展基于信息交互规则的建模研究[4]，建立一套扩展性好、通用性强的系统状态监测模型，通过计算机加载并动态执行该规则模型，完成对信息系统的自动化、精细化、流程化的实时状态监测，使指挥员和操作员实时掌握系统的运行状态，及时发现系统运行中的异常情况，并给出故障对任务执行的影响程度评估，为指挥员的指挥决策提供参考，辅助艇员快速完成系统故障的定位和修复。

1 信息系统的层次结构划分

按照不同舰艇平台的使命任务不同，信息系统的组成和结构也不尽相同。以某舰艇平台为例，信息系统由一体化网络、显控设备、声纳分系统、通信分系统、指挥控制分系统、光电雷达设备、对抗设备、武器设备等组成。信息系统的组成如图1所示。

图1 舰艇信息系统的组成框

信息系统可划分为系统、分系统和设备三层[5]，其中各功能分系统又包含多个型号的电子设备。系统包含的分系统或直属设备均作为上网节点，通过双冗余的方式接入一体化网络，实现节点间的通信和数据交互。

为降低网络通信在时间和空间上的耦合性，降低单点失效的概率和风险，提高网络通信的可靠性，方便开展网络通信管理，采用消息中间件的发布/订阅[6-7]的方式实现网络通信交互。这种方式通过发布者和订阅者之间的主题关联，较好地实现了网络通信的松耦合。

2 系统分层建模

按照信息系统各分系统、设备间的协同交互工作过程和通信协议，基于规则对信息系统进行实时状态监测建模[8-10]。可将系统状态监测模型划分为三层：第一层为单节点信息层，第二层为节点间交互信息层，第三层为系统交互逻辑层。

2.1 单节点信息层

单节点信息层主要描述单个上网节点(设备)的基本属性和基本状态信息。单个上网节点的基本属性包括：节点ID、名称、编号、类型、IP地址、所在位置等。单个上网节点的基本状态信息包括：节点的网络连接状态、工作状态、心跳状态、模拟训练状态、BIT状态信息、工作模式信息、时统信息等。这些信息仅属于该节点的状态信息或该节点直接与一体化网络的交互信息。

单节点信息层采用自定义格式的XML文件进行描述，为降低系统模型间的耦合性，增强其扩展性，系统中每个上网节点用单独的文件进行描述，每个节点对应一个描述文件，文件后缀名定义为*.snd。

单节点信息层的XSD文件格式定义如图2所示。

图2 单节点信息层Schema图

2.2 节点间交互信息层

节点间交互信息层主要描述一体化网络中存在协同的两两节点之间的信息交互关系，多个节点间交互信息可并列建模描述。

该层描述的具体内容包括：信息ID、信息名称、信源ID、信宿ID、信息内容、类型(周期/实时)、超时时间等。

节点间交互信息采用自定义格式的XML文件进行描述，一体化网络中两两节点(存在交互关系的两个节点)间交互信息单独描述，最终形成一个统一的模型文件，文件后缀名定义为.nsi。

在本层的描述中，可以引用单节点信息层的有关信息(如网络连接状态、工作状态、心跳状态、BIT状态等)，作为节点间交互信息层数据通信判定的一个输入和依据。如当单节点的网络连接状态异常时，与该节点相关的节点间交互信息直接判定为故障，并给出故障告警和原因分析提示信息。

节点间交互信息层的XSD文件格式定义如图3所示。

图3 节点间交互信息层Schema图

2.3 系统交互逻辑层

系统交互逻辑层主要描述信息系统一体化网络中节点间信息协同交互逻辑关系[11-14]。按照系统执行的任务和通道等，可将系统交互逻辑关系可抽象为一个或多个串行交互序列，序列中的每个步骤都代表两两设备间或单节点与系统间的一种交互关系，系统交互序列是对系统交互逻辑关系的一种梳理和抽象，也是后续利用计算机程序进行自动化分析和在线监测的依据和基础。

系统交互逻辑层的描述中可嵌套、引用节点间交互信息层和单节点信息层中的内容。

该层采用线框图形式描述信息系统一体化网络中节点间的协同交互逻辑关系，通过线框图的描述，建立系统交互逻辑模型。模型元素包括方框、带箭头实线和带箭头虚线三种，方框表示单个网络节点，方框中的文字表示节点名称，方框间的有向连线(带箭头实线)代表两个节点间的交互关系，带箭头虚线代表节点直接上报的报文信息。

系统中某个任务协同工作过程的交互逻辑如图4所示。

图4 系统交互逻辑线框图(示例)

根据信息系统实际工作过程，从系统交互逻辑模型中，可人工抽象出若干组的系统交互逻辑序列，线框图中每条有向连线均代表交互逻辑序列中的一个步骤，连线上的文字代表序列步骤的标号。从图4的线框图中可以抽象出系统交互逻辑序列4个，如图5所示。

图5 系统交互逻辑序列(示例)

系统交互逻辑线框图是系统中网络节点交互关系的直观描述，系统交互逻辑序列是对交互逻辑线框图的一种抽象和总结，是进行信息系统实时状态监测和故障诊断的重要依据和基础。建立系统交互逻辑线框图的目的是直观展示协同工作过程的交互逻辑，方便建模人员从中提取出交互逻辑序列。计算机最终加载执行的是系统交互逻辑序列。

系统交互逻辑序列采用自定义格式的XML文件进行描述，系统包含的所有交互逻辑序列描述在一个独立文件中，文件后缀名定义为.sis。

系统交互逻辑层的XSD文件格式定义如图6所示。

图6 系统交互逻辑层Schema图

3 系统建模步骤

信息系统状态监测模型的建立分为7个步骤，具体如下：

1)收集、整理与信息系统有关的所有资料；

2)分析信息系统的组成和层次划分，创建系统层次结构的几何模型；

3)根据系统层次结构划分和各上网设备的特点，归纳整理出系统各上网节点的属性和基本信息，按照单节点信息描述格式的要求，进行单节点信息描述，生成一系列.snd格式的模型文件；

4)根据系统层次结构划分和系统接口协议规定，归纳整理出系统存在交互关系的两两节点间的交互信息，按照节点间交互信息描述格式要求，进行节点间交互信息的描述，生成单个.nsi格式的模型文件；

5)根据系统层次结构几何模型及系统协同交互关系，进行系统交互逻辑建模，创建系统交互逻辑线框图；

6)结合实际任务工作流程和协同交互逻辑，从系统交互逻辑线框图中抽取出系统交互逻辑序列；

7)按照系统交互逻辑层描述格式要求，逐一对交互序列进行建模描述，生成单个.sis格式的模型文件。

信息系统状态监测模型建立流程如图7所示。

图7 系统状态监测建模流程

4 系统实时状态监测的实现

4.1 创建交互序列模型运行管理线程池

为实现系统交互序列监测高效、并发地执行，程序采用了线程池处理机制。线程池是一种多线程任务处理的常用方式，线程池在系统启动时创建，初始化后所有线程均处于空闲状态。处理过程中将序列监测任务添加到队列，然后在创建线程后自动启动队列中的任务，线程池中的线程都是后台线程，由系统进行统一管理[15-17]。

4.2 模型加载及模型元素数据结构动态构建

为提高系统交互序列的加载和匹配的效率，降低系统资源消耗，在系统初始化时，后台同步加载系统状态监测模型文件(包括*.snd、*.nsi、*.sis)，并在内存中动态构建各层元素对应的数据结构。模型元素数据结构构建流程如图8所示。

图8 模型加载及元素数据结构动态构建流程图

4.3 系统交互序列的加载执行

通过订阅方式实时接收一体化网络报文信息，按照信息系统接口协议对接收的报文进行解析，判定该报文的信源和信宿，在模型的内存数据结构中查找与该报文信息有关、符合条件的所有交互序列，并依次添加到线程池任务队列中，由线程池加载启用这些交互序列。

每接收到一条报文信息，系统会将信息与线程池交互序列中所有等待下一步将要执行步骤中包含的信息进行匹配，若线程中存在与之匹配的序列步骤，则按照该序列的执行顺序向下执行一步，更新序列当前执行标记；若不存在匹配序列步骤则当前序列执行线程挂起，当前序列执行标记保持不变。

若一个交互序列中所有步骤都已执行完毕，则将该任务从队列中移除，并将线程资源交还给线程池管理。

系统交互序列的加载执行流程如图9所示。

图9 系统交互序列的加载执行流程图

4.4 系统交互逻辑正确性的判定

每条交互序列都代表系统设备间的实际交互逻辑，序列中每个步骤都代表两设备间的一种或多种交互数据，通过实时接收网络报文数据，匹配系统交互监测模型，可实现系统交互逻辑正确性，报文数据合规性、完整性、正确性、报文丢包、超时等内容检测。

单节点工作状态信息作为系统交互逻辑正确性判定的重要参考条件，若节点工作状态异常，则与该节点相关的交互逻辑中的后续序列全部判定为异常，交互序列终止。

从一体化网络获取时统信息，根据当前报文的发送时戳和系统时间，结合模型中描述的各信息的发送时机(周期发送时的周期值)、超时时间，综合判定报文是否发生丢包或超时。

系统设备间交互逻辑正确性检查是通过报文接收次序，匹配对应的系统交互序列后，通过综合判定实现的。若一条序列正确执行至结束，则表示该序列代表的交互逻辑正常；当序列中某一步骤不能正确执行，可断定该步骤包含的报文在规定时间内未接送达(超时或丢失)或报文格式、内容出现错误，判定该序列代表的协同交互逻辑异常。

4.5 系统交互逻辑监测示例

以图4所示的系统交互逻辑线框图代表的系统交互逻辑为例，抽象出系统的交互序列如图5所示，根据接收报文的内容，加载执行相应的交互序列，完成系统交互逻辑监测。系统交互逻辑监测示例如图10所示。

图10 系统交互逻辑监测示例

5 系统异常的影响分析

当系统出现异常时，依据信息系统物理结构层次关系、通道信息流向关系[17-18]及遂行任务中对探测器材、武器装备等设备的需求和调度情况，参考信息系统故障模式、影响及危害性分析(FMECA)等内容，建立信息系统故障影响评价多分支串联组合模型，当系统中某一设备出现故障时，通过该模型可追踪、分析和评价该故障对此次任务执行产生的影响。

故障影响主要参考遂行任务通道中包含的设备及任务信息流向，综合判断前置设备故障对此次任务及相关设备的影响。

故障原因分析主要是给出系统当前故障模式对应可能的故障原因选项，并给出各故障原因的可能概率。

故障影响和原因分析，仅供舰艇指挥员在指挥决策及艇员完成系统故障快速排查定位时参考。

6 试验验证与结果分析

通过模拟仿真注入的方式，在实验室搭建模拟仿真环境[18-19]下对该监测系统进行了验证。具体验证方法及步骤如下：

1)监测系统接入信息系统网络，信息系统依照通信协议、数据流量大小、协同工作流程等内容，向监测系统注入数据激励。验证时共模拟注入数据激励类型210种、数据发送最小周期为20 ms，每秒发送数据200条，数据流量约为3 MB/s，信息交互流程30个，连续发送数据10天，累计注入数据总数172 800 000条，故障和正常数据交替注入。

2)通过DDS方式，实时订阅网络数据并存储，依据装备信息系统状态监测模型对信息系统的运行状态，特别是对数据格式合规性、内容有效性、交互时序流程正确性等方面进行监测。

3)通过软件模拟数据故障、流程故障并注入，共模拟故障100个，检测监测系统能否监测出故障并进行告警提示，给出故障定位和原因分析。

步骤4：对试验数据进行统计分析，结果见表1所示。

表1 试验结果统计分析

通过数据统计分析，验证了系统双冗余网络切换时间、数据采集丢包率、数据连续记录时间、数据记录正确率、异常报警提示正确率、故障检测正确率等指标符合设计要求。后期，在信息系统联调、陆试、系泊试验等环境下，通过接入实装系统网络环境，对监测系统进行了再次验证，结果同样符合要求。

7 结束语

本文从信息系统的组成与层次划分、分层建模的方法、系统建模步骤、系统实时状态监测的实现等方面出发，对基于交互规则建模的信息系统实时状态监测技术进行了研究，该方法具有较强的通用性和可扩展性，能够适应信息系统交互流程和接口协议的频繁变化，只需简单更新对应的模型，即可扩展和满足新的系统状态监测需要。

本文中提出的基于关联交互规则建模方法，属于应用层建模描述方法，不局限在一体化网络中应用，其他型号中的点对点、组播/广播网络通信、串口或1553B等总线通信[20]中均可参考应用，适用性强、应用范围广。

后续将加快研究，开发出系列辅助工具软件，用于实现建模描述、数据转换、模型文件生成的自动化，减少人工工作量，进一步提高建模的工作效率。