动车组故障预测与健康管理（PHM）体系架构研究思考

刘彬，邵军，陆航，李燕，谢名源

（1.中国国家铁路集团有限公司 机辆部，北京 100844；2.中国铁道科学研究院集团有限公司 机车车辆研究所，北京 100081；3.中国铁道科学研究院集团有限公司 电子计算技术研究所，北京 100081；4.中国铁路上海局集团有限公司 科技和信息化部，上海 200071）

0 引言

随着现代装备集成度、复杂度及智能化程度的不断提升，传统故障诊断、维修保障技术逐渐难以适应新的要求，故障预测与健康管理（Prognostics and Health Management，PHM）技术应运而生，并迅速得到各国的高度重视，当前该技术已被视为提高系统“六性”和降低全生命周期费用的关键技术。PHM技术是指利用传感器采集系统的数据信息，借助信息技术、人工智能推理算法来评估、监控与管理系统自身的健康状态，在系统发生故障前对其故障进行预测，并结合现有资源信息提供一系列维护保障建议或决策，是一种集故障检测、隔离、健康评估与预测及维护决策于一体的综合技术［1-2］。PHM是实现预测性维修和自主式保障的技术基础，也是基于状态维修（Condition Based Maintains，CBM）的提升，在有些场合也被称为CBM+［3］。

近20年来，PHM技术已在航空航天、国防军事及工业领域得到了广泛应用。如直升机完好性与使用监控系统（HUMS）用来监控直升机三大动部件状态，提升直升机飞行安全；飞机中央维护系统（ACMS）能够保证航空公司减少飞行延误、航班取消、中途返航和中途换机等事件。在动车组领域，前期法国TGV、德国ICE、英国IC125型高速列车及我国动车组，均依靠关键测点的传感器网络与车载网络控制系统实现了全列动车组关键部件及系统实时状态监控和自诊断。PHM技术应用于动车组，从动车组运用检修各场景需求出发，基于现阶段传感器、数据传输与信息化现状，通过多来源检测监测数据的汇集处理，借助智能推理算法，设计研制开放式PHM系统。一方面能够进一步提升动车组的安全性、可靠性等质量特性，另一方面可实现现有动车组修程修制优化，并为实现视情维修奠定基础。梳理动车组PHM技术国内外研究和应用现状，有助于理清当前PHM技术在动车组中的应用情况，对比国内外动车组PHM发展的差距，为我国动车组PHM技术的发展提供借鉴［4］。

1 RFLP系统建模方法论

系统架构定义是将需求、功能、逻辑和物理架构（RFLP）的概念融合到PHM架构方案的过程，并以系统性建模的方式为PHM体系架构提供指导（见图1）。

图1 系统架构定义过程

RFLP分析方法是现代工程领域著名的正向设计方法之一，几乎所有复杂系统设计研制流程都遵循该理念。RFLP分析方法一经提出，由于其符合顶层设计规律的思路及简单易记的名字，为各种设计方法论所广泛学习和借鉴。具体来说，RFLP要依次完成4个层次的分析：

（1）需求分析：定义产品需求，定义用户想要的产品和服务。

（2）功能分析：定义并分解产品功能，定义为满足客户需求产品需要具有怎样的功能及子功能。

（3）逻辑设计：从逻辑角度设计系统的架构，定义实现系统的逻辑组件及逻辑接口。

（4）物理设计：从物理角度实现系统的架构，定义最终实现系统的物理组件实体及物理接口。

系统架构设计是针对一组系统需求和全生命周期概念构建满足要求的系统属性和特征，系统需求（Sys⁃tem Requirements）需追溯至动车组PHM各业务参与方的细化需要（Stakeholder Needs），全生命周期概念提示需考虑系统的运行和支持全过程。一般来说，系统需求的提出独立于解决方案或具体技术，而满足系统需求的系统架构（主要是物理架构）则是通过具体技术实现，PHM这类复杂系统的技术包括通信与大数据、核心专家知识、人工智能、软件、服务和程序等。

RFLP方法可从系统需求发展到功能/逻辑架构的中间表示，再到后续将核心功能元素分配至物理架构的系统元素。相对来说，功能架构和逻辑架构还保持着与具体技术的独立性，而物理架构则与具体技术相关，需考虑动车组各场景数据交互、运用检修信息、传递流程等，是设计具体方案的过程。

