CSDN

訂閱

發行量:967 

三大挑戰將扼殺你的物聯網解決方案

我們都必須面對挑戰,尤其是來自物聯網的挑戰!本文旨在剖析物聯網項目中需要關注的三大挑戰:回歸,測試和模擬。作者 | Adam Dunkels譯者 | 蘇本如,責編 | 郭芮以下為譯文:當今,物聯網面臨的最大難題是如下的三大技術挑戰:規模大;功耗低;難以控制的無線通信。

2020-01-05 01:33 / 0人閱讀過此篇文章  

我們都必須面對挑戰,尤其是來自物聯網的挑戰!本文旨在剖析物聯網項目中需要關注的三大挑戰:回歸,測試和模擬。

作者 | Adam Dunkels

譯者 | 蘇本如,責編 | 郭芮

以下為譯文:

當今,物聯網面臨的最大難題是如下的三大技術挑戰:

  • 規模大;

  • 功耗低;

  • 難以控制的無線通信。

在本文中,我們將詳細介紹所有物聯網平台都必須面對的三大基本問題。作為如何在現實環境中解決這些問題的一個實例,讓我們看看Thingsquare物聯網平台是如何解決這些問題的。

在存在大量設備的情況下,即使是正常情況下不太可能發生的問題,也有可能發生。

規模:當規模足夠大時,一切都難以預料

許多物聯網的部署涉及到數百或數千個獨立設備。在存在大量設備的情況下,即使是正常情況下不太可能發生的問題,也有可能發生。

大型網絡在實地很難監控,而在其開發過程中更具挑戰性。

在Thingsquare,當我們討論物聯網的開發時,我們根據規模將其分為如下幾類:

  • 開發者規模:1-2台設備。當你面前只有一個或兩個無線設備時,理解它們的工作原理和過程就比較容易。你可以通過添加列印輸出或讓發光二極體閃爍來了解有些事情正在發生。作為一個開發人員,你會因此感到有信心,因為一切都在你的掌控之中。你甚至可以在其中一個設備上停止軟體的執行,並單步執行程序。

  • 桌面級規模:2-5台設備。在這個階段,你不再能夠單獨控制每個設備,你必須把它們當作一個整體來對待。雖然他們的數量仍然少到能夠讓你監測,但是你將不得不使用像視覺閃爍的LED燈這樣的輔助手段,讓你能夠看到這些設備上正在發生什麼。

  • 辦公室規模:5-10台設備。現在你已經沒有足夠的空間把所有設備放在一張桌子上了,你必須把它們分散到一個有點難以監控的區域。用一個新的程序開始對它們進行編程是一個實際的挑戰,因為你將不得不在物理上連接並斷開每個設備和快閃記憶體編程器(flash programmer)的連接。

  • 樓面級規模:10-100台。現在很難在一個辦公室里找到容納所有設備的空間了,你需要把它們分散在整個樓層上。這使得你很難直觀地看到所有設備,所以,要想知道發生了什麼,唯一的辦法就是通過無線通信——除非每個設備都連接了有線信道,而這本身就是一項龐大的設置工作。此外,在這種規模下,硬體問題開始顯現:因為硬體的質量並非總是那麼可靠,在99%的成材率下,100台設備中可能會有一個或多個設備存在物理損壞。

  • 部署級規模:100-500台設備。這種一種開發時很少考慮的規模,通常開發考慮的規模不超過100台設備。這種規模的原型測試和驗證的POC(概念驗證)過程和前一個類別沒有什麼不同之處。但在這種規模下,網際網路連接問題開始對系統產生影響了。如果系統的某些部分與其他部分具有不同的連接(例如,某些部分使用WiFi連接,而其他部分使用3G連接),那麼在系統的不同部分,情況將有所不同。

  • 城市級規模:500-1000+台設備。在這種規模下,需要自動化工具來跟蹤系統的行為。另外,即使所有設備都包含在一個網絡中,一個簡單的操作也需要大量的時間。例如,由於無線網絡的物理速度,向所有設備發送一個ping消息可能需要幾分鐘的時間。

在Thingsquare,我們用來應對這些挑戰的策略是:

  • 模擬。模擬一切,從物理無線層到微處理器層,再到網絡和設備的高級模擬。

  • 測試床(Testbed)開發。每個功能都在一組測試床中開發,最大的測試床有100個節點。

  • 輕量級崩潰報告。如果代碼崩潰,設備將提供一個簡短但有用的崩潰報告。

  • 回歸測試。代碼中的每一個更改都要在模擬器中經過嚴格的自動化測試。

模擬

在處理一個大型系統時,人們對系統中正在發生的事情,幾乎沒有可見性。當處理物聯網設備時,由於它們是無線的,並且沒有太多存儲和傳輸日誌的能力,它們的可見性甚至更低。

