当前位置:首页>自动驾驶>L3自动驾驶全架构硬核解析:感知·决策·执行·交互及冗余,三万字一次讲透

L3自动驾驶全架构硬核解析:感知·决策·执行·交互及冗余,三万字一次讲透

  • 2026-05-12 05:07:46
L3自动驾驶全架构硬核解析:感知·决策·执行·交互及冗余,三万字一次讲透

     这是一份让你用60分钟吃透L3级自动驾驶全系统技术架构的硬核报告。4大感知传感器原理与演进+3大定位导航技术方案+MooN(D)冗余安全架构与域控设计+4大线控执行系统(制动/转向/驱动/悬架)深度拆解+人机交互权责转移闭环+双路供电无缝切换机制,从物理原理到ISO 26262 ASIL-D功能安全,全景解析L3与传统L2的本质差异。

多年汽车行业自动驾驶产品经验,不定期分享资讯及技术解析,欢迎关注作者一起交流~

全文将近三万字,耗时一个多月整理。先给出文章知识图谱和目录,方便大家快速通览全文信息。

目录

 • 1 L3系统核心部件

◦ 1.1 感知系统

◦ 1.2 计算决策系统

◦ 1.3 执行系统

◦ 1.4 人机交互系统

• 2 L3系统核心数据流

◦ 2.1 数据流完整链路

◦ 2.2 数据采集与时间同步

◦ 2.3 感知融合算法原理

◦ 2.4 决策规划层次化

◦ 2.5 控制执行与反馈闭环

◦ 2.6 支撑系统:通信网络与OTA

• 3 感知传感器

◦ 3.1 摄像头系统

◦ 3.2 激光雷达

◦ 3.3 毫米波雷达

◦ 3.4 超声波雷达

• 4 定位与导航

◦ 4.1 GNSS/RTK定位

◦ 4.2 IMU惯性测量单元

◦ 4.3 高精地图

• 5 中央大脑(智驾域控制器))

◦ 5.1 L3架构对计算平台的本质要求

◦ 5.2 冗余安全架构:MooN(D)体系与L3域控设计体系与l3域控设计)

◦ 5.3 三个常见认知误区

◦ 5.4 趋势研判:L3架构下计算平台应当如何设计

• 6 制动系统(线控制动))

◦ 6.1 三大技术方案演进路径

◦ 6.2 EHB Two-Box方案(分体式))

◦ 6.3 EHB One-Box方案(集成式))

◦ 6.4 EMB方案(电子机械制动)——终极形态-终极形态)

◦ 6.5 三大方案综合对比

• 7 转向系统(线控转向))

◦ 7.1 线控转向技术路线总览

◦ 7.2 EPS电动助力转向系统

◦ 7.3 SBW线控转向系统

• 8 驱动系统(线控驱动油门))

◦ 8.1 系统概述与定位

◦ 8.2 技术方案对比

◦ 8.3 线控驱动与自动驾驶的协同

• 9 悬架系统(线控悬架))

◦ 9.1 悬架系统概述与分类

◦ 9.2 技术方案对比

• 10 人机交互系统

◦ 10.1 L3人机交互的本质挑战

◦ 10.2 接管请求(TOR)系统设系统设计)

◦ 10.3 DMS驾驶员监控系统

◦ 10.4 权责转移逻辑:从系统到驾驶员的无缝过渡

◦ 10.5 MRM最小风险策略

• 11 供电系统

◦ 11.1 L3对供电系统的本质要求

◦ 11.2 双路独立供电架构

◦ 11.3 电源切换原理

◦ 11.4 备份电源方案

◦ 11.5 L3供电系统的安全设计要点

◦ 11.6 未来趋势:从"被动冗余"到"主动自愈"

文章摘要

本文档系统性地阐述了L3级自动驾驶系统的完整技术架构,从感知层、决策层到执行层,深入剖析了各核心部件的技术原理与工程实现。

 核心内容覆盖:

        感知系统:摄像头(单目/双目/三目)、激光雷达(机械/半固态/全固态)、毫米波雷达(3D到4D成像)、超声波雷达,以及多传感器融合算法(BEV鸟瞰图融合)

定位导航:GNSS/RTK厘米级定位、IMU惯性导航、高精地图(含静态/动态/预测图层)

中央大脑:智驾域控制器的冗余安全架构(1oo2D/2oo2D)、MooN(D)体系、SoC+MCU异构设计

执行系统:线控制动(EHB/EMB)、线控转向(EPS/SBW)、线控驱动、线控悬架

人机交互:接管请求(TOR)系统、DMS驾驶员监控、MRM最小风险策略

供电系统:双路独立供电架构、电源无缝切换、超级电容备份

技术深度:文档从物理原理出发,结合功能安全标准(ISO 26262 ASIL-D),详细分析了L3架构与传统L2的本质差异——Fail-Operational冗余要求、通道异构性设计、端到端控制链路延迟要求等。

适用读者:汽车工程师、智能驾驶从业者、整车OEM/Tier1技术管理人员,以及对自动驾驶技术感兴趣的深度技术爱好者。文档兼顾入门科普与高级进阶,适合不同专业背景的读者按需阅读。

1L3系统核心部件

1.1感知系统

摄像头系统

l前向摄像头:负责车道线识别、交通标志识别、行人检测等

l侧视摄像头:覆盖车身两侧盲区,支持变道辅助

l后视摄像头:后方障碍物检测、泊车辅助

l环视摄像头:360°全景成像,支持自动泊车

 激光雷达

l前向主激光雷达:远距离三维环境建模,厘米级测距精度

l侧向补盲激光雷达:覆盖车身四周近距离盲区

l功能:构建三维点云,精确测距和空间建模,不受光照影响

 毫米波雷达

l前向长距雷达:远距离目标检测与测速

l角雷达:覆盖侧后方盲区

l功能:全天候工作,测速精准,穿透雨雾能力强

l4D成像雷达可提供高度信息,支持更精细的环境感知

 超声波传感器

l分布在车身四周,通常配置12个

l功能:近距离障碍物检测(0.1-5米),泊车辅助核心传感器

定位导航地图

lGNSS/RTK定位系统

Ø高精度定位模块,配合全球卫星定位系统

Ø典型精度:厘米级(开阔环境)

Ø提供车辆绝对位置坐标

lIMU惯性测量单元

Ø六轴传感器:三轴加速度计 + 三轴陀螺仪

Ø功能:短期航位推算,姿态角测量

Ø在卫星信号遮挡时(如隧道、城市峡谷)维持定位连续性

l高精地图

Ø预先采集的道路数据,包含车道线、坡度、曲率等厘米级精度信息

Ø为自动驾驶提供先验知识和环境语义理解基础

1.2计算决策系统

智驾域控制器

lSoC芯片:运行AI算法、感知融合、路径规划

lMCU芯片:实时控制、安全监控、制动转向指令下发

l内存:运行时数据存储

l存储:地图数据、算法模型存储

1.3执行系统

l线控制动

Ø电子制动助力替代传统真空助力

Ø建压速度快,支持主动制动

l线控转向

Ø电动助力转向,支持自动转向控制

Ø响应延迟低,控制精度高

l线控驱动

Ø电机扭矩精确控制

Ø支持加速、减速、能量回收

l线控悬架

Ø车身姿态主动调节

Ø舒适性与操控性兼顾

1.4人机交互系统

DMS驾驶员监控系统

舱内红外摄像头

功能:监测驾驶员视线、头部姿态、疲劳状态

人机交互界面

HUD抬头显示

方向盘握力传感器

显示屏

多模报警装置(语音、视觉、座椅震动)

2L3系统核心数据流

2.1 数据流完整链路

L3自动驾驶的数据流遵循"传感器采集 → 预处理对齐 → 感知融合 → 决策规划 → 控制执行 → 反馈闭环"的完整链路。

各环节时序要求(参考范围)

传感器采集:各传感器独立采样,帧率10-60Hz

预处理对齐:基于硬件PTP时钟同步,时间误差<5ms

感知融合:完成BEV建模与目标检测,端到端延迟<100ms

决策规划:变道决策<1.5s,刹车响应<100ms,轨迹规划周期50ms

控制执行:指令下发至执行器响应<20ms

 流程图解读:

L3数据流的核心特点是"多源输入、统一建模、分层决策、闭环优化"。各环节并非简单的线性串联,而是存在大量跨层交互——感知层持续向决策层更新环境信息,执行层实时反馈车辆状态,形成一个动态稳定的控制闭环。

这种架构设计确保了系统的实时性和鲁棒性:即使某一个传感器短暂失效,其他传感器的冗余数据仍可维持系统基本功能;即使某一帧感知出现偏差,后续帧的修正和控制层的反馈仍可将车辆拉回安全轨迹。

2.2 数据采集与时间同步

多传感器数据采集

各传感器通过不同接口传输数据:

l摄像头:通过GMSL/SerDes高速串行接口传输原始图像

l激光雷达:通过以太网传输点云数据

l毫米波雷达:通过CAN FD总线传输目标列表

lIMU/GNSS:通过串口或CAN总线传输定位数据

时间同步机制

不同传感器的采样帧率差异很大:

l激光雷达:10-20Hz(50-100ms/帧)

l摄像头:30-60Hz(16-33ms/帧)

l毫米波雷达:10Hz(100ms/帧)

lIMU:100-1000Hz(1-10ms/帧)

为解决"时空错位"问题,系统采用硬件PTP(精确时间协议)时钟同步,所有传感器共用同一时间基准,时间戳误差控制在毫秒级。基于时间戳,系统采用滑动窗口融合算法,将不同时刻采集的数据对齐到同一时间平面。

空间标定机制

不同传感器安装位置和视角不同,需要进行外参和内参标定:

l外参矩阵:描述传感器坐标系之间的变换关系

l内参矩阵:描述相机从3D空间到2D图像平面的投影关系

通过标定,多传感器数据可以映射到统一的车辆坐标系,为后续融合奠定基础。

2.3 感知融合算法原理

融合层级的本质区别

感知融合存在三种典型范式,其本质差异在于"何时合并信息":

前融合(原始数据级) 

l特征提取前 

l将多传感器原始数据直接输入统一神经网络 

l信息完整,无中间损失,但计算量巨大

特征级融合 

l特征提取后 

l各传感器独立提取特征,在特征空间融合 

l平衡性能与精度,当前主流方案

后融合(结果级融合) 

l检测完成后

l各传感器独立输出检测结果,投票合并

l计算高效,但丢失原始信息,难以处理矛盾结果 

BEV融合的核心创新

