企业官网建设流程全解析

简介：ISO/TR 4804-2020 是国际标准化组织发布的关于道路车辆自动驾驶系统安全与网络安全的技术报告，面向自动驾驶系统工程师、功能安全与信息安全从业者以及标准法规研究人员。该 PDF 为标准原版英文文件，共 1 个文件，压缩包大小约 5.04MB，便于查阅和存档。报告系统阐述了自动驾驶系统的安全性设计、网络安全加固、验证与验证流程，并强调功能安全与信息安全的融合；具体涵盖系统架构设计、故障检测与冗余机制、通信协议加固、数据加密与访问控制，以及模拟测试、道路测试和 MIL/SIL/HIL 测试方法。同时参考了 UN R155 等法规要求，为满足全球合规提供指导。无论是进行标准合规评估、制定系统安全需求，还是开展安全分析与验证工作，均可从该报告中获得完整参考。已有 1064 人学习下载，适合需要深入理解 ISO/TR 4804 技术框架，或希望在实际项目中落地安全与网络安全要求的专业人士。

1. 自动驾驶安全的那份“总纲”级技术报告：ISO/TR 4804 到底解决什么问题

功能安全和信息安全的融合，是 L3/L4 自动驾驶项目里最容易被低估、也最容易扯皮的部分。ISO/TR 4804 是 ISO 在 2020 年底发布的一份技术报告，全名是 Road vehicles — Safety and cybersecurity for automated driving systems — Design, verification and validation，直白地说就是“自动驾驶系统怎么设计、怎么验证、怎么确认才能同时把功能安全和网络安全兜住”。它不给你“通过/不通过”的结论，但给了比标准条文更贴近工程一线的做法：从安全愿景开始，拆出自动驾驶能力，再落到系统元素、逻辑架构和验证活动。这份 PDF 特别适合三类人：正在做 L3/L4 架构和安全交付的工程师，需要对外对齐法规体系的标准专家，以及刚入行想建立安全全局观的新人。我自己的用法是把它当案头手册，遇到“三份标准怎么配合”这类争论时直接翻它。

2. 标准谱系定位：它和 ISO 26262、ISO/PAS 21448、ISO/SAE 21434 怎么分工

2.1 为什么一份“技术报告”反而值得先读

ISO 文件分几类，常见的是国际标准（IS）、技术规范（TS）和技术报告（TR）。ISO/TR 4804 属于 TR，而 TR 的定位不是给出可认证的条款，而是给出“建议、指南和方法学”。它封面里写得很清楚：Designed to supplement existing standards and publications on various aspects of safety, this document presents a more technical overview of the recommendations, guidance and methods。这句话的意思是，这份文件的目的不是替代谁，而是把散落在功能安全、预期功能安全、网络安全、甚至联合国法规里的要求，放在同一张桌上对齐。

理解这一点非常重要。我见过不少团队拿到 PDF 后直接按照“标准条款”逐条评审，结果很多地方根本评不下去，因为报告里大量篇幅是解释“为什么”和“怎么选”，而不是规定“必须怎么做”。它更像一份由行业共识凝结出来的方法论地图。作为 2020 年 12 月发布的第一版，它正好填补了 ISO 26262 第二版、ISO/PAS 21448 和 ISO/SAE 21434 在自动驾驶系统性方法上的空白，内容组织也很有层次：第 4 章讲总体方法和安全愿景，第 5 章讲如何把安全目标落到设计能力，第 6 章讲验证与确认，附录里还有开发示例、深度神经网络的使用建议和推荐标准清单。

2.2 三份核心标准的分工，以及 4804 扮演的角色

要理解 ISO/TR 4804，必须先把另外三份文件的关系理清。

ISO 26262 管的是功能安全，核心关注“电子电气系统故障导致的危害”，包括随机硬件失效、系统性失效，以及对应的安全机制和 ASIL 等级分配。ISO/PAS 21448 管的是预期功能安全（SOTIF），它的切入点是“系统没有故障，但功能表现不满足预期也可能导致危害”，比如传感器在逆光或大雨环境下性能下降、算法对罕见目标物的误识别。ISO/SAE 21434 管的是网络安全，核心是“系统被恶意攻击导致的风险”，包括威胁分析、安全监测、响应与更新机制。

问题在于，L3/L4 系统里这三类风险是同时存在、相互影响的。一个网络攻击可以导致传感器数据被篡改，进而触发功能安全问题；一个功能设计缺陷也可能被攻击者利用，导致车辆进入不安全的降级状态。ISO/TR 4804 把这三份文件统一到“避免不合理风险并实现正的风险平衡”这个总目标下，还专门讨论了最小风险条件（MRC）和最小风险操纵（MRM）、“驾驶员交互”场景下的安全验证、机器学习子系统的验证策略，这些都是其他标准没有系统展开的。

