自动驾驶定位需求不止厘米级：精度、完好性与测试实践解析

如果有人问我，自动驾驶里最容易被低估的模块是什么，我一定会回答：定位。感知榜单被各种模型刷得很热闹，规划控制也整天在场景里炫技，可一辆车在隧道里、高架桥下、城市峡谷里能不能准确知道自己处在哪条车道，才是真正让人睡不着的工程问题。最近我给自己定了一个小项目：把一篇名为 Localization Requirements for Autonomous Vehicles 的论文从头到尾翻译成中文，并整理成可复用的需求笔记。今天这篇就想聊聊，那篇论文到底讲了什么，翻译它让我踩了哪些术语坑，以及这些指标翻译回工程语言之后，改变了我的哪些测试习惯。

1. 我为什么盯上这篇定位要求论文

1.1 从一条"让人后背发凉"的测试反馈说起

去年我在参与一个智能驾驶项目的时候，收到过一份来自某整车厂的需求文档，里面写了这样一句话：系统定位横向误差要小于 10 cm，纵向误差小于 20 cm，99.9% 以上的时间可用。

当时我盯着这个数字看了很久。10 cm 是什么概念？一辆正常行驶的车，车道宽度大多是 3.5 m 左右，10 cm 还不到车宽的十分之一。可问题在于，文档里从头到尾没有解释这个 10 cm 到底是怎么算出来的。是感知需求推出来的？是横向控制要求推出来的？还是随便拍脑袋定的？没人说清楚。

更尴尬的是，等到真去测试，我们发现车辆在空旷路段定位确实能跑到 8 cm 以内，但一到高架桥下、连续隧道、两侧都是高楼的路段，误差就会迅速变大。而且这个过程不是突然报警式的恶化，而是悄悄发生——车在导航地图上看不出任何异常，直到变道时才发现自己离车道线已经很近了。到那时候再修正，就已经让人手心冒汗了。

后来我一直在找资料，想弄明白"定位需求"到底应该怎么定义。市面上算法类论文很多，讲感知、讲融合、讲规划的都容易找到，但专门把"定位需求"当成一个工程问题来写的，确实不多。这篇 Localization Requirements for Autonomous Vehicles 就是我在这个阶段遇见的。它没有特别复杂的公式，更像是一份把系统需求、失效场景、指标定义放在一起梳理的技术文档。对我来说，这比看十篇网络结构分析都有用。

1.2 翻译这篇论文，我到底想得到什么

其实我做这个翻译项目，出发点并不是为了发表译文，也不是有人逼我交作业。原因很简单：翻译是一种最慢的阅读方式。你可以跳着读一遍论文，觉得自己懂了；但翻译的时候，你没法跳，每个词、每个分句、每个量词背后的含义都得处理干净。尤其是这种讲"需求"的论文，句子往往又长又绕，一个 shall、一个 probability、一个 under the operational design domain，翻译错了，后面的工程判断就会跟着错。

我当时定的产出物有三个：

1. 一份完整的中文翻译稿，保留原文的术语对照，不丢上下文。
2. 一份术语表，把所有反复出现的关键词统一译法，避免同一个词在一篇文档里出现三种说法。
3. 一份"可验证需求清单"，把论文里提到的每一条约束提取出来，补上验证方法和测试场景。

做完之后我发现，真正值钱的不是翻译结果，而是那个被迫逐句思考的过程。所以这篇文章不只是分享论文内容，也会把我中途走过的弯路和最后的判断逻辑写出来。如果你在做 L3/L4 相关系统、在写车辆需求文档、或者刚入门准备啃英文技术论文，应该都能从中拿到点能直接用的东西。

2. 论文里的定位需求框架：不是"越准越好"，而是"分维度约束"

2.1 至少五个维度：精度、可用性、连续性、完好性和覆盖

很多人提到高精度定位，第一反应就是"厘米级"，好像只有一个精度指标。这篇论文想矫正的恰恰就是这个印象：定位需求不是一条线，而是一个多维度的约束集合。你可以把定位系统想象成一个出租车司机。光认路准不够，你还得按时出车，行驶途中不能突然甩手不干，就算偶尔走错路也必须立刻告诉你，而不是闷头往前开。

