4. 硬件架构设计：冗余架构（2oo2、2oo3）、主控单元、驱动单元、检测单元
各位同学，咱们今天聊点硬核的——硬件架构。说实话，门控系统这东西，你要是只做一套单机版，那叫玩具。真正上线的自动驾驶列车，它的门控系统必须能扛得住各种极端情况。我参与过的几个项目里，最让我印象深刻的，就是有一次在测试现场，一套2oo2架构的系统，一个通道的电源模块突然挂了，结果系统愣是没让列车停运，门照样开关自如。嗯，这就是冗余架构的魅力。
4.1 冗余架构：为什么非要“双份”甚至“三份”？
你想想看，列车门要是打不开，乘客下不了车；要是关不上，列车发不了车。这都不是小事。所以，硬件必须冗余。说白了，就是关键部件要有备份，一个坏了，另一个立刻顶上。
常见的冗余架构有两种：2oo2 和 2oo3。我建议你先把这两个概念吃透，因为后面所有的主控、驱动、检测单元设计，都围绕它们展开。
4.1.1 2oo2 架构（二取二）
2oo2，全称是“Two out of Two”。意思是两个通道都正常工作，系统才输出允许动作的信号。任何一个通道故障，系统就进入安全侧（比如禁止开门）。
我在项目中遇到过一种情况：某条线路的站台门，用了2oo2架构。有一次一个通道的传感器误报了一个“门未锁紧”信号，结果系统直接判定为故障，门就不动了。虽然安全，但影响了运营效率。所以，2oo2架构的优点是安全性极高，缺点是可用性稍低——因为只要一个通道出问题，整个系统就罢工。
核心特点：
- 两个通道必须同时“同意”，系统才动作。
- 单点故障会导致系统停机（安全侧）。
- 适用于对安全性要求极高、对可用性要求一般的场景。
4.1.2 2oo3 架构（三取二）
2oo3，就是“Three out of Two”。三个通道中，只要有任意两个通道一致，系统就按这个一致的结果执行。说白了，就是“少数服从多数”。
我曾经在一个地铁项目中，主控单元用了2oo3架构。当时有一个通道的CPU因为散热问题偶尔死机，但另外两个通道依然正常工作，系统完全不受影响。这就是2oo3的好处——既能保证安全，又能保证高可用性。当然，代价就是硬件成本高，而且三个通道之间的同步和表决逻辑比较复杂。
我的建议：
如果项目预算充足，且对可用性要求极高（比如全自动运行线路），优先选2oo3。如果预算有限，且安全是第一位的，2oo2完全够用。我个人习惯在关键安全功能（如门锁控制）上用2oo2，在非关键但影响运营的功能（如状态监测）上用2oo3。
4.2 主控单元：系统的“大脑”
主控单元，就是整个门控系统的决策中心。它负责接收来自列车网络（比如TCMS）的指令，处理传感器信号，然后决定“开门”还是“关门”。
主控单元的设计，我建议重点关注三点：处理能力、通信接口、冗余切换。
| 设计要素 | 说明 | 我的经验 |
|---|---|---|
| 处理能力 | CPU主频、内存大小、实时性要求 | 别用消费级芯片，工业级或车规级是底线。我曾经见过用ARM Cortex-M4的，够用但别超频。 |
| 通信接口 | MVB、CAN、以太网、数字IO | 接口要留余量。我习惯至少预留20%的IO端口，方便后期扩展。 |
| 冗余切换 | 主备切换时间、切换逻辑 | 切换时间要控制在100ms以内。我记得有一次测试，切换时间长了，导致门控指令丢失，后来优化了心跳检测机制才解决。 |
主控单元内部，通常包含两个或三个独立的“通道”。每个通道都有自己的CPU、内存和通信模块。它们之间通过高速总线（比如PCIe或专用背板）进行数据同步。
注意：
主控单元的冗余切换，不能依赖外部信号。我曾经见过一个设计，主备切换靠列车网络发指令，结果网络断了，两个通道都以为自己是主，导致系统混乱。正确的做法是：每个通道独立检测对方的心跳，自己决定是否接管。
4.3 驱动单元：把指令变成动作
驱动单元，说白了就是“干活的”。它接收主控单元的控制信号，然后驱动电机、电磁阀、继电器等执行机构，让门打开或关闭。
驱动单元的设计，我建议你记住一个原则：功率要够，保护要全。
- 功率设计：驱动电机需要多大的电流？启动瞬间的浪涌电流是多少？我建议留出1.5倍的余量。有一次我在项目中，电机堵转时电流飙升，驱动板直接烧了，后来换了更大功率的MOSFET才解决。
- 保护电路：过流保护、过压保护、过热保护、短路保护，一个都不能少。我习惯在驱动单元上加一个独立的硬件看门狗，万一主控单元死机了，驱动单元能自动切断输出，防止门失控。
- 冗余设计：驱动单元本身也要冗余。比如，两个驱动通道分别控制电机的两组绕组，一个通道坏了，另一个还能以半功率驱动门动作。虽然慢一点，但至少能保证门能关上。
避坑指南：
我曾经在一个项目中，驱动单元的电源滤波没做好，导致电机启动时产生大量电磁干扰，影响了主控单元的通信。后来我在驱动单元的电源入口加了一个共模扼流圈，问题就解决了。所以，驱动单元的EMC设计一定要重视。
4.4 检测单元：系统的“眼睛”和“耳朵”
检测单元，负责采集各种传感器信号，比如门的位置、速度、力矩、障碍物检测等。这些信号是主控单元做决策的依据。
检测单元的设计，我建议你关注三点：传感器选型、信号调理、故障诊断。
4.4.1 传感器选型
门控系统常用的传感器有：
- 位置传感器：霍尔传感器、编码器、接近开关。我建议用非接触式的，寿命长，故障率低。
- 力矩传感器：用于检测门是否被卡住。我习惯用电流检测来代替，因为电机电流和力矩成正比，成本更低。
- 障碍物检测：红外传感器、超声波传感器、压力传感器。我个人偏好压力传感器，因为它能直接检测到夹到人，反应最快。
4.4.2 信号调理
传感器出来的信号，往往很“脏”。有噪声、有漂移、有毛刺。所以，必须经过信号调理电路，比如滤波、放大、整形、隔离。
我建议你在每个传感器通道上加一个隔离放大器，防止外部干扰窜入主控单元。我曾经遇到过一个问题：一个接近开关的线缆和电机线缆走在一起，结果电机启动时，接近开关误触发，导致门控系统以为门已经到位了。后来加了隔离和屏蔽，问题才解决。
4.4.3 故障诊断
检测单元不仅要采集信号，还要能判断传感器本身是否坏了。这叫“自诊断”。
我常用的方法有两种：
- 冗余传感器：同一个位置装两个传感器，如果两个信号不一致，就报故障。
- 信号合理性检查：比如，门从开到关，位置信号应该是单调变化的。如果突然跳变，那肯定是传感器坏了。
小技巧：
我习惯在检测单元中加一个“心跳信号”。如果主控单元在一定时间内没收到检测单元的心跳，就认为检测单元故障，然后进入安全模式。这个机制简单但非常有效。
4.5 架构集成：把三块拼起来
好了，主控、驱动、检测，这三块怎么拼成一个完整的系统？我画个简单的逻辑图给你看：
+----------------+ +----------------+ +----------------+
| 检测单元 | | 主控单元 | | 驱动单元 |
| (传感器、调理) | ----> | (决策、冗余) | ----> | (功率放大、保护)|
+----------------+ +----------------+ +----------------+
^ | |
| | v
+-----------------------+-------------------> 执行机构（电机、阀）
实际项目中，这三块单元通常集成在一块或几块电路板上。我建议你采用模块化设计：检测单元、主控单元、驱动单元各自独立成板，通过背板或线缆连接。这样，任何一个单元坏了，直接换板子就行，不用动整个系统。
嗯，硬件架构设计就聊到这里。下一章，咱们会深入讲讲软件架构，看看这些硬件怎么被“指挥”起来。记住，硬件是骨架，软件是灵魂，两者缺一不可。