1. 课程导入与VxWorks实时系统故障诊断全景

VxWorks是典型的硬实时嵌入式操作系统，广泛用于航空电子、工业控制、轨道交通、医疗设备和通信基站等场景。这类系统的共同特点是：任务必须在确定的时间窗口内完成，一旦错过截止期，后果可能不是"慢一点"，而是设备失控、数据丢失甚至安全事故。因此，VxWorks系统的故障诊断与可靠性验证，不能停留在"程序能不能跑通"的层面，而要回答三个问题：系统在正常负载下是否满足时序约束？在异常条件下能否被观测、定位和恢复？长期运行后可靠性是否仍然成立？

学习目标与整体框架

本课程围绕"诊断"与"验证"两条主线展开。诊断解决的是"出了什么问题、在哪里、为什么"；验证解决的是"是否满足设计约束、是否足够可靠"。两者共享同一套观测手段：任务状态、信号量、消息队列、内存、中断、时钟与日志。整体框架可以概括为四层：

• 观测层：通过WindSh、系统查看器、日志、示波器/逻辑分析仪获取任务、中断、内存、时间戳等原始数据。
• 分析层：把原始数据映射为可判断的指标，如任务响应时间、抖动、优先级反转、栈使用峰值、内存碎片率。
• 定位层：依据现象与指标缩小范围，区分是调度问题、同步问题、内存问题、中断问题还是驱动/硬件问题。
• 验证层：用测试用例、压力注入、故障注入和长时间运行，确认修复有效且未引入回归。

这四层不是线性流程，而是循环：验证中发现的新现象会回到观测层，形成持续改进的闭环。下图给出本节的全景关系，帮助建立后续章节的定位坐标。

VxWorks典型应用场景与故障挑战

不同场景对"故障"的定义并不相同。航空电子强调确定性与余度管理，工业控制强调周期任务的稳定抖动，通信设备强调高吞吐下的中断与缓冲管理，医疗设备强调看门狗与安全状态切换。下表给出常见场景、典型约束与高发故障的对应关系，便于在后续章节中按场景选择诊断手段。

这些故障有一个共同点：它们往往在实验室轻载下不出现，只在特定时序、特定负载或长时间运行后暴露。因此诊断的关键不是"猜"，而是建立可观测性。例如，判断一个周期任务是否稳定，不能只看它"跑起来了"，而要在任务入口和出口打时间戳，统计连续N个周期的执行时间与间隔：

/* 示例：周期任务时间戳采集（参数为教学示例） */
#define N 1000
UINT32 tIn[N], tOut[N];
int idx = 0;

void ctrlTask(void)
{
    while (1) {
        tIn[idx] = tickGet();          /* 入口时间戳 */
        controlStep();                 /* 实际控制计算 */
        tOut[idx] = tickGet();         /* 出口时间戳 */
        idx = (idx + 1) % N;
        taskDelay(1);                  /* 1 tick 周期，示例值 */
    }
}

采集后计算执行时间 tOut[i]-tIn[i] 与周期间隔 tIn[i+1]-tIn[i]。若执行时间最大值接近周期值，说明余量不足；若间隔出现明显跳变，说明被高优先级任务或中断抢占。这些判断依据将在后续章节展开。

从现象到判断：一个最小诊断闭环

以"控制任务偶尔超时"为例，最小闭环可以这样走：先在任务入口/出口打时间戳，确认超时是否真实存在；再查看同时段是否有高优先级任务或中断密集触发；接着检查共享资源是否使用了互斥量而非二值信号量，排除优先级反转；最后用压力注入复现并验证修复。整个过程依赖的是同一套观测数据，而不是反复修改代码试错。