ISO/TR 4804:2020详解：自动驾驶安全设计、验证与正版获取指南

简介：ISO/TR 4804-2020是一份聚焦道路车辆自动驾驶系统的技术报告，围绕安全与网络安全的设计、验证与验证展开，适合功能安全、信息安全及智能驾驶系统相关工程师与研究者使用。压缩包内为1份PDF文件，大小约5.04MB，内容完整保留原版英文正文，便于按条款查阅。目前已有1064人学习下载。报告不仅介绍了系统架构设计、故障检测与冗余处理、通信协议加固、数据加密与访问控制等防护思路，还结合MIL/SIL/HIL、模拟测试和实际道路测试讲解了验证与确认方法；同时，它重点协调功能安全与信息安全的关系，为落实ISO 26262、ISO/SAE 21434及UN R155等标准要求提供了可操作的参考路径。报告还强调在故障或性能下降时安全地将控制权交还驾驶员或过渡到安全状态，并建议建立贯穿生命周期的更新、维护和修复流程，以应对新出现的威胁与漏洞。对需要系统性理解自动驾驶安全标准的人来说，这是一份实用且有针对性的学习资料。

1. 自动驾驶团队反复搜索"ISO TR 4804-2020.pdf 正版"：背后的真实需求是什么

在功能安全圈，反复搜"ISO TR 4804-2020.pdf 正版"的人，往往不是缺一份 PDF，而是缺一套能把 L3 以上自动驾驶安全性讲完整的依据。2020 年 12 月发布的这份技术报告，全称是 Road vehicles — Safety and cybersecurity for automated driving systems — Design, verification and validation，它是目前少有的把功能安全、预期功能安全和网络安全放在同一张设计桌面上讨论的公开文件。对做自动驾驶系统架构、安全分析与验证的工程师来说，它既是设计阶段的参考坐标，也是评审阶段用来对齐说法的底线。这篇文章就把这份文件是什么、怎么拿正版、怎么用起来、以及最容易踩的坑拆开讲完。

2. ISO TR 4804-2020 的定位与内容框架：为什么它不是 26262 的翻版

2.1 技术报告（TR）与国际标准（IS）的制度性差异

ISO 文件体系里，TR 全称 Technical Report，是技术报告。它会被正式发布，拥有与标准同等的国际编号和版权保护，但不含强制性要求条款。真正意义上的国际标准（IS）则相反，里面有大量"shall"级别的规范性条款，可以用来做符合性认证。ISO TR 4804:2020 就是这样一份"不强制"的报告：它明确说明自己给出的是自动驾驶系统开发、验证与确认方面的指导性做法，你没法拿着它去做第三方认证，但它代表了一个阶段里功能安全与网络安全工程在自动驾驶领域的共识水平。

这个差异带来的直接结果是使用方式的差别。企业可以把 ISO 26262 的认证证书挂到官网，但没人会"认证通过 ISO TR 4804"。TR 的价值更多体现在设计评审、安全案例论证和供应商技术协议里。它是你证明"我们的安全论证方法不是拍脑袋"时最值得引用的公开依据之一，但它永远不会替你做裁决。把 TR 当成"弱化版的 26262"去读，从第一篇就会读偏。

2.2 核心内容：安全原则、预期功能安全与网络安全协同设计

从结构上看，这份报告提出了一条从抽象安全目标到具体验证活动的推演路径。它先给出了自动驾驶系统在设计阶段应遵循的安全原则体系，比如车辆始终遵守交通规则、避免碰撞、明确最小风险状态（MRC）与最小风险操作（MRM）、支持驾驶员或远程操作员接管、故障降级策略，以及在感知受限时如何保守决策。每个原则都不是空话，背后都对应了系统架构、传感器配置、规划算法、HMI 设计上的具体方向。新手容易把这些当成口号，实际上它们是后续一切技术决策的源头。

