2. PCS 7历史数据体系架构

在SIMATIC PCS 7中，历史数据并不是由单一组件集中存储的，而是由OS归档、Process Historian（PH）和Information Server（IS）三层协作完成。理解这三者的组件关系与数据流，是后续配置归档变量、规划存储容量、设计报表与Web访问的前提。很多工程问题——例如“为什么PH里查不到某个变量”“为什么IS报表数据延迟”——根源都在于没有理清这三层各自负责什么、数据从哪来、往哪去。

三层组件的职责边界

OS归档是历史数据的第一现场。每个OS服务器（或单站）在运行过程中，会把本机采集的过程值、报警、操作记录写入本地归档。OS归档的存储介质通常是OS服务器上的Archive目录，按时间分段（Segment）滚动保存。它的特点是：数据离现场最近、写入实时性最高，但容量受限于OS服务器本地磁盘，且只覆盖本OS所辖的自动化站范围。换句话说，OS归档是“局部、短期、实时”的历史层。

Process Historian是中央历史数据库。它通过PH-Ready或PH-Collector机制，从各OS服务器持续拉取归档数据，集中存储到PH服务器的SQL Server数据库中。PH的价值在于：跨OS、跨区域地汇聚全厂历史数据，存储周期长（可达数年），并对外提供统一的查询接口。PH不直接连接控制器，它只与OS服务器通信，因此OS归档是PH的数据源。

Information Server是面向用户的历史数据呈现层。它本身不存储过程数据，而是作为PH的“前端”，通过PH的查询接口读取数据，生成Web报表、趋势曲线和KPI看板。IS可以部署在独立服务器上，用户通过浏览器访问，无需安装WinCC客户端。因此IS解决的是“让非操作员角色也能看历史数据”的问题。

数据流与组件关系

下面这张图展示了从现场信号到最终用户报表的完整数据链路，以及三个核心组件之间的接口关系。

关键接口与配置要点

OS归档到PH的传输依赖PH-Ready组件。在OS服务器上安装PH-Ready后，需要指定PH服务器的名称，并选择哪些归档变量需要上传。这里有一个常见误区：并非OS归档中的所有变量都会自动进入PH，必须在OS侧显式配置“PH变量”或通过归档组态将变量标记为可上传。如果某个变量在PH中查不到，首先应检查它在OS侧是否被纳入了PH上传范围。

PH到IS的连接则通过PH查询服务实现。IS服务器上需要配置PH服务器的连接信息，并创建对应的数据源。IS的报表和趋势模板中引用的变量名，必须与PH中存储的变量名一致。如果变量名在PH侧被重命名或归档组被调整，IS侧的报表就会失效。因此在实际工程中，建议在项目初期就统一变量命名规范，并在PH和IS两侧保持一致。

典型数据流示例

假设某化工厂有一套PCS 7系统，包含2个OS服务器（OS-A、OS-B）和1台PH服务器、1台IS服务器。反应釜温度TT-101由OS-A采集，归档周期为1秒，压缩方式为“周期归档”。操作员在OS-A上看到的是本地归档的实时趋势。同时，OS-A通过PH-Ready将TT-101上传到PH。PH以1秒粒度存储该变量，保留周期设为3年。IS上配置了一张“反应釜温度日报表”，每天8:00自动从PH查询前一天的数据并生成PDF。用户通过浏览器访问IS，即可查看该报表。

在这个例子中，如果操作员发现OS-A上的趋势正常，但IS报表中TT-101的数据缺失，排查顺序应该是：先确认OS-A上TT-101是否被标记为PH上传变量；再确认PH中是否存在该变量的归档记录；最后检查IS报表模板中引用的变量名是否与PH一致。这个排查顺序正是由三层数据流的依赖关系决定的——上游不通，下游必然无数据。

组件部署的常见形态

在实际项目中，这三层组件的部署方式会根据系统规模变化。小型系统可能将OS归档和PH合并在同一台服务器上，甚至IS也共用一台机器；中大型系统则通常将PH和IS分别部署在独立服务器上，OS服务器保持独立。无论哪种形态，数据流的逻辑关系不变：OS归档是源，PH是汇聚点，IS是呈现端。理解这一点，就能在任意部署形态下正确配置和排障。

此外，PCS 7还提供了OS归档备份和PH备份机制。OS归档可以备份到网络路径或外部存储，PH数据库则可以通过SQL Server的备份策略进行保护。这些备份机制与数据流是并行的，不改变主数据链路，但它们是历史数据长期可用性的重要保障。

总结来说，OS归档、PH和IS构成了PCS 7历史数据的完整链条。OS归档解决“现场数据怎么存”，PH解决“全厂数据怎么汇”，IS解决“历史数据怎么看”。三者各司其职、逐层依赖，配置时抓住接口和变量范围，排障时沿数据流从上游到下游逐段检查，就能高效地完成历史数据平台的工程实施。