模擬是解決這一問題的重要方法。我們在如下幾個層面使用模擬:

  • 無線網絡模擬:我們模擬系統中的無線網絡行為,從而可以在任何給定時間看到傳輸中發生的情況。

  • 微處理器仿真:我們仿真運行代碼的處理器,從而允許我們按比例測量功耗和執行時間。

  • 功耗模擬:在我們的網絡模擬器和微處理器的仿真器中,我們跟蹤代碼和通信的功耗,這樣就不需要所有需要信息都從硬體上測量得到。

  • 高級模擬:我們通過使用高級程式語言(主要是Javascript)實現對物聯網設備行為的模擬,在物聯網規模大到無法藉助仿真或測試床來測試時,該語言可以幫助我們完成系統測試。

測試床開發

模擬是一個強大的工具,但它不能替代在實際硬體上的開發工作。有時你需要開發一個物理傳感器或驅動器。這時候你需要和真正的硬體交互。但更重要的是,模擬器的行為方式與現實世界不同。如果你完全在模擬中開發你的解決方案,當面對現實的時候,它很有可能會崩潰。

在Thingsquare辦公室,我們有一套規模越來越大的測試床,它包括:

  • 兩個測試床,各自帶有10台和20台設備。

  • 一個帶有100台設備的測試床。

我們使用我們的測試床來開發新的功能,並不斷測試我們的系統。我們可以使用它們來複製我們在客戶部署中看到的行為。我們也可以在測試模式中使用它們來運行比我們辦公室實際能夠容納的更大型的網絡。

輕量級崩潰報告

軟體都有可能崩潰,尤其是在開發過程中。當軟體崩潰時,崩潰報告可以幫助開發人員了解代碼崩潰的位置和原因。對於低功耗物聯網設備,想要在其上存儲和傳輸完全崩潰時保存的內存數據,幾乎不太可能。

在Thingsquare,我們使用一種輕量級技術從設備處收集崩潰報告:

  • 對於上傳到設備的每個構建好的代碼,ELF二進位文件都會被存儲適當的地方,並用該構建的git commit ID打上標記。

  • 如果設備崩潰,崩潰時的程序計數器(亦即指令地址寄存器)將會存儲在非易失性存儲器中。

  • 當設備在崩潰後重新啟動時,發生崩潰時的代碼commit ID和程序計數器會報告給後台。

這使得構建一個包含導致崩潰的內存地址和崩潰發生時的特定代碼版本的資料庫成為可能。有了這個資料庫,開發人員就可以很方便地調查並確定導致崩潰的原因,然後解決問題。

回歸測試

回歸測試是一種標準的軟體開發技術,可以確保軟體在開發過程中不會崩潰。

物聯網平台由許多類型的組件(從後端軟體到無線設備)組成。要執行回歸測試,每個組件都需要進行各自的測試,同時也需要作為一個整體進行測試。

在Thingsquare,我們使用模擬器對系統所做的每一個更改執行全平台回歸測試。在回歸測試通過之後,我們再在測試床上測試系統。回歸測試套件旨在捕獲致命的錯誤,而這些錯誤可能會導致測試台無法工作。

功耗:很低很低!

物聯網可能功能強大,但幾乎沒有什麼設備像物聯網設備那樣功耗低!

物聯網設備通常是無線設備,它們需要依靠普通電池或太陽能電池上提供電力來運行。這些電池提供的電力很弱,非常弱。功耗通常必須不高於電池的自發放電,將功耗降低到如此低水平既是一門科學,也是一門藝術。科學之處在於如何通過使用軟體或硬體來測量和了解功耗。而藝術這處則在於了解如何充分利用此信息。

功耗既是硬體問題,也是軟體問題。硬體需要進行正確的調校,並支持儘可能多地關閉組件。而軟體賜需要知道關閉什麼,何時關閉以及何時可以安全地這樣做。

在物聯網中,最棘手的部分通常是無線通信。無線電傳送會消耗大量電能,但它至關重要,因此不能盲目關閉。無線電波在接收時消耗的功率與發送時消耗的功率相同。隨著網絡規模的擴大,這一點變得越來越重要。

在Thingsquare平台中,我們使用多種技術來解決功耗問題:

  • 基於硬體的功耗測量:我們使用很棒的工具來測量硬體的功耗。

  • 基於軟體的功耗測量:每個節點都會跟蹤功率消耗並定期報告。

  • 壽命估算:基於測得的功耗數據,我們可以估算每個設備的壽命。

  • 具有異常檢測功能的功耗跟蹤:在大型系統中,我們使用異常檢測功能來查看是否有任何設備使用的功耗超出預期。

