智能驾驶需要很多不同专业的人协同工作，并不是所有人都是软件或汽车软件背景。为了能让各种不同背景的人都能一定程度上理解文章内容，本文尽量采用非常通俗的语言来描述，并配合各种图来进行阐述。本文避免使用有歧义的术语，所有术语在第一次出现时都给出其在本文的准确定义。

智能驾驶软件架构的重要性

智能驾驶的简化概念模型

智能驾驶的概念模型简单来说就是解决三个核心问题：

1. 我在哪？

2. 我要去哪？

3. 我该如何去？

第一个问题“我在哪？”需要解决的是“环境感知”和“定位”问题，需要了解的是车自身的位置以及该位置周边的静态环境（道路，交通标识，信号灯等）和动态环境（车、人等）。由此引发一系列的感知和定位的技术方案，包括各种传感器以及算法体系。

第二个问题“我要去哪？”在自动驾驶领域就是“规划决策”。由此延伸出一些术语“全局规划””局部规划"、“任务规划”“路径规划”、"行为规划”、“行为决策”“运动规划”，等等，由于语言上的歧义，这些术语有的是同一个意思的不同说法，有的其含义在不同场合经常相近但又有点差别。

抛开具体的术语，一般而言这“规划决策”这个问题都会被分解为三部分：

1. 在一定范围内的全局意义上的规划 （常用术语：全局规划，路径规划，任务规划)

2. 将第一步的结果做划分出多个阶段 （常用术语：行为规划，行为决策）

3. 对每一个阶段进行进一步的规划 （常用术语：局部规划，运动规划）

对于这些各种各样的规划衍生出很多解决问题的算法体系。

第三个问题“我该如何去？”一般指的就是“控制执行”，也就是对最小一个规划的实际执行实践，达到规划的目的。具体在车上，往往体现为各种控制算法，控制理论解决的就是这些问题。

因为这三个问题的解决归根到底都是算法问题，所以某种意义上，说自动驾驶的核心就是算法。而软件架构从某种意义上说，就是要能承载这些算法。没有很好的承载体系，再好的算法也无用武之地。

基础概念模型的分形递归特性

为了方面我们把基础概念模型的三个问题分别表示为 E , P, X,分别代表 环境(Environment)、计划(Plan)、执行(eXecute)。每一组 E-P-X 都有其描述问题空间。

比如说，我们定义问题空间 A 是“驾车从北京到广州”，那么对于问题 E：其定位关注的可能就是当前在北京那个区，不必细化到街道。我们还需要关心天气是否有雷暴雨，省道以上的道路结构信息。对于问题P：

P-1 : 第一步先设计出一个全局的路径，走哪条高速、国道、省道

P-2 ：根据全局路径计划出一系列行为组成，先到哪个高速路口，行驶多少公里，去服务区加油、更换到另一条道路等等

P-3：计划出到每一段的具体道路路径。比如到高速路口要走三环还是四环，在换到哪条路上

X 要执行 P 规划出来的每一步。

如果我们定义问题空间 B 是“驾车安全通过一个路口”，那么对于E 问题，要关注的是当前的道路信息、交通灯信息、道路上的车辆状况、行人状况等。对于P 问题：

P-1 ：第一步先规划出通过路口的安全路径，包括根据交通规则和道路信息计划到达当前路口的哪个车道，进入目标路口的哪个车道。

P-2 ：第二步要第一步的根结果规划出一系列动作序列，如先减速，切换目标车道，停车等红灯，起步加速，通过路口。

P-3 ：第三步对第二步的每一个动作要设计具体的一段轨迹，轨迹要能避开行人车辆等障碍物。

X 负责执行执行 P 问题的输出结果。

这个问题空间 B 是最接近通常规划算法要解决的问题。其中 P-1 的第一步常称为“全局规划”或“任务规划”，P-2 常被称为“行为规划”或 “行为决策”，P-3 被称为“局部规划”或“运动规划(Motion Plan)”。如下图所示，E-P-X 形成抽象的基础概念模型，问题空间 A 和 B 都是其在某个范围上的具体实现。

☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

图 1 两个EPX的问题空间

A 和 B 两个问题空间都有 相似的 E-P-X 结构，但是他们解决的问题在时间和空间上的跨度差别很大。上图中 A:X 需要执行的任务 “完成进入北四环”完全可以下一级的 EPX 循环去完成。所以实际上，如下图所示 E-P-X 模型是一个分形递归的结构。

图 2  EPX的分形递归结构

上一级的 X 总能被下一级的再一次分解为更小粒度的 E-P-X 来执行。

"分形" 又称为“自相似分形”，其通俗理解是事物的局部与整体有相似的结构，是在不同尺度上的对称，例如一颗树的一支树枝与整颗树是相似的结构，再进一步，每片树叶的茎脉也是相似的结构。下图列举了一些典型的分形结构。

图3 分形示例

这 6 个图形都有一个特点，每个图形的任何一个局部都与整个图形的结构是一样的。局部进一步放大，会发现局部的局部也是同样的结构。因此当我们有一套业务处理逻辑能够适用于整体，也同样可以适用于局部。就像有些树的培育，可以取一根树枝种下去，会长成一棵新树。映射到软件程序的表达，就是“递归”。这并不是说使用递归函数来处理，是指架构层级的递归。

“分形”更学术化的表达是"用分数维度的视角和数学方法描述和研究客观事物，跳出了一维的线、二维的面、三维的立体乃至四维时空的传统藩篱，更加趋近复杂系统的真实属性与状态的描述，更加符合客观事物的多样性与复杂性“。当我们为“物理现实”找到合适的数学表述，再转换为“程序现实”，就能找到更简洁、清晰、准确的软件架构及实现方式。

软件架构解决“物理现实”到“程序现实”的映射

E-P-X 是根据“物理现实”抽象出来的结构。而且其中绝大部分都是各种各样的是算法的工作。单个算法本身的研究和开发可以根据预定义的输入输出条件独立进行。但是算法怎么组合起来，在合适的时机被正确的触发，其结果被合理使用，才能最终形成有实际用途的功能。这个从“物理现实”到“程序现实”的桥梁核心就是软件架构。

自动驾驶系统从 Level 1 到 Level 5， 越往上，上述 E-P-X 模型的嵌套深度就越多。软件架构上的难度也就越大。大部分单一的 Level1 和 Level2 功能只需要一层 E-P-X 模型。以 AEB (自动紧急刹车）为例：

E 部分(感知) ：主要就是对前方目标（车，人）的静态识别和分类、动态跟踪，检测距离和速度。

P 部分: 因为 AEB 只做纵向的控制，可以全部通过对速度的控制来实现。所以只需要做对一段时间内的速度做出规划。

X 部分：将速度规划交由车辆控制单元执行。

并不是说只有一层 EPX ，AEB功能就简单。实际上 能够量产的 AEB 功能实现难度一样是非常大的。不过一层的 EPX , 就不需要基于场景进行调度，只需要关注与单一场景下 EPX 的实现，其软件架构就相对简单。第二章会介绍 L2 功能常见的软件架构。

什么叫基于场景的调度？

即便是在最小粒度层级的 EPX 循环中，也不是一个EXP的实现就能解决这一层级的所有问题。

比如：就一个简单的直线行驶用例，我们可以将最末端 X 单元实现为一个车辆控制算法，这算法处理完所有的平道、上坡、下坡场景。也可以使用一个调度单元（S），根据 E 单元的信息，将平道、上坡、下坡识别为不同的场景，切换不同的 下一级 EXP 循环。下一级的每个 EXP 循环实现单一的场景。实际上，即便使用一个 X 单元的控制算法解决所有平道、上坡、下坡场景，这个算法内部也一样会对这些场景进行区分，实际还是一个微小粒度的 EXP 循环。

图4  EPX的调度

如图 4所示，场景的调度（S) 可以在每一个层级都有，也就是说对“场景”的定义也有粒度的划分。所以 ，EPX模型应该是 EPX-S 模型。只是在 L2 以下没有明显的 S 部分。