lBEV(Bird's-Eye View,鸟瞰图)融合是当前行业的主流方案,其核心创新在于:

l统一视角建模:将所有传感器数据映射到俯视平面,消除透视畸变

l空间对齐自然:不同传感器在BEV空间中的坐标变换关系简单明确

l端到端可学习:从原始数据到BEV特征的映射可通过神经网络端到端学习

l便于下游任务:BEV特征天然适用于轨迹规划、预测等下游决策任务

融合算法完整流程

步骤1:各传感器独立检测

├─摄像头 → 2D检测框 + 语义分割

├─激光雷达 → 3D点云分割 + 目标聚类

└─毫米波雷达 → 距离 + 速度 + 角度测量

步骤2:特征提取与关联

├─匈牙利算法匹配同一物理目标

└─贝叶斯滤波更新置信度

步骤3:多传感器深度融合

├─BEV空间映射

└─Transformer注意力对齐

步骤4:环境统一建模

├─动态障碍物:车辆、行人、骑行者

├─静态障碍物:路沿、锥桶、护栏

└─可行驶区域:Occupancy占用栅格

输出:统一环境表示(BEV特征图+ 结构化目标列表)

流程图解读:

BEV融合的精髓在于"升维思考,降维打击"——通过将不同视角的传感器数据统一到俯视平面,巧妙解决了多传感器空间对齐的难题。Transformer注意力机制的引入,让模型能够自动学习不同传感器在不同场景下的可信度权重,实现了"可信的传感器多说,可疑的传感器少说"的自适应融合。

2.4 决策规划层次化

行为预测模块

利用LSTM或Transformer模型预测周边车辆未来数秒的运动轨迹。典型输入包括:

l目标车辆的历史轨迹

l道路拓扑和车道线信息

l交通规则约束

l车辆间交互关系

路径规划模块

采用"全局-局部"两级规划架构:

全局路径规划(高精地图导航)

粗粒度路径

局部轨迹规划(避障+ 变道决策)

细粒度轨迹

MPC模型预测控制

优化

平滑曲线生成(时速、加速度、转向角)

关键技术:

lMPC模型预测控制:在多约束条件下求解最优控制序列

l三次样条插值:生成平滑、连续的运动轨迹

l动态避障算法:实时响应突发障碍物

2.5 控制执行与反馈闭环

域控制器到执行机构的控制链路

SoC输出期望轨迹

轨迹解析

安全MCU校验(异构冗余)

安全门限

映射为CAN总线信号

总线传输

发送至各执行器ECU

执行响应

├─转向系统:EPS电机转角控制

├─制动系统:液压/电机压力控制

├─ 悬架系统:气压/电磁控制

└─驱动系统:电机扭矩控制

反馈闭环机制

执行器状态反馈

采样

实际轨迹vs 规划轨迹偏差计算

偏差分析

滚动优化调整控制指令

校正

下一周期控制

闭环控制确保了实际车辆运动与规划轨迹的精确跟踪,是自动驾驶安全性和舒适性的关键保障。

2.6 支撑系统:通信网络与OTA

车载通信网络

L3系统采用"以太网为主干,CAN FD为分支"的混合网络架构:

l千兆/万兆以太网:传输激光雷达等大数据量传感器

lCAN FD/CAN XL:传输控制指令和状态信息,实时性高

lFlexRay:高可靠性实时总线

lSerDes高速串行:摄像头、毫米波雷达等传感器数据传输

OTA与数据闭环

OTA(空中下载)技术支持:

l算法模型远程更新

l功能安全补丁下发

l地图数据增量更新

l车辆参数远程标定

数据闭环则是"影子模式"的核心:用户驾驶过程中,后台持续运行自动驾驶算法但不实际控制车辆,系统将感知差异和corner case数据上传云端,用于模型迭代和地图更新。

3感知传感器

3.1 摄像头系统

3.1.1 系统概述与定位

摄像头是自动驾驶的"智慧之眼",是最接近人类视觉的感知传感器。其核心优势在于分辨率最高,能识别纹理、颜色、字体等细节,物体类型识别能力突出,成本相对较低,技术成熟度高。核心短板在于无源特性,暗光环境成像表现一般,受雨雾、逆光等恶劣天气影响大,单目方案缺乏深度信息。

在L3自动驾驶体系中,摄像头与激光雷达、毫米波雷达形成多传感器融合,提供360°全景感知。

3.1.2 技术方案分类

按安装位置分类

按技术路线分类

单目摄像头:单一镜头,通过深度学习算法估计距离。优势是成本低、结构简单、成熟度高;劣势是测距精度依赖算法,对标定要求高。

双目摄像头:双镜头模拟人眼立体视觉,直接计算深度。优势是测距精度高、无需标定;劣势是基线短导致远距离精度下降、算法复杂、成本高。

三目摄像头:长焦+中焦+广角组合,覆盖远近不同距离,形成立体感知网络。优势是覆盖范围全面;劣势是算法复杂度高。

3.1.3 核心硬件组成

1)光学镜头

核心功能是将视野内物体的光线聚焦投射到图像传感器感光面。材质经历了从全玻璃到玻塑混合的演进:

l全玻璃镜头:耐用性好、热稳定性高,但成本高

l全塑料镜头:重量轻、成本低、易批量生产,但透光率低、耐热性差

l玻塑混合:兼顾成本与性能,是当前主流方案

关键技术包括:

l非球面镜片:一枚实现多枚球面镜片效果,解决像差问题

l多层镀膜:减少鬼影、眩光

l红外滤光片:滤除可见光外波段,提升成像质量

 (2)图像传感器(CIS)

CMOS传感器是车载主流选择,相比CCD具有集成度高、成本低、功耗低的优势。

关键参数演进:

l分辨率:从百万像素级向千万像素级演进,高端方案已达12MP以上

l动态范围:≥120dB HDR,应对强光、逆光、进出隧道等极端光照

lLED闪烁抑制:消除交通信号灯频闪干扰

l低照度性能:最低0.001lux(月光级)

技术趋势:背照式(BSI)→堆叠式,进光量持续提升。

 (3)ISP(图像信号处理器)

ISP是摄像头的"大脑",直接决定最终成像质量。核心功能包括:

l去马赛克(Demosaicing)

l降噪处理

l自动曝光/聚焦/白平衡

l伽马校正

l几何失真校正

l图像锐化

技术趋势:去ISP化——ISP功能逐步集成至域控制器SoC,模组体积缩小40%,成本再降20%。

 (4)串行器(SerDes)

将ISP输出的并行信号转为串行信号,通过同轴电缆远距离高速传输至域控制器,解决了并行传输在高速时钟下的时序失配和信号线间干扰问题。

3.1.4 技术发展趋势

1)高像素化

演进路径:百万像素级(早期)→ 800万像素(当前主流)→ 1200万像素(高端下一代)。高像素优势在于识别距离大幅提升,能识别更远的交通标志和细微路况。

2)多光谱融合

传统可见光摄像头在恶劣天气下性能受限。解决方案是融合红外热成像:

l红外热成像:夜间对远距离行人识别准确率高

l近红外夜视:主动红外照射特定波段

l远红外夜视:被动热成像,探测热辐射

l多传感器融合:摄像头激光雷达融合

3)AI算力下沉

摄像头从单一传感单元向"光学-电子-计算"一体化模块演进。部分方案在摄像头模组中集成AI加速器,直接输出结构化信息,减轻域控制器计算负担。

4)去ISP化趋势

原理是SoC集成ISP+SerDes,摄像头模组只负责采集。优势是模组体积缩小40%,成本再降20%,简化硬件架构。

3.1.5 技术挑战与解决方案

夜间与低照度挑战

挑战:传统摄像头在暗光环境几乎失效。

解决方案:

l背照式CMOS(BSI):进光量提升40%以上

l多帧合成技术:多帧图像融合降噪

lAI降噪算法:深度学习去噪

l红外补光:近红外/远红外夜视技术

强光与逆光挑战

挑战:进出隧道、对面车灯强光导致成像模糊。

解决方案:

lHDR(高动态范围):≥120dB,同时保留明暗细节

lLED闪烁抑制(LFM):消除交通信号灯频闪

l自动曝光/白平衡:实时调整参数

恶劣天气挑战

挑战:雨雾、雪天成像质量下降。

解决方案:

l多光谱融合:可见光 + 红外热成像

l镜头清洁功能:主动雨刷/除雾

l算法补偿:深度学习图像增强

车规级可靠性

七大类性能要求:图像性能、电气性能、防尘防水(IP67/69K)、机械性能、环境耐候(-40℃\~105℃)、电磁兼容、耐久性能。

功能安全要求:ISO 26262 ASIL-B等级,失效概率<10⁻⁷/h。

3.2 激光雷达

3.2.1 技术定位与价值

在L3级自动驾驶感知体系中,激光雷达是唯一能够主动发射激光并精确测量三维空间距离的传感器。相比摄像头(被动光学感知)和毫米波雷达(分辨率较低),激光雷达的核心价值在于:

l高精度测距:厘米级距离测量精度,远优于摄像头+算法的推算精度

l高角度分辨率:0.05°\~0.1°的角分辨率,可清晰分辨远处小物体

l直接获取三维信息:无需依赖算法即可生成稠密点云图

l主动感知:不依赖环境光照,在夜间、暗光、逆光条件下性能稳定

l抗干扰能力强:部分技术可抵御其他激光雷达和太阳光干扰

对于L3级自动驾驶而言,激光雷达是实现"安全兜底"的关键冗余传感器,也是应对城区复杂场景(异形障碍物、恶劣天气)的核心感知硬件。

3.2.2 按扫描方式分类

半固态技术路线详解

(1)MEMS微振镜方案

原理:通过微机电系统(MEMS)驱动的微型振镜高速摆动,将激光束反射到不同方向,实现二维扫描。

技术特点:

l微振镜尺寸小,摆动角度范围适中

l发射端采用多通道激光器阵列,接收端采用高灵敏度探测器

l功耗低,体积小,可集成在前保险杠或车灯内

l核心挑战:微振镜的抗冲击性能和寿命需满足车规要求

(2)转镜式方案

原理:电机驱动多面转镜旋转,将激光束反射到不同方向,通常采用1\~3面转镜实现水平扫描,配合振镜或棱镜实现垂直扫描。

技术特点:

l结构相对简单,可靠性高(转镜寿命长)

l视场角设计灵活(水平120°,垂直25°\~30°)

l对电机转速和控制精度要求高

(3)棱镜旋转式

原理:通过两个不同角度的棱镜高速相对旋转,激光光束在空间中形成花瓣状扫描轨迹。

技术特点:

l非重复扫描模式:随时间推移点云密度持续增加

l成本极低,但扫描均匀性略差,帧率较低

l主要应用:非乘用车场景(无人配送、机器人、测绘)

全固态技术路线详解

(1)Flash面阵式激光雷达

原理:利用激光器阵列一次性发射面阵激光照亮整个视场,通过高灵敏度探测器阵列同步接收反射光,无需机械扫描。

技术特点

l无运动部件,可靠性最高,理论寿命极长

l帧率高,无运动畸变

l核心瓶颈:探测距离受限(受限于单次发射能量)

l视场角固定,需多颗拼接实现360°覆盖

l主要应用:短距补盲(0.5\~10米近距离感知),与前向主雷达互补

(2)OPA光学相控阵方案

原理:通过调节集成在芯片上的光学相控阵中每个天线单元的相位,实现激光束的电子扫描(类似相控阵雷达原理)。

技术特点:

l真正的"纯固态":无任何机械运动,理论可靠性最高

l扫描速度极快(微秒级),可实现"软件定义扫描"

l核心瓶颈:旁瓣干扰问题(光束能量分散到非目标方向)、光学材料工艺难度大、芯片良率低、成本居高不下

l成熟度:仍处于研发阶段,尚无量产车规产品

3.2.3 按测距原理分类

目前市面上量产产品基本都是脉冲ToF方案。

FMCW技术的战略价值

FMCW代表了激光雷达的下一代技术方向:

l直接获取每个点的径向速度(而非依赖算法推算)

l对阳光直射、其他激光雷达干扰免疫

l信噪比高,探测距离更远

l硅光子技术有望实现芯片级集成,大幅降低成本

l仅需少数几个点即可精准定位和识别远距离小物体(传统ToF需数十个点)

FMCW技术挑战

l超窄线宽激光器

l频率扫描线性度

l硅光集成

l视场角与分辨率矛盾

l平衡探测一致性

l信号处理计算压力

l系统级权衡

3.2.4 技术趋势展望

数字化与芯片化

全数字化架构(Digital LiDAR)正在成为趋势:

l传统架构:发射→接收→放大→滤波→ADC→处理,链路长、信号衰减大

l数字化架构:发射→直接数字化→片上处理,"光子进、点云出"

l优势:信噪比提升、延迟降低、系统简化、成本下降

芯片级集成:将激光器+探测器+信号处理SoC封装为单颗芯片,是激光雷达成本大幅下降的关键路径。

从"堆线数"到"重性能"

行业共识正在从单纯比拼线数转向关注实际性能:

l低矮障碍物识别距离

l雨雾环境有效探测距离

l点云延迟与决策响应时间

l复杂场景下的目标分类准确率

线数竞争已从"百线级"向"五百线级"乃至"千线级"演进,但真正重要的是有效性能提升而非单纯数字增长。

感知冗余架构

L3级自动驾驶对激光雷达的冗余要求体现在个维度:

l硬件冗余:单点失效不影响系统安全,双雷达、双链路、双电源

l感知冗余:激光雷达失效时可降级为纯视觉,激光雷达+摄像头双模感知

l算法冗余:点云算法与视觉算法交叉验证,BEV感知+Occupancy Network

l功能安全:达到ASIL-B或更高等级

3.3 毫米波雷达

3.3.1 技术定位与核心价值

毫米波雷达是工作在30~300GHz频段(波长1~10mm)的电磁波传感器,是自动驾驶感知系统中技术最成熟、成本最低的全天候传感器。与摄像头(光学)和激光雷达(光学)相比,毫米波雷达的核心优势在于穿透力强,不受雨、雪、雾、霾、强光等恶劣天气和光照条件的影响,始终能提供稳定的距离和速度信息。

毫米波雷达在L3级自动驾驶中的核心价值:

l全天候感知兜底:在摄像头和激光雷达性能衰减的极端天气下,毫米波雷达是最可靠的环境感知源

l速度信息直接获取:通过多普勒效应直接测量目标的径向速度,无需算法推算

l与其他传感器的互补冗余:与摄像头、激光雷达形成"黄金三角",实现感知冗余

l成本优势:4D成像雷达量产价格仅为激光雷达的若干分之一

3.3.2 技术演进:从3D到4D的跨越

毫米波雷达过去十年的演进,是从"只能测距的辅助传感器"向"具备成像能力的核心感知器件"蜕变的过程。

1)传统3D毫米波雷达

技术特征:

l基于调频连续波(FMCW)原理

l输出维度:距离、水平角、速度(3D)

