我有一个带有微控制器和 2.4 GHz 收发器模块的无线传感器电路、一些带有 I²C 接口的集成传感器、一个 UART 端口和必要的分立元件。
该板设计用于从太阳能 (PV) 面板获取电力，带有锂聚合物电池和分流充电器。这使得传感器可以自供电并无限期地运行，需要尽可能少的维护。
我想探讨在这样的系统中可能发生的故障，这可能是由于老化、违反环境规范（温度、湿度等）或错误维护（不是设计问题/错误），在以最大限度地延长其使用寿命。
传感器节点运行的环境是建筑物，贴在天花板或墙壁上。因此不考虑极端温度或降雨。
我想出的是一些我试图总结的错误：
我如何估计传感器节点将如何发生故障，为什么？
有太多的自由度来理解“所有”可能的错误。然而，有一些技术可以在设计周期的早期（即在广泛发布之前）识别和减轻故障。
设计时活动（硬件前）
同行评审始终是发现错误的好方法。让其他人分析您的设计，并准备好为他们的问题辩护（或承认他们发现了一个错误并修复它！）没有什么可以替代审查，新鲜的眼睛经常会看到疲惫的人错过的东西。这适用于硬件和软件 - 可以像查看源代码一样轻松查看原理图。
对于硬件，正如其他人所说，DFMEA（设计失效模式和影响分析）是一个很好的建议。对于每个组件，问自己“如果短路会发生什么”和“如果开路会发生什么”，并记录您的分析。对于 IC，还可以想象如果相邻引脚彼此短路（焊桥等）会发生什么情况
对于固件，可以使用静态代码分析工具（MISRA、lint 等）来揭示代码中隐藏的错误。浮动指针和相等而不是比较（= vs ==）之类的东西是这些工具不会错过的常见“oopsies”。
书面的操作理论对硬件和软件也很有帮助。操作理论应该在相当高的层次上描述系统如何工作，保护如何工作，排序等。简单地用语言表达逻辑应该如何流动通常会导致人们意识到某些情况可能已经被遗漏了（“嗯， waitasec，这个条件呢？”）
原型级测试
一旦你拿到了硬件，就该开始“工作”了。
在完成所有理论分析之后，准确描述设备在规格范围内的运行方式至关重要。这通常称为验证测试或鉴定。所有允许的极端情况都需要进行测试。
另一个重要的鉴定活动是组件应力分析。在定义的操作条件下，每个部件都根据其最大电压/电流/温度进行评估。为了确保稳健性，应采用适当的降额准则（不要超过电压的 80%、功率的 70% 等）
只有在您了解正常情况下的情况后，您才能开始推测外部异常或您所描述的多个异常。同样，DFMEA 模型（如果 X 发生会发生什么）是一个很好的方法。想一想用户可以对设备做的任何可能的事情 - 短输出、将信号连接在一起、泼水 - 尝试它们，看看会发生什么。
HALT 测试（高度加速寿命测试）也适用于这些类型的系统。将该单元放入环境室中，从最低到最高温度、最低和最高输入和输出、振动进行锻炼。这将发现各种问题，包括电气和机械问题。
这也是进行一些嵌入式模糊测试的好时机- 将所有输入远远超出其预期范围，通过 UART / I2C 等发送乱码以查找逻辑漏洞。（例如，Bit-banged I2C 例程因锁定总线而臭名昭著。）
冲突测试是证明稳健性的好方法。禁用任何保护功能，如过热、过载等，并施加压力，直到出现故障。将设备置于尽可能高的温度，直到出现故障或出现一些不稳定的行为。使装置过载，直到动力系统出现故障。如果某些参数仅略高于最坏情况，则它表示边缘性和某些设计考虑可能必须重新考虑。
您还可以采用更高级的方法，对您的一些 DFMEA 结论进行物理测试 - 实际进行短路、开路和引脚短路，看看发生了什么。
进一步阅读
我的背景是电源转换。我们有一个名为IPC-9592A的行业标准，旨在标准化产品在哪些测试和如何进行测试方面应如何合格。本文档中提到的许多类型的测试和方法可以很容易地用于其他电气学科。
在 I2C 接口上使用多个设备时，您可能会出现“白痴”问题，其中一个设备出现故障，占用 I2C，并终止所有其他 I2C 传输。
浸泡测试与环境测试相结合将提供不同形式的故障分析。在一段时间内使用边际组件、最高/最低/波动温度、不同的湿度、肮脏的电源、嘈杂的射频环境等模拟更长的正常使用时间。系统会有真实的故障，并且可以计算出故障率。
最有可能的故障是固件错误。我所做的一切都有一些。
确保您启用了看门狗计时器，并要求在“抚摸狗”之前发生所有关键的重复功能。我喜欢在定时器中断中设置一个标志，并用它来清除主循环中的看门狗。
在重置周期内测试您的固件恢复。
由于启动是发生很多故障的时候，我喜欢通过一个继电器供电，然后编写一个快速脚本来重新上电，等待收音机指示唤醒，重复。然后这样做 10000 次左右。
几个明显的：
如果您正在执行 FMEA，您需要首先考虑系统的重要性，然后才能确定什么构成故障。