实时测控数据处理软件集群通用化框架设计

2018-07-13方建勋

火力与指挥控制 2018年6期

童艳，方建勋

（解放军91550部队，辽宁大连 116023）

0 引言

实时测控数据处理软件是测控系统的核心部件，主要负责接收各类传感器测量数据，通过实时数据处理和轨迹解算，与其他系统交互数据处理结果，完成测控任务［1］。近年来，随着测控系统向多目标多任务化方向发展，实时测控数据处理软件的处理任务明显增大，为保证实时性和可靠性，集中式处理模式越来越难以满足更多的数据处理需求。为提高实时数据处理能力，基于集群技术建立一个计算功能强大、实时性强、可靠性高的实时测控集群系统势在必行。

由于测控任务中通常面临目标型号不同、种类多样等问题，每个型号任务对应一套软件，如此庞大的软件以及多样化的软件版本，不利于软件的开发和维护管理，且对于通用性的软件升级改造复用性较差［2］。为规范软件设计方法，提高实时数据处理软件的通用性，本文从软件结构设计、通信机制、控制流程和算法模型库等关键技术开展规范化设计研究，为后续实时测控数据处理软件的版本固化和新软件的通用化研发提供技术依据。

1 集群系统软件结构

实时测控数据处理软件在高精度时统信号同步下工作，完成测控目标的实时测控数据处理、过程重演或模拟等任务。

过去采用集中式处理模式，依靠高性能小型机作为硬件平台，实现强实时高可靠实时测控数据处理任务。但随着测控技术和手段的不断发展，传感器的种类和数量、信息传输方式以及指挥控制手段都在发生巨大变化，使得集中处理模式在计算速度、吞吐能力、体系结构等方面逐渐失去其优势，实时数据处理软件开始向高性能、大容量的分布式处理模式发展。

为满足实时数据处理软件的强实时、高可靠需求，采用多进程多线程程序设计思路，将软件设计成由人机交互管理进程、信号控制进程、作业管理进程、实时数据处理进程、模拟重演进程等五大进程组成。同时，设计满足实时性的通信机制，实现进程间的信息实时交互，使进程能够相互协作完成实时数据处理任务。考虑软件设计的通用性，采用系统参数配置管理和软件模块化加载方法，完成不同任务不同作业的软件控制。对通用性较强的算法，采用模块化设计方法建立算法模型库，实现算法的通用化设计。

2 通信机制

实时测控软件规模庞大复杂，由多进程多线程组成，各进程或线程之间需要实时进行信息交互，协作完成实时测控数据处理任务。

2.1 单一节点内通信机制

2.1.1 进程内通信

进程内即线程之间的信息交互采用全局变量和锁存技术实现线程同步。

进程中开设全局共享变量，进程内的各线程通过对全局变量的访问达到信息交换的目的。

互斥锁和条件变量则是作为线程间的同步方式，对线程共享区的访问控制，需在每个共享数据结构中设计读写锁对象，通过互斥锁和条件变量来实现严格同步。

2.1.2 进程间通信

单一节点内进程间通信采用的有效解决方式是共享内存结合信号量。

在进程间通信采用共享内存区实现，它是通过将同一段物理内存映射到不同进程各自的地址空间中来实现的，当多个进程映射同一个共享内存区对象时，如果其中某一个进程向共享内存区写入了数据，那么其他进程就能够立刻读到该数据。由于映射到不同进程的虚空间中，不同进程可以直接使用，不需要进行内存的复制，没有额外的与系统调用相关的开销，所以从操作系统所能实现的所有IPC方法中，共享内存区是解决进程间数据传递的最快方法。

信号量主要是提供一种进程间同步方式，控制各协作进程对进程共享区的访问。当向共享区中的某个区域写数据时，进程将信号量一直锁定到写操作完成，以防止其他进程此时访问该共享区。当进程不再使用这段共享区时，则将该信号量解锁，以便其他进程使用。

2.2 节点间通信机制

对于分布式软件布局来说，除了采取以上方法实现单一节点机内部通信外，还要考虑不同节点间是如何实时通信的。目前，高速网络配置和成熟的SOCKET通信手段是实现节点间实时通信最简单有效的解决方式［3］。

基于实时性考虑，节点间信息的分发应建立在UDP/IP协议基础之上。对节点间需要实时交互的信息，如任务分配表、原始测量数据包、计算中间结果以及作业时间信息等，采用组播方式在节点之间信息传输。

