智能驾驶功能软件平台设计规范 第一部分：系统架构

2020-07-29 发布

1 规范应用范围

本规范规定了智能驾驶功能软件平台的系统架构、功能模块和算法组件划分。

本规范适用于 GB/T《汽车驾驶自动化分级》[2]所定义的 2 级及以上的驾驶自动化系统即智能驾驶系统。

2 规范引用文件

本规范的引用和参考文件见下表：

[1] GB/T《汽车驾驶自动化分级》

[2] ISO/DIS 23150:2020(E) Road vehicles — Data communication between sensorsand data fusion unit for automated driving functions — Logical interface

[3] ADASIS(Advanced Driver Assistance Systems Interface Specification) v3

[4] CSAE 线控转向及制动系统通讯协议要求及测试规范

[5] ISO 8855:2011 Road vehicles — Vehicle dynamics and road-holding ability

[6] 智能驾驶功能软件平台设计规范 第二部分：感知融合功能服务接口

[7] 智能驾驶功能软件平台设计规范 第三部分：预测功能服务接口

[8] 智能驾驶功能软件平台设计规范 第四部分：决策规划功能服务接口

[9] 智能驾驶功能软件平台设计规范 第五部分：定位功能服务接口

[10] Wang, Yansen & Huynh, Giap & Williamson, Chatt. (2013). Integration of Google Maps/Earth with microscale meteorology models and data visualization. Computers & Geosciences. 61. 23–31. 10.1016/j.cageo.2013.07.016.

3 缩略语

文档中可能使用到的缩写说明如下所示：

缩略语 英文全名 中文解释

AD Autonomous Driving 自动驾驶

ADAS Advanced driver-assistance systems 高级辅助驾驶系统

SAE Society of Automotive Engineers 国际汽车工程师学会

ODD Operational Design Domain 设计运行区域

APP Application 应用程序

NN Neural Network 神经网络

V2X Vehicle To Everything 车联网

IMU Inertial Measurement Unit 惯性测量单元

HMI Human Machine Interface 人机交互接口

LKA Lane Keep Assistance 车道保持辅助系统

UTM Universal Transverse Mercator 通用横墨卡托格网系统

4 智能驾驶计算平台

智能驾驶计算平台自底向上可以划分为硬件平台、系统软件、功能软件和应用软件等四层结构。硬件平台基于异构分布式架构，提供可持续扩展的计算能力。系统软件包括操作系统和中间件，为上层提供调度、通信、时间同步、调试诊断等基础服务。功能软件层包括感知、决策、规划和控制等智能驾驶核心功能的算法组件。硬件平台层、系统软件层和功能软件层共同向上支撑应用软件层的开发，最终实现智能驾驶系统产品化交付。

5 智能驾驶功能软件平台系统架构

智能驾驶功能软件平台基于不同厂商的技术实现方案进行功能抽象，共分为传感器抽象功能、感知融合功能、预测功能、决策规划功能、定位功能和执行器抽象 6 个功能模块。主机厂基于自身策略，在设计和开发功能软件时可以选择不同的功能模块和算法组件，实现拼插式功能组合，灵活构建智能驾驶系统级解决方案。具体的构建示例可参考附录 A。

• 传感器抽象功能对毫米波雷达、激光雷达、摄像头、超声波雷达、GNSS、IMU 和轮速计等车载传感器的环境感知情况进行数字抽象。传感器抽象是针对于单个传感器的输出抽象，输出包括测量原始数据、特征数据以及目标数据中的一种或多种;

• 感知融合功能对传感器抽象模块的输入数据进行融合，结合多种传感器的特性、工况和环境信息，完成对物理世界的数字呈现。感知融合功能支持根据不同传感器的组合从而实现不同的感知任务。其中，传感器组合可以是激光雷达、摄像头、毫米波雷达中一种或者多种的组合；感知任务包括移动目标识别与跟踪、自由空间、交通灯和交通标志识 别、道路结构识别等;