中间层是系统设计约束。报告强调安全架构要覆盖感知、预测、规划、执行和云控通信的全链路，并特别关注功能能力的边界，也就是 ODD。系统只能在确定的设计运行域内宣称自动化功能有效，一旦超出边界，怎么进入安全状态、怎么提醒驾驶员、怎么移交控制权，这些都必须提前设计。这个思路在后来的准入审核中反复出现，从业者读它能立刻和实际开发中的 ODD 管理、降级策略对上号。

最后一大块是验证与确认（V&V）。报告把测试手段分成仿真、受控场地测试、公共道路测试和运行阶段监控几层，并讨论每一层适合验证什么、不能验证什么。这里最值得关注的是对"未知未知场景"的态度：仿真可以用场景库覆盖已知风险，道路测试可以暴露未知风险，两者必须结合而不是用跑几万公里来证明安全。这套分层验证思路，后来大量被国内外的行业白皮书和技术规范吸收。

网络安全在这份报告里的位置很特殊。它没有被单独隔离成"信息安全章节"，而是作为安全论证的前置条件来谈：网络攻击可以改变车辆行为、篡改传感器数据、干扰决策算法，因此在设计早期就要把安全与网络安全放到同一个风险条件下去分析。很多团队把 4804 读成了"功能安全补充材料"，恰好漏掉了这个最大的差别。

2.3 与 ISO 26262、ISO 21448、ISO/SAE 21434、UN R157 的关系地图

和现有标准家族对比着看，TR 4804 的独特位置会非常清楚。ISO 26262 解决的是电子电气系统故障导致的随机与系统性失效；ISO 21448（SOTIF）解决的是功能在预期之外表现出的危险，比如感知算法在特殊光照下的性能不足；ISO/SAE 21434 负责网络安全工程的全生命周期管理。TR 4804 的定位是把这三者的输出组合到"自动驾驶系统的安全论证"里，并且额外补上验证与确认的方法论。它不重新发明概念，而是像坐标系一样把它们摆到正确位置。

UN R157 是另一个重要参照。R157 给出了 L3 型驾驶辅助在法定层面的准入要求，是规范性法规文件；TR 4804 的讨论范围更宽，涵盖 L3 到 L5 的框架性建议。量产项目里两者经常一起被引用：法规问"你的系统是否满足准入条款"，TR 问"你的设计、验证和确认方法是否足够体系化"。一个对应合规模板，一个对应方法学推力。

3. 正版 PDF 获取实操：四个正规渠道、三步验真与企业授权选择

3.1 四个正规购买渠道的对比与选择

获取正版 PDF 的路径比想象中清楚，核心原则就一条：只走 ISO 官网或其授权的国家标准服务机构。第一个渠道是 ISO 官方电子商店，登录 iso.org 后进入 Standards 栏目，直接搜索 ISO/TR 4804:2020，结算后下载 PDF。这里买到的一定是带许可信息的官方版本，购买记录可追溯，适合需要走采购流程的中大型企业。第二个渠道是各国标准化组织的在线商店，例如 ANSI、BSI 以及国内可对公转账的标准销售机构，它们能开本地发票、支持对公付款，对国内企业来说更容易入账。第三个渠道是 ISO 面向企业的订阅服务，按年度计费、按席位授权。第四个渠道是企业已有的标准数据库服务商，部分第三方标准服务商会打包销售标准访问权限。

渠道选择上，我一般这样判断：单次购买或个人学习，直接用官网；需要报销开票，选本地国家标准服务机构；团队超过五人且后续还要购买其他 ISO 标准，尽快评估订阅制。价格方面，单份 TR 在官网的标价通常在 100 瑞士法郎上下，约合人民币 800 元以内，具体以实时结算为准。技术报告通常比同级国际标准定价略低，但这不意味着它的权威性打折扣。

3.2 拿到 PDF 后 10 分钟验真：看文件属性、水印和订单号