逻辑架构带有可追溯性信息（包括版本历史、父需求、派生需求的系统架构规范），尤其是需求可追溯性至关重要，直接决定了设计是否满足用户需求［5］。如系统报出关键部件故障预测结果后，由输出端推送给用户相关维修建议，现场用户通过系统回填或其他方式将复核反馈、相关更正/预防修结果上传，形成完整的追溯机制，也称闭环反馈。更重要的是，系统设计中的任一环节都可由各层级用户验证，不断进行迭代。

上述活动在构建PHM架构的细节上起着至关重要的作用，功能架构、逻辑架构和物理架构的逐步建立过程，也可以理解为从功能、逻辑和物理视角去理解和定义系统架构。动车组PHM系统具有复杂性、跨学科性，是“系统之上的系统”。其一，PHM系统有自身的功能架构，简单理解为信息采集模块、核心处理模块和输出交互模块；其二，PHM系统监测、管理的对象又是构成动车组的各关键部件及系统，乃至是整车平台，因此不同具体对象系统会带来不同的PHM具体技术［5-6］。一般来说，系统功能架构和逻辑架构定义属于系统虚拟设计范畴，往往独立于具体技术，而对于像PHM这类偏软件集成的复杂系统，功能架构和逻辑架构的定义显得更为重要。

2 动车组PHM架构研究

2.1 需求分析

根据PHM总体需求调研，按用户层级划分，可分为中国国家铁路集团有限公司（简称国铁集团）、铁路局集团公司、动车段3个层级；按业务范畴划分，可分为模型构建、业务管理、应急监控、数据分析等（见图2）。

图2 动车组PHM系统用户层级与业务划分

（1）国铁集团用户需求。依托系统查看全路动车组及其关键配件全生命周期健康状态；督促、监管系统预测故障的后续处理；开展数字化精准维修，推动动车组造修水平提升，构建中国特色现代化动车组运维标准体系；根据健康状态评估，指导动车组系统优化，推进我国动车组造修技术进步。从业务维度划分，该层级用户以业务管理为主，负责系统统筹规划、相关方活动参与及职责划分；同时从模型构建的角度，调动各研发单位积极性，统筹模型管理、优化迭代策略。

（2）铁路局集团公司用户需求。依托系统监控、掌握铁路局集团公司配属动车组的健康状态；跟踪、分析系统一定时间范围内的多源故障成因及后续处理情况，依据故障等级组织开展应急指挥、预警故障复核确认及视情维修工作；组织、落实开展检修项目、内容、周期优化工作。从业务维度划分，铁路局集团公司用户在业务管理方面根据对配属动车组健康状态的把控动态调整相应运用检修工作，并依据相应关键部件的模型报警结果制定处置方式；同时，可从运用经验出发提出模型需求，并参与相应部件模型研发工作。

（3）动车段用户。依托系统监控、掌握配属动车组健康状态，根据不同状态等级具体落实应急处置、安排后续维修策略并反馈结果，完成预警预测的闭环管理；落实检修项目、内容、周期优化工作。从业务范围而言，动车段用户需实时关注PHM系统预警报警结果，对于与安全直接相关、影响较大的部件报警及时进行处置；对各级报警结果进行数据层分析复核、检修层作业检查；也承担模型初上线的实车验证工作。

2.2 核心功能架构

研究动车组PHM技术体系时，一方面需充分考虑现阶段动车组各环节信息化（包括CBM）技术现状，包括各车型、各系统传感器布局、检测监测信息传输能力、车地通信水平、地面数据汇集与治理效率；另一方面需针对动车组新造、运用、检修场景产生的数据特点进行分析，才可确保各场景数据层交叉融合，满足模型有机运转需求，最终实现诊断与预测、辅助决策各级用户需求。因此，技术体系研究需综合考量现有动车组检测监测体系下动车组造修与运用中产生的多源数据、各业务场景的车地传输环节和车地通信技术现状、PHM系统信息层中模型部署技术及模型预警/预测信息全流程贯通要素，最终形成技术体系的逻辑架构与物理架构。

通用复杂系统信息流传输架构主要从具体系统的业务层级出发，描述了从数据采集、传输到应用层的状态监测、健康评估及最终给用户呈现输出等全部链路。动车组PHM系统有数据采集和传输、数据处理、状态监测、故障预测、维修决策、健康评估和系统输出等主要功能模块（见图3）。

图3 动车组PHM系统功能信息流

（1）数据采集和传输：主要通过各类传感器收集部件、设备的相关数据或获得其他系统的基础履历、新造设计、维修与环境数据。

（2）数据处理：从上一层信息流接收数据并对其进行清洗、治理、特征提取等处理，使数据符合后续模型或算法的使用要求。

