简介：中信建投证券于2021年8月14日发布的中国汽研（601965）深度研究报告，聚焦智能驾驶测评这一稀缺赛道，认为公司是攻守兼备的优质标的，适合关注汽车服务、智能网联检测领域的投资者与行业研究人员研读。资源为单份PDF文件，大小4.89MB，排版清晰，包含公司业务拆解、汽车前装检测行业格局、智能汽车检测市场空间测算、投资评价及盈利预测等核心模块。已有169人学习下载，内容不仅覆盖传统检测业务的稳健增长逻辑，还重点剖析了技术、产品、消费、政策四重催化下智能化检测的增量空间，并给出2021-2023年归母净利润及EPS预测，同时提示了渗透率不及预期等风险。对理解第三方检测机构在智能驾驶产业链中的卡位价值具有直接参考意义。

1. 智能驾驶测评为什么成了关键瓶颈：一份研报背后的技术机会

智能驾驶测评是这个行业里少数“听起来只是测试、实际上决定能不能量产”的方向。某券商2021年的一份行业深度报告，把一家汽车技术研究机构的智能驾驶测评能力单独拎出来讲，并在标题里用了“稀缺”二字——这个判断放到现在依然成立：很多团队能做出会跑的智能驾驶系统，却很难拿出让人信服的证据，证明它在各种场景下足够安全、可批量交付。这篇笔记不聊投资，只聊技术落地：智能驾驶测评到底是什么、怎么搭、参数怎么设、坑在哪，以及它值不值得作为方向投入。

2. 智能驾驶测评体系怎么拆：标准、场地与四层测试任务

2.1 法规标准是测评的第一层地基

智能驾驶测评不是“自己觉得测过了就算数”，它有一套从法规到行业认可的规则体系。早期大部分主动安全功能是车企自愿做，测多测少全看良心；现在各国都在把AEB（自动紧急制动）、LKA（车道保持辅助）这类基础ADAS功能纳入新车评价规程甚至强制性准入范围，没有第三方测评报告，车型连上市销售这关都过不去。这就是测评能力成为稀缺资源的第一层原因：它已经从“加分项”变成了“及格线”。

对刚接触这个方向的人来说，建议先理清三类标准：

• 强制性法规：管的是底线，重点看AEB、车道偏离预警、盲区监测等基础功能在特定车速和场景下是否触发，判据是“有没有”和“何时触发”。
• 第三方评价规程：在法规之上做更严格的安全星级评价，增加了更多场景类型、更细的通过条件，考的是“表现好不好”。
• 功能安全与预期功能安全标准：前者面向电子电气系统失效，后者面向系统在规范使用下仍可能出现的性能局限。严格来说，ISO 26262和ISO 21448这两类标准是测评体系的“元规则”，它们决定了测评活动本身的流程合规性。

标准是不断演进的黑匣子，别指望背下来，关键是建立一条追踪机制。我一般会在团队里维护一份标准条款与测试用例的映射表，每条标准落到具体场景、具体判据，标准一更新就回头逐条核对映射关系。这个动作本身不复杂，但没有它，测评体系很快就会变成“测了什么不知道、为什么这么测也不知道”的状态。

2.2 四层测试任务：法规测试、功能测试、场景测试与预期功能安全

实际工程里，我不会把测评简单理解成“拉一台车出去跑”，而是拆成四个递进的层次：

法规测试解决“合不合法”，功能测试解决“做没做到”，场景测试解决“遇到没见过的交通情况怎么办”，预期功能安全测试解决“系统自己都不知道自己不行的时候怎么办”。最后一个最常见但最容易被忽略——很多系统在传感器视野、算法性能边界之外悄悄失效，没有预期功能安全的视角，单靠堆场景永远测不完。

四层测试必须配套使用，不能互相替代。法规测试过了不代表场景测试能过，场景测试跑得再好也不代表预期功能安全风险已闭环。建议新团队先做1到2层，把测试基础设施跑通，再逐步向上叠加。

2.3 测评中心的角色：为什么说它是“攻守兼备”的投入