论文里至少从五个维度来讨论需求，我在翻译时用一张表把它们的区别理清楚了：

这里面的"运行设计域"就是经常听说的 ODD，英文全称 Operational Design Domain，翻译成"运行设计域"比字面译成"操作设计域"更符合国内工程表达习惯。不要小看这个差异，需求文档里每多一个拗口术语，团队沟通就会多磨损一次。翻译时我统一用"运行设计域"，并在术语表里保留英文缩写，后面同事看代码、看测试场景时就能很快对上。

2.2 完好性为什么是最难写清楚的一条

五个维度里，精度最容易理解，可用性和连续性还比较直观，最容易被忽略也最难写清楚的其实是完好性。

完好性的核心不是"你测得准不准"，而是"当你测得不准的时候，系统知不知道自己在不准"。举个例子：如果一辆车在隧道里完全丢了卫星信号，定位模块可能会明确输出"定位失效"，这个时候系统反而知道该降级。最危险的是另一种状态——定位模块输出一个非常平滑、非常自信的轨迹，实际上已经悄悄偏离真实位置几十厘米，而且没有任何告警。这就是导航界常说的 misleading information，简单讲就是"错误信息没有触发保护机制"。它比没有信号更可怕，因为下游感知、规划、控制模块仍然会信任这个定位结果。

论文里对完好性的讨论，不是简单说"要检测错误"，而是会引出保护等级、告警时间、超限概率这些具体参数。翻译到这些段落时，我在原文旁边写了很大一个"注意"。因为很多团队做定位验收，只看平均误差和最大误差，根本不看"超限后多久能通知系统"，这是非常大的缺口。你可以接受定位精度在极端场景稍差一点，但不能接受系统在错误输出面前保持沉默。

2.3 一个真实案例：20 cm、2σ 和运行设计域

论文里必然会出现大量带概率约束的句子。比如类似这样一句：

The localization system shall provide a horizontal position error of no more than 20 cm with 95% probability within the defined operational design domain.

这句话我第一次看的时候，心里把它理解成"最大误差不超过 20 cm"。但翻译时必须停下来：原文说的是 with 95% probability，不是 all the time。也就是说，正常情况下有 95% 的概率误差小于等于 20 cm，那剩下 5% 呢？如果不另加完好性要求，这 5% 就可能是无人知晓的危险窗口。

正确的译法应该突出概率约束：定位系统应在其运行设计域内，以 95% 的概率保证水平定位误差不超过 20 cm。后面还要额外追问：5% 的超限时间里，系统能不能察觉？能给出多快的告警？告警后能不能在足够的时空距离内安全降级？这些问题放在一起才是一条完整的定位需求。翻译到这段话时我意识到，很多人文档里写的"定位精度 20 cm"，其实只抄了半句话。

3. 翻译中最容易翻车的术语战场

3.1 Localization 还是 Positioning：一个词能带偏整篇方向

做这次翻译之前，我以为术语不是大问题，反正都是中文的"定位"。真做起来才发现，"定位"在不同语境下对应的英文可以完全不同，用错一个词，整篇译文的专业方向就偏了。

Localization 在机器人、自动驾驶语境里一般翻译成"定位"，强调的是结合地图、里程计、传感器去确定自身位置。但同一个词放到软件工程里，意思是"本地化"，指把产品适配到某国语言和文化场景。拿机器翻译直接处理 Localization Requirements for Autonomous Vehicles，很容易得到"自动驾驶汽车本地化要求"，这就会让人以为论文讲的是市场本地化，完全错位。

Positioning 则更贴近 GNSS、卫星导航这类"算位置"的动作，常见用法是 GNSS positioning、positioning accuracy。它在多数场景下也可以翻译成"定位"，但如果有两个词同时出现，我会建议区分：positioning 处理成"位置解算"或"卫星定位"，localization 处理成"定位/车辆定位"。翻译一致性不仅仅是文字习惯，它直接影响工程人员能不能在一个需求评审会上迅速对齐上下文。

3.2 HD Map 不是"高清地图"，Ground Truth 也不是"事实真相"