2.3 全文反复出现的四个核心概念，先看懂再往下读

读这份报告时会反复撞见几个词，建议在进入第 5 章之前先把它们钉死，不然后面会绕晕。

工程上一个常见问题是：项目组把“零事故”挂在嘴边，但到验证阶段拿不出可评估的指标。4804 的做法很务实，它先承认“技术上的绝对安全不可能”，然后用 positive risk balance 把问题转换成“你能证明比基准安全多少”。在写安全案例（safety case）时，这个转换逻辑几乎是必经之路。

3. 设计层面怎么落地：“安全愿景”拆成能力与元素的可操作路径

3.1 从 dependability 域到能力矩阵：先把系统要“会做什么”写全

ISO/TR 4804 第 5 章开头讲的不是具体功能，而是一组 dependability 域，包括安全性、网络安全、可用性、可靠性、可维护性等。它强调自动驾驶能力不是“堆功能”，而是从这些域中推导出来的可验证能力。换句话说，先别急着写传感器清单，先回答一个问题：这个系统要能在哪些条件下安全地完成哪些任务？

报告里把自动驾驶能力拆成了几大类：感知环境、解释与预测、驾驶规划、运动控制、状态监控与模式管理、人机交互、最小风险操纵、以及网络安全相关的防护能力。每类能力都同时承担功能安全和信息安全职责。举一个例子，“环境感知”这一项，功能安全关注传感器故障和降级，网络安全关注数据注入和欺骗；“解释与预测”则要同时处理算法局限和被恶意构造的对抗样本。能力矩阵排出来之后，你会发现安全需求不能只挂在单一组件上。

3.2 MRC 与 MRM：设计阶段就要写清楚“失控以后去哪儿”

ISO/TR 4804 把最小风险条件和最小风险操纵放进了能力框架里，这是很多项目拖到测试阶段才补的作业。MRC 指的是系统在无法继续原任务时可接受的安全状态，MRM 则是到达这个状态的操纵动作。工程上必须回答三个问题：什么条件触发降级（比如感知置信度低于阈值、定位丢失、V2X 失效）、触发后车辆怎么做（靠边停车、车道内停车、减速进入待援状态）、以及这个过程有没有时间预算。

从报告里能提炼出的做法是：把 MRM 当作一个普通功能来开发，而不是“异常处理补丁”。它也要有明确的触发条件、安全目标和验证场景。更关键的是，MRC 的位置选择不能只在“系统能正常定位”时有效。如果定位已经丢失，MRM 策略就不能依赖高精地图，而要依赖可用的局部感知和车辆状态。许多实路测试里的严重事故，根源都是降级策略在设计阶段没有覆盖“系统已经半盲”的情况。

3.3 逻辑架构的工程启示：先定边界，再定供应商

报告中给出了一组通用逻辑架构建议，列出的元素很有参考价值：先验信息与地图、GNSS 定位、环境感知传感器与 V2X 和融合、解释与预测、驾驶规划、运动控制、监控、ADS 模式管理器、人机交互界面与用户状态监控。每个元素都被单独讨论，在第 6 章又给出每个元素的验证要点。这套架构最大的工程价值是“边界清晰”。项目里做功能分配时，我一般会拿这份元素清单去对照，很好用。

比如定位元素，它既涉及地图数据完整性，也涉及 GNSS 信号欺骗防护，还涉及传感器融合的降级逻辑。如果团队在架构设计时没有把“定位退出”的判定职责明确归属到 ADS 模式管理器，后果就是：测试里出现定位跳变时，规划模块不知道位置不可信，整个链路还在按前一帧规划继续走，最终触发错误变道。4804 把监控和管理职责独立成元素，比传统“传感器-决策-执行”三层结构更值得借鉴。

3.4 一份能力-元素-验证的追溯表，从设计直接连到测试

很多团队做追溯时是从“需求到测试用例”的纵向链条，但在自动驾驶项目里，横向的“能力到元素”映射同样重要。下面这个追溯表是我参照 4804 的框架整理出来的，可以直接用于内部评审：

这里每个验证活动都对应原报告第 6 章的思路。做项目评审时我会要求每个能力至少有一条验证活动落到“故障注入”或“攻击注入”上，否则这条能力的安全论证是悬空的。

4. 验证与确认：五个挑战、测试平台与仿真边界

4.1 L3/L4 验证“难”在哪：第二章节列的五个挑战值得反复读