• 预测功能依据环境信息和交通参与者历史测量信息，对其他交通参与者的未来行驶意图和轨迹进行预测。其中，其他交通参与者包括行人，车辆，非机动车等。预测功能的输出是决策规划功能的关键输入之一，特别是在城市交叉路口等场景下，对行人、目标车辆等障碍物的轨迹预测效果将严重影响智能驾驶系统的整体表现;

• 定位功能根据高精度地图、传感器等信息输入提供自车位置，包括本车的绝对位置以及在静态动态环境中的相对位置；

• 决策规划功能根据感知融合、自身定位和交通参与者预测等信息输入来完成自车行驶轨迹的决策和规划，并根据决策结果输出对车辆的控制命令或者告警信息;

• 执行器抽象功能执行决策规划模块输出的车辆控制命令，驱动汽车的转向、驱动和制动等执行部件。

5.1 坐标系设定

本规范中使用多个坐标系统来描述自动驾驶汽车和周边环境模型，包括全球地理坐标系（GNSS 系统）、局部地理坐标系（地图系统）、车体坐标系（感知融合、决策规划等功能）。

坐标系是定位服务中提供的位置、速度等信息的参照系统，同样的车辆运动状态在不同坐标系中会有不同的标识，因此描述一个位置信息时，必须指定相应的坐标系。这些坐标系将以笛卡尔坐标系来描述。

车体坐标系

参考 ISO 8855:2011 Road vehicles — Vehicle dynamics and road-holding ability[5]中的定义，车体坐标系以车辆后轴中心为原点，x 轴指向车辆前进方向，y 轴指向车辆前进方向的左侧方向，z 轴指向车顶方向，构成右手直角系。

局部地理坐标系

对局部地理坐标描述采用站点坐标系（East North Up, ENU），构建地球表面上建立的 3D笛卡尔坐标系（X,Y,Z），如下图 4 所示。对于地球表面局部坐标系采用 UTM 系统作为投影的平面 2D 笛卡尔坐标系描述物体位置（X,Y）。UTM 系统将地球分为 60 个区域，每个区域的经度为 6°。1 区的经度为 180°至 174°W；区域编号向东增加到区域 60，其覆盖东经 174° E 至 180°。排除 80°S 以南和 84°N 以北的极地地区。60 个区域中的每一个区域都使用墨卡托横向投影，该投影可以绘制南北大范围的区域且失真很小。具体使用方式参见：http://geokov.com/education/utm.aspx。

全球地理坐标系

对导航、高精地图及其延伸概念用到的全球地理坐标系统，主要采用WGS-84坐标系统，用来描述物体的全球地理坐标：经度、纬度和海拔。WGS-84 坐标系是基于经线纬线网所划定的一种坐标系统，以 0°经线作为起点，向东划分 0°~180°，为东经度；向西划分 0°~180°，为西经度。WGS-84 坐标系原点位于地球质心，x 轴指向本初子午线和赤道交点，z轴指向国际时间局 BIH 1984.0 定义的协议地球极方向，y 轴通过右手定则确定。

6 功能模块

6.1 传感器抽象功能

传感器抽象功能主要提供两种类型的服务接口，一种是智能传感器的信息服务接口，传感器类型包括摄像头、激光雷达、毫米波雷达和超声波雷达中的一种或者多种，提供的信息包括原始数据、特征数据和目标数据中的一种或者几种。这些数据主要是依赖于单个传感器的输出，同时也会提供传感器的性能和状态信息；另外一种是其他车载传感器，包括汽车内常用的传感器，既有传统的轮速传感器、加速度传感器、里程计、车辆行驶状态等反应车辆本身状态的传感器，也包含全球定位系统、惯性导航系统等定位传感器，以及通过 V2X 和其他车辆、路侧基础设施、云端等进行信息交互的 V2X 通信模块。传感器抽象服务接口不在智能驾驶功能软件平台设计规范中定义，可以参考 ISO/DIS 23150:2020[2]等规范中的定义。

6.2 感知融合功能

