新能源场站无人化方案：四层架构、智能巡检与告警闭环

简介：《新能源“无人化”场站解决方案白皮书》聚焦新能源场站的智能运营与少人值守，由金风服务GOLDWIND推出，面向新能源电站运维、能源数字化建设及智慧场站方案设计人员，回应场站自动监控、无人化操作和安全管理等实际问题。全文共32页，以1个PDF文件交付，压缩包约41.53MB，便于电脑端查阅、归档与团队传阅；已有292人学习，具备一定参考热度。内容围绕智能化场站、自动化控制系统、物联网与数据分析、能源生产效率及安全性展开，兼顾技术特点、应用场景和成本效益分析，可帮助读者梳理远程监控、自动控制、风险降低与降本增效的整体思路。对方案调研、项目汇报、内部培训或场站改造前期论证而言，这份白皮书可作为了解新能源无人化场站建设路径的参考资料。

1. 从一次凌晨三点的巡检工单说起：新能源场站为什么要做无人化

有个做运维的朋友吐槽过一件事：他们那片山地光伏场站凌晨三点报了一条组串电流异常，值班员开了四十分钟车到现场，发现只是汇流箱通讯模块掉线。这类「为了确认一个本不该报的信号而跑一趟」的工单，在新能源场站里占的比例相当高。新能源「无人化」场站解决方案要解决的正是这件事——不是把人全部撤走，而是把「必须到现场才能判断」的比例压下去，让智能化场站替人完成第一轮筛选和判断。

这套方案面向陆上风电、集中式光伏、分散式风光互补几类场景，交付形态是一份可落地的白皮书式设计：分层架构、统一点位模型、巡检编排、告警策略、验收指标。手里有毕设或课程设计要交的人，可以照着这套结构走完需求、设计、实现、验收；要给客户出交付方案的集成商，可以拿它改一版直接对上去讲。

2. 需求拆解与总体架构：四层结构与三类场站的能力边界

2.1 三条需求主线：少跑腿、早发现、可回溯

把「无人化」当成目标去写方案，很容易写成设备清单。我一般会先把它拆成三条能验收的需求主线，后面所有模块都往这三条上挂。

第一条是少跑腿。核心指标是现场确认类工单的下降比例，通常的做法是统计改造前后三个月的「到场后判定为无需处理」的工单占比，行业里做得比较扎实的项目能压掉四到六成。这条需求直接决定了视频、在线监测、边缘诊断要布到什么密度。

第二条是早发现。人工巡检的周期是季度级甚至半年级，缺陷从产生到被发现之间有一段很长的空窗。无人化方案要把它压到周级：叶片裂纹、组件热斑、汇流箱发热、箱变油温异常，靠固定视频加移动巡检组合去覆盖。这里衡量的是缺陷平均发现周期，不是巡检次数。

第三条是可回溯。出了问题要能还原「当时是什么数据、谁做了什么判断、系统给了什么建议」。很多方案在这一条上栽跟头——数据存了，但采样周期被聚合过，告警推了但没留触发时的原始值，事后复盘只能靠人回忆。可回溯做不好，前面两条做得再漂亮，验收时也讲不清。

提示：安全性在方案里不要只写「提升安全性」这种结论句，要落到具体指标上，比如「高风险作业人次下降比例」「越限告警的平均响应时长」，否则验收阶段没法举证。

2.2 总体架构：从感知层到应用层的四层划分

整个无人化场站的骨架，我习惯切成四层，每层都对应明确的交付物和失败表现。分层的好处是：模块再多也不会写成平铺的功能列表，每一层缺什么、坏在哪，排查时有落点。

四层里最容易做薄的是边缘层。很多方案把它当成一个「协议盒子」，实际上它承担了三件事：断网时的数据兜底、告警的第一道过滤、以及给平台层减负。边缘层做扎实，平台侧的压力会小一个量级。

2.3 三类场站的差异化配置：不做一套模板套所有

同一份白皮书要覆盖风电、集中式光伏、分散式场景，就必须在架构不变的前提下做配置差异。我一般会在方案里单列一节讲这个，因为评审最常问的一句话就是「我们这种场站适用吗」。

