第2章时间隔离基础

第2章：时间隔离基础

各位同学，咱们今天聊聊时间隔离。说实话，这个主题在安全关键系统里，比空间隔离更容易被忽视。我见过不少项目，空间隔离做得滴水不漏，结果时间上一团糟——任务互相干扰，系统崩溃得莫名其妙。

时间隔离，说白了就是：每个分区在分配的时间窗口内，独占CPU资源，不受其他分区干扰。

你想想看，在一个ARINC 653系统里，可能有十几个分区同时运行。如果没有时间隔离，一个分区里的死循环，就能把整个系统拖垮。我当年在航电项目里就遇到过——一个显示分区的bug，导致飞控分区拿不到CPU时间，差点酿成事故。

时间隔离的核心机制，就是分区调度表。系统把时间切成一个个固定长度的窗口，每个窗口分配给一个分区。窗口到了，不管分区任务有没有完成，都必须让出CPU。这就是所谓的「硬实时」保证。

时间隔离的三大要素：

很多新手会问：空间隔离和时间隔离，到底哪个更重要？

我的回答是：两者缺一不可，就像飞机的两个翅膀。

空间隔离保护的是「数据」——你的内存不会被别人篡改。时间隔离保护的是「执行」——你的运行时间不会被别人抢占。光有空间隔离，一个恶意分区可以通过CPU耗尽攻击，让其他分区饿死。光有时间隔离，一个分区可以通过DMA直接访问别人的内存，数据安全无从谈起。

我习惯用一个比喻：空间隔离是「墙」，时间隔离是「门禁」。墙保证别人进不来你的房间，门禁保证你每天有固定的时间使用房间。两者配合，才能构建真正的安全隔离环境。

注意：空间隔离和时间隔离不是独立的。比如，一个分区在时间窗口内访问了非法内存，MMU会触发异常。这个异常处理的时间，会占用当前分区的时间窗口。如果处理时间过长，可能导致分区无法完成正常任务。所以，隔离设计必须综合考虑。

这里有个关键问题：时间窗口应该切多细？

我见过两种极端：

毫秒级调度：窗口长度在1ms~100ms之间。这是传统ARINC 653的典型做法。优点是调度开销小，系统稳定。缺点是响应延迟大，不适合高实时性任务。
微秒级调度：窗口长度在1μs~100μs之间。这是近年来高性能安全系统的趋势。优点是响应快，适合传感器采样、飞控计算等任务。缺点是调度开销大，对硬件定时器精度要求高。

我在一个无人机飞控项目里，就吃过粒度的亏。一开始用10ms的调度窗口，结果发现传感器数据采集总是滞后——因为传感器中断来了，但分区还没轮到运行。后来改成100μs的窗口，问题就解决了。但代价是CPU有5%的时间花在调度切换上。

我的建议：

嗯，这里要上点硬货了。时间隔离不是靠「感觉」来保证的，而是有严格的数学基础。

核心公式很简单：

对于分区P_i，其时间窗口长度为W_i，周期为T_i
则P_i的CPU利用率为：U_i = W_i / T_i

系统总利用率：U_total = Σ(W_i / T_i) ≤ 1

每个分区的最大响应时间R_i满足：
R_i = W_i + (调度抖动 + 上下文切换开销)

这个公式看起来简单，但实际应用时有很多坑。我举个例子：

假设有三个分区：

总利用率90%，看起来没问题。但实际调度时，如果分区A和分区B的窗口在时间上重叠，调度器需要决定谁先运行。这个「调度顺序」会影响每个分区的实际响应时间。

数学保证的关键点：

我曾经在一个项目中，只做了简单的利用率计算，就以为万事大吉。结果集成测试时，一个分区总是超时。查了三天才发现，是因为另一个分区频繁访问共享内存总线，导致这个分区的内存访问延迟增加了30%。从那以后，我每次做时间隔离分析，都会加上资源竞争模型。

避坑指南：

最后说一句：时间隔离的数学保证，不是一次性的。系统升级、增加分区、修改调度参数，都需要重新做分析。我习惯在每次版本发布前，跑一遍完整的时序验证脚本。虽然麻烦，但能避免很多线上事故。

好了，这一章就到这里。下一章咱们聊聊时间隔离的具体实现技术——分区调度器是怎么工作的。