雲栖号： https://www.aliyun.com/#module-yedOfott8 第一手的上雲資訊，不同行業精選的上雲企業案例庫，基于衆多成功案例萃取而成的最佳實踐，助力您上雲決策！
我們都必須面對挑戰，尤其是來自物聯網的挑戰！本文旨在剖析物聯網項目中需要關注的三大挑戰：回歸，測試和模拟。
作者 | Adam Dunkels
譯者 | 蘇本如，責編 | 郭芮
出品 | CSDN（ID：CSDNnews）
以下為譯文：
當今，物聯網面臨的最大難題是如下的三大技術挑戰：
- 規模大；
- 功耗低；
- 難以控制的無線通信。
- 在本文中，我們将詳細介紹所有物聯網平台都必須面對的三大基本問題。作為如何在現實環境中解決這些問題的一個執行個體，讓我們看看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原文釋出時間：2020-01-05
本文作者：Adam Dunkels
本文來自阿裡雲雲栖号合作夥伴“
CSDN”，了解相關資訊可以關注“
”