为什么 PCN 判定记录是一种新的工程数据？

基础概念可参见：

PCN 在每一次判定中都会产生一组结构化数据。

这组数据不是为了事后追溯才顺便留下来的副产品。它本身就是一套面向状态迁移入口、控制判定和后续改善的工程数据模板。

  • 设备数据记录设备发生了什么。

  • 生产数据记录产品生产了什么。

  • PCN 判定记录的是系统为什么这样决定。

这三类数据不是同一层级。

1. 传统制造数据主要记录“发生了什么”

制造现场常见的数据大致可以分成三类。

第一类是设备状态数据：

  • 运行；
  • 停机；
  • 报警；
  • 转速；
  • 温度；
  • 电流；
  • 压力；
  • 位置；
  • 能耗。

第二类是生产结果数据：

  • 产量；
  • 良率；
  • 节拍；
  • OEE；
  • 不良数量；
  • 停机时间；
  • 损失时间。

第三类是事件和报警履历：

  • 报警发生；
  • 报警复位；
  • 设备启动；
  • 设备停止；
  • 工序开始；
  • 工序结束；
  • 任务完成；
  • 任务失败。

这些数据都很重要，但它们主要记录结果、状态和事件。

它们能够说明：

  • 设备停了；
  • 某个报警发生了；
  • 产量下降了；
  • 节拍变慢了；
  • 某个任务没有完成。

但它们通常不能完整说明：

  • 为什么这个目标阶段没有进入；
  • 问题属于条件、许可还是执行链；
  • 问题属于结构缺失、动态异常还是控制边界；
  • 当时有哪些候选控制路径；
  • 为什么最终选择禁止，而不是等待或重试；
  • 哪个判断节点长期存在设计薄弱点。

传统数据擅长记录“发生了什么”，但对“为什么没有发生”记录不足。

2. PCN 的判定记录的是一次完整状态迁移判定

PCN 的最小单位是一个明确的状态迁移入口：

【当前状态】 → 【目标状态】 在这个入口上，PCN 读取与目标状态进入相关的多源状态信号，

并完成 → C/A/E 状态映射 → S/D/B 判定 → 九个域级结果 → 关键项短路 → 优先级仲裁 → 多路径控制输出 → 判定记录

因此，一条 PCN 判定记录是一条完整的状态迁移判定记录。

它至少可以包含：

数据项作用
PCN_ID定位具体前置判定节点
Current_Stage记录当前状态或当前阶段
Target_Stage记录准备进入的目标状态或目标阶段
C/A/E 映射结果说明问题属于条件、许可还是执行链
S/D/B 判定结果说明问题属于结构、动态还是控制边界
九个域级结果保留 C-S 至 E-B 的完整判定结构
仲裁过程记录高优先级条件、短路逻辑和被压制候选
最终控制路径记录 Allow、Wait、Retry、Return、Prohibit 等结果
ReasonCode记录本次判定的直接原因
执行结果记录控制路径执行后是否恢复、失败或转人工
TraceID将以上数据绑定为一次完整判定事件

与一般报警记录相比，PCN 判定记录可以进一步说明：

目标阶段：WAITING → PICKING

问题域：A
问题性质：D
原因：区域许可时间戳失效
候选路径：WAIT / PROHIBIT
最终路径：PROHIBIT
仲裁原因：关键许可无法证明成立

PCN 判定记录的是这个结果怎样形成的整个过程。

3. PCN 判定记录对应一次完整的状态迁移判定

传统 PLC、MES 和设备日志通常围绕事件保存数据。

例如：设备停止，报警发生，任务失败，工序完成

PCN 判定记录保存的是一次判定对象。

一次完整对象包括：

  • Trace_ID
  • Current_Stage
  • Target_Stage
  • Input_Snapshot
  • CAE_Mapping
  • SDB_Result
  • Domain_Result
  • Priority_Arbitration
  • Control_Output
  • Execution_Result

这与一般看到的几十条分散日志不同。

这条判定信息可以直接用于：

  • 节点级统计；
  • 域级统计；
  • 原因级统计；
  • 路径级统计；
  • 恢复结果统计；
  • 规则版本对比；
  • 改善前后对比。

这就是 PCN 判定记录与普通报警履历的根本区别。

4. 为什么 PCN 判定记录可以直接形成改善对象

传统数据分析要从异常到改善，中间通常必须经过很长的工程链条：

数据异常 → 查设备 → 查信号 → 查程序 → 查互锁 → 判断问题性质 → 确定改善方向 → 修改程序或参数

每一步都需要有经验的工程师介入。

而且，很多现场数据本身并不指向明确的改善位置。例如“条件不满足”可能来自一个串联了二十个触点的内部线圈，单看报警文字无法知道真正问题在哪里。

PCN 判定记录在生成时已经包含：

哪个节点
哪个目标阶段
哪个变量域
哪种判定性质
哪个具体原因
触发了什么控制路径
最后是否恢复

因此，很多改善方向可以直接从判定模式中得到。

判定模式对应改善方向
C-S FAIL 高频补充条件信号定义、接口或映射关系
C-D FAIL 高频调整有效窗口，解决刷新、抖动或同步问题
C-B 长期处于 RETRY检查视觉、传感器或工艺边界设置
A-D UNKNOWN 反复出现补充许可时间戳、刷新机制或同步依据
A 域频繁触发 PROHIBIT审查许可来源、资源锁或安全设计
E-S FAIL：回流路径未定义补充异常排出、回退或替代路径
E-D 下游 BUSY 高频协调下游节拍、增加缓冲或调整承接逻辑
E-B 长期 WAIT 后自行恢复调整等待窗口，增加预判或提前协调
某 RETRY 路径成功率很低取消无效重试，改为人工确认或其他路径
某 PCN 节点长期无异常降低监控频率，简化部分判定或调整采集策略

