武汉智能网联道路智能化建设规范

Posted 2022-08-22 爱是与世界平行

内容整理自：武汉智能网联道路智能化建设规范（总则）（征求意见稿）

1 总体架构

智能网联道路智能化建设规范分为总则和细则两部分，本规范为总则部分，细则部分单独另行发布。

2 智能网联汽车道路准入要求

智能网联汽车在满足基本功能要求前提下，根据道路安全风险评估分级，结合智能网联汽车特点及测试与示范应用具体需求，对智能网联汽车采取分区域、分时段、有条件的进行道路开放，并提出相应准入要求。

2.1 智能网联汽车基本功能要求

（1）智能网联汽车应满足《机动车运行安全技术条件》（GB7258）等相关技术安全要求。

（2）智能网联汽车测试和示范应用过程中收集和产生的个人信息及重要数据等应当按照有关法律法规的规定在境内进行存储和使用，并主动接受国家相关部门的安全监管。

（3）智能网联汽车需具备如下自动驾驶功能：交通信号识别及响应、道路交通基础设施与障碍物识别及响应、行人与非机动车识别及响应、周边车辆行驶状态识别及响应、动态驾驶任务干预及接管、风险减缓策略及最小风险状态、自动紧急避险、车辆定位、联网通信等；

（4）智能网联汽车进行开放道路测试及示范运营应安装车载终端设备接入第三方管理平台，接受平台的在线监管；

（5）智能网联汽车应按照《基于 LTE 的车联网无线通信技术 消息层技术要求》协议规范要求向监管平台提供相应的车辆状态信息。

（6）智能网联汽车的车辆状态信息应至少包括车辆标识、车辆控制模式、 车辆位置、车辆速度、车辆加速度、行驶方向和车辆总里程等；

（7）道路测试车辆、示范应用车辆车身应以醒目的颜色分别标示“自动驾驶道路测试”或“自动驾驶示范应用”等字样，提醒周边车辆及其他道路使用者注意，但不应对周边的正常道路交通活动产生干扰。

（8）智能网联汽车应具备人工操作和自动驾驶两种模式，且能够以安全、快速、简单的方式实现模式转换并有相应的提示，保证在任何情况下都能将车辆即时转换为人工操作模式；

（9）智能网联汽车应安装具备提醒功能的装置，当遇到自动驾驶系统失效时，该装置应当立即提醒测试驾驶人接管测试车辆；

（10）智能网联汽车的车辆状态信息应满足下表的要求：

（11）智能网联汽车应具备车辆状态记录、存储及在线监控功能，能实时回传强制提供项信息，数据记录和存储应满足《智能网联汽车道路测试与示范应用管理规范（试行）》的要求。

2.2 智能网联汽车道路准入要求

（1）对于高速、快速路、高架道路场景，智能网联汽车还需满足在开放测试道路采用自动驾驶模式测试不少于 240 小时或 1000 公里的道路测试，在测试期间无交通违法行为且未发生道路测试车辆方承担责任的交通事故。

（2）对于隧道、涵洞、环岛等道路场景，智能网联汽车需在封闭测试场地进行对应的功能测试，测试通过后方可在开放道路上进行对应场景的测试。

（3）智能网联汽车根据不同道路安全风险等级要求开展测试及示范运营活动。

3 道路智能化建设总体要求

基于道路安全风险等级评估以及智能网联汽车道路准入要求，针对道路安全风险等级评估因素，通过智能化基础设施、道路交通设施以及支撑平台的建设，有效降低道路安全风险等级、提升交通运行效率及建立智能化管理服务。

3.1 道路智能设施

道路智能设施主要包括路侧通信设施、边缘计算单元、智能摄像头、激光雷达、毫米波雷达、气象监测器以及路面环境监测器等，通过在路侧布设相关智能化设备，实现违章事件检测、交通数据采集、交通事件检测、交通参与者检测、路面以及气象环境监测等功能，基于以上交通信息的采集、分析、融合处理等，实现区域交通整体监控、优化管理以及特定交通场景的安全预警保障等功能。针对不同道路场景总体要求如下：

（1）城市道路路口侧重行人、机动车、非机动车检测、交通事件检测、交通流检测等；

（2）城市道路路段侧重机动车检测、非机动车检测、交通事件检测、路面及气象环境监测等；

（3）城市快速路及公路（包括高速公路）侧重机动车检测、交通事件检测、路面及气象环境监测等；

道路智能设施需满足如下要求：

（1）道路智能设施应具备路侧通信、交通流检测、交通事件检测、交通参与者检测、路面及气象环境监测等道路交通信息感知检测功能，优先选择一机多能或感知融合一体化设备；

（2）根据对时延从高到低的不同应用需求，综合考虑建设成本，分别选用在杆件、路侧、通信机房或数据中心布设 MEC 设备；