我从官网下完单，拿到 PDF 第一件事不是读，而是验。第一步看封面与页脚：正式版的封面文件编号一定写作 ISO/TR 4804:2020(E)，标题是完整的 Road vehicles — Safety and cybersecurity for automated driving systems — Design, verification and validation。如果看到文件名里有"DTR"、"CD"或"working draft"，那些都是草案阶段产物，不是正式版。第二步看版权页：正式版在前几页会有完整的版权声明和官网信息，很多官方 PDF 在页面边缘或文档属性里嵌有购买方名称与订单号；用 Adobe Acrobat 打开后按 Ctrl+D，Mac 上在 Preview 里按 Cmd+I，可以快速查看文档属性，核对生产者与创建时间是否和官方发布信息吻合。

提示：页面特征只能做初步判断，唯一可靠的真伪核验是拿订单号到 iso.org 账号后台反查。

第三步就是反查订单：登录购买账号，在订单历史里核对订单编号、购买日期、产品名称。三分钟做完这套核验，价值很大。行业内因为同事互传 PDF 而混入草案版、旧版的情况非常常见，尤其草案文件在 2019 年到 2020 年间曾经在圈子里流传过一轮。你手里的文件如果不带 (E) 后缀或版权页缺失，一旦写进安全案例，评审追问出处时解释成本极高。

3.3 企业多员工使用场景：订阅制和个人单份买的取舍

如果团队有十几个人都要读这份文件，购买单份个人授权 PDF 再互相传阅，实际上并不合规。正版 PDF 的许可协议通常限定个人使用，企业内部共享需要额外授权。常见做法是走企业订阅：它在授权范围内允许组织内员工访问标准合集，配有统一管理后台，文件可在线阅读和导出，审计时能拿出授权覆盖证明。

我见过比较稳妥的企业做法，是把所有采购的标准放在一个受控的内部共享目录，命名为"标准库/国际标准/ISO"，里面除了 PDF 本体，还放一份采购凭证扫描件和一份授权范围说明。这套动作做一次大概半天，却能在外部审核、体系认证时省下大量解释成本。标准文档的采购建议归口到一个人或一个角色，拒绝"谁需要谁买"的无序状态。

4. 把报告落到开发流程：从安全原则到核查表的工程化方法

4.1 把安全原则转成"原则—证据—负责人"映射表

TR 4804 只读一遍价值有限，真正用的方式是把它改造成项目自查工具。我习惯的做法分三步。第一步，通读报告，把每个可操作的原则或建议提取成一个条目，按"安全驾驶行为 / 系统设计 / 验证与确认 / 网络安全边界"四类归档。第二步，为每个条目指定内部证据：设计规格里的哪一节、分析报告里的哪一张表、测试报告里的哪一条用例，必须明确到能拿出来见人的程度。第三步，给每个条目指定负责人，通常是系统架构师、功能安全工程师、网络安全工程师或验证测试负责人。

下面是我在一个 L3 级项目用过的简化映射表，可以直接拿去做第一版骨架：

提示：映射表里不要出现"详见 XX 报告"这类不含版本号的模糊引用，证据文件必须带编号和版本。

这张表的作用有两层。对内，它让安全设计不再是散落在公司各处的零散文档，而是一张可追踪、可评审的总图；对外，当客户或监管方问"你们怎么参照 TR 4804"时，你可以直接给出条目级别的对应关系，而不是一句"我们按行业最佳实践来的"。

4.2 基于场景的验证矩阵：仿真、封测场地、开放道路三层怎么排

验证这一块是 TR 4804 里被讨论最多的部分，也是最容易走偏的部分。报告的态度很明确：没有单一方法能验证自动驾驶安全性，必须分层组合，每一层都要有明确目标和统计口径。实际排验证矩阵时，第一步先把 ODD 里的维度列全：道路类型、气候条件、交通参与者类型、速度区间、基础设施质量。第二步把每一层验证的目标说清楚，而不是笼统写"做测试"。

