3. 平台架构与数据流
AVEVA能源与生产绩效监控平台（Energy & Production Performance Monitoring）并不是一个单一软件，而是一套按职责分层、通过标准接口串联的体系。理解它的关键，不是记住产品名称，而是看清“数据从现场设备出发，经过采集、计算，最终变成可决策的画面”这条链路。本节按分层架构、各层职责、典型数据流向三个角度展开，并给出可对照的配置示例。
一、四层架构：从现场到决策
平台在逻辑上分为四层，自下而上依次是：数据采集层、数据存储与计算层、可视化层、应用与决策层。层与层之间通过明确定义的接口通信，下层向上层提供数据服务，上层不直接访问现场设备。这种“分层解耦”是平台可扩展、可维护的根本原因。
数据采集层负责与现场控制系统对接，典型数据源包括DCS、PLC、SCADA、智能电表、流量计、振动传感器以及 historians（历史数据库）。采集方式主要有三类：OPC DA/UA 订阅、Modbus TCP 轮询、以及通过 MQTT/API 接入的物联网网关。采集层的关键参数是扫描周期与时间戳精度——例如电力参数常用 1 秒扫描，温度压力常用 5～10 秒，而电能累积量则依赖设备侧的时间戳对齐。
数据存储与计算层承担两件事：一是把原始数据按时间序列存入历史库（如 AVEVA Historian），二是通过计算引擎生成绩效指标。计算层通常包含实时计算与批量计算两条路径：实时计算处理秒级/分钟级的KPI（如瞬时功率、单位产品能耗），批量计算处理班次、日、月的汇总与对标。计算逻辑以“标签+表达式”的方式定义，例如：
-- 示例：单位产品电耗（kWh/t）
KPI_UnitPower = Integral(Power_kW, 'shift') / Integral(Output_t, 'shift')
-- 示例：设备综合效率 OEE
OEE = Availability * Performance * Quality
Availability = RunTime / PlannedTime
Performance = IdealCycleTime * TotalCount / RunTime
Quality = GoodCount / TotalCount可视化层把计算结果转化为画面、趋势、报表和报警。它不直接读取现场设备，而是订阅计算层发布的KPI与原始标签。可视化层的关键设计是刷新频率与数据粒度的匹配：实时画面刷新 1～5 秒，趋势图按分钟聚合，报表按班次/日聚合。若把报表也按秒刷新，会造成不必要的查询压力。
应用与决策层面向业务用户，提供能效对标、碳排放核算、生产绩效看板、异常追溯等场景。它消费可视化层暴露的指标服务，通常以 Web 门户或移动端呈现。
二、典型数据流向：一次能耗KPI的完整旅程
下面以“某产线单位产品电耗”为例，说明数据如何从现场走到看板。假设产线有一台主电机，功率由智能电表通过 Modbus TCP 采集，产量由 PLC 计数器提供。
- 采集：采集服务以 1 秒周期读取电表寄存器，得到有功功率
Power_kW；同时以 1 秒周期读取 PLC 的产量累积值Output_t。两个标签都带设备时间戳写入历史库。 - 实时计算：计算引擎订阅这两个标签，按班次窗口做积分。班次开始时窗口重置，班次结束时输出
KPI_UnitPower。若班次内产量为 0，则表达式返回无效值，避免除零。 - 存储：计算结果以 1 分钟粒度写入历史库，同时保留班次汇总值。原始秒级数据按策略保留 90 天，分钟级保留 2 年。
- 可视化：实时画面显示当前班次累计电耗与瞬时功率；趋势图按分钟展示电耗曲线；报表按班次输出对比表。
- 决策：当班次电耗超过基准值 5% 时，报警触发，能效看板高亮该产线，并关联到具体设备与时间窗口。
这条链路中，任何一个环节的参数设置都会影响最终结果。例如采集周期从 1 秒改为 10 秒，积分误差会增大；计算窗口与班次定义不一致，会导致 KPI 无法对齐；可视化刷新频率高于计算频率，会看到重复值。因此，配置时必须让采集周期 ≤ 计算周期 ≤ 可视化刷新周期，并保持时间基准一致。
三、配置示例：一个可对照的参数表
下表给出某水泥厂生料磨系统的实际配置参考（示例参数，用于说明配置方法，非实测结果）。
| 对象 | 标签/表达式 | 采集方式 | 周期 | 存储粒度 |
|---|---|---|---|---|
| 主电机功率 | Power_kW | Modbus TCP | 1 s | 1 s / 1 min |
| 生料产量 | Output_t | OPC UA 订阅 | 1 s | 1 s / 1 min |
| 单位电耗 | Integral(Power_kW,'shift') / Integral(Output_t,'shift') | 计算引擎 | 1 min | 1 min / 班次 |
| 班次电耗基准 | Baseline_kWh_t | 手工录入/对标库 | 班次 | 班次 |
四、常见数据流异常与判断
在实际运行中，数据流异常往往表现为“画面不动”“趋势断线”“KPI 跳变”。可按以下顺序排查：
- 采集层：检查 OPC 连接状态与 Modbus 从站响应。若采集服务日志出现 timeout，先确认网络与设备端口，再检查扫描周期是否过短导致设备过载。
- 计算层：查看计算引擎的输入标签是否有值。若输入正常但输出为空，检查表达式中的窗口定义与除零保护。
- 可视化层：确认订阅的标签名与计算层发布名一致。若趋势图断线，检查历史库中该时间段是否有数据，以及查询时间范围是否超出保留策略。
- 时间基准：所有层必须使用同一时区与时间同步源。若采集层用设备本地时间、计算层用服务器时间，班次边界会错位，KPI 无法对齐。
理解分层架构与数据流向，最终是为了在配置和排障时有明确的“责任边界”：数据不对，先看采集；指标不对，先看计算；画面不对，先看可视化。每一层只解决自己的问题，平台才能稳定运行。