软件架构上如何兼容 L1 到 L3+

自动泊车辅助功能就开始有场景调度的需求，比如垂直泊车、垂直泊入、水平泊出、水平泊入、斜向泊入等等都是不同的场景，其 P 和 X 部分都需要分别实现。但是场景调度可以通过HMI界面由人工来选择，是一个“人在回路中”的 S 单元。

Level 3 以上功能中，很长一段连续的驾驶过程都不需要人工干预。就必然涉及到多个不同的 EXP层级自动调度。这样在软件架构上就跟L2以下功能有很大不同。这也是为什么很多公司把 L2 和 L3+分成两个不同的团队的原因之一。

实际上只要是有意识的基于多层级的 EXP-S 模型来设计软件架构，每一个EXP-S单元都有其合适的体现，实际上是可以实现一套软件架构支持从 L1到L3+以上的自动驾驶基本。只是说 S 单元对 L2以下功能来说比较弱一些，但是其架构地位仍然存在。

L2及以下单一功能控制器的软件架构

我们先来看一下L2 功能的常用软件架构，我们对常用

使用Smart Sensor 的 AEB/ACC/LKA 解决方案

AEB/ACC/LKA 三个功能是 L2 最经典的驾驶辅助功能，一般的系统方案的感知部分多采用前向的摄像头输出目标(车辆、行人)信息，并与前向毫米波雷达给出的目标数据做融合，得到更准确的速度和距离。视觉感知和雷达感知多采用Smart Sensor 方案，这样 Tier 1 可以选用成熟的 Tier2 供应商的产品。Tier 1 主要的开发工作在感知融合与功能状态机的实现以及车辆控制算法。

常用的硬件架构

方案一：视觉感知结果传递给雷达感知控制器，雷达感知控制器中完成感知融合和 L2功能状态机

图 5 方案一拓扑

方案二：独立的L2 控制器连接 视觉和雷达的Smart Sensor，L2控制器完成感知融合和 L2 功能状态机

图 6 方案二拓扑

两个方案都是经常被采用的。方案一采用较高性能的雷达控制器，分配部分计算单元用来实现融合算法和功能状态机。很多芯片厂商做雷达处理芯片设计时就考虑到这部分算力预留。比如NXP 专为雷达ECU设计的 S32R 系列，其多核心足够同时做雷达信号处理与 L2 的功能实现。毕竟最耗算力的视觉算法是在另外器件上完成的。

方案二单独独立出来 L2实现 L2 功能的控制器, 通过私有Can 与两个 Smart Sensor 通讯获取感知数据。一般来说，这个方案可以考虑后续增加更多的 L2 功能，如果有需要，可以再接更多的 Smart Sensor。

典型的软件架构

对于采用 Smart Sensor 的系统架构来说，前向智能摄像头和前向毫米波雷达分别给出各自观测到的环境中目标对象的语义。这两部分数据直接通过 Can 总线或内部的 IPC (计算机OS的进程间通讯)机制传递给负责感知融合和 L2 功能实现的模块。

无论是硬件方案一还是方案二，业内最常用的软件架构是基于 Classic AutoSar 来开发。Classic AutoSar 提供了车载ECU通用的功能并为引用软件提供执行环境和数据输入输出通道。感知融合模块和其它 ACC/AEB/LKA 功能可以实现为一个或多个 AutoSar SWC（软件组件）。具体这些 SWC 组件是否进行拆分，如何拆分，各家开发商有自己的合理逻辑。但基本架构大同小异。

