第四章：软件架构设计：分区与隔离、时间与空间分区、ARINC 653标准简介
4.1 为什么我们需要分区？
各位同学，咱们先聊点实际的。你想想看，一个航电系统里，可能同时跑着飞控、导航、显示、通信……这些功能。如果它们都挤在一个CPU上，没有隔离，会怎样？
我见过一个真实的案例。某次试飞，一个非关键的显示任务出了bug，内存越界了。结果呢？飞控任务直接挂了。飞机差点失控。嗯，这就是没有分区的后果。
说白了，分区就是给每个任务一个「独立房间」。你住你的，我住我的。你房间着火了，不能烧到我这边来。这就是安全关键系统的核心思想——故障隔离。
核心原则：一个分区的故障，不能影响其他分区的正常运行。这是底线。
4.2 时间分区与空间分区
分区分两种：时间上的，和空间上的。咱们一个一个说。
4.2.1 空间分区
空间分区，说白了就是内存隔离。每个分区有自己的地址空间，不能乱窜。
我习惯用MMU（内存管理单元）来实现。硬件帮你盯着，分区A的代码想访问分区B的内存？MMU直接给你一个异常。干净利落。
这里有个坑，我踩过。有一次，我们用的RTOS对MMU配置有个小bug，导致两个分区共享了一段缓存。结果一个分区改了数据，另一个分区读到的还是旧值。排查了三天……嗯，从那以后，我对缓存一致性特别敏感。
注意：空间分区不仅仅是内存隔离。外设寄存器、DMA缓冲区、中断向量表，这些都要隔离。别漏了。
4.2.2 时间分区
时间分区，就是给每个分区分配固定的时间片。你跑你的，我跑我的，谁也别抢谁的CPU时间。
举个例子：
// 一个简单的时间分区调度表
// 每个分区分配固定的时间窗口
Partition A: 0ms - 10ms
Partition B: 10ms - 20ms
Partition C: 20ms - 30ms
// 然后重复这个周期为什么需要时间分区？因为有些任务对时间要求很苛刻。飞控任务必须在1ms内响应，你不能让一个显示任务把它堵了。
我建议，在设计时间分区时，一定要留有余量。我曾经遇到过一个项目，时间片算得死死的，结果后来加了一个小功能，整个调度表都得重排。教训啊。
小技巧：时间分区的切换开销要考虑进去。上下文切换、缓存刷新，这些都会吃掉时间。我一般预留5%-10%的余量。
4.3 ARINC 653标准简介
ARINC 653，说白了就是航电系统分区的「行业标准」。它定义了分区怎么搞、接口怎么弄、调度怎么做。
我个人觉得，ARINC 653最大的贡献，是把分区这件事标准化了。以前各家有各家的做法，兼容性很差。现在好了，大家都按这个来。
4.3.1 核心概念
ARINC 653里有两个核心概念：
- 分区（Partition）：一个独立的执行环境。有自己的内存、时间片、资源。
- 进程（Process）：分区内部的执行单元。一个分区可以有多个进程。
你想想看，这就像一栋楼（系统），里面有很多房间（分区），每个房间里可以住好几个人（进程）。房间之间是隔离的，但房间里的人可以互相交流。
4.3.2 分区间的通信
分区之间怎么通信？ARINC 653定义了两种方式：
| 通信方式 | 特点 | 适用场景 |
|---|---|---|
| 采样端口（Sampling Port） | 类似共享内存，每次读取最新值 | 传感器数据、状态信息 |
| 队列端口（Queuing Port） | 类似消息队列，先进先出 | 命令、事件、日志 |
我遇到过一个问题。有个项目用采样端口传飞控数据，但发送方和接收方的周期不一样。结果接收方有时读到的是旧数据。后来我加了一个时间戳，每次读数据时检查一下新鲜度。问题解决了。
关键点：分区间的通信必须经过内核（Hypervisor或RTOS）的管控。不能直接访问对方的内存。这是安全性的保障。
4.3.3 健康监控（Health Monitor）
ARINC 653还定义了一套健康监控机制。说白了，就是系统出问题时怎么办。
我习惯把健康监控分成三级：
- 进程级：某个进程挂了，重启它。
- 分区级：整个分区出问题了，重启分区。
- 系统级：系统崩溃了，切换到备份。
嗯，这里要注意。健康监控的响应时间是有要求的。你不能等飞机都掉下来了，才重启分区。我一般要求：进程级响应在10ms内，分区级在100ms内。
警告：健康监控本身不能成为单点故障。我曾经见过一个设计，健康监控模块自己挂了，整个系统没人管了。后来我们给健康监控也做了冗余。
4.4 实际项目中的经验
说了这么多理论，咱们聊聊实际。
我记得有一次做项目，客户要求用ARINC 653。我们选了一个商业的RTOS，支持分区。结果发现，它的分区切换开销比预期大很多。我们算的时间片是10ms，但切换一次就要0.5ms。五个分区切换一轮，5ms就没了。一半的时间花在切换上，这谁受得了？
后来怎么解决的？我们调整了时间片大小，从10ms改成50ms。切换次数少了，开销就降下来了。但代价是响应时间变长了。嗯，这就是工程上的权衡。
我建议，在设计初期，一定要做性能评估。别等到代码写完了才发现问题。那时候改起来，成本就高了。
我的习惯：先搭一个最小系统，跑一下分区切换的基准测试。看看实际开销是多少。然后再根据这个数据，设计时间分区表。
4.5 总结
好了，咱们今天聊了不少。总结一下：
- 分区是安全关键系统的基石。没有分区，就没有故障隔离。
- 空间分区靠MMU，时间分区靠调度表。两者缺一不可。
- ARINC 653是行业标准，定义了分区、通信、健康监控等机制。
- 实际项目中，一定要做性能评估，留有余量。
下一章，咱们聊聊实时操作系统（RTOS）在航电系统中的应用。到时候我会讲讲怎么选型、怎么配置、怎么避免常见的坑。嗯，那又是另一个故事了。