3. 多站点网络拓扑设计
多站点监控平台的核心难点不在单站点内部，而在于站点之间的数据通道。AVEVA 监控平台（如 System Platform + Historian + OMI）在跨站点部署时，通常采用“中心—分支”或“多中心对等”两种连接模型。选择哪种模型，取决于站点数量、数据实时性要求、运维权限边界以及现有广域网条件。
站点间网络连接模型
常见的三种模型如下：
- 星型汇聚模型：所有分支站点的 Historian 或数据采集节点通过 VPN/专线汇聚到中心站点，中心统一存储与展示。优点是策略集中、隔离简单；缺点是中心链路带宽压力大，单点故障影响面广。
- 环形/部分网状模型：站点之间建立两条以上路径，关键站点互为备份。适合站点数量少（3～6 个）、实时性要求高的场景，但路由与防火墙策略复杂度显著上升。
- 分层汇聚模型：按区域先汇聚到区域中心，再由区域中心上联总中心。适合站点数量多、地理分散的大型集团，能有效控制单条链路的并发连接数。
无论采用哪种模型，站点间通信应遵循“最小必要通道”原则：只开放监控平台实际使用的端口与协议，例如 OPC UA（4840/TCP）、Historian 复制（视版本而定）、SQL 复制端口、时间同步（123/UDP）以及管理通道（如 3389 仅限跳板机）。
带宽评估：从测点数量到实际吞吐
带宽评估不能只凭“站点有多少个测点”粗略估算，而应区分三类流量：
- 实时数据流：OPC UA 订阅或 Historian 复制产生的持续流量。假设某站点有 5000 个模拟量测点，采集周期 1s，每个值压缩后平均 20 字节，则原始速率约为 5000×20×8 = 800 kbps。若采用变化上报（死区 0.5%），实际可能降至 150～300 kbps。
- 历史回填流：链路中断恢复后，边缘 Historian 向中心回补数据。回填是突发流量，可能瞬间占满链路。例如 72 小时缓存、5000 测点、平均 30 秒存储一次，回填数据量约为 5000×8640×20 字节 ≈ 864 MB，若要求在 30 分钟内完成，则需约 3.8 Mbps 持续带宽。
- 管理与发布流：远程桌面、Web 发布、报警推送、备份等。这部分容易被忽略，但多个管理员同时操作时可能占用数 Mbps。
工程上建议按“实时流 + 回填流峰值 + 管理流”三者叠加后，再保留 30% 余量作为链路选型依据。若链路为共享宽带，还需考虑其他业务占用。
延迟与抖动的影响
监控平台对延迟的敏感度取决于数据用途。用于实时画面刷新和报警联动的数据，端到端延迟建议控制在 200 ms 以内；用于趋势分析和报表的历史数据，延迟可放宽到秒级甚至分钟级。抖动比平均延迟更危险：当抖动超过采集周期的 50% 时，OPC UA 订阅可能出现队列堆积，Historian 存储时间戳错位，报警顺序判断也会失真。
判断链路是否满足要求，可在边缘节点与中心节点之间持续执行类似下面的探测，观察延迟与抖动分布：
ping -n 100 10.20.0.10
# 关注平均延迟、最大延迟与丢包率
# 若平均 35ms、最大 180ms、丢包 0.2%，抖动约 145ms，已接近临界
# 使用 OPC UA 客户端测试订阅回调间隔
# 期望回调间隔 1000ms，若实际在 800~1600ms 波动，说明抖动偏大若抖动持续偏大，应优先排查：链路是否与备份、视频等突发业务共享；QoS 是否对监控流量做了优先级标记；边缘 Historian 的缓存队列是否过小导致频繁阻塞。
冗余链路与隔离区部署策略
冗余链路的目标不是“永远不断”，而是“中断后可预期地恢复”。建议采用“主用专线/VPN + 备用 4G/5G 或第二条 VPN”的组合，并在边缘节点配置双网卡或双路由。切换策略应明确：主链路连续丢包超过 5 个探测周期（例如 15 秒）后切换，主链路恢复稳定 60 秒后切回，避免频繁震荡。
隔离区（DMZ）部署的核心是把“站点内网”与“站点间通道”解耦。推荐在中心与区域汇聚点各部署一对 OPC UA 网关或反向代理：内网侧只允许网关访问 Historian 和 OPC UA Server，外网侧只暴露网关的单一端口。这样即使站点间链路被扫描或攻击，也无法直接触达 PLC 和 Historian 主库。
综合来看，多站点网络拓扑设计应围绕“连接模型选型 → 带宽分层估算 → 延迟抖动验证 → 冗余切换策略 → 隔离区收敛”这条主线推进。每一步都需要有可观察的指标和可回退的配置，而不是一次性画完拓扑图就结束。