（3）状态监测：多指在运行中的单一系统或设备中，针对某几项的检测监测参数，结合专家知识库进行阈值与逻辑组合判断。

（4）故障预测：以模型为载体，针对多设备或系统的运行参数、基础履历数据进行特征提取及模型综合研判，也可结合环境参数进行综合故障预测。

（5）维修决策：也称决策支持，是基于历史状态信息、维修履历，进行部件状态评估，在系统或设备性能退化或失效之前提供有效的维修措施。

（6）健康评估：对部件、设备和整车结构等的健康状况进行量化，预测其未来状态趋势。

（7）系统输出端：即以可视化或系统接口方式实现的结果展示与表达，一方面可以信息化的形式将预测结果或健康趋势以友好的图形方式展示给最终用户；另一方面，PHM系统将结果以信息化推送的方式传递给其他业务系统，或直接对相关设备进行控制。

根据以上通用信息流架构，结合动车组PHM数据、功能和动车组各场景全生命周期业务，梳理出PHM系统核心业务功能架构（见图4）。自左至右各模块分别实现以下业务功能：

图4 动车组PHM系统核心业务功能架构

（1）状态监测模块是对全路动车组上线状态及运行状态进行实时监测。

（2）故障预测模块是对动车组故障早期的提前预判，以便及早采取措施确保安全。

（3）健康状态评估主要负责根据各项指标对动车组功能状态进行综合评估。预测结果和健康评估结果结合动车组运行计划，在故障发生前提出合理的维修建议。

（4）决策支持（视情维修）是基于历史、状态和维修数据等对部件进行剩余寿命预测，在部件出现潜在故障风险前及时进行维护、更换。

（5）模型管理模块是将各研发单位研发的模型进行统计，方便查看各模型适用车型范围及报警相关阈值的界定范围。

此外，考虑到数据集成、数据质量、安全和平台的需要，PHM系统还要有数据交换接口、账号管理、资源管理和任务管理功能。数据交换接口模块确保在不同系统之间可有效交换数据；账号管理模块提供账号管理功能，以及鉴权和授权；资源管理模块负责管理和调度平台资源，提高整个系统的资源利用率；任务管理是监控和管理不同计算任务的模块。

2.3 业务逻辑架构

动车组PHM系统重在识别和管理故障的发生、规划维修和决策保障，是提高动车组运用效率、提升检修质量、降低维修成本、优化修程修制、推动技术发展的重要技术手段。面向动车组线上应急处置、日常运用管理、高级检修管理和健康评估管理4种业务场景，PHM系统与相关系统之间的交互融合体现在3个方面：

（1）动车组管理信息系统（EMIS）。EMIS是动车组信息化管理的统一平台，PHM系统依托EMIS中动车组履历、构型、故障、运用、检修、交互式电子技术手册（IETM）等数据进行模型计算，将产生的故障预测结果、预测性维修建议、健康评估结果等在EMIS检修生产各环节进行落实与执行，并将EMIS中生成的故障复核与处理、检修作业实绩等信息进行反馈，支撑PHM系统各类模型的迭代更新。

（2）多平台行车安全监测系统。行车安全监测系统作为PHM系统的重要数据源，依托PHM系统跨业务域的数据汇集和基于并行计算的数据处理能力，实现对动车组车载信息无线传输系统（WTDS）及动车组滚动轴承故障轨边声学诊断系统（TADS）、动车组运行故障动态图像检测系统（TEDS）、动车组运行品质轨旁动态检测系统（TPDS）等监测系统数据的实时采集处理；并通过与应急指挥和EMIS的联动，实现故障的预警预测和对动车组及其部件的健康评估，完成故障预测、应急处置和故障处理的流程管理。

（3）主机企业与核心供应商。动车组生产制造企业内的系统，作为动车组构型、履历、IETM各类手册等数据的参与方，通过与EMIS交互，实现对PHM系统的支撑，也是PHM系统输出的设计制造优化建议的执行载体。

动车组PHM系统逻辑架构见图5，通过传统方式描述了动车组PHM系统各业务场景中与外部数据交互流程、系统内部数据流转过程，与国铁集团（铁路局集团公司）用户、主机企业（核心供应商）和模型研发单位等PHM系统参与方的业务活动流程［7］，以及相关核心PHM系统元数据处理技术、模型封装技术和评价与验证技术，构成完整逻辑架构。逻辑架构自左至右描述了PHM系统的信息传递流转过程，其中数据源涵盖目前动车组检测监测体系下，车载WTDS、轨旁安全监测设备（TEDS、TADS、TPDS等）及根据《动车组技术履历信息采集技术规范》约定的入段自动化检测设备数据。

