3. 故障信息采集与数据质量

FRACAS 的闭环质量，首先取决于故障信息进入系统时的“原始质量”。如果故障现象描述含糊、环境与工况数据缺失、时间与产品状态对不上，后续的原因分析、纠正措施和验证结论都会建立在不可靠的输入之上。本节围绕“采什么、怎么记、如何校验、错了怎么改”四个层面，给出可直接落地的采集规范与校验方法。

一、故障现象描述规范：把“发生了什么”写成可复现的事实

故障现象描述的目标不是“让人看懂大概”，而是让另一个工程师在不询问当事人的情况下，能够判断故障模式、复现条件与影响范围。规范描述应包含五个要素：可观察对象、异常表现、发生时机、复现条件、影响后果。例如“设备偶尔报错”属于不合格描述；“XX-200 型控制器在环境温度 45℃、连续运行 3 小时后，第 2 路模拟量输入通道读数跳变至满量程，断电重启后恢复，复现概率约 3/10”才是可分析描述。

描述中应避免三类词：主观判断词（如“质量差”“不稳定”）、因果预设词（如“因为电容坏了所以死机”）、模糊量词（如“偶尔”“很多次”）。原因分析属于后续环节，采集阶段只记录现象与条件。对于间歇性故障，应记录观察窗口、尝试次数与成功复现次数，用“发生次数/尝试次数”表达概率，而不是用“经常”代替。

二、环境与工况数据采集：让故障发生在可还原的坐标里

同一故障现象在不同环境与工况下可能对应完全不同的原因。采集时应至少覆盖以下维度：环境类（温度、湿度、振动、供电电压、电磁环境）、工况类（负载率、运行时长、启停次数、工作模式、输入信号范围）、产品状态类（软件版本、硬件批次、累计运行时间、近期维修记录）。这些数据不必全部逐条填写，但必须与故障模式相关：热相关故障重点记录温度与散热条件，通信相关故障重点记录线缆长度、波特率与干扰源。

采集方式建议采用“自动记录优先、人工补录兜底”。例如在测试台架中，用数据采集卡以 1 Hz 记录温度、电压、电流，故障触发时自动打时间戳；现场故障则用采集表单记录关键参数，并附现场照片或日志片段。时间基准必须统一：所有记录使用同一时钟源，标注时区，避免“设备时间比服务器慢 8 分钟”导致因果错位。

三、数据完整性校验：在进入分析前拦住“脏数据”

完整性校验应作为故障记录提交前的强制关卡，而不是事后抽查。建议按四级规则执行：必填项非空（故障时间、现象描述、产品编号、上报人）、时间戳一致性（采集时间不得晚于上报时间，设备时间与系统时间偏差超过阈值需标注）、参数范围校验（温度、电压、电流等落在产品规格范围内，超范围需说明是异常值还是量程问题）、逻辑冲突检测（如“设备已停机”却记录到运行电流，或“首次发生”却存在历史维修记录）。

校验不通过时，不应简单退回，而应给出具体缺失字段与建议补录方式。例如系统提示“环境温度缺失，建议从台架日志 T-2024-06-11 回填，或现场补测并标注测量位置”。对于无法补录的历史数据，应标记为“不可追溯”，并在分析结论中降低其证据权重，而不是默认填充一个估计值。

四、常见采集错误与纠正案例

案例一：现象描述不可复现。某电源模块故障记录为“输出不稳定”。纠正时要求补充：负载从 20% 阶跃到 80% 时，输出电压在 12.0 V 附近波动 ±0.8 V，持续约 200 ms，示波器截图见附件，复现 5/10 次。补充后可直接定位到环路响应问题，而不是停留在“不稳定”这一层。

案例二：环境数据缺失导致误判。某控制器高温死机，初始记录未填环境温度，分析时误判为软件缺陷。纠正后回填台架温度曲线：故障发生在 68℃、持续运行 2.5 h 后，而同批次产品在 55℃ 下连续运行 8 h 无异常。由此将方向转向散热设计与温度保护阈值，避免无效的软件排查。

案例三：时间基准不统一。现场设备日志显示故障发生在 10:15，而维修工单记录为 10:23，两者相差 8 分钟，导致“先断电还是先报警”的因果判断出现矛盾。纠正措施是：所有采集终端统一使用 NTP 对时，工单系统记录时区，并在故障记录中增加“设备时间与标准时间偏差”字段。

五、可直接使用的故障信息采集最小字段集

该字段集可直接作为采集表单模板使用。实际执行时，可根据产品类型裁剪字段，但故障时间、产品标识、现象描述、复现条件、影响后果五项建议保留为必填。采集完成后，先跑一遍完整性校验，再进入 FRACAS 分析流程，才能保证后续的原因定位与纠正措施验证建立在同一套可信数据之上。