另一个我印象很深的词是 HD Map。第一次机器直译可能会翻成"高清地图"，但这个"HD"在自动驾驶语境里是 high-definition 还是 high-precision，要特别小心。行业里普遍说的"高精地图"强调的其实是精度、图层语义和车道拓扑，而不是视觉上清不清晰。所以我的术语表里统一写：HD Map——高精地图（不建议译"高清地图"）。

还有 Ground Truth，很多人第一眼会译成"事实真相"，听着像哲学科普。它在这里的意思其实是"参考真值"，也就是作为基准的真实位置、真实轨迹。我在翻译时把它定为"参考真值"，并在第一次出现时加了脚注：指由高精度设备或其他可信手段提供的基准数据，用于评估定位误差。后面再出现就直接沿用。

Protection level 早期我译成"保护级别"，后来读到 GNSS 相关背景，发现中文里更常见的是"保护等级"或"保护水平"，英文缩写 HPL / VPL 分别对应水平保护水平和垂直保护水平。这个细节要是不改，做完好性测试的同事看到译文可能会愣一下，然后还得回去翻原文。

3.3 机器翻译的第一个坑：Localization Requirements 变成"本地化要求"

这里单独说一个我实际犯过的错。刚开始图省事，我用在线翻译直接拉了一版初稿，结果标题被翻成"自动驾驶车辆的本地化要求"，当时差点没笑出来。这个错误很典型，因为 localization 的双重含义在自动驾驶需求文档里特别容易发生。

后来我的流程调整为：机器翻译只用来帮忙理解长句结构，绝不做最终业务判断。每出现一个关键术语，必须回到上下文里再确认一次。尤其是标题、摘要、需求正文中出现的 shall、must、should，一字之差，需求强度完全不同。术语这块如果靠机翻直接定稿，轻则译文生硬，重则让一个强制性安全需求变成建议性描述，这个代价太高了。

4. 从论文指标回到工程语言：我重新看了自己的测试用例

4.1 以前测试看平均误差，现在看尾部分布

读完论文再回看项目里的测试方案，我最直观的感受是：我们的测试统计方式太"平均主义"了。

以前的做法是：让测试车跑很多圈，记录每帧定位误差，算一个 RMSE，只要这个值低于文档阈值，就认为系统满足精度要求。RMSE 是一个很典型的平均类指标，它会把大量小误差和少量大误差混在一起。假如一串误差序列是 5 cm、6 cm、4 cm、35 cm、5 cm，均方根算出来可能还不到 15 cm，但那个 35 cm 的瞬间可能已经让车辆贴近车道线了。

论文提醒我要把统计口径改成分布视角。现在我要求测试报告至少给出三档：50 百分位误差、95 百分位误差、99.9 百分位误差，并且单独记录最大误差和最大误差发生时的场景上下文。如果一项需求写的是"95% 概率误差小于 20 cm"，那么测试就要盯住 95 分位线，而不是平均值。平均误差是给汇报用的，尾部分布才是给安全判断用的。

4.2 故障注入测试：在隧道里关掉 GNSS 会怎样

除了统计口径，我还把论文里的连续性需求和完好性需求落成了一组故障注入用例。以前我们测定位，主要测"正常场景下的精度"，很少关心"某个输入源坏了之后系统还能挺多久、能不能报警"。

现在我会强制增加这些场景：

• 在隧道中段直接把 GNSS 信号关掉，观察 IMU 飘移速度和告警时间。
• 给 IMU 注入一个常值偏置，模拟传感器老化。
• 把高精地图的坐标整体平移 1 m，模拟地图版本错位。
• 给不同传感器时间戳人为加 50 ms 错位，模拟消息延迟。

第一轮测试结果其实不太好看。GNSS 断开前几秒，融合输出的轨迹还挺平滑，但因为没有运行完整性监测，估计位置开始缓慢偏离真实道路。规划模块还在按原轨迹走，等偏差累积到 30 cm 以上，系统仍然没有提示。后来我们按论文思路加了保护等级监测，在误差超过安全包络前先触发降级请求，这才踩住了危险窗口。这里真正值钱的不是某条代码，而是"故障注入 + 完好性告警"这套测试理念。

4.3 传感器融合不是加权平均，而是互相检错