“攻守兼备”这个词虽然不是技术参数，但放在测评方向上其实很贴切。“攻”的一面在于，谁先建起高置信度的测评体系，谁就有能力定义行业测试标准、承接第三方检测业务，形成进入壁垒；研发团队也能用这套体系反过来拷问算法，逼着感知、规控模块往更难的场景迭代。“守”的一面在于，不管智能驾驶走纯视觉还是多传感器、依赖高精地图还是无图方案，最终都要用同一套测评方法来验收，测评是技术路线分叉时仍然存在的确定性需求。

这也是为什么不少整车厂和供应商宁可花大价钱自建测试团队，而不是全部委托给外部机构——外部报告解决“能不能卖”，内部测评解决“怎么改”。两条线一次投入，两头受益。对于想切入这个方向的工程师来说，意味着两类机会：一类是进第三方检测机构，把单点场景做成标准化产品；另一类是在主机厂内部从零搭建测评能力，直接服务研发迭代，这两条路都值得投入。

3. 从零搭建一套可用的测评环境：真值系统、场景库与最小闭环

3.1 测试车辆改造：真值系统、数据采集与时间同步

把普通测试车改造成“能用来评测智能驾驶的车”，最难的部分不是装传感器，而是让所有传感器说实话。测评依赖真值，也就是“那一刻真实世界到底是什么状态”，如果没有高精度真值系统，被测系统的输出根本无从比对。

我的常见做法是分三步走。第一步，装组合惯导，也就是RTK差分定位加惯性测量单元，用来输出厘米级位置、速度、姿态和精确时间基准；第二步，同步采集CAN总线信号、摄像头视频、激光雷达点云和毫米波雷达目标列表，覆盖感知和决策执行两侧的关键数据；第三步，给所有传感器统一打硬件时间戳，这是最容易被轻视的一步。很多数据采集方案里视频流有自己的时间戳，CAN信号有自己的时间戳，两套时间体系差几百毫秒很常见，问题当时看不出来，一但拿去做场景回放就全乱了。

时间同步的工程实现上，首选方案是让所有采集设备跟随同一个时钟源。差分GPS接收机输出PPS脉冲，或者用PTP（精确时间协议）把统一时间同步到网内各设备，确保各传感器帧级对齐。做数据回放时还要再校验一次同步偏移，方法很简单：找一个急刹车片段，对比CAN里的车速骤降时刻与视频里刹车灯点亮时刻，两者差应小于一个视频帧。

这套环境涉及不少硬件安装和标定工作，很难一次到位。新团队建议先用一台车、一条固定环线、一套采集配置跑通全流程，再扩展到多车多路线，不要一上来就铺开。

3.2 场景库建设：从自然驾驶数据到可复现的测试用例

测评的第二块地基是场景库。场景库不是把路测数据存起来就行，它的核心目标是把真实交通里发生的事变成可复现、可参数化、可批量执行的测试用例。

场景来源通常有这么几个：自然驾驶数据里的典型行为片段（前车急刹、邻车切入、行人横穿）、交通事故数据里的高风险片段、法规标准要求的固定场景、以及针对被测系统弱点的对抗生成场景。其中自然驾驶数据的利用效率最高，但也是最难做清理的——一段几十公里的数据里可能只有几秒钟是真正有价值的场景。

场景需要参数化。拿最常见的切入场景（cut-in）举例：不能只记“旁边车道有车插进来”，而要拆成目标车切入时的纵向相对距离、横向跨越速度、相对车速、自车车速、车道类型、路面附着状态等一组参数。这样同一个逻辑场景就能派生出几十上百条具体用例，覆盖不同难度边界。

我个人会按“功能场景—逻辑场景—具体场景”三层来组织场景库：功能场景描述事件类别，逻辑场景定义参数取值范围，具体场景给出每一组确定参数值。每次路测发现的新危险事件，就把它沉淀为一条新的逻辑场景，逐步扩大覆盖边界。这是一项需要长期积累的工作，但也是测评能力最深的护城河。

3.3 最小可用的自动化测评闭环示例

