自动驾驶汽车实际道路测试系统设计与实现

2022-12-11 02:38端帅王霁宇秦孔建杨智博
制造业自动化 2022年11期
关键词:道路自动模块

端帅,王霁宇,秦孔建,杨智博

(1.中国汽车技术研究中心有限公司,天津 300300;2.中汽研汽车检验中心(天津)有限公司,天津 300399;3.中汽科技(北京)有限公司,北京 100176;4.机械科学研究总院-中汽认证中心有限公司,北京 100044)

0 引言

随着自动驾驶技术的创新和迭代,智能网联汽车的测试标准和规范不断更新和完善。高级驾驶自动化智能网联汽车应该具备环境感知、智能决策和协同控制等能力,实现安全、高效、舒适的自动驾驶功能。高级驾驶自动化智能网联汽车的技术发展需要依托新的测试评价方法体系以及验证工具平台。2022年9月,《国家车联网产业标准体系建设指南(智能网联汽车)(2022年版)》组织开展征求意见,提出智能网联汽车测试评价技术中的关键要素,创建以评价及审核能力、管理及开发流程、测试设备及工具、测试场景为核心的全新测试评价系列标准,为建立包括仿真试验、场地试验、道路试验及审核评估在内的智能网联汽车“多支柱法”测评认证体系提供基础支撑[1]。联合国自动驾驶验证方法非正式工作组(VMAD IWG)[2]提出了模拟仿真测试、封闭场地测试、实际道路测试、审核评估和在用监测报告5种测试评估方法,促进了标准、法规和行业规范的发展。国际汽车制造商协会(OICA)[3]提出了由审核评估(包含模拟仿真测试)、封闭场地测试和实际道路测试组成的智能网联汽车“三支柱”测试认证方法。国内相关研究机构[4]提出了基于场景的测试方法是实现智能网联汽车安全测试评估的重要方法,按照测试手段可以分为模拟仿真测试、封闭场地测试和实际道路测试。

测试评价标准以“多支柱法”为指导,通过模拟仿真测试、封闭场地测试、实际道路测试等方法验证自动驾驶汽车的智能化和网联化技术能力。模拟仿真测试[5]具有高效率、低成本、高安全和高覆盖度的优势,是验证高级自动化智能网联汽车算法缺陷、功能不足的重要手段,但存在测试环境真实性、仿真建模可信度和工具链置信度的难题。上述影响因素可能使得真实的场景环境和车辆动态无法完全映射到虚拟的测试环境中。封闭场地测试[6]通过在受控的场地内搭建各类可重复的交通场景进行测试能够加速测试进程减少测试风险,是自动驾驶汽车实际道路测试前必不可少的环节。目前自动驾驶汽车在封闭场地的测试功能和场景较为单一,难以满足目前多种技术形式、不同自动驾驶等级的智能网联汽车测试需求。

相比于模拟仿真测试和封闭场地测试,实际道路测试[7]能够为自动驾驶汽车提供真实复杂的交通环境,满足其必要的设计运行条件要求,利用实际道路的随机目标和事件,充分地验证其执行动态驾驶任务的功能和性能表现。实际道路测试评价作为高级自动化自动驾驶汽车的关键环节,是推动自动驾驶汽车真正落地的至关重要的组成部分。此外,基于场景的自动驾驶汽车安全测试“三支柱”评估方法指出实际道路测试评价体系需要以里程、时长和ODC要素的全面覆盖为基础,针对真实的交通场景下的自动驾驶系统开展测试和评价。因此,高级驾驶自动化自动驾驶汽车的测试评价需要依托标准、法规的建设和测试评价、系统验证方法的设计来开展多维度测试评价的研究。

2021年7月,三部委印发了《智能网联汽车道路测试与示范应用管理规范(试行)》[8],为智能网联汽车测试和评价提供了政策支撑。2021年12月,智能网联汽车分标委组织制定的汽车推荐性国家标准《智能网联汽车自动驾驶功能道路试验方法及要求》组织开展征求意见,为智能网联汽车道路测试提供了参考和依据,推动了测试评价标准[7]的研究和发展。实际道路测试评价技术是验证ADV安全和效率的必要手段,对自动驾驶技术的迭代和商业化具有至关重要[9]。

