3. PI System数据采集与MES工单关联

在制造执行系统（MES）与PI System共存的工厂里，一个常见的困境是：PI System里存着海量的高频时序数据，MES里存着工单、批次、设备等业务上下文，但两者之间缺少一条“翻译通道”。PI标签点只知道自己在采集什么物理量，却不知道当前这批数据属于哪张工单、哪个批次；MES工单只知道生产了什么，却无法直接调取对应时段的实时曲线。本节要解决的核心问题，就是建立PI Point与MES工单号、批次号、设备编号之间的动态绑定关系，让实时数据能够按工单自动归集。

一、为什么需要动态绑定，而不是静态映射

最朴素的做法是给每个PI Point打上工单号属性，但工单是不断变化的：同一台反应釜今天生产批次A，明天生产批次B，下周可能生产批次C。如果采用静态映射，每换一次工单就要修改PI Point属性，既不可维护，也无法追溯历史。因此，正确的思路是：PI Point与设备编号保持相对稳定的绑定，设备编号与工单号/批次号之间通过MES的生产事件建立时间区间映射。这样，任意时刻的PI数据都可以通过“时间戳→设备→当时活跃的工单/批次”这条链路找到归属。

这里的关键概念是“时间区间”。MES中一张工单在某个设备上的执行，通常有明确的开始时间和结束时间，例如工单WO-20240612-001在反应釜R-101上从08:15开始、到16:40结束，对应批次B20240612A。这个区间就是数据归集的边界条件。PI System中该设备相关标签点在这个区间内采集的所有值，都应归入该工单和批次。

二、绑定的三个关键字段与匹配逻辑

动态绑定的实现，依赖三个字段的协同：设备编号、工单号、批次号。其中设备编号是PI Point与MES之间的“锚点”，工单号和批次号是归集的目标维度。

具体匹配逻辑分三步。第一步，在PI System中为每个与生产设备相关的PI Point维护一个设备编号属性（如R-101、R-102），这个属性通常来自PI AF（Asset Framework）中的设备元素层级，而不是直接写在PI Point的扩展属性里。第二步，从MES中获取工单执行事件，每条事件包含设备编号、工单号、批次号、开始时间、结束时间。第三步，对于任意PI数据点，先通过其所属AF元素的设备编号找到对应设备，再判断该点的时间戳落在哪个工单区间内，从而赋予工单号和批次号。

这里有一个容易出错的细节：时间区间的边界处理。如果工单A结束于16:40:00，工单B开始于16:40:00，那么16:40:00这个时间戳应该归给谁？工程上通常采用“左闭右开”原则，即[开始, 结束)，避免同一时刻被重复归集。如果MES给出的结束时间是16:40:00，实际应理解为16:40:00之前（不含）的数据属于该工单。此外，还要考虑设备停机、换批清洗等“无工单区间”，这些时段的数据不应被强行归入相邻工单，而应标记为“无工单”或“停机”状态。

三、实现方式：AF分析、PI Web API与中间表

在实际项目中，动态绑定通常有三种落地路径，各有适用场景。

路径一：PI AF Analysis + 属性映射。在AF中建立设备元素，元素下挂载PI Point作为属性。同时，通过AF的Table Lookup或Analysis，将MES工单事件同步为AF中的引用表。Analysis可以基于时间戳触发，把工单号和批次号写入PI Point的附加属性或AF属性中。这种方式适合工单频率不高、对实时性要求中等的场景，优点是全部在PI体系内完成，不依赖外部程序。

路径二：PI Web API + 外部服务。由外部程序（如.NET服务或Python脚本）定时调用PI Web API读取PI数据，同时从MES数据库或API获取工单区间，在内存中完成匹配后，将结果写回PI AF属性或写入独立的归集数据库。这种方式灵活度高，适合工单切换频繁、需要复杂业务规则（如按产品牌号过滤、按班组归集）的场景。

路径三：中间表 + 批量归集。在关系数据库中建立一张“工单-设备-时间区间”中间表，由ETL任务定期从MES同步工单事件，再从PI System批量抽取对应区间的数据，写入归集结果表。这种方式适合对历史数据做离线分析、生成批次报告，不要求秒级实时性。

下面给出一个中间表结构的示例，用于支撑路径三的批量归集：

CREATE TABLE mes_workorder_binding (
    id              BIGINT PRIMARY KEY,
    workorder_no    VARCHAR(32)  NOT NULL,   -- MES工单号
    batch_no        VARCHAR(32)  NOT NULL,   -- MES批次号
    equipment_code  VARCHAR(16)  NOT NULL,   -- 设备编号，如 R-101
    start_time      DATETIME     NOT NULL,   -- 工单开始时间
    end_time        DATETIME     NOT NULL,   -- 工单结束时间
    product_code    VARCHAR(32),             -- 产品编码
    status          VARCHAR(16)  DEFAULT 'ACTIVE'
);

-- 归集查询示例：取R-101在工单WO-20240612-001期间的温度数据
SELECT p.timestamp, p.value, b.workorder_no, b.batch_no
FROM pi_archive p
JOIN mes_workorder_binding b
  ON b.equipment_code = 'R-101'
 AND p.timestamp >= b.start_time
 AND p.timestamp <  b.end_time
WHERE b.workorder_no = 'WO-20240612-001'
  AND p.tag_name = 'R101_TEMP';

这个查询的关键在于连接条件：设备编号相等，且PI时间戳落在工单区间内。注意这里用了>= start_time和< end_time，即左闭右开，与前面讨论的边界原则一致。

四、结果验证与常见问题

绑定完成后，如何判断归集是否正确？可以从三个角度检查。第一，覆盖率：统计某工单区间内应归集的PI Point数量与实际归集到的数量，如果覆盖率明显低于100%，说明部分标签点未正确关联设备编号，或时间区间存在缺口。第二，重叠检查：同一设备同一时间戳是否被归入多个工单，正常情况下不应出现。第三，业务合理性：抽查某批次的温度曲线，看是否与工艺要求相符，例如反应阶段温度应在80~85°C之间，如果曲线出现长时间异常低值，可能是工单区间与实际生产时间不匹配。

另一个常见问题是工单拆分与合并。同一批次可能因设备故障被拆成两张工单，或者两张工单合并为一个批次。此时绑定关系不能简单按工单号一对一处理，而应以批次号作为更高层级的归集维度，允许多个工单区间映射到同一批次。在中间表中，可以增加batch_no索引，查询时按批次聚合，而不是按工单聚合。

五、小结：从“数据孤岛”到“工单上下文”

PI Point与MES工单的动态绑定，本质上是给时序数据补上业务上下文。设备编号提供空间维度，工单和批次提供业务维度，时间区间提供边界条件。三者结合后，PI System不再只是“看曲线”的工具，而成为可按工单追溯、按批次分析的数据底座。实现时，优先保证设备编号在AF中的一致性，再根据实时性要求选择AF Analysis、PI Web API或中间表方案，最后通过覆盖率、重叠检查和业务合理性验证归集质量。这样，MES的工单事件与PI的实时数据才能真正贯通，为后续的批次报告、质量追溯和OEE分析打下基础。