这里不需要先做复杂的数据挖掘，判定结构本身已经给出了改善落点。

5. 改善动作可以直接落回 PCN 配置

PCN 判定记录的价值不只在于发现问题，还在于改善动作有明确的执行对象。

常见改善可以直接落回：

  • Signal Metadata；
  • Stage Metadata；
  • Structure Profile；
  • Dynamic Profile；
  • Boundary Profile；
  • Action Profile；
  • Priority Profile；
  • Path Definition。

例如：

C-D FAIL 高频
→ 修改 Valid_Window
→ 检查 Timestamp_Source
→ 增加 Refresh 监视

E-S FAIL
→ 增加 PathDefined
→ 补充回流或异常排出路径

A-D UNKNOWN 高频
→ 增加许可时间戳
→ 明确许可来源
→ 增加同步确认机制

RETRY 成功率低
→ 修改 Boundary_Profile
→ 调整 Action_Profile
→ 提高 MANUAL_CONFIRM 或 PROHIBIT 的优先级

每一次修改都可以形成配置版本。

下一周期的判定记录可以继续验证：

  • FAIL 比例是否下降；
  • UNKNOWN 是否减少；
  • RETRY 成功率是否提高；
  • WAIT 是否缩短；
  • PROHIBIT 是否更准确；
  • 执行链是否更稳定。

这使改善不再停留在经验判断，而是形成可验证的规则更新。

6. PCN 判定记录可形成状态迁移设计闭环

完整闭环可以表示为：

PCN 判定
    ↓
生成判定记录
（输入 + 判定 + 仲裁 + 控制输出 + 执行结果）
    ↓
按 PCN 节点 / 域 / 性质 / 路径 / 恢复方式聚合
    ↓
识别高频失败节点、长期 UNKNOWN、无效路径和结构缺陷
    ↓
改善动作落回元数据、规则或工程设计
    ↓
重新发布 PCN 配置
    ↓
下一周期判定记录验证改善效果

这其实在管理的是状态迁移设计本身。

7. 与传统制造 DX 的区别

传统制造 DX 通常从设备数据和生产数据出发：

采集设备数据
→ 发现异常
→ 分析原因
→ 提出改善

PCN-DX 的路径则不同：

采集判定数据
→ 识别状态迁移设计缺陷
→ 修改规则、边界或路径
→ 用后续判定记录验证效果

两者的区别可以整理如下：

项目传统设备 / 生产 DXPCN 判定记录
主要数据设备状态、报警、产量、良率、OEE状态迁移判定、仲裁、路径和执行结果
记录对象设备、事件、生产结果当前状态 → 目标状态的判定入口
主要问题发生了什么为什么这样决定
分析方式从数据中查找异常和原因从判定结构中定位薄弱点
改善落点设备、参数、保全、工艺元数据、规则、边界、许可、执行链、路径
验证方式产量、节拍、OEE、报警变化后续 Trace 中的 FAIL、UNKNOWN、WAIT、RETRY 和恢复结果

传统 DX 需要较强的数据分析能力，从大量设备数据中发现问题。

PCN 判定记录已经把改善对象定位到：

  • 节点
  • 域
  • 性质
  • 原因
  • 路径

因此，改善更容易直接落到工程设计上。

8. 对 PLC、MES 和制造企业的产品价值

PCN 判定记录不只服务 PLC 内部调试，它还可以形成独立的数据产品。

对 PLC 平台厂商

PCN 的 ReasonCode 和 TraceID 可以形成标准化诊断数据格式。

PLC 平台提供的不再只是：

  • 报警码；
  • 设备状态；
  • 线圈状态；
  • 运行履历。

还可以提供：

  • 目标阶段；
  • C/A/E 域；
  • S/D/B 性质；
  • 仲裁结果；
  • 控制路径；
  • 执行结果。

这使 PLC 平台具备状态迁移判定履历能力。

对 MES / WCS 厂商

MES / WCS 可以把 PCN 判定记录作为协同诊断模块的数据源。

系统不再只显示：

WAITING
BLOCKED
PENDING

还可以继续说明：

哪个 PCN 节点
哪个目标状态
哪个域不成立
哪类问题被触发
最终选择了什么控制路径

对制造企业

制造企业可以把 PCN 判定记录直接纳入改善流程。

设备、工艺、安全、生产和系统部门可以围绕同一条判定记录讨论：

  • 当时发生了什么；
  • 为什么不能进入；
  • 哪个部门需要处理；
  • 哪条路径是否有效；
  • 哪项规则需要修改；
  • 修改后效果如何。

这比各部门分别查 PLC、HMI、MES、WCS 和报警履历更容易形成统一结论。

小结

制造现场长期保存设备数据、生产数据和报警数据。

这些数据分别记录设备发生了什么、产品生产了什么、异常什么时候发生。

PCN 判定记录的不是设备状态，而是一次状态迁移判定的全过程。

PCN 判定记录把当前阶段、目标阶段、C/A/E 映射、S/D/B 判定、九个域级结果、仲裁过程、控制路径、原因码和执行结果绑定为一次完整状态迁移事件。

这使状态迁移条件、许可关系、执行链、边界设置和控制策略能够被连续记录、比较和改善。

设备数据描述设备运行，生产数据描述生产结果，PCN 判定记录描述状态迁移决策。

文档信息

题目：“为什么 PCN 判定记录是一种新的工程数据？”
文档类型：技术札记
版本：Public Note Version 1.0
发布日期：2026-07-14
作者：全野南政 / Nansei Zenno
当前 URL：https://zennns.com/zh/notes/why-pcn-trace-is-engineering-data/