陆上风电的核心是机舱与塔筒内部的连续量监测，重点是振动、温度、功率曲线偏离，巡检对象是叶片和塔筒焊缝，无人机航线要按机位单独规划。集中式光伏的核心是组串级电流电压和汇流箱温度，点位密度高但单点价值低，重点在聚合与离群检测，巡检对象是组件热斑和支架变形。分散式场站点多面广、单站容量小，通信成本往往比设备成本还敏感，方案上要允许降采样和事件触发上传，不能按集中式的采集频率硬套。

3. 数据底座：统一点位模型、采集链路与边缘侧的质量兜底

3.1 统一点位模型：先定名，再谈采集

无人化方案返工最多的地方不在算法，在点表。不同厂家设备自带的点表命名五花八门，同一个「有功功率」可能叫 P、ActivePower、有功、kw_p，接进平台之后全靠人工映射，接三个场站就开始乱。我一般要求在设计阶段先把命名规则定死：场站编码.设备类型.设备编号.测点标识，全小写，用点分隔，不用中文。

定完点表还要定三件事：单位统一（功率统一 kW，不混用 MW）、时间戳统一（一律用设备侧时间并做 NTP 校时，平台侧不打时间）、累计量单独标记（发电量这类累计量要做差值处理，不能直接存瞬时值）。这三件事看起来琐碎，但后面数据对不上、日报表和月报表打架，基本都是这里埋的雷。

3.2 采集链路怎么搭：四种协议与网关的取舍

新能源场站里能见到的协议就那么几种，选型上没必要追求统一，按设备侧有什么就用什么，转换工作交给边缘网关。

网关侧的配置我一般写成可版本管理的配置文件，不写在设备界面里。这样换网关、加通道的时候能对比差异，出问题也能回滚：

# 边缘网关采集通道配置：一个通道对应一台设备或一组从站 gateway_id: GW-ST0007-01 channels: - name: inv_03 # 通道名，与点表中的设备编号对齐 protocol: modbus_tcp endpoint: 192.168.10.33:502 unit_id: 1 # 从站地址，多台设备串联时逐个配置 poll_interval_ms: 2000 # 轮询周期，点位多时不要低于1000 timeout_ms: 800 # 超时时间，超过3次连续失败置通道离线 retry: 2 points_file: points/inv_standard_v2.csv # 点表外置，便于批量替换 - name: station_meter protocol: iec104 endpoint: 192.168.10.10:2404 common_address: 1 # 104 公共地址，配错会导致全通道无数据 poll_interval_ms: 1000 cache: enabled: true retention_hours: 168 # 本地缓存7天，断网恢复后按时间戳续传

这段配置里有两个参数最值得盯：poll_interval_ms和cache.retention_hours。轮询周期不是越小越好，一台网关挂三十台逆变器、每台两百个点，2 秒轮询已经接近串行总线的带宽上限，再压就会大面积超时；缓存保留时长要和场站最长的通信中断时长对齐，山区站点按 7 天配是常见做法，配 24 小时的方案基本都会在第一次长断网时丢一整段曲线。

3.3 边缘侧的数据兜底：时间戳对齐与死值过滤

数据进了平台不代表能用。原始数据里至少有三类脏数据：时间戳漂移（设备时钟跑偏几分钟）、死值（通讯正常但数值卡住不动）、跳变（单点毛刺，物理上不可能）。这三类数据如果直接进告警引擎，值班员一天能收到几百条无效推送，用不了两周就会把告警群静音——这是无人化项目最典型的死法。

存储层我一般会单独留一个质量字段，把判定结果跟数值一起写进去：

-- 场站原始测点表：按天分区，保留1分钟粒度原始值 CREATE TABLE fact_station_point_1m ( station_id VARCHAR(32) NOT NULL, -- 场站编码 point_code VARCHAR(64) NOT NULL, -- 点位编码，四段式命名 ts TIMESTAMP NOT NULL, -- 采集时间，取设备侧校时后的时间 val DOUBLE PRECISION, -- 工程值，入库前已做量纲换算 quality SMALLINT DEFAULT 0, -- 0正常 1死值 2跳变 3补点 4通讯中断 PRIMARY KEY (station_id, point_code, ts) ); -- 可用率统计：验收阶段直接用这条口径，避免各说各话 -- 可用率 = quality = 0 的点位数 / 应采点位数

