性质：首次以 PLCopen 规格原文为准的逐条对照（此前所有合规 声明基于自编清单）。规格 PDF 公开免费下载，
pdftotext可直读—— "原文核对"从此是 🟢 AI 全自主，不再是人工项。本次审计推翻了两条既有声明（见 §1），并推翻了一条对认证的 错误假设（见 §2）。诚实优先于面子：数字照实改。
| Part | 规格版本 | 规格 FB 数 | 我们实现 | 覆盖率 | 旧声明 | 判定 |
|---|---|---|---|---|---|---|
| Part 1 | v2.0 (2011) | 43 | 43 个门面 | 名称面 100%；C4 已关闭 D-01～D-20，正式声明仍不完整 | "45/45" | 🟡 KB-079 关闭核心语义缺陷；B/E/V 与认证材料仍不能由数量替代 |
| Part 4 | v2.0 (2026-05) | 68 | 68 个同名门面 | 名称面 100%，条款不合规 | "零留白" | 🟡 C3 后门面齐全，但 B/E/O 接口与语义仍多为部分覆盖 |
| Part 5 | v2.0 (2011) | 11 | 11 个标准门面；45 B + 102 E 已逐项声明 | 软件合同 11/11；正式合规未提交 | "已交付" | 🟡 C5（KB-080）关闭名称、派生类型、I/O 与可软件验证语义；硬件真实性和批准仍开放 |
| 合计 | — | 122 | 不做简单相加 | — | — | 接口/条款符合度不能由 FB 名称数量替代 |
根因（值得记住的教训）：part4-coverage.md 跟踪的是自编的 30 个
FB 清单，而规格 v2.0 实际定义 68 个——我们在漏掉 38 个 FB 的清单
上宣布了"零留白"。这是 KB-051 教训（"测试只看得见写它的人想到的
东西"）在合规面上的重演。
本节的旧分组保留为规划摘要；权威 68 项逐 FB 账见 Part 4 条款审计。C6 已删除旧名 Position 回读包装，只保留 v2
MC_GroupReadPosition(Source)。
| 组 | FB | 性质/成本 |
|---|---|---|
| 组参数/动态/SW限位/回读/运动学信息（19） | P4-B1 已新增同名 C++ 门面 | mcSetValue、非 ACS 高阶回读、start-point、virtual AXIS_REF 与部分 E 级仍未支持（KB-073） |
| 工具与负载（8） | GroupRead/WriteToolData、GroupSelectTool、GroupReadTool、GroupRead/WritePayloadData、GroupSelectPayload、GroupReadPayload |
✅ P4-B2：固定容量库与 active/selected 快照；工具真实进入 TCP，载荷待 P4-B3 动力学消费 |
| 同步（3） | MC_SyncAxisToGroup、MC_SyncGroupToAxis、MC_SetDynCoordTransform |
✅ P4-B3：组里程 position-locking、PathData 主轴驱动、动态组坐标 |
| 点动（2） | MC_GroupJog、MC_GroupJogVector |
✅ P4-B2：ACS/MCS/PCS 持续点动、受控停车、接管与软限位 |
| 刚体动力学（2） | MC_GroupRead/WriteRigidBodyDynamic |
✅ P4-B3：base + 8 links 固定容量、整体校验后原子提交 |
| 跟踪（2） | MC_TrackConveyorBelt、MC_TrackRotaryTable |
✅ P4-B3：逐周期 PCS 更新、运动中跟随与完成后持续保持 |
| C3 最后 11 项 | UngroupAll/GroupPower、4 个 transform set/read、GroupSetPosition/ReadError/Halt/Wait/TransformPosition | ✅ KB-078：同名门面关闭；逐项边界见 Part 4 条款审计 §6 |
命名复核：FbSetKinTransform / FbReadCartesianTransform 分别对应
v2 §9.10.1 / §9.10.5，属于 68 项清单。C3 补齐相邻的动态/坐标变换门面后，
当前问题是插件指针、标准引用类型和输出字段的接口偏差，不再是名称缺失。
C5（KB-080）已补齐并复核全部 11 个标准 FB，逐 I/O 事实源为
plcopen-motion-part5-io.yml，生成结果为
generated/plcopen-motion-part5-io.md。当前剩余项是 IEC 基础类型替代、
真机堵转/编码器/时间戳/TorqueLimit 证明及供应商签署批准，不再存在软件
门面或已定义语义缺口。
规格 Part 1 附录 B「Compliance Procedure and Compliance List」原文 要点（只引条目不抄文本，出处纪律）：
| 事实 | 影响 |
|---|---|
| 合规 = 供应商填写声明表（支持的数据类型 + 支持的 FB 及其 I/O）→ 提交 PLCopen → 批准后发布在官网清单 + 获 Motion Control logo 使用权 | 没有测试套件、没有复核周期——是自声明 + 审批 |
合规只需 "一个或多个 FB"（"one or more Function Blocks"），且声明支持的每个 FB 必须实现其标记为 B(Basic) 的输入输出 |
不需要实现全部 FB 即可合规——覆盖率不是认证门槛，Basic I/O 的完整性才是 |
I/O 三级标记：B 强制 / E 扩展可选 / V 厂商扩展（须在合规文档列出） |
真正的合规工作 = 逐 FB 核对 B 级 I/O，而非堆 FB 数量 |
| 数据类型可替换（REAL ↔ SINT/INT/DINT/LREAL）只要全套一致 | 我们的 LREAL 口径合规 |
| 规格文本未提及会员资格是提交前提 | 会费是否必需 需人工向 PLCopen 确认（🔴 人专属） |
结论：八项硬指标 #3（PLCopen 认证）不是 6-12 个月的黑箱—— 它可能是"逐 FB 核对 B 级 I/O + 填表 + 提交"。这把 #3 从"人专属+ 长周期"大幅拉回到"🟢 AI 可做的核对工作 + 🔴 一次提交动作"。
下一步（真正的合规工作）：以 Part 1 的 43 个 FB 为起点，逐 FB 核对其 B 级 I/O 是否全部实现——这才是认证的实质内容，而我们从没做过。
| 技术面 | 内容 | 我们的状态 |
|---|---|---|
| Motion Control（TC2） | Part 1/3/4/5/6 + OOP 运动库 + 应用示例 | ✅ 官方资料全文已审计；OOP 接口族未实现（M-01~M-03） |
| Safety（TC5） | Safety Part 1-4 + SafeMotion | ✅ 全文已审计；S-01~S-10，仍为 VISION 硬门控 |
| OPC UA（TC4） | Client FB、IEC 61131-3 信息模型、NodeSet/NodeIds、架构 | ✅ 全文已审计；现行 FB 0/28、模型 0/13，触发条件仍待裁 |
| XML 交换 / TC6 | PLCopen XML v2.01 + XSD + IEC 61131-10 组件 | ✅ 全文已审计；交换基础设施 0/4，仍随编辑器门控 |
| 编码与质量指南 | Coding Guidelines v1.0、Software Quality Metrics v1.0、Creating compliant FB libraries v1.0 | ✅ 全文已审计；G-01~G-03 登记生命周期、64 条规则门与结构度量缺口 |
| 语言层规范 | ST/SFC/LD/FBD 语言指南、Annex A-E 文本语言规范方法 | ✅ Annex A-E 已审计；现有 ST 子集差距见 G-05，图形语言仍不在实现范围 |
| OOP | OOP Guidelines、OOP 运动控制库 | ✅ Guidelines、接口文档与示例库均已审计；语言能力及 6 接口/34 方法合同缺失（G-04、M-01） |
| PackML/OMAC | PackML 状态图映射 | ✅ 已审计；无 PackML 状态模型、SFC 映射或 OEE 合同（L-04） |
"Creating PLCopen compliant FB libraries"已读：是 FB 设计约定
指南（边沿触发 vs 电平控制、Execute↔Done / Enable↔Valid 配对、
定时器语义、数据表规范）——我们的 FB 面应逐条对照（多数约定我们
天然符合，需核实）。
IEC 61131-3 第三版引入 OOP（类/方法/接口），PLCopen 有 OOP 运动控制 库与 OOP Guidelines。而 L 系列批次表（L0-L7）零 OOP 计划—— 这不是"要不要做"，是我们从没意识到要决定。
待裁决：排期（L2b 之后的 L2d？）/ 显式门控（写进 VISION 解锁表） / 永不做。三选一，不许装看不见。
现行触发条件："1 个工业客户深度集成承诺"——这是死锁：我们连用户 都没有，何来深度集成承诺？
且有新证据：PLCopen 的 OPC UA 面是 IEC 61131-3 信息模型 + Client FB——它骑在语言层上，而我们正在做语言层。L2（POU 实例 模型）+ L3（进程映像）完成后，"PLC 变量 → OPC UA 节点"的地基天然 就位。耦合比原判更自然。
提案：触发条件改为 L3 完成 + 任一采纳信号（询盘/issue/灯塔接触）
——门控理由（维护面：栈是永久负担）仍成立，但条件从"不可达"变为
"可解锁"。
| # | 动作 | 归属 | 优先级 |
|---|---|---|---|
| 1 | 止血：STATUS/ROADMAP/part4-coverage 的失实数字全部改为原文口径 | 🟢 AI | 最高（诚实问题） |
| 2 | P-Part1-BIO：Part 1 的 43 个 FB 逐条核对 B 级 I/O——这是认证的实质 |
🟢 AI | 高（直通 #3） |
| 3 | P-Part4b：按 68 项清单补 47 个无同名入口并修正 21 个部分门面 | 🟢 AI | 高（~2-3 L0） |
| 4 | P-Part5b/C5：补齐并收口 Part 5 11 个标准 FB | ✅ 已完成 | KB-080；45 B + 102 E 机读声明 |
| 5 | 命名合规：FbSetKinTransform/FbReadCartesianTransform 等对齐 v2.0 |
🟢 AI | 中（声明变更） |
| 6 | 对照 Coding Guidelines / Software Quality Metrics / Creating compliant FB libraries | ✅ 已审计 | G-01~G-03，后续实现另批 |
| 7 | Annex A-E 纳入 L∀ 一致性体系 | ✅ 已审计 | G-05，语言补齐另批 |
| 8 | OOP 裁决（排期/门控/永不） | 🔴 人 | 待裁 |
| 9 | OPC UA 触发条件修正 | 🔴 人 | 待裁 |
| 10 | 向 PLCopen 确认提交合规声明是否需会员资格 | 🔴 人 | 中（#3 落地前） |
| 11 | Safety Part 1-4、SafeMotion 全文对照 | ✅ 已审计 | S-01~S-10；维持认证语境硬门控 |
| 12 | OPC UA Client FB / Information Model / NodeSet 全文对照 | ✅ 已审计 | U-01~U-11；实现仍门控 |
| 13 | XML v2.01 / IEC 61131-10 schema 全文对照 | ✅ 已审计 | X-01~X-12；实现仍门控 |
| 14 | Motion OOP/应用示例、Annex F、PackML/结构化指南对照 | ✅ 已审计 | M-01 |
创建：2026-07-12。规格 PDF 已存 scratchpad，pdftotext 可直读——
后续所有合规工作以原文为准，自编清单永久作废。
依据：Part 1 v2.0 附录 B3（43 个 FB 的 I/O 合规表，
B=强制 /E=可选 /V=厂商扩展）。B 级 I/O 总数 236，E 级 302。 这是认证的实质内容——不是 FB 数量，是声明支持的每个 FB 的 B 级 I/O 是否齐备。
结论：22/43 完全合规；21 个 FB 有 B 级缺口（29 个字段）。
| FB | 缺失 B 级 I/O | 说明 |
|---|---|---|
MC_MoveAbsolute |
Direction | 旋转轴的运动方向选择（最短路径/正/负）——我们完全没有此输入 |
MC_SetOverride |
Enable / Enabled / VelFactor | 结构性错误：规格是电平控制（Enable↔Enabled 配对），我们实现成边沿触发（Execute↔Done）；且 VelFactor（0..1 因子）语义 ≠ 我们的 percent（100.0）。这正是"Creating compliant FB libraries"指南第 1 节讲的边沿 vs 电平之分 |
MC_PhasingAbsolute / MC_PhasingRelative |
Master / Slave | 规格要求主从双轴引用，我们只有单个 axis_ref |
MC_DigitalCamSwitch |
Switches / InOperation / TrackNumber | 规格要求开关定义数组 + 轨道号；我们是单窗口简化实现（KB-005 已声明此边界，但它使该 FB 不合规） |
| 类别 | 涉及 FB | 缺失 B 级 I/O | 我们的现状 |
|---|---|---|---|
| 命名输出 | MC_MoveVelocity、MC_MoveContinuousAbs/Rel、MC_GearIn |
InVelocity、InEndVelocity、InGear |
统一用 MotionOutputs.done/busy/active，无规格命名的专属输出 |
| 剖面完成输出 | MC_PositionProfile、MC_VelocityProfile、MC_AccelerationProfile |
ProfileCompleted |
同上 |
| 剖面数据输入 | 同上三个 | TimePosition/TimeVelocity/TimeAcceleration |
我们的 profile 数据结构命名不同 |
| 回读值输出 | MC_ReadActualPosition/Velocity/Torque |
Position/Velocity/Torque |
共用基类的泛型 value 字段 |
| 数字 IO 通道 | MC_ReadDigitalInput/Output、MC_WriteDigitalOutput |
Input/Output |
通道号字段命名不同 |
| 主从轴命名 | MC_CamOut、MC_GearOut |
Slave |
单 axis_ref |
PLCopen 合规表登记的是 FB 的 I/O 名字——而 61131-3 用户看到的接口 是 L2a 的 MC_ 引脚表*，不是我们的 C++ 类字段。因此：
- B 类（命名）缺口应在 L2a 引脚表解决——C++ facade 的字段命名是 实现细节，引脚表按规格 B/E 名精确暴露即可；
- A 类（结构）缺口必须补 C++ 层——功能真的缺，引脚表无法凭空造；
⚠️ L2a 矩阵草案方向需修正：现草案"从fb/motion.h字段映射引脚" ——应改为"从规格附录 B3 的 B/E 表映射引脚"。L2a 不只是身份闭环件， 它就是 PLCopen 合规面本身。