2. Experion系统架构与数据源解析

在把 Experion 的生产数据接入运营平台之前，必须先回答一个基础问题：数据到底“住在哪里”，以及用什么方式把它取出来。Experion PKS 并不是一个单一数据库，而是一套由控制层、服务器层、历史层和接口层共同组成的分布式系统。不同数据源的物理位置、刷新频率、访问协议和语义含义都不一样，如果定位错误，后续的集成工作会反复返工。本节按“数据源—承载组件—访问方式”三条线索，把核心数据源逐一拆开。

一、控制层：C300 控制器与过程数据的第一现场

C300 是 Experion 的过程控制器，运行在控制网络上，直接执行控制策略并持有实时过程值（PV）、设定值（SP）、输出值（OP）以及控制器状态。它是所有实时数据的源头，但运营平台通常不直接与 C300 通信，而是通过 Experion 服务器间接获取。原因在于 C300 面向确定性控制，其通信资源应优先保障控制回路，而不是承载大量外部查询。

在 C300 内部，数据以“块”的形式组织，例如 PID 块、AI/AO 块、逻辑块。每个块有唯一标识，典型形式为 控制器名.块名.参数名，例如 C300_01.FIC101.PV。这个命名规则是后续所有数据映射的基础。需要特别注意的是，C300 中的 PV 是工程单位值，而 OPC 侧可能同时暴露原始值和工程值，集成时必须明确取哪一层，否则会出现量纲错误。

二、服务器层：Experion Server 作为数据汇聚点

Experion Server 是控制层与上层应用之间的枢纽。它维护实时数据库（RTDB），把 C300 的过程值、报警、事件、趋势等统一管理，并对外提供多种接口。运营平台最常接触的就是这一层。服务器上的关键数据对象包括：实时点（Point）、报警（Alarm）、事件（Event）、历史采集配置（History Collection）以及批次相关对象。

实时点的属性通常包含 PV、SP、OP、模式（Mode）、状态（Status）等。以 FIC101 为例，其 PV 可能为 125.4 m³/h，SP 为 130.0 m³/h，模式为 CAS。这些属性在 OPC 地址空间中会以不同 Item 暴露，集成时需要按业务需求选择，而不是整点全量抓取。

三、ACE：把外部数据“写进”控制系统的通道

ACE（Application Control Environment）常被误解为只做控制，其实它也是数据集成的重要入口。ACE 允许用 C 语言或脚本编写自定义算法，并通过其接口与外部系统交换数据。典型场景是：运营平台需要把优化设定值下发给 C300，或把外部计算结果写回控制器。此时数据流方向与读取相反，属于“写入”路径。

ACE 的访问通常通过其函数库完成，例如读取输入、写输出、访问点参数。由于 ACE 运行在控制环境内，写入操作必须谨慎，建议先在测试控制器上验证，并设置合理的量程和速率限制，避免对生产造成扰动。

四、OPC UA 与 OPC DA：两种协议，两种适用场景

OPC 是运营平台访问 Experion 数据最常用的方式。Experion 同时支持 OPC DA 和 OPC UA，两者定位不同。OPC DA 基于 COM/DCOM，历史悠久，适合局域网内 Windows 平台之间的快速集成，配置简单但跨平台能力弱，且 DCOM 配置容易出问题。OPC UA 则面向现代集成，支持跨平台、加密和更丰富的信息模型，适合与 MES、云平台或非 Windows 系统对接。

在地址空间上，OPC DA 的 Item ID 通常形如 FIC101.PV 或带服务器前缀；OPC UA 则使用命名空间和节点 ID，例如 ns=2;s=FIC101.PV。集成前应先用 OPC 客户端工具浏览地址空间，确认节点存在、数据类型和访问权限，再写入配置。下面这张图展示了从 C300 到运营平台的完整数据源与访问路径关系。

五、历史库：Uniformance 与趋势数据的访问

Experion 的历史数据通常由 Uniformance 历史库承载，存储过程值、报警、事件和批次相关记录。历史库的访问方式与实时数据不同，它更强调时间范围查询和聚合。常见方式包括 ODBC 查询、Uniformance API 以及通过 OPC HDA（历史数据访问）读取。集成时最容易出错的是时间戳：历史库通常以 UTC 存储，而运营平台可能按本地时间展示，必须统一时区约定，否则趋势曲线会整体偏移。

另一个关键参数是采样周期。历史采集可以按固定周期（如 1 秒、5 秒）或按变化压缩（如死区 0.5%）。如果运营平台需要做能耗计算，应确认历史点的采集周期与计算窗口匹配，否则积分结果会有偏差。示例：某流量点每 5 秒采集一次，若按 1 分钟窗口做平均，应取 12 个样本；若实际只有 8 个样本，说明存在采集中断，需要检查历史采集状态。

六、报警与事件：语义比数值更重要

报警和事件是运营平台中价值密度最高的数据之一，但它们不是简单的数值。一条报警通常包含：报警点、报警类型（HI、LO、DEV、BADPV）、优先级、发生时间、确认时间、确认人和状态。事件则记录操作、模式切换、系统消息等。访问报警数据时，OPC UA 的报警与条件（Alarms & Conditions）模型比 OPC DA 更完整，支持订阅和状态机语义。

集成时建议按“报警生命周期”建模：发生（Active）、确认（Ack）、恢复（Clear）。运营平台如果只抓取当前活动报警，会丢失历史确认记录，无法做响应时间分析。因此应同时采集报警事件流，并保留报警 ID 作为关联键。

七、批次数据：按批次 ID 而非时间切片

批次数据来自批次执行环境，记录每个批次的产品、配方、阶段、步骤和参数。它与连续过程数据的最大区别是“有边界”：一个批次有开始和结束，内部有阶段划分。访问批次数据通常通过批次历史接口或数据库表，按批次 ID 查询。如果运营平台按时间范围去截取，可能把两个批次的数据混在一起，导致收率计算错误。

实际集成中，建议先建立数据源清单，明确每个数据源的承载组件、访问协议、刷新频率、时间基准和关键标识。下面给出一个可直接参考的示例清单结构，字段可根据项目调整。

把上述数据源定位清楚后，后续的集成工作就有了明确的边界：哪些数据从 OPC UA 订阅，哪些从历史库批量抽取，哪些需要经 ACE 回写。数据源解析不是一次性任务，当控制器增加、批次配方变更或历史采集配置调整时，都需要同步更新这份映射关系。