1. 课程导入
各位工程师朋友，欢迎来到《AURIX汽车功能安全设计实战》的第一章。
咱们开门见山。功能安全，说白了就是「万一出错了，系统也不能伤到人」。你想想看，一辆车在高速上跑着，电子助力转向突然失灵，或者刹车系统误判——这不是闹着玩的。我入行那会儿，功能安全还是个「加分项」，现在？已经是准入门槛了。
1.1 ISO 26262 标准简介
ISO 26262，全称是「道路车辆功能安全」标准。它源自工业领域的 IEC 61508，但专门针对汽车电子电气系统做了裁剪和强化。
这个标准覆盖了从概念设计到最终报废的整个生命周期。它不关心你的代码写得有多漂亮，也不关心你的芯片算力有多强——它只关心一件事：风险是否被控制在可接受的范围内。
核心思想： 安全不是「加」上去的，而是「设计」进去的。ISO 26262 要求我们从项目一开始就把安全放在首位，而不是等产品做完了再打补丁。
标准分为 12 个部分（Part 1 ~ Part 12），其中我们最常打交道的是：
- Part 3：概念阶段（HARA、安全目标）
- Part 4：系统级开发
- Part 5：硬件级开发
- Part 6：软件级开发
- Part 8：支持流程（工具置信度、配置管理等）
- Part 9：ASIL 分解和安全分析
我个人习惯把 Part 3 到 Part 6 称为「核心开发链」，Part 8 和 Part 9 则是「支撑骨架」。做项目时，这两条线缺一不可。
1.2 ASIL 等级定义
ASIL，全称 Automotive Safety Integrity Level（汽车安全完整性等级）。它是 ISO 26262 里最出名的概念之一。
ASIL 分为四个等级：A、B、C、D。D 是最严格的，A 是最宽松的。另外还有一个 QM（Quality Management），意思是「按质量管理体系开发即可，没有额外安全要求」。
ASIL 等级是怎么定的？通过 HARA（Hazard Analysis and Risk Assessment，危害分析与风险评估）。评估三个维度：
- S（Severity）：伤害的严重程度（S0~S3）
- E（Exposure）：暴露在危险场景中的概率（E0~E4）
- C（Controllability）：驾驶员或其他人员对危险的控制能力（C0~C3）
然后查表得出 ASIL 等级：
| C | S1 | S2 | S3 |
|---|---|---|---|
| C1 | ASIL A | ASIL B | ASIL B |
| C2 | ASIL B | ASIL C | ASIL C |
| C3 | ASIL B | ASIL C | ASIL D |
我的经验： 很多新手容易把 ASIL 等级定得过高。我曾经见过一个项目，把车窗升降系统定成了 ASIL D——其实完全没必要。HARA 一定要基于真实的场景和数据，不要为了「保险」而盲目拔高等级。等级越高，开发成本是指数级增长的。
1.3 功能安全生命周期
功能安全生命周期，是 ISO 26262 的骨架。它把整个开发过程分成三个阶段：
- 概念阶段：定义项目、做 HARA、制定安全目标、功能安全概念。
- 产品开发阶段：系统、硬件、软件的设计、实现、集成、测试。
- 生产与运维阶段：生产、售后、报废。
每个阶段都有对应的输出物（Work Products）。比如概念阶段要输出 HARA 报告、安全目标、功能安全概念（FSC）。产品开发阶段要输出 技术安全概念（TSC）、硬件安全需求、软件安全需求、验证报告 等等。
嗯，这里要注意：生命周期不是一条直线走到底的。它有很多反馈回路。比如你在软件测试时发现了一个架构层面的缺陷，你得回到系统级去修改安全需求。这就是为什么 ISO 26262 强调「V 模型」开发流程。
下面这张图展示了功能安全生命周期的主要阶段和它们之间的关系：
1.4 AURIX 在功能安全中的角色
好了，前面讲的是「标准」和「流程」。现在聊聊咱们的硬件主角——AURIX。
AURIX 是英飞凌（Infineon）推出的 32 位微控制器系列，专门为汽车电子设计。它最大的卖点是什么？硬件级的功能安全支持。
说白了，AURIX 在芯片层面就内置了很多安全机制，让你做功能安全设计时能省不少力气。我举个例子：
- 锁步核（Lockstep Core）：两个 CPU 核执行同样的指令，结果实时比对。一旦不一致，立刻触发安全响应。这是实现 ASIL D 的硬件基础。
- SMU（Safety Management Unit）：安全管理单元，集中处理各种故障信号，并决定系统如何响应（复位、中断、紧急处理等）。
- ECC（Error Correction Code）：内存和总线上的纠错码，能检测并纠正单比特错误，检测双比特错误。
- MPU（Memory Protection Unit）：内存保护单元，防止不同软件模块互相干扰——这在 ASIL 分解时特别有用。
- 时钟和电源监控：内置的时钟监测和电压监测模块，确保芯片在安全状态下运行。
注意： 硬件支持只是基础，不是万能药。我曾经见过一个团队，以为用了 AURIX 就自动满足 ASIL D 了——结果审核时被打回来。硬件提供了「能力」，但「如何用」还得靠你的安全机制和软件设计。安全是系统级的，不是芯片级的。
AURIX 在功能安全中的角色，可以概括为三点：
- 提供硬件安全机制：锁步核、ECC、SMU 等，降低软件实现安全机制的复杂度。
- 支持 ASIL 分解：通过多核隔离和 MPU，可以把高 ASIL 需求分解到不同核上实现。
- 提供安全文档包：英飞凌会提供 AURIX 的安全手册（Safety Manual）和安全应用笔记，帮你理解如何正确使用这些硬件特性。
我个人习惯，在项目启动阶段就先仔细阅读 AURIX 的 Safety Manual。那里面的内容，都是英飞凌的工程师踩过坑之后总结出来的。你照着做，至少能避开 80% 的常见问题。
避坑指南： 我曾经在一个项目中，没有正确配置 SMU 的故障响应等级，导致一个本该触发复位的故障，被当成了普通中断处理——结果系统在故障状态下继续运行了 200 毫秒。嗯，200 毫秒在功能安全里，已经足够造成严重后果了。从那以后，我每次做 SMU 配置都会做三次交叉检查。
好了，第一章的内容就到这里。我们梳理了 ISO 26262 的框架、ASIL 等级的由来、功能安全生命周期的三个阶段，以及 AURIX 在其中的定位。这些概念是后续所有章节的基石，建议你花点时间消化。