自动驾驶汽车实际道路测试从需求分析、设计测试到实际运行,是智能网联汽车产业一个大的阶段性跨越。实际道路测试过程采集的海量数据要求测试设备和方法更加系统全面,数据存储更加规范和安全,数据处理更加灵活和方便。但是海量的测试数据管理相关的标准化基础还比较薄弱[10]。自动驾驶汽车产业承载着海量的数据处理,且数据类型多样化、来源多元化,涉及了产业链中各个环节的平台间交互融合,要建立一个统一的、标准化的运维管理平台,实现对设备的实时监控,实时掌握设备情况,为运营管理人员提供日志分析、故障诊断工具。实际道路测试与评价作为自动驾驶汽车安全行驶的不可或缺的环节,是促使自动驾驶汽车平稳落地的基础前提[11]。

本文针对以上分析,从面向支撑自动驾驶汽车实际道路测评系统需求、设计及测试流程方面,综合应用数据采集、大数据处理和云计算平台等技术手段,提出了一套面向高级驾驶自动化自动驾驶汽车实际道路测试评价的系统方案架构,并通过具备高级领航辅助驾驶车辆的实际道路测试,验证了可行性。

1 系统需求

1.1 业务需求

基于自动驾驶汽车实际道路测试和评价需求与特点,系统能够满足长时间、高里程、多任务、大容量的数据存储和计算。自动驾驶汽车实际道路测试系统主要分为车端数据采集系统和数据中心云端系统。

车端数据采集系统通过搭载各类数据采集硬件模块,运行数据采集软件,完成车端测试数据的采集和存储。车端测试设备主要包括CAN/CANFD/LIN/FLEXray协议总线接口卡、车载以太网设备、惯导&GPS组合导航设备、激光雷达和智能视觉感知设备、参考音视频设备、多目标车通讯设备、数据记录设备和光照、温湿度环境设备等。车端软件工具链运行在数据记录工控机上,通过脚本自动实现、数据采集、运行和停止功能;具备特定事件的状态触发和时刻触发,自动触发逻辑条件可通过信号库函数或其他自定义函数编辑;通过声音报警和画面提醒方式监控各路数据采集通道状态;实时上传测试车辆的位置、驾驶状态和行程状态等信息至数据中心云端。车端采集的测试数据传输协议和格式具有通用性,能够应用在不同的采集工具链;测试数据在线传输和离线存储具备安全机制;测试数据能够以高带宽数据传输能力进行读取和写入。测试数据的核心数据能够以结构化数据类型存储至云端数据中心。

数据中心云端基于大数据和与云计算技术对自动驾驶汽车实际道路测试过程进行监管、测试结果进行评价和项目任务协同管理。数据中心云端能够结合数据存储设备,以高带宽存储方式将离线数据存储至服务器云端。数据中心云端具备权限管理功能,不同的账户、角色和应用服务数据隔离;车端多任务项目协同监控和管理;测试数据清洗、加密、高速上传及真值处理;离线测试数据和处理分析的数据能够进行同步回放;参数化场景提取脚本构建测试指标提取规则,完成数据提取、切片和管理;根据测试指标需求,采用参数化脚本实现数据分析评测、构建测试评价模板和生成对应测试报告。

1.2 基础设施需求

针对自动驾驶汽车实际道路测试业务需求,测试系统的设计和实现需要满足车端数据采集系统基础设施要求和数据中心云端系统基础设施要求。

随着自动驾驶汽车实际道路数据采集系统的不断发展,设计出一个良好的、高效的车载终端系统是数据采集的基础保障。车端数采系统的数据采集需要具有准确性。车端采集系统在实际道路测试中相关试验指标或性能的观测值与其真值的接近程度。不同的测试设备需要能够将识别和输出的数据信息稳定维持在一定的误差区间,且保证数采系统的输出精确度,才能更好验证车端数据采集系统的测试能力,确认数据采集系统的数据有效性。车端测试设备的布局灵活,可以实现X/Y/Z三坐标的移动和旋转;设备之间安装位置不发生干涉,且留有散热间隙;设备连接线按照不同的功能用途进行布线。通过安装、拆卸灵活性,满足车端测试设备的可移植性。车端测试设备电气系统独立供电,线束注明电气编号以便检修设备故障。安装位置科学合理,避免因设备电磁干扰,导致设备供电高低压。

