2. 系统总体架构：分层架构设计

好，咱们直接进入正题。风电Agent系统，说白了就是一个能自己思考、自己动手的智能体。它要感知风场状态，做出决策，然后执行动作。这三件事，天然就适合分成三层来做。

我个人习惯把架构画成三明治——感知层在最底下，决策层在中间，执行层在最上面。为什么这么分？你想想看，每一层的职责和变化频率都不一样。感知层天天跟硬件打交道，决策层跑算法模型，执行层要跟外部系统对接。混在一起，改一个地方就得动全身，那可就麻烦了。

2.1 感知层：系统的眼睛和耳朵

感知层负责采集数据。包括风速、风向、温度、振动、电压、电流……所有你能想到的传感器数据，都从这里进来。

我记得有一次在项目现场，风机塔筒的振动传感器突然报错。排查了半天，发现是感知层的采集程序把数据格式搞错了——浮点数当整数解析，导致后续所有分析都跑偏。嗯，这里要注意：感知层不仅要采数据，还要做数据清洗和格式统一。

感知层的核心职责：

• 多源数据接入：SCADA系统、CMS系统、气象站、雷达成像……能接的都接进来
• 数据预处理：去噪、插值、归一化、时间对齐
• 协议转换：Modbus、OPC UA、MQTT……统一转成内部消息格式
• 心跳检测：每个传感器节点必须定期上报心跳，超过3次没收到就告警

2.2 决策层：系统的大脑

决策层是整系统的核心。它拿到感知层的数据，进行分析、预测、推理，然后生成控制指令。

说白了，决策层就是一堆模型和算法的集合。有预测风速的时序模型，有诊断故障的分类模型，有优化发电量的强化学习模型……这些模型跑在GPU集群上，实时输出结果。

我建议决策层采用微服务架构。每个模型独立部署，独立扩缩容。为什么？因为不同模型的计算量差异太大了。风速预测模型可能几毫秒就出结果，而故障诊断模型可能要跑几秒钟。混在一起，慢的会拖死快的。

决策层的核心职责：

• 状态评估：当前风场运行是否正常？有没有异常趋势？
• 预测分析：未来15分钟风速变化？未来24小时发电量？
• 策略生成：变桨角度怎么调？偏航系统要不要动作？
• 指令下发：把决策结果打包成标准指令，传给执行层

2.3 执行层：系统的手和脚

执行层负责把决策层的指令变成实际动作。控制变桨系统、偏航系统、变流器、制动系统……这些都是执行层的活。

执行层跟物理世界直接打交道，所以对实时性和可靠性要求最高。我习惯在执行层用PLC或者边缘计算网关，不依赖云端。万一网络断了，执行层还能按本地策略继续运行。

执行层的核心职责：

• 指令解析：把决策层的JSON指令转成PLC能识别的控制信号
• 动作执行：控制电机、液压阀、继电器等执行机构
• 状态反馈：执行结果要回传给决策层，形成闭环
• 安全保护：超速保护、过载保护、急停逻辑——这些必须硬件实现

2.4 层间交互：数据流与控制流

三层之间怎么通信？我画了一张图，你看一眼就明白了。

这张图展示了三层之间的数据流和控制流。感知层向上传数据，决策层向下发指令，执行层向上反馈结果。箭头方向不能搞反，否则系统就乱套了。

2.5 架构设计原则

聊完分层，咱们说说设计原则。我总结了三句话：高可用、低延迟、可扩展。

2.6 避坑指南

最后，分享几个我踩过的坑：

• 不要过度设计：一开始就搞微服务、容器化、服务网格……结果团队根本维护不过来。先做单体，等业务复杂了再拆分。
• 日志要分层：感知层、决策层、执行层的日志分开存。排查问题时，直接看对应层的日志，不用翻半天。
• 监控要全覆盖：每层都要有健康检查接口。我曾经遇到过决策层CPU跑满，但服务还在，健康检查没报错，结果整个系统卡死。后来加了CPU使用率监控，才提前发现。
• 版本管理要严格：模型版本、代码版本、配置版本，三者必须对齐。有一次模型升级了，但配置没更新，导致决策层输出全是NaN。嗯，从那以后我强制要求版本号必须一致。