1. 课程导论与法规全景：ISO 26262与ASPICE对日志监控的要求概述
1.1 为什么日志监控成了“硬骨头”？
各位工程师朋友，咱们开门见山。做车规级嵌入式开发这些年，我见过太多项目在日志监控上栽跟头。说白了，日志不就是printf加个时间戳吗？嗯，如果你真这么想，那后面有得苦头吃。
我2018年参与过一个ADAS域控制器的项目。当时团队觉得日志嘛，能打印出来就行。结果到了功能安全审核阶段，审核员问了一句：“你们怎么证明日志系统本身不会失效？”全场鸦雀无声。那一次，我们整整返工了三个月。
为什么会这样？因为车规级日志监控，它不是一个“功能”，而是一个“安全机制”。你想想看，如果系统出了故障，日志却丢了或者被覆盖了，你怎么做根因分析？如果日志系统本身占用了过多CPU，导致安全任务超时，谁来负责？
所以，今天这堂课，咱们就把ISO 26262和ASPICE对日志监控的要求彻底捋清楚。
1.2 ISO 26262：日志监控的“安全底线”
ISO 26262，做汽车电子的没人不知道。但很多人只关注功能安全目标、安全状态，却忽略了日志监控这个“小角色”。
我个人习惯把ISO 26262对日志的要求归纳为三个层次：
- 第一层：日志作为安全证据——你得能证明系统在运行期间的行为是符合预期的。说白了，出了事故要能追溯。
- 第二层：日志系统本身的可靠性——日志系统不能成为单点故障。我曾经见过一个项目，日志缓冲区满了就直接死机，这显然不行。
- 第三层：日志与安全机制的交互——比如，当系统检测到故障时，日志系统要能及时记录故障发生前后的上下文。
核心要点：ISO 26262-6（产品开发：软件层面）明确要求，软件单元的设计必须考虑“错误检测与错误处理机制”。日志监控，本质上就是一种错误检测机制。
具体到ASIL等级，要求也不一样。我整理了一个表格，大家参考：
| ASIL等级 | 日志监控要求 | 典型实现方式 |
|---|---|---|
| ASIL A | 基本日志记录，无冗余要求 | 单缓冲区，简单轮转 |
| ASIL B | 日志完整性校验，防止篡改 | CRC校验，写保护 |
| ASIL C | 日志系统故障检测与恢复 | 看门狗监控，双缓冲区 |
| ASIL D | 完全独立的日志通道，故障容错 | 硬件日志模块，ECC保护 |
注意：千万别以为ASIL A就可以随便写日志。我见过一个ASIL B的项目，因为日志系统用了动态内存分配，导致安全审核直接不通过。ISO 26262对动态行为有严格限制，日志系统也不例外。
1.3 ASPICE：日志监控的“过程约束”
如果说ISO 26262是告诉你“要做什么”，那ASPICE就是告诉你“怎么做”。ASPICE对日志监控的要求，主要体现在软件详细设计和单元测试阶段。
我记得有一次做ASPICE Level 2的认证，审核员翻着我们的日志模块设计文档，问了一个很刁钻的问题：“你们怎么保证日志模块的代码覆盖率达到了MC/DC？”
嗯，这个问题问得好。ASPICE的SWE.6（软件单元验证）要求，所有软件单元必须进行结构覆盖测试。日志模块虽然看起来简单，但它的分支逻辑——比如缓冲区满时的处理、不同日志级别的过滤——这些都需要覆盖到。
我给大家总结一下ASPICE对日志监控的几个关键要求：
- SWE.2（软件架构设计）：日志模块的接口必须明确定义，不能有隐藏的全局依赖。
- SWE.3（软件详细设计）：日志的缓冲区大小、轮转策略、优先级策略，都要有详细的设计说明。
- SWE.4（软件单元实现）：日志代码必须遵循MISRA C规范，不能使用标准库中的printf等函数。
- SWE.6（软件单元验证）：日志模块的单元测试覆盖率必须达标，包括分支覆盖和MC/DC覆盖。
一个小技巧：做ASPICE审核时，日志模块的测试用例最好单独列出来。我曾经把日志测试混在功能测试里，结果审核员说“看不清楚”，让我重新整理。后来我学乖了，日志测试独立成章，审核一次过。
1.4 两者的关系：不是二选一，是双重要求
很多工程师问我：“ISO 26262和ASPICE，到底听谁的？”我的回答是：两个都得听，而且它们不冲突。
ISO 26262关注的是“安全完整性”，它要求日志系统本身不能降低系统的安全等级。ASPICE关注的是“过程质量”，它要求日志系统的开发过程是可追溯、可验证的。
说白了，ISO 26262是“结果导向”，ASPICE是“过程导向”。你既要保证日志系统不出错，又要证明你的开发过程是规范的。
我画了一张图，帮大家理清这个关系：
1.5 日志监控的常见“坑”
做了这么多年，我踩过的坑不少。今天分享几个典型的，大家引以为戒：
- 日志缓冲区溢出导致系统崩溃——我曾经在一个项目中，日志缓冲区满了之后直接触发断言，导致系统复位。这在功能安全审核中是绝对不允许的。正确的做法是：缓冲区满时丢弃旧日志，或者采用环形缓冲区。
- 日志写入影响实时性——有个项目，日志写入用了阻塞式I/O，结果导致安全任务超时。后来我们改用DMA+双缓冲，才解决了问题。
- 日志内容泄露敏感信息——ISO 26262要求保护安全相关的数据。如果你在日志里打印了密钥或者安全算法参数，那审核员会直接亮红灯。
- 日志系统没有独立的故障检测——如果日志系统本身坏了，你怎么知道？我曾经建议在日志模块中加入心跳机制，让系统监控日志模块是否正常工作。
避坑指南：我曾经在一个项目中，日志模块用了全局变量来存储缓冲区状态。结果在中断上下文和任务上下文中同时访问，导致了数据竞争。后来我们加上了互斥锁，但性能又下降了。最终方案是：用无锁环形缓冲区，配合原子操作。这个方案后来成了我们团队的标配。
1.6 本章小结
好了，咱们把今天的内容串一下。ISO 26262和ASPICE对日志监控的要求，说白了就是两句话：
- ISO 26262：日志系统不能成为安全隐患，它本身要可靠、要独立、要可追溯。
- ASPICE：日志系统的开发过程要规范，设计要文档化，测试要覆盖到位。
这两个标准不是互相替代的，而是互补的。你既要满足功能安全的要求，又要通过过程审核。嗯，听起来有点麻烦，但做习惯了就会发现，这些要求其实是在帮你避免更大的麻烦。
下一堂课，咱们会深入讲日志系统的架构设计，包括缓冲区策略、日志级别设计、以及如何满足ASIL B/C/D的具体实现。到时候我会带大家看一些实际的代码示例。
公众号:蓝海资料掘金营，微信deep3321