基于自动驾驶汽车实际道路测试系统需求,基础设施使用具备虚拟化技术、分布式存储和资源调度能力的云服务器平台[12~14]实现。云服务器平台主要基于高性能计算节点、海量数据存储节点、网络交换管理设备和用于管理数据中心的软硬件系统构成,能够创建多个虚拟化界面、保障数据安全的软硬件系统在内的综合数据中心。数据中心云端的基础设施具备计算能力、存储能力和网络能力,同时合理协同调配这些能力到其所需要的地方。同时,还需要搭配云监控、云防护等措施,保证整个云平台的安全和稳定。

数据存储应用分布式集群架构,元数据节点有冗余设计,性能、容量随节点数增加而线性增加;数据计算模块支持横向扩展,同一节点实现数据计算、存储和融合;备份集群系统数据和虚拟机实例快照;集群网络具有端口聚合和堆叠,配置管理端口和web界面,实现多台网络设备集中式的远程管理平台;在同一个管理界面中监控和管理计算、存储、交换机、虚拟化平台等。机柜柜体具有静电防护和电磁屏蔽,供电单元防过载、过压和浪涌,UPS不间断电源供电和科学的散热空间。

1.3 数据安全要求

服务器数据安全和保护是自动驾驶汽车实际道路测试系统使用的基础要求,尤其在网络安全、操作系统安全和数据存储安全方面。

数据网络采用专业的主备防火墙冗余设计,加强入侵检测和部分异常、恶意流量阻隔;设计负载均衡和分布式集群防御策略,及时调度和切换故障节点。操作系统定期安全检测,及时更新系统和软件补丁防止病毒入侵。数据存储应具有存储磁盘损坏时服务不中断、数据不丢失,为不同的数据提供不同的保护级别;具有备份超融合集群系统数据、虚拟机实例快照备份功能;具有备份存储物理设备,可通过局域网进行数据恢复;具有磁盘或者存储节点故障时系统能自动进行数据重构。定期进行磁带备份、数据库备份、网络数据备份和更新、远程镜像操作等。通过设定访问权对访问人员身份进行核查,只有满足访问要求的人员,才能实现系统登入,以此保证服务器网络安全。

2 系统设计

2.1 业务设计

自动驾驶汽车实际道路测试系统以云管端的方式进行设计和执行,设计云-车为主从关系。系统云端下发测试任务和监控测试过程,车端执行测试任务和上传测试过程。

在实际道路测试过程中,车辆系统通过搭载工控机、定位惯导、激光雷达、智能摄像头和参考视像头等测试设备,同步采集车辆总线、道路交通、天气环境、光照以及驾驶员行为等数据信息。通过车端获取的测试数据主要分为实时在线监控数据和离线处理分析数据两部分。实时在线监控数据按照具体需求通过云-车专用网络进行实时回传,包括车辆的测试时间、地点、时长、里程、车辆驾驶状态、道路类型、天气环境以及例如车速、加速度、转向等车辆行驶动态信息。离线数据包括车辆总线数据,外接定位、感知传感器数据,参考音视频数据等非结构化数据。离线数据以高带宽接口快速传输至服务器,自动进行清洗、筛选和分库分表等。通过设定由项目信息、车辆信息和自定义信息组成的行程字段的方式与云端服务器进行数据校验、关联,获取对应的结构化和非结构化数据内容。结构化数据可以根据评价需求,设计自定义和参数化脚本程序,用于场景提取、行程评测、事件评测、场景评测和报告可视化。自动驾驶汽车实际道路测试系统能够满足不同用户、不同项目、不同车辆、不同任务的多维度协同管理和数据隔离。

2.2 平台框架

自动驾驶汽车实际道路测试系统平台框架主要分为车端系统框架和数据中心云端框架两部分。

车端采集系统框架分为电源子系统、定位子系统、真值感知子系统、参考音视频子系统和采集存储子系统等,能够满足开展测试评价的技术需求。电源子系统需要对各个小的用电设备系统的供电需求进行分析,设计出总体的电气系统,便于总体电气系统对各个子系统的供电电源进行管理。定位子系统能够输出自动驾驶系统车辆的运行轨迹,高精度定位车辆的行驶状态和位置,结合移动差分定位模块和轮速计算模块,为自动驾驶系统汽车实际道路测试提供可靠的定位数据。真值感知子系统主要由激光雷达和智能摄像头组合,能够对连续驾驶环境中的动静态目标进行正确识别,包含轿车,卡车,行人,两轮车等,并且能够精确测量和标注感知的目标物数据,例如主车与相邻目标车之间的横、纵向距离、速度、加速度、位置等信息。参考音视频子系统能够获取实际道路测试过程车内外的音视频数据,例如高清分辨率视频参考摄像头,清晰记录实际道路测试场景信息。采集存储子系统具有高性能工业数据采集存储能力,具有丰富的数据接口,例如CAN/CANFD协议接口、车载以太网接口、RJ45以太网接口、USB3.0及3.1接口、音频接口以及支持数据的高速写入和读取的高带宽传输接口。