l无高度信息,无法区分"天上"(龙门架、路牌)和"地下"(静止车辆)

核心痛点:

l误报频繁:无法区分井盖和停止的车辆,算法通过过滤"静止目标"减少误报,导致多起碰撞事故

l分辨率低:只能看到模糊的点,无法解析目标轮廓

l"幽灵刹车":将立交桥误判为障碍物,引发不必要的减速

2)MIMO+芯片化集成(过渡阶段)

技术突破:

l集成DSP和MCU的单芯片方案,极大缩小体积

lMIMO(多输入多输出)天线阵列提升虚拟通道数

l77\~79GHz频段全面取代24GHz,带宽增加带来更高距离分辨率

改进效果:

l角分辨率从5°提升至2°左右

l可区分"前方是两辆车还是一辆车"

l点云密度从数十个点提升至数百个点

3)4D成像雷达爆发期

革命性升级:增加俯仰角(高度)维度,实现"距离+速度+水平角+俯仰角"四维感知。

与传统3D雷达的核心差异:

解决的关键问题:

l精准区分"天上"和"地下":可清晰判断目标是高处的龙门架还是停在路面的车辆

l识别静止/异形障碍物:可检测侧翻三轮车、掉落纸箱、路面大坑等

l"鬼探头"预警:凭借高分辨率,对行人、宠物等小目标更早发现

l恶劣天气透视:大雨、大雪、大雾天气下成为绝对主力感知器

3.3.3 4D毫米波雷达技术方案

按硬件实现方案分类

按性能等级分类

关键硬件架构

(1)天线方案

l微带阵列天线:成本低、加工容易,但辐射效率较低

l波导腔体天线:辐射效率高、探测距离远,但对加工精度要求高

l空气波导天线(SIW缝隙):兼顾成本与性能

(2)MMIC芯片方案

l标准单芯片

l高性能级联芯片

l高集成SoC

(3)处理器方案

lFPGA:高性能4D成像雷达

l专用雷达SoC:前装量产雷达

l定制AI加速核:AI增强4D雷达

3.3.4 L3级自动驾驶对毫米波雷达的要求

核心要求

中央卫星架构

架构变革

l传统架构:雷达自带边缘处理单元,先本地处理再传域控制器

l卫星架构:雷达仅负责信号采集,原始数据通过千兆以太网传给中央计算单元

优势:

l雷达硬件轻量化,成本和功耗大幅下降

l更适配AI大模型与端到端算法融合

l统一算力调度,减少冗余

挑战:

l软硬件协同系统工程复杂

lTier1需交出核心代码("白盒"交付)

AI融合趋势前沿研发方向:

l基于深度学习的多径虚假点抑制:数据驱动方式区分真实目标与多径鬼影

l端到端雷达信号处理:从原始ADC数据直接通过神经网络输出目标信息

l雷达-视觉特征级融合:BEV+Transformer架构中,雷达点云早期与像素特征融合

3.4 超声波雷达

3.4.1 技术定位与价值

超声波雷达是自动驾驶感知层中成本最低、体积最小的传感器,主要负责0.1~5米近距离测距,是泊车场景的核心感知器件。在L3级自动驾驶中,它与激光雷达、毫米波雷达形成"远近互补"的感知链条——激光雷达覆盖5~200米的中远距离,超声波雷达则专注"最后几米"的精准防撞。

三大核心优势:

l成本极低:单颗成本低,全车布置12颗也毫无压力

l近距离精度高:0.2\~5米范围内测距精准,尤其适合泊车

l不受物体颜色影响:对透明玻璃、黑色塑料等视觉难识别的物体更可靠

致命短板:

l探测距离短(<8米)、角分辨率差

l声波速度慢(约340m/s),响应延迟大

l受雨雪、冰霜、软质材料影响较大

3.4.2 技术方案演进

1)第一代:独立探头方案

l独立探头+主控芯片架构

l配置8颗探头

l无编码,容易产生同频干扰

l探测距离2\~5米

l主要应用:倒车雷达

2)第二代:总线式编码方案(当前主流)

核心升级:

l编码发射:给不同探头发射不同编码(类似对讲机不同信道),解决多探头同频干扰

l总线式架构:方便协调不同传感器

l探测距离提升:从5米延伸至更远

l配置12颗探头

l主要应用:APA自动泊车

替代方案:UWB超宽带近场感知

UWB(超宽带)技术正在成为高端车型的替代方案,相比传统超声波具有显著优势:

3.4.3 与L3级自动驾驶的耦合关系

超声波雷达在L3级自动驾驶中扮演"最后防线"角色:

l泊车场景:超声波雷达是唯一能精准感知保险杠周围厘米级距离的传感器

l狭窄空间:对低矮路沿、细小立柱的识别是自动泊车的必要条件

l感知冗余:与激光雷达形成互补——激光雷达有近场盲区,超声波填补0\~5米精度

技术路线分化:

l高端车型:UWB方案(无孔设计+全域感知)

l主流L3车型:12颗第二代超声波雷达(性价比最优解)

l极致冗余:多传感器融合方案,不放弃任何一种感知能力

3.4.4 总结与展望

超声波雷达正处于"技术成熟期"——在L3级自动驾驶中仍不可替代(尤其对泊车场景),但技术天花板明显(声波物理极限),中长期将被UWB等新技术部分替代。市场呈现"高端UWB替代、主流方案升级"的双轨并行格局。

4定位与导航

4.1 GNSS/RTK定位

4.1.1 为什么自动驾驶需要厘米级定位

普通车载导航的定位精度约为米级——这个误差足以让车辆不知道自己究竟在哪个车道。对于L2级辅助驾驶而言,分米级(10-30cm)定位已可满足车道保持与变道规划的需求;但到了L3级及以上,系统需要在高速公路匝道汇入、复杂路口通行等场景下做出驾驶决策,厘米级(≤10cm)定位精度成为刚性门槛。"GNSS/RTK + IMU + 感知融合"已成为行业共识的技术路线。

4.1.2 GNSS定位原理与增强技术

GNSS基础定位

依赖接收多颗导航卫星发射的信号,通过三角定位原理计算接收机位置。原始GNSS定位精度通常在米级,受卫星钟差、电离层延迟、对流层延迟、多径效应等因素影响较大。

为提升精度,行业发展出多代增强技术:

(1)RTK(实时动态差分定位)

RTK是当前车规级高精度定位的核心技术。其原理是在已知坐标的基准站上安装GNSS接收机,实时计算卫星观测量误差,并通过数据链路将这些误差修正值播发给流动站(车辆)。流动站结合自身观测数据,可消除公共误差,实现厘米级实时定位。

l精度:水平±2cm + 1ppm(与基准站距离相关),高程±5cm

l收敛时间:传统RTK约数十秒,低轨增强后亚秒级

l覆盖范围:单基准站有效距离约15-20km

RTK的局限性在于依赖地面基准站网络和通信链路,在网络覆盖不足或通信中断时性能下降。

(2)PPP(精密单点定位)

PPP通过全球分布的参考站网络解算卫星轨道、钟差等误差产品,用户端无需差分数据即可获得分米至厘米级精度。优点是全球覆盖、不依赖地面基站,缺点是收敛时间较长。

(3)PPP-RTK(融合增强定位)

这是当前最先进的定位范式,将RTK的高精度与PPP的广域覆盖优势融合。PPP-RTK将基准站"观测值误差"分解为卫星轨道、卫星钟差、电离层延迟、对流层延迟等"状态量误差",通过状态域建模实现全域厘米级服务。

l收敛时间:开阔区域亚秒级固定,无网络区域分钟级收敛

l核心性能:全球全域动态定位精度稳定在厘米级以内

(4)多系统融合

当前车规级GNSS模组普遍支持多星座多频点,包括北斗、GPS、GLONASS、Galileo等。多系统融合通过信号冗余提升可用性,典型设备支持多个频点信号接收,冷启动和重捕获速度快。

4.1.3 卫惯融合:GNSS+IMU的紧耦合

单独依赖GNSS存在明显短板:城市峡谷、隧道、高架桥下等场景卫星信号容易遮挡或中断。惯性导航系统(IMU) 通过内置的陀螺仪和加速度计,依据航迹推算原理在GNSS失效时维持定位。但IMU存在固有的误差累积问题——定位精度会随时间漂移。因此,GNSS与IMU的融合成为必然选择。

融合架构演进三代:

卫惯融合的工程意义:

lGNSS有效时:GNSS提供绝对位置基准,IMU辅助提升更新频率和平滑度

lGNSS失效时:IMU依据之前的运动状态进行航迹推算(Dead Reckoning),短时间内维持定位连续性

l里程计辅助:在隧道等场景中,结合轮速计数据可将IMU漂移控制在行程距离的0.1%以内

4.1.4 未来演进方向

lPPP-RTK全面普及:融合星基增强与多频信号,实现全球无基站覆盖的厘米级定位,彻底摆脱对地面网络的依赖

l低轨+高轨通导遥一体化:低轨星座全面运营,收敛时间<10秒,定位固定率>99.99%

l大模型与RTK深度融合:时空大模型精准预测电离层、对流层误差,实现全场景零样本泛化

l通导一体化芯片:单芯片集成5G通信+GNSS定位+IMU融合+短报文

l车路云深度协同:5G+北斗+V2X协议标准化,构建全域感知网络

4.2 IMU惯性测量单元

4.2.1 IMU是什么:自动驾驶的惯性感知中枢

如果说GNSS是自动驾驶的"天上坐标",那么IMU就是它的"车内小脑"——不依赖外部信号,在卫星失锁时依然能感知车辆的每一个动作变化。GNSS与IMU,一外一内、一天一地,共同构成自动驾驶定位系统的"双螺旋"。

IMU(Inertial Measurement Unit,惯性测量单元)是自动驾驶定位系统的核心传感器,由三轴陀螺仪和三轴加速度计组成。陀螺仪感知角速度变化,加速度计感知线加速度变化,二者数据通过积分算法即可推算出载体的位置、速度和姿态。

IMU的核心价值在于自主性和实时性:

l不依赖外部信号:GNSS信号在隧道、城市峡谷、高架桥下容易中断,IMU完全自主,不受遮挡影响

l极高更新频率:通常100Hz起步,高端产品可达1KHz,远超GNSS的更新速率

l低延迟:数据更新延迟可控制在毫秒级,为控制系统的实时决策提供支撑

然而IMU也有与生俱来的短板——误差累积。陀螺仪和加速度计的测量值会随时间漂移,积分运算会不断放大这种微小误差,导致定位结果逐渐发散。因此,IMU必须与GNSS、视觉、激光雷达等外部传感器融合使用,由外部传感器周期性校准IMU的累积误差。

4.2.2 核心性能指标与误差机制

关键性能指标

(1)陀螺仪零偏不稳定性(Bias Instability)

这是衡量陀螺仪精度最核心的指标,表示陀螺仪零偏随时间的随机波动程度。数值越小,陀螺仪越精准,IMU的"惯性滑行"能力越强。

(2)角度随机游走(ARW,Angle Random Walk)

表示陀螺仪噪声水平。它决定了短时间内角度测量的不确定性,ARW越小,瞬时姿态估计越精确。

(3)阿伦方差(Allan Variance)

全面表征IMU噪声特性的标准方法,能区分出零偏不稳定性、角度随机游走、速率随机游走等不同类型的噪声源。

(4)量程与带宽

l陀螺仪量程:覆盖车辆可能出现的角速度范围

l加速度计量程:覆盖车辆可能出现的加速度范围

l带宽:IMU输出数据的频率上限,带宽越高越能捕捉快速运动变化

IMU的三大误差源

在融合算法的误差状态向量中,陀螺仪和加速度计的零偏估计是核心状态量。高质量IMU的零偏稳定性决定了融合滤波器能否长时间维持精确估计。

4.2.3 IMU分级体系与市场格局

IMU市场已形成清晰的分级体系,不同级别对应不同的应用场景和成本区间:

一个重要的趋势:战术级IMU正在"平民化"。传统战术级IMU依赖光纤陀螺(FOG)技术,价格高昂。随着MEMS工艺的成熟和算法补偿技术的进步,基于MEMS的战术级IMU价格已大幅下探,使得L3级自动驾驶的标配成为可能。

工业级与战术级的界限也正在模糊——部分厂商通过算法优化,将MEMS IMU性能推至战术级门槛。

4.2.4 双IMU冗余:L3时代的新标配

L3级自动驾驶对功能安全提出了更严苛的要求——单个传感器失效不能导致系统失效。在此背景下,双IMU甚至多IMU冗余正在成为L3车型的标配。

双IMU的价值体现在:

l故障隔离:一个IMU失效时,系统自动切换至另一个,确保定位不中断

l互相校准:两个IMU数据交叉验证,可在线检测异常,提升完好性