quality字段的价值不只是标记，它同时是查询过滤条件、告警判断依据和验收举证材料。验收时对方问「数据完整率多少」，有这张表就能直接出数，没有就只能拍脑袋。

死值的判定逻辑放在边缘侧做，规则本身不复杂，难点在于只对物理上必然波动的点位开启：

DEAD_WINDOW = 6 # 连续6个采样点数值不变，判定为死值 DEAD_EPS = 1e-6 # 变化阈值，浮点比较留一点余量 def mark_quality(series, expected_interval): """给单个点位的时序打质量标记，返回 (ts, val, quality) 列表""" out, same_run = [], 1 for i, (ts, val) in enumerate(series): quality = 0 if i > 0: gap = (ts - series[i - 1][0]).total_seconds() prev_val = series[i - 1][1] if gap > expected_interval * 1.5: quality = 4 # 通讯中断：时间差超过1.5倍周期 elif abs(val - prev_val) < DEAD_EPS: same_run += 1 if same_run >= DEAD_WINDOW: quality = 1 # 死值：连续多点不动 else: same_run = 1 out.append((ts, val, quality)) return out

这段代码里DEAD_WINDOW和DEAD_EPS两个参数要按点位类型分开配：风速、功率、电流这类连续波动的模拟量开启死值判定；开关量、定值、档位这类本来就不该变的点位必须关掉，否则每天都有一堆「死值」告警，纯属给自己找麻烦。跳变判定同理，组串电流在云遮工况下本来就会大幅波动，阈值设紧了全是误报。

4. 无人化操作闭环：智能巡检编排、告警分级与自动控制的边界

4.1 巡检编排：无人机、机器人、固定视频怎么排班

巡检这块最容易做成「设备展示」——无人机飞了几架次、生成了几千张图，然后呢？图片躺在服务器里没人看，巡检等于没做。编排的核心不是飞多少，而是任务和缺陷库打通：每次巡检产生的结果要落到缺陷记录上，缺陷记录要能生成工单，工单闭环后要回写设备台账。

排班里有个细节值得写进方案：无人机航线要和机位编号、组件区编号绑定，不能只存一条航线文件。这样缺陷出来以后能直接定位到「3 号机位 A 叶片距叶尖 12 米处」，工单派得出去，复核也好比对。另外大风、雷雨之后的加飞要写成规则，不能靠人记得，这类天气恰恰是缺陷高发窗口。

4.2 告警分级与抑制：让值班员只看该看的

无人化的场站值班人员本来就少，告警设计的目标是「每条推出来的告警都值得看一眼」。分级用三级就够：P1 立即处置（保护动作、越限、烟火）、P2 当班处置（功率异常、温度偏高）、P3 纳入检修计划（轻微离群、电池电压偏差）。分级之外还必须配抑制，否则一次通讯中断能衍生出上百条下级告警：

- id: WT_POWER_LOW name: 风机有功功率偏低 level: P2 # 10分钟均值低于额定功率的30%，持续15分钟才触发，避开启停阶段 expr: avg(power_kw, 10m) < 0.3 * rated_power for: 15m suppress: - when: comm_state == 0 # 通讯中断时抑制全部功率类告警 - when: maintain_flag == 1 # 检修票期间抑制，避免检修自己触发告警 - window: 20m # 同一点位20分钟内只推一次 notify: [值班台, 区域运维群] - id: INV_STRING_DEVIATION name: 组串电流离群 level: P3 # 与同汇流箱内其他组串的中位数比较，比固定阈值抗云遮影响 expr: current_a < 0.7 * median(current_a, group=combiner_id, window=30m) for: 30m suppress: - when: irradiance < 200 # 低辐照时段不判离群 notify: [巡检计划]

配置里有几个参数决定了误报率：for是持续时间，太短会在设备启停阶段疯狂触发；window是去重窗口，同一故障反复推会让人麻木；when是抑制条件，最值得花时间打磨的是「通讯中断抑制下级」和「检修票抑制」这两条，它们能砍掉大半无效告警。表达式里用中位数而不是固定阈值判断组串离群，是抗云遮影响的常见做法，比拍一个固定电流值靠谱得多。

