简介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 章之前先把它们钉死不然后面会绕晕。概念英文工程含义不合理风险unreasonable risk风险不是“零”而是“不可接受”。判断依据是社会共识层面的可接受性工程上要给出明确的量化目标和论证正风险平衡positive risk balance自动化系统不必证明绝对安全但要证明比人类驾驶或其他基准更安全。这个平衡要可度量、可评审宽容设计forgiveness系统在遇到错误输入、异常场景、甚至被误用时仍能给出安全响应而不是直接陷入失效状态安全愿景safety vision开发团队在项目早期形成的统一安全目标它把功能安全、预期功能安全和网络安全整合成一组可设计、可验证的能力工程上一个常见问题是项目组把“零事故”挂在嘴边但到验证阶段拿不出可评估的指标。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 的框架整理出来的可以直接用于内部评审能力实现元素功能安全机制网络安全机制验证活动环境感知摄像头/雷达/激光雷达融合传感器健康诊断、性能降级检测、融合一致性检查报文加密与防伪、拒绝异常数据注入仿真故障注入、HIL 场景回放、封闭场地目标物测试定位GNSS/IMU/地图匹配完好性监测、多源校验、地图一致性校验地图数据签名、GNSS 欺骗检测场地多路径场景、实路长里程统计行为规划预测与轨迹规划模块轨迹包络检查、时延监测、规划结果合理性校验参数防篡改、内部通信安全MIL/SIL 回归、HIL 随机场景压力测试降级操纵ADS 模式管理器 MRM 控制器降级触发条件监控、MRC 可达性检查降级指令的完整性保护实路安全员介入模拟、HIL 全链路演练这里每个验证活动都对应原报告第 6 章的思路。做项目评审时我会要求每个能力至少有一条验证活动落到“故障注入”或“攻击注入”上否则这条能力的安全论证是悬空的。4. 验证与确认五个挑战、测试平台与仿真边界4.1 L3/L4 验证“难”在哪第二章节列的五个挑战值得反复读ISO/TR 4804 第 6.3 节列了五个验证挑战是我认为全文含金量最高的部分之一。第一个挑战是统计上证明“没有驾驶员交互时仍能避免不合理风险并获得正风险平衡”。这意味着验证工作量不能只靠实路跑里程因为极端场景出现的频率太低纯路测在时间和成本上都不现实。第二个挑战是有驾驶员交互的系统安全尤其是接管过程。接管不是瞬间完成的驾驶员状态、接管时间预算、系统降级策略都要一起验证。第三个挑战是“未知场景”。已知场景可以用需求去覆盖但未知场景只能靠系统性探索比如基于真实交通数据的聚类挖掘和边缘场景生成。第四个挑战是系统配置和变体的验证。同一个平台可能有多种传感器配置、不同软件版本验证结果如何在变体间复用报告建议用等价类和配置矩阵来管理。第五个挑战是机器学习子系统的验证这也是 Annex B 专门讨论的主题。概括成一句话L4 验证不完全是“测试工作”更多是“统计论证工作”。工程上要尽早建立“仿真 场地 实路”的互补策略而不是等实路翻车。4.2 测试平台怎么排MIL、SIL、HIL、场地、实路的适用层级报告第 6.3 节对测试平台的选择有比较清晰的讨论核心观点是要基于“被测对象”和“验证目标”来选择平台而不是“哪个平台效果好就全用哪个”。我按项目中常见的分工整理成下表平台主要验证对象优点常见风险典型阶段MIL 模型在环控制算法、逻辑策略迭代快、可自动化、无硬件依赖模型与代码实现不一致开发初期需求变更频繁时SIL 软件在环生成代码、软件集成回归成本低、覆盖率容易做高缺少真实时序和硬件行为软件集成阶段CI 回归HIL 硬件在环控制器、总线、执行器接口时序真实、能测故障注入和总线错误传感器仿真保真度不足是最大坑硬件样件阶段故障注入专项封闭场地整车级安全响应、感知极限场景可控、可重复、安全场景空间有限、动态交通流不够真实系统集成后期实路测试长尾场景、生态表现最真实能发现未知问题成本高、不可控、统计效率低量产前阶段小批量验证这里一个工程经验是高价值场景要在多个平台间“重复出现”。例如同一个紧急切入场景先在 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 类证据防止“全用仿真证明”。从那以后我每次启动项目都先花一天时间把场景模板和追溯表字段定下来改动成本远比后期整理小。这个习惯救过我很多次希望帮到你。本文还有配套的精品资源点击获取
ISO/TR 4804：自动驾驶功能安全与网络安全融合的设计验证指南
简介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 章之前先把它们钉死不然后面会绕晕。概念英文工程含义不合理风险unreasonable risk风险不是“零”而是“不可接受”。判断依据是社会共识层面的可接受性工程上要给出明确的量化目标和论证正风险平衡positive risk balance自动化系统不必证明绝对安全但要证明比人类驾驶或其他基准更安全。这个平衡要可度量、可评审宽容设计forgiveness系统在遇到错误输入、异常场景、甚至被误用时仍能给出安全响应而不是直接陷入失效状态安全愿景safety vision开发团队在项目早期形成的统一安全目标它把功能安全、预期功能安全和网络安全整合成一组可设计、可验证的能力工程上一个常见问题是项目组把“零事故”挂在嘴边但到验证阶段拿不出可评估的指标。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 的框架整理出来的可以直接用于内部评审能力实现元素功能安全机制网络安全机制验证活动环境感知摄像头/雷达/激光雷达融合传感器健康诊断、性能降级检测、融合一致性检查报文加密与防伪、拒绝异常数据注入仿真故障注入、HIL 场景回放、封闭场地目标物测试定位GNSS/IMU/地图匹配完好性监测、多源校验、地图一致性校验地图数据签名、GNSS 欺骗检测场地多路径场景、实路长里程统计行为规划预测与轨迹规划模块轨迹包络检查、时延监测、规划结果合理性校验参数防篡改、内部通信安全MIL/SIL 回归、HIL 随机场景压力测试降级操纵ADS 模式管理器 MRM 控制器降级触发条件监控、MRC 可达性检查降级指令的完整性保护实路安全员介入模拟、HIL 全链路演练这里每个验证活动都对应原报告第 6 章的思路。做项目评审时我会要求每个能力至少有一条验证活动落到“故障注入”或“攻击注入”上否则这条能力的安全论证是悬空的。4. 验证与确认五个挑战、测试平台与仿真边界4.1 L3/L4 验证“难”在哪第二章节列的五个挑战值得反复读ISO/TR 4804 第 6.3 节列了五个验证挑战是我认为全文含金量最高的部分之一。第一个挑战是统计上证明“没有驾驶员交互时仍能避免不合理风险并获得正风险平衡”。这意味着验证工作量不能只靠实路跑里程因为极端场景出现的频率太低纯路测在时间和成本上都不现实。第二个挑战是有驾驶员交互的系统安全尤其是接管过程。接管不是瞬间完成的驾驶员状态、接管时间预算、系统降级策略都要一起验证。第三个挑战是“未知场景”。已知场景可以用需求去覆盖但未知场景只能靠系统性探索比如基于真实交通数据的聚类挖掘和边缘场景生成。第四个挑战是系统配置和变体的验证。同一个平台可能有多种传感器配置、不同软件版本验证结果如何在变体间复用报告建议用等价类和配置矩阵来管理。第五个挑战是机器学习子系统的验证这也是 Annex B 专门讨论的主题。概括成一句话L4 验证不完全是“测试工作”更多是“统计论证工作”。工程上要尽早建立“仿真 场地 实路”的互补策略而不是等实路翻车。4.2 测试平台怎么排MIL、SIL、HIL、场地、实路的适用层级报告第 6.3 节对测试平台的选择有比较清晰的讨论核心观点是要基于“被测对象”和“验证目标”来选择平台而不是“哪个平台效果好就全用哪个”。我按项目中常见的分工整理成下表平台主要验证对象优点常见风险典型阶段MIL 模型在环控制算法、逻辑策略迭代快、可自动化、无硬件依赖模型与代码实现不一致开发初期需求变更频繁时SIL 软件在环生成代码、软件集成回归成本低、覆盖率容易做高缺少真实时序和硬件行为软件集成阶段CI 回归HIL 硬件在环控制器、总线、执行器接口时序真实、能测故障注入和总线错误传感器仿真保真度不足是最大坑硬件样件阶段故障注入专项封闭场地整车级安全响应、感知极限场景可控、可重复、安全场景空间有限、动态交通流不够真实系统集成后期实路测试长尾场景、生态表现最真实能发现未知问题成本高、不可控、统计效率低量产前阶段小批量验证这里一个工程经验是高价值场景要在多个平台间“重复出现”。例如同一个紧急切入场景先在 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 类证据防止“全用仿真证明”。从那以后我每次启动项目都先花一天时间把场景模板和追溯表字段定下来改动成本远比后期整理小。这个习惯救过我很多次希望帮到你。本文还有配套的精品资源点击获取