l覆盖不同安装位置:底盘、仪表盘下方等不同位置的IMU可感知不同维度的运动信息

4.2.6 未来演进方向

l战术级MEMS持续下探:MEMS工艺和算法补偿持续进步,战术级IMU价格将进一步下探,推动L2+车型标配

l功能安全成为标配:ISO 26262 ASIL-B/D认证将从高端车型向全价位段渗透,IMU的安全设计成为刚需

l双IMU/多IMU普及:L3级自动驾驶推动冗余设计,单车多IMU配置将成为行业标准

l通导一体集成:IMU与GNSS、通信芯片深度集成,单芯片实现定位+通信+感知

l具身智能场景爆发:具身智能的崛起将打开IMU的十倍级新市场,车规级IMU供应商降维竞争

4.3 高精地图

4.3.1 从导航地图到高精地图:精度与维度的跨越

传统车载导航地图的精度约为米级,仅包含路网拓扑和POI(兴趣点)信息,更新周期长。而高精地图的精度要求达到厘米级,要素覆盖从道路级精细至车道级,包含车道线、路面标记、交通标志、信号灯、坡度、曲率、护栏等数十类静态要素,并逐步叠加动态交通事件层和语义理解层。

十年演进路径:

高精地图渗透率已超过75%。从"数据提供者"到"先验知识库",高精地图的角色正在被AI重新定义。

4.3.2 高精地图的分层架构

一张完整的高精地图并非单一图层,而是由多层信息叠加构成:

(1)静态层(基础底图)

包含厘米级精度的道路几何信息:车道线、路面边界、道路中心线、道路曲率、坡度、高程、护栏、路灯等。这是高精地图的核心层,也是制作成本最高的层。

l绝对精度:通常要求相对精度10-20cm(车道与车道线之间的几何关系),绝对精度<1m

l采集方式:早期依赖专业测绘车(搭载激光雷达、高精度GNSS、IMU),单次采集成本极高

(2)语义层

在静态几何基础上赋予"meaning"——红绿灯对应哪个车道、哪个出口通往哪条路、限速是多少、道路通行方向如何。语义层是路径规划的重要输入。

(3)动态层

包含实时变化的交通信息:施工区域、交通事故、临时封路、拥堵情况、道路积水等。动态层需要持续更新,是众包更新的主要对象。

(4)实时图层(预测层)

融合实时感知数据与历史规律,对短期内交通流进行预测。如前方路口的车流汇入趋势、绿波车速建议等。这是大模型时代的产物。

4.3.3 高精地图的技术挑战

挑战一:采集与制作成本

专业测绘车的单台成本高达数百万元,全国路网覆盖的制作费用更是天文数字。传统模式下,一张高精地图的制作周期长达数月,无法满足城市道路频繁变化的现实。

挑战二:更新速度

城市道路变化极为频繁——施工围挡、车道路线调整、信号灯迁移,可能在数天内发生翻天覆地的变化。如果地图"不新鲜",自动驾驶反而会因错误信息做出危险决策。

挑战三:合规与资质

根据测绘法规,从事高精地图制作必须具备甲级测绘资质,且数据需通过国家地理信息安全审查。众包采集的数据在回传、存储、使用各环节均受严格限制。

挑战四:无图化冲击

端到端视觉方案可以在一定程度上弱化对高精地图的依赖。这对传统图商的市场空间形成了结构性挑战。

4.3.4 众包更新:从专业采集到万辆同绘

面对上述挑战,众包更新机制成为行业破局的关键。

核心原理: 通过量产车搭载的摄像头、激光雷达、GNSS等传感器,实时回传道路感知数据,在云端进行多车数据融合、变化检测和地图更新。

影子模式:用户在驾驶过程中,后台持续运行自动驾驶算法但不实际控制车辆,系统将感知差异数据上传云端,用于地图更新

REM(RoadExperience Management):同样采用众包思路,通过搭载芯片的车辆回传"道路指纹"数据

众包数据处理流程:

技术难点:多车数据质量参差不齐——不同车辆的传感器精度、行驶速度、环境光照条件各异,融合时需要解决姿态误差、时空对齐、质量校验等一系列问题。当前头部图商已通过AI自动标注将众包数据的处理效率大幅提升:AI标注平台日均处理道路要素超过500万条,自动化率超过85%。

众包激励机制: 有研究显示,采用激励机制的众包地图项目,更新速度比传统方式提高30%以上且精确度提升。

4.3.5 车路云一体化:高精地图的新舞台

当高精地图遇上"车路云一体化",其边界被显著拓展——从单一车载感知辅助工具,转变为动态信息融合平台。路侧基础设施(毫米波雷达、激光雷达、摄像头、RSU路侧单元)可实时感知交通流、信号灯状态、异常事件等信息,这些数据可以"反哺"高精地图的动态图层:

l路侧感知 → 动态图层:路侧设备识别的施工区域、临时障碍物,直接更新至地图动态层

l毫秒级下发:边缘计算节点可在毫秒级将变化信息推送至过往车辆

l局部区域高可信度:在智慧路口、示范路段,动态信息准确率可达95%以上

车路协同试点项目已覆盖多个重点城市,累计部署RSU数量可观。这直接推动高精地图从"静态底图"向"静态底图 + 动态图层 + 服务接口"三位一体的新型架构演进。

4.3.6 大模型与AI重塑地图角色

AI正在从三个维度重塑高精地图:

维度一:地图自愈能力

大模型具备从少量观测点"推理"全局的能力。当众包数据仅覆盖某路段的局部变化时,大模型可以预测性地推断附近路段是否也发生了相应变化,实现地图的"自愈"。

维度二:从"数据提供者"到"先验知识库"

世界模型进一步弱化了静态地图依赖,但对地图作为"先验知识库"与仿真训练数据的需求反而提升——大模型需要真实世界的地图数据来训练和验证。

维度三:预测性更新

通过学习历史交通流规律和施工计划,AI可预测道路变化趋势,提前生成地图变更预案,从"被动更新"升级为"预测性更新"。

4.3.7 "有图"与"无图"的融合之路

行业对"是否需要高精地图"的争论从未停止。但现实中,主流方案正在走向"有图+无图融合"的中间路线:

l高精地图作为安全冗余:在地图覆盖且鲜度足够的区域,系统可借助地图信息提前规划,提升通行效率和安全性

l感知系统兜底:在地图缺失或失效的区域,端到端视觉方案可维持基础智驾功能

l轻量化地图:地图要素从"全量"向"关键要素"精简——拓扑关系、语义信息优先级高于几何细节,降低地图依赖

4.3.8 未来展望

l轻量化地图成为主流:从"重几何精度"向"重拓扑、语义与鲜度"演进,地图形态随算法需求动态调整

l秒级实时自愈:大模型+众包融合,实现地图变化的秒级检测和自愈更新,自愈率>99%

l车路云一张图:"舱驾一体"推动导航地图与智驾地图的深度融合,共用统一数据底座,实现人驾-智驾无缝切换

l预测性更新:AI基于历史规律和交通流预测道路变化,从被动响应升级为主动预防

l合规生态完善:国家推动建立"测绘资质共享"或"授权众包"机制,众包数据权属和收益分配机制逐步清晰

l出海全球化:本土车企出海需借助国际图商的全球覆盖网络,本土图商则提供AI训练数据优势,形成"全球模型+本地数据包"的组合方案

5中央大脑(智驾域控制器)

5.1 L3架构对计算平台的本质要求

在深入讨论技术方案之前,必须先明确一个根本问题:L3级自动驾驶对计算平台的要求,与L2有本质区别,不只是"算力更高"那么简单。

L3与L2之间横亘着一道法律分界线:L2的责任主体是驾驶员,L3的责任主体是系统。这意味着当系统做出驾驶决策时,车企必须为这个决策的安全性背书——无论是在晴天的城市快速路,还是在施工绕行的路口,无论系统运行了10分钟还是10小时,一旦出事,车企都要担责。

这道法律分界线,直接决定了计算平台必须满足的三项硬性需求:

需求一:Fail-Operational冗余

这是L3与L2最核心的架构差异。L2系统的失效模式是Fail-Safe——主系统失效后,系统关闭,驾驶员接管。L3系统的失效模式必须是Fail-Operational——主系统失效后,安全系统必须保持继续运行,维持足够的控制能力,给驾驶员留出安全接管的时间窗口。

具体采用何种冗余架构来实现Fail-Operational,是IEC 61508功能安全标准中的MooN(N选M)体系——1oo1D、1oo2D、2oo2等不同架构的安全性和可用性存在本质差异。

需求二:功能安全认证

既然车企要为系统决策担责,就必须有可追溯的功能安全依据。目前全球通行的功能安全标准是ISO 26262,最高等级为ASIL-D。对于L3计算平台,SoC、MCU、电源、通信每一个关键环节都需要通过相应的功能安全认证。

同时需要诚实面对的事实是:ISO 26262最初是为传统嵌入式系统设计的,对AI推理的"黑箱"行为缺乏明确的认证路径。当感知模块通过神经网络做出"前方有行人"的判断时,如何证明这个判断的正确性边界?目前没有成熟的答案。ISO 26262的AI扩展修订版和相关标准有望在未来为这一问题提供认证路径,这是整个行业都在等待的监管突破。

需求三:实时确定性

L3允许驾驶员"脱眼",但不允许驾驶员"脱脑"——驾驶员在收到接管请求后,仍需在规定时间内接管。这意味着系统的控制链路必须足够快,为安全停车或驾驶员接管留出足够的反应时间。

关于延迟要求的具体数字,行业内没有统一标准,不同来源的数据差异较大。一般认为,L3系统的端到端控制链路(感知→决策→执行)应在100毫秒以内;执行层的控制指令周期应在10-20毫秒量级;底盘驱动和制动的响应时间应控制在10毫秒以内。这些数据仅供理解"为什么要快"的方向性参考,各家实际测试标准差异较大。

5.2 冗余安全架构:MooN(D)体系与L3域控设计

理解了L3的三项硬需求,计算平台的冗余架构设计逻辑就清晰了。L3域控的核心设计问题不是"要不要冗余",而是"采用何种冗余架构"——这正是IEC 61508功能安全标准中的MooN(N选M)体系要回答的问题。

MooN(D)记号体系解释

IEC 61508定义了一套标准化的冗余架构记号,用于精确描述系统的安全特性:

M=输出通道数:有多少个通道可以输出控制指令

oo=outof:从...中取...

N=总通道数:系统有多少个通道

D=诊断:是否包含独立的诊断通道

从上表对比分析可以看出,1oo2D是当前最合适的L3架构

1oo2D的三个关键维度

维度一:交叉关断权——1oo2D与2oo2D的根本区别

1oo2D的诊断通道可以关断对方通道。当通道A出现危险失效(输出错误但未完全崩溃),诊断通道可以强制关断A,让B继续运行。这是因为1oo2D的输出逻辑是"任一可输出",关断A不影响B的输出能力。

但是2oo2D只能自关断。当通道A出现危险失效,它可能"半死不活"地持续输出错误指令,而2oo2D没有机制强制关断A——因为A自己不知道自己坏了。即使诊断通道检测到A异常,关断A后系统只剩B一个通道,无法满足2oo2"双通道一致"的要求,系统必须停机。

这个区别决定了:1oo2D是Fail-Operational,2oo2D本质是Fail-Safe增强。在L3的高速场景下,系统故障后必须能够继续运行(如安全停车到应急车道),1oo2D的交叉关断权是必须的。

维度二:通道异构性——1oo2D架构的灵魂

1oo2D的两个通道如果是同构的(相同硬件+相同软件),则存在共因失效风险——同一批芯片的同一硅缺陷、同一软件的同一bug,可能同时击穿两个通道,导致1oo2D退化为1oo1。

通道异构性层级(从低到高):

1)硬件同构+软件同构(最低)

l机制:相同芯片+相同算法

l风险:共因失效风险最高,同一芯片bug或软件bug可同时击穿两个通道

l防护:主要依赖诊断通道检测,但诊断通道对系统性共因失效的检测能力有限

2)硬件同构+算法异构(中)

l机制:同一芯片,但运行不同的算法(如主控算法+影子验证算法)

l风险:中等,同一芯片的系统性故障仍可能同时影响两个通道

l防护:通过算法层面的差异,降低软件bug的共因失效概率

3) 硬件异构+软件异构(高)

l机制:物理层面阻断共因失效(不同芯片平台),软件层面深度异构

l风险:低,物理层面的差异性使共因失效概率极低

l防护:这是当前L3域控中通道异构性的较高水平

4)跨域物理异构(最高)

l机制:完全不同的物理原理,如电子制动与电机驱动提供执行层冗余

l风险:极低,共因失效概率几乎为零

l防护:这是终极异构,但更多用于执行层而非计算层

