如果有人问我自动驾驶里最容易被低估的模块是什么我一定会回答定位。感知榜单被各种模型刷得很热闹规划控制也整天在场景里炫技可一辆车在隧道里、高架桥下、城市峡谷里能不能准确知道自己处在哪条车道才是真正让人睡不着的工程问题。最近我给自己定了一个小项目把一篇名为 Localization Requirements for Autonomous Vehicles 的论文从头到尾翻译成中文并整理成可复用的需求笔记。今天这篇就想聊聊那篇论文到底讲了什么翻译它让我踩了哪些术语坑以及这些指标翻译回工程语言之后改变了我的哪些测试习惯。1. 我为什么盯上这篇定位要求论文1.1 从一条让人后背发凉的测试反馈说起去年我在参与一个智能驾驶项目的时候收到过一份来自某整车厂的需求文档里面写了这样一句话系统定位横向误差要小于 10 cm纵向误差小于 20 cm99.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翻译错了后面的工程判断就会跟着错。我当时定的产出物有三个一份完整的中文翻译稿保留原文的术语对照不丢上下文。一份术语表把所有反复出现的关键词统一译法避免同一个词在一篇文档里出现三种说法。一份可验证需求清单把论文里提到的每一条约束提取出来补上验证方法和测试场景。做完之后我发现真正值钱的不是翻译结果而是那个被迫逐句思考的过程。所以这篇文章不只是分享论文内容也会把我中途走过的弯路和最后的判断逻辑写出来。如果你在做 L3/L4 相关系统、在写车辆需求文档、或者刚入门准备啃英文技术论文应该都能从中拿到点能直接用的东西。2. 论文里的定位需求框架不是越准越好而是分维度约束2.1 至少五个维度精度、可用性、连续性、完好性和覆盖很多人提到高精度定位第一反应就是厘米级好像只有一个精度指标。这篇论文想矫正的恰恰就是这个印象定位需求不是一条线而是一个多维度的约束集合。你可以把定位系统想象成一个出租车司机。光认路准不够你还得按时出车行驶途中不能突然甩手不干就算偶尔走错路也必须立刻告诉你而不是闷头往前开。论文里至少从五个维度来讨论需求我在翻译时用一张表把它们的区别理清楚了维度一句话解释典型工程表达精度位置估计与真实位置的偏差有多大横向误差 ≤ 20 cm2σ可用性在运行设计域内满足精度要求的时间占比可用性 ≥ 99.5%连续性一旦开始满足要求能持续满足多久连续 15 s 指标不中断完好性误差即将超限时系统能不能及时告警保护等级 告警时间置信度/覆盖输出结果是否带可验证的统计置信区间95% 置信区间内这里面的运行设计域就是经常听说的 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 这三兄弟在需求文档中的含义完全不同。英文情态词含义建议中文译法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% 分别对应什么失效场景这种追问比多刷十篇论文都有用。一开始我只是想翻译一篇论文做完才发现真正被重新校准的是自己对定位到底要求什么的理解。