ISO/TR 4804 第 6.3 节列了五个验证挑战，是我认为全文含金量最高的部分之一。第一个挑战是统计上证明“没有驾驶员交互时仍能避免不合理风险并获得正风险平衡”。这意味着验证工作量不能只靠实路跑里程，因为极端场景出现的频率太低，纯路测在时间和成本上都不现实。第二个挑战是有驾驶员交互的系统安全，尤其是接管过程。接管不是瞬间完成的，驾驶员状态、接管时间预算、系统降级策略都要一起验证。

第三个挑战是“未知场景”。已知场景可以用需求去覆盖，但未知场景只能靠系统性探索，比如基于真实交通数据的聚类挖掘和边缘场景生成。第四个挑战是系统配置和变体的验证。同一个平台可能有多种传感器配置、不同软件版本，验证结果如何在变体间复用，报告建议用等价类和配置矩阵来管理。第五个挑战是机器学习子系统的验证，这也是 Annex B 专门讨论的主题。概括成一句话：L4 验证不完全是“测试工作”，更多是“统计论证工作”。工程上要尽早建立“仿真 + 场地 + 实路”的互补策略，而不是等实路翻车。

4.2 测试平台怎么排：MIL、SIL、HIL、场地、实路的适用层级

报告第 6.3 节对测试平台的选择有比较清晰的讨论，核心观点是要基于“被测对象”和“验证目标”来选择平台，而不是“哪个平台效果好就全用哪个”。我按项目中常见的分工整理成下表：

这里一个工程经验是高价值场景要在多个平台间“重复出现”。例如同一个紧急切入场景，先在 MIL 里做算法调参，再到 SIL 里验证生成代码一致，然后上 HIL 注入总线故障，最后到场地做一次真实车辆测试。场景参数保持一致，才能逐层确认问题在哪一层引入。

4.3 仿真别只盯着公里数：validating simulation 才是隐藏关键

报告第 6.6 节专门写了 simulation 的类型和仿真有效性验证，这一点特别容易翻车。很多团队把“仿真里程”当作安全论据，但报告强调的是：仿真结果本身也要验证。换句话说，仿真工具本身是一个“被测对象”，你用它产生的结论有多可信，取决于它在多大程度上复现了真实世界。

我一般会把仿真有效性拆成三层来检查。第一层是参数标定：传感器噪声、时延、误检率、漏检率是否来自真实数据标定，还是拍脑袋填的；第二层是场景分布：仿真场景库里的天气、道路、交通流分布是否和实际 ODD 内的数据一致；第三层是结果一致性：同一个场景在 SIL 中和在实路中的系统行为是否在关键指标上可比，比如接管请求触发时间、减速度曲线、横向偏差范围。在这三层都对齐之前，仿真里程再大都不能说明安全。

提示：如果供应商跟你说“仿真里程已经覆盖多少万公里”，先问三个问题：场景分布来自哪份真实数据？传感器模型是否经过实车数据校准？同一场景在 SIL 和实路上的关键指标偏差是多少？答不上来，这个仿真结果就只适合做相对比较，不适合做绝对安全论证。

做完三层检查之后，仿真才能真正用于“缩小实路验证范围”。这也是 4804 传达的核心态度：仿真不是实路的廉价替代品，而是把实路验证引导到高风险场景的工具。

5. 落地避坑：功能安全与信息安全融合项目的五条踩坑记录

5.1 踩坑一：把 TR 当硬性条款逐条审计

现象：内部 Audit 时安全工程师拿着 ISO/TR 4804 逐条核对研发输出，要求“这里报告说要这样，我们必须照做”，结果研发侧和功能安全侧僵持不下。

原因：TR 全称是 Technical Report，它提供的是 recommendations、guidance 和 methods，不是规范性要求。原文措辞大量使用“can”“should”而非“shall”。当硬条款用，必然和实际项目节奏冲突。

解决：把报告内容做一次“分级转换”。凡是涉及安全目标和基本原则的，吸收进公司级安全规范；凡是涉及具体方法和最佳实践的，转成内部指南；凡是只提供背景论述的，留在培训材料里。审计时依据的是转换后的内部规范，而不是直接引用 TR。

5.2 踩坑二：SIL 全绿、实路翻车，传感器模型太“美颜”

现象：同一个场景在 SIL 硅基仿真里跑得行云流水，上了 HIL 或实路就出现感知漏检，减速度激增，安全员被迫接管。

原因：传感器仿真模型过度理想化。比如把摄像头模型简化成“目标框直接输出”，没有模拟曝光延时、运动模糊、低照度噪声和误检。规划模块在 SIL 里看到的“世界”比真实世界干净得多。