第一层仿真，适合覆盖大量已知场景和参数化扰动，例如在 ODD 边界附近把光照、雨雾、交通密度做参数扫描。关注的指标通常是场景通过率、碰撞率、TTC（碰撞时间）小于阈值的次数、以及 MRM 激活次数的分布。第二层封测场地，适合做高危险但在公开道路不允许出现的工况，例如前车急刹、行人横穿、传感器极端遮挡，重点是可重复性和测量精度。第三层公共道路测试，它不能作为主要安全证据，更多是暴露未知未知场景，并采集真实工况数据供仿真复现。

每个场景都要挂上量化通过标准。我一般在仿真层写"雨天高速场景，车道保持偏移不超过 0.3 米"；在场地层写"受控行人穿行场景，制动后与行人净距不小于 1.5 米"。TR 4804 本身没有给具体阈值，这些数字来自项目风险评估和安全目标分解，但把每个场景都配上量化标准，是评审时最有说服力的做法。参数怎么定，可以参考同类系统的公开事故数据和法规要求，再留出工程余量。

4.3 从 TR 到内部流程文件：版本管理与可追溯性

工程上最怕的不是没有标准，而是标准引用得含糊。流程文件里必须把版本写全：ISO/TR 4804:2020，而不是只写"ISO TR 4804"。正式版目前是 2020 年 12 月的这一版，后续如果有替代它的正式标准发布，企业需要做差异分析并更新映射表，这是标准落地最容易被忽视的一步。

可追溯性方面，公司如果已经用了 Polarion、DOORS 这类需求管理工具，就把映射表的"原则条目"建成正式需求源，链接到下游设计文档和测试用例。没有工具时用表格也能跑，但有三件事必须做到：单元格里写证据文件的编号和版本，而不是"详见 XX 报告"；每次设计评审前检查映射表里所有证据文件是否过期；换项目时复制骨架但不要复制证据，因为不同车型的架构与风险完全不同。借用别人的证据文件，是评审现场最容易被识破的偷懒方式。

5. 避坑重灾区：围绕这份文档最容易翻车的 5 个现场

标准文档的坑往往不在文档本身，而在文件流传、等级误判和适用范围三个环节。下面五条都是从业者圈子里反复出现的问题，每条按现场现象、背后原因、处理方式来说明。

5.1 手上是 DTR 草案，却当成正式出版版引用

现象：评审会上有人投影"ISO TR 4804"的某一页，内容是对的，但屏幕角落的文件标题上印着 ISO/DTR 4804。问版本号，回答"就是这版啊"。如果不较真，整份安全文档的证据链就从根上松了。

原因：2019 年到 2020 年间，这份报告经历了委员会草案和最终草案等阶段，草案文件通过项目合作、供应商交流在产业链里流传过。草案与正式版的核心表述可能有差异，引用时根本无法定位到正式版的对应段落。

解决：拿到文件立刻看封面文件编号，正式版的正确写法是 ISO/TR 4804:2020(E)，多一个字母少一个年份都不行。内部标准库只允许管理员上传经过三步验真的版本，草案文件放在单独目录，文件名前加"draft-not-for-citation"标记。所有引用统一走标准库链接，不接收个人本地文件。

5.2 拿 TR 的建议做法去做符合性声明

现象：供应商技术方案里白纸黑字写着"符合 ISO/TR 4804 的安全要求"，但问到具体条款却只能绕回"我们有自己的安全体系"。合同评审时风险很大。

原因：TR 全称就是技术报告，里面的表述大量属于推荐层面，不是"必须"级别的规范。很多人把"我们参照了"写成了"我们符合"，在一个法律与工程都看文字准确性的行业里是硬伤。

解决：投标与协议文本统一使用"依据 ISO/TR 4804:2020 的推荐做法，我们建立了……"句式，把内部映射表作为附件，按条目摆出对应证据。对外口径上，TR 4804 是论证的参考坐标系，不是认证的准绳；真要符合性声明，去看 UN R157 或项目目标市场对应的正式法规。

5.3 只看安全分析，跳过网络安全章节

现象：某 L4 园区项目做了完整的故障模式分析、安全分析和 SOTIF 分析，却在一次安全测试中发现，攻击者通过远程接口篡改感知数据后，MRM 触发逻辑完全没有考虑"感知结果被篡改"这条路径，车辆在错误的位置执行了靠边停车。

