最近，我發(fā)現(xiàn)車子的“引擎檢查”（check engine）警示燈亮起，這可能表示引擎出現(xiàn)了一點小問題，它可能會導致車子過熱。我用車載診斷程式碼掃描儀快速檢查后發(fā)現(xiàn)，警示燈號亮起在某方面與引擎的冷卻劑有關。不過，駕駛控制臺（儀表板）的溫度指示器仍然顯示引擎溫度是“正?！钡?，后來我才發(fā)現(xiàn)問題其實和動力傳動系統(tǒng)無關，而是冷卻系統(tǒng)的傳感器故障。

　　對我來說，現(xiàn)代超感應車輛是眾所周知的物聯(lián)網(wǎng)（IoT）先驅。事實上，對于許多車型來說，這是一種IoT現(xiàn)象，因為車子可以連接至制造廠以回報各種讀數(shù)、狀態(tài)和事件。無論車子是否直接作為IoT節(jié)點進行連結，今日的車輛都搭載了許多傳感器，擁有對于溫度、壓力、流量和開啟/關閉等各種讀數(shù)的自我意識。我們也被告知有了這一切真的很美好。


　　但我不確定是否真是這樣。任何有經(jīng)驗的工程師都知道，傳感器是系統(tǒng)中最脆弱的部份。由于其固有的角色，傳感器經(jīng)常必須暴露于濕氣、振動、溫度和其他物理應力惡劣的現(xiàn)實世界中。有時這樣的環(huán)境暴露是由它所監(jiān)測的目標直接導致的，但經(jīng)常都是來自監(jiān)測其他參數(shù)時發(fā)生的副作用。無論原因如何，傳感器的壽命比一般電路板（PCB）上的電子元件更嚴苛，即使是相較于車用環(huán)境中的電路板元件。

　　問題就在于當我們將IoT傳感器添加到所有事物時，將會看到更多的假陽性和假陰性，而使得測試與評估越來越困難。很快地，計劃如何測試許多讀數(shù)和警告指標的真實性和可信度，將會成為測試專項的很大一部份。

　　這雖然是一個問題，但還只是其中的一部份。評估傳感器和測試其讀數(shù)是相當困難的。因為選項十分有限或者只是因為沒什么吸引力。您可以添加冗余傳感器和接口電路，但這又使得成本、重量、功耗以及空間負擔隨之增加，而且您還需要一種方式來確定兩個傳感器中的哪一個是正確的?；蛘?，您可能必須添加兩個額外的傳感器，然后使用“三選二”（two-out-of-three）方案？當然，所有額外添加的冗余也可能提高與傳感器有關的信號鏈可靠性問題。

　　另一個選擇是為傳感器性能建置真實、獨立以及封閉電路的測試。在某些情況下，這是一種非常實際的作法。例如，您可以將馬達定向到指定的位置或速度，然后查看傳感器讀數(shù)是否與定向動作一致。如果是的話，啟動器和傳感器很可能都是好的；而如果不一致的話，一定有什么地方出錯了，必須進一步檢查。然而，很明顯的，這種刺激/反應現(xiàn)象對于許多傳感器變數(shù)或設置（例如溫度或壓力讀數(shù)）而言是完全不切實際的。

　　我在想，基于IoT的傳感器節(jié)點擴展與普及后將會產(chǎn)生幾個意想不到的后果。首先，當警報過多成為一種問題后，將逐漸出現(xiàn)一種忽略許多警報的趨勢。雖然這可能不是一個什么好的反應，但卻是人類對于不斷發(fā)生這種刺激的正常反應，特別是當其中有許多都被認為是假警報時。

　　其次，測試工程師將必須把更多的時間花在設計關聯(lián)多個傳感器讀數(shù)的算法，以確定它們是否能夠算出更好的結論——例如哪些讀數(shù)是正確的，哪些是錯誤的。在使用多個傳感器的應用中，發(fā)生超出范圍但仍與其他讀數(shù)有關的讀數(shù)也很常見。例如，過熱（溫度讀數(shù)）可能與冷卻劑液位不足或流量指示有關。但這些關聯(lián)性并不容易建立，而且需要大量的模擬、建模以及特別是系統(tǒng)級的理解，而當微妙的互動和關係使得系統(tǒng)的復雜度增加，這一切也會變得越來越難以實現(xiàn)。

　　您是否曾經(jīng)遇過太多IoT之類的傳感器數(shù)據(jù)導致過多的假警報？以及隨之而來不必要的系統(tǒng)關機？或是直接忽略所有的警報？你擔心太多的傳感器可能導致最終無法控制嗎？還有，這些傳感器讀數(shù)將會對測試開發(fā)帶來的負擔呢？