解决：把传感器模型按 4804 强调的“感知元素验证”思路重做。至少要在仿真链路里注入三类退化：空间分辨率退化、时间延迟和丢帧、目标置信度扰动。做 SIL 和 HIL 的 back-to-back 对比测试，以 HIL 为基准校准 SIL，两边偏差超过阈值就回到模型层排错。

5.3 踩坑三：场景等价类划得太粗，覆盖率虚高

现象：场景库统计覆盖率 95%，但一次路测就在一个“认为已覆盖”的场景里出了事故。回头看，原因是那个场景被归入了错误的等价类。

原因：等价类划分过度依赖设计师假设。比如“白天”和“夜晚”被当作两个类，但忽略了“日出时逆光”这类更危险的光照条件。等价类的边界本身就需要验证，而不是拍脑袋定。

解决：场景库建设要引入数据驱动方式。从自然驾驶数据、交通事故事后分析、法规标准场景三条来源抽取场景参数，再做聚类，把聚类结果作为等价类划分的依据。人工划分只作为补充，不能作为唯一来源。

5.4 踩坑四：traceability 断链，审计前夜补文档

现象：阶段性评审时被要求提供“安全目标-能力-系统元素-测试用例-结果记录”的完整链条，一查发现好几个子系统只有需求文档，测试记录里的用例 ID 与需求 ID 对不上。

原因：需求管理工具、测试管理工具、问题跟踪工具各自独立，需求变更后没有同步到测试侧。AI 生成的测试用例也可能绕过了评审流程，导致 ID 体系不统一。

解决：项目启动就确定统一的追溯字段和 ID 规范，例如需求 ID 是 REQ-SAF-xxx，测试用例必须引用至少一条需求 ID。CI 构建里加一个校验脚本，检查所有测试用例的状态和结果是否能追溯到需求，查不到直接构建失败。这套机制不复杂，但比人肉追文档可靠得多。

5.5 踩坑五：拿传统安全机制硬套深度神经网络

现象：安全评审时要求对感知 DNN 的每一个输出去解释原因，否则就不给通过。团队花了几个月做可解释性，最后还是没能覆盖安全案例要求。

原因：ISO 26262 的框架是为确定性系统设计的，DNN 的行为受训练数据、网络结构、运行环境共同影响，逐条解释输出既不现实，也很难通过标准要求的评审流程。

解决：按 ISO/TR 4804 Annex B 的思路走“数据生命周期+兜底机制”路线。重点放在训练数据集的覆盖度、分布漂移监测、输入输出的异常检测，以及 DNN 失效时由传统确定性模块兜底。安全论证围绕“整个感知系统是否可控”，而不是“单个神经元是否可解释”。Annex B 里对安全相关元素的 DNN 实现给了不少可以参考的验证方法，值得逐段读。

6. 一个具体技巧：把场景库与追溯表做成团队共同语言

场景库和追溯表这两样东西，最怕的就是“各做各的”。仿真团队用一套场景编号，测试团队用另一套，安全评审时对不上。我现在的做法是在项目初始化时就定一套场景数据模板，所有工具链共用字段，字段全部用 ISO/TR 4804 的分层术语来命名。一个典型的场景条目长这样：

scenario_id: SC-ODD-HWY-0042 category: highway_cut_in road_type: multi_lane_highway weather: rain_heavy lighting: daytime_overcast dynamic_objects: - object_role: target_vehicle initial_speed_kmh: 90 cut_in_lane_distance_m: 18 trigger_time_s: 2.5 system_state: l3_engaged expected_behavior: safe_deceleration_and_takeover_request related_requirements: - REQ-SAF-PLAN-001 - REQ-CYB-PLAN-007 reviewer: safety_team

场景 ID 字段按“ODD 类别-道路类型-场景类型-序号”来编码，天气、光照、目标车动作、触发时间、预期行为全部结构化。对比试验时，仿真、场地、实路都跑同一个 ID，这样 SIL 和 HIL 的偏差可以直接定位到某一字段，比如“雨天重降水”在 SIL 里没触发降级，在 HIL 里触发了，差异就导向传感器模型的标定。

另一件事是追溯表里强制加一个字段：验证方法类别，取值只能是 SIMULATION、HIL、PROVING_GROUND、ROAD_TEST、ANALYSIS 之一。每个安全需求必须至少挂一条 ANALYSIS 类证据，防止“全用仿真证明”。从那以后，我每次启动项目都先花一天时间把场景模板和追溯表字段定下来，改动成本远比后期整理小。这个习惯救过我很多次，希望帮到你。

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