IoT设备的自我测试

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

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

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

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

  • CPU 中央处理器
  • Peripherals 外围设备
  • Memory 内存
  • Software 软件

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

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

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

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

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

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

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

(2)数据/代码腐烂

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

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

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

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

8