多余度飞控系统中监督与表决机制的本质差异及适航符合性设计

1. 从一次评审现场的争论说起监督和表决到底是不是一回事几年前参加一个飞控系统的设计评审会上两位工程师为一个问题争得面红耳赤A说“表决器本身就是监督器没必要单独做一套监督逻辑”B坚持“监督和表决是两码事混在一起迟早出问题”。当时我坐在下面心里其实是偏向A的——都是拿多路信号做比较、做判断能有多大区别后来项目推进到验证阶段连续出了几个故障注入测试的异常我才真正意识到当初那个争论背后藏着一个非常关键的认知分水岭。这个分水岭就是监督机制和表决机制虽然经常被放在一起讨论但它们解决的问题、所处的层次、失效时的表现完全不同。把两者混为一谈轻则导致架构冗余度设计不合理重则让整个系统的故障容错能力出现盲区。而一旦涉及适航符合性审查这种混淆几乎是致命的——审查方会直接质疑你的架构是否真正满足安全性目标。这篇文章想做的事情很明确把多余度飞控系统里“监督”和“表决”这两个概念彻底拆开讲清楚它们各自的职责边界、技术实现、交互关系以及在实际适航审查中怎么证明你的设计是合规的。适合正在做飞控架构设计、安全性分析或者适航取证相关工作的同行参考也适合刚接触多余度系统、对这两个概念还比较模糊的读者建立框架认知。需要提前说明的是下面涉及的具体参数、阈值和架构方案都是基于行业内常见实践做的合理演绎不同项目、不同机型会有差异重点是理解背后的设计逻辑而不是照搬数字。2. 监督机制的本质它到底在“盯”什么2.1 监督不是比较而是对“可信度”的持续判定很多人第一次接触监督机制会下意识觉得它就是“拿几路信号比一比不一样就报警”。这个理解不能说错但太窄了。监督机制的核心任务是对系统内部各个组成部分的可信度进行持续判定——注意是持续判定不是一次性比较。举个具体的例子。在一个三余度飞控系统里三个通道各自跑自己的控制律输出各自的舵面指令。表决机制负责从这三个指令里选出一个“大家都认可”的结果。但问题来了如果某个通道的传感器慢慢漂移了它的输出和另外两路逐渐偏离表决器可能在偏离还很小的时候选不出明显异常这时候谁来发现这个通道“不太对劲”答案是监督机制。监督机制会持续监控每个通道的关键状态量——比如传感器读数的一致性、计算资源的健康度、通信链路的完整性、电源电压的稳定性等等。它不直接决定用哪个输出但它会告诉系统“2号通道的可信度在下降。”这个信息会直接影响后续表决时的权重分配甚至触发通道隔离。所以监督机制的本质是一个状态评估与预警系统它的输出不是“选谁”而是“谁还值得信任”。2.2 监督机制的三个层次通道内、通道间、系统级在实际架构中监督机制通常分布在三个层次上每个层次关注的东西不一样。通道内监督是最底层的。每个余度通道内部自己监控自己的传感器、处理器、电源、内存等资源。比如处理器会跑看门狗、做指令集自检、监控栈深度传感器通道会做信号范围检查、变化率检查。这一层的监督是“自检”性质的目的是让每个通道能对外声明“我自己是健康的”。通道间监督是中间层。多个通道之间互相比较关键数据比如交叉比较传感器的原始读数、比较控制律的中间变量、比较输出指令。这一层能发现单个通道自检发现不了的问题——比如某个传感器虽然在自己量程内、变化率也正常但和另外两路就是不一致。通道间监督是发现“共因失效”之外大部分故障的主力。系统级监督是最高层。它站在整个飞控系统的高度综合所有通道的健康信息、表决器的状态、执行机构的反馈判断整个系统是否还能安全飞行。这一层会决定是否降级、是否切换工作模式、是否触发告警。这三个层次不是孤立的它们的信息会汇总到飞控计算机的监控模块里形成一张完整的“健康画像”。我见过一些设计把三层监督混在一起做结果故障定位非常困难——出了问题不知道是通道内自检漏了还是通道间比较逻辑有缺陷。分开做、分层报排查起来会清晰很多。2.3 监督机制的典型实现手段与参数设定逻辑监督机制具体怎么实现常见的手段包括这几类范围检查信号是否在物理可能的范围内。比如空速信号不可能为负高度变化率不可能超过某个极限。变化率检查信号的变化速度是否合理。比如舵面指令在1毫秒内跳变50度物理上不可能直接判定异常。交叉比较多通道同类型信号之间做差值比较超过阈值则判定不一致。时间一致性检查信号的时间戳是否同步通信周期是否稳定。资源监控CPU负载、内存占用、总线带宽等是否在正常范围。看门狗与心跳处理器是否按时喂狗通道间心跳是否正常。这些手段本身不复杂难的是阈值怎么定。阈值太松故障漏报阈值太紧虚警率飙升飞行员会被频繁的告警干扰。我参与过的一个项目早期交叉比较阈值设得太紧地面测试时因为传感器正常噪声就频繁触发不一致告警后来不得不重新做噪声建模把阈值调整到噪声峰峰值的3倍以上同时引入持续时间条件——只有不一致持续超过一定时间才判定为故障。这里有个经验阈值设定一定要基于实测噪声数据和故障注入数据双向验证。纯靠理论计算或者拍脑袋定阈值后面一定会返工。适航审查时审查方也会要求你提供阈值设定的依据包括噪声统计特性、故障模式影响分析的结果。3. 表决机制的核心从多路信号中“选出一个”3.1 表决的本质是决策不是监控如果说监督机制是在问“谁可信”那表决机制就是在问“用哪个”。这是一个决策问题而且是一个必须在有限时间内完成的决策问题。飞控系统的控制周期通常在毫秒级这意味着表决算法必须在极短的时间内处理完所有输入输出一个确定的指令。这个指令会直接送到舵面执行机构没有太多犹豫的时间。所以表决机制的设计目标很明确快速、确定、可预测。常见的表决算法有几种。最简单的是多数表决三路信号取两路相同的或者取中值。四路信号可以取两两平均后再比较。更复杂的有加权平均表决根据每个通道的可信度分配权重可信度高的通道权重更大。还有阈值表决只有落在某个范围内的信号才参与表决。多数表决的逻辑最直观但有个前提故障通道数不能超过容错能力。三余度系统只能容忍一个通道故障如果两个通道同时故障且方向一致多数表决就会选错。这时候就需要监督机制提前把不可信通道隔离掉让表决只在健康通道之间进行。3.2 表决器的输入从哪来监督结果如何影响表决这里就体现出监督和表决的交互关系了。表决器不是闭着眼睛对所有输入一视同仁它的输入实际上包含两部分各路信号的数值以及监督机制给出的可信度标记。一个典型的工作流程是这样的监督机制先对每个通道的健康状态做出判定输出“健康”“降级”“故障”三种标记。表决器收到这些标记后只对标记为“健康”的通道进行表决。如果健康通道数量少于表决所需的最小数量系统就进入降级模式或者触发告警。这种设计的好处是表决器不需要自己去判断哪个信号有问题——那是监督机制的活。表决器只需要根据可信度标记在可信的信号集合里做决策。职责清晰逻辑简单验证起来也容易。但这里有个坑监督机制的判定延迟会直接影响表决的准确性。如果监督机制需要比较长时间才能确认某个通道故障在这段时间里故障通道的信号仍然参与表决可能导致表决结果错误。所以监督机制的响应时间必须和飞控控制周期匹配不能太慢。我见过一个设计监督机制的交叉比较窗口设了50毫秒而飞控周期是10毫秒。结果在故障发生的头几个周期里故障信号一直在参与表决虽然最终监督机制正确隔离了故障通道但中间那几个周期的错误指令已经发出去了。后来把监督窗口缩短到20毫秒同时增加了快速一致性检查作为补充才解决了这个问题。3.3 表决算法的选择依据与典型参数选择哪种表决算法取决于几个因素余度数、故障模式、计算资源、适航要求。表决算法适用余度数优点缺点中值表决3实现简单计算量小无法处理两路同向故障多数表决3或4逻辑直观易于验证需要监督机制配合隔离故障加权平均3以上能利用可信度信息平滑输出权重设计复杂验证难度大阈值表决任意灵活可适应不同场景阈值设定依赖大量测试数据在实际项目中三余度系统最常用的是“中值表决监督隔离”的组合。四余度系统可能会用“两两平均多数表决”的两级结构。具体选哪种要在架构设计阶段就确定因为它直接影响余度管理策略和故障隔离逻辑。表决周期通常和飞控控制周期一致比如10毫秒或20毫秒。表决器的计算延迟必须远小于控制周期一般要求在一个周期内完成所有比较和决策。如果计算资源紧张可以考虑简化表决算法但简化后的算法必须经过充分的验证确保不会引入新的失效模式。4. 两者的本质差异一张表说清楚4.1 职责、层次、时序、失效表现的全方位对比监督和表决的差异可以从多个维度来拆解。下面这张表是我在实际工作中总结的每次给新同事讲这两个概念我都会先把这个表画出来。对比维度监督机制表决机制核心职责判定可信度识别故障从可信信号中选出输出所处层次贯穿通道内、通道间、系统级主要在通道间和系统级输入各通道状态量、传感器数据、资源信息各通道输出信号、监督给出的可信度标记输出健康标记、故障告警、隔离指令最终控制指令时序关系持续运行先于表决每个控制周期执行依赖监督结果失效表现漏报导致故障信号参与表决虚警导致可用通道减少选错输出导致错误指令无输出导致系统降级验证重点故障覆盖率和虚警率表决正确性和实时性适航关注点能否覆盖所有危险故障模式能否在故障情况下保持可控这张表里最值得关注的是时序关系和失效表现两行。监督机制必须在表决之前完成可信度判定否则表决器就是在“盲选”。而两者的失效表现完全不同监督漏报会让坏信号混进表决监督虚警会让好通道被误隔离表决选错会直接输出错误指令表决无输出会让系统失去控制。这些失效模式在安全性分析中必须分别考虑不能混在一起。4.2 为什么不能把监督和表决合并成一个模块回到开头那个评审现场的争论。A工程师认为“表决器本身就在做比较比较就能发现不一致发现不一致就是监督”。这个逻辑听起来有道理但忽略了一个关键问题表决器的比较是为了选出一个结果而不是为了评估每个输入的可信度。举个例子。三路信号分别是10、10、12。多数表决会选出10因为两路相同。但表决器不会告诉你“12那一路可能有问题”——它只是完成了选择。如果12那一路是慢慢漂移的这次是12下次是13再下次是14表决器每次都能选出正确的10但它永远不会主动报告“第三路在漂移”。而监督机制会持续跟踪三路信号的偏差趋势在偏差还很小的时候就发出预警。这就是合并的代价你会失去对“渐变故障”的早期发现能力。渐变故障在飞控系统里非常危险因为它不会突然触发阈值而是慢慢侵蚀系统的容错能力。等到表决器发现异常时可能已经只剩一个健康通道了。另外合并还会导致故障定位困难。如果表决结果异常你无法判断是监督漏报了故障还是表决算法本身有问题。分开设计、分开验证出问题时可以分别排查适航审查时也能分别提供证据。4.3 交互边界监督结果如何“喂”给表决器监督和表决虽然分开设计但它们之间的接口必须定义得非常清楚。这个接口通常包含以下信息通道健康状态每个通道当前是健康、降级还是故障。可信度等级有些系统会给出连续的可信度值而不只是离散标记。故障类型是传感器故障、处理器故障还是通信故障。隔离指令是否需要将某个通道从表决集合中移除。时间戳监督结果的有效时间过期作废。这个接口的设计原则是监督机制只提供信息不直接干预表决。表决器根据这些信息自主决定如何使用。这样做的好处是监督机制的失效不会直接导致表决器失效——如果监督机制挂了表决器可以退回到“所有通道都健康”的默认假设虽然容错能力下降但系统不会完全失控。我见过一个反例某个设计里监督机制直接控制表决器的输入开关监督判定故障就物理断开该通道的信号。结果监督机制本身出了个软件bug误判所有通道故障直接把所有输入都断开了系统完全失去控制。后来改成监督只发标记、表决器自己决定是否采纳安全性就好很多。5. 适航符合性审查方到底在看什么5.1 从安全性目标到架构证据的完整链条适航审查不是看你用了多先进的技术而是看你能否证明你的设计满足安全性目标。对于多余度飞控系统安全性目标通常包括在单故障情况下保持可控在双故障情况下保持安全等等。这些目标会分解到具体的架构需求上比如“三余度系统必须能容忍一个通道的任意故障”。监督和表决机制作为架构的核心组成部分必须分别证明它们能满足分配到的安全性需求。这个证明链条通常是这样的安全性分析如FHA、FMEA、FTA识别出所有危险故障模式。架构设计说明监督和表决如何覆盖这些故障模式。验证活动通过测试和分析证明覆盖有效。符合性证据提交给审查方包括测试报告、分析报告、设计文档。审查方会重点看几个东西你的故障覆盖率是否完整虚警率是否可接受监督和表决的交互是否会导致新的失效模式以及你是否有足够的证据证明这些。5.2 监督机制的适航证据故障覆盖率与虚警率的平衡监督机制的适航证据核心是故障覆盖率。你需要证明对于所有可能导致危险后果的故障模式监督机制都能在可接受的时间内检测到并正确响应。这个证明通常通过故障注入测试来完成。在试验台上人为注入各种故障——传感器漂移、处理器死机、通信中断、电源波动——然后观察监督机制是否能正确检测和隔离。测试用例必须覆盖安全性分析中识别的所有故障模式包括单故障和组合故障。但光有覆盖率还不够虚警率同样重要。虚警会导致可用通道减少降低系统的容错能力。如果虚警率太高系统可能频繁降级反而增加了飞行风险。适航审查时审查方会要求你提供虚警率的统计数据以及你如何通过阈值优化、滤波算法、持续时间条件等手段把虚警率控制在可接受范围内。我参与过的一个项目为了证明监督机制的虚警率满足要求我们跑了超过1000小时的飞行数据回放统计了所有告警事件最终把虚警率控制在每飞行小时0.1次以下。这个数据后来成了适航审查的重要证据。5.3 表决机制的适航证据正确性与实时性的双重证明表决机制的适航证据重点在正确性和实时性两个方面。正确性证明通常采用形式化方法或穷举测试。形式化方法是用数学手段证明表决算法在所有可能的输入组合下都能输出正确结果。穷举测试则是把所有可能的输入组合都跑一遍观察输出是否符合预期。对于三余度中值表决输入组合是有限的穷举测试是可行的。对于更复杂的加权表决可能需要形式化验证。实时性证明相对直接测量表决算法在最坏情况下的执行时间证明它小于控制周期的某个比例比如50%。这个测量必须在目标硬件上进行不能只用仿真数据。审查方会要求你提供最坏执行时间WCET的分析报告。还有一个容易被忽略的点表决机制在降级模式下的行为。当健康通道数量减少时表决算法如何调整是切换到更简单的算法还是直接输出唯一健康通道的信号这个切换逻辑必须明确定义并且经过验证。审查方会关注降级过程中的瞬态行为确保不会出现指令跳变或失控。5.4 常见审查问题与应对思路在实际适航审查中关于监督和表决审查方最常问的问题包括监督机制的检测延迟是多少你需要提供从故障发生到监督机制发出告警的最长时间并证明这个时间不会导致危险后果。表决器在监督机制失效时如何工作你需要说明降级策略并证明降级后的系统仍然满足最低安全性要求。监督和表决的共因失效如何避免如果两者跑在同一个处理器上一个硬件故障可能同时影响两者。你需要证明有足够的隔离措施。阈值设定的依据是什么不能只说“经验值”要提供噪声数据、故障数据、统计分析结果。故障注入测试覆盖了哪些故障模式要提供完整的测试矩阵和结果。应对这些问题的思路其实很统一用数据说话用证据链证明。每一个设计决策都要有依据每一个参数都要有来源每一个测试都要有记录。适航审查不是考试而是同行评审——你要让审查方相信你的设计是经过深思熟虑的你的验证是充分的。6. 实操中的经验与教训那些文档里不会写的东西6.1 监督阈值调参从频繁虚警到稳定运行的踩坑记录前面提到过阈值设定的问题这里展开讲一个完整的踩坑过程。项目早期三余度系统的交叉比较阈值设的是固定值比如气压高度差超过50英尺就告警。地面测试时没问题但到了飞行测试因为大气扰动和传感器安装位置差异正常飞行中三路高度信号经常差到60-70英尺导致频繁虚警。飞行员抱怨告警太多影响操作。第一次调整把阈值放宽到100英尺。虚警少了但故障注入测试时发现一个通道的高度信号漂移到80英尺时监督机制没有告警故障信号继续参与表决。虽然表决结果还是正确的另外两路一致但容错能力已经下降了。第二次调整引入动态阈值。根据飞行阶段和大气条件动态调整阈值——平飞时阈值紧一些机动飞行时阈值松一些。同时增加持续时间条件只有差值超过阈值并持续超过200毫秒才告警。这次调整后虚警率大幅下降故障检测延迟也在可接受范围内。第三次调整在动态阈值基础上增加趋势监控。不仅看当前差值还看差值的变化趋势。如果差值在持续增大即使还没超过阈值也提前发出预警。这个改动让系统能更早发现渐变故障。最终方案是三次调整的叠加动态阈值持续时间趋势监控。这个方案后来通过了适航审查审查方认可了阈值设定的依据——我们提供了超过500小时的飞行数据统计分析和完整的故障注入测试报告。6.2 表决器降级逻辑一个差点导致失控的设计缺陷另一个印象深刻的教训来自表决器的降级逻辑。最初的设计是三余度系统当监督机制隔离一个故障通道后剩下两个健康通道表决器从“三选中值”切换到“两路平均”。逻辑上没问题但实际测试时发现切换瞬间会出现指令跳变。原因在于三选中值表决时输出是中间那个值切换到两路平均后输出是两个值的平均。如果两个健康通道的信号本身有微小差异切换瞬间输出会跳变。这个跳变虽然不大但足以让舵面产生可感知的抖动。更严重的是如果切换发生在飞行关键阶段比如着陆拉平这个抖动可能导致飞行员操作失误。后来我们修改了降级逻辑切换时不是直接跳到平均值而是用渐变过渡——在几个控制周期内逐步把故障通道的权重降到零同时把健康通道的权重升上来。这样输出是平滑变化的不会跳变。这个修改看起来简单但验证起来很麻烦。我们需要证明渐变过渡不会引入新的失效模式比如过渡期间如果又有一个通道故障怎么办。最终我们做了大量的故障注入测试覆盖了过渡期间的各种故障组合才通过了审查。6.3 监督与表决的时序配合一个容易被忽略的细节还有一个细节是监督和表决的时序配合。飞控系统的控制周期是固定的比如10毫秒。监督机制和表决机制都在这个周期内运行。问题是监督机制需要多长时间完成判定如果监督机制用了8毫秒才给出可信度标记表决器只剩2毫秒做决策时间非常紧张。更麻烦的是如果监督机制和表决器跑在同一个处理器上它们会争抢计算资源。监督机制的计算量突然增大比如故障发生时需要做更多比较可能导致表决器超时。我们的解决方案是把监督机制和表决器分配到不同的处理器核上通过共享内存交换数据。监督机制在自己的核上运行表决器在另一个核上运行两者通过时间戳同步。这样即使监督机制计算量增大也不会影响表决器的实时性。这个方案增加了硬件成本但换来了确定性的时序保证。适航审查时审查方对这个设计表示认可因为时序确定性是飞控系统的基本要求。6.4 适航审查前的自查清单最后分享一个我在适航审查前常用的自查清单覆盖监督和表决相关的关键点监督机制的故障覆盖率是否达到安全性分析的要求有没有遗漏的故障模式虚警率是否有统计数据支撑是否满足运行要求监督阈值是否有依据是否经过噪声数据和故障数据验证表决算法是否经过形式化验证或穷举测试表决器的最坏执行时间是否满足实时性要求监督和表决的接口是否明确定义是否有防止误用的保护机制降级逻辑是否经过验证切换过程是否平滑监督和表决的共因失效是否分析过是否有足够的隔离故障注入测试是否覆盖了所有危险故障模式测试结果是否可追溯所有设计决策是否有文档记录证据链是否完整这个清单不是万能的但能帮你提前发现大部分明显的问题。适航审查最怕的不是技术难题而是证据缺失——你明明做了正确的事但拿不出证据来证明。所以平时就要养成记录和归档的习惯别等到审查前才临时补材料。监督和表决这两个机制说到底就是多余度飞控系统的“免疫系统”和“决策系统”。免疫系统负责识别入侵者决策系统负责在健康细胞中选出最优解。两者缺一不可混在一起更不行。把它们的边界划清楚把接口定义好把证据留完整适航符合性就是水到渠成的事。