深度软件异构是通道异构性的高水平实现:

l一个通道跑L2++级成熟算法(保守但可靠)

l另一个通道跑更激进的冗余算法

l两套算法从训练数据到推理逻辑完全不同

l同一corner case几乎不可能同时击穿两套算法

随着L3从低速扩展到高速,共因失效的后果从"可容忍"变为"不可接受"。低速L3中,共因失效导致系统停机,驾驶员可以接管;高速L3中,共因失效可能导致危险事故。因此,通道异构性将从"可选项"变为"必选项"。

维度三:诊断独立性——决定可靠性上限

诊断通道如果和被诊断通道共享物理资源(同一SoC内的软隔离),则SoC的系统性故障可能同时影响诊断通道和被诊断通道,导致诊断失效。

当前L3认证方案均采用外置独立MCU,这不仅是技术选择,也是法规要求的"硬门槛"。深度软件异构+外置MCU是目前诊断独立性+通道异构性的组合最高水平。

5.3 三个常见认知误区

在讨论L3计算平台时,有三个误区值得专门澄清:

误区一:"宣称L3"等同于"具备L3功能安全架构"

两者之间存在巨大差距。"宣称L3"只需要一块PPT,"具备L3功能安全架构"需要ISO 26262 ASIL-D认证、MooN(D)冗余架构(1oo2D/2oo2等)、第三方验证报告和准入许可。少数头部方案已完成L3认证,其他厂商的"L3声称"目前还停留在企业自述层面,缺乏第三方背书。

误区二:算力冗余≠安全冗余

算力解决的是"能处理多复杂的场景",MooN(D)安全冗余解决的是"处理失败时怎么办"。几百TOPS的算力确实远超入门方案,但如果是1oo1架构,任一故障就是系统级失效,无法维持Fail-Operational运行——双芯片提供的是算力冗余(性能备份),不是MooN(D)意义上的安全冗余(诊断+交叉关断+异构通道)。高算力是L3的必要条件,但不是充分条件。

误区三:传感器数量多就等于满足L3要求

传感器多解决的是"看得更清楚"的问题,MooN(D)冗余架构解决的是"某个传感器失效时怎么办"的问题。传感器的感知能力(分辨率、探测距离)和系统的安全架构是两个完全不同的维度。用30个传感器实现感知层的异构冗余(视觉+激光+毫米波多重感知)很重要,但更重要的是有可靠的网络架构保障通信链路的可靠性——这才是L3架构的核心。

5.4 趋势研判:L3架构下计算平台应当如何设计

基于以上分析,可以对L3计算平台的演进趋势和设计方向做出以下判断:

趋势一:1oo2D是L3架构的"入场券",2oo2仅在低速简单场景勉强达标

无论采用何种硬件方案,1oo2D架构(双通道+独立诊断+交叉关断权)是L3域控的最低充分架构。没有这个,法规层面无法通过L3准入,技术层面也无法承担"系统为驾驶决策负法律责任"的要求。2oo2架构(双通道一致输出)仅在低速简单场景(如60km/h以下拥堵辅助)可满足L3最低门槛——系统故障后停机,驾驶员在低速下接管的安全风险可控。但高速L3要求系统在故障后继续运行(如安全停车到应急车道),2oo2无法满足这一要求,必须升级到1oo2D。

趋势二:通道异构性将从"可选项"变为"必选项"

随着L3从低速扩展到高速,共因失效的后果从"可容忍"变为"不可接受"。低速L3(如60km/h以下):共因失效导致系统停机,驾驶员可以接管,1oo2D的硬件同构+软件异构(主控+影子)足够高速L3(如120km/h):共因失效可能导致危险事故,1oo2D的通道异构性必须提升——硬件异构或深度软件异构将成为必须

趋势三:算力竞争进入"有效算力"时代

从"L2的几十TOPS"到"L3的数百TOPS",数字在快速攀升,但真正重要的不是TOPS数字本身,而是在复杂城区场景下维持实时性的有效算力。城区NOA意味着同时运行BEV感知、占用网络、轨迹预测、多目标跟踪、路径规划等多个模型,且帧率必须稳定在30fps以上(每帧<33ms)。各家厂商正在从"堆算力"转向"优化模型效率"——通过模型蒸馏、量化、剪枝,把大模型压缩到能实时运行的量级,同时保持精度。

趋势四:硬件可进化将成为高端平台的标配

"硬件可插拔"理念代表了一个重要方向:智驾芯片的迭代周期(2-3年)远快于整车生命周期(10-15年),一次性定死的算力无法应对未来的算法需求。通过标准化的高速接口(PCIe、以太网)和模块化的域控设计,主板可以在不换整车的前提下独立升级。这一趋势的底层支撑是中央+区域架构的E/E设计——只有当通信架构解耦于具体芯片,算力升级才不会牵一发动全身。

趋势五:端到端大模型将重塑计算平台需求

端到端大模型正在成为下一代智驾算法的主流架构。这种模型将感知、规划、决策整合为一个统一的神经网络,理论上比模块化的"规则堆砌"更容易通过功能安全认证(因为决策路径更短、更可追溯)。但端到端大模型对计算平台提出了新的挑战:

l内存带宽需求激增:大模型参数量远超传统感知模型,需要更大的内存带宽支撑

l新的芯片架构需求:新一代芯片都在为大模型优化原生支持

l实时性与大模型的矛盾:大模型推理时间远长于轻量级模型,如何在保持实时性的同时部署,是各家都在攻克的工程难题

l功能安全认证路径:相关标准预计还需数年才能为大模型提供明确的认证框架

趋势六:舱驾融合将加速,但安全隔离是前提

舱驾融合(智能座舱+智能驾驶合并到一颗SoC)是降本和提升体验的双重趋势。相关方案正在量产落地。但舱驾融合带来一个新的安全挑战:座舱域的娱乐应用(视频、游戏、第三方App)出现故障或被攻击时,不能影响智驾域的实时安全链路。这要求SoC内部在硬件层面实现严格的安全域隔离(类似手机AP和Modem的安全隔离),否则舱驾融合反而会成为L3安全架构的漏洞。高通的Ride Flex平台和英伟达的Thor平台都在强调硬件级的安全域隔离能力,但具体实现效果有待量产验证。

6制动系统(线控制动)

6.1 三大技术方案演进路径

线控制动技术经历了从机械到电子的三代演进:

机械制动真空助力器 → 传统液压制动液压 → EHB线控制动液压 → EMB全电控制动机械,电机直驱卡钳

技术路线演进的核心驱动力是:响应速度、控制精度、冗余能力、能量回收效率的持续提升。

6.2 EHB Two-Box方案(分体式)

6.2.1 系统架构

站在整车液压系统的角度,ESC和eBooster在车上共用一套液压系统,两者协调工作,原理如下:

eBooster和ESC共用一套制动油壶、制动主缸和制动管路。

eBooster内的助力电机产生驱动力推动主缸活塞运动,使油壶中的制动液流入主缸管路并进入ESC进液阀,经ESC中的调压阀和进液阀流入4个轮缸,从而建立起制动力。

当eBooster不工作时,ESC也可以独立控制制动液从主缸流入轮缸,从而建立制动力。

eBooster建压的动态响应速度比ESC主动建压更快,且NVH表现更好,因此eBooster是制动控制系统中的主执行机构。

6.2.2 核心组件

eBooster

eBooster最基础的功能是为驾驶员制动提供助力。其原理为利用传感器感知驾驶者踩下制动踏板的力度和速度,并将信号处理之后传给电控单元,电控单元控制助力电机对应的扭距,在机电放大机构的驱动下,推动制动泵工作,从而实现电控制动,响应速度更快并且能够精准的控制压力。

另外,eBooster属于非解偶踏板系统,和真空助力器一样,在制动过程中eBooster能够反馈最真实和自然的踏板感,驾驶员能直观的感受到制动系统的变化,例如ABS回馈力和刹车片的衰退等,驾驶员可以通过这些异常的变化及时发现制动系统的潜在问题并做出及时处理,从而减少安全隐患。 

ESC(电子稳定控制系统)

ESC最重要的功能就是为整车提供稳定性功能,稳定性功能主要集成了以下三个子功能:

l制动防抱死系统 (Anti-lock Brake System, ABS)

l牵引力控制系统(Traction Control System, TCS)

l辆动态控制系统 (Vehicle Dynamic Control, VDC)

6.2.3 技术特点

6.2.4 冗余机制

EHB Two-Box方案(分体式)的冗余机制,核心在于‌将电子助力功能与轮缸液压控制功能分离部署‌,通过‌双独立执行单元互为备份‌,实现高安全等级的制动冗余。以下是其关键冗余机制:

主要冗余方式

‌ESC作为主备份‌:在Two-Box方案中,电子助力器(如博世iBooster)负责主要建压,而ESC(车身电子稳定控制)模块独立存在,‌在助力器失效时可主动建压‌,提供行车制动力,确保制动功能不完全丧失‌‌。

‌机械备份保留‌:即使电子助力器和ESC均失效,系统仍可通过‌纯液压机械连接‌(踏板直接推动主缸)提供基础制动力,满足法规最低要求(通常可达0.5g以上减速度)‌‌。

‌独立供电与控制‌:电子助力器与ESC分别连接‌独立的电源和ECU‌,避免单点电源或控制失效导致整体制动失效,提升系统鲁棒性‌‌。

‌纵向稳定性冗余‌:部分方案(如博世“三级ABS”)在ESC中集成冗余轮速传感器和ABS控制逻辑,确保在助力器失效时仍能维持防抱死和车辆稳定性‌‌

6.3 EHB One-Box方案(集成式)

6.3.1 系统架构

6.3.2 核心组件

高度集成模块包含:

l电机驱动单元

l主缸及液压单元

l电磁阀体

l踏板模拟器

lECU控制器

6.3.3 技术特点

6.3.4 工作原理深度解析

EHB(电子液压制动)的本质是"电子信号替代机械连接,电机建压替代人力踩踏"。

从物理层理解EHB的工作原理:

1) 踏板信号采集层

l驾驶员踩踏制动踏板

l踏板行程传感器和踏板力传感器同步采集驾驶员意图

l信号数字化后发送至ECU

l踏板模拟器提供反馈力,模拟传统制动脚感

2) 电机建压层

lECU根据踏板信号计算目标制动压力

l驱动电机通过减速机构推动主缸活塞

l主缸活塞压缩制动液,建立系统压力

l压力传感器实时反馈实际压力,形成闭环控制

3) 液压分配层

l电磁阀组根据ECU指令控制各轮缸压力

l可实现独立四轮控制(ABS、TCS、ESC功能)

l支持制动能量回收与液压制动的平滑过渡

为什么需要液压中间层?

液压传递的本质优势:

l力放大:帕斯卡原理,小活塞推动大活塞实现力的放大

l响应快:液体几乎不可压缩,压力传递几乎瞬时

l成熟可靠:液压制动已有百年历史,技术积累深厚

EHB保留液压中间层的原因:

l技术延续性:基于成熟的液压制动架构,风险低

l法规兼容:满足现有制动法规要求

l成本可控:相比纯EMB,量产成本更低

 6.4 EMB方案(电子机械制动)——终极形态

6.4.1 核心原理:完全摒弃液压系统

什么是EMB?

EMB是Electro-Mechanical Brake(电子机械制动)的简称,是一种全电子化制动系统,通过电信号触发电机、传感器、控制单元等执行机构,将驾驶员的制动意图直接转化为机械制动力。对比目前中国乘用车市场上较为常见的EHB(Electronic Hydraulic Braking)电子液压制动系统,EMB在EHB的基础上,用电子机械替换掉传统制动系统中的制动主缸和液压管路等液压装置,制动时由电机直接推动制动片夹紧制动盘,从而产生制动力。

EMB(Electro-Mechanical Brake)的革命性在于彻底取消了液压系统:

l无制动主缸

l无液压管路

l无制动液

l电机直接驱动卡钳

这是线控制动的终极形态——从"电-液-机"三级传递进化为"电-机"直接驱动。

6.4.2 执行器结构(五大模块)

1.行车制动模块:电机 + 力放大机构 + 运动转换机构 + 压紧组件

2.驻车制动模块:驱动部件 + 运动部件 + 锁止部件

3.制动间隙补偿:自动调整摩擦片磨损

4.快速回位:紧急制动后快速释放

5.传感器:转矩/转速/位置传感器

技术方案对比

6.4.3 技术特点深度对比

为什么EMB是下一代?

从三代演进的本质来看:

1.传统液压制动:人力踩踏→真空助力→液压传递→制动。响应慢、不可控、无法能量回收。

2.EHB(电子液压制动):电子信号→电机建压→液压传递→制动。响应加快、可控、支持能量回收,但仍保留液压中间层。