数据中心云端框架采用实现存储、计算、网络及硬件设施的解耦,统一规划网络、存储和计算资源,提高云平台可拓展能力的超融合架构。基础设施由数据存储系统、超融合计算模块、数据保护模块、数据收集模块和网络设备组成。平台服务通过设备集群管理软件能够监控和管理基础设施资源,包括高性能计算节点、海量数据存储节点、交换机设备和虚拟化软件。自动驾驶汽车实际道路测试系统应用围绕数据存储层、业务服务层、页面访问层和负载均衡层进行部署,总体设计技术架构如图1所示。自下而上依次为上层提供服务,同层的应用可以随意安装不存在依赖关系。数据存储层主要是提供关系数据存储或者非关系型(NoSQL)数据存储的功能。业务服务层主要为上层页面访问层提供基础服务能力,包括离线数据真值处理、行程评测、场景提取、事件评测和场景评测等,分析处理之后的数据实现切片、回放和下载;页面访问层主要是提供页面展示逻辑;负载均衡层主要提供服务和页面的负载能力,分散服务器压力,增强服务的并发能力。

图1 总体设计技术框架

自动驾驶汽车实际道路测试系统应用主流分布式架构技术,采用springboot做为基础的技术架构,redis做为nosql数据库,mysql用于永久数据的存储,通过分布式任务分发和调度系统支持大数据计算。系统后端使用的java和python编程语言,灵活多变,通用性较好;前端使用react,应用服务和业务分离,极大提供了系统的可扩展性和兼容性,提供更加好的用户体验。

在整体技术架构应用时,一方面对于访问频率不高或者需要长期存储的数据,系统会将数据存储mysql中,设置定期的全量离线备份,保证数据的完整性,需要的时候可以将数据进行回热。另一方面,使用redis做为nosql缓存数据库,将常用的数据和使用频率很高的数据放入redis内存数据中。当系统访问热点数据时,直接从内存中获取数据,可以提供系统的响应速度。

2.3 应用模块

自动驾驶汽车实际道路测试系统在数据中心云端的应用服务主要为权限管理模块、项目管理模块、车辆监控模块、行程关联模块、场景提取模块和分析评测模块。

2.3.1 权限管理模块

基于自动驾驶汽车实际道路测试系统权限管理模块设定用户群、角色和应用服务三部分内容。用户群可以创建、编辑、删除和修改用户账号。角色是对用户和权限的管理和分配,不同的角色可以分配不同的用户和不同的模块操作权限。应用服务由各个业务模块组成,例如车辆监控、项目管理、行程关联、场景提取和分析评测等各个业务模块组成。

用户群分为超级管理员、主账号和子账号群体,超级管理员具备创建主账号、子账号、角色、应用服务功能;主账号能够创建子账号用户和同步子账号数据。子账号能够根据分配的模块权限操作对应的功能模块。角色群能够按照项目要求在成员中添加主、子账户并为其分配对应的操作权限。应用服务主要是建立测试机构和项目名称信息,结合平台各个功能模块组成该项目的项目成员和操作模块权限。其中应用服务各个功能模块操作权限相对独立,互不影响。

2.3.2 项目管理模块

项目管理模块的主要功能是对多项目、多车辆、多任务信息的分类和管理。项目管理可以同步权限管理模块的账户信息和项目信息。根据车端的不同测试任务设定的委托单位、委托项目、部门、委托人和创建时间等项目信息关键字段。

2.3.3 车辆监控模块

车辆监控数据实时存储和可视化。车端消息数据与图片数据的存储,车辆监控模块可显示执行路试任务的车辆数、位置、速度、天气和道路类型等信息。监控模块能够在线实时视频监控、状态监控和传感器监控。在线监控视频窗口展现车辆的行驶视频画面;状态监控展现不同道路(高速公路、快速路、城市道路、其他道路)下已采集里程数和已采集时长、Log信息;传感器监控展现车端所接入的各种数据通道的运行、故障、离线装填。

2.3.4 行程关联模块

