第1章硬实时系统概述

一、硬实时系统概述

各位工程师朋友，咱们直接进入正题。硬实时系统，说白了就是「在规定时间内必须完成，晚一毫秒都不行」的系统。我做了十几年运动控制，见过太多因为实时性没做好导致设备撞机、工件报废的案例。今天咱们就把这块彻底讲透。

实时系统不是铁板一块。根据任务超时带来的后果，业内一般分成三类：

我遇到过不少工程师把软实时的方案直接搬到运动控制上，结果一跑高速就丢步。你想想看，伺服周期如果抖动了 100 微秒，电机位置可能就偏了几个脉冲。这就是硬实时和软实时的本质区别——硬实时系统必须保证最坏情况下的响应时间。

做运动控制这么多年，我总结硬实时系统就三个关键词：确定性、可预测性、低延迟。咱们一个一个说。

确定性意味着「每次执行的时间都一样」。不是平均时间，是最坏情况时间。我曾经调试一个 EtherCAT 主站，发现偶尔会有 200 微秒的抖动。查了三天，最后发现是网卡中断亲和性没设置好。嗯，这种坑踩过一次就记住了。

可预测性比确定性更进一步。它要求你能提前算出最坏情况下的执行时间。比如伺服周期是 125 微秒，那你的控制算法必须在 100 微秒内完成，留出 25 微秒的余量。我习惯在架构设计阶段就做 WCET（最坏情况执行时间）分析，而不是等代码写完了再调。

低延迟不是越低越好，而是「可接受的延迟上限」要足够低。举个例子：

我见过有人为了追求极致延迟，把中断优先级调得特别高，结果导致系统其他任务饿死。说白了，延迟要低，但更要均衡。

运动控制对实时性的要求，可以拆成三个维度来看：

伺服周期是运动控制的最底层心跳。目前主流伺服驱动器的电流环周期在 1~10 微秒，速度环 50~200 微秒。我建议你在选型时注意一点：伺服周期越短，对主站实时性要求越高。比如用 125 微秒的 EtherCAT 周期，你的主站必须保证每个周期都能在 100 微秒内完成数据收发。

核心原则：伺服周期决定了运动控制的最小时间粒度。周期越短，控制精度越高，但对系统实时性要求也越苛刻。

插补周期是 CNC 和机器人控制的核心。它负责把轨迹规划出来的位置点，按时序发送给各个轴。常见的插补周期有 500 微秒、1 毫秒、2 毫秒。我个人的经验是：

为什么？因为插补周期越长，轨迹的轮廓误差越大。你想想看，1 毫秒内机床可能走了 10 毫米，如果插补点没算准，加工出来的曲面就会有波纹。

IO 响应往往被忽视，但恰恰是出问题最多的地方。比如急停信号，从触发到伺服停止，整个链路必须在 1 毫秒内完成。我曾经遇到一个项目，急停信号走了 PLC 再转给驱动器，结果延迟了 5 毫秒，差点造成安全事故。

避坑指南：安全相关的 IO 响应，一定要走硬件直连或者专用安全总线。不要依赖软件逻辑去处理急停，因为软件可能被高优先级任务抢占。

下面这张图是我梳理的硬实时运动控制架构的核心逻辑。你可以把它当作整个课程的地图：

这张图把咱们今天讲的内容串起来了。从实时系统分类出发，到三大核心特征，再到运动控制的具体要求，最后落到架构设计的关键技术上。后面的课程会逐一展开每个模块。

个人建议：刚开始接触硬实时系统的朋友，不要一上来就追求极致性能。先把确定性做出来，再慢慢优化延迟。我见过太多人把系统调得飞快，但一遇到异常情况就崩了。稳，比快更重要。

好了，第一章的内容就到这里。硬实时系统的概念和运动控制的要求，咱们已经讲清楚了。下一章我会深入聊聊 RTOS 的选型策略，以及怎么给运动控制任务分配优先级。到时候见。

公众号:蓝海资料掘金营，微信deep3321