3.EMB(电子机械制动):电子信号→电机直接驱动→制动。响应最快、精度最高、无液压损耗、能量回收效率最大化。

EMB解决了EHB的所有固有问题:

l液压管路泄漏风险 → 完全取消液压

l制动液定期更换 → 免维护

l液压系统的迟滞和非线性 → 纯电机控制,线性度极佳

l低温下液压油粘度变化 → 不受温度影响

6.4.4 应用挑战与解决方案

6.5 三大方案综合对比

6.5.1 性能对比表

6.5.2 适用场景

7转向系统(线控转向)

7.1 线控转向技术路线总览

技术演进路径

机械转向(MS) → 液压助力转向(HPS) → 电动助力转向(EPS)→ 冗余转向系统(RSS) → 线控转向(SBW)

每一代演进的核心驱动力:助力效率、控制精度、响应速度、与自动驾驶的融合深度。

三大技术体系

7.2 EPS电动助力转向系统

7.2.1 四种EPS方案架构

C-EPS(Column-EPS)转向管柱助力式

特点:结构最简单,成本最低,但助力能力有限,适用于小型车。

P-EPS(Pinion-EPS)小齿轮助力式

特点:助力能力中等,适用于中型车。

DP-EPS(Double Pinion-EPS)双小齿轮助力式

特点:双齿轮设计,助力能力强,适用于中大型车。

R-EPS(Rack-EPS)齿条助力式

特点:助力能力最强,NVH表现最好,适用于大型车/豪华车。

7.2.2 四种方案详细对比

7.2.3 EPS工作原理深度解析

助力控制算法的本质

EPS的核心控制逻辑可以理解为:助力力矩是驾驶员输入力矩、车速、方向盘转角的函数。

l高速:减小助力 → 提升稳定性(防止转向过度)

l低速:增大助力 → 提升灵活性(挪车、泊车更轻便)

完整控制流程

为什么需要蜗轮蜗杆?

从物理层理解:电机转速高但扭矩小,转向需要低速大扭矩。蜗轮蜗杆机构的作用是:

l减速:电机转速降低数十倍

l增扭:扭矩相应放大数十倍

l自锁:在特定角度下提供自锁能力,防止外力反向驱动

这是"小电机驱动大负载"的经典工程解决方案。

ADAS接管模式深度解析

关键设计考量:

l接管/退出的平滑性:不能有突兀的力矩跳变

l人机共驾的冲突仲裁:当系统与驾驶员意图冲突时,如何裁决

l权限分级:哪些场景系统有最高权限,哪些场景驾驶员优先

7.3 SBW线控转向系统

7.3.1 系统架构

革命性变化:方向盘与车轮之间没有任何物理连接,完全通过电信号传递转向意图。这是"软件定义汽车"在转向系统的终极体现。

7.3.2 核心技术特点

1)完全解耦

l方向盘与车轮0机械连接

l纯电信号传递指令

l实现"软件定义转向"——转向比、路感、助力特性全部可软件配置

2)可变转向传动比

传统EPS的转向比是固定的(如16:1,方向盘转16°,车轮转1°),而SBW可以动态调整:

l低速泊车:6:1(方向盘转6°,车轮转1°)→ 打满方向只需1圈

l高速巡航:18:1(方向盘转18°,车轮转1°)→ 转向更沉稳,防止误操作

l自动紧急转向:14:1-160°方向盘范围 → 快速避障

3)主动路感反馈——SBW的力反馈模拟原理

路感反馈电机精准模拟:

l轮胎抓地力反馈:通过电机力矩模拟路面附着力

l路面摩擦系数:湿滑路面反馈更"滑"的手感

l转向阻力:模拟机械转向的阻力感

l自定义转向手感:运动/舒适/节能模式,不同路感

SBW力反馈的物理原理:

方向盘端的路感电机不直接驱动车轮,而是根据:

l车轮端的转向阻力(通过执行电机电流推算)

l当前车速和驾驶模式

l预编程的路感特性曲线

实时计算并输出反馈力矩,让驾驶员获得与传统机械转向几乎一致但更优的操控手感。

4)性能指标对比

7.3.3 全冗余安全架构——L3+ ASIL-D要求

三重冗余架构

1. 控制器冗余

双路转向执行电机

- 主路:主电机驱动

 - 备路:备电机热备(<10ms切换) 

2. 传感器冗余

- 双路力矩传感器(路感验证)

- 双路转角传感器(差分校验) 

- 三模冗余传感器数据表决 

(3). 电源/通信冗余 

- 双电源供电

- 双通信总线(以太网+CAN)

冗余策略

(1)主系统故障:

l立即切换至备份系统

l保持至少50%转向助力

l覆盖90%以上日常场景

(2)极端情况(双系统失效):

l后轮转向辅助

l制动系统协同

l安全靠边停车

8驱动系统(线控驱动油门)

8.1 系统概述与定位

线控驱动系统(Drive By Wire,DBW),也称为线控油门或电子节气门,是智能网联汽车实现纵向控制的关键执行系统。与线控制动、线控转向共同构成线控底盘的三大核心执行单元。

核心功能:将驾驶员的加速意图或自动驾驶系统的动力请求转化为对发动机/电机输出扭矩的精确控制,实现车辆的纵向运动。

在L3自动驾驶体系中,线控驱动系统需要支持两种控制模式的无缝切换:

l人工接管:驾驶员通过油门踏板直接控制动力输出

l系统接管:自动驾驶域控制器通过电子接口发送扭矩/加速度指令

8.2 技术方案对比

8.2.1 传统燃油车:电子节气门(ETC)

电子节气门系统已经完全取代了传统的机械拉线油门,是线控驱动技术最早实现大规模量产的应用。

系统架构:

关键技术特征:

l踏板信号延迟:<5ms

l节气门响应时间:50-150ms

l节气门控制精度:±1°(角度)

l冗余设计:双通道踏板传感器 + CAN总线校验

l安全机制:制动优先(Brake Override)

安全设计要点:

l制动优先策略:当驾驶员同时踩下制动踏板和油门踏板时,无条件切断驱动力,防止"油门当刹车"的事故

l跛行回家模式:传感器故障时进入安全模式,限制发动机功率

l防意外加速:踏板传感器采用双通道冗余,两路信号偏差超过阈值时切断驱动

市场成熟度:极高(1990年代开始量产,当前新车渗透率>99%)

8.2.2 混合动力车型:电控油门 + 电机协同

混动车型的线控驱动需要协调发动机和电机两种动力源,工作模式更为复杂。

控制策略:

l纯电模式:切断发动机供油,电机独立驱动

l混动模式:根据SOC和功率需求,协调发动机和电机输出

l能量回收:减速时切换为发电机模式,回收动能

关键技术难点:

l发动机启停的扭矩冲击抑制

l发动机-电机切换的平顺性

l多种能量流的实时优化

8.2.3 纯电动汽车:电机扭矩控制

纯电动汽车的线控驱动系统取消了发动机和变速箱,结构大幅简化,控制精度和响应速度显著提升。

系统架构:

核心技术指标对比:

FOC矢量控制:纯电动汽车的电机控制采用磁场定向控制(Field Oriented Control),实现毫秒级扭矩响应,为自动驾驶的纵向控制提供了精准的执行基础。

8.2.4 分布式驱动:轮边电机与轮毂电机

随着L3及以上高阶自动驾驶的发展,分布式驱动成为重要技术方向。

方案对比:

扭矩矢量分配(Torque Vectoring):

四轮独立驱动的基础上,可实现对每个车轮的独立扭矩控制:

l弯道内侧车轮减小扭矩,外侧增大,提升过弯稳定性

l紧急避让时快速调整横摆力矩

l配合ESP/VCU实现车辆动力学协同控制 

技术挑战:

l电机同步控制的实时性要求

l电磁兼容(EMC)问题

l轮毂电机的散热和可靠性

l簧下质量增加对悬架系统的负面影响

8.3 线控驱动与自动驾驶的协同

8.3.1 标准化的控制接口

为支持L3自动驾驶的纵向控制,线控驱动系统需要提供标准化的软件接口:

CAN FD/FlexRay接口规范:

l接收目标加速度或目标扭矩指令

l上报实际输出扭矩、电机转速、系统状态

l支持10ms控制周期(向5ms演进)

l故障诊断和跛行回家模式

8.3.2 再生制动协调

电动汽车的制动需要协调机械制动和再生制动:

Blending控制策略:

l小减速度需求:完全使用再生制动,最大化能量回收

l中等减速度:再生制动 + 机械制动补充

l紧急制动/ABS触发:优先机械制动,限制再生制动比例

这种协调控制由VCU或制动系统统一管理,对驾驶员几乎透明。

9悬架系统(线控悬架)

9.1 悬架系统概述与分类

悬架系统是连接车身与车轮的关键结构,负责缓冲路面冲击、维持车身姿态稳定,直接影响车辆的舒适性、操控性和安全性。

在L3级自动驾驶中,悬架系统的角色正在从被动执行向主动感知+智能决策转变——通过与高精地图、V2X路侧单元、前视摄像头等感知系统联动,实现"预判式"调节,将路面不平带来的颠簸在发生前就予以抑制。

根据控制方式的不同,悬架系统可分为以下四代:

9.2 技术方案对比

9.2.1 空气悬架系统

原理:以空气弹簧替代传统金属弹簧,通过充放气调节弹簧刚度,配合可变阻尼减震器实现舒适性与运动性的兼顾。

核心组成:

l空气弹簧:由橡胶囊和内部气压支撑体构成,通过气泵和阀体控制气囊压力

lCDC减震器:连续可变阻尼控制,通过电磁阀调节油液通道开度,实现阻尼力的实时调节

l空气供给单元:包括静音空压机、冷凝器、干燥器和解耦罐,负责空气的压缩、冷却、干燥和稳定供给

lECU控制单元:接收车身高度传感器、加速度传感器信号,综合判断后发出控制指令

技术特点:

l刚度可调:高压软、低压硬,兼顾空载舒适与满载支撑

l车身高度可调:高速行驶降低车身(减小风阻、提升稳定性),低速/越野升高车身(提升通过性)

l响应速度:CDC阻尼调节可达1000次/秒,空气弹簧调节约需0.5\~2秒

l能耗:空压机工作时有明显噪音和振动,是系统的噪声和故障主要来源

关键技术演进:

l闭式空气供给单元:取代传统的开式空压机系统,减少气体泄漏和噪声,提升可靠性

l单腔→多腔空气弹簧:从单腔升级到双腔、三腔设计,进一步扩大刚度调节范围

9.2.2 CDC连续可变阻尼

CDC(Continuous Damping Control,连续阻尼控制)减震器是一种先进的减震技术,能够根据道路状况和驾驶风格实时调整减震力,提供更好的驾驶体验和车辆控制性能。

原理:通过电磁阀实时调节减震器内油液流动通道的截面积,实现阻尼力的连续变化。驾驶员或ECU可根据驾驶模式、路面状况、车速等参数选择舒适(Normal)、运动(Sport)或经济(Eco)等不同阻尼曲线。

技术特点:

l响应速度快(毫秒级),可抑制车身俯仰和侧倾

l无需改变悬架结构,改装或加装相对容易

l通常需要配合空气弹簧使用以实现最佳效果

9.2.3 磁流变减震器

原理:在减震器油液中悬浮有磁性微粒(铁磁颗粒),通过电磁线圈通电产生磁场,使液体在毫秒级时间内从牛顿流体转变为Bingham塑性体,从而实现阻尼力的剧变。

技术特点:

l响应速度极快(<10ms),远超传统CDC

l阻尼力变化范围大,可实现"软→硬"的瞬间切换

l能耗低:仅在状态切换时需要电流,稳定状态几乎不耗电

l缺点:磁流变液成本高,低温性能有所衰减

l典型应用:高性能豪华车型

9.2.4 全主动悬架系统——终极形态

终极形态:通过执行器直接推动车轮或车身,实现四轮独立、任意方向的力输出,是L3/L4级自动驾驶时代悬架系统的终极形态。

预判式主动悬架的工作原理:

这就是"预判式悬架"的核心——不是被动"应战",而是主动"预判"。

10人机交互系统

10.1 L3人机交互的本质挑战

从"辅助提示"到"责任转移"的范式跃迁,,L2到L3的人机交互范式差异,不是一个渐进式改进,而是一次根本性的范式转换。

L2人机交互逻辑:系统是"副驾驶",驾驶员是"主驾驶"。系统通过提示音、仪表盘图标等方式"建议"驾驶员注意,但任何时候责任都在驾驶员。驾驶员可以忽略系统提示(尽管这是不明智的),系统无法强制驾驶员做什么。

L3人机交互逻辑:系统是"主驾驶",驾驶员是"后援用户"(Fallback-Ready User)。系统必须确保驾驶员在需要时具备接管能力,否则系统不能继续运行。当系统发出接管请求时,驾驶员有法律义务响应——这个义务不是建议,而是强制。

