3、控制律安全监控：独立监控通道设计、看门狗定时器、交叉通道数据比较(CCDL)
各位，咱们接着聊。上一章讲了余度管理，这一章我重点说说监控。你想想看，飞控系统里控制律算得再准，万一监控不到位，那也是白搭。我见过不少项目，算法写得花里胡哨，结果监控通道设计得一塌糊涂，最后试飞时出了洋相。所以，这一章咱们把监控的三个核心手段掰开揉碎了讲清楚。
3.1 独立监控通道设计
什么叫独立监控通道？说白了，就是不能让监控逻辑和主控制逻辑混在一起。我个人的习惯是，监控通道必须有自己的传感器输入、自己的处理器、自己的输出路径。哪怕主通道挂了，监控通道还能独立判断系统是否安全。
为什么非要独立？因为共因失效。你想想看，如果主控和监控共用同一个电源、同一个时钟、甚至同一块PCB板，一个雷击或者一个电源浪涌，两个通道一起完蛋。那余度设计还有什么意义？
核心原则：监控通道与主通道之间，物理隔离、电气隔离、软件隔离，三者缺一不可。
我在项目中遇到过一件事。某次系统联调，主通道的CPU跑飞了，监控通道居然也跟着报错。查了半天，发现两个通道共用了一个I2C总线来读取传感器数据。总线被主通道的异常信号拉死，监控通道自然也读不到数据。从那以后，我要求所有监控通道必须使用独立的传感器接口，哪怕多花点成本也值得。
独立监控通道的设计要点：
- 独立的传感器源：比如主通道用惯导A，监控通道就用惯导B，或者用不同的传感器类型（比如主通道用激光惯导，监控通道用光纤惯导）。
- 独立的计算资源：最好用不同的处理器型号，或者至少是不同的芯片批次，避免批次性缺陷。
- 独立的执行路径：监控通道的输出可以直接切断舵机电源，或者切换到备份控制律。
我的小技巧：监控通道的软件代码，尽量由不同的工程师编写。这样能避免思维定势带来的隐藏bug。我曾经吃过这个亏，同一个团队写的代码，主控和监控犯了一模一样的逻辑错误。
3.2 看门狗定时器
看门狗这东西，听起来简单，但用不好就是摆设。很多工程师觉得，只要在定时器溢出前喂狗就行了。嗯，这里要注意，看门狗的设计远不止喂狗这么简单。
看门狗的核心作用是什么？检测程序是否跑飞或者死锁。但如果你只是在主循环里随便喂一下狗，那程序死锁在某个子函数里，看门狗照样被喂得饱饱的，根本起不到监控作用。
我建议的看门狗设计方法：
- 分层喂狗：在任务调度器里喂一次，在关键算法执行完后喂一次，在输出刷新前喂一次。这样能确保每个关键环节都在正常运行。
- 窗口看门狗：不光要喂，还要在规定的时间窗口内喂。喂早了或者喂晚了，都算故障。这能防止程序跑飞后意外喂狗。
- 独立看门狗芯片：不要用CPU内部集成的看门狗，万一CPU内部时钟出问题，看门狗也跟着失效。用外置的独立看门狗芯片，更可靠。
// 伪代码示例：分层喂狗策略
void main_loop() {
while(1) {
feed_watchdog(LEVEL_1); // 主循环喂狗
if (sensor_update() == OK) {
feed_watchdog(LEVEL_2); // 传感器更新后喂狗
}
if (control_law_exec() == OK) {
feed_watchdog(LEVEL_3); // 控制律执行后喂狗
}
output_actuator();
}
}
警告：千万不要在中断服务函数里喂狗！我曾经见过一个项目，工程师图省事，在定时器中断里喂狗。结果主程序死锁了，中断还在跑，看门狗永远不超时。这个bug查了整整两周才找到。
看门狗的超时时间怎么设？我个人习惯是：主循环周期的3到5倍。比如主循环跑10ms，看门狗就设30ms到50ms。太短了容易误触发，太长了起不到保护作用。
3.3 交叉通道数据比较(CCDL)
CCDL，全称是Cross Channel Data Link。这东西在多余度系统里太重要了。简单说，就是让两个或多个通道互相交换数据，然后比较结果是否一致。
为什么要做交叉比较？因为单个通道的故障可能很难自检出来。比如传感器漂移了，它自己可能觉得数据没问题，但跟另一个通道一比，差距就出来了。
CCDL的设计要点：
- 比较什么数据：通常比较关键的状态量，比如姿态角、角速率、加速度、控制输出指令。不要什么都比，通信带宽有限，挑最重要的比。
- 比较的阈值：两个通道的数据不可能完全一样，总有细微差异。所以得设一个合理的阈值。我一般设阈值为传感器噪声的3倍标准差。太小了容易误报，太大了漏报。
- 比较的频率：每个控制周期都比一次。如果某个周期没收到对方的数据，直接报故障。
| 比较项 | 典型阈值 | 说明 |
|---|---|---|
| 滚转角 | ±2° | 动态飞行时适当放宽 |
| 俯仰角 | ±2° | 同上 |
| 角速率 | ±5°/s | 机动飞行时注意 |
| 舵面指令 | ±3% | 百分比满行程 |
我曾经在项目中遇到过CCDL误报的问题。两个通道的数据明明差不多，但比较逻辑总是报不一致。查到最后，发现是通信时序问题——一个通道的数据是上一帧的，另一个通道的数据是当前帧的，时间戳没对齐。从那以后，我要求所有CCDL数据必须带上时间戳，比较前先对齐时间。
关键点：CCDL的故障处理策略要明确。如果发现数据不一致，是直接切换通道？还是先做多数表决？我个人建议：对于双余度系统，不一致时直接切换到监控通道；对于三余度或四余度系统，用多数表决更稳妥。
嗯，这一章的内容就这些。独立监控通道、看门狗、CCDL，这三个手段组合起来，基本能覆盖大部分控制律的故障场景。下一章咱们聊聊更高级的话题——故障注入测试。到时候我会分享一些我在实验室里做故障注入的实战经验。
最后提醒一句：监控设计得再好，也要经过充分的验证。我见过太多设计文档写得完美，实际测试一跑就露馅的案例。记住，纸上得来终觉浅，绝知此事要躬行。
公众号:蓝海资料掘金营，微信deep3321