2. AVEVA系统架构与核心组件
AVEVA生产监控与工业可视化系统并不是单一软件，而是一套由多个组件协同工作的分布式平台。理解各组件之间的分工与通信关系，是后续建模、组态、历史存储和远程发布的基础。本节围绕System Platform、InTouch、Historian、AVEVA Insight等核心组件，梳理它们的职责边界、分布式部署方式、客户端/服务器通信模型以及许可与部署模式。
一、核心组件的职责分工
AVEVA System Platform是整个架构的“骨架与中枢”。它提供统一的命名空间（Galaxy）、对象模型、模板库和部署引擎。在System Platform中，设备、产线、工艺段被抽象为自动化对象（AutomationObject），通过模板实例化后形成应用对象（ApplicationObject），再由部署引擎分发到各台运行时节点。它解决的是“模型在哪里定义、实例在哪里运行、数据如何被统一命名”的问题。
InTouch是面向操作员的可视化与交互组件。它负责画面显示、报警呈现、趋势查看和操作指令下发。在System Platform体系中，InTouch View作为可视化客户端运行，画面中绑定的变量来自平台对象，而不是孤立的内存标记名。这样，同一套对象模型可以同时驱动画面、历史和安全策略。
Historian（历史数据库）负责高密度时序数据的采集、压缩与长期存储。它从运行时节点订阅过程值，按时间戳写入历史库，并提供趋势查询、统计分析和报表接口。Historian通常独立部署在专用服务器上，以保证磁盘I/O和查询性能。
AVEVA Insight是面向云端或远程访问的分析与可视化服务。它通过边缘网关或数据发布通道，将关键过程数据上传到云端，供工程师和管理人员在浏览器或移动端查看KPI、趋势和报警摘要。Insight不替代本地SCADA，而是对本地系统的补充，强调远程可见性和轻量分析。
二、分布式架构与通信模型
AVEVA System Platform采用典型的分布式客户端/服务器模型，但并非单一服务器，而是由多个角色节点组成。核心角色包括：Galaxy Repository（全局命名空间与对象定义库）、App Engine（对象逻辑运行时）、InTouch View（可视化客户端）、Historian Server（历史数据服务）以及License Server（许可管理）。这些角色可以部署在同一台服务器上，也可以分散到多台物理或虚拟服务器。
通信模型上，各组件之间主要依赖两类通道。第一类是平台内部通信：App Engine与Galaxy之间通过平台专有协议同步对象定义和部署状态；InTouch View通过平台数据访问接口订阅App Engine中的属性值。第二类是数据采集与发布通道：Historian采集器通过OPC UA或平台原生接口从App Engine订阅过程值，再写入Historian Server；Insight则通过边缘发布通道从Historian或App Engine提取数据上传云端。
在实际项目中，一个常见的部署拓扑是：一台服务器承担Galaxy和License Server角色，一台服务器运行App Engine和InTouch View，另一台专用服务器运行Historian Server。现场PLC通过OPC UA驱动接入App Engine。操作员站通过局域网访问InTouch View。工程师站通过System Platform IDE进行远程建模和部署。这种分离式部署的好处是：历史查询不会影响实时控制逻辑，画面刷新不会挤占历史写入带宽。
三、许可与部署模式
AVEVA的许可模式通常基于组件和规模两个维度。组件维度决定哪些功能可用，例如System Platform许可、InTouch View许可、Historian许可、Insight许可。规模维度决定可用的对象数量、客户端数量、历史标签数量或连接设备数量。许可通常由License Server统一管理，各运行时节点在启动时向License Server请求授权。
部署模式上，常见有三种：单机部署、分布式部署和混合云部署。单机部署将Galaxy、App Engine、InTouch View和Historian放在同一台机器上，适合小型项目或演示环境。分布式部署将各角色拆分到不同服务器，适合中大型项目，强调性能和可用性。混合云部署在分布式基础上增加Insight云端发布，适合需要远程监控和多站点集中管理的场景。
四、组件间的数据流与依赖关系
从数据流角度看，整个过程可以概括为：现场设备产生原始信号，驱动层将其转换为标准协议数据，App Engine接收并执行对象逻辑，InTouch View从App Engine读取属性值用于画面显示，Historian采集器从App Engine订阅过程值并写入历史库，Insight从Historian或App Engine提取数据发布到云端。反向操作指令则从InTouch View下发到App Engine，再由App Engine写入现场设备。
依赖关系上，Galaxy是所有组件的配置源头，没有Galaxy就无法部署App Engine和InTouch View。License Server是运行前提，没有有效许可，运行时节点无法启动。Historian依赖App Engine提供数据源，Insight依赖Historian或App Engine提供数据出口。因此，在排障时，应按照“Galaxy→License→App Engine→InTouch View→Historian→Insight”的顺序逐层检查。
五、部署检查要点
在完成架构设计后，部署前应确认以下要点：各服务器之间的网络端口是否开放，尤其是平台内部通信端口和OPC UA端口；License Server是否可被所有运行时节点访问；Galaxy是否已完成备份；Historian的磁盘空间和写入性能是否满足标签量和采样频率要求；Insight的边缘发布通道是否已配置正确的证书和网络出口。
以一个中等规模项目为例：假设有3条产线，每条产线约2000个过程标签，操作员站6台，历史存储要求保留12个月。此时建议部署一台Galaxy/License服务器、两台App Engine服务器（按产线分组）、一台Historian服务器、一台Insight网关。InTouch View可部署在操作员站本地，也可通过终端服务集中发布。该配置下，单台App Engine承载约3000个对象，Historian写入约6000点/秒，属于可接受范围。