4. 安全生命周期

功能安全不是一次性的“认证动作”，而是一条贯穿产品从想法到报废的安全生命周期。ISO 26262 把生命周期划分为多个阶段，每个阶段都有明确的安全活动、责任主体和交付物。对车规硬件工程师而言，理解这条链条的关键在于：上游的假设会变成下游的约束，下游的证据要能回溯到上游的目标。本节围绕概念、系统、硬件、生产运行四个阶段，梳理安全活动与交付物的对应关系。

一、概念阶段：把“危险”变成“安全目标”

概念阶段是安全生命周期的起点，核心任务是把整车层面的危险识别出来，并转化为可分配、可验证的安全目标。该阶段通常包括相关项定义、危害分析与风险评估（HARA）、安全目标制定以及功能安全概念（FSC）的初步形成。

• 相关项定义：明确被分析对象的边界、功能、接口、运行模式及与整车的交互关系。边界不清，后续所有分析都会失焦。
• HARA：通过严重度（S）、暴露率（E）、可控性（C）三个参数确定 ASIL 等级。ASIL D 为最高等级，对应最严格的安全要求。
• 安全目标：针对每个危害事件给出顶层安全目标，例如“避免在行驶中发生非预期制动”。
• 功能安全概念：把安全目标分配到整车层面的功能或外部措施，形成功能安全要求。

概念阶段的主要交付物包括：相关项定义文档、HARA 报告、安全目标清单、功能安全概念、安全计划初稿以及验证评审记录。这些文件是后续系统与硬件设计的“宪法”，任何下游变更都必须回溯到此处确认是否影响安全目标。

二、系统阶段：把安全目标拆成技术安全要求

系统阶段承接功能安全概念，将其细化为技术安全概念（TSC）和技术安全要求（TSR）。这一阶段要回答：用什么系统架构、什么安全机制、什么诊断覆盖来满足安全目标。

典型活动包括：系统架构设计、安全机制定义、FMEA/FTA 分析、安全分析验证、软硬件接口（HSI）定义以及系统集成测试策略制定。系统阶段的关键交付物有：技术安全概念、技术安全要求规范、系统架构设计说明、安全分析报告、HSI 文档、系统验证计划与报告。

三、硬件阶段：把技术安全要求落到电路与器件

硬件阶段是车规硬件工程师的主战场。它把技术安全要求分解为硬件安全要求（HSR），再通过硬件设计、器件选型、安全机制实现和验证活动，证明硬件能够满足目标 ASIL 等级。

核心活动包括：硬件安全要求分解、硬件架构设计、FMEDA（失效模式、影响及诊断分析）、诊断覆盖率评估、硬件集成测试、故障注入测试以及硬件安全论证。硬件阶段特别关注单点故障、潜伏故障和共因失效，常用指标包括 SPFM（单点故障度量）和 LFM（潜伏故障度量）。

硬件安全要求示例：
HSR-001：电源监控电路应在欠压超过 5% 时，于 10ms 内输出复位信号。
HSR-002：MCU 看门狗应具备独立时钟源，窗口超时时间 20ms ± 10%。
HSR-003：ADC 参考电压监测应覆盖开路与短路故障，诊断覆盖率 ≥ 90%。

硬件阶段交付物通常包括：硬件安全要求规范、硬件设计原理图与 BOM、FMEDA 报告、DFA（相关失效分析）报告、硬件测试报告、安全机制验证报告以及硬件安全论证文档。这些交付物是功能安全审核中审查最密集的部分。

四、生产运行阶段：让安全在量产后持续成立

很多团队把认证通过当作终点，但 ISO 26262 明确要求安全活动延伸到生产、运行、服务和报废阶段。生产阶段要确保制造过程不会引入安全相关缺陷；运行阶段要建立现场监控、故障报告、安全分析和变更管理机制。

• 生产计划：定义生产过程中的安全相关控制点、测试覆盖和追溯要求。
• 运行监控：收集现场失效数据，评估是否影响安全目标。
• 变更管理：任何硬件、软件或工艺变更都要重新评估安全影响。
• 安全论证维护：持续更新安全案例，确保其与最新状态一致。

该阶段交付物包括：生产控制计划、生产测试记录、现场监控报告、问题管理记录、变更影响分析以及安全案例更新版本。

五、四阶段安全活动与交付物对照

六、案例与复盘：一次“追溯断链”的教训

某域控制器项目在硬件阶段发现，看门狗窗口时间被设计为 30ms，而系统阶段的技术安全要求写的是 20ms ± 10%。硬件工程师认为“30ms 也能覆盖大部分故障”，但安全经理指出：该参数直接关联到安全目标“避免控制器失效导致非预期转向”，窗口时间放宽会降低故障检测的及时性。最终团队回溯到系统阶段，重新评估了故障容错时间间隔（FTTI），确认 30ms 不满足要求，硬件设计被修正。

总结来看，概念阶段定义“安全要达成什么”，系统阶段定义“系统如何达成”，硬件阶段证明“电路与器件确实达成”，生产运行阶段保证“量产后持续达成”。四个阶段通过安全要求、安全分析和安全论证三条主线串联，形成可追溯、可验证、可维护的安全生命周期。