图5 动车组PHM系统逻辑架构

同时，考虑未来模型跨专业分析研判、跨交路应用，考虑纳入跨专业及外部环境数据。逻辑架构的中、下部框架简化描述了为支撑服务PHM系统的数据源汇集、并行处理的功能：

（1）具备大数据获取、存储、处理和应用能力的信息化技术框架，目前规划应用的有Hadoop、Storm、Spark等利用ETL、数据仓库、分布式并行计算等高效的大数据处理技术。可简单理解为数据汇集、清洗处理的环节［8］。

（2）模型封装与部署方面，拟采用容器式和任务流式部署以对比其效率，2种方式都可实现模型程序在系统中的运转，但各有优缺点。容器式部署方式利用容器技术，将模型程序及其运行所需的环境组件封装成容器，并通过k8s对容器组件进行管理，具有统一的管理页面，使得各容器间资源相互隔离，不会相互影响，但在Windows环境下日常管理的复杂度较高，且每个容器占用的系统资源较高，其优化方式有待进一步深入研究。任务流式部署方式利用调度工具实现模型程序的管理，方式较为灵活，可针对不同运维、管理技术需求的模型进行独立维护，且系统资源占用较为均衡。具体部署方式需要在后续的试验与验证阶段评价优劣及适用度。

2.4 信息化物理架构

动车组PHM系统定位于车辆管理中的动车组管理部分，是整个动车组信息化保障体系的重要组成环节，从系统建设方面也可理解为EMIS主要功能架构的延伸，服务于运用检修主体业务。动车组PHM系统依托分布式存储、分布式计算、数据仓库、数据挖掘等技术，打造集“易用性、伸缩性、开放性”于一体的系统平台，满足用户量高并发和高可用；基于数据标准化、业务集成化、应用平台化、模型组件化的设计理念，采用统一的应用开发框架，定义标准的软件开发测试规范、安全管理规范、运维规范，实现基于云化、分布式和服务化的技术架构。自下向上整个架构划分为数据接入层、基础设施层、平台层和应用层（见图6）。

图6 动车组PHM系统物理架构

2.4.1 数据接入层

数据接入层可通过铁路内部服务网（简称内网）从机辆信息管理平台、数据服务平台获取路内既有支撑系统数据，主要包括运用检修数据、检测监测数据；通过互联网、铁路外部服务网（简称外网）获取主机企业及关键设备供应商数据，主要包括新造、设计与构型数据、高级修相关数据。通过内、外网实现跨平台、跨网络、跨系统多源异构数据的接入。

2.4.2 基础设施层

基础设施层支撑PHM系统硬件资源调配及网络链路安全。主要通过对基础计算、存储、网络资源的池化和虚拟化，为上层应用与服务提供统一硬件资源调度和监控管理，支持按需分配与动态扩展（硬件资源），并通过标准化接口向上层提供计算、存储等基础服务，提高IT资源的易用性、敏捷性。依托国铁集团主数据中心服务器集群，实现海量数据的存储与计算，缓解资源压力，提升服务器整体性能［9-11］。通过高稳定、高带宽的网络链路，实现网络资源的高吞吐、高可用、低延时。同时，根据国家网络安全等级保护要求，通过边界防护、入侵防范等技术手段，确保基础设施安全可靠。

2.4.3 平台层

平台层包括数据平台层和集成平台层。数据平台层面向数据处理关键技术，实现数据采集、数据抽取、数据存储和数据分析挖掘，通过资源调度、多租户管理等手段，打造松耦合、高效和高可用的数据支撑平台；集成平台层通过关系型数据库、内存数据库、安全认证及报表组件等，提供服务运行环境与模型管理，实现中间件服务，面向应用开发，提供安全可靠的平台支撑。

（1）数据平台层。根据数据结构、类型、量级及状态的不同，实现多源数据采集功能。例如，对于时效性、并发性（保证3 000多列动车组同时传输）要求极高的WTDS数据，采用分布式消息队列解决系统实时、高吞吐量的流数据问题，采用分布式发布订阅机制，依托消费组、主题、分区等技术，满足数据的实时、并行处理要求［9-13］。同时，对于通过关系型数据库获取的EMIS构型履历、高级修信息等静态数据库，多采用分布式文件系统，具有高容错性、高吞吐量的特点。

