最近，我发现车子的“引擎检查”(check engine)警示灯亮起，这可能表示引擎出现了一点小问题，它可能会导致车子过热。我用车载诊断程序码扫描仪快速检查后发现，警示灯号亮起在某方面与引擎的冷却剂有关。不过，驾驶控制面板(仪表板)的温度指示器仍然显示引擎温度是” “正常”的，后来我才发现问题其实和动力传动系统无关，而是冷却系统的传感器故障。
对我来说，现代超感应车辆是众所周知的物联网(IoT)先驱。事实上，对于许多车型来说，这是一种IoT现象，因为车子可以连接至制造厂以回报各种读数、状态和事件。无论车子是否直接作为IoT节点进行连结，今日的车辆都搭载了许多传感器，拥有对于温度、压力、流量和开启/关闭等各种读数的自我意识。我们也被告知有了这一切真的很美好。
但我不确定是否真是这样。任何有经验的工程师都知道，传感器是系统中最脆弱的部份。由于其固有的角色，传感器经常必须暴露于湿气、振动、温度和其他物理应力恶劣的现实世界中。有时这样的环境暴露是由它所监测的目标直接导致的，但经常都是来自监测其他参数时发生的副作用。无论原因如何，传感器的寿命比一般电路板(PCB)上的电子组件更严苛，即使是相较于车用环境中的电路板组件。
问题就在于当我们将IoT传感器添加到所有事物时，将会看到更多的假阳性和假阴性，而使得测试与评估越来越困难。很快地，计划如何测试许多读数和警告指标的真实性和可信度，将会成为测试项目的很大一部份。
这虽然是一个问题，但还只是其中的一部份。评估传感器和测试其读数是相当困难的。因为选项十分有限或者只是因为没什么吸引力。您可以添加冗余传感器和接口电路，但这又使得成本、重量、功耗以及空间负担随之增加，而且您还需要一种方式来确定两个传感器中的哪一个是正确的。或者，您可能必须添加两个额外的传感器，然后使用“三选二”(two-out-of-three)方案？当然，所有额外添加的冗余也可能提高与传感器有关的讯号链可靠性问题。
另一个选择是为传感器性能建置真实、独立以及封闭电路的测试。在某些情况下，这是一种非常实际的作法。例如，您可以将马达定向到指定的位置或速度，然后查看传感器读数是否与定向动作一致。如果是的话，启动器和传感器很可能都是好的；而如果不一致的话，一定有什么地方出错了，必须进一步检查。然而，很明显的，这种刺激/反应现象对于许多传感器变量或设置(例如温度或压力读数)而言是完全不切实际的。
我在想，基于IoT的传感器节点扩展与普及后将会产生几个意想不到的后果。首先，当警报过多成为一种问题后，将逐渐出现一种忽略许多警报的趋势。虽然这可能不是一个什么好的反应，但却是人类对于不断发生这种刺激的正常反应，特别是当其中有许多都被认为是假警报时。
其次，测试工程师将必须把更多的时间花在设计关联多个传感器读数的算法，以确定它们是否能够算出更好的结论——例如哪些读数是正确的，哪些是错误的。在使用多个传感器的应用中，发生超出范围但仍与其他读数有关的读数也很常见。例如，过热(温度读数)可能与冷却剂液位不足或流量指示有关。但这些关联性并不容易建立，而且需要大量的模拟、建模以及特别是系统级的理解，而当微妙的互动和关系使得系统的复杂度增加，这一切也会变得越来越难以实现。
您是否曾经遇过太多IoT之类的传感器信息导致过多的假警报？以及随之而来不必要的系统关机？或是直接忽略所有的警报？你担心太多的传感器可能导致最终无法控制吗？还有，这些传感器读数将会对测试开发带来的负担呢？
编译：Susan Hong
本文授权编译自EE Times，版权所有，谢绝转载
