5.2 软件架构与模块化

5.2 软件架构与模块化

本节摘要：ROS 解决"模块怎么通信"，架构解决"功能该放哪个模块"。本节给出传感器层-感知层-决策层-执行层的四层参考架构，讲清模块切分的三条判据与接口设计的四条约定，并说明失效降级为什么必须在架构期设计而非事后补丁。

一个反例：万能节点是怎么长成的

很多项目这样开始：一个节点负责读雷达、算定位、做规划、发指令——反正都在一起方便。三个月后它变成三千行的"万能节点"：改一行参数要整包重启；日志里四类信息搅在一起，查问题像考古；新人不敢动任何一行。然后有人提议拆分，拆分失败——因为代码里的依赖已经缠死，定位与规划共享了七个全局变量。这个反例的教训不是"要模块化"这句废话，而是：模块边界必须由数据的所有权划定，而不是由开发顺序顺成。谁生产这份数据、谁消费它、过期了归谁，想清这三问，边界自然浮现。

四层参考架构

机器人软件的通行分法是四层，每层一个明确职责：

两层之间的箭头就是第 5.1 节的话题网络。分层的深层理由是时间尺度分离：层内数据频率相近，层间用消息队列解耦——感知慢半拍不该拖死执行层，执行层的高频回路也不该被决策层的大计算阻塞。反过来，架构审查第一问就是"这条消息跨了几层、频率差多少"，频率差越大越要小心队列深度与时间戳。

图：四层架构与跨层消息的时间语义

模块切分的三条判据

1. 数据所有权：一个模块对一类数据拥有生产权（定位模块拥有位姿），其他模块只订阅。两个模块共同写一个状态 → 边界画错了。
2. 失效独立性：任何一个模块崩溃，系统应有明确的降级行为而不是整体瘫痪。做不到，说明隐式依赖没断干净。
3. 节奏一致性：模块内部的计算节奏应当单一（要么全 50 Hz，要么事件驱动）。一个节点里既有 100 Hz 回路又有 0.1 Hz 大计算，多半该拆。

接口设计四约定

模块间消息一旦定下就是长期合同，四条约定能省掉绝大多数扯皮：

• 时间戳与坐标系必填：位姿消息必须说明"何时、在哪个系"，缺一不可——这是第 1.3 节坐标系纪律在集成层的延伸；
• 置信度随数据走：估计类消息带协方差或置信分，下游按置信度决策（低置信就降速重试）而不是盲目消费；
• 枚举状态而非魔法数字：行为状态机的状态用显式枚举（IDLE、NAVIGATING、CHARGING、FAULT），跨模块的状态判断才有共同语言；
• 每条话题写清单位与频率：弧度还是度、米每秒还是百分比，文档里一句话，集成现场省半天。

失效降级：架构期就要画的出口

每个关键模块都要回答"我挂了系统怎么办"。参考答案分级：感知降级（SLAM 失效 → 退到里程计航位推算，限速行驶）、决策降级（规划器超时 → 原地停等，不发模糊指令）、执行降级（轨迹跟踪发散 → 断开轨迹环，走安全停障）。设计要点有两条：降级触发必须是显式状态（广播 FAULT 与原因码，让全系统知道现在是降级态）；降级后的行为要单独测试——大量现场事故源于降级路径从未被走过，真降级时行为未知。

💡 关键直觉：架构的好坏不画在图上，显现在凌晨三点的故障里。模块化、置信度、降级出口，每一条都是给"出事那天"写的保险——平时看着冗余，出事时是唯一的光。

本节要点

• 四层架构的本质是时间尺度分离；跨层消息必带时间戳与坐标系，超龄数据宁弃勿用。
• 模块切分三判据：数据所有权、失效独立性、节奏一致性；边界由数据流定，不由开发顺序定。
• 接口四约定（时间戳、置信度、枚举状态、单位频率）是模块间的长期合同。
• 降级路径在架构期设计、在测试期真的走过一遍，否则降级当天就是事故当天。

生命周期节点：受控的启动与关闭

组件化之后的新问题：二十个节点的启动顺序、依赖等待、故障重启由谁管。生命周期节点把节点状态显式化——未配置、未激活、已激活、已关闭——状态迁移由外部管理者驱动，每个迁移点执行校验（配置阶段检查参数合法、激活阶段自检传感器就绪）。这解决了"隐式启动"的三类事故：节点起好了但下游先动（拿到空数据误判故障）、节点反复崩溃重启（没有退避策略拖垮整机）、关闭顺序错乱（驱动先停导致控制层收到僵尸数据）。生命周期管理的代价是启动逻辑变复杂，换来的是"整机启停像开关灯一样确定"——设备量上去之后这笔交易稳赚。

监控与可观测性：架构的自我感知

架构的最后一层是"让架构自己可被观察"。三级监控从下往上：进程级（节点是否存活、CPU 内存水位）——最低保障；数据级（关键话题的频率、时延、时间戳年龄）——第 5 章反复强调的时序看板在这里实现；语义级（系统处于什么业务状态、降级了没有、为什么）——行为状态机的状态广播。三级都做才叫可观测：只做进程级，会出现"节点活着但发的是三年前的地图"这种僵尸状态；只做语义级，出问题不知道是哪个进程的锅。工程上第三级常被漏掉——而恰恰是它，决定运维人员能否在用户投诉前发现问题。

问题：代码复用与模块边界冲突时听谁的

这是架构期的经典矛盾：感知层与决策层都要用坐标变换，放哪边？原则是"按数据流方向复用，不按方便程度复用"。坐标变换是感知层的产出物（它需要全系统的外参标定知识），决策层只应消费变换服务，而不是自己持有一份标定副本——两份标定迟早不同步。通用判断式：一段代码若被两层需要，看它依赖的原始数据属于哪层，就把代码放哪层，另一层通过接口调用。把这条写进团队的架构评审清单，能消掉一半的"代码放哪"争论。

补机器人软件分层的黄金五层：驱动层（硬件封装，标准是接口稳定可替换硬件不动上层）→功能层（感知、定位、规划、控制各模块，标准是输入输出契约明确、可独立测试）→任务层（状态机或行为树编排，标准是任务逻辑改动不碰功能模块）→接口层（人机界面、遥操作、语音，标准是降级可用）→运维层（日志、监控、OTA、参数管理，标准是出问题能定位）。分层的价值在改动隔离：换一个激光雷达只动驱动层，改一个任务流程只动任务层。判断一个机器人软件架构好不好的快捷方法：提三个假设变更（换传感器、改任务流程、加一个新功能），看各自要碰几层——碰的层数越少，架构的模块化成色越好。多数架构烂尾的原因是把功能逻辑写进驱动回调、把任务判断散在功能模块里，两层污染让每次改动都变成全局回归。