3. 系统架构与组件
Yokogawa 的过程历史数据库并不是一个单一软件，而是一套由多个组件协同工作的体系。理解这套体系的关键，是分清“数据从哪里来、经过谁、存到哪里、被谁读取”这四个环节。本节围绕 Exaquantum 与 Exaopc 两大核心，梳理历史数据库的组件构成、采集接口、客户端工具以及与 DCS/PLC 的连接方式。
一、Exaquantum 与 Exaopc 的分工
Exaquantum 是横河的过程信息管理系统（PIMS），定位是“面向全厂的历史数据平台”。它负责长期存储、聚合、计算和发布过程数据，典型能力包括历史趋势、批次分析、KPI 计算、报表与 Web 发布。Exaopc 则是 OPC 接口产品，定位是“数据接入与互操作层”，它把 DCS、PLC、第三方系统的实时数据以 OPC 标准暴露出来，供 Exaquantum 或其他客户端采集。
两者关系可以概括为：Exaopc 解决“连得上、读得到”，Exaquantum 解决“存得久、算得清、看得见”。在实际项目中，Exaopc 常作为 OPC Server 部署在靠近控制层的服务器上，Exaquantum 作为上层历史库部署在信息网侧，中间通过 OPC 或专用采集接口衔接。
二、核心组件构成
一套典型的历史数据库系统包含以下组件：
- 数据采集接口（Collector/Interface）：负责从 OPC Server、DCS 网关或 PLC 读取实时值，按扫描周期写入历史库。常见接口包括 OPC DA/UA 采集器、DCS 专用驱动接口。
- 历史存储引擎（Historian）：以时间序列方式存储测点值，支持压缩、死区（Deadband）、插值与长期归档。
- 组态与标签管理工具：定义测点（Tag）、工程单位、量程、采集周期、压缩方式等元数据。
- 计算与聚合引擎：执行平均值、累计量、批次统计、KPI 公式等运算。
- 客户端工具：趋势查看、报表、Web 门户、Excel 插件、API/SDK 等。
- OPC 接口层（Exaopc）：对外提供 OPC DA/UA/AE 服务，屏蔽底层 DCS/PLC 差异。
三、数据采集接口的工作方式
采集接口的核心参数是扫描周期与死区。扫描周期决定采集频率，例如 1 秒、5 秒或 10 秒；死区决定“变化多少才记录”，例如量程的 0.5%。两者共同影响数据精度与存储量。
以某温度测点为例：量程 0～200 ℃，死区设为 0.5%，即 1 ℃。若当前值为 120.0 ℃，只有当新值超过 121.0 ℃ 或低于 119.0 ℃ 时才触发记录。这样既保留有效变化，又避免噪声占满存储。采集器通常还支持“定时强制记录”，即使无变化也按周期落一个值，便于趋势连续性。
四、与 DCS/PLC 的连接方式
连接方式主要分三类：
- 通过 DCS 网关/OPC Server：DCS（如 CENTUM VP）通过其 OPC Server 或 Exaopc 暴露数据，Exaquantum 采集器以 OPC 客户端身份订阅。这是最常见、最规范的方式。
- 通过专用驱动接口：部分 DCS 提供专用历史接口或 API，采集器直接对接，减少中间层。
- 通过 PLC 通信：PLC 侧常用 OPC UA、Modbus TCP 或厂商协议，经 Exaopc 或第三方 OPC Server 统一后接入。
连接时需关注：网络分区（控制网与信息网之间通常有防火墙或 DMZ）、OPC 的 DCOM 配置（DA 场景）、UA 的证书与端口、以及采集服务器的冗余部署。
五、客户端工具与访问路径
历史数据最终要被人和系统使用。常见客户端包括：趋势客户端（查看实时与历史曲线）、Web 报表门户、Excel 插件（把历史数据拉入表格分析）、以及 API/SDK（供 MES、ERP 或自研系统调用）。访问路径通常是：客户端 → Exaquantum 服务 → 历史存储引擎 → 返回时间序列结果。
六、部署与排障要点
实际运行中，最常见的问题集中在三处：一是 OPC 连接失败（DCOM 权限、UA 证书、端口不通）；二是采集断数（采集服务停止、网络抖动、DCS 侧接口限流）；三是历史查询慢（标签过多、时间范围过大、磁盘 IO 不足）。排查顺序建议从“数据源是否可读”开始，逐层向上验证：先用 OPC 客户端测试能否读到实时值，再检查采集器日志是否写入，最后在趋势客户端确认历史曲线是否连续。