这种责任转移带来的设计约束是革命性的:

"脱手脱眼不脱脑"的心理悖论

L3要求驾驶员在系统运行时可以"脱手脱眼",但必须保持"接管就绪"——这被业界形象地称为"脱手脱眼不脱脑"。然而,认知心理学研究表明,这是一个违背人类注意力分配规律的奢望。

注意力恢复时间成本:一项基于静态驾驶模拟器的研究测试了驾驶员在高度分心状态(玩互动游戏)后接管车辆的表现:

l90%的驾驶员在3-4秒后才第一次看向道路

l90%的驾驶员在6-7秒后手握方向盘、脚踩踏板

l90%的驾驶员在7-8秒后关闭自动驾驶系统

l12-15秒后才完成第一次后视镜扫视和速度表查看——这是理解当前交通情境的必要前提

这组数据揭示了一个关键问题:10秒的接管时间窗口,在认知层面并不充裕。当驾驶员正在专心处理非驾驶相关任务时,从"分心状态"恢复到"情境感知状态"可能需要比10秒更长的时间。

"模式混淆"风险:人类在执行自动化的任务时,会形成一种"自动化 complacency"(自动化自满)——即过度依赖系统自动化,导致警觉性下降。L3系统允许驾驶员进行非驾驶任务,但这种"许可"本身会降低驾驶员的认知准备度。当接管请求到来时,驾驶员可能处于"半投入"状态,既没有完全沉浸于非驾驶任务,也没有完全进入驾驶情境——这种中间状态是接管失败的高危因素。

10.2 接管请求(TOR)系统设计

10.2.1 TOR的核心设计原则

接管请求(Take-Over Request,TOR)是L3人机交互的核心功能——当系统检测到即将超出ODD(运行设计域)、发生系统故障或其他需要驾驶员接管的场景时,必须通过多模态界面向驾驶员发出明确、强制的接管请求。

TOR设计的三大原则:

l不可忽略性:驾驶员无论在做什么(看手机、看视频、聊天),都必须能感知到TOR

l明确性:TOR的含义必须清晰无误——"立即接管驾驶",不能有歧义

l渐进性:TOR强度应随时间递增,从温和提醒到强烈警告

10.2.2 多模态TOR策略

单一模态的TOR容易被忽略,L3系统必须采用多模态冗余提醒策略,从视觉、听觉、触觉三个维度同步发起:

视觉通道

lHUD闪烁红色警示

l仪表盘全屏接管提示

l中控屏弹出接管窗口

l车内氛围灯变为红色并闪烁

听觉通道

l渐进式报警音(从温和到尖锐)

l语音提示("请立即接管驾驶")

l音量自动增大(覆盖车内娱乐系统声音)

触觉通道

l方向盘震动(频率和强度递增)

l座椅震动(整个座椅或坐垫局部)

l安全带预紧(触觉+安全双重提示)

渐进式强度曲线设计:

10.2.3 TOR时机与场景判断

TOR不是"定时触发",而是需要根据实时场景动态判断:

提前量计算:

l高速公路施工路段:提前15-30秒发出TOR

l城市道路复杂路口:提前10-15秒发出TOR

l系统故障降级:立即发出TOR

场景分类策略:

l可预测场景(如即将驶出高速公路):提前告知驾驶员"还有30秒需要接管",给驾驶员充分的心理准备

l不可预测场景(如传感器突然失效):立即发出最强TOR,同时启动降级策略

l渐进式场景(如雨势增大超出感知能力):TOR强度随雨势增大而升级,给驾驶员渐进式的认知过渡

10.3 DMS驾驶员监控系统

10.3.1 DMS的核心地位转变

在L2时代,DMS(驾驶员监控系统)是"舒适性配置"——提醒驾驶员不要疲劳驾驶、不要分心看手机。在L3时代,DMS是安全核心组件,法规强制要求。

这种地位转变的本质原因:L3允许驾驶员"脱手脱眼",但系统必须有能力确认驾驶员"仍在环内(In-the-Loop)",能够在需要时接管。DMS就是这个"确认机制"。

10.3.2 DMS监控维度

L3级DMS需要监控的维度远多于L2:

视线追踪

l视线方向(是否看前方道路)

l视线停留时间

l扫视频率(反映警觉度)

面部状态

l闭眼时长(疲劳检测)

l打哈欠频率

l头部姿态(低头=看手机)

l面部朝向(是否面对驾驶方向)

生理状态(可选)

l心率(通过摄像头远程测量)

l呼吸频率

交互状态

l是否手握方向盘

l踏板操作状态

l对TOR的响应速度

10.3.3 DMS与TOR的闭环协同

DMS不是"为了监控而监控",而是要与TOR系统形成闭环,这种"监控-预判-干预"的闭环,是L3人机交互安全的核心保障机制。

10.4 权责转移逻辑:从系统到驾驶员的无缝过渡

10.4.1 三个关键时间节点

L3的权责转移不是"瞬间切换",而是一个包含三个关键时间节点的过程:

关键洞察:T1(物理接管)和T2(情境感知完成)之间存在显著的时间差——可能长达数秒。在这个过渡阶段,系统不能简单"甩手",必须维持监控能力,作为驾驶员的"安全备份"。

10.4.2 过渡阶段的安全保障机制

l过渡阶段(T1→T2)是事故高发期,必须设计多重安全保障:

l感知系统维持监控:即使驾驶员已物理接管,感知系统仍持续监控环境,必要时发出AEB/ESB干预

l渐进式控制权转移:系统控制权不是"瞬间交棒",而是随驾驶员情境感知度的提升逐步让渡

l双监控模式:系统和驾驶员同时监控环境,任一检测到危险都可触发制动

l接管质量评估:系统评估驾驶员的接管质量(转向是否平稳、刹车是否及时),如果评估为"接管质量差",则系统延长干预时间

10.4.3 人机共驾的权限仲裁

L3的本质是"人机共驾"——不是简单的"要么人开要么系统开",而是复杂的权限动态分配。

权限分级架构:

Level 0:驾驶员完全控制

系统只提供预警,不干预控制

Level 1:辅助干预

系统可提供转向/制动辅助,但驾驶员有最高override权限

Level 2:部分自动化

系统控制纵向+横向,驾驶员监控

驾驶员随时可override

Level3:有条件自动化(本章主题)

系统完全控制,驾驶员"后援待命"

TOR后驾驶员必须接管

过渡阶段双重监控

Level4:高度自动化

系统完全控制,无驾驶员也可MRM

驾驶员可选干预

Level5:完全自动化

系统全权负责,无需人类干预

仲裁原则:

l安全优先:当系统判断有碰撞风险时,系统有最高干预权限,可override驾驶员操作

l意图优先:当驾驶员明确表达接管意图(如用力转动方向盘),系统应立即让渡控制权

l渐进原则:权限转移是平滑过渡,而非跳变式切换

10.5 MRM最小风险策略

10.5.1 MRM的定义与触发条件

MRM(Minimum Risk Maneuver,最小风险策略)是L3系统的"最后一道安全阀"——当驾驶员未能在规定时间内响应TOR时,系统必须自动执行安全停车策略,将车辆从动态交通中移出,进入安全状态。

MRM触发条件:

lTOR发出后规定时间内(如10秒)驾驶员无响应

lDMS检测到驾驶员丧失驾驶能力(如睡着、突发疾病)

l系统发生严重故障,无法维持L3运行

l其他系统判断需要紧急进入安全状态的场景

10.5.2 MRM执行流程

一个完整的MRM流程包含以下步骤:

10.5.3 MRM的伦理与法规考量

MRM不是"纯技术问题",而是包含深刻的伦理和法规考量:

伦理挑战:

l紧急情况下,MRM是优先保护车内乘员还是车外行人?(经典的电车难题在L3时代变成工程问题)

l如果MRM执行过程中发生事故,责任如何划分?

法规挑战:

l不同国家/地区对MRM的执行标准有不同要求

l事故责任认定的法律框架尚不完善

l数据记录与取证的标准不统一

工程折中:

当前的工程实践采用"保守安全"原则:

lMRM的核心目标是"停止"而非"规避"——将车辆安全停下是最高优先级

l尽量避免激进的避让操作(可能引发次生事故)

l所有MRM操作都必须完整记录,用于事后追溯

11供电系统

11.1 L3对供电系统的本质要求

如果说线控底盘是自动驾驶的"四肢",计算平台是"大脑",那么供电系统就是"心血管系统"——没有稳定可靠的电力供应,所有高级功能都无从谈起。

L3对供电系统的要求,与传统汽车有本质区别:

l传统汽车:供电失效→发动机熄火→驾驶员手动操控靠边停车

lL3自动驾驶:供电失效→系统可能无法发出制动/转向指令→车辆失去控制,驾驶员可能未处于接管就绪状态

这就要求L3的供电系统必须实现:任一单点故障都不能导致系统失去关键控制能力。

11.2 双路独立供电架构

11.2.1 架构设计原则

L3级供电系统的核心设计原则是:物理隔离、独立运行、交叉备份。

典型的双路独立供电架构:

关键设计要点:

1)物理隔离:两个蓄电池的充电、配电、接地完全独立,避免共因失效(如某路短路不影响另一路)

2)关键负载双路供电:制动、转向、智驾域控制器等关键系统必须同时接入两路供电,任一路失效不影响运行

3)独立故障检测:每路供电有独立的电压、电流、温度监控,故障时不干扰另一路的诊断

4)分级供电策略:故障时优先保障安全相关系统供电,切断舒适性负载(如空调、娱乐系统)

11.2 电源切换原理

11.2.1 切换时序的物理本质

电源切换不是"简单的开关切换",而是一个包含检测、判断、执行、确认的完整时序过程。从物理层理解,这个过程需要解决三个核心问题:

1)如何快速准确地判断"真故障"而非"误报"?

2)如何实现无缝切换(输出电压不中断)?

3)如何避免切换过程中的浪涌电流损坏负载?

11.3.2 完整切换时序

11.3.3 无缝切换的关键技术

"先合后断"重叠供电

这个重叠期是"无缝"的关键——即使只有几十微秒的重叠,也足以避免电压跌落。但重叠时间不能太长,否则两个不同电压等级的电源直接互连会产生大环流。

无隙切换的硬件保障:理想二极管控制器

传统二极管ORing电路有0.7V的压降,损耗大。现代电源系统采用理想二极管控制器:

l驱动低导通电阻的MOSFET(mΩ级)替代二极管

l压降<50mV,损耗降低一个数量级

l内置快速切换逻辑,确保电源切换无间隙

11.4 备份电源方案

11.4.1 多层次备份体系

L3级供电冗余不是"双电池就够了",而是一个从"毫秒级储能"到"长时间备用"的多层次体系:

第一层:电容储能(μs-ms级)

lMLCC陶瓷电容+电解电容阵列

l作用:吸收切换瞬间的电压跌落,保证关键IC供电不中断

l典型容量:数千μF至数万μF

l响应时间:即时

第二层:超级电容(秒级)

l双电层电容器(EDLC)

l作用:电源完全失效时,支撑系统完成MRM最小风险策略

l典型容量:数十法拉

l支撑时间:10-30秒(足够车辆安全停车)

第三层:备用蓄电池(分钟级)

l独立12V铅酸/锂电池

l作用:主电源故障时,支撑系统运行至维修或用户干预

l典型容量:10-20Ah

l支撑时间:30分钟以上

第四层:高压转低压备用DC/DC(持续级)

l从动力电池取电,反向降压供给低压系统

l作用:低压主电源故障时,从高压母线取电维持

l典型功率:1-3kW

l支撑时间:等于动力电池剩余里程

层次化设计的核心理念:用最快的设备应对最快的故障,用最大容量的设备应对最长时间的需求。各层取长补短,形成完整的防护体系。

11.4.2 超级电容在MRM中的关键角色

为什么L3必须配备超级电容?因为主电源完全失效时,必须有足够能量完成一次完整的MRM最小风险策略。一次MRM需要的能量估算:

制动系统建压:~500J

转向系统动作:~200J

双闪+报警:~100J

控制系统运行:~200J

合计:~1000J

一个50F/16V的超级电容组可存储能量:

E = 0.5 × C × V² = 0.5 × 50 × 256 = 6400J

即使考虑转换效率(\~70%),仍有近4500J可用——足够完成4次完整的MRM。这就是超级电容的价值:在最极端的全车断电情况下,仍能确保"把车安全停下"这一最低目标。

11.5 L3供电系统的安全设计要点

11.5.1 ISO 26262功能安全要求

L3供电系统必须达到ASIL-D等级,关键安全设计包括:

1)端到端保护(E2E):电源输出与负载之间的通信加入E2E保护,确保指令不被篡改

