古建筑火灾预警有两个必须同时回答的问题：建筑环境里是否出现火情信号？负责监测的设备本身是否仍然可靠？“幽鉴潜盾——隐形微光人工智能火灾预警平台”围绕这两个问题设计。项目将微光供能、红外测温、无线通信和智能终端组合起来，并在火情监测之外加入设备健康监测与维护判断。
下面按设备组成、数据流和算法分工，说明这套方案如何工作。
English version: Yinjian Qiedun: From Fire Detection to Predictive Maintenance
一、系统的组成部分
1. 现场检测器：感知温度并回传数据
安装在建筑内部的检测器包含红外探测元件和无线传输模块。红外元件接收环境红外辐射，将测量结果转换为温度数据和数字信号；无线模块再对数据进行编码，通过低功耗无线链路发送到接收终端。每台设备需要有唯一编号，方便终端把数据和建筑内的安装位置对应起来。
2. 供电模块：微光发电配合储能
微光电池把现场光照转换为电能。能量管理电路负责供电和电池充电；在光照充足时，发出的电能可供设备工作并补充储能，在夜间或弱光条件下，则由储能电池继续为红外探测和无线通信模块供电。项目材料也提到使用 MPPT 调节光伏工作点，以提高不同光照条件下的能量获取效率。
这部分设计的目的，是减少外接电线和频繁更换电池的需要，让检测器能以较小体积布置在不便施工的位置。实际能否保持全天候工作，还取决于采光、功耗、储能容量和无线发送频率之间的能量平衡；现有材料提出了系统方案，但没有提供足以核实现场续航的长期运行记录。
3. 接收终端：汇集信息并给出两类提示
终端接收各检测器的温度信号和运行状态数据，承担数据解析、火情识别、故障筛查、维护提示和用户查看等任务。系统的逻辑因此分成两条并行的数据路径：一条监测建筑环境并触发火灾风险提示，另一条监测设备运行状况并提示检修。设备故障告警用于维护预警设备本身，不能代替火灾告警。
二、火情监测路径：从红外辐射到报警
环境红外辐射
↓
检测器测温并生成数字信号
↓
无线模块编码、发送温度数据
↓
终端解析温度变化并判断风险
↓
显示火灾风险提示，提醒管理人员响应项目论文把火情判断描述为：终端依据预设的风险识别方法，关注异常高温或温度快速变化等信号；满足风险条件时，发出火灾提示。传感器和无线链路负责“测到并送达”，终端负责“解释测量值并提醒”。
现有材料没有给出一套可复现的火情阈值、判定公式或误报测试结果，因此不能据此确定系统在多高温度、何种变化速率下必然报警。火情判断的具体参数需要结合传感器标定、建筑环境和实测数据确定。
三、设备自检路径：从运行指标到维护建议
火情判断使用环境温度数据；设备健康判断则主要使用检测器自身的运行指标。流程文档列出的数据字段包括：
- 电压、电流：反映供电和能量使用状态；
- 信号强度、响应频率：反映无线通信链路和设备响应状况；
- 时间戳、设备编号：用于比较状态随时间的变化，并找到对应设备；
- 位置（可选）：可将设备编号关联到建筑布置图。
资料中的数据处理草案依次包括采集、预处理、异常筛查、趋势预测、维护分类和位置辅助定位：
周期采集运行指标与设备编号
↓
记录时间、检查空值和无效数据，整理数值特征
↓
Isolation Forest：筛出偏离常态的观测
↓
Prophet：观察电压等指标未来的变化趋势
↓
XGBoost：综合指标，分类判断是否需要维护
↓
编号关联布置图，向维护人员提供检查对象和提示流程文档举例每台设备每 1–2 小时发送一次健康数据，但这是方案示例，不是已确认的最终采样周期。其伪代码示例先在本地做数据整理和异常筛查，再把异常数据上传，供云端进行趋势预测与维护判断。论文和答辩材料则较概括地说由终端或云端 AI 处理，因此模型实际部署位置仍需统一说明。
第一步：Isolation Forest 找出可疑观测
Isolation Forest（孤立森林）通过随机选择特征、随机切分取值范围，建立多棵隔离树。对每条观测，模型计算它在各棵树里被分离出来所经过的路径长度，再综合成异常分数。与大多数记录差异明显的观测通常更容易被较少切分隔离，因此会被标记为异常。
在设备场景中，电压突然下降、信号强度明显偏离常态，或电流与响应频率组合异常，都可能进入待检查清单。它的作用是发现与历史或整体分布不一致的读数，并不直接证明哪一个硬件已经损坏。材料中的 Python 示例使用 -1 表示异常、1 表示正常，并以 contamination=0.01 作为示例参数；异常比例应由真实运行数据和误报情况校准，不能直接当作固定规格。
第二步：Prophet 观察指标随时间的趋势
异常筛查关注单次或局部观测，Prophet 则关注某项指标在时间轴上的变化。流程示例将每台设备的时间戳整理为 ds，将电压值整理为 y，训练时间序列模型，再生成未来时点的预测均值和上下界。若电压持续下降，趋势及预测区间可作为进一步检查供电或储能部件的线索。
趋势预测给出的是“按已有序列推算的可能变化”，不是故障确诊。文档示例预测未来 24 小时；另有材料写 24–48 小时。具体预测时长、采样间隔和使用的数据指标需要按实际数据确定。AI 原理文档也提醒，Prophet 更适合较长时间序列中的趋势和季节变化，短期或数据量不足时，预测效果需要单独验证。
第三步：XGBoost 给出维护分类
XGBoost 是监督式分类方法。流程说明以电压、电流、信号强度和响应频率等作为输入特征，以 needs_maintenance（是否需要维护）作为训练标签。模型通过带标签的训练样本学习指标组合与维护类别的关系，随后对新数据输出“正常”或“需要维护”的分类结果。训练材料还提到将数据拆分为训练集和验证集，并用准确率等指标评估模型。
这个步骤依赖可信的历史标签：维护人员检查后确认“需要维修”或“无需维修”，才能形成有实际意义的训练目标。如果标签只是按预设阈值或模拟规则生成，模型学到的可能只是这些规则，而不一定能识别现场的真实故障。因此，分类输出应作为维护优先级建议，后续仍需人工检查确认。
四、三种算法如何协作
三种算法的职责可以概括为：
| 环节 | 方法 | 回答的问题 | 主要输出 |
|---|---|---|---|
| 异常筛查 | Isolation Forest | 哪些观测明显偏离常态？ | 异常记录和分数/标记 |
| 趋势预测 | Prophet | 指标接下来可能如何变化？ | 时间序列预测及区间 |
| 维护分类 | XGBoost | 哪些设备应优先安排维护？ | 正常/需维护类别 |
这是一个从监测到维护的分析流程，但不应误解为三个模型必然把前一个模型的输出逐级作为下一个模型的输入。现有流程文档写明，XGBoost 使用传感器指标和维护标签进行训练；没有明确说明会把 Isolation Forest 的异常分数或 Prophet 的预测值作为 XGBoost 特征。最终实现应在系统图中标明数据接口，确认各模型是串联、并行，还是由终端按规则汇总。
五、异常怎样变成可执行的检修线索
模型输出异常设备编号后，终端可将编号关联到建筑布置图，帮助维护人员先找到具体位置。再结合指标表现缩小排查范围：例如功率或电压持续偏低，可优先检查微光电池、储能和能量管理；无线信号强度偏低或响应频率异常，可优先检查通信链路或红外探测模块。问答稿描述了交互图表在鼠标悬停时显示设备 ID 和具体读数的设想。
这些是用于安排检查的可能原因，单一指标与部件故障并非一一对应。现场检修后应记录最终发现、维修措施和复测结果；如果项目进入持续运行阶段，这些确认过的记录可成为更可靠的维护标签，逐步改进模型和阈值。存档材料尚未展示完整的维修回填机制。