PHM技术梳理-2

2. PHM系统架构

首先，我们看看预测与健康管理系统架构。PHM具体架构在ISO 133741、ISO 13374-2、ISO 13374-3、ISO 13379、ISO 13381等标准中都有比较清晰的定义，这些架构都是通用性的OSA-CBM架构定义。在航空里面，SAE ARP 6803等一些标准中也都有对应的定义。时间关系，我们不展开讲这些架构。我们简要讲讲在航空上，这种架构怎么实现。也就是说PHM系统架构中的状态感知、故障检测、故障诊断、健康状态评估、故障/剩余使用寿命预测、维修决策分别在哪里实现？如何对这些技术进行集成。下面的这些内容是参考性的，很多内容属于是“学院派”的，有很多理想化的设想，可能与技术真正装机仍有一定的距离，咱们都可以讨论。

航空领域中，PHM体系架构包含了机载健康监测部分和地面维护部分。两部分之间通过空地数据链，或者在地面通过有线方式进行数据传输。在机载部分主要实现飞机系统的状态感知、状态评估、故障检测和故障隔离功能，具体功能实现过程和信息综合过程依赖于飞机航电系统的架构形式。地面维护部分是一个分布式的数据存储、健康状态评估、故障预测和维修决策系统。
只要讲到PHM在航空上的应用，大家一定要提F35的PHM架构。从很多文献中都能找到这张图，只不过有些文献中这张图是中文的，有些是英文的。由于没有更详细的技术资料，我们仍然难以窥见F35上信息的综合过程。只看这个图的话，和通用的PHM架构没有什么区别，所以对我们没有多大的参考。我始终觉得一个PHM架构是否合理，和信号综合过程的层次是否清晰，数据是否完整直接相关，至于具体用了什么算法和模型实现诊断与预测，由所掌握的数据量和数据质量来决定。因为没有F35系统设备的架构图，我们没办法去猜。我们拿民机B787作为例子来看看。

波音的PHM架构包含了机载（Onboard Maintenance System, OMS）系统、波音运营中心、航空公司运营中心等几大部分。其中机载部分又包含了中央维护系统CMS、飞机的状态监控系统（Aircraft Condition Monitoring System, ACMS）、波音电子飞行包，主要是电子日志数据等，这些系统的信息由飞机ACARS（Aircraft Communications Addressing and Reporting System）发送给波音运营中心和航空公司运营中心。或者飞机回到地面后，通过有线数据连接的方式将数据读取传送给波音运营中心和航空公司数据中心做排故、预测等。时间有限，我们不展开了。下面我们简要开看一下B787机载中央维护系统。


飞机上主要还是以监控和诊断为主。这个图是B787现有的中央维护系统的架构。在B787左右两个CCR（Common Computing Resource）机柜中各有一块GPM（General Processor Module），上面运行中央维护计算功能CMCF（Central Maintenance Computing Function）。在之前的波音系列飞机上，有专门的中央维护计算机。B787上不再是独立的中央维护计算机了，而是具体的APP应用。一块运行CMCF的GPM上，同时还在运行着其他应用。比如左侧机柜中的GPM上除了CMCF，还包括机组告警、起落架-前轮转弯系统管理、舱门控制等功能应用。而一个CMCF包含了数据收集、数据通信管理、飞机状态监测、故障显示和机组报警等功能。CMCF通过机载ARINC 664网络收集来自于各机载子系统的检测结果。从现在公开的资料来看，看不出来CMCF使用了多么复杂的算法，更多的是故障逻辑。对机载子系统更加复杂的故障检测和诊断算法是机载设备的供应商实现的。比如，大家有时间的话可以去看看霍尼韦尔的报告《Interfaces for Sensory Prognostics and Management Systems》。对于CMS系统来说，机载子系统的检测结果相当于BIT的结果，它通过RDC接口发送给CMCF故障代码。



地面的维修部分由于没有太多的资料，我们不再介绍了，大体的架构可以参考下面这个图。

大概总结一下，飞机上的检测和诊断一直为保证飞机的飞行安全起着重要的作用。如果说飞机上的检测和诊断面临的比较大问题是什么的话，我觉得还是在飞机的中央维护系统顶层的跨区域和跨系统信息综合方面不是很充分。因为飞机上的机载设备的检测和诊断主要是由设备的供应商实现，飞机的中央维护系统收集各机载设备的BIT结果和关键飞行参数，通过逻辑判断进行故障决策。如果把各机载设备的BIT检测结果作为一个个独立事件来看的话，很容易陷入“头疼医头，脚疼医脚”的窘境。有相关的研究资料表明，在飞机的飞行过程中，航电系统检测到的异常事件中，有85%以上的事件是NFF（No Fault Found）事件，也就是说是飞机在地面上无法发现(复现)这些异常事件。这些NFF事件的发生有多种情况，有些是飞行过程中特定的飞行环境条件导致的异常，只不过造成这些异常的飞行环境在地面上复现不出来，所以记录到的异常就发现不了。另有可能性是BIT设计不合理导致的虚警事件。现有的机载系统故障检测和诊断中交叉校验机制并不完备。而实际上，飞机系统是一个复杂的功能有机体，很多故障的发生发展存在级联效应和传播机理。这种故障级联效应伴随着信号的传递和功率传递发生着。比如，我们拿飞机的动力与作动系统来看，发动机附件机匣输出的能量通过系统中的元部件进行一级级的转化和传递，最终推动舵面运动。在这个过程中，每一个元部件的内部状态决定了能量的分配和传递状态。从这张图中我们可以看到，在这个系统中存在着多个传感器，这些传感器的检测结果实际上反映传感器所在区域能量分布的某一项特征。我们来看，在这个系统里面，故障发生后改变的是什么？通过仔细分析可以发现，故障发生后实际上改变的是系统中的能量分布。由于能量传递是守恒的，因此系统中一个故障的发生导致某一区域内能量分布变化，会在多个传感器的检测特征上体现出来。所以通过对传感器检测结果进行合理的特征提取、特征构造、特征融合，就有可能实现多源信息融合的故障诊断，从而提高故障诊断的准确度，避免因“头疼医头，脚疼医脚”带来的诊断精度低、虚警高的问题。


这一点上，有点像咱们的中医诊病理论。中医诊病理论是从人体整体的经脉运行角度出发判断人体病症所在的位置。所以，有好多研究从中医方法论的角度研究故障预测与健康管理，比如：《基于中医诊断理论的航空发动机故障诊断技术》等论文。

(未完待续……)