5.6 全线集成测试——一次完整的安全回路验证
场景导入：总装车间的最终检验
在总装车间里，每一辆下线的汽车都要经过一条“最终检验线“。检验员不只是在检查油漆有没有划痕：他们在踩刹车、打方向盘、加速减速、开大灯、按喇叭，同时眼睛盯着诊断仪屏幕上的几百个实时数据流。他们不是在“使用“这辆车，而是在激活它的每一个安全回路。
ABS泵启动了吗？制动压力传感器读数对吗？制动灯点亮的同时，ESP控制器的制动状态标志位翻转了吗？CAN总线的制动报文带了正确的E2E头部吗？ABS控制器的看门狗在制动循环中一直正常喂狗了吗？
一条合格的最终检验线，能在30秒内回答所有这些问题。
这就是本章要做的事：不是对某个独立模块做单元测试（这在5.2到5.5已经做完了），而是把四个模块串联成一个闭环，模拟一个完整的安全监控场景，然后故意在运行中插刀子。你将看到你的安全框架如何像人体的免疫系统一样，在“入侵者“出现的第一时间将其拦截。
集成测试的架构设计
我们需要模拟一个简化的控制系统，包含三个软件组件（任务）和三条数据流：
┌──────────────┐ E2E Protected ┌──────────────┐ Safe Queue ┌──────────────┐
│ Sensor │ ───────────────→ │ Controller │ ──────────→ │ Actuator │
│ Task │ │ Task │ │ Task │
│ │ │ │ │ │
│ checkpoint(0)│ │ checkpoint(1)│ │ checkpoint(2)│
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
└──────────┬──────────────────────┴─────────────────────────────┘
│
┌──────┴──────┐
│ Watchdog │ ← 监控三个checkpoint，deadline各不相同
└─────────────┘
三个任务的deadline配置（这些数字是教学简化的，真实系统的deadline来源于调度分析）：
| 任务 | deadline_ms | tolerance_ms | max_misses | 物理含义 |
|---|---|---|---|---|
| Sensor | 100 | 20 | 3 | 每100ms采集一次传感器数据 |
| Controller | 80 | 15 | 2 | 每80ms运行控制算法 |
| Actuator | 120 | 30 | 3 | 每120ms执行一次驱动输出 |
两个E2E上下文对（发送端和接收端各持一份）：
safe_e2e_ctx_t sensor_tx = { .data_id = 1, .counter = 0 }; // 传感器发送端
safe_e2e_ctx_t sensor_rx = { .data_id = 1, .counter = 0 }; // 控制器接收端
// 两个counter在正常运行时保持同步
一个安全队列：从controller到actuator的命令通道。
完整测试代码走读
让我们逐阶段阅读test_full_integration()（位于main.c）：
Phase 1：基础设施初始化
safe_wdg_t wdg;
safe_wdg_init(&wdg, on_timeout);
safe_wdg_register_slot(&wdg, 0, "sensor", 100, 20, 3);
safe_wdg_register_slot(&wdg, 1, "controller", 80, 15, 2);
safe_wdg_register_slot(&wdg, 2, "actuator", 120, 30, 3);
safe_wdg_start(&wdg);
safe_e2e_ctx_t sensor_tx = { .data_id = 1, .counter = 0 };
safe_e2e_ctx_t sensor_rx = { .data_id = 1, .counter = 0 };
safe_queue_t cmd_queue;
safe_queue_init(&cmd_queue);
printf(" Phase 1: Infrastructure initialized.\n");
此时，看门狗的timerfd开始以20ms周期脉动，三个槽位各就各位，E2E上下文和队列已就绪。不需要分配什么资源，没有线程创建，没有堆分配。这是嵌入式风格的初始化：一切都在栈和静态内存中完成。
Phase 2：10个正常周期
for (int cycle = 0; cycle < 10; cycle++) {
/* ── 传感器任务 ── */
safe_wdg_checkpoint(&wdg, 0); /* "我还活着" */
uint8_t reading[8];
snprintf((char *)reading, sizeof(reading), "S%03d", cycle);
uint8_t frame[SAFE_E2E_MAX_DATA_LEN + SAFE_E2E_HEADER_SIZE];
size_t f_len = safe_e2e_protect(&sensor_tx, reading,
strlen((char *)reading) + 1, frame);
/* ── 控制器任务 ── */
safe_wdg_checkpoint(&wdg, 1);
uint8_t rx_data[SAFE_E2E_MAX_DATA_LEN];
size_t rx_len;
safe_status_t e2e_st = safe_e2e_check(&sensor_rx, frame, f_len,
rx_data, &rx_len);
if (e2e_st == SAFE_OK) {
uint8_t cmd[SAFE_QUEUE_DATA_SIZE];
snprintf((char *)cmd, sizeof(cmd), "CMD_%s", rx_data);
safe_queue_add(&cmd_queue, cmd, strlen((char *)cmd) + 1);
}
/* ── 执行器任务 ── */
safe_wdg_checkpoint(&wdg, 2);
uint8_t exec_cmd[SAFE_QUEUE_DATA_SIZE];
size_t cmd_len;
safe_queue_get(&cmd_queue, exec_cmd, &cmd_len);
/* ── 模拟工作 + 看门狗服务 ── */
usleep(25000); /* 25ms 执行时间 */
safe_wdg_service(&wdg);
}
这段代码中有一个微妙的设计：e2e_st == SAFE_OK的检查不允许错误传播。如果E2E检查失败，controller不生成命令，它默默跳过这轮循环。这模拟了安全关键系统的“静默丢弃“策略：宁可漏掉一条指令，也不能基于错误数据生成错误的指令。
在真实系统中，“静默丢弃“需要配合超时检测。如果连续N个周期E2E检查失败，controller应该触发一个故障响应（如进入跛行模式）。这超出了safe-lite的教学范围，但设计意图你应该清楚。
Phase 3：故障注入与检测
Phase 3故意在三个不同的安全层注入故障：
Fault A — 破坏E2E帧 payload（测试CRC检测）
uint8_t bad_msg[] = { 0xFF, 0xFF, 0xFF, 0xFF };
uint8_t bad_frame[SAFE_E2E_MAX_DATA_LEN + SAFE_E2E_HEADER_SIZE];
safe_e2e_protect(&sensor_tx, bad_msg, sizeof(bad_msg), bad_frame);
fault_bit_flip(bad_frame, sizeof(bad_msg) + SAFE_E2E_HEADER_SIZE, 10);
// 翻转整个帧的第10位
uint8_t tmp[SAFE_E2E_MAX_DATA_LEN];
size_t tmp_len;
safe_status_t st_a = safe_e2e_check(&sensor_rx, bad_frame, ...);
// 预期：SAFE_CRC_MISMATCH
为什么翻转第10位而不是第0位？ 第0位在CRC字节内（byte 0, bit 0），翻转的结果是CRC变了但payload没变，CRC重新计算仍会不匹配，效果一样。但选择payload区域的比特翻转更直观地演示了“数据在传输中损坏“的语义。两种都能被检测，但后者对初学者更可理解。
Fault B — 破坏队列条目的CRC（测试存储层检测）
uint8_t qdata[] = "Q_FAULT";
safe_queue_add(&cmd_queue, qdata, strlen((char *)qdata) + 1);
uint32_t last_idx = (cmd_queue.head + safe_queue_count(&cmd_queue) - 1)
% SAFE_QUEUE_MAX_ENTRIES;
fault_queue_crc_corrupt(&cmd_queue, last_idx);
safe_status_t st_b = safe_queue_get(&cmd_queue, tmp, &tmp_len);
// 预期：SAFE_CRC_MISMATCH
定位last_idx的逻辑值得解释：(head + count - 1) % MAX_ENTRIES定位到最后一个已入队但未出队的条目，即刚刚添加的“Q_FAULT“条目。然后fault_queue_crc_corrupt翻转该条目的entry_crc最低位。下次get时，CRC重新计算必然不匹配。
Fault C — 饿死看门狗槽位（测试任务层检测）
for (int i = 0; i < 10; i++) {
safe_wdg_checkpoint(&wdg, 0); /* sensor 活着 */
safe_wdg_checkpoint(&wdg, 1); /* controller 活着 */
/* slot 2 (actuator) 故意不checkpoint */
usleep(35000); /* 35ms */
safe_wdg_service(&wdg);
}
// 预期：SAFE_TIMEOUT，看门狗触发 on_timeout 回调
关键计算：actuator的deadline=120ms，tolerance=30ms → 极限=150ms。max_misses=2。每个循环sleep 35ms，actuator的last_seen不断累积。
触发序列：
- 循环0-3：elapsed < 150ms，miss_count=0（未超极限）
- 循环4：elapsed ≈ 140ms，仍 < 150ms
- 循环5：elapsed ≈ 175ms，> 150ms → miss_count=1
- 循环6：elapsed ≈ 210ms，> 150ms → miss_count=2，达到max_misses → FIRE
同时，sensor和controller持续checkpoint，证明这是“actuator特定故障“，不是“系统级瘫痪“。
结果总览：安全体检报告
运行后，集成测试输出：
─── Test: Full Integration (End-to-End Safety Loop) ───
Phase 1: Infrastructure initialized.
Phase 2: Running 10 normal cycles...
Phase 2 complete. Queue entries remaining: 0
Phase 3: Injecting faults...
Fault A (bit-flip in E2E frame): CRC_MISMATCH
Fault B (CRC corruption in queue): CRC_MISMATCH
Fault C (starving actuator checkpoint for 300ms)...
*** WATCHDOG TIMEOUT: slot 2 (actuator) unresponsive ***
Fault C result: watchdog fired=1
Integration summary:
E2E bit-flip detected: YES
Queue CRC corrupt detected: YES
Watchdog timeout detected: YES
[PASS]
三个YES：你的安全监控框架在三个独立的安全层面上全部正确响应了注入的故障。这不是巧合，是设计。
完整的安全回路图
将整个集成测试的结构展开，我们得到一条完整的安全回路：
┌─────────── 安全回路 起始 ───────────┐
│ │
▼ │
┌────────────────────────┐ │
│ 传感器正常采集 │ │
│ 数据: "S003" │ │
└───────┬────────────────┘ │
│ │
▼ │
┌────────────────────────┐ │
│ E2E Protect() │ │
│ → CRC8 + Ctr + DID │ │
│ Frame: [CRC|hdr|data] │ │
└───────┬────────────────┘ │
│ │
▼ │
┌────────────────────────┐ ┌──────────────┐ │
│ E2E Check() │ ← ─ │ 故障注入 A │ │
│ CRC→DID→Counter 全过 │ │ bit-flip │ │
└───────┬────────────────┘ └──────────────┘ │
│ │
▼ │
┌────────────────────────┐ │
│ 控制器生成指令 │ │
│ 指令: "CMD_S003" │ │
└───────┬────────────────┘ │
│ │
▼ │
┌────────────────────────┐ ┌──────────────┐ │
│ safe_queue_add() │ ← ─ │ 故障注入 B │ │
│ + magic + CRC │ │ CRC corrupt │ │
└───────┬────────────────┘ └──────────────┘ │
│ │
▼ │
┌────────────────────────┐ │
│ safe_queue_get() │ │
│ magic + CRC 验证通过 │ │
└───────┬────────────────┘ │
│ │
▼ │
┌────────────────────────┐ │
│ 执行器执行指令 │ │
└───────┬────────────────┘ │
│ │
▼ │
┌────────────────────────┐ │
│ 看门狗 checkpoint(0/1/2) │
│ 三个任务全部打卡 │ │
└───────┬────────────────┘ │
│ │
▼ │
┌────────────────────────┐ ┌──────────────┐ │
│ safe_wdg_service() │ ← ─ │ 故障注入 C │ │
│ → SAFE_OK │ │ starvation │ │
└────────────────────────┘ └──────────────┘ │
│ │
└─────────── 返回循环 ─────────────────────────┘
当故障注入A生效时 → 回路在“E2E Check“节点被拦截
当故障注入B生效时 → 回路在“safe_queue_get“节点被拦截
当故障注入C生效时 → 回路在“safe_wdg_service“节点被拦截
没有任何一个故障能穿透全部三道防线到达执行器。
代码度量：你能量化的东西
完成后的safe-lite项目规模：
| 度量 | 数值 |
|---|---|
| 总C代码行数 | ~1173行 |
| 总头文件行数 | ~238行 |
| 编译时间 | <0.5秒 |
| 运行时（11测试） | ~2秒 |
| 二进制大小 | ~45KB |
| 编译警告 | 0 |
| 动态内存分配 | 0 |
| 线程数 | 1 |
| 依赖的外部库 | 仅glibc |
这组数字说明了一件事：安全监控的逻辑复杂度不体现在代码体积上。一个完整的教学级安全框架可以在1173行内实现，比大多数项目的README还短。真正的复杂性在于设计决策：用哪个多项式？计数器窗口多大？deadline设多长？这些问题的答案不能从代码中推导出来。它们必须从系统级安全分析中得出。
从safe-lite走向真实的AUTOSAR
如果你从本章开始，一个零基础的新手，一步步敲完了所有代码并看到11个PASS，你在功能安全领域已经完成了从“听说“到“实践“的跨越。当你面对真实的AUTOSAR工具链时，你会发现这些经验直接可迁移：
| safe-lite | AUTOSAR | 相似度 |
|---|---|---|
safe_wdg_checkpoint() | WdgM_CheckpointReached() | 概念100%相同 |
safe_e2e_protect() | E2E_P01Protect() | 90%（缺少配置结构体） |
safe_e2e_check() | E2E_P01Check() | 85%（缺少status type） |
safe_queue_add() | 自定义CDD或RTE队列 | 设计意图相同 |
fault_bit_flip() | 硬件SEU注入 | 物理原理相同，实现方式不同 |
本篇小结
- 集成测试将看门狗、E2E 保护、安全队列串联为 Sensor→Controller→Actuator 闭环，三个任务各有独立的 deadline 配置和 checkpoint 槽位。
- Phase 2 展示正常回路：传感器 E2E Protect → 控制器 E2E Check → 指令入安全队列 → 执行器出队消费，每条消息经历两层保护。
- Phase 3 同时注入三类故障：E2E payload 比特翻转（CRC_MISMATCH）、队列条目的 entry_crc 翻转（CRC_MISMATCH）、actuator 看门狗饥饿（TIMEOUT），全部被精确拦截。
- “静默丢弃“策略是关键设计：E2E 检查失败时控制器不生成指令，宁可漏掉一条消息也不基于错误数据做决策。
- 1173 行 C 代码、零动态内存分配、单线程、仅依赖 glibc，完成“安全回路“的完整闭合验证，经验可直接迁移到 AUTOSAR 的 WdgM/E2E/SafeLib 组件。
【全书完】： 但你的实践才刚刚开始。从第四章 Arctic Core 6560 行量产级代码的逐行拆解，到第五章亲手敲出的 1173 行 safe-lite 教学框架，你已经走完了“看懂→模仿→构建“的完整闭环。下一次你在 AUTOSAR 项目中看到
WdgM_CheckpointReached()或E2E_P01Check()时，你不会再问“这宏是干什么的“，你会知道它是一个 6 行冗余取反存储的安全守卫，或是一个用模 16 环上窗口算法验证消息新鲜度的纯函数。这就是本书的目的：让你不仅能理解功能安全代码，更能写出安全的代码。