最近,我發現車子的「引擎檢查」(check engine)警示燈亮起,這可能表示引擎出現了一點小問題,它可能會導致車子過熱。我用車載診斷程式碼掃描儀快速檢查後發現,警示燈號亮起在某方面與引擎的冷卻劑有關。不過,駕駛控制台(儀表板)的溫度指示器仍然顯示引擎溫度是「正常」的,後來我才發現問題其實和動力傳動系統無關,而是冷卻系統的感測器故障。

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

20171017_IoT_NT01P1

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

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

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

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

我在想,基於IoT的感測器節點擴展與普及後將會產生幾個意想不到的後果。首先,當警報過多成為一種問題後,將逐漸出現一種忽略許多警報的趨勢。雖然這可能不是一個什麼好的反應,但卻是人類對於不斷發生這種刺激的正常反應,特別是當其中有許多都被認為是假警報時。

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

您是否曾經遇過太多IoT之類的感測器資訊導致過多的假警報?以及隨之而來不必要的系統關機?或是直接忽略所有的警報?你擔心太多的感測器可能導致最終無法控制嗎?還有,這些感測器讀數將會對測試開發帶來的負擔呢?

編譯:Susan Hong

(參考原文:Will IoT Sensors Lead to Test Headaches?,by Bill Schweber)