根据数据规模、结构、类型、状态的不同，PHM系统提供了不同的数据存储方式，主要采用数据仓库、非关系型数据库及关系型数据库，既保障了系统应用的响应时间，也满足了海量数据的存储与批量计算。同时，分布式协调调度组件提供集群利用率管理、资源统一管理、数据共享、配置维护、分布式同步、选举Leader等功能，实现数据平台的高效、稳定运行［8，14］。面向主题的、集成的、随时间变化的但信息本身相对稳定的数据集合，可将海量数据进行多维建模，并通过加工、汇总和整理，形成数据仓库，用于对管理决策过程的支持，包括OLTP和OLAP分析。

（2）集成平台层。描述了PHM系统提供的多开发语言和运行环境，包括Java、Python、JDK环境、API管理工具及应用中间件服务等；搭建基于内存键值对存储的分布式内存数据库，将静态数据和热交互数据在分布式缓存和数据网格中存放，实现性能方面的快速响应；通过电子证书、数字签名等身份认证机制，确认操作者身份及对特定资源的访问和使用权限，确保系统访问策略可靠、安全；使用报表组件，实现动车组故障统计分析、健康状态统计、部件寿命到限分析等功能；使用开源的JS图形库辅助开发，如D3和Echarts等工具对数据分析的结果集进行图形化展示，清晰有效地传达与沟通信息；基于模型管理工具，方便快捷地实现已封装自定义模型的申请、注册、部署、运行、监控管理，实现自主建模模型的引用、转换、演化等。

3 动车组PHM系统验证与熟化

动车组PHM系统的验证与确认工作在开展初期，关键一步是确定一套科学合理且适用于动车组PHM系统特点的顶层工作流程规划，形成标准规范指导动车组PHM系统验证与确认顶层工作（见图7）。然后根据各阶段的验证确认活动，结合具体对象进行详细活动的方案设计与实施。

图7 动车组PHM系统工程验证与确认

当前装备系统设计研制的流程通常基于系统工程的指导。系统工程是涉及多学科的复杂系统在综合考虑各种约束条件下达到最优的方法和手段，其核心思想是在产品开发周期的早期阶段进行需求分析与系统功能分析，并进行设计综合和系统验证。动车组PHM系统的设计研制及验证确认也应确保在系统工程思想的指导下进行。

确认活动是针对PHM系统在设计研制等过程中的要求进行确认，目标是保证要求的正确性和完整性。理想情况下，在设计执行开始前应对所有要求进行确认，但对于动车组PHM这种复杂集成系统，确认成为研制周期内正常且持续的阶段性过程，即每个阶段的确认活动都会保证系统研制朝着预想的方向进行。

验证是通过一系列活动证明所研制系统是否满足所设定的需求和要求，即该系统被正确开发，常用方法包括符合性说明、计算/分析、安全评估、试验验证和类比推理等，解决“验什么”“何时验”“怎么验”的问题。因此动车组PHM系统的验证与确认工作在系统工程的指导下，根据动车组PHM系统特点，形成验证与确认流程，用以在合适时机对待检查对象进行需要的验证确认工作。

确认包括在方案阶段用户直接提出的需求和后续各系统详细设计时分配的需求，并明确PHM系统的最终目的，形成平台级的验证确认指标。在进行PHM系统总体设计时，需对设计类文档进行确认审查，对上级分解需求进行确认，并构建初步的验证策略和评价指标体系，主要针对平台级。设计阶段结束后，PHM系统进入工程研制阶段，包括软硬件开发、制造和组成，该阶段的验证主要为软硬件的功能验证及确认，如传感器性能验证测试、数据采集功能及接口验证，该阶段形成了PHM系统的核心算法群，需对算法性能进行验证，包括诊断功能、预测功能及相关评价。对于动车组PHM系统决策支持、运维分析等输出层的核心功能，需对PHM系统与其他平台系统的交互功能进行验证，保证其能够实现决策支持的能力，并对PHM系统作出综合评价。PHM系统在完成设计研发投入使用后，其日常的运行及维护可能会通过数据积累对算法及相关软硬件进行迭代优化，则需考虑需求更新的确认及算法迭代后的更新验证。

4 结束语

采用RFLP系统建模方法，从业务需求、核心功能、逻辑框架和物理架构等方面进行了动车组PHM体系架构研究，并从方案设计、系统研发和验证熟化3个阶段对动车组PHM系统相关技术要素进行了归纳梳理。通过系统工程的正向设计，PHM系统可以更好地集中行业各参与方优势，使其在动车组检修运用各场景中发挥作用。后续将根据动车组技术发展、运用检修需求和各层级不同业务用户反馈，持续完善动车组PHM系统建设，针对系统核心功能、各类模型不断优化迭代，支撑动车组的安全运用和智能维修，促进动车组造修技术发展。