2. KPI体系总论：什么是KPI、为什么ADAS需要KPI、KPI体系设计原则（SMART原则）、KPI分类（感知、决策、控制、系统级）

各位工程师朋友，大家好。我是老张，在ADAS领域摸爬滚打了十几年。今天咱们聊聊KPI体系总论。

说实话，我刚入行那会儿，大家对KPI这事儿挺模糊的。项目做完了，领导问「这车到底好不好用？」我们只能拍胸脯说「感觉还行」。后来吃了不少亏，才明白——没有量化指标，你根本说不清楚系统到底行不行。

2.1 什么是KPI？

KPI，全称Key Performance Indicator，关键性能指标。说白了，就是一把尺子。

你想想看，我们做ADAS系统，最终目的是让车安全、舒适、可靠地跑在路上。但「安全」怎么量？「舒适」怎么量？KPI就是把这些抽象概念，变成一个个可测量、可对比的数字。

我个人习惯把KPI分成两类：

• 结果型KPI：比如「紧急制动成功率」、「车道保持偏离次数」。这些是最终用户能感知到的。
• 过程型KPI：比如「感知延迟」、「控制指令输出频率」。这些是开发过程中用来监控系统健康度的。

举个例子。我在做AEB项目时，客户要求「不能撞车」。但「不能撞车」太模糊了。我们把它拆解成：

• 在30km/h以下，对静止车辆，制动成功率≥99%
• 在50km/h以下，对行人，制动成功率≥95%
• 误触发率≤1次/10000公里

你看，这样一拆，测试团队就知道怎么测了，算法团队也知道往哪个方向优化了。

2.2 为什么ADAS需要KPI？

这个问题，我当年也问过自己。后来在项目里摔过跟头，才真正理解。

第一，KPI是沟通的桥梁。

ADAS系统涉及感知、决策、控制、整车集成、测试验证等多个团队。没有统一的KPI，大家各说各话。感知团队说「我检测率99%」，决策团队说「我规划路径很平滑」，但合在一起，车就是跑不好。为什么？因为大家的「好」不是一个标准。

第二，KPI是迭代的指南针。

我记得有一次，我们做LKA（车道保持辅助）系统。算法团队改了一版代码，自测觉得效果不错。但上车实测，发现车辆在弯道里总是偏右。后来一查KPI，发现「横向偏差标准差」这个指标从0.15米涨到了0.22米。虽然主观感觉「还行」，但数据已经报警了。如果没有这个KPI，我们可能就把有问题的版本交付了。

第三，KPI是安全的底线。

这一点，做功能安全的同事应该深有体会。ISO 26262里要求ASIL等级，但怎么证明你的系统达到了ASIL B或ASIL D？靠的就是一系列量化的安全KPI。比如「故障检测时间」、「安全状态进入时间」等等。没有这些数字，安全就是一句空话。

2.3 KPI体系设计原则——SMART原则

设计KPI不是拍脑袋。我见过太多团队，定了一堆KPI，最后发现根本没法用。要么测不了，要么测了也没用。

这里我强烈推荐SMART原则。嗯，这五个字母，每个都有讲究。

字母	含义	ADAS中的例子	避坑指南
Specific	具体的	「前向碰撞预警的触发距离」而不是「预警要准确」	我曾经见过一个KPI叫「系统表现良好」——这没法测，赶紧改掉
Measurable	可测量的	「车道线检测距离≥50米」而不是「能检测到车道线」	注意：测量手段要可行。有些指标理论上能测，但实际测试成本极高
Achievable	可实现的	「AEB在80km/h下对静止车辆制动成功」——目前技术很难做到	我建议先定一个「跳一跳够得着」的目标，别一开始就定天方夜谭
Relevant	相关的	「ACC的跟车时距」与「用户舒适度」强相关	有些团队喜欢堆KPI，但跟系统目标无关的指标，再漂亮也没用
Time-bound	有时限的	「在Q2末，AEB误触发率降低到1次/10000公里以下」	没有时间节点的KPI，最后往往不了了之

2.4 KPI分类：感知、决策、控制、系统级

ADAS系统是个典型的「感知-决策-控制」闭环。每个环节都有自己的KPI，最后还要有系统级的KPI来兜底。

2.4.1 感知层KPI

感知层负责「看」和「听」。说白了，就是让车知道周围有什么。

• 检测率：比如「行人检测率≥98%」。注意，这里要区分不同场景（白天/夜晚、晴天/雨天）。
• 误检率：比如「每帧误检目标数≤0.1个」。误检太多，决策层会疯掉。
• 感知延迟：从传感器采集到数据输出，延迟≤100ms。这个很关键，延迟大了，决策层拿到的就是「过期信息」。
• 目标跟踪稳定性：比如「同一目标ID保持时间≥5秒」。ID频繁跳变，下游没法做稳定决策。

我记得有一次，我们用的一个感知模型，检测率很高，但ID跳变特别厉害。结果ACC系统在高速上频繁加减速，乘客晕车了。后来我们加了一个「ID保持率」的KPI，才把这个问题压下去。

2.4.2 决策层KPI

决策层负责「想」。它要决定下一步怎么走。

• 规划合理性：比如「路径曲率变化率≤0.1/m」。曲率变化太剧烈，车会「画龙」。
• 决策响应时间：从感知输入到决策输出，延迟≤50ms。
• 行为预测准确率：比如「对旁车切入意图的预测准确率≥85%」。这个很难，但很重要。
• 安全裕度：比如「规划的跟车距离≥安全距离的1.2倍」。留点余量，别卡着极限跑。

2.4.3 控制层KPI

控制层负责「动」。它把决策层的指令，变成方向盘、油门、刹车的具体动作。

• 跟踪误差：比如「横向跟踪偏差≤0.2米」。车实际走的线，跟规划线之间的差距。
• 控制响应时间：从收到指令到执行器开始动作，延迟≤20ms。
• 控制平滑度：比如「加速度变化率≤2m/s³」。加速度变化太猛，人会前仰后合。
• 稳态误差：比如「定速巡航时速度偏差≤1km/h」。跑高速时，速度忽快忽慢，谁受得了？

2.4.4 系统级KPI

系统级KPI是「总账」。它衡量的是整个系统在真实场景下的表现。

• 功能可用性：比如「ACC功能在高速场景下的可用率≥95%」。注意，这里要定义清楚「可用」的标准。
• 系统可靠性：比如「平均无故障时间（MTBF）≥1000小时」。这个需要大量路测数据。
• 用户满意度：比如「用户主观评分≥4.0/5.0」。这个虽然主观，但最终买单的是用户。
• 功能安全指标：比如「危险事件发生率≤1e-9/h」。这是ISO 26262里的硬指标。

我建议，系统级KPI不要超过5个。太多了，反而抓不住重点。而且，系统级KPI要能「分解」到感知、决策、控制层。比如「功能可用性」低，你要能定位到是感知层检测率不够，还是决策层规划不合理。

2.5 小结

好了，这一章的内容就这些。总结一下：

• KPI是把抽象需求变成可量化数字的工具
• ADAS没有KPI，就像飞机没有仪表
• 设计KPI要遵循SMART原则，尤其是「相关性」别忽略
• KPI要分层：感知、决策、控制、系统级，层层递进，互相支撑

下一章，我们会深入聊聊感知层的KPI。到时候我会分享一些具体的测试方法和踩坑经历。咱们下章见。