1. 航空航天嵌入式系统与VxWorks概述

航空航天嵌入式系统与通用工业控制或消费电子最大的区别,在于它必须在“不可维修、不可重启、环境极端、后果严重”的约束下长期正确运行。一颗在轨卫星一旦发射,软件缺陷无法通过现场插拔电源解决;飞行控制计算机在强振动、宽温、辐照和电磁干扰下,仍要在毫秒级周期内完成采样、控制律计算与舵面/推力输出。因此,这类系统的核心不是“功能能不能实现”,而是“在最坏情况下能否按时、按确定逻辑、可验证地实现”。实时操作系统(RTOS)正是承载这一要求的软件基座,而VxWorks是其中在航天器、飞行控制与机载设备中被长期验证的一类代表。

一、VxWorks在航天器、飞行控制与机载设备中的角色

从系统分层看,航空航天嵌入式软件通常分为应用层、任务/中间件层、RTOS内核层和板级支持/硬件层。VxWorks处在承上启下的位置:向下通过BSP(板级支持包)管理处理器、存储器、中断控制器、总线与定时器;向上提供多任务调度、任务间通信、中断管理、内存管理、时间管理和文件/网络等基础服务。应用软件不直接操作寄存器,而是以任务、信号量、消息队列、看门狗等抽象完成控制逻辑。

在航天器上,VxWorks常见于星务管理计算机、姿态与轨道控制计算机、有效载荷控制器。典型任务包括:以固定周期采集陀螺、星敏感器、磁强计数据;运行姿态确定与卡尔曼滤波;输出动量轮、磁力矩器或推力器指令;同时执行遥测采集、遥控指令解析、故障检测与安全模式切换。在飞行控制中,它承担周期性的控制律解算与余度管理,保证从传感器到作动器的信号链在确定时限内闭合。在机载设备中,它用于任务计算机、显示控制、数据链管理和传感器管理,强调分区隔离、健康监控与可适航证据链。

这些场景对RTOS提出的不是单一“快”,而是一组可度量、可验证的实时指标。下面这张图把VxWorks在系统中的位置、典型任务链与关键实时指标放在同一张关系图中,便于建立整体认识。

VxWorks在航空航天嵌入式系统中的位置与实时指标关系 应用层 姿态确定与滤波 控制律解算 遥测/遥控处理 故障检测与安全模式 余度管理与表决 数据链/载荷管理 VxWorks RTOS内核 优先级抢占调度 任务间通信(队列/信号量) 中断管理与延迟处理 时间管理与周期定时 内存保护与分区 看门狗与健康监控 文件/网络/总线服务 BSP与硬件层 处理器与时钟 中断控制器 存储器与EDAC 1553B/CAN/串口 传感器与作动器接口 看门狗与复位电路 核心实时指标 中断延迟 µs级,最坏可界定 任务切换时间 与优先级相关 周期抖动 Jitter越小越确定 CPU余量 最坏工况下仍有余量 可预测性 WCET可分析 可靠性 容错与恢复能力 典型信号链: 传感器采样 → 中断/周期任务 → 滤波与控制律 → 作动器指令 → 遥测回传 闭环时限约束

二、实时操作系统的核心指标:从“快”到“可证明的确定”

评价航空航天RTOS,不能只看主频或平均响应。工程上更关注以下可度量指标:

  • 中断延迟:从硬件中断发生到中断服务程序第一条指令执行的时间。它决定系统对突发事件的响应下限,通常要求在微秒级,并且最坏值可界定。
  • 任务切换时间:高优先级任务就绪后,内核完成上下文保存与恢复的时间。VxWorks采用优先级抢占调度,切换时间与任务数量和优先级层次相关,需在目标板上实测。
  • 周期抖动(Jitter):周期任务实际唤醒时刻与理论时刻的偏差。控制律对抖动敏感,例如1 kHz控制周期若抖动过大,等效于采样时刻不确定,会降低相位裕度。
  • 最坏执行时间(WCET):任务或中断路径在最坏输入下的执行时间。它是可调度性分析的基础,不能只用平均值代替。
  • CPU余量:最坏工况下仍保留的计算能力,用于应对模式切换、故障恢复和未来功能扩展。
  • 可预测性与可靠性:包括内存保护、分区隔离、看门狗、错误注入后的恢复行为,以及能否提供可追溯的测试证据。

这些指标之间存在耦合。例如,为了降低中断延迟,可能把处理逻辑放在中断服务程序中,但这会拉长中断占用时间,影响其他中断响应;为了降低抖动,可能提高周期任务优先级,但会挤压低优先级遥测任务的CPU余量。因此,实时设计本质上是“在约束下做权衡”,而不是追求单项最优。

三、课程项目背景:一个可运行的星载姿态控制示例

本课程以一个简化的星载姿态控制计算机为项目背景,贯穿后续章节。项目设定为:目标板采用双核处理器,VxWorks 7内核,控制周期1 ms(1 kHz),通过1553B总线接收星敏感器和陀螺数据,通过PWM接口驱动动量轮,同时以10 Hz周期向遥测系统发送状态帧。项目不追求真实卫星的全部复杂度,但保留关键实时结构:周期任务、中断、任务间通信、看门狗、故障检测与安全模式。

一个典型的周期任务伪代码如下,用于说明VxWorks任务的基本形态:

void attitudeControlTask(void)
{
    while (1) {
        /* 等待1ms周期信号量,由定时器中断释放 */
        semTake(cycleSem, WAIT_FOREVER);

        /* 1. 读取传感器数据(来自1553B中断处理后的缓冲区) */
        readSensorData(&gyro, &starTracker);

        /* 2. 姿态确定与滤波 */
        attitudeEstimate(&gyro, &starTracker, &attitude);

        /* 3. 控制律解算 */
        controlLaw(&attitude, &torqueCmd);

        /* 4. 输出到动量轮 */
        writeActuator(&torqueCmd);

        /* 5. 喂看门狗并更新健康计数 */
        wdFeed();
        healthCounter++;
    }
}

这段代码的关键不在语法,而在于它体现了实时系统的几个约定:周期由定时器中断和信号量保证;传感器数据在中断与任务之间通过缓冲区传递;控制律必须在下一个周期到来前完成;看门狗用于检测任务是否卡死。后续章节会逐步展开BSP配置、任务优先级设计、1553B驱动、WCET测量和故障注入测试。

学习建议:在进入具体开发前,先建立“时间账本”意识。对每个周期任务,记录其触发时刻、最坏执行时间、截止时间和实际抖动。只有把这些量测出来,实时性才从口号变成可验证的工程结论。
常见误区:把“平均响应快”等同于“实时性好”。航空航天系统关注的是最坏情况下的行为,平均值再小,只要最坏值超出截止时间,系统就是不可接受的。

本章后续内容将围绕这个项目背景展开:先理解VxWorks的启动流程与BSP,再进入任务、中断、通信、时间管理,最后完成一个可测量、可复现的姿态控制闭环。读者应始终把“确定性与可验证性”作为判断设计优劣的第一标准。