简介这份白皮书聚焦新能源场站“无人化”建设面向新能源运营方、场站运维人员与解决方案规划者旨在回答如何借助智能化、自动化手段提升场站生产效率与安全性。全文共32页打包为1个PDF文件压缩包约41.53MB结构完整便于直接查阅和团队内部传阅。内容结合金风服务GOLDWIND的实践梳理智能化场站、无人化操作与自动化控制系统的整体思路并讨论物联网、人工智能、数据分析在自动监控、远程控制和生产管理中的应用同时涉及技术特点、应用场景、成本效益分析、安全风险控制等关键议题。读者可据此了解无人化场站从方案设计到落地运维的主要环节也能为项目调研、立项论证和既有场站升级提供较为具体的参考资料。目前已有292人学习。1. 无人化场站真正难的不是机器人是把值班表重新排一遍一个装机 200MW 的风电场夜里两点中控室还坐着两个人一个盯 SCADA 告警一个打电话叫检修。你问他们场站能不能无人化十有八九会回你一句摄像头装了、无人机也飞了人不还是得在问题就出在这——大多数所谓的新能源无人化场站解决方案只做了看得见没做判得准、控得住、兜得回来。真正卡住无人化的从来不是机器人不够多而是告警没人收敛、点位各叫各的名字、远程操作没有联锁兜底、出了事责任说不清。这份 32 页白皮书要解决的正是这四件事把感知、边缘、平台、应用四层拉通把少人值守拆成可分级、可验收的工程条目。适合正在做新能源场站智能化毕设的学生也适合要给区域公司出一版可交付方案的从业者。2. 需求与边界先分清哪些能无人、哪些必须留人无人化最容易犯的错是把减少现场常驻人员直接理解成取消所有人。真做过项目的人都知道风电、光伏这类场站的无人化是有边界的升压站倒闸操作、风机塔筒内作业、消防应急处置这些环节短期内不可能把人拿掉。所以方案的第一步不是画架构图而是做现状盘点和分级把能无人和必须留人的边界先划死后面的技术和预算才有落点。2.1 现状盘点的四个断点第一类是感知断点。场站里的视频监控、消防主机、门禁、环境监测、箱变测控往往是不同年份、不同厂家分批上的各有一套后台谁也不给谁数据。值班员要看全站状态桌面上摆四个客户端切来切去热词里说的数据孤岛在这儿不是概念是每天晚上真实发生的操作。第二类是数据断点。同一台风机SCADA 里叫WT01_GearBoxTemp振动系统里叫1#齿轮箱温度到了集团侧报表又变成T_01_GB_T。点位不统一任何跨系统的分析和模型都无从谈起。更麻烦的是历史数据留存周期短多数场站只存三个月到半年想做趋势诊断、做设备劣化的基线样本根本不够。第三类是决策断点。传统告警只报现象不报原因一台风机报振动超限背后可能是轴承磨损、可能是对中不良、也可能只是传感器松动。值班员靠经验判断经验又只长在少数几个老师傅身上。人不走知识走不了人一走判断力就断了这是无人化最隐蔽的一道坎。第四类是执行断点。很多场站做到了远程看得见但没做到远程控得住——复位、启停、切换这些动作要么必须两人到场要么压根没有远程通道。看得见控不了人还是得去无人化就停在纸面上。盘点阶段通常的做法是列一张断点清单按影响哪个业务、影响多大、改造成本多少三列打分先改高分低成本的。我一般会要求把每个断点落到现场照片和系统截图上别写辅控系统未集成这种虚话写清楚是哪台设备、哪个接口、什么协议。2.2 无人化按 L0 到 L4 分级别一上来就喊全无人白皮书里最值得抄的一段是把无人化拆成等级而不是给一个笼统的实现无人化目标。等级划分让甲乙双方在方案阶段就能对齐预期也避免了验收时扯皮。通常的做法是按下表定义等级定义现场常驻典型特征适用场站L0传统有人值守每班 2 至 3 人就地监控、就地操作新投运、未改造场站L1集中监控、少人值守每班 1 至 2 人数据上传集控中心告警统一接收区域已建集控的场站L2无人值班、少人值守白天 1 人夜间无人视频巡检替代例行巡查远程复位可用辅控较完整的场站L3无人值班、定期巡检无常驻按周巡检自动巡检闭环、异常自动生成工单新建或整体改造场站L4全自主运行无常驻按需检修控制策略自寻优、故障自愈示范项目暂不普遍分级的意义在于给改造定节奏。多数运营方真正的目标其实是 L2 到 L3而不是 L4。把 L3 写成目标配套的技术投入、组织调整、制度修订都在可控范围内一开口就是 L4方案会写得很漂亮落地时一定会翻车。提示分级要和场站类型绑定。分布式光伏、集中式风电、储能电站的边界完全不同储能因为有消防和高低压操作短期内很难做到 L3 以上。2.3 把需求写成可验收的条目需求写成提高安全性、降低运维成本这种话等于没写。无人化方案的需求必须落到场景、指标口径和验收方式三要素上下面这张表是方案里最该做实的一页编号场景现状目标验收方式R-01日常巡检每日人工巡检 2 次单次 90 分钟视频与机器人巡检替代 80% 例行巡检连续 30 天巡检记录比对R-02告警处理日均 400 条有效率不足 10%收敛后日均不超 40 条有效率超 60%抽取 7 天告警逐条复核R-03远程复位需两人到场平均 45 分钟具备条件的故障远程复位10 分钟内完成复位成功率与耗时统计R-04故障预警事后告警关键部件提前 7 天预警准确率超 70%回溯 6 个月历史数据验证R-05数据完整性断网即丢数断网 4 小时内数据完整率 99%断网演练 数据比对R-01 和 R-02 是无人化的核心支撑R-03 决定人能不能真的撤走R-04 是加分项R-05 是底线。写方案时把 R-05 放在最后很容易被忽略但它是唯一一条不达标就整个方案不成立的硬指标——数据断了、补不回来后面的模型和报表全是假的。3. 总体架构设计四层结构与两条不能上云的链路架构图谁都会画难的是说清每层的职责边界和什么数据必须留在本地。很多方案把四层结构画得很齐整一到实施就发现边缘侧算力不够、控制链路时延超标只能回退成云端集中处理等于把安全性押在公网上。这一章按白皮书的思路把层次划分和链路预算讲透。3.1 感知、边缘、平台、应用四层各管什么感知层负责取全。它不只是 SCADA还包括振动在线监测、油液、红外测温、视频与声学、消防与门禁、环境与气象。这一层的设计原则是能采尽采、按需上传——不是所有点位都要秒级上传但所有点位都必须有统一的命名和时标。边缘层负责判快。部署在场站侧的一台边缘网关或小型服务器承担三件事协议转换与数据清洗、本地规则判断告警初筛、阈值联动、断网缓存。它是对时延最敏感的一层也是无人化能不能成立的关键。我的经验是边缘节点不要追求大而全一台设备只跑规则和缓存把重模型留给平台侧稳定性会好很多。平台层负责存准、算准。统一时序库存原始数据设备模型库存主数据算法服务跑诊断模型和劣化预测。这一层的核心资产是设备模型和标签体系不是服务器数量。应用层负责用起来。集控大屏、巡检工单、告警中心、报表、移动端。这一层最忌讳堆功能无人化场景下真正每天被打开的就那么两三个页面告警列表、巡检任务、设备详情。注意四层之间不是严格串行的。视频这类大带宽数据通常走独立通道直达平台不经过边缘规则引擎否则边缘节点会被视频流拖垮。3.2 数据流与时延预算哪条链路不能走云端架构能不能落地最后都收敛成一张时延和带宽预算表。下表是这类项目里我通常会先跟甲方对齐的口径业务采样周期端到端时延单站带宽估算部署位置风机 SCADA 遥测1 至 5 秒小于 3 秒200 至 500 kbps边缘 平台振动在线监测连续采集按帧上传特征值分钟级1 至 3 Mbps边缘视频巡检按任务触发秒级4 至 20 Mbps独立通道远程控制指令事件触发小于 500 毫秒极小本地闭环消防与安防联动事件触发小于 1 秒极小本地闭环表里最关键的两行是最后两行控制指令和消防联动不能依赖云端往返。公网抖动个两三百毫秒远程操作的体感就完全变了消防联动要是等云端下发等回来火已经起来了。所以架构上必须坚持本地闭环、云端监督——控制逻辑跑在场站侧云端只做策略下发和操作审计。带宽估算也要留余量。按经验视频通道按峰值的 1.5 倍报遥测按点位数乘平均帧长再乘 1.3否则一到雨雪天摄像头码率上去整条链路就堵。3.3 边缘节点部署与断网续传断网续传是无人化的后悔药。场站大多在山区、戈壁、海上链路中断是常态而不是异常。边缘节点必须能在断网期间本地缓存至少 4 小时的全量数据恢复后按时间序补传并且要能处理重复写入。下面这段是边缘侧缓存与补传的核心逻辑Python 写得比较直白实际工程里会换成 C 或 Go但状态机是一样的# 边缘侧断网缓存与补传先落本地再按序回放 import time, sqlite3, json CACHE_DB /data/edge_cache.db BATCH 500 # 单次补传条数按链路质量调 RETRY_INTERVAL 30 # 补传失败重试间隔秒 def buffer_point(tag, ts, value): 断网时写入本地环形缓存tag 为标准化点位名 conn sqlite3.connect(CACHE_DB) conn.execute( INSERT OR IGNORE INTO cache(tag, ts, value) VALUES (?,?,?), (tag, ts, json.dumps(value)) ) conn.commit() conn.close() def replay(client): 链路恢复后按时间序补传成功的记录删除失败的留着重试 while True: conn sqlite3.connect(CACHE_DB) rows conn.execute( SELECT id, tag, ts, value FROM cache ORDER BY ts LIMIT ?, (BATCH,) ).fetchall() if not rows: conn.close() break try: client.push([{tag: r[1], ts: r[2], value: json.loads(r[3])} for r in rows]) conn.execute( DELETE FROM cache WHERE id IN (%s) % ,.join(? * len(rows)), [r[0] for r in rows] ) conn.commit() except Exception: conn.close() time.sleep(RETRY_INTERVAL) # 链路仍不稳定退避后重试 continue conn.close()这段逻辑有三个设计点值得说。INSERT OR IGNORE依赖(tag, ts)上的唯一索引保证设备重发不会写重ORDER BY ts保证补传顺序时序库对乱序写入的容忍度很低乱序会导致聚合查询结果错乱BATCH不要设太大链路刚恢复时带宽不稳一次推 5000 条很容易整批失败重来500 条是个比较稳的量级。缓存表还需要一个容量上限。按单站 5000 点位、5 秒周期算一小时约 360 万条记录SQLite 撑得住但磁盘要留够一般做法是加一个定期清理任务保留最近 72 小时超期数据落盘压缩别让它把边缘节点的系统盘撑爆。4. 关键模块实现从点位标准化到控制联锁的三段硬骨头架构讲完真正决定项目成败的是三个模块设备模型与点位标准化、巡检与诊断闭环、控制许可与联锁。这三块对应前面盘点的数据断点、决策断点和执行断点缺一个无人化就只能在演示环境里跑。4.1 设备模型与点位标准化先把名字统一了点位标准化是所有智能化的前置条件也是最枯燥、最容易偷工减料的一步。常见做法是建立场站—设备类型—设备实例—测点四级模型测点名用统一编码中文名只作为展示别名。下面是一个风机齿轮箱测点的模型定义{ stationId: ST-001, deviceType: WIND_TURBINE, deviceId: WT-017, points: [ { tag: WT.WT017.GBX.OIL_TEMP, name: 齿轮箱油温, unit: degC, dataType: float, samplePeriod: 5, deadband: 0.5, alarmLevel: [H, HH], ref: { source: SCADA, addr: 40021 } }, { tag: WT.WT017.GBX.VIB_X, name: 齿轮箱振动X向, unit: mm/s, dataType: float, samplePeriod: 1, deadband: 0.05, alarmLevel: [H], ref: { source: CMS, addr: ch01 } } ] }tag采用对象.实例.部件.测点的四段式好处是可以直接前缀匹配批量查询做区域级统计时不用再维护映射表。deadband是死区也就是变化量小于该值不上传这一项能砍掉相当比例的无效数据量对带宽紧张的场站尤其重要。ref保留原始来源和地址方便回溯和联调排查别把原始地址丢掉否则现场对点位时会非常痛苦。时序数据落到平台侧通常建两张表一张窄表存原始值一张按小时或天聚合的宽表供报表使用-- 原始时序表按时间和标签建联合索引写入为主 CREATE TABLE ts_point_raw ( tag VARCHAR(64) NOT NULL, ts TIMESTAMP NOT NULL, value DOUBLE PRECISION, quality SMALLINT DEFAULT 0, -- 0正常 1可疑 2无效 PRIMARY KEY (tag, ts) ); -- 小时聚合表报表和诊断模型主要读这张 CREATE TABLE ts_point_hourly ( tag VARCHAR(64) NOT NULL, stat_hour TIMESTAMP NOT NULL, avg_val DOUBLE PRECISION, max_val DOUBLE PRECISION, min_val DOUBLE PRECISION, sample_cnt INTEGER, PRIMARY KEY (tag, stat_hour) );quality字段别省。传感器故障、通信中断时写进去的值是无效的如果不打标后面算可利用率、算均值都会被污染。经验值是质量位为 2 的点在统计时直接剔除为 1 的点参与计算但打标记报表里单独列一栏说明。4.2 智能巡检闭环任务、识别、工单三件事串起来巡检不是摄像头拍到就行而是一个完整闭环任务下发、采集识别、结果复核、异常转工单、工单回写。很多项目只做了前半段识别结果堆在系统里没人看运维自然不买账。巡检任务的核心是一个状态机用 Python 表达最清楚# 巡检任务状态机pending - running - reviewing - closed import enum, datetime class TaskState(enum.Enum): PENDING pending # 已生成等待执行 RUNNING running # 设备正在采集 REVIEWING reviewing # 识别完成待人工复核 CLOSED closed # 已闭环无异常或已转工单 def advance(task, event, payloadNone): 按事件推进状态非法跃迁直接拒绝避免状态错乱 rules { (TaskState.PENDING, start): TaskState.RUNNING, (TaskState.RUNNING, finish): TaskState.REVIEWING, (TaskState.REVIEWING, pass): TaskState.CLOSED, (TaskState.REVIEWING, defect): TaskState.CLOSED, # 同时生成工单 } nxt rules.get((task.state, event)) if nxt is None: raise ValueError(非法状态跃迁: %s %s % (task.state, event)) if event defect: # 缺陷等级决定工单时限一般缺陷 7 天严重缺陷 24 小时 task.workorder_id create_workorder( devicetask.device_id, defect_typepayload[defect_type], levelpayload[level], deadlinedatetime.datetime.now() payload[sla] ) task.state nxt task.save() return taskrules这张迁移表是这套代码的价值所在。巡检任务一旦被并发操作或者被脚本重复触发状态就会乱掉出现任务还在识别中就被标为已闭环这类脏数据。把合法迁移写死成白名单非法事件直接抛异常比事后修数据省事得多。识别环节要控制误报。视频识别在逆光、雨雾、镜头脏污的情况下误报率会飙升仅靠调模型阈值解决不了。通常的做法是加两道闸一是同一目标连续 N 帧命中才确认二是识别结果与设备实时状态做交叉校验——比如识别到叶片结冰同时段环境温度高于 5 度就自动降级为待复核而不是直接生成工单。4.3 自动控制与安全联锁谁能下发、什么条件才放行远程控制是无人化里责任最重的一块。我的原则很明确任何一条控制指令都必须过一遍独立于业务代码的许可校验校验逻辑不能写在业务分支里否则改一次业务就可能漏掉一条联锁。# 控制指令许可校验与业务逻辑解耦所有指令统一入口 def check_permit(cmd, ctx): cmd: 指令对象ctx: 场站实时上下文 返回 (是否放行, 拒绝原因) dev ctx.device(cmd.device_id) # 1. 设备本身状态检修挂牌、就地优先、故障闭锁 if dev.maintenance_lock: return False, 设备处于检修挂牌状态 if dev.local_mode: return False, 就地控制优先禁止远程操作 # 2. 场站级联锁风速、并网条件、消防状态 if ctx.wind_speed cmd.spec.max_wind: return False, 风速超限 %.1f m/s % ctx.wind_speed if ctx.fire_alarm: return False, 消防联动中禁止一切远程控制 # 3. 操作合规双人复核、操作票、时间窗 if cmd.requires_dual_check and not cmd.dual_check_passed: return False, 该指令需双人复核 if not ctx.in_allowed_window(cmd.op_type): return False, 当前时段不允许该类型操作 # 4. 二次确认写操作必须带预期结果执行后比对 if cmd.op_type in (RESET, START, STOP) and not cmd.expect: return False, 缺少执行后预期结果校验条件 return True, 这段校验函数的四个判断块对应现场最容易出事的四类情况。检修挂牌和就地优先是人的安全宁可不执行也不能误动场站级联锁是设备的安全风速、消防这类全局状态必须前置判断双人复核和操作票是责任的安全无人化之后现场没人盯着只能靠制度在系统里固化二次确认是结果的安全指令下发成功不等于执行成功必须带回预期状态比对比对不上就要触发告警并回滚。联锁表要跟这段代码一一对应并且在验收文档里单独成页。一般的规范是每条联锁写清触发条件、动作、复位方式、责任人。复位方式尤其容易漏不少项目做完发现联锁触发后没有任何路径解除只能重启整个系统这在夜里是灾难。5. 避坑与排查五个最容易在验收现场翻车的地方方案写得再完整现场总有几处躲不开。下面五条是这类项目里出现频率最高的每一条都按现象、原因、解决写遇到时可以直接对照。5.1 告警风暴把监控大屏冲垮现象系统上线第一周日均告警从 400 条涨到 3000 多条值班员直接把告警音关了大屏成了装饰。原因点位接入后把所有原始阈值告警全量透传没有收敛。一台风机通信中断会同时产生通信中断、数据超时、点位无效、变位频繁等十几条告警一个网关掉线整个下挂设备全部告警。告警量随点位数线性增长而人的处理能力是固定的。解决上三层收敛。第一层是同源收敛把同一设备在时间窗内的多条告警合并成一条事件第二层是父子抑制上级设备网关、交换机故障时抑制下挂设备的衍生告警第三层是时间窗抑制同一条告警在抑制期内不重复推送。核心代码不长# 同源告警收敛同一设备在窗口期内只保留首条其余计数合并 def converge(alarms, window_sec300): merged {} for a in sorted(alarms, keylambda x: x.ts): key (a.device_id, a.alarm_type) last merged.get(key) if last and (a.ts - last.ts).total_seconds() window_sec: last.count 1 # 合并计数不新增展示条目 last.last_ts a.ts continue merged[key] a return list(merged.values())window_sec按告警类型取值通信类给 300 秒温度类给 1800 秒工艺类给 60 秒。一刀切地设成 300 秒会把真正的工艺异常也吞掉这一点千万别图省事。5.2 视频识别误报率高运维直接弃用现象识别准确率在实验室是 92%上线后运维抱怨十条里八条是假的一个月后没人再看识别结果。原因实验室样本和现场光照、镜头洁净度、遮挡情况差异太大更关键的是识别结果没有和实时工况交叉验证导致大量技术上正确、业务上无意义的结果——比如夜里识别到人员未戴安全帽。解决加业务规则过滤把识别结果作为证据而不是结论。人形识别限定在工作时段和作业区域烟火识别要求连续多帧命中设备外观缺陷要求同时段该设备无停机记录。规则层用配置表达别写死在模型服务里现场调参时才不用改代码发布。5.3 断网期间数据补不齐现象断网演练做了 4 小时恢复后数据完整率只有 87%验收卡在这一项。原因多半是边缘缓存没设容量上限SQLite 写满后开始报错而业务侧没做降级直接丢数或者补传逻辑按批次删除中途失败后重试时批次错位部分数据永远补不上去。解决缓存加上限与清理策略保留最近 72 小时补传改为成功一条删一条或者按主键幂等写入别依赖批次顺序同时把缓存写入失败本身做成一条告警让问题在演练前就暴露。演练时一定要按最坏情况做——断网同时断摄像头看系统怎么表现。5.4 远程控制权责不清出事没人认现象远程复位功能上线后一次误操作导致风机非计划停机 6 小时事后查日志发现三条指令分别来自集控、区域公司、厂家服务人员谁也没想到别人也在操作。原因控制权限没有做互斥和抢占操作日志只记了成功没记谁在什么权限下发的。解决控制权加令牌机制同一设备同一时刻只允许一个主体持有操作权令牌超时自动释放所有指令记录操作人、角色、来源系统、预期结果和实际结果高风险指令强制双人复核并留痕。这套东西在方案阶段容易被当成管理问题跳过但它是无人化能不能长期跑下去的地基。5.5 验收口径各说各话现象乙方说告警收敛率到了 85%甲方一算只有 60%双方对着两套数据争论一周。原因分子分母定义不同。乙方按收敛后条目数除原始条目数算甲方按有效告警占比算两个指标名相近但含义完全不同。解决验收指标在方案阶段就写死计算公式、取数范围和时间窗口附件里放一页指标定义表。像告警收敛率 (原始告警数 − 推送告警数) / 原始告警数统计周期 7 天样本为全部接入点位写成这样就不会有歧义。这一页纸看着不起眼能省掉验收期一半的会议。6. 验收与答辩用一张指标表把无人化讲成可复现的结论这套方案最后能不能立住全看能不能拿出一张可复现的指标表。我的做法是在验收前两周先做一次内部预演按正式口径跑一遍数据把不达标的项提前暴露。核心指标就五条别堆太多指标计算方式目标值数据来源例行巡检替代率自动巡检次数 / (自动 人工) 次数不低于 80%巡检系统记录告警收敛率(原始 − 推送) / 原始不低于 85%告警中心 7 天数据告警有效率确认有效条数 / 推送条数不低于 60%人工复核抽样 200 条远程操作成功率成功次数 / 下发次数不低于 95%操作日志断网数据完整率补传成功条数 / 应采条数不低于 99%断网演练报告答辩时最容易被问倒的不是技术细节而是人撤走之后出了事谁在第一时间知道。这一问必须答得具体告警推到哪个岗位、多长时间内响应、响应不了升级给谁、现场无人时谁有钥匙。我一般会准备一张值班响应流程图和一张升级时限表比讲十页算法都有用。还有一个小技巧演示环节别只放识别成功的样例主动放一段失败案例说清楚系统是怎么把误报压下去的。评审最认这个因为它证明你真的跑过现场不是拿实验室结果充数。从那以后我每次做这类方案都会在方案评审前强制走一遍断网加告警风暴的双重演练通不过就不往下推。血泪经验是这两项在演示环境里从来没出过事在现场却几乎必然出事提前压一遍比事后解释省太多力气。这份 32 页的白皮书把分级模型、四层架构、联锁表和指标口径都整理成了可直接引用的图表做毕设的同学可以拿它当架构章节的骨架出方案的同行可以照着改成本地版本省下的时间拿去跑演练更值。希望帮到你。本文还有配套的精品资源点击获取