4. AUTOSAR与ISO 26262的关系
各位好，欢迎来到第四章。今天我们要聊的是AUTOSAR里三个最核心的安全机制：内存保护（MPU）、时序监控（Watchdog）和程序流监控（Program Flow Monitor）。这三个东西，说白了就是功能安全在嵌入式软件层面的“三道防线”。
我做了这么多年功能安全项目，可以负责任地告诉你：没有这三样东西，你的ASIL等级基本就是纸上谈兵。ISO 26262里对系统化的硬件随机失效、软件系统性失效都有明确要求，而这三项机制就是最直接的落地手段。
4.1 内存保护（MPU）—— 给每个任务画个圈
MPU，全称 Memory Protection Unit。它不是什么新东西，ARM Cortex-R系列、Cortex-M系列里都有硬件支持。但在AUTOSAR架构下，它的用法有讲究。
MPU的核心作用就一句话：防止一个任务把另一个任务的内存踩了。 你想想看，在混合安全等级的系统中，QM代码和ASIL D代码跑在同一个核上，如果QM代码一个野指针写到了ASIL D的变量区——嗯，后果不堪设想。
4.1.1 MPU在AUTOSAR中的配置要点
AUTOSAR的MPU配置主要在OS（操作系统）模块和Memory Mapping（内存映射）中完成。我个人习惯按以下步骤来：
- 划分安全域：根据ASIL等级，把任务分成不同安全域。比如ASIL D的任务放在一个域，QM的放在另一个域。
- 定义内存区域：每个域分配独立的代码区、数据区、堆栈区。
- 配置MPU寄存器：设置每个区域的访问权限（读/写/执行）、起始地址、大小。
- 上下文切换时更新MPU：任务切换时，OS自动更新MPU配置，确保当前任务只能访问自己的区域。
下面是一个典型的MPU区域配置表，我在项目中经常用这种表格来跟硬件团队对齐：
| 区域编号 | 起始地址 | 大小 | 权限 | 关联任务 | ASIL等级 |
|---|---|---|---|---|---|
| Region 0 | 0x2000_0000 | 64 KB | R/W/X | OS Kernel | ASIL D |
| Region 1 | 0x2001_0000 | 32 KB | R/W | BrakeControl | ASIL D |
| Region 2 | 0x2001_8000 | 16 KB | R/W | SteerControl | ASIL B |
| Region 3 | 0x2002_0000 | 128 KB | R/W/X | Infotainment | QM |
4.2 时序监控（Watchdog）—— 别让系统“死”了
Watchdog，看门狗，这名字很形象——它就像一条拴在门口的狗，你得定时去喂它（喂狗），否则它就咬人（复位系统）。
在功能安全里，Watchdog的作用是检测系统是否因为硬件或软件故障而停止正常运行。比如CPU跑飞了、任务死锁了、中断卡住了——这些情况都会导致喂狗超时，Watchdog就会触发复位或安全状态。
AUTOSAR里Watchdog的管理是通过WdgM（Watchdog Manager）模块来实现的。它比传统裸机上的看门狗要复杂得多。
4.2.1 AUTOSAR Watchdog的分层架构
AUTOSAR把Watchdog分成了三层：
- Wdg（Watchdog Driver）：最底层，直接操作硬件寄存器，负责喂狗、设置超时时间。
- WdgIf（Watchdog Interface）：抽象层，屏蔽不同硬件Watchdog的差异。
- WdgM（Watchdog Manager）：管理层，负责监控多个“被监控实体”（Supervised Entities），判断它们是否按时“报到”。
我刚开始接触AUTOSAR时，觉得这分层太啰嗦。后来发现，正是这种分层让系统可以同时监控几十个任务，每个任务有自己的超时阈值和动作策略。
4.2.2 喂狗策略与配置
WdgM支持两种监控模式：
- Alive Supervision（存活监控）：只检查被监控实体是否在指定时间窗口内至少喂狗一次。简单，但精度低。
- Deadline Supervision（截止时间监控）：检查被监控实体是否在精确的时间点喂狗。精度高，适合周期任务。
下面是一个Deadline Supervision的配置示例，我习惯用这种表格来定义每个任务的喂狗时间窗口：
| 被监控实体 | 期望周期 | 最早喂狗时间 | 最晚喂狗时间 | 超时动作 |
|---|---|---|---|---|
| BrakeControl | 10 ms | 8 ms | 12 ms | 安全复位 |
| SteerControl | 20 ms | 18 ms | 22 ms | 安全复位 |
| SensorRead | 5 ms | 4 ms | 6 ms | 错误记录 |
4.3 程序流监控（Program Flow Monitor）—— 检查代码有没有“走偏”
程序流监控，简称PFM。这个机制可能很多工程师不太熟悉，但它恰恰是ASIL C/D等级下必不可少的机制。
PFM要解决什么问题？想象一下：你的代码里有一个if-else分支，正常情况下应该走if分支。但某个硬件故障或者内存翻转导致程序计数器跳到了else分支——这就是程序流错误。MPU管不了这个，Watchdog也管不了（因为任务还在跑，还在喂狗）。这时候就需要PFM。
PFM的原理很简单：在代码的关键路径上插入“检查点”，运行时校验这些检查点是否按预期顺序执行。
4.3.1 PFM的实现方式
AUTOSAR里PFM通常有两种实现方式：
- 软件PFM：在代码中手动插入检查点变量，运行时更新变量值，然后在关键位置校验。成本低，但需要开发者手动维护。
- 硬件PFM：利用芯片自带的程序流跟踪单元（比如ARM的ETM/PTM），硬件自动监控程序执行路径。成本高，但可靠性好。
我个人更倾向于硬件PFM，因为软件PFM容易被人为疏忽。但很多项目受限于成本，只能用软件方案。
4.3.2 软件PFM的典型实现
下面是一个简单的软件PFM实现思路，我在项目里用过类似的方法：
/* 定义检查点ID */
#define CHECKPOINT_START 0xA5A5
#define CHECKPOINT_INIT 0xB5B5
#define CHECKPOINT_RUN 0xC5C5
#define CHECKPOINT_END 0xD5D5
/* 全局检查点变量 */
static uint16_t CheckpointSequence = 0;
/* 在关键路径上设置检查点 */
void SafetyFunction(void) {
CheckpointSequence = CHECKPOINT_START;
// 初始化
InitHardware();
CheckpointSequence ^= CHECKPOINT_INIT; // 异或更新
// 主逻辑
RunControlAlgorithm();
CheckpointSequence ^= CHECKPOINT_RUN;
// 结束
Cleanup();
CheckpointSequence ^= CHECKPOINT_END;
// 校验序列是否正确
if (CheckpointSequence != (CHECKPOINT_START ^ CHECKPOINT_INIT ^ CHECKPOINT_RUN ^ CHECKPOINT_END)) {
// 程序流错误，触发安全措施
SafetyErrorHandler();
}
}
4.4 三种机制的协同工作
好了，三种机制都讲完了。但我要强调一点：它们不是孤立的，而是协同工作的。
举个例子：一个ASIL D的刹车控制任务。
- MPU：确保刹车任务的内存不会被其他任务访问，防止数据被篡改。
- Watchdog：确保刹车任务在每个10ms周期内都能按时完成并喂狗，防止任务死锁。
- PFM：确保刹车任务的执行路径正确，没有因为程序计数器错误而跳过关键步骤。
这三者组合起来，才能覆盖ISO 26262对随机硬件失效和系统性失效的大部分要求。
嗯，这一章的内容就到这里。记住，安全机制不是越多越好，而是恰到好处。配置过度会影响性能，配置不足又无法通过安全认证。这个平衡点，需要你在实际项目中慢慢摸索。