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

咱們都必須面對挑戰，尤爲是來自物聯網的挑戰！本文旨在剖析物聯網項目中須要關注的三大挑戰：迴歸，測試和模擬。

如下爲譯文：

當今，物聯網面臨的最大難題是以下的三大技術挑戰：

• 規模大；
• 功耗低；
• 難以控制的無線通訊。

在本文中，咱們將詳細介紹全部物聯網平臺都必須面對的三大基本問題。做爲如何在現實環境中解決這些問題的一個實例，讓咱們看看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平臺採用跳頻技術，它既符合監管要求，又能在同一位置支持多個網絡。每一個網絡都有本身的躍點調度，這使得網絡之間的干擾儘量少。獨立的網絡須要不一樣的安全密鑰，可是保持通訊頻率的獨立使系統更加高效。

結論

物聯網是一個重大的技術挑戰，由於其龐大的部署規模，功耗需求和無線通訊的使用。

幸運的是，經過使用物聯網平臺，你不須要直接面對這些挑戰。由於這些問題應該已經被平臺解決。