原因：团队按传统功能安全习惯分章节阅读，把网络安全视为独立专业，忽略了 TR 4804 开篇就强调的原则：安全与网络安全是一体化设计，攻击路径本身就是安全失效模式的一种输入。

解决：把映射表里的"网络安全边界"设为强制门禁项，网络安全工程师在每次设计评审中必须签字确认"本次变更是否影响安全论据，若影响，对应攻击路径是否已更新"。我还会把威胁分析中和车辆动态控制相关的攻击路径单独拉一张表，与 MRM、降级策略做交叉验证。这个动作成本不高，但救过不少次评审。

5.4 内部流传的 PDF 与授权范围不符

现象：外部审核时需要出示 TR 4804 的采购凭证，公司买过 3 个席位，工程师电脑里却躺着 15 份同文件拷贝，最后只能以"已清理"作数，狼狈程度不言而喻。

原因：单用户授权的 PDF 被当作部门共享资料在整个团队传播，采购环节没有评估使用人数，也没有把授权管理交给专人。

解决：第一步盘点内部所有拷贝，只保留有授权凭证的版本，其余从共享目录移除。第二步在采购流程里增加"授权范围"字段，明确单用户还是团队订阅，把订单号、授权人数、有效期存档。标准采购统一归口到一个角色，这件事看起来是流程形式主义，但在审计场景里，它是唯一能让文件合法留在公司电脑上的依据。

5.5 适用范围判断失误：L2+ 项目硬套 L3 验证要求

现象：某 L2+ 高速领航项目直接照搬 TR 4804 中的接管时间测试方法，结果系统根本不允许驾驶员长时间脱离方向盘，测试人员在封闭场地反复演练"无意义的接管"。设计文档里堆了一堆用不上的 MRM 章节，测试成本和评审噪音都上去了。

原因：TR 4804 讨论的高阶自动化有明确的驾驶员不在环或间歇在环前提，MRM、接管、最小风险状态这些概念都建立在这个前提上。L2+ 系统驾驶员全程在环，设计目标完全不同。

解决：项目启动会上用"自动化等级 + ODD + 驾驶员职责 + 目标市场法规"四个维度做适用范围判断，在安全计划里写清楚 TR 4804 是"主依据"还是"背景参考"。如果目标是 L2+，重点提取报告中的设计原则与验证方法论，而不是把 MRM 与接管测试原样搬进需求。

6. 用 TR 4804 去审供应商方案：值得问的四个角度

当供应商带着自动驾驶方案过来做技术交流时，TR 4804 可以变成你的提问框架。我一般只问四个问题。

第一，你们的场景库覆盖了哪些 ODD 边界条件？请给一张场景分类表，标明仿真、场地、道路测试各自覆盖了多少已知风险场景，以及它们与 TR 4804 安全原则的映射关系。第二，你们的 MRM 触发条件和执行顺序是什么？能不能现场讲清楚从感知异常到进入最小风险状态的完整决策链，以及每个环节的量化阈值。第三，验证与确认的覆盖率是怎么计算的？别只说跑了多少公里，要看 ODD 边界处的参数化覆盖是否充分，以及未知未知场景由哪一层测试来承担。第四，功能安全与网络安全的接口是谁在管理？如果对方回答"两个团队各做各的"，这个隐患比任何算法问题都值得警惕。

这四个问题问完，供应商是真的做过体系化安全工程，还是停留在演示车水平，脉络会非常清楚。我自己养成的习惯，是把 TR 4804 的目录结构同步到团队知识库的安全板块，每一次设计评审都指着里面某一条问"这一条你们的证据在哪"。用不了几次，团队的安全文档质量会有肉眼可见的变化。标准文件本身不生产安全，但它给了所有人一个精确对齐的坐标系，值得花一晚上把正版 PDF 的每一页读懂，再把它变成自己的工具。希望帮到你。

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