2. FactoryTalk Historian体系结构

FactoryTalk Historian 并不是单一软件，而是由两个定位不同的产品线组成：FactoryTalk Historian SE（Site Edition，站点版）与 FactoryTalk Historian ME（Machine Edition，机器版）。理解体系结构的关键，是先分清“谁负责长期集中存储、谁负责设备侧就地采集”，再理解两者如何在同一套 FactoryTalk 命名空间下协同。SE 是服务器级的历史数据库，承担全厂级数据汇聚、长期归档与上层分析；ME 是嵌入在 Logix 控制器（如 ControlLogix、CompactLogix）内的模块化历史数据服务，直接在机架中采集并缓存本机数据。二者不是替代关系，而是“集中—边缘”的分工关系。

一、SE 的组件构成与部署模式

FactoryTalk Historian SE 的核心是 PI Server 体系，其组件可归为四类：

• 数据归档层：包括 PI Data Archive（历史数据归档，存储带时间戳的测点值）与 PI Asset Framework（AF，资产模型层，把测点组织成设备、单元、产线的层级结构）。
• 接口采集层：FactoryTalk Historian SE Interface，通过 RSLinx Enterprise / FactoryTalk Linx 与 ControlLogix、PLC-5、SLC 等控制器通信，按扫描周期读取标签值并写入 Data Archive。
• 客户端与展现层：PI ProcessBook、PI DataLink、PI Vision、FactoryTalk View SE 的趋势控件等，用于查询、绘图与报表。
• 管理与安全层：PI System Explorer、PI SMT，以及基于 FactoryTalk Directory 的账户与权限体系。

部署模式上，SE 常见三种拓扑：单机一体化（Data Archive、AF、接口、客户端同机，适合试点或小型产线）、分布式多服务器（接口服务器靠近控制网、归档服务器集中在数据中心、AF 服务器独立，适合多车间）、高可用集群（PI Collective 集体，多台 Data Archive 互为副本，读写可切换，用于关键连续生产）。选择依据主要是数据点数、保留年限、跨网段数量与可用性要求。

二、ME 的组件构成与部署模式

FactoryTalk Historian ME 是一块插入 Logix 背板的模块（如 1756-HIST2G），其内部运行精简的历史数据服务，包含：采集引擎（通过背板直接读取控制器标签，无需外部 OPC 通道）、本地存储（CF 卡或内置闪存，容量决定缓存时长）、Web 服务（内置网页用于配置与趋势查看）、同步客户端（把数据上传到 SE 的 Data Archive）。

ME 的部署模式非常直接：模块插在控制器机架，配置 IP 后即可独立工作。它的价值在于“断网不停采”——即使上层网络中断，ME 仍持续记录本机数据，网络恢复后再补传。典型场景是单机设备、远程无人站、OEM 出厂设备，以及网络不稳定但需要保留过程数据的场合。

三、数据流与协同关系

把两者放在一起看，数据流是“自下而上、边缘缓存、集中归档”：现场仪表 → Logix 控制器标签 → ME 模块就地采集并缓存 → 通过以太网将历史数据转发至 SE 的 Data Archive → AF 建模 → 客户端查询与展现。SE 侧的接口也可以直接采集同一控制器，因此实际项目中常见“ME 采本机、SE 采全厂”的混合结构。需要强调的是，ME 上传到 SE 后，数据在 Data Archive 中按统一时间戳归档，AF 再将其挂接到对应设备层级，从而让边缘数据获得与集中数据一致的查询口径。

四、典型拓扑与选型判断

实际工程中，拓扑选择可以用几个问题快速判断：数据是否必须跨车间集中？保留期是否超过 ME 本地容量？网络是否稳定？是否需要冗余？若答案偏向“集中、长期、稳定、冗余”，选 SE；若偏向“单机、就地、断网、轻量”，选 ME。混合场景下，ME 负责设备侧高频缓存，SE 负责全厂归档与建模，两者通过转发通道衔接。

理解体系结构的最终目的，是让数据从产生到被查询的路径清晰可控：现场信号进入控制器，ME 在边缘缓存，SE 在中心归档并建模，客户端按统一口径查询。只要这条链路中的每一段职责明确、时间一致、容量匹配，历史数据平台就能稳定支撑后续的绩效分析与排障回溯。