（3）道路智能设施优先安装在道路已有杆件上，在功能及合规性满足的前提下，设备安装的杆件选择优先级依次为：路侧灯杆、红绿灯杆件、交管监控杆、标志牌杆件、新建杆件；

（4）道路智能设施至少具备 RJ45 10M/100M/1000M 自适应以太网口，支持 TCP/IP 协议；

（5）道路智能设施应支持自定义 IP 地址，支持灵活的组网方式；

（6）道路智能设施优先输出结构化数据，智能摄像头、激光雷达等设备要求输出原始图像及点云数据；

（7）道路智能设施应支持实时数据上传；

（8）道路智能设施支持与卫星时钟同步功能，优先选择自带 GNSS 模组设备，设备至少支持 NTP 协议；

（9）道路智能设施应支持车路协同支撑平台对设备的统一调度和管理；

（10）路侧通信设施、交通流检测设施、交通事件检测设施、交通参与者检测设施应至少支持抱箍安装、吊装等方式；气象监测设施和路面环境监测设施应支持共杆布设，实现共杆、供电、采集系统和通信传输共享；

（11）道路智能设施防护等级应不低于 IP 65。

（12）道路智能设施应满足二级等保防雷要求。

（13）路侧通信设施应可通过内置具备接收高精度定位设施提供 GNSS 模组的时钟信号，能与北斗时钟信号同步。同时支持车辆通信设备无 GNSS 信号下的时钟同步，具备通过直连通信链路为车辆通信设备提供时钟同步功能。

（14）路侧通信设施应具备 PC5 口和 Uu 口的空口安全和传输安全的能力。

（15）路侧通信设施支持与信号机、多种检测器、应用服务器对接。

（16）路侧通信设施具备符合一致性认证的协议栈软件。

（17）路侧通信设施需接入第三方 CA 安全认证平台。

3.2 道路交通设施

道路交通设施的建设及改造主要基于智能网联汽车加入现有交通流后，对现有道路基础设施进行针对性增加，以加强智能网联汽车安全保障及提升道路交通安全。主要满足以下要求;

（1）适应智能网联汽车驾驶的道路应遵循“安全合理、经济适用、资源节约、因地制宜”的原则设置道路交通安全和管理设施。

（2）测试道路应按《道路交通标志标线》、《武汉市交通管理设施设置技术指引》完善道路交通安全和管理设施。

（3）测试道路应充分利用既有道路的交通安全和管理设施，不能满足使用需求的应进行改造。

（4）对于评估风险较高或已经发生较大交通事故的路段应注重被动防护措施的设置。

（5）道路交通安全设施和管理设施应以道路基础设施条件、交通流条件、交通环境、道路使用者需求及交通管理的需要进行设置。当设置条件发生变化时，应及时增减、调换、更新交通安全设施和管理设施。

（6）道路交通安全和管理设施除应保持其各自特性和相对独立外，还应相互匹配，使之成为统一、协调、完整的系统工程。

（7）道路交通安全和管理设施的养护、管理应有专门机构负责。定期开展排查，发现损毁、灭失、缺少的应及时修复和补充。

（8）测试道路在开放前应将风险评估报告及道路交通安全和管理设施改造设计图纸提交至公安交通管理部门审查。

3.3 支撑平台

道路智能化的建设除了对道路的通信、感知以及道路交通等设施进行建设外，同时需要有相关的支撑系统平台对智能化设备、车辆、交通等进行监控、管理、运维、安全保障、数据处理等，进一步增强道路交通安全，提升交通运行效率，提供智能化管理服务等。

3.3.1 数据平台

数据平台汇聚路侧所有智能化设备、车端以及其它平台端的数据，平台应具备数据存储、查询、索引、分析等功能，通过安全、梳理、整合等一系列处理，产生可信及可用的信息，为各种应用提供数据支撑。

（1）提供多种数据采集工具，支持多种格式数据采集；

（2）具备对海量数据的存储、计算、接口服务能力；

（3）提供接口服务，供二次开发应用；

（4）提供权限管理能力，可对不同用户开放不同模块。

3.3.2 管理平台

3.3.2.1 设备管理平台

设备管理平台主要是对设备进行实时监测和智能监管，提供针对设备的录入、监控及管理。设备管理平台需具备对设备的分析、处理、展示、查询、标记及定位等功能，支持管理多种类型、厂商的设备，能对设备厂商、品牌、型号等进行字典管理，同时能对设备的运营状态、绑定状态、运行状态进行管理。通过汇聚所有设备的状态数据，平台可对接各硬件设备接口或网管平台，具备对接口数据进行脱敏、封装、存储等相关功能。

3.3.2.2 车辆管理平台

