第1章实时系统概述

1、实时系统概述

大家好，我是你们这堂课的主讲人。做了十几年嵌入式系统，我接触过的实时系统项目少说也有几十个了。今天咱们先聊聊最基础的东西——到底什么是实时系统？

很多人一听「实时」两个字，第一反应就是「快」。其实不完全对。实时系统的核心不是快，而是确定性。说白了，就是系统必须在规定的时间内完成规定的任务。晚了一毫秒，可能就出大事了。

我习惯这样定义：实时系统是指那些计算结果的正确性不仅取决于逻辑结果，还取决于结果产生时间的系统。

举个例子。你写一个计算器程序，算1+1=2。你按了等号键，过了5秒钟才显示结果。结果是对的，但你会觉得这计算器坏了。为什么？因为响应时间太长了。这就是实时性的体现。

在工业控制里，情况更极端。一个PID控制回路，采样周期是1ms。你必须在1ms内完成采样、计算、输出。哪怕你算得再准，只要超时了，控制器输出就是错的。设备可能就失控了。

核心要点：实时系统 = 逻辑正确 + 时间正确。两者缺一不可。

这里有个关键概念，大家一定要搞清楚——硬实时和软实时的区别。我在项目里见过不少工程师把这两个搞混，结果设计出来的系统要么过度设计浪费成本，要么根本满足不了需求。

硬实时系统，错过截止时间就是事故。我做过一个航空发动机控制的项目，控制周期是5ms。有一次因为中断优先级配置错了，导致一个控制任务延迟了2ms。结果呢？发动机喘振了。还好是在测试台上，不然后果不堪设想。

软实时系统就宽容多了。你看视频卡了一下，顶多骂两句，不会出人命。但也不能太离谱，对吧？

我的经验：设计前先问清楚——这个任务错过截止时间会怎样？如果答案是「会死人」，那就是硬实时。如果答案是「用户体验差一点」，那就是软实时。别自己瞎猜，一定要和需求方确认。

说到应用场景，其实你身边到处都是实时系统。我挑三个典型的说说。

这是硬实时的典型代表。飞行控制系统、导航系统、发动机控制系统……每一个都是硬实时。我记得有个项目是做卫星姿态控制的。卫星在轨道上，姿态调整必须在指定窗口内完成。窗口过了，卫星就偏了。地面站得花更多燃料去纠正。燃料是有限的，卫星寿命就缩短了。

航空航天里的实时系统，通常采用时间触发架构。所有任务都在固定的时间片里执行。这样可预测性最强。我参与过一个ARINC 653标准的航电系统，分区调度就是典型的时间触发。每个分区固定分配时间窗口，谁也别抢谁的。

工业控制是实时系统最大的应用领域之一。PLC、DCS、运动控制器……这些都是实时系统。我最早接触实时系统就是在工厂里做PLC编程。那时候用的还是8位单片机，主频低得可怜。但控制周期必须做到10ms以内。

工业控制的特点是：周期性任务多。采样、计算、输出，周而复始。调度策略上，通常用速率单调调度（RMS）。周期越短的任务，优先级越高。这个后面章节会详细讲。

嗯，这里要注意一点。工业现场干扰大，实时系统必须考虑容错。我曾经遇到过传感器信号被电机干扰的情况。如果系统没有容错机制，一个错误数据就能让整个产线停机。

自动驾驶是近几年最火的实时系统应用。它融合了感知、决策、控制三个环节。每个环节都有严格的实时要求。

感知环节：摄像头、激光雷达、毫米波雷达的数据必须在几十毫秒内融合完成。决策环节：路径规划、行为决策必须在百毫秒级完成。控制环节：转向、制动、加速的控制周期通常在10ms以内。

我有个朋友在做自动驾驶的域控制器。他跟我说，最头疼的不是算法，而是调度。传感器数据来了，你得保证在指定时间内处理完。处理不完，车就撞了。这是典型的硬实时。

避坑提醒：我曾经见过一个团队，在自动驾驶项目里用了Linux做实时扩展。结果发现中断响应时间不稳定，有时候能到几十毫秒。这在工业控制里还能忍，在自动驾驶里就是致命问题。后来他们换成了RTOS。所以，选型时一定要考虑最坏情况下的响应时间，而不是平均时间。

说了这么多，我画了一张图，把实时系统的核心知识串起来。你看一眼，心里就有谱了。

这张图把实时系统的核心要素都串起来了。定义、分类、应用场景、核心挑战，四个维度。你记住一句话就行：实时系统 = 在正确的时间做正确的事。

好了，第一章就到这里。内容不多，但都是基础。后面的章节我们会深入调度策略、优先级反转、死锁这些实战内容。到时候我会拿我踩过的坑给大家当反面教材，保证比教科书有意思。

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