装备CBM 与IETM 智能维修系统的集成研究*

杜晓明，郭德兴，朱 宁，姜相争

（1.陆军工程大学指挥控制工程学院，南京 210007；2.陆军工程大学石家庄校区，石家庄 050003；3.解放军72456 部队，山东 潍坊 261305）

0 引言

随着基于状态的维修（Condition Based Maintenance，CBM）、故障预测与健康状态管理（Prognostic and Health Management，PHM）等概念的提出，当前装备维修由以手册为中心的事后检测发展为以信息为中心的状态监测与分析，先进的分析技术集成于装备及其服务中，对应系统亦被称为赛博物理系统（Cyber-physical Systems，CPS）［1］。CPS 在装备维修领域的典型应用便是基于交互式电子技术手册（Interactive Electronic Technical Manuals，IETM）的智能维修系统。IETM 拥有大量装备基本原理、使用操作和维修保障等数据，可以构成一个数字化的装备信息空间，为装备使用保障人员提供交互式的推理决策支持，因此，装备故障诊断与修复是其中一项关键内容。

目前，该方向研究的热点之一是如何完善CBM/PHM 与IETM 系统的有机集成，以提高装备故障诊断的高效性与准确性。对此，学者Cooper 率先提出了基于IETM 和CBM 的自适应诊断与单兵技术支持系统［2］，后续美军给予重点关注，开发类似“虚拟维修系统”、“智能维修系统”［3］。美海军在给V22 鱼鹰飞机开发的综合自动维修环境优化系统（CAMEO）中实现了IETM 系统与其地面数据站的信息集成，F-22 战斗机IETM 通过与其CBM 系统集成，实现5 级IETM 功能［4］。国内李磊、吴永明等提出在现有IETM 框架下进行功能扩展，实现与故障诊断系统和专家系统的融合［5-6］。Gang Niu 等则提出了模糊语义推理和状态融合诊断相集成的IETM 智能维修系统［7］，上述系统或方法主要关注两方面，一是加强CBM 与IETM 之间的数据共享，二是基于CBM 数据增强IETM 的推理能力。这些研究工作虽给出了CBM 与IETM 集成的不同思路与实践，但还存在两个方面不足：一是方法面向具体系统或开发商，系统紧耦合，接口协议、数据定义专用，缺乏普适性；二是集成定位较为笼统，没有精准区分其层次。为使基于IETM 的智能维修系统接口更具通用性和针对性，本文提出了一种符合OSA-CBM 规范的CBM 与IETM 集成框架，架构将集成应用分为4 个层次，支持分布式部署，能与各型CBM 子系统实现统一交互，有效解决系统间的紧耦合问题，显著提升系统功能的重用性和多系统间的互操作性。

1 CBM 与IETM 集成框架

CBM 系统通过收集装备运行参数，对数据进行系统分析、处理和评估，查找装备故障点或劣化点，评估装备健康状态，并给出维护建议。根据对装备实施监测评估的深度，CBM 系统应用大致可分为以下3 个等级［8］：

一是加装部分数据采集器，或配备手持状态检测仪器，从装备采集状态数据，并由检测人员根据装备当时状态评估其工作状态，确定维修方式。

二是内置数据采集传感器，其具有一定数据处理、状态评估和报警功能。此类系统能在数据超过阈值，或在故障发生或即将发生时，进行报警。此类警报可以故障代码的形式出现，通过警报现象、故障代码和数据值进行故障隔离。

三是带有智能化故障诊断装置，不但能够进行故障报警，还能通过专家系统作出故障诊断，装备健康评估，预测装备寿命和未来的故障模式，给出维护建议。

根据CBM 系统实现等级的不同，IETM 与其集成的框架如图1 所示，可分为4 个层次。

1）基于故障警报的集成。由CBM 系统提供警报现象或故障代码，IETM 从CBM 中获取装备数值数据、特征值、状态数据等数字形式的数据，基于IETM 故障数据模块，以交互式故障诊断方式实现故障定位，并提供维修支持；

2）基于故障定位的集成。由CBM 给出故障定位信息，IETM 从CBM 中读取故障代码，基于IETM故障数据模块中的故障数据报告，直接为CBM 系统提供维修程序支持；

图1 IETM 同CBM 系统集成框架

3）基于维修决策的集成。依据CBM 系统提供的维修决策报告，通过IETM 维修过程数据模块，直接提供维修所需的零部件、工具、人员、维修等级等卡包信息和维修程序信息；

4）基于状态数据的故障预测集成。在装备未发生故障时，通过IETM 过程数据模块直接读取CBM系统提供的状态数据，如日志信息和健康信息等，由IETM 直接进行故障预测，辅助装备维修。

