3. 功能安全开发流程与AURIX映射
ISO 26262 把功能安全从“事后检查”变成“贯穿全生命周期的工程活动”。对 AURIX 项目而言，理解这条生命周期不是为了背条款，而是为了回答三个问题：当前阶段该产出什么、这些产出如何映射到芯片资源、以及最终如何证明安全目标被满足。本节围绕安全生命周期、ASIL 等级、安全目标与技术安全需求，说明它们在 AURIX 项目中的落地方式。
一、安全生命周期：从概念到退役的闭环
ISO 26262 的安全生命周期可概括为几个相互衔接的阶段：相关项定义、危害分析与风险评估、安全目标与功能安全概念、技术安全需求与系统设计、硬件/软件开发、集成与验证、安全确认、生产运行与退役。每个阶段都有明确的输入、输出和验证活动，前一阶段的输出是后一阶段的输入，形成可追溯的链条。
在 AURIX 项目中，这条链条会具体落到芯片层面。例如“相关项定义”阶段要明确 ECU 的功能边界与 AURIX 承担的角色；“技术安全需求”阶段要把安全目标分解为对 CPU 锁步、内存保护、时钟监控、电压监控等机制的具体要求；“集成与验证”阶段则要利用 AURIX 的故障注入、错误引脚、SMU 报警等能力验证安全机制是否有效。生命周期不是文档流程，而是把安全目标逐层翻译成芯片可执行、可观测、可验证的配置。
二、ASIL 等级：决定开发严格度的标尺
ASIL 由危害事件的严重度（S）、暴露率（E）和可控性（C）共同决定，分为 A、B、C、D 四个等级，D 最严格。ASIL 等级直接影响开发要求：等级越高，对安全机制覆盖率、诊断覆盖率、验证独立性、工具置信度和文档追溯的要求越强。
在 AURIX 项目中，ASIL 等级决定了安全机制的取舍与配置强度。以 ASIL D 为例，通常要求 CPU 采用锁步核、关键存储区启用 ECC、总线与时钟具备监控、SMU 对报警做分级响应，并且安全机制自身的失效也要被覆盖。而 ASIL B 场景可能只需部分机制，或降低诊断覆盖率目标。需要强调的是，ASIL 是“分配给具体安全目标”的，不是给整颗芯片贴一个标签；同一颗 AURIX 上不同功能可以有不同的 ASIL 等级，因此安全机制配置必须按功能分别论证。
三、安全目标与技术安全需求：从“避免什么”到“怎么做”
安全目标描述的是“要避免什么危害”，例如“避免因扭矩异常输出导致非预期加速”。它通常带有 ASIL 等级、安全状态和故障容错时间间隔（FTTI）。技术安全需求则是安全目标在技术层面的展开，回答“用什么机制、达到什么指标、在什么时间内响应”。
以 AURIX 为例，一条安全目标可能分解为多条技术安全需求：CPU 需具备锁步比较能力，检测到比较错误后在 FTTI 内进入安全状态；关键 RAM 需具备 ECC，单比特错误可纠正、双比特错误可检测；SMU 需在报警触发后按预设路径驱动端口进入安全状态。这些需求必须可追溯到安全目标，并能在 AURIX 的寄存器配置、启动自检、运行时监控中找到对应实现。
四、在 AURIX 项目中落地安全计划
安全计划是把生命周期活动变成可执行任务的文件。它至少要明确：每个阶段做什么、谁负责、何时完成、依据什么标准、产出什么证据。在 AURIX 项目中，安全计划需要特别关注与芯片相关的活动节点，例如启动自检（SSM）的配置与验证、SMU 报警路径的测试、锁步核比较错误的注入验证、ECC 错误注入与响应确认。
一个可参考的落地方式是按“安全机制—验证方法—证据形式”组织计划。以锁步核为例，安全机制是 CPU 锁步比较，验证方法是通过故障注入制造比较错误，证据形式是错误被检测到并在 FTTI 内触发安全状态的记录。以 SMU 为例，安全机制是报警聚合与响应，验证方法是逐条触发报警源并观察端口动作，证据形式是报警日志与响应时间测量。这样组织后，安全计划不再是抽象条目，而是与 AURIX 具体资源一一对应的任务清单。
五、安全案例：把证据组织成可论证的结论
安全案例不是简单堆文档，而是围绕安全目标构建论证结构：安全目标是什么、分解出哪些技术安全需求、每条需求由什么机制实现、机制有效性由什么证据支撑、证据是否覆盖了 ASIL 要求的诊断覆盖率。在 AURIX 项目中，安全案例的证据主要来自三类活动：启动与周期自检结果、故障注入与错误响应测试、以及运行时监控与报警日志。
判断安全案例是否成立，关键看追溯链是否完整。如果某条技术安全需求指向“RAM ECC 覆盖双比特错误”，那么证据必须能说明 ECC 被正确配置、错误注入后确实被检测、检测后系统在 FTTI 内进入安全状态。缺少任何一环，论证就出现断点。对 ASIL D 项目，还要考虑安全机制自身的失效模式，例如 SMU 报警路径是否被监控、锁步比较器本身是否具备自检能力。
六、落地时的常见关注点
- ASIL 分配要落到功能而非整芯片：同一颗 AURIX 上不同功能可有不同 ASIL，机制配置需按功能分别论证。
- FTTI 必须可测量：从故障发生到进入安全状态的时间要在验证中实测，不能只写目标值。
- 安全机制自身也要被覆盖：锁步比较器、SMU 报警路径、时钟监控等机制需具备自检或冗余判断。
- 证据要可追溯：每条技术安全需求都应有对应的配置、测试和记录，避免出现无法闭合的论证断点。
- 工具置信度要评估：用于配置和验证 AURIX 安全机制的工具，需按 ASIL 等级评估其置信度。
把 ISO 26262 的安全生命周期映射到 AURIX，本质上是把“安全目标—技术安全需求—芯片机制—验证证据”这条链打通。安全计划负责安排这条链上的活动，安全案例负责证明这条链没有断点。对开发者而言，最实际的做法是从一条具体的安全目标出发，逐层向下追问：它分解成了哪些技术安全需求、这些需求在 AURIX 上由什么机制实现、机制是否被验证、证据是否足以支撑结论。沿着这条路径推进，功能安全开发就不再是文档负担，而是可执行、可验证的工程活动。