📚 课程目录第1章课程导入与Sitara可靠性测试全景

1. 课程导入与Sitara可靠性测试全景

在嵌入式产品开发中，功能跑通只是起点，真正决定产品能否量产、能否在客户现场长期稳定运行的，是系统的可靠性与鲁棒性。TI Sitara 系列处理器（如 AM335x、AM437x、AM57x、AM62x 等）广泛应用于工业 HMI、电机控制、网关、医疗设备和车载终端，这些场景往往要求 7×24 小时连续运行、宽温工作、频繁上下电，甚至面对电源跌落、EMC 干扰和存储老化。本课程围绕 Sitara 平台，系统讲解如何从芯片到整板构建一套可执行、可复现、可判读的可靠性压力测试体系。

学习目标

完成本课程后，你应当能够：理解可靠性、可用性、鲁棒性等基本概念在嵌入式语境下的具体含义；掌握 Sitara 系统从 SoC 内部模块到板级接口、再到整机环境的测试对象层次；能够针对 DDR、eMMC、以太网、USB、电源、温度等关键对象设计压力测试用例；能够使用常见工具（如 memtester、stress-ng、iperf3、fio、rtcwake、thermal zone 读取等）搭建测试环境；能够根据日志、错误计数和性能曲线判断系统是否通过测试，并定位早期失效点。

可靠性基本概念

可靠性（Reliability）指系统在规定条件和规定时间内完成规定功能的能力。工程上常用 MTBF（平均无故障时间）和 FIT（每十亿小时失效数）来量化。与可靠性紧密相关的是可用性（Availability），即系统在任意时刻可正常工作的概率，通常用 A = MTBF / (MTBF + MTTR) 表示，其中 MTTR 为平均修复时间。对嵌入式设备而言，可用性往往比单纯可靠性更贴近用户体验：一台设备即使偶尔重启，只要恢复快、数据不丢，用户仍可接受。

压力测试（Stress Test）并不是为了“把设备弄坏”，而是通过加速施加负载、温度、电压、频率等应力，在短时间内暴露设计余量不足、器件批次差异、软件竞态和散热瓶颈。它回答三个问题：系统在极限条件下还能不能工作？失效的边界在哪里？失效模式是否可恢复？

可靠性测试强调“可复现”：同样的硬件、同样的软件版本、同样的应力条件，应得到可比较的结果。因此测试前必须记录 SoC 型号、硅版本、DDR 型号与频率、PMIC 配置、内核版本、设备树和测试脚本版本。

压力测试在 Sitara 开发流程中的位置

典型的 Sitara 产品开发流程为：需求与选型 → 原理图与 PCB 设计 → Bring-up（点亮最小系统）→ 功能验证 → 驱动与外设调试 → 系统集成 → 可靠性压力测试 → 量产测试。压力测试位于功能验证之后、量产之前，是“设计验证”与“生产导入”之间的质量闸门。它既验证硬件设计余量，也验证软件在长时间运行下的稳定性，例如内存泄漏、中断丢失、DMA 描述符耗尽、文件系统碎片化等。

需要强调的是，压力测试不是一次性动作，而应贯穿样机阶段、小批量试产和量产抽检。每一轮硬件改版（如更换 DDR 颗粒、调整 PMIC 输出电压、修改散热方案）都应重新执行关键压力项。

从芯片到整板的测试对象层次

Sitara 系统的可靠性测试对象可以划分为四个层次，越往上越接近真实使用场景，越往下越接近物理失效机理：

芯片级：SoC 内部 CPU、DDR 控制器、PRU、GPU、VPU、内部总线与温度传感器。关注点包括 CPU 满载下的频率与电压、DDR 误码率、结温是否超过规格。
板级接口：DDR 颗粒、eMMC/OSPI、以太网 PHY、USB PHY、SD 卡、CAN、UART、PCIe。关注信号完整性、误码、掉线、重传和热插拔。
系统级：Linux 内核、文件系统、电源管理、看门狗、RTC、启动链。关注长时间运行下的内存、句柄、中断和日志异常。
整机与环境级：整机在高低温、湿度、振动、电压跌落、EMC 干扰下的表现。关注是否复位、是否丢数据、是否可自动恢复。

下面这张图给出 Sitara 可靠性压力测试的全景关系：左侧是测试对象层次，中间是典型应力类型，右侧是判读依据。它帮助你在设计测试用例时，明确“测什么、加什么应力、看什么结果”。

一个可执行的最小压力测试示例

为了让概念落地，下面给出一个在 Sitara 板卡上可直接参考的最小压力测试组合。假设目标板为 AM62x，运行 Linux，DDR 为 2GB，eMMC 为 8GB，测试时长 2 小时，环境温度 25℃。测试前先记录基线：

# 记录软件与硬件版本
uname -a
cat /proc/device-tree/model
cat /sys/class/thermal/thermal_zone0/temp

# 记录 DDR 容量与频率
cat /proc/meminfo | head -3
dmesg | grep -i ddr

随后并行施加三类应力：CPU 与内存、存储、网络。CPU 与内存使用 stress-ng，存储使用 fio 对 eMMC 做顺序写与随机读写，网络使用 iperf3 双向打流。示例命令如下：

# CPU + 内存压力，4 核，2 小时
stress-ng --cpu 4 --vm 2 --vm-bytes 512M --timeout 7200s

# eMMC 顺序写与随机读写
fio --name=seqwrite --filename=/data/test.bin --size=1G \
    --bs=1M --rw=write --direct=1 --runtime=3600 --time_based
fio --name=randrw --filename=/data/test.bin --size=512M \
    --bs=4k --rw=randrw --rwmixread=70 --direct=1 --runtime=3600 --time_based

# 网络双向打流
iperf3 -s &
iperf3 -c 192.168.1.100 -t 3600 -P 4 --bidir

测试过程中每 30 秒采集一次温度、频率和错误计数，写入 CSV。测试结束后检查：dmesg 中是否有 OOM、I/O error、watchdog 复位；eMMC 的 SMART 或厂商健康寄存器是否出现异常增长；网口统计中 CRC 错误和丢包是否为零；温度是否始终低于 SoC 规格上限（例如 AM62x 工业级结温通常为 -40℃ 至 105℃，需留 10℃ 以上余量）。

压力测试会加速器件老化，尤其是 eMMC 擦写和高温运行。样机数量有限时，应合理分配测试项，避免同一块板反复承受极限应力导致提前损坏，影响后续功能验证。

如何组织一轮完整的可靠性测试

建议按“定义通过准则 → 搭建环境 → 执行基线 → 施加应力 → 采集数据 → 判读与定位 → 回归验证”的闭环推进。通过准则必须在测试前写清楚，例如：连续运行 72 小时无复位、无 OOM、无 I/O 错误；DDR 误码率为零；以太网丢包率低于 1e-6；结温不超过 95℃。测试环境要固定电源、网线、散热条件和被测板位置，避免引入额外变量。

当出现失效时，先区分是硬件余量不足、软件缺陷还是测试方法问题。例如 DDR 在高温下出现误码，可能是时序余量不足，也可能是散热不良导致结温过高；eMMC 写入失败，可能是寿命耗尽，也可能是掉电时序不满足。定位时可通过降低单一应力、更换器件、对比不同硅版本等方式逐步收敛。