车辆管理平台主要是对开放测试道路的智能网联汽车测试、示范应用及运营进行管理。车辆管理平台需要具备车辆管理、信息查询、监控管理、系统设置等功能。支持车辆与 OBU 的绑定关系管理，可查看车辆的实时运行状态，包括车辆位置、速度、航向角、挡位、行驶里程等信息，可监控车辆实时轨迹，查看历史运行轨迹等。

3.3.3 管理平台

3.3.3.1 V2X Server 平台

V2X Server 平台主要实现车路协同的连接，包括车路协同数据的收集、路由和分发，提供统一的人/车/路建模抽象和数据开放服务。

（1）为路侧设备提供统一的设备建模、发放、认证、注册鉴权、设备升级、 配置、数据订阅、命令、数据存储归档服务等，保证只有合法设备才能相互通信以及传输信息的安全。

（2）对接交通管理部门的信息及需求，提供交通事件的分析和下发服务，包括车辆、路侧感知、信号机、系统录入事件信息等。提供交通标志信息下发服务，实现电子标牌功能，并支持电子标牌字典服务。

（3）对感知设备上传的信息进行采集、融合及分析，提供道路信息的实时分析和发布服务。

3.3.3.2 感知融合平台

感知融合平台将各个感知模块采集的多源异构数据（如摄像头、激光雷达、毫米波雷达等设备的数据）以视频、图片、文字等形式呈现，并进行数据有效挖掘识别和融合交互，实现数据标准化和智能处理。

3.3.4 高精度地图

（1）高精度地图采集、制作、生成、格式转换应符合国家、行业相关标准要求，并符合国家及省市测绘法规管理规范要求。鼓励企业与有资质的图商合作进行数据管理,规范众包数据采集、存储和传输行为。

（2）高精度地图采集制作范围应包含各类道路及道路设施数据。道路数据包括主道、辅道、应急车道、非机动车道、人行道等。此外，采集制作信息应包括不限于路面、路侧、空中交通通勤、控制、管理等数据及交通附属设施等全量数据。

（3）高精度地图数据应包括道路属性数据、几何数据、关联关系数据。道路属性数据应包括车道模型数据（类型、通行状态、数量和通行方向等）和车道线模型数据（类型、颜色、宽度和编号等）。车道几何数据应包括车道边线、车道中心线、车道参考线等数据。关联关系数据应包括车道与道路关联关系数据。

（4）高精度地图至少包括道路层、车道层、道路标志标线层以及道路设施层数据，可根据需要扩展临时信息层和自定义图层。道路网图层组:用于描述由道路交织而成的交通网络系统,以支持路径规划；车道网图层组:用于描述由车道交织而成的交通网络系统，以支持路径规划；道路标线层组:是对现实世界施划或安装于道路上的各种道路交通标线的记录，常用于车道级显示、感知、定位和规划；道路设施层组:用于描述与表达真实世界的各类道路交通设施,以支持感知、定位、规划和控制；临时信息层组:用于进行动态数据的接入，主要包括车辆、行人等高度动态数据，更新频率快；自定义图层组:用于进行扩展数据的接入，是基于现有地图数据的补充与修改，以支持个性化导航、高级可视化渲染等。

（5）高精度地图数据应包括：矢量数据、激光点云数据、视觉数据、全景照片、三维模型数据、opendrive 或 NDS 数据，可生成 shp 文件；

（6）高精度地图采用 CGCS2000 大地坐标系，数值保留小数点后 7 位，高程基准为 CGCS2000 椭球大地高，数值保留小数点后 4 位。

（7）高精度地图中涉及的所有路口、环岛、匝道、分合流等位置应是全量数据。不在制图范围内的路段，应至少采集 200 米或不足 200 米的至下一个路口。

（8）高精度地图应提供 OPENDRIVE 数据格式，数据支持 OPENDRIVE V1.4、 V1.5、V1.6 版本，并可快速扩展支持 OPENDRIVE 数据格式的后续演进版本。

（9）高精度地图应可通过 V2X Map 自动转化工具自动输出基于车联网无线通信技术 V2X 应用要求的 Map 消息集数据，Map 消息数据包括路口和路段、一个或多个路口。

（10）高精度地图测绘车至少搭载 GNSS、INS、激光和视觉等传感器，其中 GNSS 接收机和天线必须是大地测量型设备，且需支持 20H 及以上高采样率。测绘车运行速度不应超过 60km/h，尽可能避免突然加减速、快速转弯等突发性操作。

3.3.5 高精度定位

（1）高精度定位系统应符合国家、行业相关标准要求，并符合国家及省市测绘法规管理规范要求。

（2）GNSS 高精度定位服务支持 CGCS2000 和 WGS84 坐标系，同时具备CGCS2000 和 WGS84 两个坐标系服务端口。

（3）GNSS 高精度定位服务支持 RTCM3.2 格式播发差分数据，支持Ntrip1.0 协议。