节点间信息以20 Hz频率进行传输，完成处理后再以组播方式发送到相应的节点机。节点间信息传输流程如图1所示。

图1 节点间信息传输流程

为提高通信效率，满足系统的实时性要求，采用SOCKET的多路复用技术select监测信息数据包是否到达［4］。当有数据包到达，先识别可进行信息数据包读操作的套接字，然后设置相应的同步标识并进行写入处理，完成后继续等待下一数据包到达，如果在等待过程中发生中断，则返回继续等待。由于通信传输时延等因素的存在，数据帧处理时用数据帧中的时间戳与当前接收时间进行比较，实现数据帧更新过滤，保证各节点能够获取最新的实时信息。最终将实时接收的信息存储到共享内存区或本地磁盘，供本地节点使用。

3 控制模型

3.1 主控模块设计

作为通用型实时数据处理软件，在执行不同的任务和作业时，各子功能模块的加载和运行情况是不一样的，一般由主控模块根据接收到的信号控制进程内其他各子功能模块的运行［7］。为实现系统的通用性和可靠性，每个功能模块在设计上除了完成基本功能实现外，还必须包括与系统配置和异常处理相关的初始化配置和错误处理等模块设计，通常在主控模块中被调用。

初始化配置模块使软件模块在执行基本功能之前处于就绪状态。初始化配置包括配置文件调用、现场产生两种配置模式。配置文件的使用属于静态配置，适用于诸如设备参加字配置、设备合作目标配置、方案预设、目标参数设置等事前已知但随任务型号和发次变化的配置项；现场产生属于动态配置，适用于诸如作业启动项配置、加载模块配置等需要在系统运行中根据需求动态调整的配置项。

错误处理模块是对系统可能出现的各种异常采取的必要保护措施，为保证系统的稳定性和可控性提供技术支持。如系统初始化的异常处理、线程调用的异常处理等。

一般主控模块设计见图2中的伪C代码。

3.2 线程控制模型设计

一个进程通常是由多个线程组成，每个线程又包含若干功能模块，系统执行不同的作业时需要不同的模块参加，协作运行实现不同的功能［5］。为实现进程内不同模块加载的通用性和灵活性，设计线程模块开关，构成模块开关数据结构，在每个作业启动时更新一次模块开关数据结构。每个对应线程所属模块的开关成员通过逻辑值“真（TRUE）”表示参加/“假（FALSE）”表示不参加“当前作业”运行。

线程控制模型设计见下页图3中的伪C代码。

3.3 故障恢复机制

3.3.1 设计思想

图2 一般主控模块设计

在软件运行时，为保证实时性和可靠性，缩短故障恢复时间，实时数据处理软件任意任务程序始终处于1主1备热备份状态，即除了运行该任务程序进行任务处理的节点外，另一节点同时运行该程序，启动任务处理，但不输出处理结果，构成1主1备工作模式。在此过程中，通过心跳线实时监视节点状态，发现节点故障后立即执行任务迁移和恢复，以缩短任务迁移和恢复的响应时间，提高系统的实时性。

3.3.2 任务分配表的设计

任务分配表是主控节点用于向系统内各节点分配任务，是随着节点状态变化动态分配的［6］。任务分配表结构单元设计如图4所示。作业号表示系统执行的作业，用于配置与作业相关的执行环境；节点IP地址是指任务分配节点的IP标识；目标号表示任务分配节点处理该任务的测控目标编号；任务号表示任务分配节点处理的任务，如外测任务、遥测任务等；热备类型表示任务分配节点上分配的任务作为主任务还是备任务运行。

图3 线程控制模型

图4 任务分配表结构单元

3.3.4 故障或异常处理方法

假设当前任务A的主任务分配到节点1上，备任务分配到节点2上。

1）主任务故障时的处理

当节点1上的任务A（主）发生故障，并被控制节点捕获，处理过程如下：

①控制节点通过任务分配表切换节点2上的任务A为主任务类型运行。

②如果节点1是任务故障，重新启动该任务，作为备任务类型运行。

③如果节点1是机器故障，控制节点根据任务分配策略迁移节点2上的任务到其他“活动”节点并作为备任务运行，如节点3分配了任务A的备任务，此时节点2与节点3上运行的任务A重新构成1主1备热备份状态；同时，恢复故障节点的状态。

2）备任务故障时的处理

