简介：华为智慧电厂解决方案完整文档，面向电力行业信息化规划人员、电厂技术骨干及关注能源数字化转型的从业者。方案聚焦智能发电与产业融合，阐述利用大数据、云计算、物联网、AI等技术实现生产过程自主优化与设备智能运维，提升电厂安全、高效、绿色、低碳运行水平，并涉及电力监控、智慧停车、应急指挥系统等智慧城市应用。资源包共1个PDF文件，压缩包大小4.57MB，内容结构完整，含行业趋势、公司汇报、方案探讨等章节，并展示华为发电行业工业互联网平台架构及大唐南京电厂、华能集团等实践案例。已有628人学习下载，适合需系统了解智慧电厂技术框架与实施路径的读者。通过阅读可掌握数据统一采集、智能决策、智慧检修、移动巡检等关键环节实现方式，理解物联网平台、大数据平台、AI平台与工业互联网参考架构如何协同支撑电厂数字化转型，获得可落地的智慧电厂建设思路。
1. 华为智慧电厂解决方案：先打通数据，再谈智能
“华为智慧电厂解决方案.pdf”看下来，最大的感受是：它劝你先把平台和数据玩明白，再谈AI。电力行业谈智能化，最不缺算法和算力，缺的是把DCS、SIS、MIS、EAM这些互不贯通的老系统汇到一张图上的能力。方案以工业互联网平台参考架构为骨架，把设备接入、物联网平台、大数据、AI、应用集成和混合云部署串成一条线，再落到智能巡检、设备预测性维护、锅炉燃烧优化、安全管理等场景，每一层都给了可对接的产品和接口方向。适合电厂信息中心、设备管理岗和做电力系统集成的工程师读——前者能拿它当规划框架，后者能靠它确定平台边界和实施顺序。
2. 工业互联网平台架构：垂直孤岛到分层解耦，关键是三层职责
2.1 垂直孤岛为什么走不通：电厂里“一个业务一套系统”的真实面貌
先看现状。绝大多数投产十年以上的电厂，信息化是跟着部门需求一点点长出来的：MIS管日常办公，EAM管资产维护，燃料管理系统管煤场和化验，SIS做性能计算，视频监控和门禁自成一套。每个系统都有自己的数据库、服务器和建设周期，数据在单个系统内部好用，跨系统共享就全靠报表和人工导出，同一个设备的编码在每个系统里还不一样。方案里把这种方式画成“垂直孤岛式建设”，每个应用都配一套应用软件、数据库、网络和IT基础设施，重复投资，集成困难。
我实际项目里见过最典型的例子：设备台账在EAM里叫“1号给水泵A”，在MIS工单里叫“给水泵#1A”，在SIS点位表里叫“PUMP_1A_SPEED”。三个名字对应同一个设备，做数据分析时光对齐编码就消耗半个月工期。方案里提出“平台化、生态化才能支持智慧电厂建设长期演进”，言下之意就是先把底层数据和公共能力从业务系统里拆出来，让应用之间不再直接互相耦合。
盘点一下典型电厂的系统构成和问题：
| 系统 | 数据源 | 常见问题 |
|---|---|---|
| DCS/SCADA | 锅炉、汽机、电气运行实时数据 | 点位开放不全，OPC授权受限 |
| SIS | 厂级性能计算和报表 | 历史数据存储周期短，查询慢 |
| EAM | 设备台账、检修工单 | 编码不统一，KKS码和资产码对不上 |
| MIS | 办公流程、人事、公文 | 与生产数据隔离，数据靠手工导入 |
| 燃料管理 | 煤场、化验、采制化 | 煤质数据滞后，影响燃烧调整 |
| 视频/门禁/定位 | 安防、人员、车辆 | 各厂商私有协议，无法联动 |
平台化的思路，就是把这六个竖井打掉，底层数据统一收编，应用层只关注业务逻辑，不再各自背着数据库和中间件。
2.2 平台化三层：数据采集、工业PaaS、工业APP怎么分工
方案引用工业互联网联盟的参考架构，把平台分成四块：数据采集是基础，工业PaaS是核心，IaaS是支撑，工业APP是关键。这个逻辑对发电企业来说要反过来读：先搞清楚APP要解决什么问题，再决定PaaS需要哪些能力，最后才谈基础设施。很多企业先买服务器和云平台，再找应用往里面装，装完后发现数据采集跟不上，APP就成了空中楼阁。
数据采集这一层，方案列的是“构建精准、实时、高效的数据采集体系”，落到现场就是：DCS、PLC、SCADA的点表，辅机传感器的测点，摄像头视频流，定位基站的位置数据，机器人回传的图像和红外热像，全部通过边缘网关或工业网关汇聚，再做协议转换。这层不解决，平台的数据湖就是无水之源。
工业PaaS这一层分两块：一块是通用PaaS，包括物联网平台OceanConnect、大数据平台FusionInsight、人工智能EI和集成平台ROMA；另一块是应用PaaS，里面装的是机理业务模型、行业算法模型库，以及智能巡检、资产管理、生产可视化这类场景化套件。方案里的说法是“将大量工业技术原理、行业知识、基础工艺、模型工具规则化、软件化、模块化，封装为可重复使用的组件”。这句话是整份材料里最值钱的一句：电厂的经验不能只长在老师傅脑子里，而是要变成可重复调用的算法组件，这就是aPaaS的定位。
工业APP层面向最终用户，运行在平台能力之上，单个APP不再需要重复买数据库和中间件。平台化带来的改变就在这里：应用在换，底座不动，数据资产始终留在企业手里。
2.3 集团侧与厂侧两级平台的边界
方案给的部署形态是：集团侧建一个大的工业互联网平台，电厂侧建一个轻量级工业互联网平台，两边通过专线和云平台打通。集团平台负责全局数据汇集、模型训练、应用发布和统一运维；厂侧平台负责边缘计算、实时数据处理、就地分析和本地应用。两边不是上下级关系，而是各有边界、互为补充。
| 层级 | 计算/存储资源 | 大数据与AI | 典型应用 |
|---|---|---|---|
| 集团侧 | 全栈专属云HCS或公有云 | FusionInsight大数据、EI全栈AI | 跨厂对标、设备故障诊断、煤耗分析、竞价辅助决策 |
| 厂侧 | FusionCube、轻量云资源池 | 边缘计算、实时数据库、轻量AI推理 | 智能巡检、人员定位、实时监控、移动检修、智慧园区 |
| 边缘层 | 工业网关、智能边缘终端 | 协议转换、数据预处理、就地联锁 | 传感器接入、视频接入、DCS只读采集 |
方案里强调“连接是基础，平台是关键，应用是核心”。这套两级平台的精髓在梯度：厂侧平台负责把生产数据接进来、把实时性兜住，集团平台负责把数据资产经营起来。不少集团项目栽在第一期就想把所有厂的实时数据全拉到集团平台，网络带宽和数据库都撑不住，正确的做法是厂侧先预处理、按需上送，集团侧做跨厂分析。这一条，做规划时候就得定清楚。
3. 从设备到平台：OceanConnect、FusionInsight、EI三层各自管什么
3.1 OceanConnect设备接入与协议转换：物模型建好，数据治理省一半功夫
方案把物联网平台OceanConnect放在gPaaS层，承担设备接入、设备管理和应用使能三件事。最先落地的实际是设备接入。电厂现场的设备类型最典型有五类：DCS、PLC、SCADA这类控制系统，走OPC UA或Modbus TCP；温度、振动、倾角、红外、地磁这类传感器，走LoRa、NB-IoT或蓝牙；摄像头和机器人，走RTSP或GB/T28181；定位基站走厂商私有协议；智能仪表和巡检终端走MQTT或HTTP。五花八门的协议要在一个平台里统一成标准物模型，这一步是全部数据可用的前提。
OceanConnect的CIG模块（设备接入及协议转换）做的事情是：一边连接设备，一边解析协议并统一成内部消息格式，再映射到物模型上。物模型是设备的数字化模板，定义了属性、事件、命令。比如一个测振传感器，属性里有振动速度、加速度、温度，事件里有超限报警，命令里有采集频率设置。接入配置前先在平台侧把设备型号和物模型建好，设备侧端数据才能正确映射。
物模型配置示意（JSON）：
{ "productId": "vib_sensor_pro", "productName": "轴承测振传感器", "properties": [ { "code": "vib_speed", "name": "振动速度", "dataType": "double", "unit": "mm/s", "writable": false }, { "code": "vib_temp", "name": "轴承温度", "dataType": "double", "unit": "℃", "writable": false } ], "events": [ { "code": "vib_alarm", "name": "振动超限报警", "type": "info", "params": ["vib_speed", "vib_temp"] } ], "commands": [ { "code": "set_interval", "name": "设置采集周期", "params": [ { "code": "seconds", "dataType": "int", "unit": "s" } ] } ] }这份物模型告诉平台设备长什么样，CIG负责把设备上报的数据按这个模板解析入库。参数说明：dataType: double对应浮点测点值，writable: false表示平台不能反写传感器，生产测点只读是电力现场的安全底线；事件里的params数组是报警上报时携带的字段；命令set_interval用于远程修改采集周期，实际部署里这类命令通常要走反向隔离，不是所有项目都会开放。
物模型建好之后，点位表、数据库字段、可视化页面的数据源、AI训练的特征列，全部复用这一套定义。这一步做扎实了，后续数据治理工作量至少省一半。数据链路的常见做法是：设备 → 边缘网关 → CIG → OceanConnect → 消息队列 → FusionInsight。DCS和PLC的数据不建议直连平台，要经过边缘网关只读汇聚，一是安全和隔离要求，二是平台侧断网也不影响DCS正常控制。
3.2 FusionInsight数据仓库与数据湖：实时库和离线数仓怎么分工
方案给大数据平台FusionInsight的职责是：数据采集、数据存储、数据处理、数据分析、人工智能。落到电厂实际，我喜欢分成四条数据流水线：DCS实时数据进实时数据库，保持秒级入库，供画面刷新和报警联动；历史数据和经营数据进数据湖工厂DLF做清洗、对齐、分层，形成数仓；设备、工单、台账这类结构化数据进GaussDB200融合数仓，供报表和查询使用；图片视频类数据进对象存储，供AI训练和事后追溯。
数仓分层在发电场景里我一般按四层映射：
| 分层 | 发电场景含义 | 典型内容 |
|---|---|---|
| ODS | 原始数据区 | DCS实时快照、传感器原始上报、工单流水 |
| DWD | 明细数据层 | 按设备、按时点对齐后的测点明细 |
| DWS | 汇总数据层 | 锅炉效率、厂用电率、煤耗等指标日/月汇总 |
| ADS | 应用集市 | 供巡检APP、燃烧优化模型、经营看板取数的宽表 |
数据湖工厂DLF负责从ODS到DWD的清洗任务调度，常见做法是定时任务每隔15分钟把实时库的数据落一次数仓。实时库和数仓的分工要明确：实时库保证“当下看得见”，数仓保证“历史查得了、模型喂得饱”。如果只建实时库不做数仓，等模型训练需要365天历史数据时，会发现数据早被滚动清掉了。这个坑我见过不止一次，现在项目里一律要求DCS历史数据至少保留三年，磁盘不够就压缩存储，绝不能只留三个月。
3.3 EI平台的AI能力：三个场景各自的数据门槛
方案里EI平台提供从芯片、训练框架到应用使能的全栈能力，对应到电厂有三个经典场景。每个场景的数据门槛差别很大：
| 场景 | 输入数据 | 核心要求 | 输出 |
|---|---|---|---|
| 锅炉燃烧优化 | DCS历史运行数据（风、煤、汽温、氧量），专家机理模型 | DCS点位授权完整，机组负荷区间覆盖足够宽 | 供操作员参考的氧量、配风、给煤量建议 |
| 设备预测性维护 | 振动/温度/电流历史数据，故障维修记录 | 故障样本要能覆盖典型故障模式，至少几百条 | 未来N小时的故障概率与检修建议 |
| 安全帽/工装识别 | 摄像头视频流，标注图像集 | 不同光照、不同角度的正负样本均衡 | 违规事件实时推送 |
AI平台的价值不是替代机理模型，而是跟机理模型叠加。方案说“结合专家机理模型，优化锅炉燃烧控制模型”，在项目里的理解是：纯数据驱动模型在小负荷波动时容易给出离谱建议，机理模型负责框住物理边界，数据模型在边界内找最优。数据驱动的价值在于能看到老师傅凭经验看不到的相关性，但输出范围必须人为限定。
注意：供热管网是大滞后系统，阀门动作到温度反馈的延迟可能超过一个小时。训练供热控制模型之前，必须先把特征和标签做时间偏移对齐，否则模型学到的全是错位关系，跑起来就是玄学。
4. 智能应用落地顺序：巡检、检修、安全、经营决策怎么推进
4.1 智能巡检和移动检修：机器人、手持终端、摄像头和定位怎么配合
方案里智能巡检的技术栈包括手持巡检终端、机器人、无人机、智能摄像头、定位基站和智能安全帽。实际分工是：巡检机器人负责固定路线的可见光和红外巡检，适合锅炉钢架、输煤栈桥这些人员不好到、又不需要频繁判断的场景；手持终端和智能安全帽负责人工巡检，带NFC或RFID定位打卡和作业票关联；智能摄像头负责配电室、卸煤口、危化品库的连续监控；无人机用在输电线、高边坡、煤场盘煤和全局巡查。
大唐南京电厂的三维虚拟电厂、人员定位、智能巡检、移动办公，是这套体系的典型组合。推进顺序上我建议：先上人员定位和手持巡检终端，把巡检到位率管起来，投入产出最快；再接视频识别做安全帽违规检测；最后才上机器人和无人机。原因是前两者对管理流程依赖小，机器人则要考虑续航、网络覆盖和防护等级，一上来就铺开容易翻车。
| 终端 | 采集内容 | 适用场景 | 注意点 |
|---|---|---|---|
| 巡检机器人 | 可见光、红外热像、气体检测 | 输煤栈桥、锅炉钢架、危险区域 | 网络覆盖要稳定，充电桩要布够 |
| 手持巡检终端 | NFC点位、拍照、振动测温 | 日常点检、缺陷上报 | 要和EAM工单打通才能闭环 |
| 智能安全帽 | 人员定位、视频回传、语音 | 检修现场、受限空间 | 电池续航和佩戴舒适度决定使用率 |
| 固定摄像头 | 违章识别、漏油检测、表计读数 | 配电室、油库、卸煤口 | 光照和遮挡对识别准确率影响大 |
人员定位依赖定位基站，方案里提到的eLTE是自建授权无线网络，语音和数据融合，智能安全帽带定位模块后，人员轨迹、到岗时间、危险区域闯入告警都能实时化。应急指挥系统在电厂里的形态通常是：报警位置叠加在三维模型或二维地图上，值班员一键调度最近人员处理。华为在智慧城市里沉淀的应急指挥和车辆管理能力，放到电厂园区里正好用得上——园区安防、车辆管理、智慧停车的逻辑跟城市级平台是一致的，智慧停车这类应用本质上就是车辆定位和车位状态的上云管理。
4.2 设备预测性维护：数据准备与建模流程
方案里预测性维护模型的定义是：用历史运行数据和故障维修数据构建预测模型，预判故障发生概率，提前保养，减少突发故障成本。项目里做这件事的流程分四步：数据收集、标签构建、特征提取、模型训练与验证。
数据收集要拿设备至少一年的运行数据，振动、温度、电流、出口压力，配套维修记录给出故障时间和故障类型。标签构建是预测性维护最费工的一步：把维修记录里的故障时间点往前推一段时间，比如故障前7天标记为“即将故障”，让模型学习故障发生前的特征模式。特征提取用滑动窗口对连续测点算统计量，均值、标准差、峰值、峭度。窗口长度按设备类型选，泵和风机我一般用30分钟窗口、15分钟滑步。
模型选型上直接上随机森林或LightGBM这类表格数据模型，不要一上来就上深度学习——故障样本动辄只有几十条，深度网络很难收敛。随机森林这类模型调参相对省心，不像深度网络那么玄学。模型下方再挂一层规则滤波器：模型输出概率超过阈值但物理量没有异常趋势时，比如轴承温度正常、振动不涨，拦截不报，降低误报率。
建模流程代码：
import pandas as pd from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import train_test_split # 读取实时库导出的测点历史数据，时间戳已对齐 df = pd.read_parquet("pump_1a_features.parquet") # 标签列是故障发生前7天内标记为1的窗口样本，0为正常样本 X = df.drop(columns=["label", "timestamp"]) y = df["label"] # 随机森林：对几十到几百条故障样本也能给出可用结果，且特征重要性可直接用于解释 model = RandomForestClassifier( n_estimators=300, max_depth=8, min_samples_leaf=10, class_weight="balanced", random_state=42, ) X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, stratify=y, random_state=42 ) model.fit(X_train, y_train) # 验证时重点看召回率，宁可多一点误报，也不能漏掉真实故障 from sklearn.metrics import recall_score, precision_score y_pred = model.predict(X_test) print("recall:", recall_score(y_test, y_pred)) print("precision:", precision_score(y_test, y_pred))代码思路是让模型在样本不均衡情况下也能学到故障模式，class_weight="balanced"会自动放大少数类权重。参数说明：n_estimators=300在稳定性和训练耗时之间比较平衡，max_depth=8防止树学得太深把个体噪声记住，min_samples_leaf=10保证叶子节点有足够样本支撑，stratify=y保证训练测试集里故障样本比例一致——否则几十条故障可能全留在训练集里，测试出来召回率是零。训练完成后一定要输出特征重要性，看哪个测点对故障贡献最大，这个结果对调整点检计划很有用。
4.3 经营决策与生产优化的数据链路
方案里行业趋势部分提到电力市场改革后竞争加剧，电厂核心竞争力不再只是安全发电，还有成本和响应速度。生产侧数据的价值延伸到经营侧：竞价上网辅助决策、燃煤效率优化、设备资产分析、产业链协同分析。数据链路是：ERP、MIS、燃料管理、EAM、实时生产数据通过ROMA集成平台统一接入，在数仓里形成经营宽表。
ROMA在这条链路的职责是打通OT和IT：生产系统的DCS实时数据接口只读，经营系统的ERP用API主动取数，ROMA在中间做协议适配和消息路由。方案强调“企业内部所有IT、OT系统融合，打通上下游合作伙伴”，落到工程上，集成的范围从厂内扩展到了煤炭供应商、电网调度和售电公司。竞价辅助决策模型需要分钟级的成本估算，公式大致是煤耗乘煤价加厂用电成本再加设备折旧分摊，煤价行情要实时抓取，煤质数据要跟着批次走。
方案里大渡河公司的“一中枢、多中心、四单元”智慧企业架构，本质上是把生产、经营、调度分开建，又通过统一数据中枢串联。经营分析不能一上来就做全集团大平台，先做月度煤耗与发电成本归集，再逐月细化到机组、到班次，积累半年就能画出成本曲线。
5. 避坑指南：两网隔离、DCS接口、集成性能、AI样本与三维维护
5.1 生产网和管理网隔离：数据单向摆渡是硬门槛
现象：设备数据采集程序部署在厂区边缘网关上，运行一周后被安全部门告警，生产大区设备直连管理大区平台，违反隔离要求，项目暂停整改。
原因：电力监控网络里生产控制大区和管理信息大区之间有严格的安全管控要求，实时控制系统可以和设备直连，但数据进入管理大区或云平台前必须经过隔离装置，只能单向摆渡。很多项目初期画架构图时把DCS和平台画在一条线上，审图时才发现违规。
解决：把边缘网关和生产设备放在生产大区侧，网关通过正向隔离装置把数据摆渡到管理大区的数据接收服务器，再由接收服务器写入平台。采集上报走正向隔离，配置下发走反向隔离，反向隔离通常还要结合人工审计。平台侧对DCS等生产系统的API调用必须严格只读，不能有任何写回操作。这个设计在方案评审时就要定下来，施工后再改网络分区，代价非常大。
注意：正向隔离的摆渡方向不能搞反，反向配置下发比数据采集麻烦得多，建议交给有电力二次安防实施经验的团队来布线。
5.2 DCS数据接口的授权与点位开放度
现象：燃烧优化项目进场后发现DCS厂家只开放了50个点位，缺一次风量、缺磨煤机出口温度，模型根本训不出来；DCS厂家报出的OPC授权费用比现场实施费还贵。
原因：DCS厂家有生态壁垒，点位开放范围和授权价格由原厂家控制，部分老机组原厂家已退出市场，备件和文档都找不齐。商务和技术两件事没提前锁定，项目就会卡在数据源这一环。
解决：技术上先做只读网关采集，通过标准OPC UA接口尽快拿到点位清单，再核对控制系统侧的点表确认关键参数是否覆盖。商务上在合同阶段列明数据接口范围、授权期限、点位数量，并约定DCS厂家的配合时间。我项目里的做法是把“数据接口开放”列为关键路径任务，和平台部署并行推进，必须比平台先准备好——数据不到位，后面所有算法都是空转。
5.3 ROMA集成接口性能：批量同步调用堵塞
现象：ROMA集成平台上线三个月后，设备故障工单流转开始延迟，高峰时段接口平均响应时间从200毫秒涨到5秒，移动检修App频繁转圈。
原因：对接的二十多个系统全部走了同步调用，一个工单流程要依次调EAM、人员定位、门禁、短信网关四个接口，任何一个慢都会拖垮整条链路。高频数据比如定位上报、传感器遥测也走同步API，消息量一大，集成平台就成了瓶颈。
解决：把跨系统流程改造成事件驱动。高频率遥测数据不走同步API，改走消息队列异步上报，消费方按需订阅；工单流转的核心节点改用事件通知，下游系统监听事件后再拉取详情；批量数据交换比如煤质化验单、日报表，走文件交换或批量接口，不做逐条同步。改完之后，接口压力至少降一个数量级。方案里ROMA强调“多云协同、企业生态协同”，这个目标只有在消息解耦状态下才现实。
5.4 AI样本不足：预测性维护模型“假装正常”
现象：设备预测性维护模型上线后，测试集准确率超过95%，但三个月里真实发生的三起轴承故障一个都没提前预警，运维人员开始质疑模型。
原因：训练数据里故障样本占比不到0.5%，模型学到的最优策略就是永远输出“正常”，准确率虚高但毫无价值。这是数据驱动方法在电力行业的经典翻车场景——电厂设备可靠性高，真正的故障数据本就稀缺。
解决：先用规则和机理模型兜底，再逐步积累样本。第一阶段以阈值规则预警为主，比如振动速度超过4.5mm/s或温升速率超限就报警，规则能被老师傅接受；第二阶段把规则触发的预警结果和事后确认的故障记录合并成标注数据集，人工复核每一条异常窗口；第三阶段样本量达到几百条以后再训练机器学习模型，模型输出仍经过规则滤波器，物理量没有对应趋势的预警自动抑制。方案里强调“机理业务模型、行业算法模型库”，目的就是让数据模型有物理边界。这套做法到位后，每天的有效告警数量从几十条降到个位数，现场才真的敢用。
5.5 三维可视化：建出来容易，维护起来是长期账
现象：三维虚拟电厂项目验收后，部门日常没人打开，只有领导参观时演示一下；三维模型里的设备状态和实际不符，报警位置指向也错位。
原因：三维模型建的时候按设计图纸和竣工图做静态场景，设备和管道的位置、阀门朝向可能与现场不完全一致。系统上线后设备改造、管道变更没有同步更新模型，三维和现实逐渐分道扬镳。纯展示用的三维没有绑定生产数据，没有日常使用场景，自然没人维护。
解决：三维建模范围要从一开始就收敛到有业务价值的区域：主厂房、锅炉、配电室、输煤系统，不做全厂地毯式建模。每个三维设备绑定统一编码，这个编码与EAM台账、DCS点位、维护工单共用；报警数据按设备编码挂到三维位置，点选设备能看到实时测点和历史曲线。更新流程挂进检修工单，凡涉及设备位置变更的工单，验收时强制检查三维模型是否同步修改。三维的价值在可视化定位和人员培训，把它当生产工具用，而不是当展示片，这笔投入才收得回来。否则等三维和现场差距变大再回头补模型，就是吃后悔药。
6. 燃烧优化模型上线前：先跑三个月影子模式验证
燃烧优化是智慧电厂里技术含量最高、也是方案反复提及的场景：用DCS历史数据做深度学习，结合专家机理模型输出控制建议。但我判断这套东西实测价值如何，从来不看PPT，只看三个数字：NOx排放均值降了多少、供电煤耗降了多少克每千瓦时、DCS可用率和操作员接受度有没有受影响。
我的习惯做法是影子模式，英文叫shadow mode，不直接闭环。具体流程是：
- 在一台独立的边缘分析服务器上部署燃烧优化模型，实时接收DCS广播数据，延迟要求秒级以内，只读；
- 模型按固定周期（通常5分钟）计算目标氧量、配风方式、给煤量调整建议，写入独立建议表，不写回DCS；
- 操作员正常操作，系统自动记录“如果按建议操作，关键参数会变成多少”，每天生成建议命中率报表；
- 跑满三个月后，对比建议执行期和未执行期的锅炉效率、NOx排放、减温水用量。
跑影子模式期间有个细节值得注意：建议值要带置信区间，模型给出的氧量建议如果偏离当前运行值太大，这条建议要标记为不采纳，避免极端建议拉低统计指标。最终评审看两个口径：一是模型建议被操作员采纳的比例，二是采纳后的工况下排放和煤耗有没有实质改善。三个月时间足够覆盖不同煤种、不同负荷率，比单周试运行靠谱得多。
影子模式的评估逻辑示意：
# 影子模式评估示意：每5分钟读一次实时测点，生成建议 import time # 假设已有DCS只读口封装，O2为烟气氧量，COAL为给煤量，LOAD为机组负荷 while True: o2, coal, load = read_dcs_realtime(["O2", "COAL", "LOAD"]) # 模型输出目标氧量和给煤调整量，带置信度 target_o2 = model.predict_target_o2(load=load, coal=coal) conf = model.confidence(load=load, coal=coal) # 偏差超过0.8%时标记为不采纳，避免统计失真 accepted = abs(target_o2 - o2) < 0.8 write_advice_table({ "ts": time.time(), "load": load, "target_o2": target_o2, "current_o2": o2, "accepted": accepted, "confidence": conf, }) time.sleep(300)代码逻辑不写DCS，只把建议记录到独立表里，因此非常安全。参数说明：偏差阈值0.8%是在和有经验的值长确认后定的，太小的偏差没有统计意义，太大说明模型和当前工况差距太远；目标氧量由模型基于负荷和给煤计算，置信度低于0.6的建议自动置为不采纳。
实际评审时，没法在同一台机组上做AB轮换，能做的是：操作员采纳了一条建议时，把采纳时刻前后的关键参数变化提取出来，再跟未采纳时段做负荷、煤质对齐后的对比分析。这个口径比简单的全时段均值对比准确得多。
从那以后，我接手任何一个AI优化类项目，都会先把“影子模式验证期”写进项目章程。没有三个月真实运行数据支撑的优化效果，我一律视为估算值——算法再先进，也得先证明它在自己的锅炉上靠谱。希望帮到你。
本文还有配套的精品资源，点击获取