很多讲多传感器融合的文章，喜欢把定位系统描述成"把 GNSS、IMU、视觉、激光雷达放在一起加权平均"。这种说法听起来很顺，但看完论文之后我越来越不同意。

加权平均的前提是参与融合的每个输入都可信。但在实际情况里，GNSS 可能因为多路径而出现平滑漂移，IMU 可能因为温度变化产生偏置，高精地图本身也可能存在图层错误。如果所有信号都往同一个方向偏，融合器算出来的依然是一个自信的错误结果。真正合格的融合系统，在做加权之前要先做一件事：一致性检查。通过残差监测、传感器健康标志、预测与观测的偏离程度，先判断哪个输入不可信，再决定要不要把它剔出融合。

论文里对这点描述得很克制，没有给太多玄乎的公式，但把它翻译成工程语言就是一句："融合系统应当先判断每个输入是否可信，再决定是否使用它，而不是无条件相信所有输入。"这也是我读完那篇论文后给团队写的评审建议的第一条。

5. 如果你也想把这类论文读透，这套流程可以照抄

5.1 先翻摘要和引言，再建术语表

很多人翻译技术论文，喜欢从头到尾顺翻，第一遍就把正文全部处理完。我自己试下来效率不高。更好的方法是先翻摘要和引言，先建立对全局的认知。摘要通常会在几句话内告诉你这篇论文解决了什么问题、用什么思路、得出什么结论，相当于提前画好地图。

第二轮再开始建术语表。把摘要和引言里反复出现的关键词挑出来，统一译法，后面翻正文就不会越翻越乱。比如我在这个项目里，第一版术语表有 30 多条，翻完正文之后扩展到 50 多条。术语表里除了"英文-中文"对照，我还会写一栏"场景说明"，简单记下这个词在哪段里出现、为什么这样译，方便以后回查。

5.2 用"shall / should / may"判断需求强度

需求类论文和算法类论文有个明显区别：它大量使用规范情态动词。英文里 shall、should、may 这三兄弟，在需求文档中的含义完全不同。

翻译时如果不管英文原文，直接按语感全部译成"要"，需求等级就糊掉了。比如 The system shall provide ... 是强制的，必须满足、必须验证；如果译成"系统可以提供……"，读出来就像可选项，下游工程师就会把它当成非功能需求，开发优先度立刻下降。我在术语表里专门加了一条规则：遇到 shall 必须译成"应"，遇到 should 译成"宜"，遇到 may 译成"可以"，并且用不同颜色在原 PDF 里高亮，方便回看需求强度。

5.3 给数字写"计算附注"

论文里出现数字时，我建议不只翻译字面意思，还在旁边补一段计算附注。比如可用性 99.5%，如果按一年 8760 小时算，理论上的失效时间上限是 43.8 小时。这个数字看起来好像很大，但实际运营时会发现，工程上要的是"受控的失效"，而不是把 43.8 小时全部集中在一个工作日。类似地，20 cm 和 95% 概率放在一起时，如果误差模型是高斯分布，可以大概反推标准差，但前提是确认误差分布真的接近高斯。GPS 一旦出现多路径、遮挡，误差分布会有明显长尾，直接反推标准差会得出过度乐观的结论。把这些计算附注写在译文旁边，别人看文档的时候一眼就知道这个指标该怎么拆。

5.4 把译文沉淀成需求评审模板

最后一步，也是这个翻译项目最大的产出：我把每一类定位约束整理成了结构化需求条目，每一条都包括需求编号、所属维度、原文约束、中文翻译、验证方式和风险备注。这样就不是一篇孤零零的译文，而是一张可以直接用于需求评审的检查表。

我甚至把这套模板用在了后来的新项目里，任何新场景进来，先对照这张表补一轮定位需求评审，省了非常多扯皮时间。最后把整理好的文档打印出来，放在团队例会桌上当讨论底稿。有人开始追着问"你这条需求里面的 2σ 是怎么来的"、"95% 和 99.9% 分别对应什么失效场景"，这种追问，比多刷十篇论文都有用。一开始我只是想翻译一篇论文，做完才发现，真正被重新校准的，是自己对"定位到底要求什么"的理解。