做智能驾驶功能软件平台的第一件事不是写代码而是把系统架构定下来。这是我做了几个量产项目之后最大的体会。很多团队一上来就拆分模块、定义接口、搭通信框架结果三个月后推倒重来问题基本都出在架构层没想清楚。《智能驾驶功能软件平台设计规范 第一部分系统架构》这份规范解决的就是这个“最先要做又最容易糊弄过去”的问题。这篇内容我会结合自己在实际项目中踩过的坑把架构设计的思路、模块划分的逻辑、接口和通信的关键设计点以及落地时的避坑经验一次性讲透给正在做架构评审、模块解耦和接口对齐的同行做个参考。1. 为什么智能驾驶平台要先定系统架构1.1 从项目痛点说起智能驾驶功能软件的复杂度这几年涨得离谱。一个L2级别的基础功能涉及感知、融合、预测、规划、控制、HMI提示再加上高精地图、定位、云端交互代码规模轻松到百万行级别。如果还沿用“每个功能一个工程、传感器数据直接灌给算法节点”的老做法第一版Demo可能跑得很快但到了量产阶段就全是坑。我见过最典型的例子某个泊车项目感知团队写了一个视觉感知节点直接把图像数据通过共享内存发给了规划团队两边约定了一个私有结构体。结果感知算法要升级换了新的输出格式规划那边编译直接过不了整个联调停了两周。这种问题归结起来只有一个原因——模块之间没有清晰的架构边界接口没有规范约束。系统架构规范要干的事情就是把整个功能软件平台划分成职责清晰的层次和模块规定好数据怎么流、服务怎么调用、故障怎么处理。它不关心某一个感知算法的具体实现而是关心这些算法以什么形态挂在平台上互相之间以什么方式协作。架构定了后面写代码才是真正的“填砖头”而不是边盖边拆。1.2 这份规范到底在约束什么《智能驾驶功能软件平台设计规范 第一部分系统架构》这类文档一般会覆盖几个核心方面功能软件的层次划分、逻辑组件之间的交互关系、数据流和消息通信机制、系统资源的确定性调度以及冗余和降级策略。从工程落地角度看它实际上在回答三个问题。第一每个功能模块放在哪个层级它的职责边界是什么能调用哪些服务、不能直接碰哪些东西。第二模块之间的接口长什么样是同步调用还是异步消息数据格式谁定义、怎么演进。第三整个系统如何保证在算力有限的条件下稳定运行极端场景下如何降级而不是直接崩溃。这三个问题如果不在架构阶段讲清楚后面每个迭代都会有人问“这个数据我该从哪里拿”“这个模块能不能直接访问传感器”“那个功能挂了我这边要不要一起降级”。每个问题都会变成一次跨团队扯皮消耗的时间远超写代码本身。所以架构规范不是文档工作它是在给所有开发人员划定一条公共的“交通规则”。2. 架构设计的核心思路2.1 分层架构把职责切清楚现在比较公认的做法是把智能驾驶功能软件平台分成三层来设计功能软件层、平台服务层、操作系统抽象层。对应到项目里每一个模块都必须在其中找到属于自己的层级。功能软件层是离业务最近的感知、融合、预测、决策规划、控制都在这一层。这一层的特点是业务性强、迭代频繁算法团队主要在这里工作。平台服务层是承上启下的提供通信服务、数据管理、日志服务、诊断服务、健康管理、时间同步等公共能力。这一层更像是智能驾驶系统的“操作系统”对上层提供稳定统一的API屏蔽底层硬件差异。操作系统抽象层则负责封装不同的芯片平台、硬实时操作系统或者Linux发行版让平台服务层不要被某个具体SoC绑定。我理解的架构设计第一原则就是严格禁止越层访问。功能软件层想拿传感器原始数据必须通过平台服务层提供的数据访问接口不能自己去读设备节点。这个约束在前期会觉得“多此一举”但一旦芯片更换、驱动调整只有数据访问被收敛了才能把改动限制在一个很小的范围内。我在项目里见过最头疼的就是某个感知模块直接依赖了摄像头驱动的私有格式换了一个型号的摄像头之后整个感知链路都要跟着改。2.2 服务化拆解不等于乱拆分层之后接下来是功能模块的拆分方式。这两年的主流方向是基于SOA面向服务架构的思路把功能软件层的各个能力做成服务服务之间通过接口进行调用和数据交互。SOA落地的第一问题是服务粒度。拆太大了等于没拆整个感知是一个服务接口又粗又重协作还是混乱。拆太细了又会产生大量通信开销和服务管理负担一个感知服务拆成几十个子服务光服务注册、发现、负载均衡就够喝一壶。我的经验是按“可独立演进的业务能力”来切一个服务应该对应一个相对完整且可独立迭代的功能域比如目标感知、融合跟踪、行为预测、轨迹规划、车辆控制。每个服务内部的算法怎么改其他服务不需要关心只要接口协议不变就可以。第二问题是服务之间怎么协作。大部分场景我倾向用异步消息机制而不是同步RPC。感知结果以周期性的消息发布出去规划模块订阅这些消息两边通过话题解耦。这样感知的发布频率调整了规划侧不需要改代码只要配置订阅关系就行。但控制指令这类对时延敏感、需要确认的交互用同步请求/响应模式会更容易保证时序关系。实际落地时两种模式会共存架构规范里必须把各自的适用场景界定清楚。2.3 “感知—规划—控制—协同”四大功能簇功能软件层内部的划分我习惯先把它聚成四个功能簇而不是一上来就拆到原子模块。感知功能簇负责环境感知和多传感器融合对外输出目标列表、可行驶区域、交通标志等结构化信息。规划决策功能簇负责行为决策、轨迹规划和速度规划告诉车辆接下来往哪走、怎么走。控制功能簇负责执行轨迹规划的结果输出转向、加速、制动的控制指令。协同功能簇则分管人机交互、远程监控、云端交互等非驾驶主线但必须存在的功能。分完这四个功能簇之后再往里去定义模块。比如感知功能簇里可以拆出视觉感知、毫米波雷达感知、激光雷达感知、融合模块决策规划里可以拆出场景理解、行为决策、运动规划、安全校验。每个模块的输入输出、周期、DDS数据分发服务主题都需要被明确定义。架构文档里把这一层画清楚开发人员拿到手才知道自己该写什么、跟谁对接。这里有一个非常关键的细节就是模块的“周期”必须写清楚因为智能驾驶大多数处理是周期性的视觉感知可能是30Hz到60Hz毫米波雷达可能是20Hz到50Hz融合模块一般用固定周期比如20Hz规划控制通常是20Hz到50Hz。周期不一致导致的时序错乱在架构层面就必须被识别出来。3. 落地过程中最关键的几个细节3.1 接口规范架构的“语法”架构光有分层和模块不够接口规范才是保证大家协作顺畅的“语法”。接口设计里最容易犯的错误是把接口协议直接和某个实现语言的数据结构绑定比如用C的struct字段名、内存布局都和某一版代码强相关。第一版跑起来挺顺畅等到对方升级版本、增加字段问题就出来了。我的做法是所有跨模块接口用统一的接口描述语言来定义然后自动生成各语言的代码骨架。这样接口一改双方同步看到变更编译期就能发现不兼容。字段命名也有约定禁止用a、b、tmp这种无意义命名单位必须写在字段名里或者定义明确的注释约束比如速度字段要写清楚是m每s角度字段要写清楚是rad还是deg。这个细节看起来小我以前就遇到过一次A模块输出的航向角单位是弧度B模块默认用角度去算结果车辆在高架弯道上直接偏了一个车道排查了两天才发现是单位问题。接口版本管理也特别重要。架构规范里要明确接口变更的流程哪些改动是兼容的新增字段、扩展枚举哪些是不兼容的删除字段、改变字段含义。不兼容变更必须走评审流程上下游模块统一迁移禁止悄悄改。项目里最怕的就是有人“顺便把接口改了”下游模块第二天跑起来发现数据对不上还以为是自己的bug。3.2 通信与数据流时延和QoS是硬指标功能软件平台的通信机制选型很大程度上决定了系统的性能和稳定性。现在智能驾驶主流的通信中间件是DDS它天然支持发布/订阅模式QoS策略丰富适合多传感器数据的实时分发。不过DDS的QoS配置是有讲究的不是随便填个默认值就行。可靠性策略上感知数据这类周期性的、丢几帧可以容忍的消息用BEST_EFFORT即可也就是尽力传输。控制指令、状态切换这类必须确保送达的消息用RELIABLE。如果反过来配感知消息用可靠性传输网络稍有抖动就会积累排队时延持续增加最后系统表现反而不稳定。我在项目里遇到的低概率“幽灵现象”最后查下来就是某条感知消息被意外配置成RELIABLE当网络出现瞬时拥塞时消息积压规划拿到的数据已经是一百多毫秒之前的了。数据流设计还有一个容易忽略的点——大数据的传输路径。图像数据、点云数据动辄几十MB每秒不适合走标准的DDS消息通道。我会单独规划共享内存通道通过DDS只传递数据描述和共享内存的索引真正的大块数据通过零拷贝方式读取。这样通信开销不会成为瓶颈带宽留给控制消息和状态消息。同时要配套失效保护机制共享内存通道异常了接收方要能通过超时判断感知数据失效并触发降级逻辑。3.3 确定性调度与算力分配智能驾驶是安全关键系统处理的确定性非常关键。一个规划控制模块如果运行时延忽高忽低抖动超过几十毫秒下游执行机构就会感到“车子一顿一顿的”。所以在平台服务层必须提供确定性调度能力保证关键链路的处理周期可控。最直接的做法是为关键模块预留专用CPU核心或GPU算力分区。硬件上现在的智驾SoC普遍多核把感知、融合、规划、控制分配到不同的核心配置核心隔离避免相互抢占。操作系统层采用硬实时或者配置高优先级抢占策略确保关键任务不会被低优先级任务阻塞。非关键任务比如日志上传、远程诊断放到低优先级或者独立核心上绝不允许它们影响驾驶主链路。算力的“余量”也要提前规划。架构阶段就得估算整个功能软件平台在峰值场景下的算力消耗比如城市快速路上同时出现多目标、强光、雨雾天气感知算力消耗会明显上涨。规划出峰值负载建议预留不低于20%到30%的算力余量给将来算法升级和新增功能留空间。有几个项目到后期算法精度提升需要增加算力发现SoC已经满载只能做裁减是特别被动的事。3.4 冗余与降级L3以上绕不开的课题系统架构设计中冗余与降级是安全落地的保障。功能上备份感知、备份规划甚至备份控制链路是L3级及以上的常见要求。代价是算力成倍增长功耗和成本都上去。架构上要做一个合理折中关键模块做冗余非关键模块做普通部署。降级策略是我一直建议在架构阶段就要定义的。典型的分级降级模型可以这样划分正常状态下所有功能全开检测到感知能力下降比如摄像头被遮挡、雷达故障系统进入“有限功能模式”关闭依赖该传感器的功能ACC自动退出或提醒接管到了更严重的故障比如定位失效系统进入“最小风险策略”模式靠道路模型和历史轨迹安全减速停车。每一级降级对应的触发条件、功能退出逻辑、HMI提示方式都需要在架构文档里明确定义。这个工作一定要前置。我见过不少项目故障降级逻辑是在联调阶段才紧急补上的结果没有统一的降级状态管理一个模块一个想法车辆遇到故障时的“反应”完全不可预测。等到整车安全评审时被提出一堆问题再返工代价非常大。4. 架构落地避坑指南4.1 接口风暴大家各写各的怎么收敛架构规范发布之后最常遇到的问题就是接口风暴。每个开发团队都觉得自己模块的输入输出是特殊的不愿意按照公共接口规范来定义结果审到后面接口五花八门。我建议的做法是在项目启动时就搭一个接口评审组任何跨模块接口变更必须过评审。评审的重点不是复杂度而是接口设计是否符合几个原则第一字段是否真正必要有些内部计算中间量不应该暴露给外部第二是同步还是异步需要和调用场景匹配第三接口是否足够通用比如目标列表数据不应该绑定特定的传感器来源。评审组可以先用一个量化指标来盘点接口比如每个接口被复用的次数如果大量接口只被一个消费者用一次说明模块划分或者接口设计出了偏差。另外接口文档和代码必须同步更新。我习惯把接口定义为代码仓库里的版本化文件评审通过后自动生成文档避免出现“文档一套、代码一套”的混乱。如果有人偷懒改了代码没更新接口文件CI流程里加一道检查编译不过从源头堵住。4.2 传感器配置变化架构别跟着崩智能驾驶系统的传感器配置在开发过程中经常变。今天用三颗毫米波雷达明天调整成五颗摄像头从800万像素升级到1200万像素测距能力变了。架构如果不能适应这种变化每次配置调整都会带来一轮重构。为了应对变化架构上要把“传感器抽象”做成一个独立的接口层次。感知模块不直接订阅某个具体传感器的数据主题而是订阅抽象过的感知输入接口比如“前向感知目标列表”“环视感知目标列表”。具体哪颗传感器提供这个数据由平台的传感器管理模块负责映射。这样调整传感器配置只需要改平台层的映射关系感知算法几乎不用动。这个设计的额外好处是方便仿真测试。仿真环境里可以模拟任何传感器配置只要配置映射到同一个抽象感知输入接口算法不需要区分数据来自真实传感器还是仿真器。我们团队后来做仿真回归测试就是靠这层抽象每天可以自动跑上千个场景效率提升非常明显。4.3 仿真一致性问题架构验证的试金石架构设计得再漂亮也要靠验证来兜底。这里最常见的问题是仿真结果和实车表现不一致。原因通常出在数据时间戳上。仿真环境里时间比较理想实车上传感器数据、执行器反馈的时延是客观存在的。架构上如果对时间戳没有统一处理仿真里能通过的算法到实车就暴露时序问题。所以架构规范里一定要定义统一的时间同步方案和时钟源。每个功能模块处理数据时必须基于数据的采集时间戳而不是模块本地收到数据的时刻。平台服务层要提供时间同步服务把各个传感器、执行器的数据对齐到一个统一时间轴上。测试时仿真环境要注入真实的时延分布而不是理想化的零时延这样仿真结果才有参考价值。在验证环节我还建议搭一套“架构合规性检查工具”用静态检查扫描代码看有没有模块绕过平台服务层直接进行跨模块交互有没有接口字段单位随便定义。这套东西写起来不复杂但对维持架构规范的严肃性特别有帮助。规范的权威性不是靠文档贴出来而是靠工具在开发流程里自动执行出来的。5. 一些额外的想法架构设计这个东西最难的不是建立规范而是在持续迭代中守住规范。功能软件平台只要还在演进就会有各种各样的“特殊情况”跳出来今天一个模块说“我这个场景必须突破架构”明天另一个模块说“这个接口要加个临时字段”。守不住原则架构很快就变成一张废纸。我自己有两个小习惯在几个项目里反复验证过有效。第一代码评审里必须有一项是架构合规检查哪怕多花二十分钟也能拦住大部分跑偏的改动。第二定期做一次架构review不一定大张旗鼓每个迭代结束复盘一下看哪些模块开始变胖、哪些接口开始变多、哪些跨层访问“不小心”出现了及时修正比年底统一治理省力得多。后面有时间的话我准备继续写设计规范系列的下一个部分重点拆一下接口规范和数据定义这块涉及的内容更细踩过的坑也更多。如果你正在设计智能驾驶功能软件平台或者正在为架构评审发愁希望这篇内容的经验能让你少走一些弯路。说到底架构规范是在为整个项目降低不确定性把每个人的工作边界画清楚才能让整个团队在一条稳定、可预期的轨道上高效推进。