3. 平台架构与部署模式
在设备状态监测与运维项目中，平台架构决定了数据从哪里来、在哪里处理、以什么形式被消费，而部署模式则决定了系统的边界、成本结构与运维责任。理解 AVEVA 平台的整体架构与部署选项，是后续配置数据接入、建立分析模型和设计运维看板的前提。
一、AVEVA 平台的整体分层架构
AVEVA 的设备状态监测与运维能力并非单一软件，而是由多个层次协同构成的平台体系。从下到上可以划分为四个逻辑层：
- 数据接入层：负责从现场设备、PLC、DCS、SCADA、 historians 以及第三方系统中采集数据。典型组件包括 AVEVA Edge、AVEVA Historian、OPC UA/DA 接口、MQTT 网关等。这一层解决“数据能不能进来”的问题。
- 数据存储与建模层：负责时序数据、事件数据、资产元数据的统一存储与语义建模。AVEVA Historian 存储高频时序数据，AVEVA PI System（在部分部署中）承担企业级时序库角色，而资产模型则通过 AVEVA Model 或 Asset Framework 建立设备层级、测点映射与属性关系。
- 分析与应用层：包含状态监测规则引擎、异常检测算法、预测性维护模型、报警管理、工单触发等。AVEVA Predictive Analytics、AVEVA Insight 以及基于 AVEVA 平台的定制应用均运行在这一层。
- 展示与集成层：面向运维人员、工程师和管理者的可视化看板、移动端应用、报表系统，以及通过 REST API、WebSocket 与 ERP/EAM 系统的集成接口。
这四层之间通过标准协议和统一命名空间衔接，使得“一个测点”从现场到看板保持一致的语义标识，避免因命名混乱导致的分析偏差。
二、核心组件构成与职责
在具体部署时，需要明确各组件的职责边界。以下是一套典型的 AVEVA 状态监测平台组件清单：
| 组件 | 主要职责 | 典型部署位置 |
|---|---|---|
| AVEVA Edge / 网关 | 协议转换、边缘预处理、断线缓存 | 现场机柜或边缘服务器 |
| AVEVA Historian | 高频时序数据存储、压缩、查询 | 本地数据中心或云虚拟机 |
| Asset Framework / Model | 设备层级建模、测点语义映射 | 与 Historian 同域部署 |
| AVEVA Predictive Analytics | 异常检测、剩余寿命预测、模型训练 | 分析服务器或云容器 |
| AVEVA Insight / 看板 | 可视化展示、移动访问、报警推送 | 云端 SaaS 或本地 Web 服务器 |
| 集成接口 | 与 ERP/EAM 交换工单、备件、资产数据 | 按目标系统位置决定 |
三、本地部署与云部署选项
AVEVA 平台支持三种主流部署模式，选择哪种取决于数据敏感性、网络条件、运维能力和成本预算。
1. 纯本地部署（On-Premises）：所有组件安装在工厂或企业自建数据中心。数据不出厂区，适合对数据主权要求高、网络隔离严格或现场带宽受限的场景。缺点是前期硬件投入大，需要自有 IT 团队维护服务器、数据库和备份。
2. 云部署（Cloud / SaaS）：平台组件运行在 AVEVA 云或公有云（如 Azure、AWS）上，现场仅保留边缘网关。优势是弹性扩展、按订阅付费、免去基础设施维护。适合多站点集中监测、远程运维团队或缺乏本地 IT 资源的企业。需要注意的是，云部署对现场到云端的网络稳定性有要求，且需评估数据出境合规性。
3. 混合部署（Hybrid）：这是工业场景中最常见的模式。高频时序数据和实时报警留在本地 Historian，确保低延迟和断网可用；分析模型、长期存储和跨站点看板放在云端。边缘网关负责本地缓存与按需上传，兼顾实时性与全局分析能力。
四、选型考量与决策要点
在实际项目中，部署模式的选择不是非此即彼，而是围绕以下几个维度做权衡：
- 数据敏感性与合规要求：涉及工艺配方、产能数据或受监管行业时，优先考虑本地或混合部署，核心数据留在厂内。
- 站点数量与分布：单站点且网络稳定可考虑本地；多站点、跨地域则云或混合更利于集中管理。
- 实时性要求：毫秒级联锁或实时控制必须本地处理；分钟级状态监测和日报表可接受云端延迟。
- IT 运维能力：没有专职 IT 团队时，SaaS 模式可显著降低运维负担；有成熟数据中心则可发挥本地部署的自主可控优势。
- 成本结构：本地部署是资本支出（CAPEX）为主，云部署是运营支出（OPEX）为主。需按 3～5 年周期做总拥有成本对比，而不是只看首年投入。
- 扩展性：未来若计划接入更多设备或增加 AI 分析负载，云和混合模式在弹性扩展上更有优势。
五、部署前的检查清单
无论选择哪种模式，部署前建议逐项确认以下内容，避免上线后返工：
- 现场设备协议清单是否完整（OPC UA、Modbus、Profinet 等），网关是否支持对应驱动。
- 测点命名规范是否统一，是否已规划资产层级结构（厂区→装置→设备→部件→测点）。
- 网络带宽与延迟是否满足所选部署模式的要求，是否已开通必要的防火墙端口。
- Historian 的存储容量与压缩策略是否按测点数量和采样频率估算。
- 用户权限与角色是否划分清楚（管理员、工程师、运维人员、只读用户）。
- 备份与灾难恢复方案是否覆盖配置数据、模型和时序数据。
架构与部署模式确定后，后续的数据接入、模型配置和看板设计才有稳定的基础。建议在项目初期就用一张架构图明确各组件的位置和数据流向，并让 IT、OT 和运维团队共同评审，确保平台既能满足当前监测需求，也具备向预测性维护演进的扩展空间。