2)时序监控:内置独立看门狗,监控CPU和电源管理芯片的运行状态

3)故障注入测试:设计阶段通过故障注入验证各种失效模式下的系统行为

4)诊断覆盖率:对关键电路的故障诊断覆盖率>99%

11.5.2 共因失效防护

供电系统的最大敌人不是"单点故障",而是"共因失效"——一个原因同时击垮多个冗余通道。

典型的共因失效场景与防护:

11.5.3 健康管理与预测维护

L3供电系统不是"装好就不管了",而是需要持续的健康监控:

1)电池SOH(State of Health)监控:持续监测蓄电池的内阻、容量、充放电效率,预测剩余寿命

2) 电容老化监测:监测超级电容和电解电容的ESR(等效串联电阻)变化,提前预警电容老化失效

3) 线束连接可靠性监控:监测接插件的接触电阻变化,预警松动或腐蚀

4)预测性维护:基于大数据分析,在故障发生前提醒用户更换老化部件,从"故障后维修"转向"故障前预防"

11.6 未来趋势:从"被动冗余"到"主动自愈"

当前L3供电系统的主流思路是"被动冗余"——准备好备份,故障时切换过去。下一代供电系统正在向"主动自愈"演进:

1)智能故障定位与隔离:系统不仅能检测故障,还能精准定位故障点(如"第3支路第2个保险丝短路"),并自动隔离故障支路

2)动态功率路径重组:根据实时健康状态,在毫秒级内重新规划供电路径,绕过故障点,恢复系统供电

3)AI辅助故障预测:基于机器学习的故障预测模型,提前数天预警潜在故障

4)自愈型电力电子器件:自带冗余和故障旁路功能的功率半导体,单个器件损坏后自动旁路,不影响系统运行

这种从"1+1备份"到"N-M容错"的架构演进,将使L3级自动驾驶的供电可靠性提升一个数量级。

最新文章

随机文章

基本 文件 流程 错误 SQL 调试
  1. 请求信息 : 2026-05-12 10:02:09 HTTP/2.0 GET : https://e.mffb.com.cn/a/504334.html
  2. 运行时间 : 0.094504s [ 吞吐率:10.58req/s ] 内存消耗:4,652.41kb 文件加载:140
  3. 缓存信息 : 0 reads,0 writes
  4. 会话信息 : SESSION_ID=d179b881f963e804279a1bd16a769107
  1. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/public/index.php ( 0.79 KB )
  2. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/autoload.php ( 0.17 KB )
  3. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/composer/autoload_real.php ( 2.49 KB )
  4. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/composer/platform_check.php ( 0.90 KB )
  5. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/composer/ClassLoader.php ( 14.03 KB )
  6. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/composer/autoload_static.php ( 4.90 KB )
  7. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-helper/src/helper.php ( 8.34 KB )
  8. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-validate/src/helper.php ( 2.19 KB )
  9. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/helper.php ( 1.47 KB )
  10. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/stubs/load_stubs.php ( 0.16 KB )
  11. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Exception.php ( 1.69 KB )
  12. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-container/src/Facade.php ( 2.71 KB )
  13. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/symfony/deprecation-contracts/function.php ( 0.99 KB )
  14. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/symfony/polyfill-mbstring/bootstrap.php ( 8.26 KB )
  15. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/symfony/polyfill-mbstring/bootstrap80.php ( 9.78 KB )
  16. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/symfony/var-dumper/Resources/functions/dump.php ( 1.49 KB )
  17. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-dumper/src/helper.php ( 0.18 KB )
  18. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/symfony/var-dumper/VarDumper.php ( 4.30 KB )
  19. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/App.php ( 15.30 KB )
  20. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-container/src/Container.php ( 15.76 KB )
  21. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/psr/container/src/ContainerInterface.php ( 1.02 KB )
  22. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/app/provider.php ( 0.19 KB )
  23. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Http.php ( 6.04 KB )
  24. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-helper/src/helper/Str.php ( 7.29 KB )
  25. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Env.php ( 4.68 KB )
  26. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/app/common.php ( 0.03 KB )
  27. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/helper.php ( 18.78 KB )
  28. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Config.php ( 5.54 KB )
  29. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/app.php ( 0.95 KB )
  30. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/cache.php ( 0.78 KB )
  31. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/console.php ( 0.23 KB )
  32. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/cookie.php ( 0.56 KB )
  33. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/database.php ( 2.48 KB )
  34. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/facade/Env.php ( 1.67 KB )
  35. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/filesystem.php ( 0.61 KB )
  36. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/lang.php ( 0.91 KB )
  37. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/log.php ( 1.35 KB )
  38. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/middleware.php ( 0.19 KB )
  39. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/route.php ( 1.89 KB )
  40. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/session.php ( 0.57 KB )
  41. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/trace.php ( 0.34 KB )
  42. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/config/view.php ( 0.82 KB )
  43. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/app/event.php ( 0.25 KB )
  44. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Event.php ( 7.67 KB )
  45. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/app/service.php ( 0.13 KB )
  46. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/app/AppService.php ( 0.26 KB )
  47. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Service.php ( 1.64 KB )
  48. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Lang.php ( 7.35 KB )
  49. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/lang/zh-cn.php ( 13.70 KB )
  50. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/initializer/Error.php ( 3.31 KB )
  51. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/initializer/RegisterService.php ( 1.33 KB )
  52. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/services.php ( 0.14 KB )
  53. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/service/PaginatorService.php ( 1.52 KB )
  54. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/service/ValidateService.php ( 0.99 KB )
  55. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/service/ModelService.php ( 2.04 KB )
  56. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-trace/src/Service.php ( 0.77 KB )
  57. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Middleware.php ( 6.72 KB )
  58. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/initializer/BootService.php ( 0.77 KB )
  59. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/Paginator.php ( 11.86 KB )
  60. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-validate/src/Validate.php ( 63.20 KB )
  61. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/Model.php ( 23.55 KB )
  62. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/model/concern/Attribute.php ( 21.05 KB )
  63. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/model/concern/AutoWriteData.php ( 4.21 KB )
  64. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/model/concern/Conversion.php ( 6.44 KB )
  65. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/model/concern/DbConnect.php ( 5.16 KB )
  66. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/model/concern/ModelEvent.php ( 2.33 KB )
  67. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/model/concern/RelationShip.php ( 28.29 KB )
  68. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-helper/src/contract/Arrayable.php ( 0.09 KB )
  69. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-helper/src/contract/Jsonable.php ( 0.13 KB )
  70. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/model/contract/Modelable.php ( 0.09 KB )
  71. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Db.php ( 2.88 KB )
  72. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/DbManager.php ( 8.52 KB )
  73. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Log.php ( 6.28 KB )
  74. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Manager.php ( 3.92 KB )
  75. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/psr/log/src/LoggerTrait.php ( 2.69 KB )
  76. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/psr/log/src/LoggerInterface.php ( 2.71 KB )
  77. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Cache.php ( 4.92 KB )
  78. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/psr/simple-cache/src/CacheInterface.php ( 4.71 KB )
  79. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-helper/src/helper/Arr.php ( 16.63 KB )
  80. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/cache/driver/File.php ( 7.84 KB )
  81. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/cache/Driver.php ( 9.03 KB )
  82. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/contract/CacheHandlerInterface.php ( 1.99 KB )
  83. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/app/Request.php ( 0.09 KB )
  84. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Request.php ( 55.78 KB )
  85. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/app/middleware.php ( 0.25 KB )
  86. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Pipeline.php ( 2.61 KB )
  87. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-trace/src/TraceDebug.php ( 3.40 KB )
  88. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/middleware/SessionInit.php ( 1.94 KB )
  89. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Session.php ( 1.80 KB )
  90. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/session/driver/File.php ( 6.27 KB )
  91. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/contract/SessionHandlerInterface.php ( 0.87 KB )
  92. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/session/Store.php ( 7.12 KB )
  93. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Route.php ( 23.73 KB )
  94. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/route/RuleName.php ( 5.75 KB )
  95. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/route/Domain.php ( 2.53 KB )
  96. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/route/RuleGroup.php ( 22.43 KB )
  97. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/route/Rule.php ( 26.95 KB )
  98. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/route/RuleItem.php ( 9.78 KB )
  99. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/route/app.php ( 1.72 KB )
  100. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/facade/Route.php ( 4.70 KB )
  101. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/route/dispatch/Controller.php ( 4.74 KB )
  102. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/route/Dispatch.php ( 10.44 KB )
  103. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/app/controller/Index.php ( 4.81 KB )
  104. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/app/BaseController.php ( 2.05 KB )
  105. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/facade/Db.php ( 0.93 KB )
  106. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/connector/Mysql.php ( 5.44 KB )
  107. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/PDOConnection.php ( 52.47 KB )
  108. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/Connection.php ( 8.39 KB )
  109. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/ConnectionInterface.php ( 4.57 KB )
  110. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/builder/Mysql.php ( 16.58 KB )
  111. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/Builder.php ( 24.06 KB )
  112. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/BaseBuilder.php ( 27.50 KB )
  113. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/Query.php ( 15.71 KB )
  114. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/BaseQuery.php ( 45.13 KB )
  115. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/TimeFieldQuery.php ( 7.43 KB )
  116. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/AggregateQuery.php ( 3.26 KB )
  117. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/ModelRelationQuery.php ( 20.07 KB )
  118. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/ParamsBind.php ( 3.66 KB )
  119. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/ResultOperation.php ( 7.01 KB )
  120. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/WhereQuery.php ( 19.37 KB )
  121. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/JoinAndViewQuery.php ( 7.11 KB )
  122. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/TableFieldInfo.php ( 2.63 KB )
  123. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/Transaction.php ( 2.77 KB )
  124. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/log/driver/File.php ( 5.96 KB )
  125. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/contract/LogHandlerInterface.php ( 0.86 KB )
  126. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/log/Channel.php ( 3.89 KB )
  127. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/event/LogRecord.php ( 1.02 KB )
  128. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-helper/src/Collection.php ( 16.47 KB )
  129. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/facade/View.php ( 1.70 KB )
  130. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/View.php ( 4.39 KB )
  131. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Response.php ( 8.81 KB )
  132. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/response/View.php ( 3.29 KB )
  133. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/Cookie.php ( 6.06 KB )
  134. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-view/src/Think.php ( 8.38 KB )
  135. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/framework/src/think/contract/TemplateHandlerInterface.php ( 1.60 KB )
  136. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-template/src/Template.php ( 46.61 KB )
  137. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-template/src/template/driver/File.php ( 2.41 KB )
  138. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-template/src/template/contract/DriverInterface.php ( 0.86 KB )
  139. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/runtime/temp/600e51726691ba7063b44bb89d9aaaff.php ( 11.98 KB )
  140. /yingpanguazai/ssd/ssd1/www/e.mffb.com.cn/vendor/topthink/think-trace/src/Html.php ( 4.42 KB )
  1. CONNECT:[ UseTime:0.000549s ] mysql:host=127.0.0.1;port=3306;dbname=e_mffb;charset=utf8mb4
  2. SHOW FULL COLUMNS FROM `fenlei` [ RunTime:0.000634s ]
  3. SELECT * FROM `fenlei` WHERE `fid` = 0 [ RunTime:0.000254s ]
  4. SELECT * FROM `fenlei` WHERE `fid` = 63 [ RunTime:0.000282s ]
  5. SHOW FULL COLUMNS FROM `set` [ RunTime:0.000462s ]
  6. SELECT * FROM `set` [ RunTime:0.000205s ]
  7. SHOW FULL COLUMNS FROM `article` [ RunTime:0.000514s ]
  8. SELECT * FROM `article` WHERE `id` = 504334 LIMIT 1 [ RunTime:0.000638s ]
  9. UPDATE `article` SET `lasttime` = 1778551329 WHERE `id` = 504334 [ RunTime:0.001825s ]
  10. SELECT * FROM `fenlei` WHERE `id` = 67 LIMIT 1 [ RunTime:0.000232s ]
  11. SELECT * FROM `article` WHERE `id` < 504334 ORDER BY `id` DESC LIMIT 1 [ RunTime:0.000423s ]
  12. SELECT * FROM `article` WHERE `id` > 504334 ORDER BY `id` ASC LIMIT 1 [ RunTime:0.012882s ]
  13. SELECT * FROM `article` WHERE `id` < 504334 ORDER BY `id` DESC LIMIT 10 [ RunTime:0.005501s ]
  14. SELECT * FROM `article` WHERE `id` < 504334 ORDER BY `id` DESC LIMIT 10,10 [ RunTime:0.000704s ]
  15. SELECT * FROM `article` WHERE `id` < 504334 ORDER BY `id` DESC LIMIT 20,10 [ RunTime:0.000819s ]
0.096331s