zui近，我發現車子的“引擎檢查”(check engine)警示燈亮起，這可能表示引擎出現了一點小問題，它可能會導致車子過熱。我用車載診斷程式碼掃描儀快速檢查后發現，警示燈號亮起在某方面與引擎的冷卻劑有關。不過，駕駛控制臺(儀表板)的溫度指示器仍然顯示引擎溫度是“正常”的，后來我才發現問題其實和動力傳動系統無關，而是冷卻系統的傳感器故障。
對我來說，現代超感應車輛是*的物聯網(IoT)。事實上，對于許多車型來說，這是一種IoT現象，因為車子可以連接至制造廠以回報各種讀數、狀態和事件。無論車子是否直接作為IoT節點進行連結，今日的車輛都搭載了許多傳感器，擁有對于溫度、壓力、流量和開啟/關閉等各種讀數的自我意識。我們也被告知有了這一切真的很美好
但我不確定是否真是這樣。任何有經驗的工程師都知道，傳感器是系統中zui脆弱的部份。由于其固有的角色，傳感器經常必須暴露于濕氣、振動、溫度和其他物理應力惡劣的現實世界中。有時這樣的環境暴露是由它所監測的目標直接導致的，但經常都是來自監測其他參數時發生的副作用。無論原因如何，傳感器的壽命比一般電路板(PCB)上的電子元件更嚴苛，即使是相較于車用環境中的電路板元件。
問題就在于當我們將IoT傳感器添加到所有事物時，將會看到更多的假陽性和假陰性，而使得測試與評估越來越困難。很快地，計劃如何測試許多讀數和警告指標的真實性和可信度，將會成為測試專項的很大一部份。
這雖然是一個問題，但還只是其中的一部份。評估傳感器和測試其讀數是相當困難的。因為選項十分有限或者只是因為沒什么吸引力。您可以添加冗余傳感器和接口電路，但這又使得成本、重量、功耗以及空間負擔隨之增加，而且您還需要一種方式來確定兩個傳感器中的哪一個是正確的。或者，您可能必須添加兩個額外的傳感器，然后使用“三選二”(two-out-of-three)方案?當然，所有額外添加的冗余也可能提高與傳感器有關的信號鏈可靠性問題。
另一個選擇是為傳感器性能建置真實、獨立以及封閉電路的測試。在某些情況下，這是一種非常實際的作法。例如，您可以將馬達定向到的位置或速度，然后查看傳感器讀數是否與定向動作一致。如果是的話，啟動器和傳感器很可能都是好的;而如果不一致的話，一定有什么地方出錯了，必須進一步檢查。然而，很明顯的，這種刺激/反應現象對于許多傳感器變數或設置(例如溫度或壓力讀數)而言是*不切實際的。
我在想，基于IoT的傳感器節點擴展與普及后將會產生幾個意想不到的后果。首先，當警報過多成為一種問題后，將逐漸出現一種忽略許多警報的趨勢。雖然這可能不是一個什么好的反應，但卻是人類對于不斷發生這種刺激的正常反應，特別是當其中有許多都被認為是假警報時。
其次，測試工程師將必須把更多的時間花在設計關聯多個傳感器讀數的算法，以確定它們是否能夠算出更好的結論——例如哪些讀數是正確的，哪些是錯誤的。在使用多個傳感器的應用中，發生超出范圍但仍與其他讀數有關的讀數也很常見。例如，過熱(溫度讀數)可能與冷卻劑液位不足或流量指示有關。但這些關聯性并不容易建立，而且需要大量的模擬、建模以及特別是系統級的理解，而當微妙的互動和關係使得系統的復雜度增加，這一切也會變得越來越難以實現。
您是否曾經遇過太多IoT之類的傳感器數據導致過多的假警報?以及隨之而來不必要的系統關機?或是直接忽略所有的警報?你擔心太多的傳感器可能導致zui終無法控制嗎?還有，這些傳感器讀數將會對測試開發帶來的負擔呢?