2 OSA-CBM 规范

为降低CBM 与IETM 系统在集成中的耦合度，提高互操作性，CBM 与IETM 之间的交互机制须有一种标准开放的协议，这样既能实现IETM 与同一CBM 系统各组件之间的互操作和信息共享，又能实现IETM 与不同产商CBM 系统间的互操作，从而解决传统集成过程中因不同标准重复开发通信框架的问题。

由MIMOSA 管理与发布的CBM 开放体系结构（Open System Architecture for CBM，OSA-CBM）是实现CBM 系统互通互联的国际标准［9］，它将CBM 系统的数据处理功能分为6 层，如图2 左侧所示，底3层与装备状态监测密切相关，上3 层与人员判断决策相关，每层功能块可分布部署，亦可集中部署。它规范了CBM 数据处理模块之间的数据交换机制，实现了与具体数据传输技术的脱耦，解决了不同供应商提供的CBM 系统组件之间集成问题，免去了通信框架的重复开发。OSA-CBM 规范分为信息规范和通信规范，使用统一建模语言（UML）定义，可采用多种编程语言和中间件技术实现，供应商和集成人员可采用与其环境相适配的技术来实现该标准。

2.1 信息规范

OSA-CBM 信息规范定义了传输的数据类型，主要有4 种，包括：结果数据（DataEvent）、配置数据（Configuration）、说明数据（Explanation）和扩展数据（Extensible）。

配置数据定义了CBM 功能模块的输入数据源、数据处理算法描述、数据输出目标模块、数值的单位和阈值等元信息；说明数据则对CBM 功能模块如何生成输出进行了数据说明；扩展数据仍然不成熟，在规范中没有很好地定义；结果数据则是由OSA-CBM 功能模块生成的事件集或数据集，即装备状态监测数据（如测量值），处理或评估过的结果数据等。

结果数据的类型与CBM 功能模块类型密切相关，不同功能层产生不同类型的结果数据，如图2所示。DA 数据是被格式化的传感器数据，此类数据具有一致的格式；DM 数据是由DA 数据转换后的一个或多个有意义的特征值；SD 数据是将DM 数据与期望值进行比较，得到的计算条件指标［10］。HA、PA 和AG 数据分别是装备当前的健康状况、未来故障预测以及维修建议等。

图2 OSA-CBM 功能层与DataEvent 的关联

通常情况下，CBM 系统由多个分系统分布部署，每个分系统可包含上面定义的一种或多种功能层，提供一个或多个功能层的接口，允许输出一种或多种类型的数据。

2.2 通信规范

针对CBM 功能模块之间数据传输、信息交换，OSA-CBM 规范定义了4 种通信类型，包括同步、异步、服务和订阅。这些机制遵循客户端-服务器调用访问模式，即提供数据的CBM 功能模块为服务器，而接收数据的CBM 功能模块为客户端。

1）同步：客户端通过调用向服务器申请数据，服务器直接返回数据，如通过HTTP 请求提取Web XML 模型数据。

2）异步：客户端数据申请与客户端接收数据要通过两次独立的访问完成。该机制允许任意数量的上层模块在需要时建立与下层模块的双向连接，可设置有3 种通信模式，一是根据请求而返回数据；二是出现警报而返回数据，例如某参数超过阈值；三是全部推送，无需事先请求，下层模块将每次收集的数据推送至所有连接的更高层模块。

3）服务：客户端无需申请，就会被动地接收服务器发送的数据。

4）订阅：客户端需向服务器订阅数据，服务器才定期或在出现警报时发送数据给订阅者。

3 CBM 与IETM 集成接口

为了捕获CBM 系统的结果数据，IETM 系统同样需遵循OSA-CBM 规范。本文选择订阅通信机制作为IETM 同CBM 系统集成的数据传输接口，并采用基于组件的框架设计方法，将IETM 系统和CBM系统内部处理功能和接口功能相分离，如图3 所示。在集成接口模型中，定义了访问入口和数据队列两类组件。

图3 CBM 与IETM 系统集成接口模型

3.1 接口设计

3.1.1 访问入口

订阅通信机制下的访问入口有两种类型：即数据服务入口DataEventServer 和数据接收入口DataEventReceiver，如图3 所示。DataEventServer 是CBM 服务器模块向CBM 客户端模块提供数据的访问接口，DataEventReceiver 是CBM 客户端模块接收CBM 服务器模块数据的接口，接口设计采用观察者模式。DataEventServer 提供了添加和删除观察者对象DataEventObserver 的功能，每个DataEventServer可关联任意数量的观察者。CBM 客户端模块为获取服务端推送的数据，须通过DataEventServer 接口提供的观察者注册功能，成为DataEventServer 的一个观察者。成功注册后的观察者包含了对客户端模块中DataEventReceiver 接口的一个链接，待服务器模块准备好数据时，即可触发DataEventReceiver 通知提取数据。

