IoT设备的自我测试

东西坏了，事情也出了差错。 简单的说就是 XX发生了。 不管用什么词，事实上我们都生活在一个不完美的世界里。 在嵌入式系统中，有很多失败的可能。 在简单的系统中，失败通常导致它们不工作。 在复杂的系统中，失败可能以更微妙的方式表现出来。

嵌入式系统引入了"智能"，所以显而易见的是，这种智能可以用来检测即将发生的问题和已经发生的问题，并可能减轻失败的影响。

这种内置故障控制的通常术语是"自我测试"。这是一个很有可能被许多会议所讨论的大问题，细节可能会写满一本书。 但在这里，只考虑一下关键问题。

从本质上讲，嵌入式系统中有四个可能出现的故障领域:

• CPU 中央处理器

• Peripherals 外围设备

• Memory 内存

• Software 软件

一个 CPU 的失败是相当罕见的，但是，当然，不是未知的。部分失败是不可能的，所以预期的情况是无法运行代码，所以没机会解决失败。由于电子元件的故障通常发生在电源上，CPU 故障很可能会以一个完全死机的形式出现。在多 CPU 设计中，这是一个不同的问题，当一个 CPU 可以监视另一个 CPU 的活动并且更优雅地报告失败。

内存是一个关键的系统组件，当然，现代设备中有很多的内存。失败也是未知的。 一个暂时的故障，可能是由一个杂散粒子引起的，可能会导致无法解释的、无法生成的装置崩溃。真的没有什么办法可以解决这种可能性。 一个严重的或者永久性的失败更容易被发现。

内存可以通过两种方式进行测试: 如果CPU有闲置时间的话，在加电的时候（在任何有用的数据存储在存储在内存之前），或者在动态运行中。如果一个简短的启动延迟可以被容忍的话，要考虑是否需要一个全面的内存检测。 通常的测试被称为"动态测试"，在这种方法中，内存被清除，每个位都被写入，每个位都被检查，以确保它是零。 

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

外围设备多种多样，可能会失败，这里有许多有趣的方法。 然而，能提供的一般性建议很少。自测代码可以检查设备对其地址的响应，因为如果没有这样做，就意味着发生了不好的事情。否则，一些设备可能有一个"循环回路"模式，能够检查基本的发送/接收功能。除此之外，任何自我测试都需要创造力，这种创造力是基于对设备功能的理解。

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

（1）陷入一个循环(无反应) 

（2）数据/代码腐烂

最常见的原因(1)实际上是某种硬件问题，导致软件正在等待一个永远不会出现的响应。 这仍然是一个软件错误，因为超时总是谨慎的。解决这种问题的最好方法就是使用某种watchdog设施。如果没有收到软件的定期响应，通常要硬件重置系统。一个专用的任务可能在多线程应用程序中做同样的工作。

指针错误是导致(2)随机内存损坏的可能原因，很难对其进行检测和诊断。幸运的是，一个常见的错误是使用无效的指针。由于这会导致一个软件中断，预防措施是确保相应处理程序的实现。 另一个普遍的错误是像堆栈或数组这样的内存区域的溢出。 这个问题可以通过在两端使用保护检查或监测其访问情况加以解决。

还有一个重要的未决问题。 一旦发现失败或即将发生失败，能做些什么呢？ 这完全取决于系统的性质。 在某些情况下，特别是深度嵌入式系统，系统重置是唯一合理的做法。在后面的分析中记录失败是一种可能。 对于其他系统，用户可能会被建议或者决定要采取的行动。 另一种可能性是，设备使用网络连接向用户/供应商/开发人员发送有关故障的信息。

自我测试的底线对每一个嵌入式系统都是不同的，这使得这个行业的工作变得有趣。结果是，每个设备的自我测试都是不同的，对发现故障的反应也是可变的。 唯一不变的因素是失败的可能性，以及许多开发人员对这种可能性的否定。