1. 课程导入与可靠性工程视角
在工业数据平台中，PI System 往往被当作“历史数据库”来理解，但从可靠性工程的角度看，它更像是一条从现场设备到上层应用的数据供应链。这条链路上任何一环失效，都不会只表现为“某个点没数据”，而会沿着采集、传输、缓存、写入、查询的路径逐级放大，最终影响报表、KPI、报警、先进控制甚至生产决策。本课程的核心，就是把 PI System 的数据接口与采集链路当作一个可分析、可度量、可加固的工程对象来对待。
一、核心对象：链路上的六类实体
要谈可靠性，先要明确“可靠的是什么”。在 PI System 采集链路中，真正需要被持续保障的对象可以归纳为六类：
- 数据源：DCS、PLC、RTU、SCADA、智能仪表、OPC UA/DA 服务器、关系数据库、文件或消息队列。它们是数据的起点，决定了原始值的语义与时间戳来源。
- 接口层：PI Interface、PI Connector、PI Adapter、OPC 客户端、自定义 API 程序。它们负责协议转换、标签映射、时间戳处理和异常重连。
- 缓冲层：PI Buffer Subsystem、接口本地缓存、消息队列。它决定网络中断或 PI Data Archive 不可用时，数据能否“先存后补”。
- 归档层：PI Data Archive 及其 Collective 成员。它承担最终写入、压缩、时间序列存储与冗余切换。
- 服务层：PI AF Server、PI Web API、PI Analysis Service、PI Notifications。它们把原始数据加工为资产模型、计算属性与事件。
- 消费层：PI Vision、Excel PI DataLink、第三方报表、MES/ERP、算法平台。它们决定数据最终是否被正确使用。
这六类实体不是简单的串联关系，而是存在多对多、可冗余、可旁路的拓扑。例如一个 Connector 可以同时向两个 Data Archive 成员写入；一个 Buffer 可以服务多个接口实例；一个 AF 属性可能同时依赖多个 PI Point 和计算表达式。可靠性分析必须建立在这种真实拓扑之上，而不是一条理想直线。
二、可靠性目标：不只是“有数据”
很多团队把采集可靠性简化为“接口在运行、点有值”。但在工程实践中，至少需要同时满足六个可度量的目标：
- 完整性：在约定时间窗口内，实际归档点数与应采集点数之比达到目标，例如 99.9%。
- 时间正确性：时间戳来源明确，源端时间与 PI 归档时间偏差在允许范围内，避免“数据到了但时间错了”。
- 顺序性：同一测点的值按时间单调写入，回补数据不覆盖新数据，乱序可被识别和处理。
- 延迟可控：从源端产生到可被消费查询的端到端延迟满足业务要求，例如报警类 < 2 s，报表类 < 5 min。
- 可恢复性：网络中断、Archive 切换、接口崩溃后，能自动重连并回补，且不产生重复或丢失。
- 可观测性：链路各环节有状态、计数、日志和告警，故障发生时能快速定位到具体节点。
这六个目标之间存在张力。例如为了降低延迟而缩短缓冲时间，会削弱可恢复性；为了提高完整性而无限缓存，会带来磁盘和回补风暴风险。可靠性工程不是追求单点最优，而是在业务约束下做可解释的权衡。
三、故障代价：从丢点到决策失真
采集链路故障的代价不是线性的。一个 5 分钟的接口中断，如果发生在非关键测点，可能只是报表上一个小缺口；如果发生在批次切换、联锁动作或环保监测窗口，代价会迅速放大。常见的代价路径包括：
- 追溯断链：批次生产数据缺失，导致质量追溯无法闭环，合规审计不通过。
- 报警漏报：关键测点未及时归档，报警服务无法触发，安全风险上升。
- 核算偏差：能耗、收率、物耗计算基于不完整数据，月度结算出现争议。
- 控制失效：先进控制或优化算法依赖实时数据，数据延迟或跳变导致控制品质下降。
- 信任流失：业务用户发现数据不可信后，会绕过 PI 系统自建表格，形成数据孤岛。
因此，可靠性投入的优先级应由业务影响 × 发生概率 × 可检测性共同决定，而不是平均用力。关键测点、关键接口、关键时间段应获得更高的冗余、更密的监控和更快的恢复流程。
四、全链路视角：问题地图
后续章节将围绕这条链路展开。为了便于建立整体认知，可以把问题地图分为五个域：
| 问题域 | 典型问题 | 关键手段 |
|---|---|---|
| 源端与协议 | 扫描周期不合理、时间戳缺失、地址映射错误 | 源端建模、时间同步、点表校验 |
| 接口与连接 | 重连风暴、句柄泄漏、单实例瓶颈 | 接口参数调优、多实例、健康检查 |
| 缓冲与回补 | Buffer 溢出、回补顺序错乱、磁盘写满 | 缓冲容量规划、回补策略、磁盘监控 |
| 归档与冗余 | Collective 切换异常、归档延迟、压缩争议 | 冗余验证、写入性能基线、归档策略 |
| 服务与消费 | AF 计算失败、Web API 超时、报表口径不一致 | 依赖分析、缓存策略、数据质量校验 |
五、一个可执行的开场检查
在进入具体技术细节之前，建议先对现有环境做一次轻量级链路体检。以下检查项可直接用于现场：
1. 列出所有 PI Interface / Connector 实例，记录其数据源、目标 Archive、Buffer 状态。
2. 对每个关键测点，确认源端时间戳来源（设备时间 / 接口时间 / 系统时间）。
3. 检查 Buffer 队列深度与历史溢出记录，确认是否存在未回补缺口。
4. 查看 Data Archive Collective 成员状态与最近一次切换记录。
5. 抽查 AF 计算属性，确认其依赖的 PI Point 是否存在长期无数据或时间戳异常。
6. 在 PI Vision 或报表端，选取一个关键 KPI，反查其数据来源链路是否完整。
7. 记录当前基线：接口重连次数、归档延迟、查询响应时间、数据完整率。这份检查不追求一次性解决所有问题，而是帮助团队建立“链路可观测”的起点。只有先看清链路，后续的接口调优、缓冲规划、冗余验证和故障复盘才有可靠的依据。可靠性工程的第一步，永远不是买更多硬件，而是把现有链路的真实状态测量清楚。