TPCA / PCN 建立在什么工程基础上？
讨论一种新的工程方法时，很容易陷入两个极端。
一个极端是什么都说成新的。
另一个极端是，只要其中某个概念以前出现过，就认为整个方法没有新的东西。
这两种看法都不适合工程系统。
状态、状态迁移、Interlock、Ready、安全许可、超时、降级、备用路径，这些当然不是今天才出现的概念。成熟的自动化系统早就在使用它们。
真正的问题是：
这些机制已经存在，为什么复杂自动化系统仍然经常出现下面的情况？
- 设备没有报警，但进不了下一步；
- 机器人 Ready，动作却不能开始；
- MES 有任务，WCS 有记录，现场却一直 Waiting；
- 所有单机看起来正常，整条执行链却接不起来；
- 一个状态刚刚还是有效的，几秒以后已经不能再作为放行依据；
- 安全许可、运行条件、下游状态和异常路径分散在不同程序里，最后只能靠工程师查梯形图、日志和接口。
TPCA / PCN 关注的是：
在系统准备进入目标状态、目标执行路径或目标物理执行阶段之前，把原本分散的判断统一组织到一个明确的状态迁移入口。
从这个角度看，TPCA / PCN 建立在五个很传统、也很扎实的工程基础之上。
1. 复杂系统不能只看信号，还要看状态和状态迁移
一个信号为 TRUE，并不能直接说明系统应该进入下一阶段。
例如机器人 Ready，只能说明机器人当前具备某种运行条件。
它不能单独回答：
- 当前系统处于什么阶段；
- 准备进入什么阶段；
- 工件条件是否成立；
- 安全许可是否成立；
- 下游是否能够承接；
- 当前状态是否仍然有效。
自动化系统真正需要处理的是：
当前状态 → 目标状态。
也就是说，问题不只是“这个信号现在是多少”，而是：
为了从当前状态进入目标状态，到底需要哪些条件成立？
因此 TPCA 的基本分析单位不是单个状态位，而是一个明确的状态迁移入口。
只有先确定：
Current State → Target State
后面的 C、A、E 以及 S、D、B 才有明确的工程意义。
2. 能够执行，不等于允许执行
复杂系统中，“能不能做”和“允不允许做”必须区分。
机器人可能已经 Ready，夹爪可能正常，路径也可能可以执行。
但如果安全许可没有成立、区域许可被撤销、上位系统没有放行，系统仍然不能进入目标状态。
因此 TPCA 将进入目标状态前的相关信息进一步整理为不同变量域。
其中：
C = Condition，条件状态。
用于描述目标状态进入前的对象条件、现场条件、识别条件、任务条件、参数条件等是否成立。
A = Authority，许可状态。
用于描述系统是否被允许进入目标状态。
A 可以包括：
- 安全许可；
- 区域许可；
- 上位系统放行；
- 人工确认；
- 权限；
- 授权；
- 资源锁；
- 对方设备许可。
尤其对于关键 A，它可以构成独立必要约束。
也就是说：
即使 C 成立、E 也能够接续，只要关键 A 不成立，系统仍不得进入目标状态。
把 C 和 A 分开，并不是为了增加两个分类名称。
而是为了避免把本质不同的问题全部压缩成：
Condition = FALSE
3. 单体 Ready，不等于执行链成立
这是复杂自动化系统中非常容易被忽略的一点。
机器人 Ready，不代表抓取后的工件有地方放。
压装设备 Ready，不代表搬送机构已经退出压装区域。
检测设备 Ready，不代表检测完成后的结果能够正常上传。
AGV Ready，不代表目标站点可以接收。
主设备 Ready，也不代表异常排出路径已经可用。
因此 TPCA 中的 E 并不是普通的 Equipment Ready。
E = Execution Chain，执行链状态。
它关注的是：
系统一旦进入目标状态，后面的执行过程能不能继续接得住？
E 可以包括：
- 本体设备状态；
- 末端执行机构；
- 下游承接；
- 正常执行路径；
- 返回路径；
- 异常分流路径；
- 备用路径；
- 资源释放；
- 结果上传；
- 状态回写；
- 对方设备接收。
Ready 可以作为 E 的一个输入。
但 Ready 不能代表整个 E。
所以复杂系统完全可能出现：
所有单机都 Ready，但执行链仍然不成立。
4. 状态值必须带有时间语义
工业现场还有一种非常典型的问题：
信号本身没有错。
错的是时间。
视觉系统曾经输出 OK，但工件已经移动。
下游设备刚才 Ready，但当前状态已经变化。
资源锁曾经释放，但随后已经被其他主体重新占用。
上位许可曾经成立，但后来已经撤销。
所以：
TRUE 不等于当前仍然有效。
一个状态能不能用于本次状态迁移判断，还必须进一步看：
- 什么时候产生；
- 有没有刷新；
- 是否超时；
- 是否发生抖动；
- 多个状态是否同步；
- 是否存在冲突；
- 是否正在切换；
- 当前置信度是否仍然满足要求。
TPCA 将这一类判定性质定义为：
D = Dynamics，动态时序有效性。
因此，同一个状态至少存在两个完全不同的问题。
第一个问题：
这个状态有没有定义、有没有接入、能不能观测？
这是 S——Structure，结构完整性。
第二个问题：
这个状态现在是否仍然有效、可信、同步？
这是 D——Dynamics，动态时序有效性。
如果不区分这两个问题，最后往往都会被压缩成一个模糊的 NG。
5. 复杂系统必须明确控制边界
很多工程状态不是简单的 OK / NG。
例如：
视觉识别置信度已经接近正常放行范围的边缘。
位置偏差接近允许补偿范围。
下游暂时不能承接，但仍处于允许等待窗口。
某项许可正在切换，当前还不能放行，但也不能简单判断为永久失效。
这类状态的共同特点是：
系统已经不能按照“正常条件完全成立”处理，但也不能简单压缩成一个失败状态。
因此工程系统需要事先定义控制边界。
例如：
- 哪些范围仍然允许继续观察；
- 哪些状态可以再次采样；
- 哪些状态允许重新确认；
- 哪些状态已经超过允许重试范围；
- 哪些状态进入降级候选范围；
- 哪些边界越过以后不得进入目标状态；
- 哪些情况需要人工确认；
- 哪些情况进入更高等级的控制约束。
TPCA 将这一类判定性质定义为：
B = Boundary，控制边界。
例如：
视觉识别置信度接近允许边界，可以形成 C-B 判定。
某项许可处于限制或确认边界，可以形成 A-B 判定。
下游等待接近允许时间窗口，可以形成 E-B 判定。
B 判断的是：
某个 C、A 或 E 状态是否已经进入控制边界，以及相关边界条件是否被触发。
6. TPCA 在这些工程基础上增加了什么？
把前面的五点分别拆开看，都不是陌生概念。
- 状态机有状态迁移。
- PLC 有 Interlock。
- 安全系统有许可。
- 工业通信有时间戳和超时。
- 控制系统有边界、降级和安全停止。
- 调度系统也有等待、重派和备用路径。
TPCA 的重点是把这些原本分散的工程机制，重新组织到一个明确的目标状态迁移入口。
这个入口由 PCN——Pre-Control Node 承担。
其基本处理链为：
Current State → Target State → PCN → C / A / E Mapping → S / D / B Evaluation → CAE-SDB Result → Arbitration → Multipath Control → PCN Trace
其中：
PCN 回答：
在哪里进行这次迁移前判断？
C / A / E 回答：
需要判断哪些状态变量？
S / D / B 回答：
从什么性质判断这些状态？
CAE-SDB Result 表示：
当前状态迁移入口形成了什么结构化判定结果？
Arbitration 处理：
多个判定结果同时成立时，哪个结果具有更高控制优先级？
Multipath Control 决定：
系统最终输出哪一条控制路径？
PCN Trace 则记录：
当时依据什么状态、判定和仲裁结果形成了这个控制输出？
所以 TPCA 是一条完整的工程链：
状态迁移入口 → 状态整理 → 结构化判定 → 判定结果 → 控制仲裁 → 多路径控制 → 判定履历。
小结
TPCA / PCN 是建立在成熟工程机制已经大量存在的基础上。
真正的问题是：
这些判断长期分散在状态机、PLC 程序、Interlock、安全逻辑、HMI、MES / WCS、调度系统、接口协议和工程师经验中。
当系统越来越复杂以后，仅仅增加一个 Ready、一个报警或者一个 Interlock，已经越来越难解释：
系统为什么不能进入下一状态？
TPCA 因此把分析对象收缩到一个明确的位置：
目标状态迁移入口。
再通过：
PCN Runtime → C/A/E 状态映射 → S/D/B 判定 → CAE-SDB Result → Arbitration → Multipath Control → PCN Trace
把一次状态迁移判断变成可设计、可判定、可执行、可记录和可复用的工程对象。
文档信息
题目：TPCA / PCN 建立在什么工程基础上？——五个基础工程共识 文档类型：技术札记 版本：Public Note Version 1.0 发布日期：2026-08-18 作者：全野南政 / Nansei Zenno 当前 URL：https://zennns.com/zh/notes/engineering-foundations-of-tpca-pcn/
本文属于 TPCA / CAE-SDB 状态迁移前置控制架构的公开说明内容。