基於硬體的功耗測量

第一步是確定原始硬體的功耗。最好的方法之一就是使用一種叫做Otii的裝置。我們不僅需要查找硬體中可能導致功耗增加的錯誤,而且還要確定硬體各個組件所消耗的基準功耗。

然而,測量一台設備的功耗並不能讓我們看到整個網絡的功耗。因此,我們需要進行持續的測量。

基於軟體的功耗測量

基於軟體的功耗測量讓我們能夠連續跟蹤每個設備的功耗。

因為軟體可以完全控制硬體,所以我們只需要測量每個組件打開的時間就可以很好地估算總功耗。每個設備都會定期報告此數據。

壽命估算

因為我們現在可以跟蹤每個設備的功耗,所以我們可以使用它來估算每個設備的壽命。

具有異常檢測的功耗跟蹤

隨著設備數量的增長,監視單個設備的功耗變得越來越困難。因此,我們需要引入自動化工具。

我們從每個設備上收集功耗數據,可以使用異常檢測來突出顯示具有異常高功耗的設備。這些設備需要仔細檢查——因為它們可能存在導致高功耗的錯誤,如果我們在開發過程中能找到它,那麼在我們部署解決方案時,它們就不會造成麻煩。

一旦我們找到了一個有問題的設備,我們就可以深入了解細節,並查看歷史功耗。我們發現,在幾個時間尺度上對功耗進行平均可以提供有用的信息:一小時的功耗平均值有助於發現在一天中重複出現的問題,而24小時的平均值則有助於發現每周重複出現的問題。

上圖顯示了一個設備的24小時平均功耗。顯然這個設備在4月份的幾天裡耗電量出現性異常。

一旦我們發現了存在的問題,我們就可以更加深入地研究為什麼會發生這種問題。如果我們不具備識別這種問題的能力,那麼這種問題就不會被發現,然後它們就會悄悄進入生產環境。

無線通信:難以控制

很多物聯網都使用無線網絡。而無線通訊難以控制。

理解無線通信的一種方法是把它想像成光一樣:它會反射並以意想不到的方式被遮擋。無線覆蓋可能在一個地方很好,但僅僅一步之遙就不行了。就像燈發出的光,即使在靠近燈的地方也可能被遮住一樣。

如果有東西擋在無線信號傳輸的路上,無線信號傳輸可能就會阻塞。許多物聯網解決方案部署的位置不可避免地會有物體移動。如果某個大的物體正好在通信路徑上移動,那麼該通信路徑可能會被堵塞。

無線通信也受到其他無線通信的嚴重影響。不同的頻率有不同的干擾量。2.4 GHz頻段,包括了WiFi和藍牙信號,是一個特別難進入的頻段。這就是為什麼許多設備使用其他頻段(如亞GHz頻段)進行通信。

在Thingsquare系統中,我們採取以下措施來應對這些挑戰:

  • 網狀聯網:我們使用IPv6網狀組網技術來繞過障礙物。

  • 跳頻技術:我們使用跳頻技術來避免無線干擾。

網狀組網技術

網狀組網技術是這樣的一種技術:一個設備通過重複發送來自其他設備的消息,來幫助其他設備達到更遠的距離。

這種技術並不要求每個設備都在接入點的範圍之內,它允許設備伸展到更大的區域。同時它還允許網絡自動繞過障礙物。

Thingsquare平台使用支持RPL網格路由協議的IPv6組網技術。所有節點都會不斷地測量到其鄰居接點的連接質量,如果發現質量更好的連結,則可以重新排列路由圖。

網格的形成和維護過程是完全自動化的。因此,只需將擴展器放入網絡,就可以將網絡擴展出去。

跳頻技術

跳頻技術是一種可以避免在一個特定的無線信道上花費太多時間的方法。這是必需的,因為該信道可能被其他通信所占用。對於某些頻率範圍,跳頻是一項監管要求,不能正確切換頻道的設備將被禁止部署。

Thingsquare平台採用跳頻技術,它既符合監管要求,又能在同一位置支持多個網絡。每個網絡都有自己的躍點調度,這使得網絡之間的干擾儘可能少。獨立的網絡需要不同的安全密鑰,但是保持通信頻率的獨立使系統更加高效。

結論

物聯網是一個重大的技術挑戰,因為其龐大的部署規模,功耗需求和無線通信的使用。

幸運的是,通過使用物聯網平台,你不需要直接面對這些挑戰。因為這些問題應該已經被平台解決。

原文:https://dzone.com/articles/the-3-challenges-that-will-kill-your-iot-solution

本文為 CSDN 翻譯,轉載請註明來源出處。





文章標籤: