1. 实时系统基础：什么是实时系统、硬实时与软实时的区别、运动控制中的实时性要求
1.1 到底什么是实时系统？
先问大家一个问题：你觉得「快」和「实时」是一回事吗？
很多人刚入行时会搞混。我当年也犯过这个错。有一次做伺服驱动器调试，我拍着胸脯说「这系统响应够快，肯定是实时的」。结果被老工程师一句话问住了：「快是快，但你能保证每次都在规定时间内完成吗？」
嗯，这就是关键。
实时系统，不是「快」的系统，而是「可预测」的系统。
说白了，实时系统的核心就一条：必须在规定的时间窗口内，完成规定的任务。晚一毫秒，就是失败。哪怕你平时跑得再快，只要有一次超时，系统就算出问题。
我习惯用一个比喻来解释：
- 普通系统像快递员——今天送到就行，早一点晚一点无所谓
- 实时系统像心脏起搏器——每次跳动必须准时，不能早也不能晚
在运动控制里，这个区别尤其明显。你想想看，一个机械臂如果某次轨迹插补晚了5毫秒，会发生什么？轻则抖动，重则撞机。
实时系统的三个核心特征：
- 确定性（Determinism）：任务执行时间可预测，不是靠运气
- 及时性（Timeliness）：必须在截止时间前完成
- 可靠性（Reliability）：系统不能因为偶尔的异常就崩溃
1.2 硬实时 vs 软实时——差之毫厘，失之千里
这里我要重点讲一下。很多工程师干了几年，对这两个概念还是模模糊糊的。
硬实时（Hard Real-Time）：
- 错过截止时间 = 系统故障
- 后果可能是灾难性的
- 例子：安全气囊控制器、飞行控制系统、伺服驱动器位置环
软实时（Soft Real-Time）：
- 偶尔超时还能接受，但性能会下降
- 后果是用户体验变差，但不至于出事故
- 例子：视频播放、网络电话、机器人示教器界面
我曾经在一个项目中吃过亏。当时做多轴同步控制，我用了Linux + RT-Preempt补丁，觉得软实时就够了。结果在高速加工时，偶尔一次调度延迟导致两个轴不同步，工件直接报废。那次之后，我学乖了——运动控制的核心环路，必须走硬实时。
避坑指南：
我曾经见过有人把Windows + 定时器中断当成硬实时来用。结果机器一跑高速就出问题。记住：非实时操作系统 + 高优先级线程 ≠ 实时系统。真正的硬实时，需要从硬件到软件全链路保证。
1.3 运动控制中的实时性要求——到底要多「实时」？
这个问题，我每次培训都会被问到。答案其实很简单：取决于你的控制周期。
运动控制系统的典型层级和实时要求如下：
| 层级 | 典型周期 | 实时类型 | 说明 |
|---|---|---|---|
| 电流环 | 1μs - 10μs | 硬实时 | FPGA或专用DSP实现，软件几乎无法做到 |
| 速度环 | 50μs - 200μs | 硬实时 | 必须用RTOS或实时扩展 |
| 位置环 | 200μs - 1ms | 硬实时 | 主流工业以太网总线周期 |
| 轨迹规划 | 1ms - 10ms | 软实时 | 偶尔抖动可以接受 |
| 人机交互 | 10ms - 100ms | 非实时 | 普通Linux/Windows即可 |
你看，越靠近电机，实时性要求越苛刻。我个人的经验是：位置环以上的层级，软实时还能凑合；位置环及以下，必须硬实时。
一个小技巧：
判断一个系统是不是真实时，我习惯看它的「最差情况响应时间」（Worst-Case Response Time, WCRT）。别只看平均延迟——平均1μs，最差100μs的系统，在运动控制里就是定时炸弹。
1.4 实时系统的核心逻辑——一张图看懂
下面这张图，是我做培训时必画的。它把实时系统、硬实时/软实时、运动控制要求串在了一起：
1.5 一个真实的例子——为什么实时性这么重要？
我参与过一个六轴机器人的项目。当时用的EtherCAT总线，周期1ms。理论上够用，对吧？
但实际跑起来，发现偶尔会有一次总线抖动，延迟到了1.3ms。就这0.3ms的偏差，导致机器人末端轨迹出现了肉眼可见的抖动。客户直接拒收。
后来怎么解决的？我们把控制周期从1ms降到了500μs，同时把位置环从软实时改成了硬实时。代价是CPU占用率从40%飙升到85%。但效果立竿见影——抖动消失了。
这个案例告诉我一个道理：在运动控制里，实时性不是「锦上添花」，而是「生死存亡」。
总结一下本章的核心要点：
- 实时系统 = 可预测，不是快
- 硬实时：错过截止时间 = 事故；软实时：偶尔超时还能忍
- 运动控制中，电流/速度/位置环必须硬实时，轨迹规划可以软实时
- 判断实时性，看最差情况响应时间（WCRT），别看平均值
嗯，这一章就到这里。实时系统的基础打牢了，后面讲测试方法时你才能理解为什么有些工具测出来不准，为什么有些指标才是关键。
公众号:蓝海资料掘金营，微信deep3321