2. 高端装备PHM需求分析与指标定义

PHM系统不是先选算法再找场景,而是从装备任务与故障后果出发,把“需要知道什么、需要多快知道、知道后能做什么”逐层转化为可设计、可验证的系统指标。本章围绕任务剖面、FMEA、R/M/A指标、功能与非功能需求,以及需求到指标的转化方法展开。

一、任务剖面:需求的起点

任务剖面描述装备在一次完整任务中经历的环境、工况、载荷与时间序列。以某型舰载燃气轮机为例,其任务剖面可划分为:冷态启动(0~3 min,转速0→额定,热应力最大)、巡航(2~6 h,稳态高负荷)、机动变工况(频繁加减速,转子与叶片交变应力)、停机冷却(热梯度反转)。PHM需求必须绑定到这些阶段:启动阶段关注启动失败与热部件裂纹,巡航阶段关注效率衰减与轴承磨损,机动阶段关注喘振与叶片高周疲劳。

任务剖面应量化为“阶段—时长—环境—关键故障敏感项”的对应关系,而不是笼统写“长期运行”。只有明确各阶段占比与严酷度,后续FMEA和指标分配才有依据。

二、FMEA:从故障模式到PHM监测对象

FMEA按“故障模式—原因—局部影响—最终影响—严酷度—检测方式”展开。以燃气轮机为例:

故障模式原因最终影响严酷度PHM可监测征兆
主轴承磨损润滑失效、颗粒污染转子卡滞、任务中断Ⅱ类(严重)振动频谱边频、油液金属屑、温度上升
压气机叶片结垢进气盐雾、灰尘效率下降、喘振裕度降低Ⅲ类(中等)压比-流量特性偏移、排气温度上升
燃烧室喷嘴堵塞燃油杂质、积碳局部过热、火焰筒烧穿Ⅰ类(灾难)排气温度场不均、火焰脉动
传感器漂移老化、温漂虚警/漏警、控制偏差Ⅲ类多源冗余不一致、残差趋势

FMEA的输出直接决定PHM的监测对象与优先级:Ⅰ类故障必须配置在线实时监测与快速保护;Ⅱ类故障需具备趋势预测与维修决策支持;Ⅲ类故障可采用定期检测或软测量。关键点是:FMEA不是一次性文档,而应随任务剖面和运行数据迭代更新。

三、R/M/A指标:PHM的量化目标

可靠性(Reliability)常用MTBF(平均故障间隔时间)衡量;维修性(Maintainability)用MTTR(平均修复时间)衡量;可用性(Availability)由两者共同决定:A = MTBF / (MTBF + MTTR)。PHM对这三者的作用路径不同:

  • 可靠性:通过早期故障预警避免突发失效,但不改变固有可靠性,主要减少非计划停机。
  • 维修性:通过故障定位与剩余寿命预测,把“定期拆检”变为“按需维修”,压缩MTTR中的诊断与准备时间。
  • 可用性:PHM的直接目标是提升任务可用性,例如将某型装备的年可用度从0.92提升到0.96。

指标定义必须可测量。例如“故障预测准确率≥85%”需明确:预测对象、预测时间窗(如提前24 h)、允许误差带(如RUL误差≤15%)、样本统计口径。否则指标无法验收。

PHM需求到系统指标的转化链 任务剖面 启动 / 巡航 / 机动 / 停机 时长·环境·载荷谱 FMEA 故障模式·原因·影响 严酷度·监测征兆 R / M / A 指标 MTBF · MTTR · 可用度 任务成功率·保障成本 PHM需求 功能需求 非功能需求 功能需求(系统必须做什么) • 状态监测:振动/温度/转速/油液多源采集 • 故障诊断:定位到部件级,输出置信度 • 寿命预测:RUL估计,提前≥24h预警 • 维修决策:生成工单建议与备件需求 • 健康管理:趋势记录、报告、数据回传 非功能需求(约束与品质) • 实时性:诊断延迟≤200ms,预警≤1s • 虚警率:≤5%,漏警率:≤1% • 环境适应性:-40℃~+70℃,抗振抗盐雾 • 可扩展性:支持新增传感器与算法插件 • 安全性:数据加密、权限分级、审计日志 需求 → 系统指标转化方法(QFD式映射) ① 需求条目化:每条需求唯一编号、来源、优先级 ② 指标分解:将“提前预警”分解为采样率、特征窗口、模型更新周期 ③ 分配与验证:分配到传感器/算法/软件模块,定义测试用例与判据 ④ 追溯矩阵:需求ID ↔ 指标 ↔ 验证方法 ↔ 责任人

四、功能需求与非功能需求

功能需求回答“系统必须做什么”,通常包括:多源数据采集与同步、特征提取、故障诊断、剩余寿命预测、维修决策建议、健康报告生成、数据存储与回传。以某型装备为例,功能需求可写为:“在巡航阶段,系统应能基于振动与排气温度,在轴承磨损发展到中期前给出预警,并定位到主轴承部件。”

非功能需求回答“做到什么程度、受什么约束”,包括实时性、虚警率/漏警率、环境适应性、可扩展性、安全性、功耗与重量。例如:诊断延迟≤200 ms、虚警率≤5%、MTBF≥10000 h、支持-40℃~+70℃工作。非功能需求往往决定架构选型:若要求200 ms内完成诊断,边缘计算与轻量模型成为必选项,而非全部上云。

五、需求到系统指标的转化方法

转化不是简单“翻译”,而是逐层分解与分配。推荐四步法:

  1. 需求条目化:每条需求赋予唯一ID、来源(任务剖面/FMEA/用户)、优先级(必须/重要/期望)。
  2. 指标分解:将高层需求拆为可测量的技术指标。例如“提前预警轴承磨损”分解为:采样率≥20 kHz、特征窗口≤1 s、模型推理周期≤10 s、RUL误差≤15%。
  3. 分配与验证:把指标分配到传感器、采集卡、算法模块、软件平台,并定义验证方法(台架试验、历史数据回放、现场试运行)。
  4. 追溯矩阵:建立“需求ID—指标—验证方法—责任人”的追溯表,确保每条需求可追踪、可验收。
示例:需求“降低非计划停机” → 指标“年可用度≥0.96” → 分解“MTBF≥2000 h、MTTR≤4 h、预警提前量≥24 h” → 分配“振动监测通道≥8、油液检测周期≤50 h、诊断模型召回率≥90%” → 验证“台架故障注入试验+现场数据回放”。
常见误区:把“PHM系统应具备故障预测能力”直接当作指标。这类描述无法设计、无法验收。必须补充预测对象、时间窗、误差带、样本量与统计口径,才能进入系统设计。

需求分析的最终产出是一份可追溯的需求规格说明:每条需求有编号、有指标、有验证方法、有优先级。它既是后续架构设计的输入,也是验收测试的基准。任务剖面决定场景边界,FMEA决定监测重点,R/M/A决定量化目标,功能与非功能需求决定系统能力与约束,四步转化法把它们拧成一条可执行的工程链路。