📚 课程目录第3章 INTEGRITY系统架构与集成对象分析

3. INTEGRITY系统架构与集成对象分析

INTEGRITY 是一款面向高安全、高可靠嵌入式场景的实时操作系统，其架构设计的核心思想是：把“必须绝对可信”的部分压缩到尽可能小，把“可能出错”的部分隔离在受控容器中。理解 INTEGRITY 的集成与配置管理，必须先看清它的四层基本结构——微内核、地址空间与分区、任务与线程模型，以及在此之上需要被管理的核心集成对象。本节围绕这四层展开，并给出集成对象清单与配置样例。

一、微内核：可信计算基的最小化

INTEGRITY 的微内核（Microkernel）是整个系统的可信计算基（TCB）。它只负责四件事：分区调度、地址空间隔离、进程间通信（IPC）和中断/异常的基础接管。文件系统、网络协议栈、设备驱动、甚至部分运行时库，都不在内核中，而是作为独立的分区或任务运行在用户态。这样做的直接收益是：TCB 代码量小、可被形式化验证，且任一用户态组件崩溃不会直接破坏内核。

微内核对外提供的核心抽象是“分区（Partition）”和“任务（Task）”。分区是资源隔离的单位，任务是被调度的单位。内核通过一张静态配置表（通常由 XML 或 INTEGRITY 专用的 .int 配置文件描述）在启动时建立所有分区、地址空间、任务和通信通道。这意味着：系统的集成关系在编译/链接阶段就已确定，而不是运行时可随意变更的。这正是配置管理在 INTEGRITY 项目中格外重要的原因。

二、地址空间与分区：隔离的物理边界

INTEGRITY 使用 MMU（内存管理单元）为每个分区建立独立的地址空间。分区内的任务共享该分区的地址空间，分区之间默认不可见。地址空间的划分由配置文件中的 memory region 描述，典型字段包括：起始地址、大小、访问权限（读/写/执行）、是否可缓存。例如，一个典型的航空电子配置中，分区 A 被分配 0x8000_0000 起、2 MB 的只读代码段和 1 MB 的可读写数据段；分区 B 被分配 0x8100_0000 起、4 MB 的独立空间。两者物理地址不重叠，MMU 页表在启动时由内核根据配置生成。

分区之间若需要通信，必须显式声明通道（Channel）。通道是内核管理的 IPC 端点，配置中需指定源分区、目标分区、消息大小上限、方向（单向/双向）以及是否允许阻塞。未声明的通道在运行时无法建立，这从架构上杜绝了“意外耦合”。

三、任务与线程模型：调度与并发

在分区内部，任务（Task）是调度的基本单位。每个任务拥有独立的栈、优先级和周期/时限参数。INTEGRITY 支持两种主要调度策略：固定优先级抢占调度和基于时间窗口的分区调度（ARINC 653 风格）。分区调度保证每个分区在预定义的时隙内运行，时隙之外即使有高优先级任务也无法抢占其他分区的 CPU 时间。

任务之间通过信号量、事件标志和消息队列同步。线程（Thread）在 INTEGRITY 中通常指任务内的执行流，共享任务栈或使用独立栈。配置时需要明确：任务名、所属分区、优先级、栈大小、周期、执行时间预算、入口函数。这些参数直接决定系统能否满足实时性要求，也是集成阶段最容易被改错、最需要版本控制的内容。

四、系统集成中需要管理的核心对象

基于上述架构，INTEGRITY 项目的配置管理对象可以归纳为五类：

镜像（Image）：最终烧录到目标板的二进制文件，由微内核、各分区可执行体、配置表链接而成。镜像的版本必须与配置表版本、各分区二进制版本严格对应。
库（Library）：包括 INTEGRITY 提供的系统库（如 POSIX 兼容层、文件系统客户端库）和项目自研库。库的 ABI 版本变化会直接影响分区可执行体的兼容性。
配置文件（Configuration）：描述分区、地址空间、任务、通道、调度的 XML/.int 文件。它是“集成关系的唯一真相来源”，任何架构变更都应先改配置、再改代码。
驱动（Driver）：在 INTEGRITY 中通常以用户态任务形式存在，通过内核暴露的硬件访问接口操作外设。驱动的版本、所依赖的内核接口版本、以及它所属的分区，都需要纳入管理。
构建脚本与工具链：交叉编译器版本、链接脚本、镜像打包工具的参数，同样影响最终镜像的可复现性。

下面这张图展示了从配置源到最终镜像的集成对象关系，以及各对象之间的依赖方向。

五、配置样例与集成检查要点

下面给出一个简化的 INTEGRITY 配置片段（XML 风格），用于说明分区、任务和通道是如何被声明的。该样例属于教学示例，参数为合理假设值，不代表任何真实项目。

<Partition name="NavDisplay">
  <Memory start="0x80000000" size="2M" perms="RX"/>
  <Memory start="0x80200000" size="1M" perms="RW"/>
  <Task name="RenderTask" priority="10" stack="64K"
        period="20ms" budget="8ms" entry="render_main"/>
  <Task name="InputTask" priority="20" stack="32K"
        period="10ms" budget="3ms" entry="input_main"/>
  <Channel name="ToFMS" direction="out" maxMsg="256"
           target="FlightMgmt"/>
</Partition>

<Partition name="FlightMgmt">
  <Memory start="0x81000000" size="4M" perms="RWX"/>
  <Task name="ControlTask" priority="5" stack="128K"
        period="10ms" budget="5ms" entry="control_main"/>
  <Channel name="FromNav" direction="in" maxMsg="256"
           source="NavDisplay"/>
</Partition>

集成阶段应重点核对以下内容：分区地址区间是否重叠；每个任务的周期与预算之和是否超出分区时隙；通道的源与目标是否成对声明；库的 ABI 版本是否与分区可执行体编译时一致；驱动所依赖的内核接口版本是否与当前微内核匹配。这些检查项一旦遗漏，往往在目标板启动后才暴露，排查成本远高于在配置阶段拦截。

配置表是 INTEGRITY 集成关系的“单一真相来源”。建议将配置文件、各分区源码、库版本、驱动版本统一纳入版本库，并用构建脚本自动生成镜像版本号，确保任何一次镜像都能追溯到确切的配置与代码组合。

总结来看，INTEGRITY 的架构把“隔离”和“确定性”放在首位：微内核提供最小可信基础，分区与地址空间提供物理隔离，任务与线程模型提供可预测的调度，而镜像、库、配置文件、驱动和构建工具链则构成集成管理的核心对象集合。掌握这四层结构与五类对象之间的依赖关系，是后续进行配置项识别、版本控制和集成验证的基础。