很多 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 从单点算法走向整车工程时，必须补上的架构能力。