测评体系的“骨架”确定后，还要跑通一个最小的自动化闭环：读数据、识别场景事件、算指标、出报告。下面给一个精简但能直接改用的示例，演示cut-in场景下“系统响应时间”的评估逻辑。

from dataclasses import dataclass import json @dataclass class FrameData: ts: float # 本帧时间戳，统一为UTC毫秒 ego_speed: float # 自车速度，m/s ego_acc: float # 自车纵向加速度，m/s²，制动为负 target_lat: float # 目标车横向位置，m，自车中心线为0 target_lon: float # 目标车纵向相对距离，m，自车位置为0 target_rel_v: float # 目标相对速度，m/s，正为接近 def load_frames(data_dir: str, start: int = 1, end: int = 400): frames = [] for i in range(start, end + 1): with open(f"{data_dir}/{i:04d}.json", "r", encoding="utf-8") as f: raw = json.load(f) frames.append(FrameData(**raw)) return frames def is_cut_in(frame: FrameData) -> bool: # 典型切入事件：目标横向位置位于本车道边界附近，且有接近趋势 return abs(frame.target_lat) < 0.3 and frame.target_rel_v > 0.5 def evaluate_cut_in_response(frames): event_start = None response_time = -1 for frame in frames: if is_cut_in(frame): if event_start is None: event_start = frame.ts # 事件发生时刻，首次越线 continue if event_start is not None and frame.ego_acc < -1.0: response_time = frame.ts - event_start # 系统开始明显制动 break max_deceleration = min(f.ego_acc for f in frames) return { "cut_in_detected": event_start is not None, "response_time_ms": response_time, "max_deceleration_m2s": max_deceleration, } if __name__ == "__main__": frames = load_frames("./data/cut_in_case") result = evaluate_cut_in_response(frames) print(json.dumps(result, ensure_ascii=False, indent=2))

代码的逻辑不复杂：逐帧读入数据，先判断是否出现切入事件，再找系统开始明显制动的时刻，两者相减得到响应时间。参数上注意三个地方：target_lat的阈值0.3米表示目标车已经进入本车道边界，太小容易漏检，太大会把邻道正常行驶也算进来；target_rel_v的0.5米/秒用于过滤静止干扰物；制动判定阈值-1.0米/秒²不是随意定的，它对应大多数人能感知到的平缓制动下限，低于这个值可能是传感器噪声或轻微波动，容易误判。

这是最简的规则版本。实际生产中会替换掉硬编码阈值：事件识别交给基于目标跟踪的算法，制动判定结合AEB触发信号和加速度曲线斜率。但接口设计可以沿用这个思路——数据帧结构统一、评价逻辑与采集格式解耦、结果输出成标准JSON，后续换算法、换传感器都只改局部模块。

4. 测评指标怎么定：从“能刹住”到“敢说安全”的五个关键指标

4.1 功能指标：触发条件、响应时间与控制质量

功能指标的难点不是“有没有指标”，而是“指标之间会打架”。比如AEB测试只盯着“触发距离够不够远”，系统就可能提前缓刹，结果在密集车流里经常被后车追尾；只盯着“响应时间够不够快”，系统又可能频繁误触发，搞得驾乘体验一塌糊涂。所以功能指标要一组一组看，不能单点考核。

我常用的一组最小功能指标是：

• 触发条件边界：记录系统触发时的本车速度、目标相对速度、TTC（碰撞时间）阈值。重点看阈值附近的表现，通常要求临界区内的触发一致性，不能同一参数状态时而触发时而不触发。
• 响应时间：从事件发生到系统输出控制指令的时间差。cut-in场景一般看100毫秒级差异；AEB场景对响应稳定性要求更高，跑同一场景多次时，响应时间方差不能过大。
• 控制质量：不只问“刹没刹住”，还要看减速度曲线平滑度、横向偏移峰值、驾驶员主观体验。用“最大减速度变化率”来量化粗暴程度，减速度变化率超过一定阈值就触发舒适性告警。