当然也可以不采用 Classic AutoSar , 用其它合适的 RTOS 作为底层系统，或许对于车载ECU需要通用功能开发和达到功能安全标准的难度会大一些，但在应用功能开发的架构体系上跟采用 Classic AutoSar 的方案没有太大差别。

图7 ACC/AEB/LKA 的典型软件架构

MBD开发方式

业内常用MBD（基于模型的开发）方式来实现感知融合算法，规划和控制执行算法以及 ACC/AEB/LKA 功能状态机。然后使用工具生成 C 代码，再手动集成到目标平台。MDB开发方式的一个便利之处在于可以先使用模型工具和 CanOE 之类的设备直接上车开发调试，或者与仿真平台连接进行开发调试。这样开发团队可以分成两部分，一部分人用模型工具开发应用功能，一部分人开发所有车载ECU都需要的一系列繁琐工作，然后再集成在一起。

集成度更高的产品解决方案

一般全自动泊车产品会采用集成度更高的方案，在一个 ECU 内将视觉算法（静态障碍物识别，动态障碍物识别，行人识别，车位线识别）超声波雷达算法（距离检测，障碍物检测）泊车过程的轨迹规划和控制执行，都放在一个控制器内完成。集成度更高的还会在自动泊车控制器中同时 支持360环视功能，这就还需要支持摄像头环视图像的校正和拼接2D/3D 的图形渲染视频输出HMI 生成等功能。
 示意性的硬件拓扑如下。

硬件拓扑示意

图 8  泊车系统的硬件拓扑方案

图中的各个模块在不同的硬件选型方案中有不同的分布模式。一般情况下用于实时处理的 MCU 会单独使用一颗芯片。不同的芯片厂家有各自的 AI 单元解决方案。有的用高性能的 DSP,有的专有的矩阵计算单元，有的用FPGA, 不一而足。

典型的软件架构

下图是自动泊车系统一个典型的软件架构(只是简化后的示意，实际量产系统会复杂更多)：

