一、项目背景与需求分析
各位同行，今天咱们聊聊风电场上位机监控系统部署这件事。说实话，这活儿看着简单，但坑不少。我做了十来年风电自动化，踩过的雷能写本书。今天先讲第一章——项目背景与需求分析。
1.1 风电场上位机监控系统概述
先说说什么是上位机监控系统。说白了，就是风电场的大脑和眼睛。
风电场里几十台风机，每台都有PLC、传感器、变流器。这些设备自己跑自己的，但总得有人盯着吧？上位机就是干这个的。它把每台风机的数据收上来，展示在屏幕上，让运维人员知道哪台风机在偷懒、哪台要检修。
我见过不少刚入行的工程师，觉得上位机就是个“大号显示器”。其实远不止这些。它还要做数据存储、报警处理、历史趋势分析，甚至远程控制。嗯，这里要注意——远程控制功能一定要做权限管理，我吃过这个亏。
核心功能清单：
- 实时数据采集（风速、功率、温度、振动等）
- 状态监控与报警
- 历史数据存储与查询
- 报表生成与导出
- 远程启停控制（带权限）
- 与电网调度系统通信
1.2 业务需求调研
做需求调研，我最怕听到“你们看着做就行”。这话听着省事，实际上最坑人。
我建议分三步走：
- 跟运维人员聊——他们天天跟设备打交道，最清楚痛点。比如“每次查历史数据要翻半天”，这就是需求。
- 看现场环境——机房有没有空调？网络稳不稳定？我曾经遇到一个项目，现场网络延迟高达500ms，结果按常规方案做，数据根本刷不出来。
- 确认接口协议——风机厂家用的啥协议？Modbus TCP？IEC 61850？OPC UA？这个不搞清楚，后面全白干。
个人经验：需求调研时，一定要让客户签字确认。我遇到过口头说“就这样”，做完又说“不对”的情况。白纸黑字，对大家都好。
1.3 技术选型与架构设计
技术选型这块，我踩过的坑最多。先看一张架构图，这是我个人比较推荐的风电场监控系统分层架构：
架构清楚了，咱们再聊技术选型。我个人习惯用这个组合：
| 层级 | 推荐技术 | 说明 |
|---|---|---|
| 数据采集 | Kepware / 自研采集器 | Kepware支持协议多，但贵。小项目我建议自研，用C#或Go写个采集器，灵活 |
| 实时数据库 | InfluxDB + Redis | InfluxDB存时序数据，Redis做缓存。注意InfluxDB的保留策略要提前设好 |
| 关系数据库 | MySQL 8.0 / PostgreSQL | 存配置信息、用户信息、报警记录。我习惯用PostgreSQL，对JSON支持更好 |
| 消息队列 | RabbitMQ / EMQX | 数据量不大用RabbitMQ，量大用EMQX。我有个项目一天200万条数据，EMQX扛得住 |
| 前端框架 | Vue3 + ECharts | Vue3响应式好，ECharts画趋势图、饼图、柱状图都方便 |
| 大屏展示 | Grafana | 开箱即用，对接InfluxDB很方便。运维人员看了都说好 |
避坑指南：我曾经在一个项目里选了MongoDB存时序数据，结果查询速度慢得离谱。后来换成InfluxDB，同样的数据量，查询快了10倍。时序数据，还是得用专门的时序数据库。
1.4 架构设计要点
架构设计这块，我总结几个关键点：
- 高可用——监控系统不能断。我建议数据库做主从复制，采集器做双机热备。你想想看，风电场半夜出故障，监控系统挂了，运维人员都不知道，那多危险。
- 可扩展——风电场可能扩建，新风机要能无缝接入。所以接口设计要规范，别搞成硬编码。
- 安全性——上位机跟风机PLC通信，万一被攻击，后果不堪设想。所以网络要隔离，防火墙要配好，远程控制要双重认证。
嗯，说到安全性，我多啰嗦一句。有个项目，客户要求手机APP能远程启停风机。我坚持加了短信验证码+人脸识别双重认证。客户嫌麻烦，后来出了个事故——运维人员手机丢了，被人远程停了风机，损失几十万。从那以后，客户再也不嫌我啰嗦了。
1.5 小结
这一章咱们聊了项目背景、需求调研、技术选型和架构设计。说白了，就是搞清楚“要做什么”和“用什么做”。
我个人觉得，需求调研比技术选型更重要。技术选型错了可以换，需求搞错了，整个项目都得重来。所以，多花时间跟客户聊，多去现场看看，比闷头写代码强得多。
下一章咱们聊环境搭建和基础组件部署，到时候我会分享一些具体的配置经验。