3.1.2 数据队列

IETM 模块可视为OSA-CBM 服务器的数据客户端，负责接收来自于CBM 系统模块内处理生成的数据，数据类型覆盖6 类不同功能层模块。为保证数据处理与数据收发能够并行进行，在集成接口模型中引入数据队列概念，以实现CBM 服务器与IETM 系统间的高效通信。当服务端有数据准备完毕或有警报时，则将相应数据事件（dataEvent）插入到CBM 服务端数据队列，并通知IETM 系统接收数据，IETM 系统通过DataEventReceiver 接口接收服务端推送的数据，并将其置于IETM 客户端数据队列。

3.2 接口通信模式

集成过程中，模块间数据通信采用观察者模式，模块内数据通信采用生产者/消费者模式。

图4 CBM 数据服务器的观察者模式

CBM 功能模块与IETM 系统间的数据通信采用观察者模式，如图4 所示。在该模式中，IETM 系统模块根据所要数据需求，确定要连接访问的CBM服务器模块类型， 并通过该模块提供的DataEventServer 接口注册为该服务器模块的一个数据观察者DataEventObserver。当CBM 服务器模块准备好新数据或某状态值超过阈值发出警报时，DataEventServer 就会在观察者池中找到已订阅的观察者对象，如IETM 系统，通知其提取数据。IETM 系统在得到数据更新事件后，判断该数据是否在其感兴趣的主题列表中，如是，则会使用关联的DataEventReceiver 接口提取相关数据。

CBM 模块内和IETM 系统内部采用生产者/消费者模式，如图5 所示，以解决数据接收与数据处理之间可能存在的阻塞问题。例如，当IETM 系统要提取CBM 模块发送的数据时，IETM 的DataEventReceiver 接口负责从CBM 数据服务器模块接收数据，是数据的生产者；IETM 逻辑引擎要基于接收的数据进行故障推理判断，是数据的消费者；数据队列则用于接收和处理数据的缓冲区。

图5 IETM 系统的生产者/消费者模式

数据队列对象将IETM 系统内部的数据处理功能与对外的数据通信功能相分离，以支持IETM 系统DataEventReceiver 接收新数据的过程与IETM 逻辑引擎处理数据的过程两者可并行实施。

4 应用验证

基于上述集成框架及集成接口算法，以液压故障模拟实验平台为基础，构建了IETM 系统与CBM系统的集成应用框架原型，如图6 所示。其中，振动信号采集系统与内置信号采集系统实现OSA-CBM第一层功能，负责采集液压平台的振动、压力、温度、流量及转速等信号，并经网络传至CBM 数据处理服务器；服务器实现OSA-CBM 一层以上各功能模块，包括信号处理、特征处理、故障报警及维修决策等；IETM 系统则根据状态信号、故障代码、维修决策指导实施故障修理。作为CBM 的客户端，IETM既可获得数据处理服务器提供的上层判断决策数据，亦可直接获取采集系统的底层状态数据，自行展开故障推理。上述采集系统、CBM 服务器与IETM系统三者分布运行，但共同基于OSA-CBM 标准集成框架。

下页图7 显示液压故障模拟平台在报警后的一类处理过程：IETM 系统连接CBM 数据处理服务系统，获取平台故障代码及与相关装备具体状态参数，基于以上信息，IETM 辅助维修人员定位故障原因，并根据所链接的故障维修模块，指导维修人员完成故障部件的更换。

图6 IETM 与CBM 系统集成应用框架原型

5 结论

CBM 与IETM 两者都是装备保障的重要支撑技术，CBM 在获取装备状态数据、实施健康评估和维修决策辅助等方面具有优势，但缺乏详细的装备保障数据支持，而IETM 却能提供完备的装备技术数据和保障过程数据，两者的集成发挥了各自在装备维修保障中的优势。文中给出的集成框架既保证了IETM 能获得CBM 提供的不同层面数据，也保证了集成的通用性和互操作性。框架后续的具体实现可采用各类中间件技术如CORBA、COM／DCOM、.NET、XML 等。框架结构具备的可重用特性，可大大减少两系统间通信机制的开发时间，使开发者更能集中于CBM 系统和IETM 系统功能开发设计上。

图7 CBM 与IETM 系统集成应用实例