这三类指标的权重随场景而变化：法规测试最看重触发条件边界，因为那是底线；用户日常体验最看重控制质量和误触发率；安全评价则把响应时间放到第一位。建议在测试规范里明确写明每类场景的指标优先序，才能避免开发团队和测试团队各说各话。

4.2 场景指标：场景覆盖率与边界参数密度

场景指标回答的问题是：我们测过的这些内容，能不能代表真实世界。两个指标我每次汇报时都会带上，一个是场景类型覆盖率，另一个是边界参数密度。

场景类型覆盖率，指场景库中已覆盖的场景类型占目标场景清单的比例。目标场景清单从哪里来？从标准要求加真实事故形态加路采数据聚类结果三方汇总。注意覆盖率不等于数量，同一个cut-in场景参数稍微变一变就能凑出上千条用例，但那只覆盖了一个事件类别，对提升覆盖率没有帮助。

边界参数密度，指在参数空间的边缘区域布置的测试用例数量。算法往往在参数边界附近失效，比如目标车切入时横向距离刚好贴近车道线、相对速度介于“系统认为安全”和“实际危险”的临界值。边界参数密度越高，越容易暴露潜在失效。我会用二维参数网格来审视场景库，以相对距离为横轴、相对速度为纵轴，观察用例在网格中的分布，凡是边缘区域稀疏的，就针对性补测试用例。

4.3 统计指标：接管率、风险事件率与置信区间

路测积累到一定里程后，就要用统计指标来判断系统整体表现。最常看的是每千公里接管次数和危险事件率。接管次数统计的是系统请求驾驶员接管或驾驶员因不信任而主动接管的次数；危险事件率则统计路测中出现的近距离切入、急刹、偏离车道等风险事件。

这里有个容易翻车的细节：统计指标必须有明确的定义边界，否则数据之间完全不可比。比如接管，要区分“系统请求的被动接管”和“驾驶员主动接管”，两者含义完全不同；再比如危险事件，必须明确定义TTC阈值和事件持续时间，不然同一段路测数据两个人能统计出两个结果。

另一个是置信区间问题。路测里程再长，抽样偏差始终存在。1000公里合法里程里零接管，并不代表每千公里接管率真的为零，样本量不足时这个结论非常脆弱。我一般会先设定可接受的失效率上限，再反推所需的最低测试里程，而不是跑完多少算多少。这也是测评报告里最容易被外部专家质疑的地方，提前算清楚才能站得住脚。

5. 智能驾驶测评避坑指南：五个让人翻车的常见问题

5.1 场景复现不了：先查传感器时间同步

现象：同一个测试场景，同一套软件版本，上午跑一遍系统触发了AEB，下午再跑一遍相同场景，系统没反应。换了驾驶员、换了测试车也无规律，完全没有复现性。

原因：最初怀疑是算法问题，查了很久才发现是时间同步漂移。车载摄像头时间戳来自系统时钟，CAN信号时间戳来自CAN网关，两套时间相差约600毫秒。回放时事件检测模块先看到的是晚到的目标信息，导致场景状态和实际车辆状态错位，触发逻辑时好时坏。

解决：从采集源头统一所有传感器的时间基准，用差分GPS或PTP做硬件同步，并在数据回放前加“同步校验”步骤。日常排障建议把时间戳对齐检查做成自动化脚本，每次回放前先计算视频关键事件与CAN信号关键事件的时间偏移，超过阈值直接拒绝回放。

5.2 结果不稳定：把道路测试当台架测试用

现象：同一版本软件，上周路测表现优秀，这周换了一条路、换了个时段，指标直接下滑一截。开发团队拿着报告找测试团队理论，双方各执一词。

原因：道路测试的环境变量太多，交通流密度、日照角度、路面状态、随机目标物都会影响智能驾驶表现。拿道路测试数据做“版本好坏”的判断，本质上是在拿随机样本做统计推断，样本量不够时结果必然不稳定。

解决：把“评审版本”和“抽样验证”分开。版本通过与否以仿真回归测试为基准——固定场景库、固定参数、固定评价逻辑，保证可复现；道路测试只做抽样验证和未知场景发现。道路测试报告里必须记录交通流密度、天气、光照、时间段，并注明该批次结果不对应版本结论。

