2. AVEVA监控平台典型架构剖析
要设计高可用架构，第一步不是堆叠冗余组件，而是把一套典型 AVEVA 监控平台拆开看清楚：它由哪些层组成、数据在层与层之间怎么流动、哪些组件一旦失效会直接导致画面黑屏或数据中断。本节以一套常见的三层部署形态为对象进行剖析——采集层、服务层、呈现层，并在此基础上识别高可用薄弱点。
一、系统组成：三层结构与关键组件
典型 AVEVA 监控平台（以 System Platform + InTouch / OMI 组合为例）可划分为三层：
- 采集层：现场 PLC、RTU、智能仪表通过工业协议接入。核心组件是 通信驱动（如 DAServer / OI Server / DI 驱动）与 设备集成对象（DI Object）。驱动负责协议解析与点位扫描，DI 对象负责把原始点位映射为平台可识别的属性。
- 服务层：由 Galaxy Repository（对象库）、App Engine（应用引擎）、Historian（历史库）、Alarm & Event 服务、License 服务 组成。App Engine 承载控制逻辑、脚本、报警计算；Historian 负责时序数据落盘；Galaxy 保存整个平台的工程对象模型。
- 呈现层：InTouch / OMI 可视化节点、Web 客户端、报警看板。呈现层不直接读 PLC，而是通过服务层获取实时值与历史趋势。
三层之间通过 平台内部通信（如 MX / OPC UA / 私有 RPC） 连接。理解这条链路，是判断“哪里断了会怎样”的前提。
二、数据流：从现场点位到操作员画面
一条典型的实时数据流如下：
- PLC 周期刷新寄存器，例如
DB1.DBD0每 100 ms 更新一次。 - 通信驱动按扫描周期（示例：250 ms）读取该点位，写入 DI 对象的属性
PV。 - App Engine 按部署周期（示例：500 ms）读取 DI 属性，执行脚本与报警判断，更新内部对象属性。
- InTouch / OMI 节点通过订阅方式获取属性值，刷新画面元素。
- Historian 按采集周期（示例：1 s 或变化存储）将值写入历史表。
这条链路中，每一跳都有独立的周期与缓冲。当某一跳变慢或中断，下游看到的是“值不更新”或“值跳变”，而不是立即报错——这正是高可用排查中最容易误判的地方。
三、关键组件的高可用薄弱点识别
把上述组件逐一对照“单点失效后果”，可以快速定位薄弱点：
| 组件 | 典型部署 | 失效后果 | 薄弱点等级 |
|---|---|---|---|
| Galaxy Repository | 单机 SQL + Galaxy | 无法部署、无法改工程、节点重启后拉不到对象 | 高 |
| App Engine | 单实例 | 逻辑停算、报警不产生、画面值冻结 | 高 |
| Historian | 单节点 | 趋势断档、历史数据丢失 | 中高 |
| 通信驱动 | 单驱动实例 | 该协议下所有点位中断 | 高 |
| License 服务 | 单机 | 节点无法启动或降级运行 | 中 |
| 呈现层节点 | 多台操作站 | 单台黑屏，其他站可用 | 低 |
从表中可见，采集层与服务层是薄弱点集中区，呈现层因天然多站而相对健壮。高可用设计的重点应放在 Galaxy、App Engine、Historian 与通信驱动的冗余与切换上。
四、薄弱点的判断依据与观察方法
识别薄弱点不能只看“是否单机”，还要看失效是否可被下游感知。例如：
- App Engine 主备切换时，若 InTouch 未配置重连，画面会短暂显示旧值而非断线提示，操作员可能误判现场状态。
- Historian 写入失败时，若未启用本地缓存，数据会直接丢失，事后无法补录。
- 通信驱动断线后，DI 对象质量戳（Quality）应变为
BAD，但若画面未绑定质量戳，操作员看到的仍是最后一次有效值。
判断薄弱点的核心问题不是“它会不会坏”，而是“它坏了以后，下游能不能知道、能不能继续、能不能恢复”。
五、典型架构与薄弱点可视化
下图把三层结构、数据流方向与薄弱点标注在同一张图上，便于对照排查。
图中红色边框标注的 Galaxy、App Engine、通信驱动是三个最需要优先做冗余设计的组件；Historian 以橙色标注，属于中高风险，建议至少配置本地缓存与写入重试。呈现层多站部署，单站失效影响有限，但需确保每台操作站都能独立重连服务层。