第2章架构设计原则

第二章：架构设计原则

各位好，我是老轨。今天咱们聊聊制动系统架构设计的三个核心原则。这三个原则，说白了就是系统设计的「命根子」。我做了十几年制动系统，见过太多因为原则没守住而翻车的案例。

嗯，咱们一个一个来看。

模块化，听起来简单吧？就是把一个大系统拆成小块。但怎么拆，拆到什么程度，这里头有讲究。

我个人习惯把制动系统拆成三层：

为什么要这么拆？你想想看，如果所有功能都揉在一个大模块里，出问题排查起来有多痛苦。我在项目中遇到过，某次调试时制动指令一直不响应，查了三天才发现是某个全局变量被意外修改了。要是模块化做得好，这种问题半小时就能定位。

模块化设计的关键要点：

举个例子，制动控制单元（BCU）内部，我习惯把安全功能和非安全功能分开。安全功能比如紧急制动、防滑控制，这些必须独立成模块，不能和非安全功能混在一起。为什么？因为安全功能需要最高级别的可靠性验证，混在一起会大大增加验证难度。

我的小技巧：模块划分时，先画数据流图。看看哪些数据是频繁交互的，哪些是偶尔交互的。频繁交互的可以考虑合并，偶尔交互的坚决分开。

冗余设计，说白了就是「留后手」。轨道交通制动系统，你敢让它出故障吗？不敢。所以必须冗余。

常见的冗余架构有两种：2取2和3取2。我分别说说。

2取2，就是两个通道同时工作，两个结果一致才输出。不一致？那就报故障。

这种架构的优点是简单、响应快。缺点嘛，容错能力差——只要一个通道出问题，系统就「罢工」了。

我记得有一次，某项目用了2取2架构做紧急制动指令。调试时发现两个通道偶尔不一致，查了半天是晶振漂移导致的。从那以后，我要求所有2取2通道必须用同一时钟源。

3取2，三个通道，两个以上一致就输出。这种架构容错能力强，一个通道坏了还能继续工作。

但代价是什么？成本高、复杂度高、响应慢。你想想看，三个通道要投票，投票逻辑本身也得可靠，不然就是「投票系统出故障」的尴尬局面。

注意：3取2不是万能的。我曾经遇到过一个案例，三个通道中有两个因为同一批次芯片的共因故障同时失效。3取2架构对这种共因故障毫无办法。所以，冗余设计必须考虑多样性——不同批次、不同供应商、甚至不同原理的通道。

实际项目中，我一般这样分配：

这个原则，是所有原则里最重要的。说白了就是：系统出故障时，必须进入安全状态，而不是任意状态。

什么是安全状态？对于制动系统来说，安全状态就是「制动施加」。你想想看，如果系统故障时制动失效了，那后果是什么？所以，故障导向安全的设计思路是：一旦检测到故障，立即施加制动。

我见过一个反面教材。某项目设计时，工程师觉得「故障时保持当前状态」更合理。结果呢？列车在高速运行时制动系统故障了，系统保持「无制动」状态，列车停不下来。嗯，这个项目后来被要求全面整改。

故障导向安全的设计要点：

具体实现上，我习惯用「安全继电器」和「看门狗」组合。安全继电器负责切断动力，看门狗负责监控主控芯片是否「死机」。一旦看门狗超时，安全继电器自动动作，施加制动。

这里有个坑：看门狗超时时间设置。太短了容易误触发，太长了又起不到保护作用。我一般设置在50-100ms之间，具体看系统响应时间。

避坑指南：我曾经把看门狗超时设成200ms，结果某次测试时主控芯片卡住了，200ms后才触发安全制动。虽然最终安全了，但制动距离比预期多了不少。从那以后，我坚持看门狗超时不超过100ms。

还有一个容易被忽略的点：故障导向安全不只是硬件的事，软件也要配合。比如，软件要能检测到传感器故障、通信故障、执行器故障，并且每种故障都要有对应的安全处理逻辑。别搞「统一处理」，不同故障的安全策略可能不同。

举个例子：

嗯，这三个原则讲完了。模块化是基础，冗余是保障，故障导向安全是底线。三者缺一不可。下次咱们聊聊制动系统的具体架构设计，到时候会用到今天讲的这些原则。

记住一句话：架构设计不是炫技，是保命。别为了省成本或者图省事，把原则丢了。