ISO 26262 深度解读系列 · 系统设计篇1. 开篇一个需求翻译错误导致的召回2019 年某欧洲整车厂在量产前的最终安全评审中发现其电动转向系统EPS的 AEB自动紧急制动联动功能存在安全需求缺口。问题出在哪里不是 HARA 做错了不是 ASIL 定错了甚至不是代码写错了——是安全需求从安全目标翻译到技术安全需求的过程中遗漏了 FTTI故障容忍时间间隔的分配。具体来说HARA 阶段输出的安全目标是车辆在高速行驶时不得因转向助力丧失导致不可控ASIL 等级为 ASIL DFTTI 为 50ms。但在功能安全需求FSR编写时工程师将安全目标直译为一条技术需求——ECU 须检测转向扭矩传感器故障并在安全时间内执行安全状态——却没有将 50ms 的 FTTI 进一步分解到感知、处理、执行各环节。这导致什么后果硬件团队按照自己的理解设计了 30ms 的故障检测时间软件团队设计了 15ms 的响应时间执行器团队设计了 20ms 的动作时间。三者加起来 65ms远超 50ms 的 FTTI 总预算。更糟糕的是各团队之间没有进行端到端的时间预算对齐直到系统集成测试阶段才发现故障响应链路总延迟超标。事故后果与修复代价项目被迫在 DV设计验证阶段返工重新分配 FTTI 预算、更换更快的传感器、重写故障检测算法、调整执行器参数。整个 EPS 项目延期 6 个月涉及 3 家供应商同步修改额外开发和测试成本超过 2 亿元人民币。虽然最终在量产前修复但如果这个缺陷流入市场后果不堪设想——在高速公路上失去转向助力 65ms 而非 50ms可能意味着车辆偏移额外 2-3 米。本文核心论点安全需求不是复制粘贴而是一步步翻译和分解的过程。从 HARA 输出的安全目标出发经过功能安全概念FSC→ 功能安全需求FSR→ 技术安全概念TSC→ 技术安全需求TSR每一层都需要工程师进行翻译——将上层的安全意图转化为下层可验证、可实现的技术规格。这个翻译过程是 ISO 26262 Part 3概念阶段和 Part 4系统级产品开发的核心内容也是功能安全工程中最容易出错的环节之一。把安全需求分配比作翻译一本技术手册。安全目标是手册的核心思想用一句话概括FSR 是章节摘要每章讲什么TSC 是写作大纲用什么结构写TSR 是逐段草稿每一段写什么、怎么写。任何一层翻译出错最终手册就会失真。你不能把核心思想直接当章节摘要用也不能跳过大纲直接写草稿——每一步翻译都有其不可替代的作用。2. 概念阶段在安全生命周期中的位置在 A01 中我们介绍了 ISO 26262 的 V 模型和安全生命周期。现在让我们把镜头拉近聚焦到 V 模型的最顶端——概念阶段Concept Phase。根据 ISO 26262 的分工概念阶段主要对应 Part 3概念阶段其产出将直接输入到 Part 4系统级产品开发的后续活动中。2.1 V 模型中的 Part 3 定位回顾 A01 中的 V 模型V 模型的左上角是系统定义和需求分析这正是 Part 3 的工作范围。Part 3 的位置可以用一句话概括它是连接车辆层面的安全意图与系统层面的技术实现的桥梁。图 1ISO 26262 V 模型中 Part 3概念阶段位于左上角是安全需求翻译链的起点2.2 概念阶段的三层产出概念阶段Part 3的工作可以分为三个递进的层次层次产出物对应章节状态第一层相关项定义Item DefinitionPart 3 Clause 5已在 A01 中完成第二层危害分析与风险评估HARAPart 3 Clause 6已在 A02 中完成第三层功能安全概念FSCPart 3 Clause 7-8本章核心可以看到前两层分别在 A01 和 A02 中讨论过。本章聚焦的是第三层——功能安全概念FSC以及从 FSC 向技术安全概念TSC和技术安全需求TSR的过渡。虽然 TSC 和 TSR 严格来说属于 Part 4 的范畴但从 FSC 到 TSC/TSR 的翻译过程是概念阶段和系统级开发的交接点必须连贯理解。概念阶段的交付物清单检查在实际项目中概念阶段的交付物通常包括(1) 相关项定义文档(2) HARA 分析报告含安全目标清单(3) 功能安全概念文档含 FSR 清单(4) 安全验证报告。如果任何一个交付物缺失或不完整项目不应进入 Part 4 的系统设计阶段。3. 功能安全概念FSC的四层结构功能安全概念Functional Safety Concept, FSC是概念阶段的核心产出。在 ISO 26262 Part 3 Clause 7 中FSC 被定义为基于安全目标和 ASIL 等级对相关项功能层面安全措施的规格说明。3.1 FSC 的构成FSC 由两个核心部分组成安全目标Safety Goal, SG来自 HARA 的最高层安全需求已在 A02 中详细讨论。每个安全目标都绑定一个 ASIL 等级和 FTTI。功能安全需求Functional Safety Requirement, FSR对安全目标的细化分解定义在功能层面需要做什么来实现安全目标。FSR 是安全目标的分解产物。一个安全目标通常会被分解为多条 FSR每条 FSR 聚焦安全目标的某个特定方面。3.2 FSR 的四要素每条 FSR 必须包含以下四个基本要素要素说明示例功能描述需要执行什么安全动作当检测到转向扭矩传感器信号超范围时……安全状态达到安全后的系统状态……系统进入受限助力模式提供最大 30% 的基础助力FTTI故障容忍时间间隔……故障必须在 50ms 内被检测并响应ASIL 等级安全完整性等级ASIL D继承自父安全目标3.3 安全需求分配链的全景从安全目标到最终实现安全需求经历一条完整的分配链。这条链横跨 Part 3 和 Part 4是整个功能安全工程的骨架图 2安全目标 → FSR → TSC → TSR 分配链安全目标 (SG)HARA 输出ASIL FTTI细化FSR功能安全需求Part 3 · FSC技术化TSC技术安全概念Part 4 · 架构方案分配TSR技术安全需求Part 4 · HW/SW SRFSR 四要素功能描述 安全状态FTTI ASIL 等级TSC 内容HW 架构概要SW 架构概要 接口TSR 分配方向→ HW SR硬件需求→ SW SR软件需求ASIL 继承SG 的 ASIL 传递到 FSRTSR 的 ASIL 可通过裁剪调整双向可追溯性SG ↔ FSR ↔ TSR ↔ HW/SW 设计每层必须能追溯到上层并被下层验证图 2安全需求从安全目标到技术安全需求的四层分配链注意 ASIL 等级的继承与裁剪关系这条链的关键特征是ASIL 等级从安全目标向下传递除非通过 ASIL 分解或裁剪进行调整而FTTI 从安全目标向下分配被分解到各子系统的局部时间预算。链上的每一层都必须满足双向可追溯性——向上能追溯到安全目标向下能被设计和测试用例覆盖。4. 功能安全需求FSR编写规范FSR 是功能安全需求分配链中最关键的中间层。写得好的 FSR 能让后续的 TSC 和 TSR 编写事半功倍写得差的 FSR 则会成为整个项目的技术债务。4.1 FSR 编写的六要素模板在 A02 中我们介绍了安全目标的编写模板。FSR 的模板更加详细包含六个要素编号要素说明编写示例1FSR 编号唯一标识关联父安全目标FSR-EP-001EP EPS 项目2触发条件什么条件下此 FSR 被激活当主扭矩传感器信号超出有效范围 [min, max] 时3安全动作系统需要执行什么操作系统应切换到冗余扭矩传感器并在 20ms 内完成信号有效性验证4安全状态动作完成后系统的安全状态若冗余传感器也失效进入受限助力模式最大 30% 基础助力5FTTI从故障发生到安全状态的时间上限50ms继承自 SG-EP-0036ASIL 等级继承自父安全目标或经分解后的子 ASILASIL DFSR 编号规范建议推荐使用FSR-项目缩写-序号的格式如 FSR-EP-001、FSR-EP-002。FSR 编号应能明确追溯到其父安全目标如 SG-EP-003最好在需求管理工具中建立显式链接关系。4.2 FSR 的可验证性要求ISO 26262 对 FSR 有一条硬性要求每个 FSR 必须是可验证的。所谓可验证意味着必须能设计出至少一个测试用例来证明该 FSR 是否被满足。不可验证的 FSR 会导致一个严重的后果在系统验证阶段你无法证明安全需求已经被满足——这在功能安全评审中是一个硬伤可能导致项目被叫停。4.3 好的 FSR vs 坏的 FSR下面通过几组正反案例来展示 FSR 编写的常见陷阱场景坏的 FSR反例好的 FSR正例问题分析案例 1制动系统系统应确保制动功能安全当主制动回路压力低于 5MPa 时系统应在 30ms 内激活冗余制动回路并达到不低于 60% 的制动力反例没有量化指标、没有触发条件、没有 FTTI完全不可验证案例 2转向系统检测到故障后系统进入安全状态当转向角传感器偏差超过 5 度时ECU 应在 40ms 内切换至备用传感器并通知驾驶员通过仪表盘警告灯反例缺少故障检测阈值、FTTI、安全状态的具体定义案例 3电池管理电池管理系统应防止过充当单体电池电压超过 4.25V 时BMS 应在 100ms 内断开充电回路接触器且接触器断开响应时间不超过 50ms反例缺少电压阈值、FTTI 分解和执行器约束案例 4ADAS 感知前方碰撞预警功能必须可靠当 TLR目标最近距离小于 2.0m 且 TTC碰撞时间小于 1.5s 时系统应在 200ms 内发出 AEB 制动指令反例中可靠不可度量正例定义了精确的触发阈值和时间要求FSR 编写的SMART原则每条 FSR 都应满足 SMART 原则——Specific具体的、Measurable可度量的、Achievable可实现的、Relevant与安全目标相关的、Time-bound有明确时间约束的。如果一条 FSR 违反了其中任何一条就需要重写。5. 技术安全概念TSC从要做什么到怎么做当 FSC含安全目标和 FSR 清单完成并通过评审后工作重心从 Part 3 过渡到 Part 4。Part 4 的第一步是技术安全概念Technical Safety Concept, TSC——它回答的问题不再是功能上要做什么而是技术上怎么实现。5.1 TSC 是什么TSC 是 FSR 的技术实现方案。在 ISO 26262 Part 4 Clause 7 中TSC 被定义为在系统架构层面对实现功能安全需求的技术措施和架构选择的规格说明。如果 FSR 说的是需要检测故障并在 50ms 内响应那么 TSC 回答的就是用什么传感器检测、用什么处理器处理、用什么执行器响应、它们之间怎么通信。FSR 和 TSC 的关系就像建筑工程中的功能需求和设计方案。FSR 是甲方写的我要一栋能抗震 8 级的大楼TSC 是乙方建筑师画的采用钢筋混凝土框架结构 基础隔震系统 阻尼器的设计方案。甲方不需要通常也不应该指定用什么牌子的水泥但乙方必须证明他的方案能抗震 8 级。5.2 TSC 定义的内容TSC 文档通常包含以下核心内容内容模块说明典型交付物硬件架构概要系统的硬件组成和拓扑系统框图、关键元器件清单软件架构概要系统的软件分层和模块划分软件架构图、任务调度方案安全机制实现 FSR 所需的故障检测/处理/恢复手段安全机制清单如看门狗、ECC、冗余通道接口定义系统内部和外部接口的安全相关规格接口协议、信号范围、诊断信息格式ASIL 分配策略各子系统/元件的 ASIL 等级分配ASIL 分配矩阵FTTI 分配各环节的时间预算分配FTTI 预算表5.3 FSC 到 TSC 的翻译过程FSC 到 TSC 的翻译是一个多轮迭代的过程不是一次性完成的。典型的翻译步骤包括步骤 1FSR 聚类分析。将所有 FSR 按功能模块感知、处理、执行、通信等进行分组识别出哪些 FSR 可以由同一技术方案实现哪些需要独立的安全机制。步骤 2安全机制选型。针对每组 FSR选择合适的安全机制。例如信号合理性检查、信号冗余、定时监控、程序流监控、数据一致性检查等。步骤 3架构草案。绘制系统架构草案标注关键安全元件、安全机制和数据流。此阶段可能需要与硬件团队和软件团队反复沟通。步骤 4FTTI 分配。将每个 FSR 的 FTTI 分配到架构的各个环节传感器采集 → 信号处理 → 故障检测 → 决策 → 执行器驱动确保总和不超过 FSR 的 FTTI。步骤 5ASIL 分配。根据安全机制和架构确定各子系统/元件的 ASIL 等级应用 ASIL 分解或裁剪规则。图 3FSC 到 TSC 的五步翻译过程注意中间存在迭代循环和评审关卡6. 技术安全需求TSR分配TSC 完成并评审通过后下一步是将 TSC 转化为技术安全需求Technical Safety Requirement, TSR。TSR 是 TSC 的可验证规格也是硬件和软件开发的直接输入。6.1 TSR 的层次结构TSR 的分配遵循从系统到子系统到元件的层次结构系统级 TSR描述整个系统层面的技术安全需求直接来自 TSC 的分解。硬件安全需求HW SR分配给硬件子系统/元件的 TSR包括元器件选型、电路设计、PCB 布局等层面的安全要求。软件安全需求SW SR分配给软件模块的 TSR包括软件架构、算法、诊断、通信等层面的安全要求。TSR 的最后一公里属性TSR 是功能安全需求链的最后一公里——向下就是具体的硬件设计和代码实现。如果 TSR 写得不好硬件工程师和软件工程师就无法正确理解安全要求最终实现就会偏离安全意图。因此TSR 的编写需要系统安全工程师与 HW/SW 团队紧密协作。6.2 ASIL 裁剪ASIL TailoringASIL 裁剪是指系统级 ASIL 等级向子系统/元件分配时的合理调整。它不是任意降低 ASIL而是基于工程理由的有条件调整。裁剪场景规则说明约束条件已有安全标准覆盖如果某子系统的开发遵循已有的安全标准如 ISO 26262 Part 5/6其 ASIL 可以按该标准的最严等级执行必须证明已有标准在该 ASIL 等级下的充分性经验证的成熟元件已经通过大量量产验证的元件如已通过 ASIL D 认证的 MCU可以按照其已有认证等级使用必须确认使用环境与认证环境一致需评估使用环境差异非安全相关元件通过分析证明某元件的故障不会导致安全目标违反必须通过 FMEA/FMEDA 证明故障不影响安全且结果需经独立评审确认ASIL 分解按 Part 9 的 ASIL 分解规则将高 ASIL 分解为多个低 ASIL 的独立元素必须满足独立性要求无共因失效需 DFA 分析支撑安全机制 ASIL 不低于被保护功能安全机制如诊断、监控的 ASIL 不应低于其保护的功能的 ASIL安全机制本身的故障不应削弱被保护功能的安全性ASIL 裁剪的常见错误很多项目团队把ASIL 裁剪当成降低成本的手段——发现某个元件买不到 ASIL D 的版本就把系统的 ASIL D 需求裁剪为 ASIL B。这完全是本末倒置。ASIL 裁剪的前提是有充分的工程理由和安全分析支撑而不是因为找不到合适的元件就降级。正确的做法是如果找不到满足 ASIL D 的元件应该重新审视架构设计例如引入冗余、ASIL 分解等而不是简单地裁剪 ASIL。6.3 TSR 分配矩阵TSR 分配的结果通常用一个分配矩阵来呈现TSR 编号TSR 描述分配目标ASILFTTI父 FSRTSR-EP-HW-001主 MCU 须支持锁步模式或等效故障检测机制HW: MCU 选型ASIL D10ms检测FSR-EP-001TSR-EP-HW-002扭矩传感器 ADC 精度不低于 12-bit采样率不低于 1kHzHW: 传感器模块ASIL D2ms采样FSR-EP-001TSR-EP-SW-001扭矩信号处理算法须包含合理性检查和范围检查SW: 信号处理模块ASIL D5ms处理FSR-EP-001TSR-EP-SW-002故障管理模块须在检测到故障后 20ms 内触发安全状态转换SW: 故障管理模块ASIL D20ms响应FSR-EP-002TSR-EP-HW-003电机驱动桥须支持独立于 MCU 的硬件过流保护HW: 功率驱动ASIL B15ms执行FSR-EP-0037. 安全需求分配的工程策略在实际项目中安全需求分配不是按部就班的机械过程而是需要工程判断的策略选择。下面介绍三种常用的分配策略及其适用场景。7.1 策略一按 ASIL 等级分组将不同 ASIL 等级的需求分开管理和实现确保高 ASIL 需求的开发过程方法、工具、人员能力满足标准要求低 ASIL 需求则可以采用更轻量的流程。策略维度说明优点缺点按 ASIL 分组ASIL A/B 的需求放一组ASIL C/D 的需求放另一组分别管理降低高 ASIL 需求的开发成本避免全 ASIL D造成的过度工程需求之间的耦合关系可能导致分组困难ASIL 等级边界上的需求容易产生争议按功能模块分配传感器、处理器、执行器、通信各自承担对应的功能安全需求职责清晰便于并行开发各模块可以独立验证跨模块的需求如 FTTI 预算需要额外的协调工作按安全机制分配安全机制本身的需求独立跟踪确保安全机制的 ASIL 不低于被保护功能保证安全机制的保护能力不被削弱便于安全机制本身的验证安全机制需求数量可能很多增加管理复杂度工程实践建议大多数成熟的项目团队会综合使用以上三种策略。按 ASIL 分组用于确定开发流程的严格程度按功能模块分配用于确定各团队的工作范围按安全机制分配用于确保安全机制的完整性。三种策略的交叉使用能最大程度地覆盖所有需求分配场景。7.2 安全机制 ASIL 的守恒定律ISO 26262 中有一个重要的原则安全机制的 ASIL 不应低于其保护的功能的 ASIL。这意味着如果被保护功能的 ASIL 是 D那么监控该功能的安全机制本身也必须满足 ASIL D 的开发要求。这就像保安的安检设备必须比被保护区域的安全等级更高。你不能用一个 ASIL B 的看门狗来监控一个 ASIL D 的核心功能——如果看门狗自己先坏了谁来发现核心功能的故障7.3 三种策略的对比总结对比维度按 ASIL 分组按功能模块分配按安全机制分配首要关注点开发流程适配团队职责划分安全机制完整性适用阶段Part 4 系统设计阶段Part 4/5/6 开发阶段Part 4 安全概念阶段关键交付物ASIL 分组矩阵模块需求分配表安全机制需求清单典型项目规模所有规模中大型项目高 ASIL 项目与 FTTI 的关系间接直接各模块分摊 FTTI间接8. FTTI 分配时间预算的精算FTTIFault Tolerant Time Interval故障容忍时间间隔是安全目标的核心参数之一也是安全需求分配中最容易被忽视、最容易出错的环节。正如开篇案例所示FTTI 分配不当可能导致整个项目的返工。8.1 FTTI 从安全目标到子系统的分配方法安全目标中的 FTTI 是一个总预算需要被逐层分配到各子系统。分配方法遵循加法原则各环节的时间消耗之和不得超过总 FTTI。典型的 FTTI 分配链路FTTI_total T_detect T_process T_actuate T_marginT_detect故障检测时间传感器信号采集 诊断算法执行T_process故障处理时间故障确认 决策逻辑 安全状态选择T_actuate故障响应时间执行器动作 状态切换完成T_margin安全裕量预留 10%-20% 的缓冲时间应对系统负载波动、时序抖动等8.2 典型 ADAS 系统的 FTTI 预算分配环节子环节时间预算说明感知层T_detect传感器数据采集5ms摄像头/毫米波雷达/激光雷达数据同步感知融合处理15ms多传感器数据融合与目标检测故障诊断10ms传感器信号合理性检查、数据完整性校验处理层T_process故障确认与分类10ms多重确认机制防止误触发决策逻辑5ms安全状态选择与降级策略执行执行层T_actuate执行器驱动20ms制动执行器响应含 CAN 总线传输延迟状态确认10ms执行器状态反馈确认安全状态已达到小计75ms安全裕量T_margin, ~15%15ms应对系统负载波动、时序抖动FTTI 总预算90ms注此为示例值实际值取决于安全目标8.3 FTTI 分配的常见错误错误类型具体表现后果正确做法未考虑通信延迟FTTI 预算中只计算本地处理时间忽略了 CAN/以太网总线传输延迟端到端响应时间超标将通信延迟纳入 T_process 或 T_actuate 预算未考虑诊断周期故障检测时间的计算假设即时检测忽略了诊断算法需要多个采样周期确认故障检测时间被低估诊断周期 采样间隔 × 确认轮次安全裕量为零各环节时间预算加起来恰好等于 FTTI没有留任何裕量任何时序波动都导致 FTTI 超标预留 10%-20% 的安全裕量只给处理器分配 FTTI将全部 FTTI 预算给软件处理层传感器和执行器的时间需求被忽略传感器和执行器的选型不当各环节均衡分配每层都有明确的时间约束静态分配不更新FTTI 预算在设计初期确定后不再更新即使架构发生变更FTTI 预算与实际架构不匹配每次架构变更后必须重新验证 FTTI 预算FTTI 分配的不可能三角在 FTTI 分配中存在一个不可能三角——检测精度诊断覆盖率、响应速度FTTI、成本硬件冗余度三者不可兼得。提高诊断覆盖率通常需要更多的传感器采样时间和更复杂的算法增加 FTTI 压力缩短 FTTI 通常需要更快的硬件或更简单的算法可能降低诊断覆盖率增加硬件冗余可以提高两者但显著增加成本。工程师需要在这三者之间找到平衡点。9. 完整案例L2 ADAS 域控制器的需求分配本章通过一个完整的案例演示从安全目标到 TSR 的全流程需求分配。场景设定为一个 L2 级别的 ADAS 域控制器集成了 ACC自适应巡航、LKA车道保持辅助和 AEB自动紧急制动三个功能。9.1 步骤 1安全目标清单来自 A02 的 HARA 结果SG 编号安全目标描述ASILFTTISG-ADAS-001车辆在高速行驶时前方碰撞预警系统不得因感知失效而未能触发 AEBASIL D200msSG-ADAS-002车辆在高速公路上行驶时LKA 系统不得因转向执行失效导致车辆偏离车道ASIL B100msSG-ADAS-003ACC 系统不得因纵向控制失效导致车辆意外加速ASIL A300ms9.2 步骤 2FSCFSR 编写FSR 编号触发条件安全动作安全状态FTTIASILFSR-ADAS-001前方目标 TLR 2m 且 TTC 1.5sAEB 制动系统全制动车辆减速至停止或安全跟车距离200msDFSR-ADAS-002摄像头感知链路故障连续 3 帧无有效输出切换至毫米波雷达降级感知AEB 降级为雷达-only 模式减少碰撞工况100msDFSR-ADAS-003车道偏离角度超过 3 度且 LKA 未纠偏触发紧急转向修正车辆回到车道中心线 /- 0.3m 内100msBFSR-ADAS-004ACC 控制器发出异常加速指令禁用加速执行器车辆维持当前速度或减速300msAFSR-ADAS-005ADAS 域控制器 MCU 故障独立安全处理器接管最小风险策略通过仪表盘警示驾驶员并请求接管150msD9.3 步骤 3TSC架构设计基于上述 FSR设计如下 TSC 架构方案主处理器ASIL D 等级 SoC如英飞凌 AURIX TC4x负责感知融合和决策独立安全处理器ASIL D 等级 MCU独立于主 SoC负责监控主处理器的健康状态和最小风险策略感知冗余前向摄像头ASIL D 毫米波雷达ASIL B双传感器融合执行冗余制动系统双通道主通道 备用通道安全机制端到端信号监控、程序流监控、数据 ECC、看门狗、通信 CRC9.4 步骤 4TSR 分配硬件/软件TSR 编号描述分配目标ASILFTTITSR-ADAS-HW-001主 SoC 须支持锁步内核或等效 CPU 安全机制HW: SoC 选型D5ms诊断TSR-ADAS-HW-002前向摄像头须支持 ASIL D 数据输出和自诊断HW: 摄像头模块D30ms感知TSR-ADAS-HW-003毫米波雷达须支持信号质量自检和盲区检测HW: 雷达模块B40ms感知TSR-ADAS-SW-001感知融合算法须包含传感器信号合理性检查SW: 融合模块D20ms处理TSR-ADAS-SW-002AEB 决策算法须包含碰撞时间TTC三重冗余计算SW: 决策模块D10ms决策TSR-ADAS-SW-003故障管理模块须支持按 ASIL 等级优先级的故障处理SW: 故障管理D15ms处理TSR-ADAS-HW-004制动执行器双通道切换时间不超过 50msHW: 制动系统D50ms执行TSR-ADAS-SW-004独立安全处理器须每 10ms 周期性检查主 SoC 心跳SW: 安全监控D10ms监控9.5 步骤 5FTTI 预算以 SG-ADAS-001AEB 功能FTTI200ms为例环节时间预算累计时间负责模块摄像头数据采集15ms15msHW: 摄像头雷达数据采集10ms25msHW: 雷达感知融合处理30ms55msSW: 融合模块故障诊断与确认20ms75msSW: 故障管理AEB 决策15ms90msSW: 决策模块CAN 总线传输5ms95msHW: 通信制动执行器响应50ms145msHW: 制动系统状态反馈确认15ms160msHW: 制动系统安全裕量40ms200ms系统裕量9.6 ADAS 域控制器安全需求分配架构图图 4L2 ADAS 域控制器安全需求分配架构——从左侧的物理架构到右侧的需求映射10. 需求可追溯性从安全目标到代码的证据链ISO 26262 对安全需求的可追溯性Traceability有严格要求。所谓可追溯性是指每一条安全需求都能追溯到其来源上层需求并都能被其下层的设计和测试覆盖。10.1 需求追溯矩阵的概念需求追溯矩阵Requirements Traceability Matrix, RTM是记录需求之间关联关系的核心文档。它是一张二维表格行代表需求列代表覆盖该需求的下游产物设计、代码、测试用例。追溯矩阵就像一本家谱。安全目标是祖辈FSR 是父辈TSR 是子辈HW/SW 设计是孙辈测试用例是曾孙辈。家谱上每一行都要能向上追溯祖先、向下查找后代任何一环断了就说明血脉安全证据链有问题。10.2 双向追溯ISO 26262 要求双向追溯追溯方向含义验证方法向上追溯Forward Traceability每条设计/代码/测试都能追溯到其对应的安全需求检查是否有孤儿设计/代码/测试——即没有对应安全需求的产物向下追溯Backward Traceability每条安全需求都能被下层设计和测试覆盖检查是否有悬空需求——即没有被任何设计/代码/测试实现的安全需求追溯矩阵中的两种致命缺陷孤儿设计Orphan Design设计中包含了一些没有对应安全需求的额外功能。这些功能本身可能是正常的非安全功能也可能是错误添加的过度设计。需要区分如果是非安全相关的功能ASIL QM应在追溯矩阵中标注如果是错误添加的应删除或重新评估。悬空需求Orphan Requirement安全需求没有被任何设计/代码/测试覆盖——这意味着安全需求被遗忘了。悬空需求在安全评审中是一票否决级别的缺陷。10.3 追溯矩阵模板示例需求编号需求描述父需求设计文档代码模块测试用例状态SG-ADAS-001AEB 功能不得因感知失效而失效HARA-003ADAS-FSC-001--TC-SG-001~005已覆盖FSR-ADAS-001碰撞检测触发 AEB 全制动SG-ADAS-001ADAS-FSC-001SW-FUSION-01TC-FSR-001~003已覆盖FSR-ADAS-002摄像头故障切换至雷达降级SG-ADAS-001ADAS-FSC-002SW-FMON-02TC-FSR-004~006已覆盖TSR-ADAS-SW-001融合信号合理性检查FSR-ADAS-001ADAS-TSC-001SW-FUSION-01TC-TSR-SW-001已覆盖TSR-ADAS-SW-002TTC 三重冗余计算FSR-ADAS-001ADAS-TSC-001SW-AEB-03TC-TSR-SW-002已覆盖TSR-ADAS-HW-004制动双通道切换时间 50msFSR-ADAS-001ADAS-TSC-002HW-BRAKE-01TC-TSR-HW-004已覆盖追溯矩阵的维护原则追溯矩阵不是写完就扔的文档而是需要在整个安全生命周期中持续维护。每次需求变更、设计修改、测试用例增减都必须同步更新追溯矩阵。在功能安全评审中评审专家通常会随机抽取 3-5 条需求检查其完整的追溯链——如果发现追溯链断裂就是严重的发现项。10.4 工具支持在实际项目中安全需求的数量通常从数十条到数百条不等追溯矩阵用 Excel 维护会很快变得难以管理。因此大多数 Tier 1 和 OEM 都使用专业的需求管理工具工具厂商核心功能适用场景IBM DOORS Next GenerationIBM需求管理、追溯链接、基线管理、评审工作流大型项目ASIL D 级系统Siemens PolarionSiemens需求管理、ALM 集成、追溯矩阵自动生成中大型项目与 Simulink 集成Jama ConnectJama Software需求管理、实时协作、覆盖率分析中小型项目敏捷开发Integrity (PTC)PTC需求管理、生命周期管理、合规性追踪航空航天、汽车行业11. 常见误区在多年的功能安全评审实践中以下五个误区反复出现。每一个误区都可能导致项目返工、成本超支甚至安全隐患。误区一安全目标直接当 FSR 用这是最常见也最危险的误区。安全目标是最高层面的安全需求通常用自然语言描述如车辆不应因转向助力丧失而失控。FSR 则需要对安全目标进行细化——添加触发条件、量化阈值、安全状态定义和 FTTI 分配。错误做法直接将安全目标车辆在高速行驶时不得因感知失效而未能触发 AEB标记为 FSR-001不做任何细化。正确做法将安全目标分解为 FSR-001碰撞检测触发 AEBFTTI200ms、FSR-002感知冗余切换FTTI100ms、FSR-005域控制器 MCU 故障监控FTTI150ms等多条 FSR每条都有明确的触发条件、安全动作和安全状态。误区二TSR 分配不考虑 ASIL 裁剪规则有些项目团队在分配 TSR 时简单地一刀切——所有 TSR 都标记为安全目标的 ASIL 等级不做任何裁剪或分解。这会导致两种后果要么是过度工程低风险功能也按 ASIL D 开发成本暴增要么是ASIL 不足应该保持 ASIL D 的安全机制被降级。正确的做法是依据 Part 9 的 ASIL 分解规则和本章 6.2 节的裁剪原则对每条 TSR 进行合理的 ASIL 分配并用安全分析DFA、FMEDA 等作为支撑。误区三FTTI 只给处理器不给传感器和执行器正如开篇案例所示这种错误极其常见。很多软件工程师认为 FTTI 是软件处理时间将其全部消耗在算法和决策环节不给传感器采集和执行器响应留预算。数据说话在典型的 ADAS AEB 系统中FTTI 预算的分配比例通常是感知层占 25%-30%处理层占 25%-30%执行层占 35%-40%通信和其他占 5%-10%。如果将全部 FTTI 给处理器传感器和执行器的选型就会不当——例如选择了采样率太低的摄像头或响应太慢的制动执行器。误区四需求变更不更新追溯矩阵在项目进行过程中安全需求变更几乎是不可避免的——可能是 HARA 结果更新、可能是架构调整、可能是安全目标 FTTI 修改。每次需求变更后如果不同步更新追溯矩阵就会出现追溯链断裂导致安全评审失败。配置管理建议建立安全需求的变更控制流程Change Request每次变更必须经过安全评审批准变更后必须同步更新(1) FSC 文档(2) TSC 文档(3) TSR 分配矩阵(4) 追溯矩阵(5) 受影响的测试用例。任何一项遗漏都会在评审中被发现。误区五FSC 和 TSC 混为一谈FSC功能安全概念和 TSC技术安全概念是两个不同阶段、不同层次的产出。FSC 在 Part 3概念阶段完成回答功能层面要做什么TSC 在 Part 4系统级产品开发完成回答技术层面怎么做。对比维度FSC功能安全概念TSC技术安全概念所属 PartPart 3Part 4核心问题功能上要做什么技术上怎么做关注层面车辆/功能层面系统/E/E 架构层面是否涉及具体元件否技术无关是涉及元器件选型是否涉及具体软件否是涉及软件架构ASIL 分配继承自安全目标可进行裁剪和分解FSC 和 TSC 的区别就像合同条款和施工图纸。合同条款规定大楼必须抗震 8 级FSC施工图纸规定采用钢筋混凝土框架 隔震基础 阻尼器TSC。你不能把合同条款当施工图纸用也不能在施工图纸中偏离合同条款的要求。