感知融合功能基于各种传感器的输入，完成对动态交通参与者和静态交通环境信息的识别，输出可移动物体、道路结构、可行驶空间、静态目标和交通标志等信息服务，也可以综合输出完整的环境模型信息。

感知融合功能服务接口的具体内容在《智能驾驶功能软件平台设计规范 第二部分：感知融合功能服务接口》[6]中定义。

6.3 定位功能

定位服务依赖传感器抽象功能和感知融合功能中的部分服务，提供自车的绝对位置、姿态、速度和加速度等信息。

定位功能服务接口的具体内容在《智能驾驶功能软件平台设计规范 第五部分：定位功 能服务接口》[9]中定义。

6.4 预测功能

预测功能依据感知融合和自动定位等信息输入，对行人，车辆，骑行者等交通参与者的行为意图和行驶轨迹做出预测。具体的信息输入包括传感器获取到的可移动目标的当前数据和历史数据，含地图信息在内的周围静态交通环境信息，自车的位置和状态信息，通过 V2X获取到的交通参与者的信息等。其中，行人的姿态和手势、车辆灯光等信息都是预测服务的重要依据。

预测功能服务接口的具体内容在《智能驾驶功能软件平台设计规范 第三部分：预测功能服务接口》[7]中定义。

6.5 决策规划功能

决策规划功能是自车最终驾驶行为决策和轨迹规划模块，输出对于车辆姿态控制的控制命令。功能软件平台中的感知融合服务，定位服务和预测服务都是决策规划功能的输入信息来源。此外，决策规划功能中的路点导航组件还有另外的信息来源，驾驶员通过 HMI 接口将智能驾驶的目的地信息和用户要求作为信息输入。

决策规划功能服务接口的具体内容在《智能驾驶功能软件平台设计规范 第四部分：决策规划功能服务接口》[8]中定义。

6.6 执行器抽象功能

执行器抽象功能根据决策规划模块的输出，结合车辆当前的行驶状态来完成车辆实际控制，并反馈最终结果。执行器抽象服务接口不在智能驾驶功能软件平台规范中定义，可以参考《线控转向及制动系统通讯协议要求及测试规范》[4]中的定义。

附 录 A

（资料性附录）

功能软件设计开发流程示例

A.1 CITY PILOT 功能软件设计开发应用示例

以City Pilot为例来说明如何根据本规范定义的智能驾驶功能软件平台系统架构来进行功能软件的设计和分工，从而实现跨产业界的分工协作并加速功能软件的开发。功能软件设计的步骤可以分为三步：首先进行应用场景的分解，然后完成分场景的功能抽象，最后根据功能软件平台系统架构来完成整体功能的搭建组装。

第一步，应用场景分解：

City Pilot主要实现城市场景开放道路场景通行功能，完成点到点的智能驾驶任务，具体来说包括如下场景：本车道自由行驶、本车道跟随、本车道启停、遇障停车、本车道避障绕行、任务变道、超车、避障变道、超车变道、靠边停车、并行驾驶、定点启停、取消变道、变道避障、指定地点停车、开放道路路口通行、无障碍物行驶、红绿灯启停等；

第二步，功能抽象：

可以根据上述场景进行功能抽象，分解成最小化的功能模块和算法组件：

• 场景应用软件：设定功能应用的场景，判断条件，默认配置，场景策略和人机交互需求等应用逻辑支持City Pilot的场景功能实现；

• 传感器抽象服务：选配对应传感器，支持实现该应用

• 感知融合服务：为解决本车道行驶、变道行驶、路口通行，必须有

  • 红绿灯检测
  • 动态目标识别和跟踪
  • 融合算法
  • 自由空间检测
  • 道路结构检测
  • 车辆状态反馈

• 定位服务：自车定位是必须的，对应传感器配置可以选用基于不同方式的自车定位

  • 融合定位信息
  • 地图

• 预测服务： 提供对人机非的预测服务

  • 行为预测
  • 轨迹预测

• 决策规划服务：

  • 导航
  • 行为决策
  • 轨迹规划
  • 车辆控制

第三步，组合搭建：