假设节点2上的任务A（备）发生故障，并被控制节点捕获，处理过程如下：

①如果节点2是任务故障，重新启动该任务；

②如果节点2是机器故障，控制节点根据任务分配策略迁移节点2上的任务到其他“活动”节点，如节点3分配了任务A的备任务，此时节点1与节点3上运行的任务A重新构成1主1备热备份状态；同时，恢复故障节点的状态。

3）主备任务同时故障的处理

假设节点1上的任务A（主）和节点2上的任务A（备）出现故障，并被控制节点捕获，处理过程如下：

①如果节点同为机器故障，在其他“活动”节点上根据任务分配策略重新构成1主1备热备份状态；同时，恢复故障节点的状态。

②如果节点同为任务故障，则同时重启节点1和节点2上的任务，构成1主1备。

③如果1个节点为机器故障，1个节点是任务故障，则将任务故障节点重启为主任务，根据任务分配策略在其他“活动”节点上重新找一个节点启动备任务，构成1主1备热备份状态；同时，恢复故障节点的状态。

4）故障节点恢复时的处理

节点上的机器故障恢复后，向控制节点发送状态包。控制节点收到状态包后向其发送整个系统的配置信息、状态信息等。

节点按照配置信息和状态信息配置好软件状态，重新作为“活动”节点加入到系统中，准备就绪，此时控制节点将根据任务分配策略为其重新分配任务。

4 算法模型库

实时数据处理常用算法在实时数据处理软件中被频繁使用，如果缺少标准算法模型，则是谁使用谁设计编写，导致软件编程人员的重复性工作较多，增加了工作量和软件的复杂度，且软件的通用性较差［8］。算法模型库的设计目的是将实时数据处理常用算法进行标准化处理，统一设计数据处理函数，构建一套标准接口函数库，有利于程序开发和移植。

4.1 常用算法分类

实时数据处理软件中的常用算法主要分以下几类：

1）矩阵计算；

2）坐标系之间的转换；

3）数据异常处理及误差修正；

4）设备数据的定位、求速计算；

5）数字滤波器。

4.2 算法模型库的设计

模型库的基本组成主要有与常量、数据类型和数据结构相关的定义和与算法实现相关的函数。除此之外，为便于编程人员使用，完整的模型库还应包括函数说明、算法功能注释等内容，这些内容虽与模型库的功能实现无关，但对模型库的应用者来说非常重要，相当于模型库的联机帮助文档。

为了提高模型库的可用性，在设计时首先需要制定一个好的命名规则，可以使程序员望名知意，减少注释的繁琐。

比较著名的命名规则是微软公司的“匈牙利”法，该命名规则的主要思想是“在变量和函数名中加入前缀以增进人们对程序的理解”。“匈牙利”法的基本原则是：变量名＝属性＋类型＋对象描述，其中每一对象的名称都要求有明确的含义，可以取对象名字全称或名字的一部分。但“匈牙利”法最大的缺点是烦琐，如果通篇都采用“匈牙利”法，则会使大多数程序员无法忍受。在模型库设计中，采用命名规则的目的是标准化接口设计，因此，对于局部变量的命名，采用绝大多数编程人员认可的共性规则，如“int i，j，temp；”。对于共用结构变量和函数的命名，以简单易用为原则，对“匈牙利”命名规则做了合理的简化，制定以下命名规则。

【规则1】标识符采用英文单词或其组合，便于记忆和阅读。

【规则2】函数名以m开头，后接用大写字母开头的单词组合而成。

【规则3】变量和参数用小写字母开头的单词组合而成。

【规则4】结构名以大写字母开头的单词组合而成。

模型库的设计主要包括接口设计和函数体设计。

接口设计对函数中用到的数据结构进行标准化设计，编程实现时全部采用标准化结构形式调用，这样编程人员只需明确接口形式，就可方便地查询和使用库函数。

函数体设计即算法的程序实现部分，在设计过程中，对函数功能进行合理划分，并保证算法的正确性和计算结果的唯一性。

算法模型库在正式发布前需要从正确性、易用性、精度、容错能力等方面对算法模型进行充分验证。通常，模型库发布后不需要再作维护和修改，可供编程人员直接使用。

对于新算法的扩充问题，由于模型库的设计采用模块化设计思想，易于版本升级和功能扩展，但对扩充的算法模型同样需要严格开展验证工作，之后以新版本进行发布。