同一测试时间、测试地点只能够执行一个任务,即只能够存在一条行程。所以,每次任务都代表一次行程。行程具有行程信息列表,包含委托单位、委托项目、委托人、项目里程、项目时长、试验日期、工程师、驾驶员、自定义信息和备注信息等字段组成。

这些行程字段在云端平台进行创建,可以导出为行程字段信息,将字段信息导入到车端采集软件。车端数据包内生成包含行程字段的关联文件。将车端离线数据上传至云端服务器,通过云端行程模块通过关键文件校验进行行程数据关联和管理。

2.3.5 场景提取模块

场景提取模块部署在场景管理平台,主要实现场景数据管理、场景标签管理和场景提取配置功能。场景提取模块主要将编译好的python脚本运行在java模块上进行工作。场景提取模块的程序为用户自定义开发的程序,可一次发起多个场景提取程序,每个程序对应一条场景数据。通过设计具体场景的算法逻辑,结合参数化配置文件,执行场景提取脚本。通过更改参数值得到所需要的测试场景。场景提取的场景数据可切片、回放、评测、打印和生成报告。

2.3.6 分析评测模块

在实际道路测试过程中,根据指标评估需要对道路类型、天气状态、高低速占比、自动驾驶里程和时长等统计类指标进行分析和评测。用户通过使用python语言自定义参数化评测规则,运用java进行后处理,完成对所需指标的数学统计。通过场景提取得到的场景、在线采集手动或自动方式记录的事件标签数据也可以通过同样方式完成分布统计和分析。分析评测的数据可切片、回放、评测、打印和生成报告。

2.4 业务流程

基于实际道路测试系统业务需求、平台框架和应用模块的研究,其具体业务实施流程[15]可以分为创建用户和角色、下发行程任务、车端数据采集、行程数据关联、离线数据分析五个阶段,如图2所示。

图2 系统业务流程

2.4.1 创建用户和角色

通过权限关联模块登录超级管理员账户,填写用户名和邮件来创建子账户,并且设定账户相关的角色。在角色中添加项目成员和应用服务权限。角色可以关联不同的用户和不同的权限。在超级管理员账户中创建的子账户、角色和应用服务权限,数据信息会同步至创建的子账户项目管理模块,包含委托单位、委托项目和委托人信息。

2.4.2 下发行程任务

根据实际道路测试的行程要求,在系统建立行程信息。行程信息包括项目信息、车辆信息和自定义信息。项目信息主要为委托单位、委托项目、委托人、项目里程、项目时长、检验依据、试验日期;车辆信息主要为工程师、驾驶员、车辆品牌、车辆型号、车辆车牌、保单号、VIN号、工程文件、数据协议等。根据不同的项目特征和特点,规范填写行程信息内容。一条行程信息对应一个行程,新建立的行程信息会生成独立的行程编号,作为该行程的唯一标识。在新建行程之后,通过导出行程字段信息,分别上传至对应的车端采集平台。此后,云端更改的行程信息可以通过网络同步至车端。

2.4.3 车端数据采集和监控

云端的行程信息下发至车端,车端数据采集软件进行数据采集,包括车辆总线、传感器数据、道路类型、交通环境、天气、光照等实际道路数据。实际道路测试过程的实时回传车辆行驶轨迹、里程和时长,车端数采设备运行状态、数据通道传输状态等;车辆的行程信息进行回传,例如音频、视频回传、已采集里程和时长的统计、自动驾驶模式下的行驶里程和时长统计。车端同步采集存储的离线数据需要采用高带宽传输设备存放至服务器。

2.4.4 行程数据关联

通过车端测试设备采集得到的离线数据信息以高带宽的速度传输、分库分表、自动上传至云端系统。使用系统的行程关联模块进行数据读取、清洗、校验和关联,滤除不符合测试要求的数据。

2.4.5 离线数据分析

车端测试数据离线上传至云平台,按照测试要求分析和处理测试数据,主要分为真值处理、场景提取、行程分析评测、事件评测和场景评测。

实际道路测试场景具有无穷性和随机性,通过测试评价指标的筛选和提取,获得有利于指标评价的测试场景。在实际道路测试过程中,通过使用脚本和自定义参数配置的方式,实现多种典型功能场景的提取。在场景提取完成之后,可以对场景数据进行可视化,检查实际道路测试过程中发生问题的场景类型及分布情况。通过事件标签、状态标签的方式记录测试过程的道路类型、天气类型、自动驾驶模式、车辆限速、交通流状态等数据信息。数据离线处理之后在云平台进行事件标签评测、场景评测、以及行程评测,分析事件、场景以及行程的里程、时长和数目统计,并直接生成对应的测试报告。

