2. PI System接口与采集链路总体架构

要理解 PI System 的采集可靠性，第一步不是去调某个参数，而是先看清数据从现场设备一路走到 PI Data Archive 的完整链路。PI System 并不是单一软件，而是一组职责分明的组件协同工作：靠近数据源的一侧负责"取数"，中间一侧负责"缓冲与转发"，靠近 PI Server 的一侧负责"落库与对外服务"。任何一段出问题，最终表现都是"PI 里没有数据"或"数据有缺口"，但根因可能完全不同。

一、四类采集组件：Interface、Connector、Adapter 与 PI Server

PI System 的采集入口主要有三类，它们面向不同的数据源形态和部署环境。

PI Interface 是历史最悠久、覆盖最广的一类采集组件。它通常以 Windows 服务形式运行在接口节点上，通过厂商提供的 API、OPC DA/UA、串口、文件、数据库等方式读取数据，再写入 PI Data Archive。典型代表如 PI Interface for OPC DA、PI Interface for Modbus TCP、PI Interface for RDBMS。Interface 的配置核心是接口实例（instance）与接口点（PI Point），一个接口进程往往对应一个数据源连接，通过 startup 配置文件、批处理文件（.bat）和 PI ICU 工具管理。

PI Connector 是较新的采集组件，强调"自动发现、自动建点、集中管理"。它通常以 Windows 服务或容器形式部署，通过 Connector Relay 或直接与 PI Web API 通信，把数据写入 PI Data Archive 或 PI Asset Framework。典型代表如 PI Connector for OPC UA、PI Connector for UFL、PI Connector for CygNet。Connector 的优势在于减少手工建点，但引入了 Relay 这一中间环节，链路更长。

PI Adapter 是面向边缘和云原生场景的采集组件，通常以轻量容器运行在边缘网关或 Kubernetes 环境中，通过 PI Web API 或 PI Data Archive 的写入接口上传数据。典型代表如 PI Adapter for OPC UA、PI Adapter for Modbus TCP。Adapter 强调跨平台、可编排、配置即代码（YAML/JSON），适合大规模边缘部署。

三类组件最终都指向同一个落点：PI Data Archive。它是时序数据的存储核心，负责压缩、归档和查询。而 PI Asset Framework（AF） 则在其上构建资产模型，把测点组织成设备、单元、工艺段等有语义的结构。PI Web API、PI Vision、PI DataLink 等消费端通过 AF 和 Data Archive 读取数据。

二、缓冲与转发：链路可靠性的关键缓冲层

采集链路最怕的不是"读不到"，而是"读到了但送不出去"。当 PI Data Archive 短暂不可用、网络抖动或写入被限流时，如果采集端没有缓冲能力，数据就会直接丢失。因此缓冲与转发机制是可靠性的核心。

对于 PI Interface，缓冲通常由 PI Buffer Subsystem（PI Buffer Server / PI BufSS） 提供。接口进程先把数据写入本地缓冲区，再由缓冲子系统异步转发到 PI Data Archive。缓冲区可以配置为内存缓冲、磁盘缓冲或两者结合，磁盘缓冲文件通常位于接口节点的本地磁盘。当 PI Data Archive 恢复后，缓冲数据按时间顺序回放，从而填补缺口。

对于 PI Connector，缓冲由 Connector 自身或 Relay 承担。Connector 通常内置本地队列，在无法连接 Relay 或 PI Web API 时暂存数据；Relay 则作为集中转发点，把多个 Connector 的数据汇聚后写入 PI Server。这种"边缘缓冲 + 集中转发"的结构提高了可管理性，但也意味着 Relay 成为潜在的瓶颈点，需要重点监控。

对于 PI Adapter，缓冲通常依赖边缘侧的持久化队列或消息中间件。Adapter 把采集到的数据先写入本地队列，再通过 PI Web API 批量上传。批量大小、上传间隔和重试策略直接影响数据完整性和 PI Server 的写入压力。

三、端到端链路全景

把上述组件串起来，一条典型的端到端链路是：现场设备/控制系统 → 采集组件（Interface / Connector / Adapter）→ 缓冲与转发层（PI Buffer Subsystem / Connector Relay / 边缘队列）→ PI Data Archive → PI AF → 消费端（PI Vision / PI Web API / PI DataLink）。

下面这张图展示了这条链路的主要组件、数据流向以及缓冲层的位置。图中用不同颜色区分采集侧、缓冲转发侧和 PI Server 侧，便于快速定位问题发生在哪一段。

四、链路分段与故障定位思路

把链路分成"数据源—采集—缓冲—落库—消费"五段后，排查就有了方向。当 PI Vision 上看不到数据时，可以按以下顺序快速缩小范围：

• 先看采集端：接口进程是否在运行？日志里是否有连接失败、超时、认证错误？以 PI Interface 为例，接口节点的 PIICU 日志和 .bat 启动脚本的输出是首要线索。
• 再看缓冲端：缓冲文件是否在增长？如果缓冲持续增长而 PI Data Archive 没有数据，说明写入通道断了，问题在缓冲到 PI Server 之间。
• 然后看落库端：PI Data Archive 上该 PI Point 是否有最新时间戳？如果时间戳停在某个时刻，说明写入中断；如果时间戳正常但值不对，问题可能在采集映射或数据源本身。
• 最后看消费端：AF 属性是否绑定了正确的 PI Point？PI Web API 是否返回数据？这一步排除的是展示层问题，而不是采集问题。

需要特别注意的是，不同采集组件的缓冲行为差异很大。PI Interface 的缓冲由独立的 Buffer Subsystem 管理，接口进程本身不直接持有大量数据；PI Connector 的缓冲通常在 Connector 服务内部，Relay 只做转发；PI Adapter 的缓冲则依赖边缘队列。这意味着同样表现为"数据缺失"，三类组件的排查入口和恢复动作并不相同。

五、一个简化的链路配置示例

假设某现场有一台 OPC UA 服务器，需要把 200 个测点采集到 PI Data Archive。可以选择 PI Interface for OPC UA，也可以选择 PI Connector for OPC UA。两者的链路差异如下：

这个对比说明：链路架构的选择不是"越新越好"，而是取决于数据源特性、运维能力和可靠性要求。Interface 链路短、可控性强，但建点和维护工作量大；Connector 链路长、自动化程度高，但 Relay 成为需要重点保障的环节。