1. 飞控计算机与硬实时操作系统的核心逻辑1.1 为什么飞控场景对“硬实时”如此苛刻飞控计算机跟咱们平时用的手机、电脑完全是两码事。手机卡一下顶多就是滑动不跟手你骂两句继续用飞控计算机要是卡一下那可能就是姿态失控、舵面响应延迟后果不堪设想。所以在这个领域里“实时”不是一个性能指标而是一条生死线。所谓硬实时操作系统Hard RTOS核心定义是系统必须在确定的时间窗口内完成响应超出这个窗口哪怕一毫秒都算任务失败而且这个失败是不可接受的。注意这里的关键词是“确定”不是“快”。快和确定是两回事——一个系统平均响应只要1微秒但偶尔会飙到50毫秒这在飞控里就是不合格的另一个系统响应稳定在200微秒抖动不超过5微秒这才是硬实时系统追求的目标。我经常用一个类比来解释硬实时系统就像高铁时刻表每一班车必须准点到达晚点一秒整个调度就乱了而软实时系统更像公交车晚个三五分钟大家也能接受。飞控计算机要的就是高铁级别的确定性。那飞控计算机到底要处理哪些任务典型的有传感器数据采集陀螺仪、加速度计、大气数据、控制律解算姿态控制、导航计算、舵机指令输出、余度管理多通道表决、健康监控与故障隔离。这些任务的周期从1毫秒到几十毫秒不等而且有严格的优先级和执行顺序要求。比如姿态控制回路通常要求1到10毫秒的周期抖动必须控制在微秒级否则控制律的相位裕度就会被吃掉飞行品质直接下降。1.2 硬实时操作系统在飞控中的角色定位很多人以为RTOS就是个“调度器”把任务排排队就完事了。实际上在飞控计算机里RTOS承担的角色要重得多它更像是一个资源仲裁者加时间守门人。具体来说它要干这几件事第一任务调度确保高优先级的控制任务在截止时间前拿到CPU第二时间管理提供高精度的时钟节拍和定时器让周期性任务严格按节拍执行第三资源隔离防止某个低优先级任务或者故障任务抢占关键资源第四通信管理管理任务间的数据交换保证数据一致性和时序正确第五故障处理在检测到异常时快速响应触发余度切换或者安全模式。这里有个容易被忽略的点飞控计算机的RTOS通常不是通用RTOS直接拿来用的而是经过深度定制和认证的。因为飞控软件要满足DO-178C标准根据软件等级A到E级的不同对RTOS的要求也完全不同。A级软件要求RTOS本身也要经过严格的验证包括需求追溯、覆盖率分析、最坏执行时间WCET分析等等。这就意味着你不能随便拿个开源RTOS就往上装得看它有没有对应的认证包和证据链。1.3 从热搜词看行业关注点的变化最近看到一些热搜词挺有意思比如“rtos手表 开源”、“rtos项目推荐”说明现在很多开发者开始从消费电子或者创客项目切入RTOS学习。这是个好现象但也要提醒一句消费级RTOS和飞控级RTOS之间的差距比很多人想象的要大得多。消费级RTOS关注的是低功耗、易移植、生态丰富飞控级RTOS关注的是确定性、安全性、可认证性。两者的设计哲学几乎相反。比如FreeRTOS在创客圈很火但它的调度器在某些边界条件下抖动较大也没有ARINC 653那种分区隔离机制直接拿来做飞控是不现实的。当然作为学习RTOS原理的入门平台它还是很合适的。2. 飞控计算机常用硬实时操作系统技术拆解2.1 ARINC 653分区机制飞控RTOS的基石说到飞控RTOSARINC 653是绕不开的话题。这个标准最初是为航空电子系统定义的核心思想是时间和空间分区。时间分区是什么意思就是把CPU时间切成一个个固定的时间窗口每个分区只能在分配给自己的窗口内运行。比如一个周期是100毫秒分区A拿20毫秒分区B拿30毫秒分区C拿50毫秒严格按顺序轮转。这样即使分区A里的任务跑飞了它也只能在自己的20毫秒里跑飞不会影响分区B和C。这就像给每个租户分配了固定的营业时间到点必须关门下一个租户进场。空间分区则是给每个分区分配独立的内存空间通过MMU内存管理单元做保护防止分区之间互相踩内存。这个机制在飞控里特别重要因为飞控计算机上可能同时跑着控制律、导航、显示、维护等多个功能它们的安全等级不同必须隔离。ARINC 653的调度通常是两级调度第一级是分区调度按时间窗口轮转第二级是分区内的任务调度通常用固定优先级抢占式调度。这种设计的好处是确定性极强最坏情况下的响应时间可以精确计算。注意ARINC 653分区机制会带来一定的CPU开销因为分区切换需要保存和恢复上下文。在资源紧张的嵌入式平台上分区数量的设计需要权衡。我见过有的项目分了8个区结果分区切换开销吃掉了15%的CPU时间最后不得不合并分区。2.2 DO-178C认证对RTOS的约束DO-178C是航空软件适航认证的核心标准它把软件分为A到E五个等级A级是最高等级指软件失效会导致飞机灾难性事故。飞控计算机上的控制律软件通常是A级这就对RTOS提出了极高的要求。具体来说DO-178C对RTOS的约束体现在几个方面。第一需求追溯RTOS的每一个功能都必须有明确的需求文档而且需求要能追溯到测试用例。第二结构覆盖根据等级不同要求达到语句覆盖、判定覆盖、MC/DC覆盖等。MC/DC覆盖尤其苛刻要求每个判定条件中的每个子条件都能独立影响判定结果。第三最坏执行时间分析RTOS的每个系统调用都必须有WCET分析而且要考虑缓存、流水线、中断等所有影响因素。第四配置管理RTOS的源代码、目标码、配置文件、测试数据都要纳入严格的配置管理。这就导致一个现实能用于A级飞控软件的RTOS产品非常少。国际上比较知名的有VxWorks 653、LynxOS-178、Deos、PikeOS等它们都提供了DO-178C认证包包括生命周期数据、验证证据、WCET分析报告等。这些认证包的价格往往比RTOS本身还贵而且每年维护费用不菲。2.3 主流飞控RTOS技术路线对比目前飞控计算机上常用的硬实时操作系统大致可以分成三条技术路线。第一条是商用认证RTOS代表产品有VxWorks 653、LynxOS-178、Deos。这类RTOS的特点是认证证据齐全工具链成熟技术支持有保障但价格昂贵而且通常绑定特定的硬件平台。它们适合对认证要求高、预算充足的大型飞控项目。第二条是开源RTOS加认证适配比如RTEMS、FreeRTOS、Zephyr等。RTEMS在航天领域用得比较多它有ARINC 653分区支持也有一定的认证证据积累。FreeRTOS和Zephyr在消费和工业领域很火但在飞控A级软件上的应用还比较有限主要问题是认证证据不足和确定性分析不够充分。不过对于一些低等级的飞控项目或者无人机飞控它们是可以考虑的。第三条是自研RTOS一些大型航空企业会自己开发RTOS完全掌控源代码和认证证据。这条路成本最高但灵活性和自主性最强。自研RTOS的难点在于你需要从零建立一套完整的验证体系包括WCET分析工具、覆盖率测试工具、形式化验证方法等工作量巨大。技术路线代表产品认证支持成本适用场景商用认证RTOSVxWorks 653、LynxOS-178DO-178C A级认证包高大型民机、军机飞控开源RTOS适配RTEMS、FreeRTOS、Zephyr部分认证证据低到中无人机、通航、低等级飞控自研RTOS各企业自研自主建立极高特殊需求、自主可控要求高2.4 调度算法与确定性分析飞控RTOS的调度算法选择直接决定了系统的确定性。常用的调度算法有这几种。固定优先级抢占式调度FPPS是最常见的。每个任务分配一个固定优先级高优先级任务就绪时立即抢占低优先级任务。优点是实现简单、开销小、确定性好分析。缺点是优先级反转问题需要通过优先级继承或优先级天花板协议来解决。在飞控里控制律任务通常给最高优先级健康监控给次高数据记录给最低。时间片轮转调度通常用在同优先级任务之间保证公平性。但在飞控里纯时间片轮转很少单独使用更多是作为分区内调度的补充。速率单调调度RMS是一种静态优先级分配方法优先级根据任务周期来定周期越短优先级越高。RMS有一个经典的可调度性判据对于n个任务如果CPU利用率不超过n(2^(1/n)-1)则一定可调度。这个判据在飞控任务设计时经常用来做初步验证。最早截止时间优先EDF是动态优先级调度理论上CPU利用率可以到100%。但EDF的确定性分析比RMS复杂而且在过载情况下的行为不如RMS可预测。飞控里用EDF的案例相对少一些。实操心得在做飞控任务调度设计时我习惯先用RMS做优先级分配然后用WCET分析工具算出每个任务的最坏执行时间再用响应时间分析RTA验证每个任务是否满足截止时间。如果RTA不通过要么优化代码降低WCET要么调整任务周期要么换更快的处理器。这个过程往往要迭代好几轮。3. 飞控RTOS的实操配置与核心环节实现3.1 任务划分与优先级设计实战假设我们要在一个飞控计算机上设计RTOS配置处理器选一款主频200MHz的PowerPC系列芯片飞控里很常见内存512MB要求支持三余度表决。我们来看看任务怎么划分。首先列出功能清单三轴姿态控制律解算、传感器数据采集与滤波、舵机指令输出、余度管理表决、导航解算、健康监控、数据记录、维护通信。然后根据安全等级和实时性要求分配任务周期和优先级。任务名称周期优先级安全等级备注姿态控制律5ms1最高A硬实时抖动50us传感器采集2.5ms2A与控律同步舵机输出5ms3A与控律同步余度表决10ms4A三通道数据比对导航解算20ms5B可容忍稍大抖动健康监控50ms6B监控系统状态数据记录100ms7C非关键维护通信200ms8最低D非关键这个划分的逻辑是控制律和传感器采集是飞控的核心回路周期最短、优先级最高余度表决关系到故障安全优先级次之导航解算周期稍长健康监控和数据记录可以容忍更大延迟维护通信优先级最低只在CPU空闲时运行。优先级分配用的是RMS方法周期越短优先级越高。但这里有个细节传感器采集周期2.5ms比控制律5ms短按理说优先级应该更高但实际设计中我把控制律放在最高优先级原因是控制律的截止时间更紧而且传感器采集可以在控制律之前触发通过中断方式唤醒。这种微调需要结合具体硬件的中断机制来定。3.2 时间分区配置与调度表生成如果采用ARINC 653分区机制我们需要配置分区调度表。假设一个主周期Major Time Frame是40ms我们分成4个分区窗口。分区A控制律传感器舵机20ms 分区B余度表决健康监控10ms 分区C导航解算6ms 分区D数据记录维护通信4ms这个分配的依据是各分区的CPU利用率。控制律分区任务最重给20ms余度表决和健康监控计算量中等给10ms导航解算6ms数据记录和维护通信是非关键任务给4ms就够了。主周期40ms的选择要保证所有分区的最坏执行时间之和不超过40ms并且留有一定余量通常至少20%。分区调度表的生成通常由RTOS的配置工具完成比如VxWorks 653的配置工具可以图形化地拖拽分区窗口然后生成配置文件。配置文件里会定义每个分区的起始时间、持续时间、内存基地址、入口点等信息。/* ARINC 653分区配置示例伪代码 */ partition_config_t partitions[] { { .name CTRL_PARTITION, .id 1, .period_ms 40, .duration_ms 20, .priority 1, .memory_base 0x10000000, .memory_size 0x01000000, .entry_point ctrl_partition_main }, { .name VOTE_PARTITION, .id 2, .period_ms 40, .duration_ms 10, .priority 2, .memory_base 0x11000000, .memory_size 0x00800000, .entry_point vote_partition_main }, /* 其他分区省略 */ };注意分区窗口的持续时间必须大于该分区内所有任务的最坏执行时间之和而且要考虑分区切换开销。我通常会在WCET总和的基础上加30%的余量防止边界情况导致分区超时。3.3 中断处理与时钟同步飞控RTOS的中断处理有几个特殊要求。第一中断延迟要确定不能因为中断嵌套或者关中断时间过长导致响应抖动。第二中断优先级要合理传感器中断、时钟中断、通信中断的优先级要仔细分配。第三中断服务程序要短尽量把耗时操作放到任务里做。时钟同步是另一个关键环节。飞控计算机通常有多个时钟源系统时钟、RTC、外部同步时钟比如GPS秒脉冲。RTOS需要管理这些时钟并提供统一的时基给应用任务。在余度系统中多个通道的时钟还要做同步否则表决时数据对不齐。我参与过的一个项目里三余度通道的时钟同步精度要求是10微秒以内。实现方式是每个通道的RTOS维护一个本地时钟计数器通过交叉通道数据链交换时钟值然后用时钟同步算法类似NTP的简化版做调整。调整时不能直接跳变时钟否则会导致任务周期错乱要用渐进调整的方式每次调整一点点慢慢收敛。3.4 余度管理与故障切换的RTOS支持余度管理是飞控RTOS必须支持的功能。典型的三余度系统里三个通道同时运行相同的控制律然后对输出做表决。如果某个通道的输出与其他两个差异超过阈值就判定该通道故障将其隔离。RTOS在这里的角色是提供交叉通道通信机制和故障检测与切换机制。交叉通道通信通常用共享内存或者专用通信链路实现RTOS要保证通信的确定性和数据一致性。故障检测包括通道健康状态监控、输出比较、心跳检测等。一旦检测到故障RTOS要快速触发切换把故障通道隔离让系统继续运行。这里有个坑故障切换的时间必须足够短否则飞控系统在切换期间会失去控制。通常要求切换时间在几十毫秒以内。为了达到这个要求RTOS的故障处理路径要尽可能短不能有阻塞操作也不能有不确定的延迟。/* 余度表决伪代码 */ int vote_outputs(channel_output_t outputs[3], channel_output_t *result) { /* 两两比较 */ int diff01 abs(outputs[0].value - outputs[1].value); int diff02 abs(outputs[0].value - outputs[2].value); int diff12 abs(outputs[1].value - outputs[2].value); if (diff01 THRESHOLD diff02 THRESHOLD) { /* 通道0和1一致通道2可能故障 */ *result average(outputs[0], outputs[1]); return 2; /* 通道2故障 */ } else if (diff01 THRESHOLD diff12 THRESHOLD) { /* 通道1和2一致通道0可能故障 */ *result average(outputs[1], outputs[2]); return 0; /* 通道0故障 */ } else if (diff02 THRESHOLD diff12 THRESHOLD) { /* 通道0和2一致通道1可能故障 */ *result average(outputs[0], outputs[2]); return 1; /* 通道1故障 */ } else { /* 三个通道都不一致无法表决 */ return -1; } }4. 常见问题与排查技巧实录4.1 任务抖动超标怎么排查任务抖动是飞控RTOS调试中最常见的问题之一。表现是任务的实际执行周期不稳定有时候快有时候慢抖动超过设计要求。排查思路是这样的先确认抖动是系统性的还是偶发的。系统性抖动通常跟调度配置有关偶发抖动通常跟中断、缓存、内存访问冲突有关。系统性抖动的排查步骤第一检查任务优先级分配是否合理有没有低优先级任务长时间占用CPU导致高优先级任务被延迟第二检查分区窗口配置是否足够有没有分区超时导致后续分区被压缩第三检查时钟节拍精度系统时钟源是否稳定。偶发抖动的排查步骤第一用示波器或者逻辑分析仪抓取任务执行的时间戳看抖动发生的规律第二检查中断延迟特别是高频率中断比如传感器中断是否导致任务被频繁打断第三检查缓存命中率如果任务代码或数据经常被换出缓存执行时间会波动很大第四检查内存访问冲突多核系统里如果多个核访问同一块内存会导致总线仲裁延迟。实操心得我遇到过一次抖动超标排查了两周才发现是DDR内存刷新周期和任务周期产生了共振。DDR每隔7.8微秒刷新一次而某个任务的周期是7.8微秒的整数倍导致任务每次执行时都撞上内存刷新执行时间被拉长。解决办法是把任务周期改成7.5微秒避开共振点。这种问题在文档里根本找不到只能靠实测和经验。4.2 分区超时与CPU利用率优化ARINC 653分区超时是指某个分区在分配的时间窗口内没有完成执行导致后续分区被延迟。这个问题在飞控里很严重因为分区超时会破坏整个调度表的确定性。分区超时的原因通常有分区内任务WCET估算不准、任务数量过多、中断处理占用时间过长、缓存未命中等。解决办法第一重新做WCET分析用更精确的工具比如aiT、RapiTime测量实际执行时间第二优化代码减少循环嵌套、减少浮点运算、用查表代替实时计算第三调整分区窗口给任务重的分区更多时间第四考虑把一些非关键任务移到低优先级分区或者后台执行。CPU利用率优化是个持续的过程。我通常会把CPU利用率控制在70%以下留30%余量给峰值负载和未来扩展。如果利用率超过80%系统就会变得很脆弱任何一点额外开销都可能导致超时。4.3 认证过程中的RTOS证据准备DO-178C认证过程中RTOS相关的证据准备是最耗时的环节之一。需要准备的材料包括RTOS需求文档、RTOS设计文档、RTOS源代码、RTOS目标码、RTOS测试用例、RTOS测试结果、RTOS覆盖率分析报告、RTOS WCET分析报告、RTOS配置管理记录、RTOS问题报告等。这里有个经验尽早介入认证。不要等软件开发完了才想起来RTOS认证的事那时候发现证据不足就来不及了。最好在项目启动阶段就选定经过认证的RTOS产品然后让RTOS供应商提供认证包你只需要做集成验证和补充测试。如果用的是开源RTOS认证工作量会大很多。你需要自己做需求追溯、自己做覆盖率分析、自己做WCET分析。这时候可以考虑用一些认证辅助工具比如LDRA、VectorCAST、RapiTime等它们可以自动化生成部分认证证据。常见问题可能原因排查方法解决措施任务抖动超标中断延迟、缓存冲突、内存刷新共振示波器抓时间戳、检查中断延迟调整任务周期、优化中断处理分区超时WCET估算不准、任务过多重新做WCET分析、检查分区配置优化代码、调整分区窗口优先级反转共享资源未做优先级继承检查信号量/互斥锁配置启用优先级继承协议时钟同步偏差大时钟源不稳定、同步算法收敛慢检查时钟源精度、调整同步参数换高精度晶振、优化同步算法认证证据不足需求追溯不完整、覆盖率不达标对照DO-178C检查清单逐项核对补充测试用例、完善追溯矩阵4.4 从开源RTOS迁移到认证RTOS的注意事项很多团队一开始用开源RTOS做原型后来要转认证RTOS这个迁移过程有不少坑。第一API不兼容。开源RTOS和认证RTOS的API往往不一样比如FreeRTOS的xTaskCreate和VxWorks的taskSpawn参数和语义都不同。迁移时需要写一层适配层或者逐个任务重写。第二调度行为差异。开源RTOS的调度器可能在某些边界条件下行为和认证RTOS不同比如同优先级任务的调度顺序、中断嵌套的处理方式等。迁移后需要重新做时序验证。第三认证证据不可复用。开源RTOS上的测试用例和覆盖率数据在认证RTOS上不能直接复用需要重新跑一遍。这意味着测试工作量会翻倍。第四工具链变化。认证RTOS通常绑定特定的编译器和调试器比如VxWorks用Wind River的WorkbenchLynxOS用Lynx的Momentum。团队需要重新学习工具链。实操心得如果项目有认证需求我建议一开始就用认证RTOS做原型哪怕成本高一点。后期迁移的代价往往比一开始就用认证RTOS更大。如果实在要用开源RTOS做原型那就把RTOS相关的代码封装好尽量让上层应用不直接依赖RTOS API这样迁移时改动量会小很多。4.5 飞控RTOS未来技术趋势的个人观察从最近的一些技术动态来看飞控RTOS有几个趋势值得关注。一是多核支持。随着飞控计算机处理能力需求增加多核处理器越来越普遍。但多核RTOS的确定性分析比单核复杂得多缓存一致性、总线仲裁、核间通信都会引入不确定性。目前能支持多核认证的RTOS产品还不多这是个技术难点。二是虚拟化技术。通过Hypervisor在同一个硬件平台上跑多个RTOS实例每个实例负责不同的功能这样可以减少硬件数量、降低重量和功耗。但虚拟化会引入额外的延迟对硬实时性是个挑战。三是形式化验证。传统的测试方法很难穷尽所有边界情况形式化验证可以从数学上证明RTOS的正确性。不过形式化验证的工具和人才都很稀缺目前还主要在研究阶段。四是开源RTOS的认证化。一些开源RTOS项目正在努力积累认证证据比如RTEMS和Zephyr都有认证相关的子项目。如果这条路走通了飞控RTOS的成本会大幅下降。我个人在实际项目中的体会是飞控RTOS选型没有绝对的最优解关键是要匹配项目的认证要求、预算、进度和团队能力。认证要求高的项目老老实实买商用认证RTOS省心省力认证要求低或者没有认证要求的项目开源RTOS完全够用还能省下一大笔钱。最怕的是认证要求高但预算不够那就只能自己啃认证证据这条路非常难走要有心理准备。最后分享一个小技巧在做RTOS配置时把所有的配置参数都写成宏定义或者配置文件不要硬编码在代码里。这样调试时改参数不用重新编译而且配置变更也有记录可查。这个习惯在认证时特别有用因为认证审查员会要求你提供配置变更的记录和理由。
