NOA 系统架构：高算力侧、车控侧和功能仲裁如何分工

很多 NOA 系统刚开始设计时最容易讨论的是算法感知怎么做预测怎么做规划怎么做控制怎么做。但真正进入工程集成后很快会遇到另一个更基础的问题这些能力到底应该放在哪一侧高算力侧有更强的计算资源适合做环境理解、决策规划和复杂状态管理。车控侧离底盘更近适合做车辆信号适配、执行器控制、基础辅助驾驶和安全兜底。功能仲裁则要站在两者之间决定当前到底哪个功能有效、哪路控制请求可以进入执行端、系统状态应该如何显示给用户。如果这三个边界没有拆清楚后面会出现很多典型问题规划有轨迹但车控不执行车控有控制量但 HMI 显示不一致高级功能退出时基础功能没有接住驾驶员已经接管但系统仍在输出控制请求。所以NOA 架构设计的重点不是简单回答“算法放在哪个控制器”而是回答三个问题高算力侧负责什么车控侧负责什么功能仲裁如何统一控制权。本文不讨论具体项目实现也不展开私有接口只从工程抽象角度拆解一套 NOA 系统中高算力侧、车控侧和功能仲裁的分工方式。1. 先看问题NOA 不是单控制器功能NOA 的功能链路天然跨越多个系统层级。上游要处理定位、地图、导航、感知、融合、场景模型和决策规划中间要处理功能状态、驾驶员意图、抑制原因、故障原因和降级策略下游要处理车辆状态、横纵向控制、底盘反馈、执行器限制和人机提示。这些任务对计算资源、实时性、安全边界和接口稳定性的要求并不一样。高算力侧更关心“怎么理解环境、怎么规划行为”。它面对的数据量大计算复杂模块更新快也更依赖场景语义。车控侧更关心“车辆当前能不能执行、应该怎么执行、异常时怎么兜底”。它面对的是底盘信号、执行器能力、车辆状态有效性和控制闭环稳定性。功能仲裁更关心“当前系统到底由谁说了算”。它不应该只是转发某一路状态而要把高级功能、基础辅助驾驶、主动安全、驾驶员输入和故障诊断统一成一个最终结果。可以把整套系统抽象成三层这张图的关键不是模块多少而是控制权的方向高算力侧可以提出高级功能请求和控制建议车控侧要确认车辆是否能执行仲裁层负责输出唯一的功能状态和唯一的控制来源。2. 高算力侧负责复杂场景理解和高级行为生成高算力侧通常承载 NOA 中更依赖算力和场景语义的部分。它的第一类职责是环境理解。系统需要把传感器、定位、地图、导航、车道线、道路边界、障碍物和自车运动状态组织成规划可用的场景表达。这里的数据量大算法迭代快也经常需要结合道路结构和目标语义做复杂判断。第二类职责是决策规划。比如当前是否跟车、是否变道、目标车道是哪条、是否需要绕行、如何处理慢车或切入车、如何生成横向路径和纵向速度。这些逻辑决定车辆接下来“想怎么走”。第三类职责是高级功能状态管理。NOA 不能只输出轨迹还要知道自己当前是否满足激活条件是否处于就绪、激活、抑制、超控或故障状态。高算力侧至少应该维护高级功能自身的状态和不可用原因。第四类职责是生成高级控制请求。规划输出轨迹后控制模块可以生成横向、纵向或轨迹跟踪相关请求再交给车控侧进一步仲裁和执行。但高算力侧不应该把自己理解成最终执行者。它可以说“我认为可以进入 NOA”“我给出了一条轨迹”“我请求某个加速度或转向控制”但它不能绕过车控侧直接决定执行器。原因很简单车辆状态、底盘限制、驾驶员输入、基础功能和主动安全都可能改变最终控制权。因此高算力侧输出的不是“最终命令”而是“高级功能请求”和“高级控制建议”。一个比较清晰的高算力侧输出可以包括高级功能状态关闭、等待、就绪、激活、抑制、超控、故障。高级功能可用性是否满足定位、导航、场景、规划、控制条件。抑制或故障原因用于仲裁、HMI 和诊断。规划结果目标车道、行为决策、路径、速度或轨迹。控制请求横向控制请求、纵向控制请求或轨迹跟踪请求。降级建议高级功能不可用时是否建议保留基础横向或纵向能力。这样设计的好处是高算力侧能充分发挥复杂算法能力同时不会侵入车控侧的执行安全边界。3. 车控侧负责车辆接口、基础功能和执行安全车控侧的核心价值是把辅助驾驶能力落到真实车辆上。它的第一类职责是车辆信号适配。不同车型、不同底盘、不同供应商接口的信号定义并不完全一致。车控侧需要把车速、档位、方向盘、制动、油门、车门、安全带、底盘状态、执行器反馈等信号整理成系统可用的统一输入。第二类职责是基础辅助驾驶能力。比如基础巡航、车道保持、自动变道的执行约束、主动安全相关请求等。这些功能即使没有完整 NOA也常常需要独立工作并在高级功能不可用时承担降级出口。第三类职责是控制执行。车辆最终执行的是加速度、制动、扭矩、转向、灯光、声音、显示等请求。无论上游规划多复杂进入执行端之前都必须经过统一控制出口完成限幅、滤波、保持、平滑切换和安全检查。第四类职责是安全兜底。车控侧更接近底盘和执行器应当能识别关键车辆状态无效、执行器不可用、驾驶员强接管、底盘安全功能介入、关键通信超时等风险并在必要时抑制、降级或退出自动控制。车控侧的设计原则是不盲信上游也不重复上游。不盲信上游是因为高算力侧给出的轨迹或控制请求必须结合车辆当前能力才能执行。比如车辆处于非目标档位、驾驶员踩下制动、车门打开、底盘稳定性控制介入、关键消息超时这些情况下即使上游给出轨迹车控侧也不能直接执行。不重复上游是因为车控侧不应该重新做一套复杂环境理解和行为决策。否则两个侧会对同一场景形成两套判断反而增加冲突。车控侧更适合关注车辆可执行性、控制平顺性和安全约束。车控侧输出的关键结果通常包括标准化车辆状态和驾驶员输入。基础辅助驾驶功能状态和控制请求。执行器状态、底盘反馈和车辆限制。车控侧抑制、故障和降级原因。最终执行控制量。面向 HMI 和诊断的状态反馈。如果说高算力侧决定“高级功能想怎么开”车控侧决定的就是“这辆车现在能不能这样开以及最终怎么执行”。4. 功能仲裁统一功能模式而不是简单转发状态高算力侧和车控侧都会产生状态。高算力侧会说 NOA 是否可用、是否激活、是否需要降级。车控侧会说基础辅助驾驶是否可用、驾驶员是否接管、底盘是否允许控制、是否有执行器故障。主动安全功能也可能在某些风险场景下提出更高优先级请求。如果每个模块都把自己的状态直接发给 HMI 或控制端系统很快就会变成“各说各话”。功能仲裁要解决的就是把这些状态合成一个最终功能模式。它至少要处理几类关系高级功能和基础功能的关系NOA 可用时优先高级功能不可用时评估是否可降级到基础功能。自动系统和驾驶员的关系驾驶员制动、转向、油门等输入应优先于舒适性控制。普通辅助和主动安全的关系主动安全请求通常应具备更高优先级。抑制和故障的关系暂时条件不足可以等待或降级关键故障必须退出或禁止激活。内部状态和 HMI 的关系用户看到的状态必须来自最终仲裁结果而不是某个子模块的局部判断。可以把功能仲裁抽象成下面的流程这里有一个重要细节功能仲裁输出的是“模式”和“原因”不是直接输出执行器控制量。比如功能仲裁可以决定当前是 NOA、基础巡航、横向超控、纵向超控、故障退出或者抑制等待。但最终横向采用哪路转向请求、纵向采用哪路加速度请求还需要控制仲裁来决定。5. 控制仲裁统一控制出口处理切换体感功能仲裁解决“当前是什么模式”控制仲裁解决“当前采用哪路控制量”。这两个层次必须分开。举例来说系统处于 NOA 模式时横向和纵向都可能来自高级规划控制。但驾驶员轻踩油门后纵向可能进入超控横向仍由系统保持。NOA 高级路径不可用时纵向可能降级到基础巡航横向可能退出或保留基础车道保持。主动安全触发时纵向制动请求可能临时覆盖舒适性控制。这些都不是单纯的功能模式能表达清楚的。控制仲裁至少要输出三类结果当前横向控制源高级横向、基础横向、驾驶员、退出。当前纵向控制源高级纵向、基础纵向、主动安全、驾驶员、退出。切换策略保持上一帧、渐变、滤波、限幅、重置或直接退出。控制仲裁的工程难点不在于选一个优先级而在于切换那一下。如果上一帧还在用高级规划的加速度下一帧突然切到基础巡航上一帧方向盘还在跟踪轨迹下一帧突然释放或切换控制器用户会非常敏感。功能逻辑可能是正确的但体感会很差。因此统一控制出口需要配合几类保护控制源切换前后保留上一帧有效控制量避免输出空洞。对加速度、转角、转角速度或扭矩请求做限幅和滤波。在标定时间窗内完成控制源渐变避免突变。驾驶员强接管和主动安全请求保留快速响应通道。控制器重置、轨迹重规划和状态切换要有明确同步关系。可以把控制仲裁理解成这样对用户来说他们不会关心当前控制量来自哪个模块他们只会感受到车辆是否突然顿挫、方向盘是否跳变、功能退出是否突兀。控制仲裁就是把系统逻辑正确转化为驾驶体感自然的一层。6. 通信分层实时控制和状态诊断分开设计高算力侧和车控侧之间必须通信但不是所有消息都应该走同一种链路。车辆状态、驾驶员输入、关键底盘信号、控制请求和执行反馈属于高实时链路。它们直接影响控制闭环要求延迟稳定、周期明确、丢帧可诊断。状态机、功能仲裁、诊断原因、调试信息、环境摘要等消息更适合走通用状态链路。它们需要表达更完整结构更灵活更新频率也不一定和控制闭环完全一致。如果把所有消息都塞进同一条链路很容易出现两个问题控制信号被大体量状态消息阻塞或者状态诊断被实时链路格式限制得过于贫乏。更合理的方式是分层通信分层的目标不是让架构更复杂而是让控制闭环和诊断表达各自稳定。工程上还要特别关注消息超时。对高实时链路来说超时本身就是一种控制风险对状态诊断链路来说超时可能导致 HMI 和内部状态不一致。两类超时都要进入状态机和仲裁闭环而不是只在通信模块里打印日志。7. 控制权流转从高级功能到基础功能再到驾驶员NOA 架构的核心不是“高级功能永远优先”而是控制权可以有秩序地流转。正常情况下高算力侧生成高级功能请求功能仲裁确认车辆条件和驾驶员状态后进入 NOA 模式控制仲裁选择高级横纵向控制源车控侧统一输出执行器请求。当高级功能条件不满足但基础功能仍可信时系统可以从 NOA 降级到基础辅助驾驶。例如导航或高阶场景条件不可用时保留基础纵向巡航自动变道条件不满足时保留车道内辅助横向不可用但纵向可用时只退出横向。当驾驶员接管时驾驶员输入必须进入更高优先级。方向盘接管影响横向控制源油门或制动影响纵向控制源。这里要避免一个常见错误把驾驶员接管理解成整个系统立即全退出。更细的做法是区分横向超控、纵向超控和完全退出。当关键故障发生时系统不应再追求功能连续性而要优先退出或进入安全降级。关键执行器异常、车辆状态无效、控制链路超时、底盘安全功能介入等问题都应该能触发明确的退出策略和 HMI 提示。这个控制权流转可以抽象为这个图里最重要的是“重新确认”。高级功能从降级或超控状态恢复到 NOA不应该只因为某个信号恢复就自动抢回控制权。是否需要驾驶员确认要根据功能等级、法规要求、场景风险和产品策略设计。8. 常见架构坑第一高算力侧直接输出最终控制命令。这样做短期看链路简单长期会绕过车辆状态、底盘约束和驾驶员接管导致执行安全边界不清。第二车控侧重复做复杂决策。车控侧如果重新判断目标车道、行为决策和复杂场景很容易和高算力侧形成双主逻辑后续问题很难定位。第三功能仲裁和控制仲裁混在一起。最终功能模式和最终控制源不是同一个问题混在一起会导致状态显示正确但控制切换不平顺或者控制执行合理但 HMI 表达混乱。第四HMI 直接取子模块状态。用户看到的状态必须来自最终仲裁结果否则很容易出现高算力侧显示可用、车控侧实际不允许执行的矛盾。第五高级功能不可用就直接全退出。很多场景下基础功能仍然可信粗暴退出会放大接管压力也浪费了系统已有能力。第六只做功能优先级不做原因码。没有抑制、故障、超控和降级原因系统出了问题只能靠猜测试和量产排查都会很痛苦。9. 调试方法沿控制权链路逐层收缩排查 NOA 进不去、突然退出、降级不符合预期、HMI 和控制不一致这类问题不要一上来就盯着规划或控制算法。更有效的方法是沿控制权链路逐层收缩先看高算力侧高级功能状态是否满足规划是否有有效输出抑制原因是什么。再看车控侧车辆条件是否允许驾驶员输入是否触发超控底盘或执行器是否有异常。再看功能仲裁最终功能模式是什么为什么没有选择 NOA是否进入降级或退出。再看控制仲裁横向和纵向控制源分别是谁是否发生控制源切换切换策略是否生效。最后看执行反馈控制请求是否真正进入执行器执行器反馈是否符合预期是否存在超时或限幅。这里有一个很实用的判断如果高算力侧有轨迹但车不动优先查车控侧条件、功能仲裁和控制仲裁如果 HMI 显示功能可用但控制没有进入执行端优先查最终仲裁结果是否被 HMI 和控制端共同使用如果功能退出但没有明确原因优先查抑制和故障原因是否在两侧都进入了状态闭环。10. 架构设计 checklist设计或评审 NOA 系统架构时可以按下面的问题自查高算力侧是否只输出高级功能请求、规划结果和控制建议而不是绕过车控侧直接控制执行器。车控侧是否统一适配车辆信号、基础辅助驾驶状态、执行器控制和安全兜底。高级功能状态、基础功能状态、驾驶员输入、底盘状态和故障原因是否都进入功能仲裁。功能仲裁是否输出唯一最终功能模式和 HMI 状态。功能仲裁和控制仲裁是否分层横向和纵向控制源是否可以独立选择。高级功能不可用时是否评估基础横向或纵向能力能否保留。驾驶员接管是否区分横向超控、纵向超控和完全退出。控制源切换是否有保持、滤波、渐变、限幅或重置策略。实时控制链路和状态诊断链路是否分层设计。消息超时、执行器异常、底盘安全介入是否能触发明确的抑制、降级或故障退出。HMI 是否只展示最终仲裁结果而不是某个子模块的局部状态。日志是否能复盘每一次激活、抑制、超控、降级和退出。11. 结语NOA 系统架构不是把高算力控制器、车控控制器和几个算法模块连起来就结束了。真正关键的是控制权边界高算力侧负责复杂场景理解和高级行为生成车控侧负责车辆接口、基础功能、执行控制和安全兜底功能仲裁负责把多路状态统一成唯一功能真相控制仲裁负责把多路控制请求统一成唯一执行出口。这套分工清楚之后系统才知道什么时候可以进入 NOA什么时候应该降级到基础辅助驾驶什么时候要响应驾驶员接管什么时候必须故障退出。从用户角度看这是功能状态清楚、切换平顺、退出有理由。从工程角度看这是问题可定位、接口可演进、系统可验证。这也是 NOA 从单点算法走向整车工程时必须补上的架构能力。