简介《新能源“无人化”场站解决方案白皮书》聚焦新能源场站的智能运营与少人值守由金风服务GOLDWIND推出面向新能源电站运维、能源数字化建设及智慧场站方案设计人员回应场站自动监控、无人化操作和安全管理等实际问题。全文共32页以1个PDF文件交付压缩包约41.53MB便于电脑端查阅、归档与团队传阅已有292人学习具备一定参考热度。内容围绕智能化场站、自动化控制系统、物联网与数据分析、能源生产效率及安全性展开兼顾技术特点、应用场景和成本效益分析可帮助读者梳理远程监控、自动控制、风险降低与降本增效的整体思路。对方案调研、项目汇报、内部培训或场站改造前期论证而言这份白皮书可作为了解新能源无人化场站建设路径的参考资料。1. 从一次凌晨三点的巡检工单说起新能源场站为什么要做无人化有个做运维的朋友吐槽过一件事他们那片山地光伏场站凌晨三点报了一条组串电流异常值班员开了四十分钟车到现场发现只是汇流箱通讯模块掉线。这类「为了确认一个本不该报的信号而跑一趟」的工单在新能源场站里占的比例相当高。新能源「无人化」场站解决方案要解决的正是这件事——不是把人全部撤走而是把「必须到现场才能判断」的比例压下去让智能化场站替人完成第一轮筛选和判断。这套方案面向陆上风电、集中式光伏、分散式风光互补几类场景交付形态是一份可落地的白皮书式设计分层架构、统一点位模型、巡检编排、告警策略、验收指标。手里有毕设或课程设计要交的人可以照着这套结构走完需求、设计、实现、验收要给客户出交付方案的集成商可以拿它改一版直接对上去讲。2. 需求拆解与总体架构四层结构与三类场站的能力边界2.1 三条需求主线少跑腿、早发现、可回溯把「无人化」当成目标去写方案很容易写成设备清单。我一般会先把它拆成三条能验收的需求主线后面所有模块都往这三条上挂。第一条是少跑腿。核心指标是现场确认类工单的下降比例通常的做法是统计改造前后三个月的「到场后判定为无需处理」的工单占比行业里做得比较扎实的项目能压掉四到六成。这条需求直接决定了视频、在线监测、边缘诊断要布到什么密度。第二条是早发现。人工巡检的周期是季度级甚至半年级缺陷从产生到被发现之间有一段很长的空窗。无人化方案要把它压到周级叶片裂纹、组件热斑、汇流箱发热、箱变油温异常靠固定视频加移动巡检组合去覆盖。这里衡量的是缺陷平均发现周期不是巡检次数。第三条是可回溯。出了问题要能还原「当时是什么数据、谁做了什么判断、系统给了什么建议」。很多方案在这一条上栽跟头——数据存了但采样周期被聚合过告警推了但没留触发时的原始值事后复盘只能靠人回忆。可回溯做不好前面两条做得再漂亮验收时也讲不清。提示安全性在方案里不要只写「提升安全性」这种结论句要落到具体指标上比如「高风险作业人次下降比例」「越限告警的平均响应时长」否则验收阶段没法举证。2.2 总体架构从感知层到应用层的四层划分整个无人化场站的骨架我习惯切成四层每层都对应明确的交付物和失败表现。分层的好处是模块再多也不会写成平铺的功能列表每一层缺什么、坏在哪排查时有落点。层级主要职责典型设备与技术交付物典型失败表现感知层采集电气量、环境量、图像与振动信号智能电表、汇流箱监测模块、振动传感器、热成像球机、无人机、挂轨机器人点位清单、设备台账、安装点位图装了没人用图像不回流边缘层协议转换、本地缓存、初步诊断、断点续传边缘网关、工业交换机、本地存储通道配置表、缓存策略、时钟同步方案断网期间数据整段丢失平台层数据存储、点位模型、告警引擎、规则管理时序数据库、消息队列、规则引擎点表、告警规则库、接口文档数据在但查不出、规则改了不生效应用层集中监控、巡检管理、工单闭环、报表监控大屏、移动端、工单系统页面原型、场景脚本、验收指标大屏好看值班员不用四层里最容易做薄的是边缘层。很多方案把它当成一个「协议盒子」实际上它承担了三件事断网时的数据兜底、告警的第一道过滤、以及给平台层减负。边缘层做扎实平台侧的压力会小一个量级。2.3 三类场站的差异化配置不做一套模板套所有同一份白皮书要覆盖风电、集中式光伏、分散式场景就必须在架构不变的前提下做配置差异。我一般会在方案里单列一节讲这个因为评审最常问的一句话就是「我们这种场站适用吗」。陆上风电的核心是机舱与塔筒内部的连续量监测重点是振动、温度、功率曲线偏离巡检对象是叶片和塔筒焊缝无人机航线要按机位单独规划。集中式光伏的核心是组串级电流电压和汇流箱温度点位密度高但单点价值低重点在聚合与离群检测巡检对象是组件热斑和支架变形。分散式场站点多面广、单站容量小通信成本往往比设备成本还敏感方案上要允许降采样和事件触发上传不能按集中式的采集频率硬套。维度陆上风电集中式光伏分散式采集密度中单机几百点高组串级上万点低按事件触发通信方式光纤为主光纤加环网无线为主成本敏感巡检主力无人机看叶片无人机热成像看组件固定视频为主关键指标功率曲线符合度组串离群率通信可用率3. 数据底座统一点位模型、采集链路与边缘侧的质量兜底3.1 统一点位模型先定名再谈采集无人化方案返工最多的地方不在算法在点表。不同厂家设备自带的点表命名五花八门同一个「有功功率」可能叫 P、ActivePower、有功、kw_p接进平台之后全靠人工映射接三个场站就开始乱。我一般要求在设计阶段先把命名规则定死场站编码.设备类型.设备编号.测点标识全小写用点分隔不用中文。字段说明示例station_id场站编码全局唯一ST0007point_code点位编码遵循四段式命名st0007.inv.03.power_kwpoint_type数据类型模拟量/开关量/累计量analogunit工程单位统一 SI不混用kWsample_interval采样周期秒60deadband死区变化小于该值不入库0.5store_policy存储策略原始/1分钟/1小时raw_1malarm_enable是否参与告警计算true定完点表还要定三件事单位统一功率统一 kW不混用 MW、时间戳统一一律用设备侧时间并做 NTP 校时平台侧不打时间、累计量单独标记发电量这类累计量要做差值处理不能直接存瞬时值。这三件事看起来琐碎但后面数据对不上、日报表和月报表打架基本都是这里埋的雷。3.2 采集链路怎么搭四种协议与网关的取舍新能源场站里能见到的协议就那么几种选型上没必要追求统一按设备侧有什么就用什么转换工作交给边缘网关。协议适用对象实时性常见踩坑点Modbus TCP/RTU汇流箱、逆变器、电表秒级寄存器地址偏移、字节序反了IEC 60870-5-104升压站测控、保护装置毫秒到秒公共地址与信息体地址配错OPC UA风机主控、部分 PLC秒级节点 ID 变动后订阅失效MQTT分散式站点、自研终端秒级QoS 设 0断网直接丢数据网关侧的配置我一般写成可版本管理的配置文件不写在设备界面里。这样换网关、加通道的时候能对比差异出问题也能回滚# 边缘网关采集通道配置一个通道对应一台设备或一组从站 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 巡检编排无人机、机器人、固定视频怎么排班巡检这块最容易做成「设备展示」——无人机飞了几架次、生成了几千张图然后呢图片躺在服务器里没人看巡检等于没做。编排的核心不是飞多少而是任务和缺陷库打通每次巡检产生的结果要落到缺陷记录上缺陷记录要能生成工单工单闭环后要回写设备台账。巡检手段覆盖对象周期触发方式产出无人机可见光热成像叶片、组件、支架、集电线路月度定时航线 大风后加飞缺陷位置、等级、图像挂轨机器人升压站、开关柜、电缆沟每日定时表计读数、局放、温度固定视频周界、箱变、塔筒底部常驻事件触发 AI 识别告警片段、抓拍图人工巡检无人机盲区、复杂缺陷复核季度计划复核结论排班里有个细节值得写进方案无人机航线要和机位编号、组件区编号绑定不能只存一条航线文件。这样缺陷出来以后能直接定位到「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, groupcombiner_id, window30m) for: 30m suppress: - when: irradiance 200 # 低辐照时段不判离群 notify: [巡检计划]配置里有几个参数决定了误报率for是持续时间太短会在设备启停阶段疯狂触发window是去重窗口同一故障反复推会让人麻木when是抑制条件最值得花时间打磨的是「通讯中断抑制下级」和「检修票抑制」这两条它们能砍掉大半无效告警。表达式里用中位数而不是固定阈值判断组串离群是抗云遮影响的常见做法比拍一个固定电流值靠谱得多。4.3 自动控制的红线三类动作分级授权自动化控制系统是白皮书里最容易写过头的地方。真实项目里有一条我始终坚持的原则能自动调节不等于能自动操作。按授权级别分三类方案里写清楚后面出问题也讲得明白。动作类型示例授权级别回退策略连续调节类无功电压调节、功率因数调整全自动越限自动回中位5 分钟未收敛转人工限值类AGC/AVC 限功率、储能充放电功率自动执行 通知调度指令优先本地策略不得覆盖开关操作类断路器分合、逆变器启停、风机复位人工确认后执行单步执行失败不重试转人工定值与保护类保护定值修改、参数下发禁止远程仅支持本地操作并留痕「禁止远程」这一条不要含糊。方案里明确写出来评审时反而是加分项——说明设计者知道边界在哪。开关操作类做成单步执行、失败不重试也是血泪经验远程复位连着下发三次设备侧状态机直接卡死现场还得跑一趟。5. 避坑与常见问题排查五条最容易翻车的线5.1 网关「假在线」心跳正常数据全零现象是监控页面上设备状态显示绿色在线但所有测点数值恒为 0或者停在某个固定值上。原因是网关的心跳走的是自己跟平台之间的链路跟设备侧采集是两回事设备掉线时心跳照样通。解决上要改判定口径在线状态由「最近一次成功采集时间」决定超过三个轮询周期没有新数据就置为离线同时在点表层记录last_success_ts监控页展示的是这个时间而不是心跳时间。5.2 巡检图像堆成山没人点开现象是无人机每月飞几架次图库几千张缺陷记录寥寥无几。原因是巡检任务和缺陷库没打通图像按架次存、缺陷按设备存中间少了一层绑定。做法是把航线与设备台账绑定图像按「机位/组件区 部件 位置」自动归档识别结果直接生成待确认缺陷人工只做确认和定级不做从零开始的翻找。5.3 告警风暴阈值直接照抄设备手册现象是投运第一周每天几百条告警第二周值班员把告警群静音了。原因是阈值用的是设备铭牌参数或手册推荐值没考虑场站的实际工况比如高原场站的风速、沙尘地区的辐照衰减。解决上先跑两周观察期把告警只记录不推送统计各条规则的触发频次和真实命中率把命中率低于三成的规则重写或者下线再开推送。5.4 无人化之后没人会手动人机切换演练漏了现象是系统升级或者平台故障那天值班员发现手动操作路径已经生疏切不回就地控制。原因是方案里只设计了自动流程没设计退出机制。这一条必须写进方案保留完整的手动操作路径就地控制柜的标识和操作票同步更新每季度做一次人机切换演练并留记录。5.5 验收时拿不出数指标没在设计阶段定义现象是验收会上被问「现场确认工单下降了多少」翻遍系统拿不出改造前的基线数据。原因是方案里只写了功能没写指标口径和采集方式。做法是在设计阶段就把三到五个核心指标写进方案连同计算公式、数据来源表、统计周期一起定死投运前先采一段基线否则后面所有对比都是空谈。6. 验收与答辩一张指标表加三个演示场景就够了验收和答辩本质是同一件事用最短的时间让别人相信这套方案真的跑起来了。我的做法是准备一张表加三个场景能讲清楚就不用堆功能列表。指标表建议控制在五到六行每行都要有基线、目标值和数据来源缺一项就会被追问指标基线目标数据来源数据可用率投运前一周实测≥ 95%点位表 quality 字段统计无效告警占比观察期统计≤ 20%告警表 处置结论现场确认类工单占比改造前三个月下降 40% 以上工单系统分类缺陷平均发现周期季度人工巡检缩短至 30 天以内缺陷库时间戳高风险作业人次改造前统计下降 50%作业票三个演示场景按「发现—判断—处置」串起来每个控制在三分钟以内。第一个演数据链路现场拔掉一台网关的网线演示本地缓存、恢复后续传、数据不丢这个场景最能证明边缘层不是摆设。第二个演告警闭环人为制造一个组串离群从触发、分级、抑制、派单到工单回写走一遍重点展示抑制规则生效避免一次故障推几十条。第三个演巡检闭环从航线任务下发到缺陷生成再到工单派发展示图像和设备的绑定关系。答辩被追问最多的三个点提前准备好答案一是无人化之后出了事故谁负责答案是保留人工确认环节和完整操作留痕自动动作全部有边界和回退二是断网怎么办答案是边缘缓存加断点续传给出具体的保留时长三是这套东西能不能复制到别的场站答案在点表规范和配置外置上接口层不动、配置层改。从那以后我每次做这类方案都强制先写验收指标表再写功能清单——顺序倒过来最后一定要返工。希望帮到你。本文还有配套的精品资源点击获取