简介：这份PDF文献以自动驾驶面临的挑战为核心，整合了吉利汽车研究院总工程师与博世底盘控制系统中国区副总裁在智能网联汽车前沿论坛上的专业分享，适合智能汽车研发、人工智能、车辆工程等领域的从业者、高校研究者及学生作为参考文献阅读。内容围绕感知系统、网络信息安全、功能安全三大主题展开，涉及摄像头、雷达、激光雷达等多传感器在复杂交通环境中的实时感知与可靠性难题，V2X通信、黑客攻击、数据泄露等网络风险，以及ISO 26262、UNECE等标准法规的落地适配要求。特别是对博世在中国市场的自动驾驶路线图有清晰梳理，包括2020年L2.5级高速公路辅助功能、2021年L3级交通拥堵引导功能、遥控泊车及驾驶员监控摄像头等关键节点，并强调了针对中国驾驶行为与环境工况的本土化开发思路。资源为PDF文件，共1个文件，压缩包大小2.84MB，内容精炼，便于快速获取行业前沿信息；目前页面已有103人学习下载，读者可据此建立对自动驾驶挑战的体系化认知，并在开展相关技术调研、项目规划或课程学习时作为参考切入点。
1. 为什么花了十年时间，感知算法还没敢说「超越人」
吉利汽车研究院总工程师刘卫国在分享中提到一个很扎心的结论：从 2008 年开始做自动驾驶系统，到 2018 年时视觉、雷达、V2X 算法都试过了，但「目前为止没有完整算法能够超越人」。这句话背后其实是整个行业的心照不宣：感知不是单点模型的精度问题，而是长尾场景、失效模式和安全冗余共同作用下的系统工程问题。一篇关于「自动驾驶面临的挑战」的访谈材料，把感知系统、网络信息安全、功能安全放在一起讨论，恰恰说明这些挑战已经超越了算法本身，进入到了工程落地的深水区。
这篇文章不打算复述访谈内容，而是把材料里提到的技术线拆开：感知融合和语义分割的工程边界、从 L2 到 L3 的冗余架构设计、SOTIF 和仿真验证、以及安全关键系统在真实工况里的本土化落地。如果你正在做智能驾驶相关的开发、测试或选型，这篇文章能帮你在面对「挑战」这个词时，知道它的具体形态和应对路径。
2. 感知系统与语义分割：多传感器融合的工程边界在哪里
2.1 传感器选型不是堆料，而是应对失效模式的博弈
刘卫国在访谈里强调感知系统是车辆关键技术里最重要的一点，而目前感知系统的核心组件通常包括摄像头、毫米波雷达、激光雷达和超声波雷达。博世 2018 年之前在中国大规模落地的是 L1/L2 辅助驾驶，那个阶段主流的传感器配置是前视摄像头加毫米波雷达，成本可控且性能在高速工况下够用。到了 2020 年量产遥控泊车时，才引入超声波雷达和环视融合。这个时间线说明一个问题：传感器的加入不是「越来越好」，而是「这个功能需要什么感知冗余」。
我一般会把传感器选型看成失效模式的互补问题，而不是精度的堆叠。摄像头对车道线、交通标志和物体分类最强，但遇到逆光、隧道出口的明暗突变、雨雾天就很容易失效。毫米波雷达不受光照影响，测距测速准，但横向分辨能力弱，经常把护栏和静止车搞混。激光雷达点云精度高，能精确描绘物体轮廓，但价格高、恶劣天气噪点多，而且对远处小目标的识别并不稳定。超声波雷达只在低速近距离泊车场景里可靠。
| 传感器 | 强项 | 典型失效模式 | 常见补充手段 |
|---|---|---|---|
| 摄像头 | 目标分类、车道线、交通标志 | 逆光、雨雾、夜间暗光 | 图像增强、红外补光 |
| 毫米波雷达 | 测距测速、全天候 | 静止目标漏检、横向位置不准 | 与摄像头目标级融合 |
| 激光雷达 | 近距离高精度三维感知 | 雨雪衰减、反射率低的黑色物体 | 与视觉语义信息对齐 |
| 超声波雷达 | 近距离探测、泊车 | 探测距离短、脏污误报 | 环视摄像头视觉校验 |
2.2 语义分割在实际自动驾驶系统里的位置
语义分割通常被认为是视觉感知里的「高配」能力，因为需要对每个像素做分类，计算开销大，实时性压力也大。它能直接给下游提供可通行区域、车道边界、障碍物轮廓的稠密描述，尤其对非结构化道路和城市复杂路口很有价值。但有意思的是，L2 级量产系统里反而很少依赖语义分割，更多用目标检测加语义实例信息；到了 L3 和更高级别，语义分割才开始承担更重的角色。
如果把语义分割接到车端模块里，常见的方式是采用 DeepLabV3 这类带空洞卷积的模型。下面是一个用 PyTorch 加载预训练模型做推理的示例，这种思路在验证分割效果时很常见，也是拿到自动驾驶数据集之后快速做 baseline 的基本操作：
import torch from torchvision import models, transforms from PIL import Image # 加载在 COCO 子集上预训练的 DeepLabV3 模型 model = models.segmentation.deeplabv3_resnet101( weights=models.segmentation.DeepLabV3_ResNet101_Weights.COCO_WITH_VOC_LABELS_V1 ) model.eval() # 车端实际部署时，输入通常会被压缩到 512x512 或 768x768 以控制时延 preprocess = transforms.Compose([ transforms.Resize((512, 512)), transforms.ToTensor(), transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]) ]) def infer_segmentation(image_path: str): img = Image.open(image_path).convert("RGB") input_tensor = preprocess(img).unsqueeze(0) with torch.no_grad(): output = model(input_tensor)["out"][0] mask = output.argmax(0).numpy() return mask # shape: (512, 512)，类别索引 0~20这段代码里有几个参数要说明。Resize((512, 512))是输入分辨率，车端一般不会直接用原始相机分辨率去做全图分割，因为 ResNet101 骨干网络的计算量很大，512 的分辨率已经对算力平台有要求。Normalize的均值和标准差是 ImageNet 的统计值，如果换用 BDD100K 或 Cityscapes 上训练好的模型，需要同步更换预处理参数。argmax(0)得到每个像素的类别索引，类别数量和训练数据的标签定义强相关，COCO 预训练模型只有 21 类，实际车端往往要重新在自有分割数据集上微调。
2.3 数据集才是感知算法的真正上限
网络上对自动驾驶数据集的讨论非常多，但真正在工程里用起来，最核心的问题不是数据量，而是标注质量和长尾覆盖。Cityscapes 对城市街景的像素级标注做得很细，BDD100K 覆盖了更多的天气和时段变化，Waymo Open Dataset 提供了多传感器同步数据。这些数据集拿来训练语义分割模型效果都不错，但到了中国的高速公路和城市快速路，情况会发生变化：加塞频繁、两轮车混行、工程施工区布置随意，开源数据集里这些场景占比低，模型很容易误判。
实践里我一般会先在自己的路采数据上做一次「空白测试」，把预训练模型跑一遍，统计哪些场景的 mIoU 掉得最狠。通常排在前面的就是雨天积水反光、强逆光下的隧道口、以及近距离遮挡。这些长尾场景单纯靠扩大数据集很难解决，成本上也承受不住，所以需要后续结合仿真场景生成来补。这里已经跨越到了测试验证的范畴，后面会专门展开。
3. 从 L2 到 L3：HWA/TJP 功能演进中的冗余与安全分解
3.1 博世路线图里的功能分水岭
博世在中国的路线图清晰地把功能落地分成几个阶段：2014-2018 年 L1/L2 大规模量产，2020 年落地可变道的 L2.5 级高速公路辅助 HWA，2021 年落地 L3 级交通拥堵引导 TJP，2022-2023 年再推更高级别的 L3 功能。这里面最值得关注的是 HWA 和 TJP 的差异，它不只是功能命令的不同，而是整个系统架构的升级。
HWA 本质上还是 L2 的延伸，车辆可以在高速上自动跟车和变道，但驾驶员必须保持注意力，随时准备接管。TJP 则是 L3 的功能，在交通拥堵场景下，系统在限定设计运行域内承担驾驶责任，驾驶员可以合法地把手从方向盘上拿开，看手机、处理邮件。这个责任转移的瞬间，就是工程上最敏感的分水岭。
3.2 冗余架构：L3 为什么必须加制动和转向冗余
蔡旌在访谈里讲得很直白：L2 不需要制动和转向冗余，L3 需要。原因从系统论上看并不难理解：L2 的安全兜底是驾驶员，系统失效时只要驾驶员及时接管即可；L3 里驾驶员已经不是安全兜底了，系统在设计运行域内必须在单点失效时仍然保持安全状态，这意味着制动系统、转向系统、电源、通信网络都要有备份。
| 维度 | L2（HWA 前身） | L3（TJP） |
|---|---|---|
| 驾驶员状态监控 | 方向盘握持检测或 DMS 提醒 | 强制驾驶员监控摄像头，判断是否适合接管 |
| 转向系统 | 单套 EPS，偶发失效靠驾驶员 | 冗余 EPS 或双套转向执行器 |
| 制动系统 | 基础 ESC + 驾驶员备份 | 冗余制动路径，电子制动助力备份 |
| 退出策略 | 提醒驾驶员接管，无最短时间要求 | 定义明确的接管时间（如 10 秒），否则最小风险 maneuver |
| 信息安全 | 低优先级 | 高优先级，需要防护恶意报文注入 |
这张表里最有工程价值的细节是驾驶员监控摄像头。L3 里摄像头不再是记录仪，而是缓解策略的输入信号：系统必须判断驾驶员是否把视线移回路面、手是否回到方向盘、是否具备接管条件。博世把驾驶员监控摄像头和 L3 同时引入，说明它已经把「人机共驾的责任交接」当作系统功能的一部分，而不是事后提醒机制。
3.3 功能安全：从危害分析到 ASIL 分解
ISO 26262 覆盖的是电子电气系统的功能安全，核心方法是先做危害分析和风险评估，也就是 HARA。具体做法是找出整车层面的潜在危害事件，然后按严重度 S、暴露概率 E、可控性 C 三个维度打分，查 ASIL 等级表。下面这个例子展示一个高速公路 ACC 场景的危害分析条目：
| 危害事件 | 典型场景 | S | E | C | ASIL |
|---|---|---|---|---|---|
| 车辆错误加速 | 高速公路上，前方车辆静止，ACC 继续加速 | S3 | E4 | C3 | D |
| 车辆无提示退出自动驾驶 | 隧道内 GPS 信号丢失，系统静默退出 TJP | S2 | E3 | C2 | B |
| 制动过晚导致追尾 | 旁车道车辆突然切入，AEB 触发过晚 | S3 | E3 | C2 | C |
ASIL D 是整个行业里最高安全等级，对单点故障度量指标有严格量化要求。工程上为了满足 ASIL D，通常会做 ASIL 分解：把一条 ASIL D 的安全需求拆分到两个相互独立的设计上，比如一个 ASIL B 的感知路径加一个 ASIL B 的独立验证路径，通过分解降低对单一组件的要求，但整体上仍然满足 D 的综合目标。这个做法在量产方案里非常普遍，代价是双份的开发成本和复杂的相互独立性论证。
3.4 SOTIF：功能安全覆盖不到的「聪明反被聪明误」
ISO 21448 定义了预期功能安全 SOTIF，它解决的不是电子硬件失效，而是「系统在正常工作时，因为功能不足或设计局限导致的不安全风险」。典型的例子是：视觉算法把白色货车车厢误识别为天空，这在功能上「正常工作」，但结果是致命的。刘卫国访谈里提到的「预期安全分解」，本质上就是在做 SOTIF 的工作——把感知算法的功能局限，通过场景分析找出来，再决定是改进算法还是限定运行范围。
L3 级系统的 SOTIF 要求比 L2 高一个量级，因为 L2 里即便出现误判，驾驶员通常还能兜住；L3 里系统发现不了误判，就只剩下碰撞和系统退出两个选项。这也是为什么自动驾驶仿真和场景库在近两年被提到前所未有的高度。
4. 座舱外的验证：CarSim、NI 和 VTD 联合仿真的真实分工
4.1 为什么验证不能只靠实车路测
按行业的公开说法，自动驾驶测试车辆如果想要证明比人类驾驶更安全，需要的测试里程是数十亿公里级别，单纯靠实车根本跑不完。所以仿真验证成为主流做法。自动驾驶仿真相关的检索里，CarSim、NI（VeriStand/TestStand）和 VTD（Virtual Test Drive）联合仿真被反复提起，这套组合覆盖了三个不同层面：CarSim 负责车辆动力学模型，VTD 负责虚拟场景和传感器仿真，NI 负责实时 I/O 和硬件在环。
我一般会把联仿环境理解成一个「时间同步的三角形」：每个仿真步长内，VTD 输出虚拟传感器数据给感知算法，感知结果输入决策规划，决策结果送到 CarSim 计算车辆动力学响应，最后由 NI 实时系统做传感器和执行器的物理信号转换。任何一环的时间不同步，都会让测试结果失真。
############################################################################## # 基于 bash 的联合仿真启动脚本（示意） # 用途：一次性拉起 VTD 场景服务、CarSim 车辆模型和 NI 实时接口 ############################################################################## VTD_ROOT=/opt/vtd CARSIM_DB=/data/carsim_projects # 场景文件：VTD XML 格式，包含道路拓扑、天气和交通流定义 SCENARIO_FILE="data/scenarios/cn_urban_rain_v3.xml" # 启动 VTD 内核，指定仿真步长和 RDB 通信端口 $VTD_ROOT/bin/vtdStart.sh \ --scenario "$SCENARIO_FILE" \ --step 0.005 \ --port 12000 & VTD_PID=$! sleep 20 # 等待 VTD 场景加载完成 # 启动 CarSim 到 Simulink 实时目标的 TCP 桥梁 python3 carsim_bridge.py \ --host 127.0.0.1 \ --port 12000 \ --vehicle sedan_cn \ --tire model_21这个脚本里几个参数需要注意。--step 0.005对应 200Hz 的仿真步长，对车辆动力学仿真是合理的，步长过大则 CarSim 的稳定性不足，过小则 CPU 负担重。--port 12000是 VTD 的 RDB 通信端口，CarSim 和 NI 都通过这个端口收发状态量。sedan_cn是车辆模型名称，这里通常会关联一个 CarSim 里标定好的中国本土车型参数。启动 VTD 后要等 20 秒，这个时间取决于场景文件的复杂度和机器配置，实际使用时应该用日志里的「Scenario loaded」关键字来判断是否就绪，而不是固定 sleep。
4.2 场景库构建：从自动驾驶数据集到 corner case
仿真场景和自动驾驶数据集在这个环节合流了。VTD 场景可以直接导入采集自真实路测的轨迹数据，把路采数据「回放」成仿真场景。一套合格的场景库至少应该覆盖天气和光照、道路结构、交通参与者行为和通信干扰这几个维度：
| 场景维度 | 代表场景 | 仿真关注点 |
|---|---|---|
| 天气光照 | 雨、雪、雾、逆光、夜间 | 摄像头和激光雷达的传感噪声模型 |
| 道路结构 | 隧道、弯道、匝道、施工改道 | 车道模型、地图匹配、GPS 遮挡 |
| 交通参与者 | 加塞、行人横穿、两轮车切入 | 预测模块响应、AEB/ESC 触发逻辑 |
| 通信干扰 | V2X 报文丢失、延迟、伪造 | 信息安全策略和降级机制 |
评价场景库质量时，我习惯看两个指标：场景覆盖率和场景应用频次。覆盖率衡量的是场景库对真实工况的完整度，通常需要和自然驾驶数据库做差异分析；应用频次则反映回归测试的稳定性。新版本算法上线前，至少要跑一遍全量场景，确保没有在修复一个 corner case 的同时引入另一个回归。
4.3 仿真的可信度边界与安全决策
仿真的价值再高，也要认清它的边界。传感器模型是仿真里最容易失真的部分——摄像头模型对雨后水花的模拟、激光雷达模型对低反射率物体的响应，都很难做到高保真。所以仿真通过只是必要条件，实车测试才能验证仿真模型本身是否可信。ROAD 测试和仿真测试的理想配比是按成本和风险倒推出来的，核心原则是：仿真兜住长尾和极端工况，实车验证仿真模型的可信度，两者形成闭环。
5. 本土化落地与信息安全：从规范认证到一条可落地的验签技巧
5.1 中国工况逼迫出的本土化适配
博世在访谈里反复强调中国驾驶行为和环境的特殊性，强调与本土合作方在高精度地图、人工智能层面做联合开发。这不是市场公关话术，而是技术层面的刚需。中国高速公路的加塞频率和两轮车混行程度，在欧美场景库里几乎找不到等价模型；城市快速路的隧道、立交复杂程度，对定位系统的挑战也比欧美典型道路高。做本土化适配时，我一般的做法是抓三个落点：把中国自然驾驶数据转成仿真场景、重新标定驾驶策略参数、对高精度地图的鲜度做特殊处理。
5.2 信息安全的核心是通信信任链
刘卫国提到网络信息安全是自动驾驶的重中之重。车和云端、车和车（V2X）之间的每一次通信，都有可能成为攻击面。我这里给一个具体的落地技巧：通信消息除了要做加密和完整性校验之外，一定要验时效。V2X 里最容易被忽视的攻击不是伪造消息，而是重放攻击——攻击者把当前红灯时段的 SPaT 消息录下来，等绿灯时再放出去，接收方如果只验签不验时效，就会采信错误信号。
下面是一个简化的验签流程示例，可以用来理解车端接收 V2X 消息时的时间窗口校验：
from cryptography.hazmat.primitives.asymmetric import ec from cryptography.hazmat.primitives import hashes from datetime import datetime, timezone import struct def verify_v2x_message(raw: bytes, public_key, max_age_ms: int = 500) -> bool: # 消息布局：header(1B) + timestamp(8B) + payload + signature(64B) ts_bytes = raw[1:9] timestamp_ms = struct.unpack(">Q", ts_bytes)[0] now_ms = int(datetime.now(timezone.utc).timestamp() * 1000) # 关键：先比时间窗口，再做密码学签名验证，可以节约算力 if abs(now_ms - timestamp_ms) > max_age_ms: return False # 消息过期，可能是重放攻击 payload = raw[1:-64] signature = raw[-64:] try: public_key.verify(signature, payload, ec.ECDSA(hashes.SHA384())) return True except Exception: return False这段代码里max_age_ms=500是接收方容忍的最大消息延迟，具体取值取决于应用场景：基础安全消息可以放宽到 1 秒，但信号灯相位消息必须更严。先比时间窗口再验签，是为了让高成本的非对称签名验证只发生在时间上没有明显嫌疑的消息上，减少计算负载。真正的量产方案还会叠加证书链验证和证书吊销列表的本地缓存更新。
把时间窗口校验作为信息安全的第一道关卡，是今年为数不多既简单又有效的落地做法。它不需要昂贵的硬件安全模块参与，在现有芯片平台上就能实现，却切中了 V2X 重放攻击的命门。从感知系统的长尾挑战、L3 的冗余架构，到这个字节级别的时间窗判断，自动驾驶这座山的每一处攀登，都落在这些具体而微的工程决策上。
本文还有配套的精品资源，点击获取