（4）GNSS 基准站网、高精度定位服务系统应能提供全天候持续稳定服务，服务在线率不低于 95%。

（5）应提供稳定持续的高精度定位服务，静态和动态实时定位精度：水平优于 10 厘米，垂直优于 20 厘米。

（6）应提供稳定可靠复杂场景的高精度定位系统服务，包括不限于高架、桥梁、临水、遮挡、高楼等场景，高精度定位系统 RTK 服务连续平均固定解应不低于 95%。

(7)基准站点要求周围无遮挡（障碍物截止高度角大于 15°）及其他信号干扰源；车道数据采集应尽量避开车流拥堵高峰期，以免采集数据遮挡，影响数据制图质量。

（8）GNSS/INS 精耦合解算完成后，应对采集范围内 GNSS 失锁或者信号较差区域利用外部控制点进行纠正处理，保证数据生产精度。

（9）高精度定位系统应具备高精度定位相关的数据处理、运行监控、信息服务、网络管理、用户管理、轨迹追踪等功能。

3.3.6 安全平台

安全平台应支持基于国密算法（国家密码管理局认定的国产商用密码系列算法）的数据保密性、完整性和真实性等的保护，包括数据加密解密、数字签名验签、数据完整性防护、密钥生命周期安全管理、网络安全防护、系统安全防护和应用安全加固等安全功能组件，满足 V2X PKI 体系业务需求，并可支持扩展提供边端协同、边云协同的网络安全防护能力。平台具体要求如下：

（1）安全平台应支持 TDCL 签发及发布，保证相同 RCA 体系中，不同PCA/ACA 下的 V2X 设备的互认。

（2）安全平台应支持对接国家级 TRCL，保证不同 RCA 下的 V2X 设备互认。

（3）安全平台应支持 V2X 设备管理，包括路侧、车载设备的管理，支持对设备初始信息进行录入。

（4）安全平台应支持基于 DCM 架构的 V2X 设备证书申请，包括 EC、PC、应用/身份证书的在线申请。

（5）安全平台 PC 证书应支持密钥衍生、链接值查询、批量下载等功能。

（6）安全平台应支持 MA 系统建设及不当行为上报等功能。

（7）安全平台应支持证书撤销，其中 PC 证书应支持基于链接值的高效撤销。

（8）安全平台应支持 EC 的黑名单管理功能。

（9）安全平台应支持 X.509 格式数字证书体系，应提供设备数字证书签发、审核、分发、更新、查询、撤销等证书管理功能。

（10）安全平台应支持地理位置加密密钥申请、密钥安全分发、密钥轮换、密钥备份和恢复等功能，实现对地理位置/地图信息等个人隐私、国家基础资源信息保护，应提供安全 API、SDK&CLI 命令行工具等多种方式以便第三方集成。

（12）安全平台应为车路协同路侧设备和车辆 OBU 提供智能的端-云安全通信能力，应支持设备授权、身份鉴权、会话管理、完整性校验、TLS 加密传输、数据备份与恢复和访问控制等多种功能，保证车联网信息数据在端-云通信传输过程中的安全性。

3.3.7 三维城市模型

（1）三维城市模型应采用统一的、符合国家规定的平面坐标和高程系统，当采用地方坐标系时，应与国家统一坐标系统建立严密的转换关系。

（2）三维城市模型应至少包含地形要素模型、建筑要素模型、交通要素模型、水系要素模型、植被要素模型、场景要素模型及其他要素模型。建筑要素、交通要素应不劣于Ⅰ级精细度表现，植被要素、场地要素模型和水系要素模型应不劣于Ⅰ级或Ⅱ级精细度表现，其他要素模型中交通设施应采用细节建模表现，剩余要素模型应不劣于Ⅱ级精细度表现。

（3）三维城市模型建设应采用高精度、高可靠性类别控制点，控制点应均匀分布在采图范围内、覆盖各类型要素场景。控制点的选取、测量等应符合国家和行业相关标准。

（4）要素模型应按照 CJJ/T 157-2010《城市三维建模技术规范》的规定划分细节层次，其几何模型应统一以“米”为计量单位；每个模型应为独立对象；在满足各级别模型细节层次要求的情况下，应尽量减少几何模型的面数；不应存在漏缝、共面和废点等；对重复利用的模型，宜建立模型库。

（5）实景三维模型数据属性信息应包含描述模型类型、用途和特征等的基本属性信息和专题属性信息。每一个三维模型应有唯一标识，应有每个三维模型的准确描述信息；属性信息内容应正确、完整，并可根据实际应用需要进行扩充。

（6）实景三维模型数据质量应满足数据完整性、几何精度、属性精度、现势性和逻辑一致性的要求。

（7）三维城市模型数据采集、制作、生成、格式转换应符合国家、行业相关标准要求，并符合国家及省市测绘法规管理规范要求。