嵌入式系统的自我测试过程

在嵌入式系统中，有很多失败的机会。在简单的系统中，故障通常会导致它们无法正常工作。在复杂系统中，故障可能以更微妙的方式表现出来。

嵌入式系统是“智能的”，因此很明显可以利用这种智能来检测即将发生的问题和已经发生的问题，并可能减轻故障的影响。

这种内置故障控制的常用术语是“自我测试”。这是一个很大的主题，很可能已被许多会议论文所涵盖，细节可能会写满一本书。但在这里，我只想考虑关键问题。

本质上，嵌入式系统有四个可能的故障区域：

中央处理器

外围设备

记忆

软件

CPU 的故障非常罕见，但当然也不是未知数。部分故障不太可能发生，因此预期的情况是无法运行代码，因此没有机会解决故障。由于电子元件的故障最常发生在上电时，CPU 故障很可能表现为完全死机的设备。在多 CPU 设计中这是另一回事，当一个 CPU 可以监视另一个 CPU 的活动并更优雅地报告故障时。

当然，内存是一个关键的系统组件，现代设备有很多。失败远非未知。可能由杂散的亚原子粒子引起的瞬态故障可能导致设备无法解释且无法重现的崩溃。真的没有什么可以解决这种可能性的。更可能检测到硬/永久性故障。

内存可以通过两种方式进行测试：上电时（这是最有可能发生故障的时候），在任何有用的数据存储在其中之前，或者在运行中，如果有空闲的 CPU 时间可用。如果可以容忍短暂的启动延迟，那么在它包含任何数据之前进行全面的内存测试是否值得。通常的测试称为“移动位”，其中内存被清除，每个位依次写入一个，并且每隔一个位检查以确保它是零。“移动零点”测试应用了相同的想法。

动态测试自然不那么全面，因为实时数据不会被破坏。唯一真正的选择是通过写入和读取一系列模式来测试每个字节/字，同时禁用中断。

外围设备种类繁多，并且可能会失败是许多有趣的方式。但是，我可以提供的一般性建议很少。自测试代码可以检查设备是否对其地址做出响应，如果不这样做则表明发生了不好的事情。否则，某些设备可能具有“环回”模式，可以检查基本的发送/接收功能。除此之外，需要由设备功能知识驱动的创造力来实施任何自我测试。

如果软件失败，那是因为它的设计或实现出现了错误。与硬件不同，无错误的软件（如果它甚至存在的话）不会随着时间的推移而变坏。软件故障大致分为两类：

陷入循环（无响应）

数据/代码损坏

（1） 最常见的原因实际上是某种硬件问题，软件正在等待永远不会出现的响应。这仍然是一个软件错误，因为超时总是谨慎的。解决此类故障的最佳方法是使用某种看门狗设施。如果未收到软件的定期响应，这通常是重置系统的硬件。专用任务可能在多线程应用程序中执行相同类型的工作。

指针错误是 （2） 的可能原因，完全随机的内存损坏很难检测和诊断。幸运的是，一个常见的错误是使用空指针或完全无效的指针。由于这会导致陷阱（软件中断），因此预防措施是确保实施陷阱处理程序。另一个流行的错误是堆栈或数组等内存区域溢出。这可以通过在任一端使用“警戒词”并监控它们的访问来解决。

仍然存在一个重要的未解决问题。一旦检测到故障或即将发生的故障，您能做些什么呢？这完全取决于系统的性质。在某些情况下，尤其是深度嵌入式系统，系统重置是唯一明智的做法。记录故障以供以后分析可能是可能的。对于其他系统，可以建议用户并可能确定要采取的行动。另一种可能性是设备“打电话回家”或使用网络连接向用户/供应商/开发人员发送有关故障的信息。

最重要的是，每个嵌入式系统都是不同的，这就是让这个行业的工作变得有趣的原因。结果是每个设备的自检都不同，对发现故障的响应也同样可变。唯一不变的因素是失败的可能性以及许多开发人员对这种可能性的否认。

审核编辑：郭婷