简介这份资源是2022年智能驾驶行业梳理系列的第一部分PPT面向关注汽车智能化产业链的投资者、行业研究人员及汽车电子从业者帮助快速建立从产业架构到Tier 1厂商格局的整体认知。压缩包内共1个pptx文件约6.79MB以图文页形式呈现行业逻辑与分析框架。内容围绕智能化的基础设施、基础零部件、芯片、软件四大项展开先以手机发展史类比智能驾驶的循序渐进路径分析新能源汽车放量、新势力崛起与差异化竞争带来的加速因素随后对比汽车零部件与消费电子的市场空间及渗透节奏梳理感知层、决策层、执行层的供应链层次并重点介绍德赛西威、华阳集团、均胜电子、华域汽车等Tier 1厂商的业务布局包括域控制器、车载娱乐系统、液晶仪表、抬头显示及智能座舱等方向。目前已有104人学习适合用于产业链梳理、公司研究与入门科普参考。1. 智能驾驶行业梳理为什么要从「配置表」往下钻2022 年做智能驾驶行业梳理最容易得到一份漂亮但没法验证的 PPT满页写着「搭载 X 颗激光雷达、算力 Y TOPS、支持 L2 高速领航」看完仍然不知道这套方案在什么场景下会失效、成本卡在哪一环、软件栈缺哪块。真正有复现价值的智能驾驶梳理方式是沿着「传感器配置 → 原始数据 → 域控制器算力 → 功能安全等级 → 数据闭环规模」这条链路把每个数字落到可计算、可测量、可对账的技术量上而不是停在厂商发布会的话术层。这份梳理适合两类人一类是要判断某套方案能不能落地、值不值得集成的技术选型者另一类是接手了别人的行业调研、需要把结论重新验算一遍的工程师。下面按技术栈分层、关键数字口径、公开数据处理、长期维护四条线推进最后落在能持续复用的梳理方法上。2. 把智能驾驶技术栈拆成感知、决策、执行与数据闭环四层2.1 四层划分的边界以及 2022 年前后的代表性形态感知层负责把物理世界变成结构化输入。2022 年前后前视摄像头上到 800 万像素毫米波雷达主流是 3 发 4 收的 77GHz 方案激光雷达正从机械旋转式转向半固态转镜和 MEMS超声波雷达仍然只负责近距泊车。融合方式上前融合原始数据级在论文和演示里被反复讨论量产落地仍以后融合目标级为主少量方案做到了特征级。决策规划层是模块化流水线感知 → 定位 → 预测 → 规划 → 控制每一段都有独立接口和独立失效模式。端到端方案在 2022 年基本停留在研究阶段行业梳理时把它单列一行即可不要和量产方案混在同一张表里比较。执行层决定功能上限。线控转向、线控制动One-Box 形态开始替代传统真空助力器、线控驱动三件套齐了才有条件谈横向和纵向的连续控制。冗余设计体现在双电源、双通信通道、双绕组电机上梳理时要把「有没有冗余」和「冗余到什么级别」分开记录。数据闭环层是最近几年才被单独拎出来的。影子模式让量产车在后台跑模型但不控车把「模型输出与人类驾驶不一致」的片段回传用于长尾场景挖掘。这一层的成本结构和其他三层完全不同属于运营支出而非物料支出混在一起算会导致整份梳理失真。2.2 用 YAML 把一套智能驾驶方案结构化落地行业梳理最怕字段随手写今天记「算力」明天记「AI 算力」季度一对比就对不上。常见做法是先定一份最小字段集用 YAML 描述、用脚本校验。# adas_stack_2022.yaml 方案名: demo_l2plus 时间切片: 2022 感知: 前视摄像头: 分辨率_万像素: 800 视场角_度: 120 毫米波雷达: 数量: 5 最远探测距离_m: 210 激光雷达: 数量: 1 线束: 128 域控制器: 算力_TOPS: 128 算力口径: INT8-dense # 必须显式声明否则不同厂商数字不可比 安全等级: ASIL-D 功能: - 高速领航 - 自动泊车 数据闭环: 影子模式车队规模: 100000 日均回传片段数: 5000字段不多但每个都对应一个可以追问的问题算力口径是稠密还是稀疏、雷达最远距离是在什么反射截面积下测的、安全等级是整个域控的还是单个功能的。校验脚本负责把这些硬约束卡住。import yaml with open(adas_stack_2022.yaml, encodingutf-8) as f: stack yaml.safe_load(f) REQUIRED [感知, 域控制器, 功能, 数据闭环] def validate(stack: dict) - bool: missing [k for k in REQUIRED if k not in stack] if missing: raise ValueError(f缺少必要字段: {missing}) # 算力口径缺失时直接拒绝避免后续把不同标称方式的数字放进同一张图 if 算力口径 not in stack[域控制器]: raise ValueError(域控制器必须声明算力口径) sensors stack[感知] lidar sensors.get(激光雷达, {}).get(数量, 0) if lidar 0 and 前视摄像头 not in sensors: raise ValueError(带激光雷达的方案必须登记前视摄像头配置) return True validate(stack) print(stack[域控制器][算力_TOPS], stack[域控制器][算力口径])REQUIRED是硬性四层缺任何一层说明这份方案描述不完整算力口径检查是整份梳理里性价比最高的一条规则它拦掉的大部分是「把稀疏算力当稠密算力写进对比表」这类错误。扩展到多方案时把validate循环套在文件列表上输出一份带错误行的报告比人工翻表快得多。2.3 传感器配置横向对比与选型理由把配置表拆成对比表之后很多看似矛盾的选择就说得通了。传感器2022 年前后典型参数优势短板主要用途前视摄像头800 万像素约 120° FOV分辨率高能读车道线和交通标志受逆光、雨雾影响大缺深度车道保持、AEB、标志识别环视摄像头200 万像素约 190° FOV覆盖近距盲区畸变校正开销大泊车、低速避障毫米波雷达77GHz3 发 4 收最远约 210m测距测速准全天候角分辨率低静止目标难分类自适应巡航、盲区监测半固态激光雷达905nm128 线10% 反射率下约 150m三维点云密度高成本高雨雪场景衰减城市领航、高精建图超声波雷达探测距离约 5m成本极低距离太短易受干扰泊车测距选型上的分歧几乎都来自三个约束成本、算力、冗余要求。纯视觉路线把成本压到最低代价是对算力和数据规模的要求陡增加激光雷达是用物料成本换感知确定性但同时推高域控的输入带宽要求。梳理时把「成本量级」「带宽需求」「失效场景」三列补齐比只记参数有用得多。提示传感器参数一定要连带记录测试条件尤其是激光雷达的探测距离不同反射率下的数字能差一倍脱离条件的对比没有意义。3. 算力、域控制器与功能安全智能驾驶梳理中最容易讲糊的三组数字3.1 TOPS 的口径差异以及等效算力的估算方式「TOPS」是行业梳理里被滥用最严重的单位。同样的芯片标 INT8 还是 FP16、按稀疏还是稠密、按峰值还是有效数字能差出一个数量级。补一条基础换算一次乘加算两次运算所以TOPS ≈ 2 × MAC 数 × 频率 ÷ 10^12。厂商标稀疏算力时等效到稠密通常要打个折扣具体折扣取决于结构化稀疏比例不能简单除二。真正影响功能的是有效算力。峰值算力和有效算力之间隔着算子调度、内存带宽、功耗墙三道坎经验上有效利用率落在 30% 到 60% 之间。做行业梳理时把「峰值算力」和「有效算力区间」分成两列记录比只写一个数字更抗追问。3.2 从分布式 ECU 到中央计算三种域控架构的取舍架构形态典型组成通信方式优势代价2022 年前后落地情况分布式 ECU每个功能一个控制器CAN / LIN开发解耦供应商成熟线束重跨域协同难仍是存量主力域集中智驾域 座舱域 车身域车载以太网 CAN减少控制器数量域内算力共享域间通信成为新瓶颈新车型主流选择中央计算 区域控制中央计算单元 区域网关千兆以太网算力集中软件可 OTA 升级单点失效风险高需冗余高端车型开始导入梳理架构时最好补一行「跨域通信时延」很多方案宣传的算力优势在实际布线条件下会被通信时延吃掉。3.3 ASIL 等级与 SOTIF 在梳理表中的位置功能安全等级由三个维度共同决定严重度 S0-3、暴露率 E0-4、可控性 C0-3。三维度组合后落到 ASIL A 到 D其中 ASIL D 对应最严苛的组合通常出现在转向、制动这类直接控制车辆运动的链路上。做梳理时把「功能」和「ASIL 等级」一一对应而不是给整个域控贴一个等级标签否则一追问就露怯。SOTIF 处理的是另一类问题系统没有任何故障但性能不足以覆盖某个场景比如逆光下的视觉误检。这部分在行业梳理里经常被漏掉实际却是城市领航功能能不能交付的关键。表里加一列「已知性能边界场景」比堆砌安全认证清单有价值得多。3.4 用 Python 粗估感知模型的算力需求def conv_flops(kernel: int, cin: int, cout: int, hout: int, wout: int) - float: 单层卷积的运算量乘加各计一次运算 macs kernel * kernel * cin * cout * hout * wout return 2 * macs # 主干网络中的一个 3x3 卷积输入 64 通道输出 128 通道输出特征图 56x56 layer conv_flops(3, 64, 128, 56, 56) print(f单层 {layer / 1e9:.3f} GFLOPs) NET_FLOPs 20e9 # 整网约 20 GFLOPs 的检测网络INT8 FPS 30 # 目标帧率 UTIL 0.4 # 有效利用率经验值落在 0.3~0.6 区间 tops NET_FLOPs * FPS / UTIL / 1e12 print(f反推所需 INT8 有效算力约 {tops:.2f} TOPS)kernel、cin、cout、hout、wout直接从网络结构里取不需要跑推理框架UTIL是唯一带经验成分的参数做行业梳理时建议同时按 0.3 和 0.6 各算一遍给出区间而不是点值。这个估算的用途不是替代 benchmark而是在没有实测数据时判断「某方案标的算力到底够不够跑它声称的功能」。4. 从 CAN 日志到感知指标用可复现的方式验证智能驾驶方案4.1 解析一份 CAN 日志的最小可运行脚本验证一套方案的实际行为最直接的材料是总线数据。# 配置 SocketCAN 接口比特率为 500kbps然后落盘带时间戳的报文 sudo ip link set can0 type can bitrate 500000 sudo ip link set up can0 # -t d 输出相对时间戳-L 输出 candump 日志格式便于后续回放与对齐 candump -t d -L can0 can_log_2022.ascbitrate必须和整车网络一致设错会直接丢帧且不报错-L格式保留了时间戳和通道信息配合canplayer可以原样回放是做复盘的基础。拿到日志后按 CAN ID 聚合区分周期报文和事件报文import re from collections import defaultdict LINE re.compile(r\((\d\.\d)\)\s(\w)\s([0-9A-Fa-f])#([0-9A-Fa-f])) def parse(path: str) - dict: frames defaultdict(list) with open(path) as f: for line in f: m LINE.match(line.strip()) if not m: continue ts, channel, can_id, data m.groups() # 按 ID 聚合后续用时间间隔判断周期报文还是事件报文 frames[can_id].append((float(ts), bytes.fromhex(data))) return frames frames parse(can_log_2022.asc) for cid, rows in sorted(frames.items(), keylambda x: -len(x[1]))[:5]: gaps [rows[i 1][0] - rows[i][0] for i in range(len(rows) - 1)] print(cid, len(rows), f平均间隔 {sum(gaps) / len(gaps):.4f}s)正则的四个捕获组分别是时间戳、通道、CAN ID、数据段按 ID 聚合后再算平均间隔间隔稳定在毫秒级的通常是周期信号车速、转向角间隔离散的通常是事件报文开门、碰撞信号。这一步能把「这辆车到底跑没跑智驾功能」这类问题从猜测变成可验证结论。单个信号的物理值解码def decode_signal(data: bytes, byte_start: int, byte_len: int, factor: float, offset: float) - float: 按 Intel 小端字节序解码信号物理值 原始值 * factor offset raw int.from_bytes(data[byte_start:byte_start byte_len], little) return raw * factor offset # 车速信号占第 2、3 字节factor 0.01offset 0单位 km/h payload bytes.fromhex(102788130000 0000.replace( , )) print(decode_signal(payload, 2, 2, 0.01, 0.0)) # 5000 * 0.01 50.0 km/hbyte_start和byte_len来自 DBC 文件factor、offset决定量纲。注意这段按小端处理Motorola 格式的报文需要逐位解析直接套用会得到错误结果——这是接盘别人脚本时最常见的坑。4.2 感知输出怎么算TTC 与简化 AP预警类功能的评价指标里TTC 最容易算也最容易被误用。def ttc(distance_m: float, ego_speed_mps: float, lead_speed_mps: float): 碰撞时间相对速度不大于 0 时返回 None表示不会追尾 rel ego_speed_mps - lead_speed_mps if rel 0: return None return distance_m / rel # 自车 25 m/s约 90 km/h前车 20 m/s间距 40 m print(ttc(40, 25, 20)) # 8.0 秒属于安全区间参数单位必须统一成米和米每秒混用 km/h 会得到差 3.6 倍的结果。工程上常把 TTC 低于 2 秒作为预警区间、低于 1 秒附近进入紧急制动区间具体阈值随车速和路面附着系数调整梳理时记录阈值来源比记录阈值本身重要。检测类指标用简化的单类别 AP 即可说明口径def iou(a, b) - float: a、b 均为 [x1, y1, x2, y2] ix1, iy1 max(a[0], b[0]), max(a[1], b[1]) ix2, iy2 min(a[2], b[2]), min(a[3], b[3]) inter max(0, ix2 - ix1) * max(0, iy2 - iy1) area_a (a[2] - a[0]) * (a[3] - a[1]) area_b (b[2] - b[0]) * (b[3] - b[1]) return inter / (area_a area_b - inter 1e-9) def average_precision(pred, gt, iou_thr: float 0.5) - float: pred: [(score, box)]gt: [box]单类别 AP 的简化实现 pred sorted(pred, keylambda x: -x[0]) used [False] * len(gt) tp, fp [], [] for _, box in pred: best_iou, best_j 0.0, -1 for j, g in enumerate(gt): if used[j]: continue v iou(box, g) if v best_iou: best_iou, best_j v, j if best_iou iou_thr and best_j 0: used[best_j] True tp.append(1); fp.append(0) else: tp.append(0); fp.append(1) cum_tp, cum_fp, precisions 0, 0, [] for t, f in zip(tp, fp): cum_tp t; cum_fp f precisions.append(cum_tp / (cum_tp cum_fp)) return sum(precisions) / len(precisions) if precisions else 0.0iou_thr是关键参数0.5 和 0.75 下同一个模型的 AP 能差十几个点行业梳理对比数字时必须标注阈值。used数组保证一个真值框只被匹配一次漏掉这个约束会算出虚高的分数。4.3 影子模式的触发式回传策略数据闭环的采样策略决定了模型迭代速度也是各家方案差距最大的地方。触发类型触发条件示例回传量级数据用途接管触发人工接管前若干秒的时序片段少而精失败场景复盘不一致触发影子模型与量产模型输出差异超阈值中长尾场景挖掘低置信度触发感知输出置信度低于阈值中标注补强随机采样固定比例抽取大保持基线分布防止采样偏置只做前三类会得到一个极端偏向困难场景的数据集模型在日常场景上的表现反而退化。随机采样这一列看着没技术含量实际是保持数据分布不失真的必要成本梳理时不能省。注意回传策略要连带记录脱敏和存储合规的处理方式否则这套方案在数据合规审查上是不完整的。5. 把智能驾驶行业梳理做成可 diff 的技术资产一次性梳理很快过期能持续用的做法是把结论落成结构化文件并纳入版本管理。第一步是定口径字典把每个指标的算法写清楚而不只是写字段名。指标口径定义必须附带记录的字段算力INT8 稠密峰值算力标称方式、是否含稀疏激光雷达探测距离10% 反射率下的最远距离测试条件、厂商自测或三方实测影子模式车队规模累计开通影子模式功能的车辆数统计截止时间安全等级单个功能对应的 ASIL 等级是否含 SOTIF 分析第二步是用代码固化对比逻辑而不是靠人眼扫表格。import pandas as pd cols [厂商, 时间切片, 算力_TOPS, 算力口径, 激光雷达数量, 安全等级, 高速领航, 车队规模] df pd.read_csv(adas_landscape.csv, usecolscols) # 只保留同口径算力避免不同标称方式混在同一张对比图里 df df[df[算力口径] INT8-dense] pivot df.pivot_table(index厂商, columns时间切片, values算力_TOPS, aggfuncmax) print(pivot.fillna(-))usecols显式限定列字段被别人改名字时会立刻报错而不是静默丢数据aggfuncmax处理同一厂商多个平台的重复行fillna(-)保留没有数据的格子避免误读成零。日常维护上做完一轮梳理就打一次 tag季度更新时用git diff --word-diff看字段级变化重点关注那些数字变大但口径变了的行——这类改动往往比数字本身更能说明行业走向。另一个实用技巧是给每个结论标注置信度来源来自公开财报、来自拆解报告、还是来自自己的脚本复算三者在后续复盘时的权重完全不同。把来源写进 CSV 的附加列比写在 PPT 备注里可靠得多因为 CSV 会跟着仓库一起演进备注不会。本文还有配套的精品资源点击获取 智能驾驶行业梳理：从配置表到域控算力、功能安全与数据闭环
简介这份资源是2022年智能驾驶行业梳理系列的第一部分PPT面向关注汽车智能化产业链的投资者、行业研究人员及汽车电子从业者帮助快速建立从产业架构到Tier 1厂商格局的整体认知。压缩包内共1个pptx文件约6.79MB以图文页形式呈现行业逻辑与分析框架。内容围绕智能化的基础设施、基础零部件、芯片、软件四大项展开先以手机发展史类比智能驾驶的循序渐进路径分析新能源汽车放量、新势力崛起与差异化竞争带来的加速因素随后对比汽车零部件与消费电子的市场空间及渗透节奏梳理感知层、决策层、执行层的供应链层次并重点介绍德赛西威、华阳集团、均胜电子、华域汽车等Tier 1厂商的业务布局包括域控制器、车载娱乐系统、液晶仪表、抬头显示及智能座舱等方向。目前已有104人学习适合用于产业链梳理、公司研究与入门科普参考。1. 智能驾驶行业梳理为什么要从「配置表」往下钻2022 年做智能驾驶行业梳理最容易得到一份漂亮但没法验证的 PPT满页写着「搭载 X 颗激光雷达、算力 Y TOPS、支持 L2 高速领航」看完仍然不知道这套方案在什么场景下会失效、成本卡在哪一环、软件栈缺哪块。真正有复现价值的智能驾驶梳理方式是沿着「传感器配置 → 原始数据 → 域控制器算力 → 功能安全等级 → 数据闭环规模」这条链路把每个数字落到可计算、可测量、可对账的技术量上而不是停在厂商发布会的话术层。这份梳理适合两类人一类是要判断某套方案能不能落地、值不值得集成的技术选型者另一类是接手了别人的行业调研、需要把结论重新验算一遍的工程师。下面按技术栈分层、关键数字口径、公开数据处理、长期维护四条线推进最后落在能持续复用的梳理方法上。2. 把智能驾驶技术栈拆成感知、决策、执行与数据闭环四层2.1 四层划分的边界以及 2022 年前后的代表性形态感知层负责把物理世界变成结构化输入。2022 年前后前视摄像头上到 800 万像素毫米波雷达主流是 3 发 4 收的 77GHz 方案激光雷达正从机械旋转式转向半固态转镜和 MEMS超声波雷达仍然只负责近距泊车。融合方式上前融合原始数据级在论文和演示里被反复讨论量产落地仍以后融合目标级为主少量方案做到了特征级。决策规划层是模块化流水线感知 → 定位 → 预测 → 规划 → 控制每一段都有独立接口和独立失效模式。端到端方案在 2022 年基本停留在研究阶段行业梳理时把它单列一行即可不要和量产方案混在同一张表里比较。执行层决定功能上限。线控转向、线控制动One-Box 形态开始替代传统真空助力器、线控驱动三件套齐了才有条件谈横向和纵向的连续控制。冗余设计体现在双电源、双通信通道、双绕组电机上梳理时要把「有没有冗余」和「冗余到什么级别」分开记录。数据闭环层是最近几年才被单独拎出来的。影子模式让量产车在后台跑模型但不控车把「模型输出与人类驾驶不一致」的片段回传用于长尾场景挖掘。这一层的成本结构和其他三层完全不同属于运营支出而非物料支出混在一起算会导致整份梳理失真。2.2 用 YAML 把一套智能驾驶方案结构化落地行业梳理最怕字段随手写今天记「算力」明天记「AI 算力」季度一对比就对不上。常见做法是先定一份最小字段集用 YAML 描述、用脚本校验。# adas_stack_2022.yaml 方案名: demo_l2plus 时间切片: 2022 感知: 前视摄像头: 分辨率_万像素: 800 视场角_度: 120 毫米波雷达: 数量: 5 最远探测距离_m: 210 激光雷达: 数量: 1 线束: 128 域控制器: 算力_TOPS: 128 算力口径: INT8-dense # 必须显式声明否则不同厂商数字不可比 安全等级: ASIL-D 功能: - 高速领航 - 自动泊车 数据闭环: 影子模式车队规模: 100000 日均回传片段数: 5000字段不多但每个都对应一个可以追问的问题算力口径是稠密还是稀疏、雷达最远距离是在什么反射截面积下测的、安全等级是整个域控的还是单个功能的。校验脚本负责把这些硬约束卡住。import yaml with open(adas_stack_2022.yaml, encodingutf-8) as f: stack yaml.safe_load(f) REQUIRED [感知, 域控制器, 功能, 数据闭环] def validate(stack: dict) - bool: missing [k for k in REQUIRED if k not in stack] if missing: raise ValueError(f缺少必要字段: {missing}) # 算力口径缺失时直接拒绝避免后续把不同标称方式的数字放进同一张图 if 算力口径 not in stack[域控制器]: raise ValueError(域控制器必须声明算力口径) sensors stack[感知] lidar sensors.get(激光雷达, {}).get(数量, 0) if lidar 0 and 前视摄像头 not in sensors: raise ValueError(带激光雷达的方案必须登记前视摄像头配置) return True validate(stack) print(stack[域控制器][算力_TOPS], stack[域控制器][算力口径])REQUIRED是硬性四层缺任何一层说明这份方案描述不完整算力口径检查是整份梳理里性价比最高的一条规则它拦掉的大部分是「把稀疏算力当稠密算力写进对比表」这类错误。扩展到多方案时把validate循环套在文件列表上输出一份带错误行的报告比人工翻表快得多。2.3 传感器配置横向对比与选型理由把配置表拆成对比表之后很多看似矛盾的选择就说得通了。传感器2022 年前后典型参数优势短板主要用途前视摄像头800 万像素约 120° FOV分辨率高能读车道线和交通标志受逆光、雨雾影响大缺深度车道保持、AEB、标志识别环视摄像头200 万像素约 190° FOV覆盖近距盲区畸变校正开销大泊车、低速避障毫米波雷达77GHz3 发 4 收最远约 210m测距测速准全天候角分辨率低静止目标难分类自适应巡航、盲区监测半固态激光雷达905nm128 线10% 反射率下约 150m三维点云密度高成本高雨雪场景衰减城市领航、高精建图超声波雷达探测距离约 5m成本极低距离太短易受干扰泊车测距选型上的分歧几乎都来自三个约束成本、算力、冗余要求。纯视觉路线把成本压到最低代价是对算力和数据规模的要求陡增加激光雷达是用物料成本换感知确定性但同时推高域控的输入带宽要求。梳理时把「成本量级」「带宽需求」「失效场景」三列补齐比只记参数有用得多。提示传感器参数一定要连带记录测试条件尤其是激光雷达的探测距离不同反射率下的数字能差一倍脱离条件的对比没有意义。3. 算力、域控制器与功能安全智能驾驶梳理中最容易讲糊的三组数字3.1 TOPS 的口径差异以及等效算力的估算方式「TOPS」是行业梳理里被滥用最严重的单位。同样的芯片标 INT8 还是 FP16、按稀疏还是稠密、按峰值还是有效数字能差出一个数量级。补一条基础换算一次乘加算两次运算所以TOPS ≈ 2 × MAC 数 × 频率 ÷ 10^12。厂商标稀疏算力时等效到稠密通常要打个折扣具体折扣取决于结构化稀疏比例不能简单除二。真正影响功能的是有效算力。峰值算力和有效算力之间隔着算子调度、内存带宽、功耗墙三道坎经验上有效利用率落在 30% 到 60% 之间。做行业梳理时把「峰值算力」和「有效算力区间」分成两列记录比只写一个数字更抗追问。3.2 从分布式 ECU 到中央计算三种域控架构的取舍架构形态典型组成通信方式优势代价2022 年前后落地情况分布式 ECU每个功能一个控制器CAN / LIN开发解耦供应商成熟线束重跨域协同难仍是存量主力域集中智驾域 座舱域 车身域车载以太网 CAN减少控制器数量域内算力共享域间通信成为新瓶颈新车型主流选择中央计算 区域控制中央计算单元 区域网关千兆以太网算力集中软件可 OTA 升级单点失效风险高需冗余高端车型开始导入梳理架构时最好补一行「跨域通信时延」很多方案宣传的算力优势在实际布线条件下会被通信时延吃掉。3.3 ASIL 等级与 SOTIF 在梳理表中的位置功能安全等级由三个维度共同决定严重度 S0-3、暴露率 E0-4、可控性 C0-3。三维度组合后落到 ASIL A 到 D其中 ASIL D 对应最严苛的组合通常出现在转向、制动这类直接控制车辆运动的链路上。做梳理时把「功能」和「ASIL 等级」一一对应而不是给整个域控贴一个等级标签否则一追问就露怯。SOTIF 处理的是另一类问题系统没有任何故障但性能不足以覆盖某个场景比如逆光下的视觉误检。这部分在行业梳理里经常被漏掉实际却是城市领航功能能不能交付的关键。表里加一列「已知性能边界场景」比堆砌安全认证清单有价值得多。3.4 用 Python 粗估感知模型的算力需求def conv_flops(kernel: int, cin: int, cout: int, hout: int, wout: int) - float: 单层卷积的运算量乘加各计一次运算 macs kernel * kernel * cin * cout * hout * wout return 2 * macs # 主干网络中的一个 3x3 卷积输入 64 通道输出 128 通道输出特征图 56x56 layer conv_flops(3, 64, 128, 56, 56) print(f单层 {layer / 1e9:.3f} GFLOPs) NET_FLOPs 20e9 # 整网约 20 GFLOPs 的检测网络INT8 FPS 30 # 目标帧率 UTIL 0.4 # 有效利用率经验值落在 0.3~0.6 区间 tops NET_FLOPs * FPS / UTIL / 1e12 print(f反推所需 INT8 有效算力约 {tops:.2f} TOPS)kernel、cin、cout、hout、wout直接从网络结构里取不需要跑推理框架UTIL是唯一带经验成分的参数做行业梳理时建议同时按 0.3 和 0.6 各算一遍给出区间而不是点值。这个估算的用途不是替代 benchmark而是在没有实测数据时判断「某方案标的算力到底够不够跑它声称的功能」。4. 从 CAN 日志到感知指标用可复现的方式验证智能驾驶方案4.1 解析一份 CAN 日志的最小可运行脚本验证一套方案的实际行为最直接的材料是总线数据。# 配置 SocketCAN 接口比特率为 500kbps然后落盘带时间戳的报文 sudo ip link set can0 type can bitrate 500000 sudo ip link set up can0 # -t d 输出相对时间戳-L 输出 candump 日志格式便于后续回放与对齐 candump -t d -L can0 can_log_2022.ascbitrate必须和整车网络一致设错会直接丢帧且不报错-L格式保留了时间戳和通道信息配合canplayer可以原样回放是做复盘的基础。拿到日志后按 CAN ID 聚合区分周期报文和事件报文import re from collections import defaultdict LINE re.compile(r\((\d\.\d)\)\s(\w)\s([0-9A-Fa-f])#([0-9A-Fa-f])) def parse(path: str) - dict: frames defaultdict(list) with open(path) as f: for line in f: m LINE.match(line.strip()) if not m: continue ts, channel, can_id, data m.groups() # 按 ID 聚合后续用时间间隔判断周期报文还是事件报文 frames[can_id].append((float(ts), bytes.fromhex(data))) return frames frames parse(can_log_2022.asc) for cid, rows in sorted(frames.items(), keylambda x: -len(x[1]))[:5]: gaps [rows[i 1][0] - rows[i][0] for i in range(len(rows) - 1)] print(cid, len(rows), f平均间隔 {sum(gaps) / len(gaps):.4f}s)正则的四个捕获组分别是时间戳、通道、CAN ID、数据段按 ID 聚合后再算平均间隔间隔稳定在毫秒级的通常是周期信号车速、转向角间隔离散的通常是事件报文开门、碰撞信号。这一步能把「这辆车到底跑没跑智驾功能」这类问题从猜测变成可验证结论。单个信号的物理值解码def decode_signal(data: bytes, byte_start: int, byte_len: int, factor: float, offset: float) - float: 按 Intel 小端字节序解码信号物理值 原始值 * factor offset raw int.from_bytes(data[byte_start:byte_start byte_len], little) return raw * factor offset # 车速信号占第 2、3 字节factor 0.01offset 0单位 km/h payload bytes.fromhex(102788130000 0000.replace( , )) print(decode_signal(payload, 2, 2, 0.01, 0.0)) # 5000 * 0.01 50.0 km/hbyte_start和byte_len来自 DBC 文件factor、offset决定量纲。注意这段按小端处理Motorola 格式的报文需要逐位解析直接套用会得到错误结果——这是接盘别人脚本时最常见的坑。4.2 感知输出怎么算TTC 与简化 AP预警类功能的评价指标里TTC 最容易算也最容易被误用。def ttc(distance_m: float, ego_speed_mps: float, lead_speed_mps: float): 碰撞时间相对速度不大于 0 时返回 None表示不会追尾 rel ego_speed_mps - lead_speed_mps if rel 0: return None return distance_m / rel # 自车 25 m/s约 90 km/h前车 20 m/s间距 40 m print(ttc(40, 25, 20)) # 8.0 秒属于安全区间参数单位必须统一成米和米每秒混用 km/h 会得到差 3.6 倍的结果。工程上常把 TTC 低于 2 秒作为预警区间、低于 1 秒附近进入紧急制动区间具体阈值随车速和路面附着系数调整梳理时记录阈值来源比记录阈值本身重要。检测类指标用简化的单类别 AP 即可说明口径def iou(a, b) - float: a、b 均为 [x1, y1, x2, y2] ix1, iy1 max(a[0], b[0]), max(a[1], b[1]) ix2, iy2 min(a[2], b[2]), min(a[3], b[3]) inter max(0, ix2 - ix1) * max(0, iy2 - iy1) area_a (a[2] - a[0]) * (a[3] - a[1]) area_b (b[2] - b[0]) * (b[3] - b[1]) return inter / (area_a area_b - inter 1e-9) def average_precision(pred, gt, iou_thr: float 0.5) - float: pred: [(score, box)]gt: [box]单类别 AP 的简化实现 pred sorted(pred, keylambda x: -x[0]) used [False] * len(gt) tp, fp [], [] for _, box in pred: best_iou, best_j 0.0, -1 for j, g in enumerate(gt): if used[j]: continue v iou(box, g) if v best_iou: best_iou, best_j v, j if best_iou iou_thr and best_j 0: used[best_j] True tp.append(1); fp.append(0) else: tp.append(0); fp.append(1) cum_tp, cum_fp, precisions 0, 0, [] for t, f in zip(tp, fp): cum_tp t; cum_fp f precisions.append(cum_tp / (cum_tp cum_fp)) return sum(precisions) / len(precisions) if precisions else 0.0iou_thr是关键参数0.5 和 0.75 下同一个模型的 AP 能差十几个点行业梳理对比数字时必须标注阈值。used数组保证一个真值框只被匹配一次漏掉这个约束会算出虚高的分数。4.3 影子模式的触发式回传策略数据闭环的采样策略决定了模型迭代速度也是各家方案差距最大的地方。触发类型触发条件示例回传量级数据用途接管触发人工接管前若干秒的时序片段少而精失败场景复盘不一致触发影子模型与量产模型输出差异超阈值中长尾场景挖掘低置信度触发感知输出置信度低于阈值中标注补强随机采样固定比例抽取大保持基线分布防止采样偏置只做前三类会得到一个极端偏向困难场景的数据集模型在日常场景上的表现反而退化。随机采样这一列看着没技术含量实际是保持数据分布不失真的必要成本梳理时不能省。注意回传策略要连带记录脱敏和存储合规的处理方式否则这套方案在数据合规审查上是不完整的。5. 把智能驾驶行业梳理做成可 diff 的技术资产一次性梳理很快过期能持续用的做法是把结论落成结构化文件并纳入版本管理。第一步是定口径字典把每个指标的算法写清楚而不只是写字段名。指标口径定义必须附带记录的字段算力INT8 稠密峰值算力标称方式、是否含稀疏激光雷达探测距离10% 反射率下的最远距离测试条件、厂商自测或三方实测影子模式车队规模累计开通影子模式功能的车辆数统计截止时间安全等级单个功能对应的 ASIL 等级是否含 SOTIF 分析第二步是用代码固化对比逻辑而不是靠人眼扫表格。import pandas as pd cols [厂商, 时间切片, 算力_TOPS, 算力口径, 激光雷达数量, 安全等级, 高速领航, 车队规模] df pd.read_csv(adas_landscape.csv, usecolscols) # 只保留同口径算力避免不同标称方式混在同一张对比图里 df df[df[算力口径] INT8-dense] pivot df.pivot_table(index厂商, columns时间切片, values算力_TOPS, aggfuncmax) print(pivot.fillna(-))usecols显式限定列字段被别人改名字时会立刻报错而不是静默丢数据aggfuncmax处理同一厂商多个平台的重复行fillna(-)保留没有数据的格子避免误读成零。日常维护上做完一轮梳理就打一次 tag季度更新时用git diff --word-diff看字段级变化重点关注那些数字变大但口径变了的行——这类改动往往比数字本身更能说明行业走向。另一个实用技巧是给每个结论标注置信度来源来自公开财报、来自拆解报告、还是来自自己的脚本复算三者在后续复盘时的权重完全不同。把来源写进 CSV 的附加列比写在 PPT 备注里可靠得多因为 CSV 会跟着仓库一起演进备注不会。本文还有配套的精品资源点击获取