4、门控系统架构：门控系统组成、主控板与门节点通信方式、CAN在门控中的角色

好，咱们进入第四章。前面聊了唤醒和休眠的基本原理，这一章得把整个门控系统的骨架搭起来。说白了，就是搞清楚系统里都有谁，它们之间怎么说话，以及CAN总线在这个大家庭里到底扮演什么角色。

我当年第一次接触门控系统时，也以为就是几个门锁加个控制器。后来发现，事情远没那么简单。一个靠谱的门控系统，其实是一个小型的分布式控制网络。

4.1 门控系统组成：谁在干活？

一个典型的门控系统，我习惯把它分成三个层次：

• 管理层（主控板）：系统的“大脑”。负责决策、逻辑运算、与外部通信（比如消防信号、楼宇对讲）。
• 执行层（门节点）：系统的“手脚”。每个门都有一个节点，负责采集门磁、按钮状态，控制电锁、指示灯。
• 通信层（CAN总线）：系统的“神经网络”。把大脑和手脚连起来，传递指令和状态。

你想想看，如果一栋楼有100个门，每个门都拉一根线到主控板，那线束得多恐怖？所以，分布式架构是必然选择。

4.2 主控板与门节点通信方式：怎么说话？

主控板和门节点之间怎么通信？这里有几个选项，我挨个说说我的看法。

方案一：RS-485

这是老前辈了。成本低，技术成熟。但有个问题——它是主机轮询模式。主控板得一个一个点名：“1号门，你状态咋样？”“2号门，你呢？” 门多了，轮询一圈下来，实时性就差了。我在一个旧项目改造时就吃过这个亏，100个节点轮询一遍，响应时间超过200ms，用户体验很不好。

方案二：CAN总线

这才是现代门控系统的首选。为什么？因为CAN是多主通信。任何一个节点都可以主动发消息。门被非法打开，门节点可以立刻“喊”出来，不用等主控板问。实时性、可靠性都高出一截。

方案三：私有单总线

有些小系统用单总线，比如DHT11那种。但距离一远、节点一多，稳定性就堪忧。我个人不建议在门控这种对可靠性要求高的场合用。

4.3 CAN在门控中的角色：它到底管什么？

CAN总线在门控系统里，不是可有可无的配角。它承担了三个关键角色：

4.3.1 实时状态上报

每个门节点需要定期（或事件触发）上报状态。比如：

• 门状态：开/关/虚掩
• 锁状态：上锁/解锁/异常
• 按钮状态：按下/释放

这些信息通过CAN报文发出去。主控板收到后，更新界面或触发报警。

4.3.2 控制指令下发

主控板下发指令，比如“打开3号门”、“锁定所有门”。CAN的广播功能在这里很实用。一条广播指令，所有节点都能收到，效率极高。

4.3.3 网络管理与诊断

嗯，这里要注意。CAN总线还负责节点的“心跳”监测。每个节点每隔一段时间发一个心跳报文。如果主控板连续几次没收到某个节点的心跳，就可以判定它离线了，触发维护告警。

我曾经在一个项目中，就是因为没用心跳机制，有个门节点电源松动了，系统还显示“在线”，结果安保人员巡检才发现门锁没电了。从那以后，我把心跳监测写进了设计规范里。

4.4 一个典型的CAN报文结构（门控场景）

咱们看一个实际例子。假设门节点上报“门被打开”事件：

// CAN报文格式（标准帧，11位ID）
// ID: 0x1A3
// 数据域：
// Byte 0: 节点地址 (0x01 - 0xFE)
// Byte 1: 消息类型 (0x01 = 状态上报)
// Byte 2: 状态码 (0x01 = 门开, 0x02 = 门关, 0x03 = 异常)
// Byte 3: 保留
// Byte 4-7: 时间戳

// 示例：节点0x05上报门开
// ID = 0x1A3
// Data = 0x05, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00

这个结构很简单，但够用。我习惯把ID的高几位用来区分消息优先级。比如报警类消息用高优先级ID，状态类用低优先级。这样即使总线繁忙，报警也能第一时间传出去。

4.5 小结一下

门控系统的架构，说白了就是“一个大脑管一群手脚，CAN总线当传话筒”。主控板不直接控制每个门，它只发指令、收状态。具体怎么驱动电锁、怎么检测门磁，那是门节点自己的事。

这种架构的好处是：扩展性好（加个门就加个节点），可靠性高（一个节点坏了不影响其他），维护方便（哪个门出问题换哪个板子）。

下一章，咱们会深入CAN网络的唤醒和休眠机制。那才是真正考验设计功底的地方。做好准备。