📚 课程目录第1章 AVEVA System Platform概述

1. AVEVA System Platform概述

AVEVA System Platform（简称 System Platform，早期常被称为 Wonderware System Platform）是面向工业自动化与工厂监控场景的可扩展监控与信息管理平台。它并不是一个单一软件，而是一套由多个协同组件构成的运行框架：底层负责数据采集与设备通信，中间层负责对象建模与逻辑运算，上层负责可视化呈现与历史数据服务。理解它的关键在于把“平台”看作一个整体——各个组件各司其职，又通过统一的命名空间和对象模型紧密耦合。

在工厂监控领域，System Platform 的典型定位是：把现场分散的 PLC、DCS、智能仪表、SCADA 数据统一接入，用面向对象的方式建立工厂模型，再以一致的画面和数据结构向操作员、工程师和管理层提供实时监控与历史追溯能力。它常用于水处理、电力、油气、制药、食品饮料等流程行业，也适用于离散制造中的设备状态监控与产线看板。

核心组件与职责

要真正用好 System Platform，必须先分清几个核心组件各自“管什么”。下面按从底层到上层的顺序说明。

Galaxy（银河/全局命名空间）：Galaxy 是整个平台的“根容器”，所有对象、模板、实例、安全模型、部署关系都注册在同一个 Galaxy 命名空间中。可以把它理解为一个集中式的对象数据库，工程师在 IDE 中创建的对象最终都归属于某个 Galaxy。一个 Galaxy 通常对应一个工厂或一个独立项目，多个 Galaxy 之间默认相互隔离。
Application Server（应用服务器，简称 App Server）：这是平台的运行时引擎，负责承载对象实例、执行脚本与逻辑、管理报警与历史、向客户端提供数据。App Server 通常以 Windows 服务方式运行，可部署为单机或冗余架构。它决定了“对象在哪里运行、数据由谁计算”。
IDE（Integrated Development Environment，集成开发环境）：工程师进行建模、组态、部署的工作台。在 IDE 中，可以创建模板（Template）、派生实例（Instance）、定义属性（Attribute）、编写脚本、配置报警与历史，并把对象部署到指定的 App Server。IDE 是“设计态”，App Server 是“运行态”，两者通过部署（Deploy）动作衔接。
ViewApp / InTouch View（可视化客户端）：面向操作员的画面运行环境。ViewApp 通过绑定 Galaxy 中的对象属性来显示实时值、趋势、报警和状态，操作员在画面上执行点击、设定值下发等操作。画面本身不直接访问 PLC，而是通过 App Server 的对象模型间接读写数据。
通信与数据接入组件：包括 DAServer（数据访问服务器）或 OI Server 等，负责与 PLC、Modbus、OPC UA/DA 等现场设备或协议通信，把原始数据映射为 Galaxy 对象可用的属性值。
Historian（历史数据库）：用于存储过程值、报警与事件的历史记录，支持趋势回放、报表与后续分析。它通常与 App Server 配合，按配置的采集周期和死区写入数据。

这些组件之间的关系可以用一张结构图来直观理解：Galaxy 是命名空间根，IDE 负责建模并部署到 App Server，App Server 通过通信组件连接现场设备，同时向 ViewApp 和 Historian 提供数据。

对象模型：平台真正的“骨架”

System Platform 与普通组态软件最大的区别，在于它采用面向对象的方式组织数据。工程师不是直接给某个 PLC 地址绑定画面，而是先定义“模板”，再由模板派生“实例”。例如，可以创建一个名为 PumpTemplate 的泵模板，其中包含 RunStatus、Fault、SpeedSP、Flow 等属性，并写好启动、停止、联锁脚本。之后在具体工位上派生 Pump_101、Pump_102 等实例，只需把各自的通信地址和参数填入，逻辑与画面自动继承。

这种做法的直接好处是：当现场有 30 台同型号泵时，只需维护一份模板逻辑；修改模板并重新部署后，所有实例同步更新。对于工厂监控而言，这意味着画面、报警、历史、脚本可以随对象一起复用，大幅降低重复劳动和人为不一致的风险。

典型应用场景

在实际工厂中，System Platform 常见的落地方式包括：

全厂集中监控：把多个车间、多个 PLC 站的数据汇总到统一 Galaxy，操作员在中控室通过 ViewApp 查看全厂流程画面、报警列表和关键趋势。
设备状态与OEE看板：利用对象属性统计设备运行、停机、故障时间，结合 Historian 数据生成班次产量与效率看板。
报警管理与追溯：在 App Server 中配置报警优先级、死区、延时，操作员确认后写入 Historian，便于事后分析误报与漏报。
批次与配方监控：在制药、食品行业，结合对象模型管理批次状态、配方参数与清洗流程，保证过程可追溯。
远程运维与多站点复制：通过模板化和 Galaxy 导出导入，把一套成熟的对象模型快速复制到新产线或新厂区。

一个最小示例：从模板到画面

假设要监控一台冷却水泵，可以按以下思路在 IDE 中完成建模（以下参数为教学示例，实际项目需按设备手册和工艺要求设定）：

模板：PumpTemplate
  属性：
    RunStatus   : Boolean   // true=运行
    Fault       : Boolean   // true=故障
    SpeedSP     : Real      // 设定转速，单位 rpm，示例范围 0~1450
    Flow        : Real      // 流量，单位 m³/h
  脚本：
    OnTrue(RunStatus) → 启动输出 = 1
    OnTrue(Fault)     → 报警 "Pump Fault" 优先级 500

实例：Pump_101
  继承 PumpTemplate
  绑定：
    RunStatus ← PLC1.Pump101.Run
    Fault     ← PLC1.Pump101.Fault
    Flow      ← PLC1.Pump101.Flow

部署到 App Server 后，ViewApp 画面只需绑定 Pump_101.Flow 和 Pump_101.RunStatus，即可显示实时流量与运行状态。若把 SpeedSP 设为 1200 rpm 并下发，操作员可在趋势中观察流量是否随之上升；若 Fault 变为 true，报警列表会出现对应条目，Historian 也会记录该时刻。判断建模是否成功，可以看三个信号：画面数值随现场变化、报警能正确触发并确认、历史趋势能回放对应时间段。

学习建议：先在一个 Galaxy 中只建一个模板和一个实例，跑通“建模—部署—画面绑定—报警—历史”这条最小链路，再扩展到多设备、多区域。这样比一开始就铺开全厂对象更容易定位问题。

整体架构的理解要点

把上面的组件和示例串起来，System Platform 的整体架构可以概括为三层：设计层（IDE + Galaxy）负责“定义工厂长什么样”；运行层（App Server + 通信组件）负责“让对象真正跑起来并读写现场数据”；呈现与归档层（ViewApp + Historian）负责“让人看到、让数据留下来”。三层之间通过 Galaxy 命名空间和对象属性解耦，现场设备更换或通信协议调整时，只要对象属性映射不变，画面和历史逻辑通常无需大改。这正是它在工厂监控中具备长期可维护性的根本原因。