📚 课程目录第2章 ctrlX CORE硬件与系统架构

2. ctrlX CORE硬件与系统架构

ctrlX CORE 是 ctrlX AUTOMATION 平台的控制核心，它把工业 PC 的算力、PLC 的实时性与 App 化的软件生态放在同一台设备上。理解它的硬件与系统架构，关键不是记住某一款型号的参数，而是建立一条判断链：应用需要多少实时算力、多少非实时算力、多少内存与存储，再决定选哪一档 CORE、如何划分内核、如何配置系统实时性。本节围绕这条判断链展开。

一、ctrlX CORE 的硬件形态与型号选型

ctrlX CORE 目前主要有三类形态：ctrlX CORE 标准型（DIN 导轨安装，无风扇，适合控制柜内）、ctrlX CORE Plus（性能更高，接口更丰富，可带更多轴与视觉/边缘计算负载）、以及ctrlX CORE 嵌入式/紧凑型（用于空间受限或成本敏感场景）。选型时不要只看 CPU 型号，而应看四个维度：

实时轴数与运动控制负载：需要同步插补的轴数、插补周期（如 1 ms、0.5 ms、250 µs）直接决定实时内核的 CPU 占用。
非实时应用负载：是否运行 ctrlX OS 上的 App（如 ctrlX Data Layer、OPC UA、视觉、AI 推理、Web HMI）。
接口需求：EtherCAT、PROFINET、EtherNet/IP、串口、USB、显示输出、现场总线模块数量。
环境与认证：工作温度、防护等级、是否需满足功能安全（如 ctrlX SAFETY）或特定行业认证。

一个常见的教学示例：某包装设备需要 8 轴 EtherCAT 同步，插补周期 1 ms，同时运行 OPC UA 服务器与一个轻量视觉检测 App。此时标准型 ctrlX CORE 通常可以满足；若轴数增加到 16 轴、周期缩短到 500 µs，并叠加 AI 推理，则应考虑 ctrlX CORE Plus。这里的“8 轴 / 1 ms / 16 轴 / 500 µs”是示例性假设，用于说明选型逻辑，实际应以 Rexroth 官方选型工具与实测负载为准。

二、实时内核与多核分配

ctrlX CORE 采用 Linux 基础系统 + 实时扩展的架构。实时性不是“整个系统都实时”，而是通过CPU 隔离（isolcpus）与实时调度策略（SCHED_FIFO），把一部分 CPU 核心专门留给实时任务，其余核心运行 Linux 通用任务与 App。典型的多核分配思路如下：

Core 0：Linux 系统核心，处理中断、网络、文件系统、App 调度。
Core 1：实时内核，运行 PLC 运动控制任务、EtherCAT 主站循环。
Core 2~N：按需分配给非实时 App、视觉、数据层服务或冗余实时任务。

在 ctrlX OS 中，可以通过系统配置或 App 的资源配置界面查看和调整 CPU 亲和性。判断实时性是否达标，不能只看“能不能跑”，而要看抖动（jitter）：在 1 ms 周期下，实时任务的实际执行时间波动应远小于周期，通常要求抖动在几十微秒量级。若抖动接近或超过周期，说明实时核心被非实时负载干扰，需要重新隔离核心或降低非实时 App 的优先级。

三、内存与存储配置

内存与存储的配置原则是“实时任务优先、非实时任务可回收”。ctrlX CORE 的内存分为实时任务栈、Linux 内核与缓存、App 运行内存三部分。选型时建议：

实时任务内存：按轴数、插补周期、I/O 映像大小估算，通常预留 256 MB~1 GB。
App 内存：每个 ctrlX App 按其文档要求预留，视觉/AI 类 App 可能单实例就需要 1~4 GB。
存储：系统盘建议使用工业级 eMMC 或 SSD，容量至少 32 GB；若需本地记录数据、日志或容器镜像，应选择 64 GB 以上，并关注写入寿命（TBW）。

一个实用的检查方法是：在目标负载下运行 free -m 与 df -h，观察可用内存与磁盘余量。若可用内存长期低于 15%，或磁盘写入频繁触发 swap，说明配置偏紧，应升级型号或减少非实时 App。

四、操作系统与实时性保障

ctrlX CORE 运行 ctrlX OS，它基于 Linux，提供实时内核、容器化 App 运行环境、ctrlX Data Layer 与安全机制。实时性保障主要来自四层：

内核层：实时补丁与 CPU 隔离，保证实时任务不被普通任务抢占。
调度层：实时任务使用 SCHED_FIFO，优先级高于普通进程。
网络层：EtherCAT 主站使用专用网口与实时驱动，避免通用网络栈的延迟抖动。
应用层：App 通过 ctrlX Data Layer 访问数据，不直接干扰实时任务。

实际调试时，可以观察 ctrlX CORE 的系统负载与实时任务统计。若发现周期超时，优先检查：是否有非实时 App 占用了实时核心、EtherCAT 从站是否掉线、网络是否出现广播风暴。判断依据是实时任务的最大执行时间与周期超时计数，而不是平均执行时间。

五、配置检查清单（可直接使用）

在完成选型与系统配置后，建议按以下清单逐项确认。该清单为示例性检查表，字段可根据项目实际增删：

检查项	判断依据	示例目标值
实时核心隔离	isolcpus 是否包含实时核心	Core 1 已隔离
实时任务优先级	是否使用 SCHED_FIFO	优先级高于普通进程
周期抖动	最大执行时间与周期比值	抖动 < 50 µs（1 ms 周期）
内存余量	free -m 可用内存	可用 > 15%
存储余量	df -h 根分区使用率	使用率 < 80%
EtherCAT 从站	从站是否全部在线	无掉线、无丢帧

提示：ctrlX CORE 的实时性不是“选最贵的型号”就能保证，而是“选对型号 + 分对核心 + 配好优先级”三者共同作用。建议在样机阶段就用目标负载做一次抖动测试，再决定是否升级型号或调整 App 部署。

注意：不要把非实时 App 部署到实时核心上，也不要在实时核心上运行通用网络服务。若发现周期超时，优先排查实时核心是否被其他进程占用，而不是直接提高任务优先级。

总结来说，ctrlX CORE 的硬件与系统架构可以理解为一条从“应用需求”到“实时保障”的映射链：先根据轴数、周期、App 负载和接口确定型号，再通过 CPU 隔离与调度策略划分实时与非实时核心，最后用内存、存储和四层实时机制保证系统在目标负载下稳定运行。掌握这条链，就能在选型、配置和排障时有据可依。