📚 课程目录第2章 PI System架构总览

2. PI System架构总览

要真正理解 PI System，不能只记住五个组件的名字，而要先回答一个更基础的问题：工业现场的数据，从产生到被人看见、被人使用，中间经过了哪些环节？PI System 的架构本质上是一条从“现场信号”到“业务语义”再到“人机界面”的数据链。PI Data Archive、PI AF、PI Vision、PI Interfaces、PI Connectors 这五个组件，分别站在这条链的不同位置上，承担不同的职责，彼此之间通过明确的接口协同工作。

一、五个组件的定位：谁负责什么

PI Data Archive 是整个系统的“时间序列数据仓库”。它存储的是带时间戳的原始测量值，例如某台泵在 2024-06-01 08:00:00 的出口压力为 1.25 MPa。它的核心能力是高密度写入、高效压缩和快速时间范围查询。它不关心“这个压力属于哪台设备、属于哪个工艺段”，只关心“标签名 + 时间戳 + 数值 + 质量码”。因此，PI Data Archive 是数据的事实层。

PI AF（PI Asset Framework） 是建立在 PI Data Archive 之上的“资产语义层”。它把孤立的标签组织成有业务含义的资产模型，例如“1号锅炉给水泵”这个资产，包含入口流量、出口压力、电机电流、轴承温度等属性，每个属性通过数据引用指向 PI Data Archive 中的具体标签。PI AF 还支持层级结构、模板、计算分析和事件框架。它回答的是“这个数据属于谁、代表什么、和其他数据是什么关系”。

PI Vision 是面向最终用户的“可视化与交互层”。工程师、操作员、管理人员通过浏览器访问 PI Vision，查看趋势图、仪表盘、资产面板和报警状态。PI Vision 本身不存储原始数据，它从 PI Data Archive 读取时间序列，从 PI AF 读取资产结构和计算属性，把两者组合成可交互的画面。

PI Interfaces 是传统的“数据采集接口”，通常以 Windows 服务形式运行在采集节点上。它们通过专有协议（如 OPC DA、Modbus、西门子 S7、AB CIP 等）从控制系统、PLC、DCS 或历史数据库中读取数据，然后写入 PI Data Archive。PI Interfaces 的典型特征是：面向标签、配置相对底层、需要针对不同数据源选择不同接口类型。

PI Connectors 是新一代的数据接入方式，定位与 PI Interfaces 类似，但设计理念不同。Connectors 更强调“开箱即用”和“资产导向”，内置了对常见数据源（如 OPC UA、关系数据库、CSV 文件、PI Web API 等）的适配能力，并可以在采集过程中直接创建 PI AF 资产模型，减少手工建模工作量。它更适合现代工业场景中数据源多样、部署周期短的需求。

二、协同关系：数据如何流动

把五个组件放在一起，数据流的方向就清晰了：

采集侧：PI Interfaces 或 PI Connectors 从现场数据源读取原始值，写入 PI Data Archive。这是数据的“入口”。
存储侧：PI Data Archive 按时间序列存储原始值，并执行压缩和归档。这是数据的“底座”。
语义侧：PI AF 引用 PI Data Archive 中的标签，构建资产模型、计算属性和分析规则。这是数据的“翻译层”。
展示侧：PI Vision 同时访问 PI Data Archive 和 PI AF，把时间序列和资产语义组合成趋势、表格、仪表盘。这是数据的“出口”。

需要特别注意的是，PI AF 并不复制 PI Data Archive 中的原始数据，而是通过“数据引用”指向它。这意味着当 PI Data Archive 中的数值更新时，PI AF 中的属性值会自动反映最新状态；当 PI AF 中的计算属性被 PI Vision 请求时，计算会在服务端执行并返回结果。这种“引用而非复制”的设计，保证了数据的一致性和存储效率。

三、系统边界：什么该放在哪里

理解架构的另一个关键，是明确各组件的边界，避免把职责放错位置：