5.3 场景参数太随意：测出来好看、上路不好用

现象：某系统在内部所有cut-in测试中都表现良好，一到开放道路就频繁出现“反应太晚”的抱怨。测试团队一开始觉得是用户故意刁难，后来才发现真实路况的cut-in参数比测试场景激进得多。

原因：场景参数是按“理想情况”设计的，比如目标车缓缓切入、横向距离刚好压线、相对速度却远低于真实博弈场景中的速度。这种参数下系统有充足时间响应，测试自然全过，但也完全没有暴露性能边界。

解决：参数必须从真实路采数据里提取分布，不要凭直觉填表。把路测数据中所有cut-in事件的横向距离、纵向距离、相对速度做分位数统计，取5%到95%分位范围作为测试参数矩阵。同时定期用新采集数据校准参数分布，防止场景库逐渐偏离真实路况。

5.4 标注口径不统一：同一指标横跳的源头

现象：同一批点云数据，两个月后再标注一遍，目标物数量、类别分布和之前差异很大。用新旧标注分别评测同一套感知算法，AEB误触发率指标一个高一个低，不知道系统真实水平是什么。

原因：不同标注员对“遮挡目标”“远距离小目标”“部分可见目标”的处理标准不一致。有的人只要点云够几个点就标，有的人要求目标轮廓完整才算数。没有统一标注规范，数据质量完全取决于执行者个人尺度和当日状态。

解决：先定分类树，明确每个目标类别的边界和最小标注要求；再跑一致性检验，用同一批数据进行重复标注，计算标注一致率，不一致的样本强制复审。关键数据集的标注规范要冻结版本，数据更新时标注规范本身不能随意改，这样才能保证前后指标可比。

5.5 只看功能通过率：漏了预期功能安全评估

现象：某系统在所有标准法规测试、功能测试中全部通过，AEB触发距离、响应时间都在目标范围内，但在一个普通雨夜场景中，系统对路面积水反光产生误识别，出现一次不必要的紧急制动。

原因：测试矩阵覆盖了“系统应该会做什么”，但没有覆盖“系统在什么条件下不知道自己做不到”。雨夜反光导致传感器产生虚假目标，感知模块置信度不够高却仍然输出了危险目标，规控模块按正常逻辑触发制动，整套链路“功能正常”，但整体行为错误。

解决：引入预期功能安全视角，给感知、决策、执行各环节建立性能边界清单，专门设计“边界扫掠”用例。比如把传感器退化条件（雨雾、逆光、低对比度）和场景条件做成交叉矩阵，逐格扫过，找出“看起来正常、实际不可信”的盲区。这类测试更应该纳入版本准入条件，因为它暴露的正是真实路测中最危险的那类事故。

6. 把测评沉淀成能力：一份可复现测试规范的最小样本

测评做到最后，拼的不是某一次测试做得多漂亮，而是能不能让测试结果长期稳定可信。我的习惯是每接手一个项目，第一件事先沉淀一份可复现的测试规范，让后来者拿着文档就能复现结果，而不是依赖某个测试工程师的经验。

一份最小可用规范至少包含这几个部分：

制定规范时的关键原则是：一切判据要写在执行之前，不允许在跑完数据之后再“根据数据表现”调整阈值，否则指标会不断向系统能力妥协，测评就失去了拷问系统的意义。我在团队里定死了一条规矩：测试参数和判据变更必须走评审流程，禁止个人在执行过程中临时修改。

还有一条重要经验：把每次回归测试的输入和输出连同软件版本一起归档。三个月后有人质疑某个指标是当时“测错了”时，能快速调出当时的数据包、场景参数和软件版本号，直接重跑验证，最有说服力。数据闭环的链路我也一直在维护：路测发现异常片段 → 沉淀为场景用例 → 加入回归场景库 → 新版软件必须重跑。这个循环跑得越顺畅，测评能力的护城河越深，我自己在这上面的投入也最值得。希望帮到你。

本文还有配套的精品资源，点击获取