3 系统应用

为了验证实际道路测试系统设计的科学性和可行性,本文选取具备领航辅助驾驶功能的乘用车为测试对象,搭载一套车端数据采集系统,如图3所示。该被测车辆能够在城市快速路执行点对点的动态驾驶任务。通过数据中心云端系统,如图4所示,结合车端数采系统在实际道路开展测试,对创建用户和角色、下发行程任务、车端数据采集和监控、行程数据关联、离线数据分析的业务流程进行了应用实践。

图3 车端数据采集系统

图4 数据中心云端机房

3.1 测试路线

选定某段城市快速路作为L2+级领航辅助驾驶测试车的测试路线,以8:00,14:00和20:00为起始路试时刻,共开展3次实际道路测试验证,单次行驶里程约80km。在保证驾驶安全和不违反交通规则的原则下,执行点对点的动态驾驶任务。

3.2 测试要求

测试车辆基于L2+领航驾驶辅助系统执行点对点的动态驾驶任务,记录车辆自动驾驶控制模式、自主变道、汇入匝道、汇入主路、人工干预、系统发出介入请求、系统降级和其他系统未满足试验要求的时间和事件。

3.3 测试指标

通过开启领航辅助驾驶功能,对测试车辆的智能驾驶性能进行客观统计评价,如表1所示,以激活里程占比、接管率、匝道汇入主路成功率、主路汇入匝道成功率和自主换道成功率的计算作为性能评价的主要输入指标。

表1 智能驾驶性能体验指标

其中,领航驾驶辅助系统激活里程占比得分按如下公式计算:

式(1)中,ma为系统激活里程;mz为总行驶里程。

汇入匝道成功率得分按照如下公式计算:

式(2)中,ns为汇入匝道成功次数;nf为汇入匝道失败次数。

汇入主路成功率得分按照如下公式计算:

式(3)中,ns为汇入主路成功次数;nf为汇入主路失败次数。

自主变道成功率得分按照如下公式计算:

式(4)中,cs为自主换道成功次数;cf为自主换道失败次数。

百公里人工接管得分按照如下公式计算:

式(5)中,ts为人工接管次数;mz为自主换道失败次数。

3.4 测试实施

基于被测车辆的领航辅助驾驶功能定义和ODC、相关技术标准/规范、企业自测数据等,自动驾驶汽车实际道路测试系统的车端数据采集和监控和离线数据分析模块功能进行测试验证,如图5~图7所示。

图5 车端数据采集和监控

图6 云端数据回放

图7 云端数据分析

3.5 测试结果

以被测试车辆的行程任务为例对测试实施方案的指标进行统计分析,数据中心云端统计分析领航驾驶辅助系统激活里程为211.415km,总的行驶里程为239.539km。对评价指标的统计次数进行提取分析,如图8所示。按照公式(1)~式(5)计算结果如图9所示。因此,系统激活里程占比得分为88.259分、汇入匝道成功率得分53.333分、汇入主路成功率得分为72.727分、自主换道成功率得分为83.942分及百公里人工接管次数得分为72.447分。根据表1分析计算,被测试车辆的智能驾驶性能体验总得分率为75.29%。

图8 评价指标统计

图9 评价指标得分

4 结语

本文立足第三方视角,基于自动驾驶汽车实际道路测试系统设计方法的研究,提出了云平台的自动驾驶汽车实际道路测试系统设计方法。针对实际道路测试系统的创建用户和角色、下发行程任务、车端数据采集和监控、行程数据关联、离线数据分析等模块,分别从业务需求、基础设施需求和数据安全要求方面,给出了具体设计的要求和实施方法,以实现自动驾驶汽车实际道路测试系统的可靠性、科学性和规范化。在有效验证自动驾驶汽车实际道路测试系统各个应用模块的同时,自动驾驶汽车实际道路测试系统建设提供重要的技术参考和依据,可作为一种规范化方法广泛应用。

猜你喜欢
道路自动模块
28通道收发处理模块设计
“选修3—3”模块的复习备考
坚持中国道路——方向决定道路,道路决定命运
道听途说
我们的道路更宽广
自动捕盗机
让小鸭子自动转身
自动摇摆的“跷跷板”
关于自动驾驶
一次骑行带来的感悟