4.3 自动控制的红线：三类动作分级授权

自动化控制系统是白皮书里最容易写过头的地方。真实项目里有一条我始终坚持的原则：能自动调节，不等于能自动操作。按授权级别分三类，方案里写清楚，后面出问题也讲得明白。

「禁止远程」这一条不要含糊。方案里明确写出来，评审时反而是加分项——说明设计者知道边界在哪。开关操作类做成单步执行、失败不重试，也是血泪经验：远程复位连着下发三次，设备侧状态机直接卡死，现场还得跑一趟。

5. 避坑与常见问题排查：五条最容易翻车的线

5.1 网关「假在线」：心跳正常，数据全零

现象是监控页面上设备状态显示绿色在线，但所有测点数值恒为 0，或者停在某个固定值上。原因是网关的心跳走的是自己跟平台之间的链路，跟设备侧采集是两回事，设备掉线时心跳照样通。解决上要改判定口径：在线状态由「最近一次成功采集时间」决定，超过三个轮询周期没有新数据就置为离线；同时在点表层记录last_success_ts，监控页展示的是这个时间而不是心跳时间。

5.2 巡检图像堆成山，没人点开

现象是无人机每月飞几架次，图库几千张，缺陷记录寥寥无几。原因是巡检任务和缺陷库没打通，图像按架次存、缺陷按设备存，中间少了一层绑定。做法是把航线与设备台账绑定，图像按「机位/组件区 + 部件 + 位置」自动归档，识别结果直接生成待确认缺陷，人工只做确认和定级，不做从零开始的翻找。

5.3 告警风暴：阈值直接照抄设备手册

现象是投运第一周每天几百条告警，第二周值班员把告警群静音了。原因是阈值用的是设备铭牌参数或手册推荐值，没考虑场站的实际工况，比如高原场站的风速、沙尘地区的辐照衰减。解决上先跑两周观察期，把告警只记录不推送，统计各条规则的触发频次和真实命中率，把命中率低于三成的规则重写或者下线，再开推送。

5.4 无人化之后没人会手动：人机切换演练漏了

现象是系统升级或者平台故障那天，值班员发现手动操作路径已经生疏，切不回就地控制。原因是方案里只设计了自动流程，没设计退出机制。这一条必须写进方案：保留完整的手动操作路径，就地控制柜的标识和操作票同步更新，每季度做一次人机切换演练并留记录。

5.5 验收时拿不出数：指标没在设计阶段定义

现象是验收会上被问「现场确认工单下降了多少」，翻遍系统拿不出改造前的基线数据。原因是方案里只写了功能，没写指标口径和采集方式。做法是在设计阶段就把三到五个核心指标写进方案，连同计算公式、数据来源表、统计周期一起定死，投运前先采一段基线，否则后面所有对比都是空谈。

6. 验收与答辩：一张指标表加三个演示场景就够了

验收和答辩本质是同一件事：用最短的时间让别人相信这套方案真的跑起来了。我的做法是准备一张表加三个场景，能讲清楚就不用堆功能列表。

指标表建议控制在五到六行，每行都要有基线、目标值和数据来源，缺一项就会被追问：

三个演示场景按「发现—判断—处置」串起来，每个控制在三分钟以内。第一个演数据链路：现场拔掉一台网关的网线，演示本地缓存、恢复后续传、数据不丢；这个场景最能证明边缘层不是摆设。第二个演告警闭环：人为制造一个组串离群，从触发、分级、抑制、派单到工单回写走一遍，重点展示抑制规则生效，避免一次故障推几十条。第三个演巡检闭环：从航线任务下发到缺陷生成再到工单派发，展示图像和设备的绑定关系。

答辩被追问最多的三个点，提前准备好答案：一是无人化之后出了事故谁负责，答案是保留人工确认环节和完整操作留痕，自动动作全部有边界和回退；二是断网怎么办，答案是边缘缓存加断点续传，给出具体的保留时长；三是这套东西能不能复制到别的场站，答案在点表规范和配置外置上，接口层不动、配置层改。

从那以后我每次做这类方案，都强制先写验收指标表再写功能清单——顺序倒过来，最后一定要返工。希望帮到你。

本文还有配套的精品资源，点击获取