简介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 就是这样一份不强制的报告它明确说明自己给出的是自动驾驶系统开发、验证与确认方面的指导性做法你没法拿着它去做第三方认证但它代表了一个阶段里功能安全与网络安全工程在自动驾驶领域的共识水平。维度技术报告 TR国际标准 IS文件性质指导性、信息性规范性要求条款语气多为推荐做法明确必须类条款认证用途不能直接作为认证依据可作为认证依据行业效力最佳实践基线合同或法规引用这个差异带来的直接结果是使用方式的差别。企业可以把 ISO 26262 的认证证书挂到官网但没人会认证通过 ISO TR 4804。TR 的价值更多体现在设计评审、安全案例论证和供应商技术协议里。它是你证明我们的安全论证方法不是拍脑袋时最值得引用的公开依据之一但它永远不会替你做裁决。把 TR 当成弱化版的 26262去读从第一篇就会读偏。2.2 核心内容安全原则、预期功能安全与网络安全协同设计从结构上看这份报告提出了一条从抽象安全目标到具体验证活动的推演路径。它先给出了自动驾驶系统在设计阶段应遵循的安全原则体系比如车辆始终遵守交通规则、避免碰撞、明确最小风险状态MRC与最小风险操作MRM、支持驾驶员或远程操作员接管、故障降级策略以及在感知受限时如何保守决策。每个原则都不是空话背后都对应了系统架构、传感器配置、规划算法、HMI 设计上的具体方向。新手容易把这些当成口号实际上它们是后续一切技术决策的源头。中间层是系统设计约束。报告强调安全架构要覆盖感知、预测、规划、执行和云控通信的全链路并特别关注功能能力的边界也就是 ODD。系统只能在确定的设计运行域内宣称自动化功能有效一旦超出边界怎么进入安全状态、怎么提醒驾驶员、怎么移交控制权这些都必须提前设计。这个思路在后来的准入审核中反复出现从业者读它能立刻和实际开发中的 ODD 管理、降级策略对上号。最后一大块是验证与确认VV。报告把测试手段分成仿真、受控场地测试、公共道路测试和运行阶段监控几层并讨论每一层适合验证什么、不能验证什么。这里最值得关注的是对未知未知场景的态度仿真可以用场景库覆盖已知风险道路测试可以暴露未知风险两者必须结合而不是用跑几万公里来证明安全。这套分层验证思路后来大量被国内外的行业白皮书和技术规范吸收。网络安全在这份报告里的位置很特殊。它没有被单独隔离成信息安全章节而是作为安全论证的前置条件来谈网络攻击可以改变车辆行为、篡改传感器数据、干扰决策算法因此在设计早期就要把安全与网络安全放到同一个风险条件下去分析。很多团队把 4804 读成了功能安全补充材料恰好漏掉了这个最大的差别。2.3 与 ISO 26262、ISO 21448、ISO/SAE 21434、UN R157 的关系地图和现有标准家族对比着看TR 4804 的独特位置会非常清楚。ISO 26262 解决的是电子电气系统故障导致的随机与系统性失效ISO 21448SOTIF解决的是功能在预期之外表现出的危险比如感知算法在特殊光照下的性能不足ISO/SAE 21434 负责网络安全工程的全生命周期管理。TR 4804 的定位是把这三者的输出组合到自动驾驶系统的安全论证里并且额外补上验证与确认的方法论。它不重新发明概念而是像坐标系一样把它们摆到正确位置。文件解决的核心问题与 TR 4804 的关系ISO 26262系统故障导致的失效提供底层功能安全方法4804 引用其输出ISO 21448预期功能的功能不足4804 将 SOTIF 纳入整体安全论据ISO/SAE 21434全生命周期网络安全工程4804 强调安全与网络不可分割UN R157L3 车道保持系统的法规准入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 打开后按 CtrlDMac 上在 Preview 里按 CmdI可以快速查看文档属性核对生产者与创建时间是否和官方发布信息吻合。提示页面特征只能做初步判断唯一可靠的真伪核验是拿订单号到 iso.org 账号后台反查。第三步就是反查订单登录购买账号在订单历史里核对订单编号、购买日期、产品名称。三分钟做完这套核验价值很大。行业内因为同事互传 PDF 而混入草案版、旧版的情况非常常见尤其草案文件在 2019 年到 2020 年间曾经在圈子里流传过一轮。你手里的文件如果不带 (E) 后缀或版权页缺失一旦写进安全案例评审追问出处时解释成本极高。3.3 企业多员工使用场景订阅制和个人单份买的取舍如果团队有十几个人都要读这份文件购买单份个人授权 PDF 再互相传阅实际上并不合规。正版 PDF 的许可协议通常限定个人使用企业内部共享需要额外授权。常见做法是走企业订阅它在授权范围内允许组织内员工访问标准合集配有统一管理后台文件可在线阅读和导出审计时能拿出授权覆盖证明。我见过比较稳妥的企业做法是把所有采购的标准放在一个受控的内部共享目录命名为标准库/国际标准/ISO里面除了 PDF 本体还放一份采购凭证扫描件和一份授权范围说明。这套动作做一次大概半天却能在外部审核、体系认证时省下大量解释成本。标准文档的采购建议归口到一个人或一个角色拒绝谁需要谁买的无序状态。4. 把报告落到开发流程从安全原则到核查表的工程化方法4.1 把安全原则转成原则—证据—负责人映射表TR 4804 只读一遍价值有限真正用的方式是把它改造成项目自查工具。我习惯的做法分三步。第一步通读报告把每个可操作的原则或建议提取成一个条目按安全驾驶行为 / 系统设计 / 验证与确认 / 网络安全边界四类归档。第二步为每个条目指定内部证据设计规格里的哪一节、分析报告里的哪一张表、测试报告里的哪一条用例必须明确到能拿出来见人的程度。第三步给每个条目指定负责人通常是系统架构师、功能安全工程师、网络安全工程师或验证测试负责人。下面是我在一个 L3 级项目用过的简化映射表可以直接拿去做第一版骨架TR 4804 主题分类内部证据示例负责人角色评审输出物安全驾驶行为决策规划模块的白盒测试报告规划算法负责人设计评审记录第 3.2 条最小风险状态MRM/MRC 设计说明及触发逻辑测试系统架构师安全案例章节 5.4驾驶员接管交互HMI 设计规格 台架接管试验数据HMI 工程师人因测试报告网络安全边界TARA 分析报告及缓解措施网络安全工程师网络安全评估记录提示映射表里不要出现详见 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 的每一页读懂再把它变成自己的工具。希望帮到你。本文还有配套的精品资源点击获取