按功能软件平台参考架构进行解耦分解后，可以通过集成不同厂商提供的功能模块和算法组件实现应用功能开发集成，具体的分工如下：

• 场景应用层软件：对整体的功能软件平台组件的整体逻辑进行实现，特别是需要和驾驶员交互的逻辑，场景规则的配置，各种异常情况的处理逻辑和降级等。

• 传感器抽象服务：选配对应传感器，支持实现该应用

• 感知融合服务：

  • 红绿灯检测：选用A公司提供的视觉红绿灯检测算法，B公司提供的V2X红绿灯服务
  • 动态目标识别和跟踪：选用C公司提供的激光3D目标检测和跟踪算法，或者D公司的视觉目标检测和跟踪算法，或者E公司的激光+视觉+radar目标检测和跟踪算法
  • 融合算法：选用F公司提供的航迹融合算法
  • 自由空间检测：选用A公司或者G公司提供的视觉自由空间检测算法
  • 道路结构检测：选用H公司或者I公司提供的视觉道路结构检测算法
  • 车辆状态反馈：对车辆状态进行收集整理，包括轮速、方向盘转角、方向盘扭矩等，填充车辆状态服务项；

• 定位服务：

  • 融合定位信息：选用K公司提供的融合定位算法
  • 地图：选用O公司提供的地图服务

• 预测服务：

  • 行为预测：选用J公司提供的行人、机动车、非机动车行为预测算法
  • 轨迹预测：选用K公司提供的行人、机动车、非机动车轨迹预测算法

• 决策规划服务:

  • 导航：选用O公司提供的地图以及导航服务
  • 行为决策：选用P公司提供的行为决策服务
  • 轨迹规划：选用P公司提供的轨迹规划服务
  • 车辆控制：选用M公司提供的车辆控制服务

根据上面的功能分解和搭建，最终设计成如图12所示的CITY PILOT功能：

1. 导航信息构建：通过场景应用软件的人机交互平台，进行运行设计域的判断，为功能软件输入预设的各种City Pilot的场景功能域配置。开启City Pilot 功能，根据用户的目的地和偏好信息，输入给决策规控模块。功能软件平台考虑自车位置和地图，站点导航功能规划整体的行驶路线；

2. 动态行驶命令形成：功能软件平台完成周边环境感知和环境模型构建，规划一条可执行轨迹并输出命令控制车辆方向和加减速；

3. 场景应用软件交互：场景应用软件监控功能软件平台的运行，特别需要进行仲裁和驾驶员参与的场景，最终决策输入功能软件平台执行。

A.2 车道保持辅助系统设计开发应用示例

以LKA（Lane keeping assistance），即车道保持辅助系统来阐明如何通过智能驾驶功能软件平台来实现辅助驾驶功能。

第一步：应用场景分析

车道保持辅助系统（LKA）需要监视车辆相对于车道边界的位置，并在即将发生车道偏离时向方向盘施加扭矩，或向制动器施加压力。车道保持辅助系统可以有不同的传感器配置和对应实现方式，下面以最常用的摄像头实现为例。

第二步：功能拆解

要实现的功能模块主要包括车道线检测、一个简单的规划层和横向控制。

• 场景应用软件：设定功能应用的场景，判断条件，默认配置，场景策略和人机交互需求等应用逻辑支持LKA的场景功能实现；

• 传感器抽象服务：选配对应传感器（摄像头），支持实现该应用

• 感知融合服务：

  • 选用A公司提供的道路结构检测（实现车道线输出）
  • 对车辆状态进行收集整理，包括轮速、方向盘转角、方向盘扭矩等，填充车辆状态服务项；

• 决策规划服务

  • 行为决策：本车道巡航或者自适应巡航；
  • 轨迹规划：选用B公司提供的轨迹规划服务，提供对车道线输出后的居中轨迹平滑功能
  • 车辆控制：选用C公司提供的横向控制服务，完成对方向盘施加扭矩，或向制动器施加压力。

如上所示，较简单的L2智能驾驶功能也可以基于功能软件平台的统一架构来实现。