本文档描述 plcopen 项目的北极星愿景。
| 是什么 | 不是什么 |
|---|---|
| 野心的方向 | 路线图（见 ROADMAP.md） |
| 3-5 年的大图景 | 工作计划（每季度 review） |
| 对长期相信什么的声明 | 对短期能交付什么的承诺 |
| 每年复盘一次 | 严格按时间表推进 |
若文档与 ROADMAP.md 冲突，以 ROADMAP.md 为准。VISION 是方向，ROADMAP 才是承诺；当下走到哪看 STATUS.md。
让工业自动化领域有一个真正开源的、现代 C++ 的、PLCopen / IEC 61131-3 标准兼容的基石，让独立开发者和小团队也能做出可信的控制系统。
项目名就是 plcopen，不改——PLCopen 合规是立身之本与认证路径。但按 分层纪律，内核＝阶梯 L0-L4 + 支撑库 kin/stream/dyn，生而无 PLCopen 语义 （2026-07-12 include 图审计 0 违规，见 架构审查报告）：它是一个 通用运动控制内核，向不同世界提供不同的控制方式——
| 控制方式 | 面向 | 状态 |
|---|---|---|
| PLCopen FB 面（Part 1/2/4/5） | 工业自动化 / PLC | C0-C6 软件收束完成；正式 B/E/V 声明、真机证据与认证仍未完成（逐条审计见 doc/compliance/） |
| ST 语言面（IEC 61131-3 运行时） | PLC 工程师 / 61131 生态 | L0-L7、L∀ 声明集已闭合；134 个 FB、1476 个 pin、feature-set pending=0 |
| 位姿/笛卡尔命令面 | 工业机械臂 / 龙门 / SCARA | 已完成 |
| 流式执行面（混合指令帧） | 机器人 / 人形 / RL 策略 | 建设中 |
| Python 面 | 仿真 / 数字孪生 / 教学 | 已有，扩展中 |
| G-code 前端 | CNC | 门控中（解锁条件表） |
机器人/人形方向不是改行，是同一内核的自然延伸；每种控制方式都走 同一套语义矩阵与验证体系。
plcopen 站在两个世界的交叉点上：学习栈下面的工业级确定性执行底座 ——VLA 出意图，plcopen 出确定性轨迹。双受众＝工业控制器开发者 + 具身智能建造者，完整论证见 embodied-strategy。
工业自动化领域长期被闭源商业软件主导：CODESYS、西门子、三菱、倍福。这带来几个问题：
- 高昂的授权费（对独立开发者和初创团队是硬门槛）
- 工具链封闭（调试、扩展、集成都受限）
- 厂商锁定（代码难以迁移）
- 学习曲线与社区割裂（每家一套生态）
| 项目 | 覆盖范围 | 空缺 |
|---|---|---|
| Intel RTmotion（Apache 2.0，活跃） | PLCopen Part 1/2：单轴 + gear/cam/superimposed/torque/jog/home/IO | 零 Part 4（无组协调、无笛卡尔、无 kinematics、无 blending/前瞻——全树关键词 0 命中）；无 Part 5；无语言层；依赖外部 Ruckig；编译为共享库非 header-only |
| MatIEC | IEC 61131-3 编译器 | 没有运行时、没有运动控制 |
| Beremiz | 完整 IDE + MatIEC | 重量级，不适合嵌入到现有控制器 |
| OpenPLC | 面向 Arduino/RPi 的入门系统 | 工业级深度不足 |
| LinuxCNC | CNC 机床控制器 | 不是通用 PLC |
| ros2_control | 机器人控制框架，生态巨大 | 无确定性滤波语义、无 PLCopen 标准面 |
| 各家运动库 | 厂商私有 | 不开源、不标准 |
旧表述已作废（"没被填上的那一块 = 现代 C++ 可嵌入的 PLCopen 组件" ——RTmotion 出现后不再成立，如实校准，不装）。
当前真实立足点：唯一支持 PLCopen Part 4 协调运动（组共享路径 / 笛卡尔插补 / kinematics 级联 / 前瞻 blending / 路径表）与 IEC 61131-3 语言层的开源运动内核，且零依赖 header-only。RTmotion 的存在是需求 验证（Intel 不会为不存在的需求投工程师），也精确划出了我们的差异化 区间：浅水区（单轴+同步）已有人，深水区（多轴协调 + 语言层）只有 我们。
野心按层次展开。层次是依赖参考而非启动顺序——2026-07-07 判据换代后， 按维护面/身份/信号三判据解锁（见解锁条件表），已出现第 2 层先于第 1 层完整化交付的实际推进。
第 5 层：完整生态（HMI / 冗余 / 分布式 / SIL 安全）
↑
第 4 层：图形化编程与 IDE（LD / FBD / SFC 编辑器）
↑
第 3 层：工业通信适配（Modbus / OPC UA / EtherNet/IP）
↑
第 2 层：多语言编程支持（ST / SFC 运行时声明集已交付）
↑
第 1 层：完整 IEC 61131-3 标准功能块库（定时器 / 计数器 / 逻辑 / 数学）
↑
第 0 层：PLCopen Part 1&2 运动控制库【稳定基线】
注：此为生态阶梯（愿景层次编号），与
core/代码分层 L0-L7 无关，两套编号不可混读。
现状（始终以 STATUS.md 为准，本段不做快照）：v0.x
旧线在 v0.11.0 后冻结为回放基线；新核 core/（L0-L7 阶梯 +
kin/stream/dyn 支撑库）已完成重写与 Phase B 纯软件批次——Part 1/2 门面
43/43（B 级 I/O 齐备 22/43 为 2026-07-12 审计时点口径，P1-A 结构缺口
其后已补，条款差距见
doc/compliance/）、
Part 4 线性/圆弧/blending/前瞻、坐标系栈、kinematics（龙门/SCARA/6R）、
轨迹流、cam 样条、Servo/CiA402 适配面。
为什么这是根：
- 运动控制是工业自动化最硬核的部分（状态机复杂、算法精度高）
- 做扎实之后，上层功能能在稳定地基上展开
- 是不需要依赖任何外部系统就能独立有用的层
关键指标：状态机正确性、曲线精度、可测试性、可嵌入性
动机：让库能完整实现 PLCopen 家族标准，不只是 Motion 部分
内容：TON / TOF / TP / CTU / CTD / CTUD / SR / RS / R_TRIG / F_TRIG + 数学/比较/逻辑运算
前置：第 0 层稳定发 v0.2.0
动机：让非 C++ 开发者也能用这套基础设施
现状（声明集已闭合）：
- ST（Structured Text）：L0-L7 与 L∀ 已完成，覆盖确定性字节码 VM、类型、 POU/134 个标准 FB、进程映像、标准函数、任务、文本 SFC 与调试监控； 完成态证据见 L 系列工作拆解
- Python 绑定：pyplcopen 已存在（pybind11，三平台 wheel），扩面由 用户反馈驱动
- Lua 脚本：未立项（无用户信号）
前置：已解锁（2026-07-07 判据换代：维护面/身份/信号，不再要求 合作者前置）
动机：让库能连真实的工厂设备
候选：Modbus TCP/RTU、OPC UA（基于 open62541）、EtherCAT 从站适配
前置：第 0-2 层稳定 + 真实工业用户提出需求（不是假设）
动机：降低工业工程师使用门槛（他们大多不写 C++）
候选：LD / FBD 编辑器，可能基于 Web 或 Electron
前置：第 0-3 层稳定 + 找到设计/前端合作者
候选：HMI 编辑器、冗余 / 热备份、分布式 PLC、SIL 安全认证
性质：这一层已经是平台级，需要真实商业驱动或社区组织推动
野心必须被真实需求拉动，不是被内心焦虑推动。每个宏大能力都有量化触发条件：
| 能力 | 解锁条件（任一满足即启动评估） | 当前状态 |
|---|---|---|
| S 曲线（Jerk 受限） | v0.2 稳定后 OR 1 个用户 issue | 已完成单轴与 homing 基线 |
| MC_Home 完整实现 | v0.2 稳定后 | C5 已关闭 Part 5 的 11/11 标准 FB 与软件合同；真机与认证证据仍独立 |
| 多轴凸轮/齿轮 | 1 个用户 issue + 有测试硬件 | 已有模拟可测基础；硬件扩展仍受此条件约束 |
| Python 绑定 | ≥3 个"Python 能调吗"询问 | 已有最小单轴仿真 facade；扩面仍由反馈驱动 |
| IEC 61131-3 标准功能块库 | v0.3 后 OR 用户明确需要 | basic 10 + Part 1/2 45 + Part 4 68 + Part 5 11 已接入 ST；范围外项见 feature table |
| ST 编译器 MVP | L0-L7、L∀ 已于 2026-07-18 闭合 | |
| SFC / LD / FBD 语言层 | SFC 执行语义随 L 系列批次 ST-L6（批次编号，非 core 分层 L6 fb）；LD/FBD 图形层仍随层 4 编辑器 | 文本 SFC 已实现；LD/FBD 图形层未解锁 |
| PLCopen Part 6（液压） | 1 个流体动力行业用户需求 | 未解锁 |
| PLCopen Safety FB 族 | 有认证语境的集成方合作（无认证的安全 FB 不做） | 未解锁；P#8 已仅锁定 STO/SS1 集成责任边界，不实现任何 SF 能力 |
| PLCopen XML / TC6 | 随 LD/FBD 编辑器 | 未解锁 |
| Modbus 适配器 | 有正在使用库的项目提集成需求 | 未解锁 |
| OPC UA | 1 个工业客户深度集成承诺 | 未解锁 |
| LD / FBD 编辑器 | 库被 ≥10 个项目引用 | 未解锁 |
| SIL 认证 | 有客户愿意承担认证成本 | 未解锁 |
| 分布式 PLC | 多个大规模部署用户 | 未解锁 |
| IEC 61499 执行层（事件驱动 FB/ECC） | UAO/4diac 生态的真实集成需求 OR 灯塔用户明确要求（2026-07-12 登记；采纳仍小众，身份连贯性存疑——61131-3 才是立身之本） | 未解锁。技术协同点已识别备查：ST VM 可直接作 61499 算法引擎、ECC 与 L6 SFC 步自动机同族、X5/ADR-0006/0007 是分布地基——解锁时起点不为零 |
条件不到不启动。每次心里冒出"想做某某"，先来翻这张表。
判据换代（2026-07-07，ST 解锁后的拷问结论）：AI 吞吐使"成本"永久 退出解锁判据——否则同一论据可解锁一切，表即失效。现行判据三条： 维护面（交付即永久负担）、身份连贯性（是否属于"扎实的 plcopen"本体，ST 过关的理由）、用户信号（原判据保留）。OPC UA/ 编辑器等继续门控的依据是前两条，不是成本。
管辖范围（2026-07-05 复盘澄清）：本表管辖第 1-5 层（PLC 生态方向， 外部需求拉动）。第 0 层运动内核自身的深化——机器人化（kinematics/ 姿态/轨迹流）、伺服与总线执行层——由 long-term-plan 与语义矩阵批准流程 管辖，不走本表；Phase B 各批次即按此路径立项。
不推测未来需求，等真实用户提出。SQLite 用 25 年、Redis 用 15 年都是这样长起来的。
一次做一件事做透。同时做三件事等于三件事都做不好。
plcopen 首先是库，不是平台或产品。即使长到第 4 层，核心仍然是"能被嵌入到别人的系统里"。
IEC 61131-3 和 PLCopen 标准是地基。偏离标准的"改进"要极度谨慎，宁可慢也不要破坏兼容性。
按单人/小团队的真实产能做承诺。不写做不到的时间表。不为了好看而灌水里程碑。
即使愿景再大，以下事情不在方向里：
- 闭源或商业锁定：代码永远 Apache 2.0
- 与标准不兼容的扩展：可以有扩展功能块，但不能改变标准功能块行为
- 平台绑定：不会只支持特定硬件或操作系统
- 学术炫技：不为"先进"而引入不必要的复杂度
- 追赶每个新技术潮流：AI、区块链、元宇宙，跟这个项目无关
这些项目证明"开源长线"是合理路径：
| 项目 | 起点 | 今天 | 花了多久 |
|---|---|---|---|
| SQLite | 1 个嵌入式 SQL 引擎 | 每部手机都用 | 25 年 |
| Redis | 1 个内存字典 + 持久化 | 全球缓存基础设施 | 15 年 |
| Stripe | 7 行代码接受信用卡 | 互联网经济基础设施 | 14 年 |
| PostgreSQL | 1 个学院派数据库 | 企业级 SQL 标杆 | 35 年 |
共同模式：前 2-3 年极度聚焦，后期被用户拉向扩展，10 年后成为基础设施。
plcopen 如果能成为"工业自动化的 SQLite"——被嵌入、被信赖、被忽略（好的基础设施是被忽略的），就达到了。
- 每年一次 VISION 复盘（通常在项目周年时）
- 允许调整方向（如果证明某个层次错了）
- 不允许：放弃开源 / 放弃标准 / 放弃长期维护
10 年后的这个项目可能跟今天完全不一样。但方向不会变：让工业自动化有一个开源的、现代的、可信的基石。
如果某天回头看，发现项目做到了这一点——成功。
如果没做到但还在路上——也没事，长线项目本就如此。
如果发现方向错了——勇敢承认并转向。
本项目欢迎任何形式的贡献。但请注意：
- 贡献要符合当前
ROADMAP.md的焦点，不是 VISION.md 的所有层次 - 如果你想推动某个未解锁的能力（第 2-5 层），先开 issue 讨论，不要直接写代码
- 解锁条件表是 gatekeeper，不是障碍——满足条件就可以启动讨论
本文档最后更新：2026-07-19（C0-C6 与 L 系列完成态口径对齐；战略与解锁条件未改） 下次复盘：2027-04（或更早，如发生重大方向变化）