2. ctrlX AUTOMATION平台架构与版本对象

在讨论版本与变更治理之前，必须先回答一个基础问题：ctrlX AUTOMATION 里到底有哪些东西是“有版本”的？如果连版本对象都分不清，后续的变更评审、回滚策略、兼容性判断都会失去锚点。本节把平台拆成五个可独立版本化的层次——ctrlX OS、ctrlX CORE、ctrlX Data Layer、ctrlX Store 以及运行其上的应用与固件，并说明它们在治理中的角色与依赖方向。

一、从“设备”到“平台”的视角转换

传统控制器的版本管理往往只关注一件事：固件版本。ctrlX AUTOMATION 则不同，它把一台 ctrlX CORE 设备视为一个可扩展的软件平台。平台上同时存在操作系统、运行时、数据通信层、应用分发渠道和第三方应用，每一层都有自己的版本号、发布节奏和兼容边界。治理的对象因此从“一个固件”变成“一组相互约束的版本集合”。

理解这一点后，版本治理的目标也随之明确：不是让每个组件都升到最新，而是让一组版本在功能、接口和安全性上保持可验证的一致状态。

二、五个版本化对象及其角色

ctrlX OS 是运行在 ctrlX CORE 硬件上的实时操作系统，负责内核、实时调度、驱动与基础服务。它决定了设备能支持哪些运行时能力，是版本治理的底座。OS 版本通常以主版本加补丁形式发布，主版本变化可能引入内核或驱动接口调整，属于高风险变更。

ctrlX CORE 在治理语境中既指硬件型号，也指设备上的核心运行时与系统镜像。不同型号（如 X3、X5、X7）在算力、接口和可承载应用数量上存在差异，因此同一应用在不同 CORE 上的兼容性结论可能不同。CORE 的系统镜像版本与 OS 版本紧密绑定，升级时通常作为整体处理。

ctrlX Data Layer 是平台的数据通信中枢，提供统一的地址空间、类型系统和订阅/发布机制。应用之间不直接点对点耦合，而是通过 Data Layer 的节点路径交换数据。它的版本影响节点结构、数据类型和 API 行为，是应用兼容性的关键判断依据。

ctrlX Store 是应用的分发与授权渠道，负责应用包的上架、版本发布、许可证管理和更新推送。它本身也有版本，但其治理价值更多体现在“渠道策略”上：哪些应用允许自动更新、哪些必须锁定版本、许可证如何随版本迁移。

应用与固件 是最终承载业务功能的单元。应用以包形式安装，可独立于 OS 更新；固件则指设备底层或外设的固件版本。应用版本治理关注依赖声明与接口兼容，固件治理关注与 OS、驱动的匹配关系。

三、依赖方向与约束方向

图中左侧箭头表示依赖方向：上层为下层提供运行能力。应用依赖 Data Layer 的接口，Data Layer 依赖 CORE 的运行时，CORE 依赖 OS 的内核与驱动。这意味着当底层版本变化时，影响会向上传播。

右侧箭头表示约束方向：上层对下层可选版本形成限制。例如某个应用声明只兼容 Data Layer API v2，那么当 CORE 镜像升级导致 Data Layer 变为 v3 时，该应用就不能被简单视为兼容。约束方向是版本治理中做“兼容性判断”的核心依据。

实际治理中，最常见的错误是只沿依赖方向检查“能不能跑起来”，而忽略约束方向“接口语义是否仍然成立”。前者是启动级兼容，后者是行为级兼容，二者必须同时满足。

四、版本对象的治理属性对比

五、一个具体的兼容性判断示例

假设现场有一台 ctrlX CORE X5，当前状态为：OS 2.4、CORE 镜像 2.4、Data Layer API v2、某应用 App 3.1.0。现在计划把 OS 升级到 2.6，需要判断应用是否仍可运行。

判断过程分三步。第一步，查 OS 2.6 的发布说明，确认是否包含 Data Layer 的主版本变化。若仍为 API v2，则接口层无破坏性变更。第二步，查 App 3.1.0 的依赖声明，确认其声明的 Data Layer 版本范围是否覆盖 v2。第三步，查 CORE 镜像 2.6 是否支持 X5 型号，以及是否要求应用重新签名或重新授权。

若三步均通过，可判定为兼容升级；若第二步失败，则需要先升级应用到声明支持新 API 的版本，再执行 OS 升级。这个顺序不能颠倒，否则会出现“系统升上去了、应用起不来”的回滚困境。

六、治理角色的分工

把五个对象映射到治理角色上：OS 与 CORE 镜像属于“平台基线”，由设备维护方统一管理；Data Layer 属于“接口契约”，由平台方发布兼容性矩阵；Store 属于“分发策略”，由运维方定义更新规则；应用与固件属于“业务变更”，由应用负责人按需发布。四类角色对应四种不同的审批粒度和回滚策略，混在一起管理就会导致要么过度管控、要么失控。