前言
本文档参考自动驾驶计算联盟(Autonomous Vehicle Computing Consortium)关于自动驾驶和辅助驾驶计算系统的概念系统架构。该架构旨在与SAE L1-L5级别的自动驾驶保持一致。本文主要介绍包括功能模块图，涵盖了底层计算单元、示例工作负载和行业标准。
本篇为第二部分主要介绍底层计算单元、示例工作负载。
自动驾驶系统架构组件
三、 信号描述
图中的模块连接在抽象级别上显示了数据从一个功能模块传递到另一个功能模块的生产者-消费者关系。但是,为简化起见,在文档的其余部分将其称为信号或数据流。功能模块的输出可能是系统中一个或多个功能模块的输入。
本文描述了系统架构图中各功能模块之间的数据流。本节中描述的数据流在后续各节的功能模块描述中引用。功能模块只是简单地引用本节的数据流,并进一步阐述数据流在其功能、用途和实现方面的作用(输入和/或输出)和计算方面的内容(作为消费者、作为生产者)。
数据流可以分组为通常的行为“配置文件”,概括如下:
· 数据流:定期更新的数据流;总是有下一个更新
· 事件:指示转变或变化的数据流;在发生变化时周期性发生
· 状况:指示状况的数据流;新更新将替换当前状况
· 状态:类似于状况,但在生产者失败或重启时仍可用(当车辆运行时)
· 配置:像状态一样,但在车辆重启后仍然存在
· 请求:请求服务;可能导致行为改变,也可能无法满足。每个数据流遵循以下模式:
· 名称:由信号传达的数据的描述
· 所有权:排他(恰好一个生产者是主要来源)| 共享(所有生产者被视为有效源)
当一个数据流有多个生产者时,“所有权”属性简单地指示是否有一个排他的生产者应该被视为主要来源。如果没有指定此属性,则认为数据流是“共享的”,即数据流的所有生产者都被视为有效的输入源(默认)。
自动驾驶车辆系统中的信号如下所示,按数据流配置文件组织。
3.1 数据流
· 自身运动:描述自主车辆相对于世界坐标系的运动。
--提供反映自主车辆动态条件的信息,用于确定机动能力
--提供有关自主车辆当前运动的信息
--与目标轨迹一起考虑,共享自主车辆姿态信息,以生成执行器请求
--随时间变化的姿态,即平移和旋转速度以及加速度
· 执行器请求:向自主车辆的制动、转向和加速执行器发送控制输入。
· 执行器反馈:提供来自车辆执行器的反馈信号。
--应该向系统其他部分公开车辆运动约束,因为此反馈是必要的
--可以与各种外部执行模块接口,此反馈在单位、格式、类型等方面将有所不同
· 底盘传感器数据:提供运动相关信息的车辆内部传感器(例如轮速传感器、方向盘转角等)。
· IMU数据:由IMU提供的测量车辆加速度和旋转率。
· 罗盘数据:由磁力计提供的正北方位。
· GNSS数据:来自全球导航卫星系统(GNSS)的数据。包括以WGS84/GPS位置表示的地理参考位置估计(不确定性通常以米测量)。
--基于GNSS的位置信息,可能与校正服务的信息组合
--包括地理参考位置估计。可能已经包括自身运动估计
· 环境传感器数据:来自一个或多个环境传感器的规范数据。
--可能包括摄像头数据(可见光和/或红外波长)、雷达(飞行时间测量手势)、声纳(可听和/或超声)或其他传感模式
--注意:可能包括各种传感器输入的组合
· 车厢传感器数据:来自一个或多个车厢内传感器的数据。可以使用各种传感技术进行乘客监测。
--示例可能包括摄像头(可见光和红外波长)、雷达(手势/心跳检测)、音频和各种其他传感机制。
3.2 事件
· 规范|特征|对象:描述三种通用的数据抽象层次。暗示这三个层次中的任意一个都可以被消费。
· 规范:感知模块可以以规范格式输出数据,即指其格式而不是处理状态。它可能经过感知模块的某些转换,例如去除阴影。
· 特征:感知模块可以以特征的形式输出数据。例如,定位模块用于地图匹配的特征。
· 对象:一个通用术语,可以描述各种实体(可能具有动态/语义状态)。例如,车道、交通灯、机动车、救护车、交通警察停止信号等。包括动态和静态对象。
· V2X数据:由V2X系统提供的数据;可以提供有关交通灯、收费站等状态的实时信息,以使检测更加可靠。来自基础设施或其他车辆关于感兴趣特征位置的信息。
· 交通状况:关于自主车辆附近或路线目标上的交通状况的动态源信息。
3.3 状况
· 任务反馈:关于任务状态的反馈,向车辆乘员/驾驶员提供通信。一个例子是系统请求驾驶员干预。通过HMI向车辆乘员提供当前任务的反馈。这可以包括诸如路线目标的进度、警告驾驶员接管控制或类似信息。
· 任务目标:可以反映复杂任务的用途表达,其目标是“到达目标目的地”,或者在更低的自动化级别,是一个更简单的目标,如“保持在当前车道的中心”。任务目标在行程中可能会改变。
· 路线目标:自主车辆将要走的路线描述,如果适用包括车道,以实现任务目标。描述每个交叉口的所需车道和转向。
· 机动:提供至少两个操作的列表,包括一个安全机动。机动表达为地图上的新位置,以及该位置的目标速度,并描述高层次的车辆运动行为(例如巡航、跟随、改道、转弯或停止)。
· 目标轨迹:是将机动分解为目标轨迹(曲线路径),其中沿轨迹路径表达转向、制动和加速的变化。
· 感兴趣区域:是世界空间中一个或多个区域的描述,感知应优先处理这些区域。这可以描述世界空间中感知应提供卓越性能(如果可能)的感兴趣区域。例如,这可以允许配置具有非均匀感知分辨率的传感器,从而特定感兴趣的道路/基础设施以更高分辨率“看到”。
· 动态对象:识别所有移动或可移动对象。例如车辆、行人或动物。
· 静态对象:识别所有不可移动对象或基础设施。静态对象仍可能具有与之相关的可改变状态。例如道路表面、路缘、锥桶、路标、交通灯、电子标志。或者甚至是一个基础设施元素,如可移动屏障(如收费站)。
· 动态对象预测:预测动态对象的路径。
· 静态对象预测:预测静态对象状态的变化,如交通灯变化的时序。
· 场景数据:提供当前场景的相关描述,用于确定自动驾驶系统是否在操作设计域内运行。一个例子是对自动驾驶系统尚未设计用以处理的被淹路面的注释。
· 姿态:描述自主车辆相对于地图的当前位置和方向。与地图信息一起使用以启用或改进高级驾驶员辅助系统(ADAS)的许多行为。
· 感知能力:给出自动驾驶系统动态感知能力的描述(例如某类实体的感知范围)。
· 系统完整性:提供车辆不同组件的运行状态报告,这些组件与自动驾驶系统的安全运行相关;来自与硬件和软件平台相关部分的派生。
3.4 状态
· 乘客状态:提供有关自主车辆每个乘客(包括驾驶员)状态的描述。信息可能包括存在、注意力、情绪状态、健康等。
--来自乘客监控功能的有关驾驶员和乘客的信息。
--在汽车公司、自动驾驶系统支持级别和系统体系结构之间有所不同。可能包括带有相关状态信息的乘客列表。
--将列出具有相关状态标记的乘客。例如<乘客:成人,座位:0,角色:司机,注意力:向前,注视区域:(34,56,32),司机意图:左转,健康:正常,情绪:正常,转向:是等。
· 基于操作域监督的路线约束:对路线进行约束以保持在操作设计域(ODD)内。一个例子是由于缺乏路灯照明而在某些时间避免某些路线。
· 基于场景的路线约束:动态确定路线约束,如封路标志、高速公路上封闭的车道或用路障封闭的高速公路入口。
· 基于操作域监督的机动约束:由于需要保持在操作域监督内而对机动施加约束。一个例子是避免超车,因为附近的车辆数量大于以当前速度可以可靠跟踪的车辆数量。
· 基于场景的机动约束:动态检测机动的约束。例如可能包括迎面而来的救护车、标有长载货物牌的车辆、视野不佳等。
· 基于场景的运动约束:动态检测车辆运动的约束。例如检测到湿滑路面、劣化路面等,可能需要适当调整驾驶风格。
· 车辆运动约束:动态更新自主车辆运动的约束。提供外部执行模块的限制反馈,汇总后呈现给其他自动驾驶系统模块,如轨迹规划(路径规划)。
3.5 配置
· 用户路线偏好:提供约束路线选择的偏好或规则。可能包括乘车服务或自主车辆本身保持在操作设计域或优化燃料消耗等的约束。首选路线引导与自动驾驶任务相关。根据范式,路线偏好可以通过操作域监督任务引导信号路径反映当前操作域的限制。
· 地图数据:提供静态的和可能的动态源地图数据,包括用于路径规划的路线图,以及所谓的高清(HD)地图。可能包括详细的地理参照标志(包括道路标志、交通灯等的位置)。
--提供当前操作域的地理约束信息。--包括可被检测/分类算法利用的来自静态或动态更新地图的先验信息。例如,可包括期望的车道属性、交通灯位置等。--提供地图子系统关于道路和特征几何及位置的信息,当与其他定位输入组合时,可用于理解自主车辆的位置和方向(点云、特征位置和方向、道路几何等)。
3.6 请求
· 操作域监督任务请求:由于车辆使用条件改变或一个或多个未能保持在授权或当前操作域内而请求修改当前任务。
· 互联任务请求:由某个远程服务请求设置/更改当前任务。一个例子是由于在车内检测到医疗紧急情况而更改目的地。来自连接服务的修改当前任务的请求。例如,乘车管理服务设置/覆盖目的地,或由于交通拥堵或事故而建议绕行。
· HMI任务请求:由车辆乘员请求任务设置/更改;来自通过HMI注册的车辆乘员的修改当前任务的请求。任务请求可能包括自动化水平的更改。
· 行为规划任务请求:行为规划(BP)请求修改任务。如果行为规划(BP)确定无法按计划执行任务,则可能需要这样做。请求的性质可以是请求人类驾驶员接管,例如。
· 自主车辆机动假设:提供一个或多个假设的机动,系统可以为此预测一个或多个结果。
四、底层计算元素
4.1 典型计算元素特性
现有的计算元素(或处理器)具有不同的特性,这影响它们处理效率。下图显示了不同计算元素的处理效率与应用程序的处理特性(例如顺序与并行)的关系图。每个计算元素都有不同的特征来提高其效率和性能。这些特性从更通用到更特定的解决方案有所不同,由这些不同/可选的特征集定义。
现有处理器的计算特性
中央处理器(CPU)中央处理器是最流行的存储程序架构的处理器(计算元素)。程序被描述为一系列指令,所以通常每个指令会逐步执行操作。由于这种逐步执行,CPU通常适用于任何顺序操作的组合。另一方面,基本CPU不适合并行操作。为了解决这个问题,今天的CPU具有几个附加的可选功能。
· 单指令多数据(SIMD)/向量类型数据纯CPU不适合数据并行,因为内部数据路径带宽限制。为了解决这个限制,一些CPU具有SIMD或向量扩展,可以在一个指令或操作中处理多个(通常是4到16)数据流。此外,随着长数据字交易和更大的寄存器文件,与外部资源(如内存)的通信也将得到改善,但在处理大量内容时,仍会出现瓶颈。
· 多核
由于工艺技术趋势,在合理的功耗下提高单个CPU的性能是困难的。多核是解决这个问题的一种方法。如果应用程序具有多个(分离的)任务,多核将发挥很好的作用,但是如果它具有紧密耦合的内部通信,有时处理器间通信(IPC)将瓶颈操作。
数字信号处理器(DSP)DSP旨在加速算术操作(加法、减法、乘法、除法),例如乘积累加操作。
数据压缩/解压缩、数字滤波、控制、识别等都包括在内,这些算法大量使用乘积累加计算(MAC),这使得DSP能够高速管理这些过程。
图形处理单元通用计算(GPGPU)GPGPU是一种将GPU的计算资源应用于图像处理之外目的的技术。图形处理单元(GPU)具有成千上万的算术核心(着色器单元),并通过并行重复简单的数值计算来实现图像处理的高速执行。利用这一特性,可以以高速执行类似图像处理的处理,其中包括人工智能(AI),如机器学习和神经网络、虚拟货币挖矿、科技研究中的数值计算和模拟以及流体计算。
要利用GPGPU,需要不同于通用处理器的编程开发环境。为了充分利用它,需要适合该架构的编程技术,编程开发环境例如NVIDIA的“CUDA”(统一设备架构)、Microsoft的“Direct Compute”和Khronos Group的“OpenCL”等。
专用加速器(例如ISP, xNN)
专用加速器基于为特定应用定制的体系结构。例如,数据流和存储器遵循专用方案。加速器甚至可以提供定制逻辑,形成高度专业化的计算元素。这种专门化极大地增加了计算效率和性能,但以牺牲通用性为代价。使用专用加速器可能需要专用和/或专有编程,甚至需要专用工具和框架。
4.2 在SoC中实现的计算单元
自动驾驶/先进驾驶辅助系统芯片
如图所示,当前的自动驾驶/先进驾驶辅助系统片上系统(SoC)通过集成不同计算特性的计算元件构建了计算组件,以实现对不同应用最有效的处理。为此,如下表所示,选择了具有不同计算特性的计算元件,如通用CPU、SIMD DSP、GPGPU和专用加速器等。
计算元件特性
·通用CPU适合运行顺序代码和有限的数据并行。
·SIMD DSP处理更数据密集的任务。
·GPGPU也可以处理高数据量和控制顺序灵活的任务。
·专用加速器针对特定操作实现最高执行效率,但需在SoC设计初期确定。
计算元件的特性及适配性分析
为分析上述计算元件,首先从某些正交的计算特性对其进行分类。SIMD类型计算元件适合运行处理大量独立数据的应用。因此,可以归纳出下表所示的正交计算特性。
正交计算特性
· 数据并行性：在并行处理不同的数据
· 任务并行性：在并行处理不同的任务
· 引用局部性：提供数据的访问时间局部性和空间局部性（数据局部性）
每个“数据并行性”和'引用局部性（数据局部性）'的分配数据模式的例子如下，任务并行与数据并行非常相似，区别在于数据局部性和上下文处理。
“数据并行性”、“引用局部性”和“计算元件”之间的关系表如表所示。数据并行性、引用局部性和计算元件的关系表。
“任务并行性”和“计算元件”之间的关系表如下表所示。任务并行性和计算元件的关系表。
综合上述计算特性,可以定义用于SoC中高效执行AD/ADAS应用所需的典型运算类型。运算类型及匹配的计算元件。
算法和运算下面我们分享了典型算法对不同运算的影响,这些运算在数据和线程并行性上有所不同。计算单元的决策依据。
定位
场景理解
行为规划
路径规划
轨迹规划
运动控制
自车运动
乘员监控
操作域
任务控制
为便于理解每个自动驾驶算法的处理特点,使用了一个简单的词来对其进行归类,即典型运算。需要注意的是,对于某些典型运算如条件分支,可能会选择多种不同的计算单元,因为它们各有所长。
五、传感器前处理
5.1 摄像头前处理流程
·自动驾驶HDR:为适应自动驾驶所处的高动态范围环境,先进的图像传感器采用同时多曝光和/或拆分像素设计。组合不同曝光可将固有动态范围(80-100dB)扩展至目标动态范围(120-140dB或更高)。
·摄像头或摄像模块:由图像传感器、颜色滤波阵列、镜头、外壳及可选前处理组成的传感器系统。
·色彩滤波阵列(CFA):应用于图像传感器的光学元件,形成特定颜色像素模式,通常以2x2单个颜色指定,如红、绿、蓝、黄、青等。常见例子有RGGB(Bayer)、RCCC、RCCB、RYYCy。
·计算机视觉(CV)前处理:用于增强传统CV算法效果的具体处理,如光流、Harris角点检测等。
·图像传感器:收集光线并输出数字像素样本的芯片。可采集不同波长光线,数字输出格式多种多样。常见波长包括可见光、IR、近红外(NIR)、短波IR(SWIR)等。
·人类视觉前处理:用于使图像对人类更易看的具体处理。
·镜头:各种镜头安装在图像传感器阵列和CFA上。传统自动驾驶应用使用固定焦距/固定镜头。
·机器学习(ML)前处理:用于增强机器学习(ML)和深度神经网络(DNN)算法效果的具体处理。这取决于所用算法,前处理范围从无到完整的人类视觉流程不等。详见成像工作组。
·传感器上的前处理:用于自动驾驶的先进图像传感器具有许多增强和压缩原始样本的功能。这些传感器通常具有数字增益调整、黑电平调整、多曝光片段线性组合等。输出流量仍很大(3~6Gbps),但远低于原始样本流。
·原始像素样本:来自芯片上ADC的未处理样本。这些样本仍受镜头、CFA、模拟增益设定、曝光设定等的光学和模拟影响调整。像素通常以每个曝光10~16位采样。一个800万像素的图像传感器,使用4次曝光,以每秒30帧的速度,将产生高达15.36 Gbps的数据率。
5.2 雷达前处理流程
·汽车雷达:由天线阵列、一个或多个微波集成电路(MMIC)和可选前处理组成。大多数汽车雷达采用频率调制连续波(FMCW)操作,但也有几种替代技术正在开发。雷达操作基础有许多不错的资料来源。
·雷达帧:通过一个或多个发射机发出的一系列传输脉冲序列,以实现场景视野、分辨率/分离度/识别度和期望维度(距离、径向速度、方位和仰角)的精度设计目标。
·原始雷达样本:来自连接特定接收机(Rx)的ADC的样本。这些ADC通常为10~16位,工作频率约50MHz(MSps),生成原始流量高达每Rx通道约800Mbps。高端汽车雷达通常有4~16个接收通道(3.2~12.8Gbps),先进研究使用几十个接收机。
·雷达数据立方体:通过处理原始雷达样本生成的1~4维立方体。通常采用FFT获得距离和多普勒维度。可用于计算方位和/或仰角的数字波束成形,但也有许多更先进的算法以更好的结果换取额外处理。
·雷达数据立方体压缩:由于数据立方体中大多数位置没有返回,存在几种简单(通常专有)算法压缩数据立方体以减少传输带宽。
·雷达检测/点云:通常对数据立方体进行阈值处理/CFAR和将相邻返回合并为单点/检测。这大大降低了数据带宽,但也损失了数据立方体中的目标“形状”。
·雷达对象:基于检测结果,传统雷达处理会将附近点集群化并返回目标对象“块”。
·雷达感知:大类算法,可将雷达数据处理为汽车、人员等分类对象,还有更多基础设施对象。这些算法通常对数据立方体、点云或对象进行操作,但也有基于原始数据的研究。
·雷达输出数据格式:点云,点具有位置、距离、强度、运动信息等属性。
5.3 激光雷达前处理流程
·汽车激光雷达传感器:激光雷达系统可以分为几类基本类别。波长、脉冲/调制技术、接收器技术和扫描技术等基本变量会带来许多权衡取舍。
·Flash与扫描激光雷达:闪光激光雷达本质上是飞行时间(TOF)相机。使用激光闪光和高速2D接收器阵列,可以捕捉到许多“曝光区间”或“距离分箱”。2D阵列给出x/y位置,对距离分箱的处理可以得到反射或返回的峰值z位置。与Flash激光雷达不同,扫描激光雷达一次只在一个x/y方向上“观察”。发出脉冲后等待一定时间获取返回。这使设计者可以一次关注发出能量(在眼安全限制内)在一个位置上。然后扫描机制移动到下一个“像素”位置。
·脉冲与调制激光雷达:脉冲激光雷达需要更高功率来克服阳光的背景噪声,但系统相对简单。调制激光雷达噪声水平更低,因为干扰源要么没有调制(阳光或其他脉冲激光雷达),要么与发射调制的时间/频率组合极不可能重合(其他调制激光雷达)。由于噪声水平更低,在相似输出功率下,调制激光雷达的范围远超脉冲激光雷达。更复杂的发射器和接收器的代价是主要缺点。根据调制方案(如FMCW),它们也有更长的“驻留”时间,因为接收器需要等待完整调制返回,而不是快速脉冲。这增加的驻留时间导致与其他技术相比点数/秒更低。
·原始激光雷达样本:激光雷达样本测量返回强度对时间的关系。它们通常每个接收器为1~6 Gbps,不太可能在当前汽车网络技术中传输。接收强度取决于发射功率、与物体距离和物体反射率。
·激光雷达返回波形:对原始样本进行阈值处理形成每个从远处物体反射的波形,也称为返回。
·激光雷达返回:使用各种算法找到返回波形的强度峰值/时间。对于任 one发射脉冲,由于波束发散和目标的半透明性,可以有许多不同的返回。这些返回通常包括视场中的x、y位置,返回的距离和强度,以及用于全局同步的时间戳。
·激光雷达点云:点云是返回列表,可以对视场中的每个x/y位置具有多个返回。大多数汽车激光雷达输出每个x/y位置1~3个返回的点云。研究界有强烈观点认为应输出返回波形,因为它们包含目标对象的更多信息。与雷达处理类似,峰值检测可有效压缩所需的数据带宽,但明显损失目标对象信息。
六、ISP接口/连接
具体的传感器选择(如摄像头)不在讨论范围内。但是,任何系统功能模块(如感知)消费的处理后的图像数据在讨论范围内。
感知功能模块
计算平台必须提供ISP功能以处理输入的摄像头数据。ISP处理能力必须足以满足应用所需的摄像头。这取决于许多因素,包括应用类别(驾驶场景、自动化水平、ODD)和应用实现。不同的自动驾驶应用开发者对于同一场景和ODD的摄像头使用方式可能有不同方法。
可以观察到一个大致趋势:
·一般来说,给定场景所需像素数受物理定律与检测算法需求的权衡限制,因此不同应用间可能一致。然而,行业采用了多种摄像头数量和分辨率组合的方法。
·具体应用可能选择较多的1-3MP范围内的低分辨率摄像头,或少量的高分辨率摄像头。对于高速自动驾驶场景(如高速公路驾驶),可能使用高达8MP以上的高分辨率摄像头以支持远距离特征的感知。
在许多计算平台实现中,ISP处理能力可以灵活配置以支持不同的摄像头配置。
处理能力可以由所有摄像头的总像素吞吐量限制,而不是任一单个摄像头。提供这种灵活性可以支持更多样化的摄像头配置。
七、功能模块图基准测试
基准测试活动主要围绕两个方面:
·对应于功能模块图构建模块的基准测试。例如深度学习推理基准测试,这是感知和其他模块的重要构建模块。
·基准测试框架,关注横跨整个计算系统的基准测试的编排、运行和分析。
八、功能安全和信息安全
功能安全和信息安全无疑是任何汽车系统解决方案的两个非常重要方面。它们都不会是驾驶自动化系统的简单附加组件,而是需要进行更详细的端到端审查,例如调研可用解决方案和其他组织的活动。
九、示例工作负载
9.1 概述
本节提供了L1辅助驾驶到L5自动驾驶系统的示例用例;工作负载配置/感知器设置和功能类别。目的对可能的硬件解决方案给出粗略方向。
在示例工作负载中,关于性能KPI的具体数字被略去,因为它们一方面是不断变化的,另一方面是有区分性的。需要注意,这里示例工作负载没有考虑故障操作能力。
示例工作负载
每个系统主要涵盖三个方面:
· 感知器套件:为驾驶功能的构建奠定基础。五个导出的系统在感知器套件方面有明显区分。
· 功能类别:提供有关系统可以提供的辅助驾驶和自动驾驶功能的指导。这是灵活的,实际实现可能存在差异。
· 计算指标:量化硬件性能。行业内认为KPI具体值是有区分性的,因此这里不给出。图中显示了示例系统之间的性能和复杂度趋势。
9.2 五个示例系统
下面分别介绍从L1辅助驾驶到L4自动驾驶的五个示例系统。
超低端系统
该系统代表一个示例性感知器配置,包含一个摄像头(1x3-8.3MP)和一个雷达。
其目标SAE等级为L1,功能类别包括:
· 基本NCAP场景
· 紧急刹车辅助
· 巡航辅助
· 自适应巡航控制
如其名称所示,该系统的计算需求在五个系统中位于范围底端。
低端系统
该系统代表一个示例性感知器配置,包含两个摄像头(2x8.3MP)、五个雷达、十个超声波传感器,以及一个驾驶员监控摄像头(1x8.3MP)。
其目标SAE等级为L2,功能类别包括:
· 高速公路巡航
· 车道内交通拥堵(最大50公里/小时)
· 驾驶员确认的换道辅助
· 监督泊车
该系统的计算需求在五个系统中位于低端。
中端系统
该系统代表一个示例性感知器配置,包含六个摄像头(2x 8.3MP + 4x 2.1MP)、五个雷达、十个超声波传感器。
其目标SAE等级为L2/L3,功能类别包括:
· 有条件的高速公路自动驾驶
· 有条件的极低速堵车自动驾驶
· 无监督泊车(与红外线配合)
· NCAP场景(包括交叉场景)
该系统的计算需求在五个系统中位于中端。
高端系统
该系统代表一个示例性感知器配置,包含12个摄像头(3x8.3MP + 9x 2.1MP)、五个雷达、两个激光雷达、十个超声波传感器和一个声学传感器。
其目标SAE等级为L3/L4,功能类别包括:
· 有条件的高速公路自动驾驶
· 无监督泊车
该系统的计算需求在五个系统中位于高端。
超高端系统
该系统代表一个示例性感知器配置,包含15个以上摄像头(3x8.3MP + 4x 4.9MP + 8x 2.1MP)、十个雷达、四个激光雷达、十个超声波传感器和一个声学传感器。其目标SAE等级为L4,功能类别包括:· 高度自动化高速公路驾驶· 高度自动化城区低速穿梭(最大50公里/小时)
该系统的计算需求在五个系统中位于顶端。
十、开发接口
除了功能之外,还必须关注自动驾驶系统(ADS)的开发过程。下面简要概述调试功能,这些功能用于电子控制单元(ECU)的初始开发,以启动和运行它。
事件记录部分则概述了从道路检索数据以服务于开发、功能改进和记录事件数据的其他用途。由于行业已经在汽车安全联盟中就这些方面达成一致,因此这里介绍了他们的工作。
10.1 调试功能
一些非侵入式的测量可以使用硬件进行,而其他的需要软件并带来开销。系统必须支持数据的“辅助”(非ADAS)使用。
概念上(如果不是物理上)应该有许多一致且不干扰的数据探针(或端口):应用程序的原始使用、数据记录器、调试接口和信息娱乐系统。
传感器数据和应用程序状态在检查方面是不同的。传感器数据源自处理器外部,可以透明地复制。应用程序数据可能只能通过侵入式手段可见。记录指令流是不同于记录数据流的单独机制。
对功能模块的调试接口应考虑以下几点:
· 探针点
· 每个I/O和所有应用程序状态变量
· 带宽
· 等同于传感器和应用程序
可能讨论的调试功能项如下:
· 错误注入
· 异常捕获
· 内部和外部中断
· 断点
· 监视点
· 分步执行(高低级)
· 读写内存
· 以完整数据速率记录整个数据平面
· JTAG
· 指令跟踪
· 时间戳
· HIL/SIL仿真
· 远程调试端口访问
· 计算元素的工作负载,如CPU/GPU和总线互连
· 计算元素功耗
10.2 事件记录
在事件期间记录数据出于许多不同原因非常重要,如碰撞调查、系统性能研究、故障分析、持续学习等。事件分析和调查将有助于识别经验教训,以实现业界在自动驾驶和驾驶辅助系统方面的整体改进。
计算平台需要以一种可以轻松灵活地收集数据的方式进行设计,以实现前述目标。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