与 2.1.1 相比，这里最显著的改变就是区分了“实时域”和 “性能域”两套系统。一般来说，我们把MCU或其它实时核心（Cortex-R,Cortex-M 或其它对等系列）上的软硬件系统成为“实时域”。把 SOC 内的大核心(Cortex-A或对等系列）以及运行在其上的 Linux/QNX 统称为性能域，这里面一般还包含了支持视觉算法加速的软硬件体系。

虽然从量产的工程化难度上，全自动泊车系统比 ACC/AEB/LKA 等 Level2 主动安全功能要小很多。但是在软件架构上，泊车系统却复杂很多。主要体现在以下方面：

图 9  泊车系统的软件架构

实时域和性能域的划分带来系统性的复杂度，需要根据实时性要求和计算资源的要求，为不同的计算选择不同的硬件平台

• 性能域的 OS 采用 Linux 后 ，OS 级别的执行环境比RTOS复杂很多
• 需要一系列的框架或中间件来支持应用的开发
• 数据通路复杂性
• 增加了视频流的处理通路
• 增加了实时域和性能域之间的数据通路需求
• 性能域各个软件模块之间有数据通讯要求
• 落实到具体的芯片平台解决方案后，架构设计需要跟芯片的各种 SDK 进行整合和统筹设计

另外，通过这个软件架构可以看到，引入Linux (或QNX/vxworks)后带来的一些问题。这些系统本身是与特定行业无关的计算机操作系统，当被用于汽车电子控制器的时候，会有一系列与特定产品功能无关，但是作为汽车 ECU 需要具备的通用功能需要实现。比如诊断、时钟同步、升级等等。这部分在整体的控制器开发中占了非常大的工作量，很多情况下会超过40%，而且跟控制器的可靠性非常相关。

在网络通讯设备领域，这些往往被称为管理平面。很多也是 AutoSar AP 提供的基础能力。实际上无论是 CP AutoSar 还是 AP AutoSar ，除了负责通讯的模块，其他大部分都是管理平面的能力。

多个单一功能的 ECU 的协同

如果一辆车上有多种 L2 功能该如何协同工作。下图是一个简化的多控制器拓扑示例。

图10 多个L2 功能控制器加域控制器的拓扑方案

这个拓扑中集成了6个控制器，“全自动泊车系统”“前向智能摄像头”和“前向毫米波雷达”提供的功能如前面所述。左右角雷达是两个镜像的设备，各自独立运行可以实现“后车逼近告警”，“开门告警”等功能。“驾驶员监控系统”检测驾驶员的状态，发现驾驶员疲劳驾驶时可以给出告警，如果驾驶员完全失去行动能力，就通知其它系统尝试减速靠边停车。

这个拓扑中有如下要点：引入域控制器连接多个独立的驾驶辅助功能控制器，域控制器与骨干网连接；驾驶辅助域内多条 Can 总线，避免总线带宽不够。

从软件架构上讲，各驾驶辅助控制器独立运行，自主决定自己的功能开启和停止。相关控制信号发送给域控制器，由域控制器转发到动力域。驾驶辅助域控制器要负责对各独立控制器的控制输出做出裁决。从域控制器在这里可以起的作用看，由轻到重有各种可能的设计。轻量化的域控制器设计中，域控制器只做简单的数据转发，将骨干网上的数据筛选后发送到域内的控制器。将域内控制器的控制信号发送到骨干网。这种方式对域控制器的算力要求不高。

域控制器再多承担一些工作就可以把其它控制器的实时域部分的计算工作接管过去。比如ACC/AEB/LKA 的规划控制计算都放在域控制器中进行。这就要求其他控制器把感知数据发送给域控制器，由域控制器统一处理。这对算力要求就更高了一些。同时对域内网络的带宽要求也提高了。

更进一步，因为能拿到所有的感知数据，域控制器还可以开发出一些增加的功能，比如依靠图中的传感器，有可能在域控制器中实现变道辅助或紧急避障的功能。

在功能逐步往域控制器集中的过程中，承担了感知部分的其它控制器的非感知部分就被逐步弱化。

EPX-SA 概念模型

仲裁机制

前面说到，ACC/AEB/LKA 功能实现，全自动泊车的实现，以及其他的单一 L2 以下功能，都可以理解为一层或两层分形递归的 EPX-S 模型。

其实 ACC/AEB/LKA 这三个功能，在实际量产产品中就是可以同时开启的，每个都是一个单独的 EPX-S 循环。也就是说多个 EPX-S 循环是可以同时并行运行的。如果同时产生的 X 输出，需要由一个仲裁机制进行裁决（Arbitration）。

当有多个控制器同时运行的时候由域控制器在更高层级上进行仲裁。

所以 EPX-S 模型应该被扩展为 EPX-SA 模型。如下图所示，场景1和场景2是两个并行运行的 EPX-S 循环，它们产生的 X 被经过仲裁后输出。

图 11  EPX-SA 概念模型

环境模型概念的提出

每个实现单一 L2 功能的控制器都有某一方面的感知能力。都描述了车辆内外环境中某一个方面的属性，可以从空间上的角度、距离进行划分，也可以从物理属性进行划分，如可见光，超声波，毫米波，激光。如果对整个环境建立一个理想的完全准确的3D模型系统，每一个传感器就相当于这个模型的一个过滤器，像“盲人摸象”一样，各自表达了理想模型某一方面的属性。

智能驾驶的感知部分，实际上就是用尽可能多的传感器加上算法来达到对理想模型的逼近。可用的传感器越多，算法越准确，与理想模型的偏差就越少。

L2的域控制器中，如果需要，可以取到所有下级控制器的感知数据，那么在这一级，就可以基于所有的感知结果拼出一个理想环境模型的现实模型，虽然与理想模型还有很大差距，但是已经是一个整体意义上的环境模型。

环境模型提供的信息，不仅仅用在各级的规划模块(P)，在调度(S) 和仲裁（A)阶段一样会被用到。