1. 实时系统概述
大家好，我是你们的嵌入式系统讲师。今天咱们开始第一讲——实时系统概述。说实话，这个主题我讲了十几年，每次都有新感悟。你想想看，一个系统如果连「准时」都做不到，那还谈什么可靠性？
1.1 实时系统的定义
实时系统，说白了就是「必须在规定时间内完成规定任务」的系统。注意，这里的关键词是「必须」和「规定时间」。不是越快越好，而是「准时」最重要。
我在项目中遇到过不少新手，他们以为实时系统就是「跑得快」。其实不然。一个实时系统，哪怕你处理速度再快，只要有一次没在规定时间内响应，那就是系统失效。
核心定义：实时系统是指那些计算结果的正确性不仅取决于逻辑结果，还取决于结果产生时间的系统。如果时间约束被违反，系统就算出错。
举个例子：汽车安全气囊的触发。从碰撞传感器检测到信号，到气囊弹出，必须在几毫秒内完成。你算得再准，晚了10毫秒，人已经撞上方向盘了——这系统就是失败的。
1.2 硬实时与软实时的区别
这里有个关键区分，我建议你牢牢记住。实时系统分两种：硬实时和软实时。
| 特性 | 硬实时 | 软实时 |
|---|---|---|
| 截止时间违反后果 | 系统崩溃或灾难 | 性能下降，但可接受 |
| 典型例子 | 飞行控制、心脏起搏器 | 视频播放、网络电话 |
| 时间确定性要求 | 100%保证 | 统计意义上的保证 |
| 设计方法 | 最坏情况分析 | 平均情况优化 |
硬实时系统：错过截止时间等于系统失败。我记得有一次调试卫星通信模块，一个定时任务晚了0.5毫秒，整个数据帧就丢了。那种场景下，没有「差不多」的说法。
软实时系统：偶尔错过截止时间，系统还能凑合用。比如你看视频，偶尔卡顿一下，虽然不爽，但不会出人命。嗯，这里要注意，软实时不等于「不实时」，只是容错性更强。
我的经验：判断一个系统是硬实时还是软实时，你就问一个问题：「如果这个任务晚了一毫秒，会死人吗？」会，就是硬实时；不会，大概率是软实时。
1.3 实时系统的应用场景
讲完理论，咱们看看实际。实时系统无处不在，我挑三个典型领域说说。
航空航天
这是硬实时的典型战场。飞行控制系统、导航系统、发动机控制……每一个任务都有严格的时间窗口。
我曾经参与过一个无人机飞控项目。那个系统里，传感器数据采集必须在1ms内完成，控制律计算必须在5ms内输出，否则无人机就会失控。你想想看，几千米高空，一个任务超时，后果是什么？
- 飞行控制：姿态调整、航向控制，周期通常为10-50ms
- 导航系统：GPS数据融合、惯性导航计算，要求微秒级同步
- 通信系统：数据链传输，必须保证实时性，否则指令延迟
工业控制
工业现场，实时系统是标配。PLC、DCS、机器人控制器……这些设备每天都在跟时间赛跑。
我记得有一次去工厂调试生产线。一个机械臂的抓取动作，从传感器触发到执行器响应，要求控制在2ms以内。为什么？因为传送带在高速运动，晚1ms，抓取位置就偏了，产品就废了。
工业控制中的典型实时任务：
- 传感器采样：周期1-10ms
- PID控制计算：周期0.5-5ms
- 通信总线（如CAN、EtherCAT）：微秒级同步
自动驾驶
这个领域最近很火。自动驾驶系统是典型的硬实时+软实时混合系统。
为什么说混合？你看：
- 硬实时部分：刹车控制、转向控制、安全气囊——这些必须100%准时
- 软实时部分：路径规划、环境感知——偶尔延迟几十毫秒，车还能开
我有个朋友在做自动驾驶的感知模块。他跟我说，最头疼的不是算法精度，而是「时间确定性」。一个目标检测算法，GPU算得快，但延迟抖动大；CPU算得稳，但速度慢。怎么平衡？这就是实时系统的艺术。
避坑指南：我曾经见过一个团队，把自动驾驶的感知任务跑在Linux上，结果因为调度延迟，导致障碍物检测晚了100ms。幸好是在测试场，不然后果不堪设想。记住：通用操作系统不等于实时系统！
小结
这一章我们讲了实时系统的定义、硬实时与软实时的区别，以及三个典型应用场景。说白了，实时系统的核心就一句话：在规定的时间内，做规定的事。
下一章，我们会深入讨论任务调度策略。到时候我会分享一些实际项目中的调度经验，包括怎么避免优先级反转——那个坑，我踩过不止一次。
好，今天就到这里。有什么问题，欢迎交流。
公众号:蓝海资料掘金营，微信deep3321