PI Data Archive 不负责业务语义。不要试图在标签名里塞进完整的设备层级信息，那会让标签管理变得混乱。标签名应保持稳定、简洁，语义交给 PI AF。
PI AF 不负责原始数据采集。AF 中的属性值来自 PI Data Archive 或外部数据引用，它本身不直接连接 PLC。
PI Vision 不负责数据持久化。它展示的画面配置存储在 PI Vision 服务器中，但趋势数据始终来自 PI Data Archive 和 PI AF。
PI Interfaces 和 PI Connectors 不负责长期存储。它们只做采集和转发，数据落地由 PI Data Archive 完成。

在实际项目中，一个常见的判断方法是：如果问题是“这个值是多少”，答案在 PI Data Archive；如果问题是“这个值属于哪台设备、和谁比较”，答案在 PI AF；如果问题是“我怎么看到它”，答案在 PI Vision；如果问题是“它怎么进来的”，答案在 PI Interfaces 或 PI Connectors。

四、一张图看清整体架构

下面的 SVG 图展示了五个组件的层次关系和数据流向。左侧是数据源，中间是采集与存储层，右侧是语义与展示层。箭头方向表示数据的主要流动方向，虚线表示引用关系而非数据复制。

五、一个具体例子：从泵出口压力到资产面板

假设现场有一台“1号锅炉给水泵”，出口压力变送器信号接入 DCS。整个链路可以这样理解：

PI Interface（例如 OPC DA 接口）从 DCS 的 OPC 服务器读取标签 BOILER1.FWP1.OUTLET_PRESS，写入 PI Data Archive，时间戳精度为秒级，质量码为 Good。
在 PI AF 中创建资产 1号锅炉给水泵，其属性 出口压力 通过数据引用指向 BOILER1.FWP1.OUTLET_PRESS。同时可以添加计算属性 压力偏差 = 出口压力 − 设定值。
在 PI Vision 中创建一个资产面板，绑定 PI AF 中的 1号锅炉给水泵 资产，显示出口压力趋势和压力偏差仪表。操作员打开浏览器即可看到实时数据。

如果后来需要增加“泵运行状态”的语义判断，只需在 PI AF 中增加一个计算属性，例如“出口压力大于 0.8 MPa 且电机电流大于 10 A 则判定为运行”，而不需要修改 PI Data Archive 中的任何标签，也不需要重新配置采集接口。这就是分层架构带来的灵活性。

六、常见误区与边界判断

误区	问题所在	正确做法
把所有设备信息写进标签名	标签名过长、难以维护，语义无法复用	标签名保持简洁稳定，语义在 PI AF 中建模
在 PI Vision 中直接写计算逻辑	计算分散、难以复用、无法被其他应用调用	计算属性放在 PI AF 中，PI Vision 只负责展示
用 PI Interfaces 替代 PI Connectors 接入 OPC UA	配置复杂、资产建模需手工完成	优先评估 PI Connectors 对 OPC UA 的原生支持
认为 PI AF 会复制一份原始数据	误解存储机制，担心数据不一致	PI AF 通过引用访问 PI Data Archive，数据始终一致

在规划阶段就要明确：PI Data Archive 的标签命名规范、PI AF 的资产层级和模板设计、PI Vision 的画面组织方式，这三者需要协同设计。如果先随意建标签，后期再补 PI AF 模型，往往需要大量返工。建议在项目初期就用一个典型工艺段做端到端验证：从接口采集、到 AF 建模、再到 Vision 展示，跑通一条完整链路，再批量推广。

总结来说，PI System 的五个组件不是并列关系，而是分层协作关系：PI Interfaces 和 PI Connectors 负责“把数据拿进来”，PI Data Archive 负责“把数据存下来”，PI AF 负责“把数据讲清楚”，PI Vision 负责“把数据给人看”。理解这条数据链和每一层的边界，是后续进行系统设计、部署和排障的基础。