# Intelligent and Efficient IoT Through the Cooperation of TinyML and Edge Computing --- - [論文連結](https://www.informatica.vu.lt/journal/INFORMATICA/article/1281/text) 大綱連結 [TOC] ## 摘要 在此篇論文中,作者提出了一種分層集成 TinyML 方案,該方案透過部署在特定場景中的 IoT 元件做出的個別決策來調整系統範圍內的決策。 基於 TinyML 的兩層邊緣計算解決方案已在一個真實的智能農業用例中實施和評估,可以節省無線傳輸、降低能耗和響應時間,同時加強數據隱私和安全性。 ## 前言 在過去幾年中,物連網逐漸融入到我們生活中,在雲端計算構逐漸浮現出傳輸頻寬不足、中央運算資源不足與能耗比不佳等問題時,邊緣計算透過將部分計算量分配到終端以獲得更快的響應時間成了新興的領域。 然而在高度分佈式環境中,各個終端元件運算能力並不相同,導致整體系統難以做出有效的決策,因此該論文透過結合邊緣計算和 TinyML,以構建一個雙層智能物聯網系統。 具體來說,每個終端設備都通過使用 TinyML 模型和本地數據做出單獨的決定,然後獲得的結果被放置在邊緣節點中基於機器學習(ML)的決策支持系統 (DSS,decision support system) 使用,該系統收集每個終端設備做出的個人決策,並以更廣泛的目標視角做出最終決策。 ## Related Work ### Edge Computing for IoT ![](https://i.imgur.com/lLLMiMt.png) Edge AI是指在邊緣裝置上進行AI運算的概念,其有者以下優勢: - 脫離網路依賴 - 降低延遲反應 - 排除資安疑慮 - 高度整合運用 其強調的是讓使用者不需要連線到伺服器,而是直接在邊緣裝置應用AI模型。 ### Hierarchical Stacking-Based Ensemble ML 集成技術(Ensemble techniques)是使用多種學習算法或模型來生成一個最佳預測模型的方法。 生成的模型比單獨使用的基礎學習器具有更好的性能。 集成學習的其他應用還包括選擇重要特徵、數據融合等。 其技術可分成三類:Bagging、Boosting和Stacking ![](https://i.imgur.com/oopvo2E.png) * Bagging Bagging(Bootstrap aggregating)是一種降低方差的方法,通過隨機抽樣生成多個模型,再將這些模型的預測結果進行平均或投票,從而得到更穩定的預測結果。 eg : Random Forest * Boosting Boosting則是一種降低偏差的方法,通過加強錯誤樣本的權重,生成多個模型,再將這些模型的預測結果進行加權平均,從而得到更準確的預測結果。 eg : Adaboost、Gradient Boosting * Stacking Stacking則是一種異質模型集成方法,通過將多個不同類型的模型進行堆疊,再使用另一個模型對這些模型的預測結果進行加權平均或投票,從而得到更好的預測效果,**也是此篇論文採用的方法** ![](https://i.imgur.com/7TfcjhS.png) ### TinyML ![](https://i.imgur.com/J0R608Q.jpg) TinyML即是微小的機器學習(Tiny Machine Learning),常應用於運算能力很低、記憶體很少的MCU上,能夠以極低功耗執行設備上的感測器的數據分析,通常在mW以下範圍,進而實現各種永遠上線的應用例及使用電池供電的設備。 常見的應用有振動偵測、手勢(運動感測器)偵測、感測器融合、關鍵字偵測(聲音段分類)、(時序訊號)異常偵測、影像分類、(影像)物件偵測 等 ## Hierarchical TinyML Scheme ![](https://i.imgur.com/dlMl0t8.png) 鑒於單個物聯網單元感應範圍有限,並不能總是能夠做出用於整體的適當決策,因此作者提出一種集成ML模型,如上圖所示 底層由物聯網終端設備構成,頂層則由和在邊緣節點組成,兩者都利用了 TinyML 。 通過這種策略,可在考慮到每個物聯網設備的個性化需求,獲得一個適當的整體決策,其整體模型的工作流程如下圖所示 ![](https://i.imgur.com/CIfnBKA.png) 與典型的集中式雲計算模型相比,這種基於邊緣計算的配置具有許多優勢。 首先,由於本地數據在所提出的系統內部處理,因此與雲計算有明顯的分離。這導致終端設備的傳輸數量減少,從而可以節省能源並避免通信無線部分的惡意攻擊。 而且決策過程的延遲也減少了,特別是考慮到當前物聯網通信技術(即 LPWAN)存在的較長傳輸時間,這個優勢更為顯著。 ## Experimental Design ### Empirical Methodology Empirical methodology包括設計和開發具有兩層決策級別的分佈式DSS,第一決策層(end-device)是由p個zone組成,每個zone包含r個slave設備,每套設備都包含一個 TinyML 模型,該模型使用一組輸入 {x1,x2,…,xn}並輸出個別的決策,第二層由單個主設備(邊緣節點)組成,同樣使用 TinyML 模型,使用 r 維的分類向量作為輸入 {s1,s2,…,sr}並輸出該區域的最終決策。 作者將開發與設計步驟歸納成以下幾點: 1. 產生一個包含m個樣本和n個特徵的數據集(m×n) 2. 進行數據預處理(標準化、檢查不平衡數據問題、缺失值、特徵選擇等)。 3. 使用 k-folds交叉驗證來確定訓練和測試集。 4. 使用基於網格搜索的超參數調整策略來訓練和評估一組分類器,以確定每個分類器的最佳設置。 5. 將這些 ML 模型轉換為 TinyML 模型。 6. 透過評估 TinyML 模型在資源有限的設備上運行時的閃存、SRAM 和延遲表現來為每個模型選擇最佳配置。 7. 對邊緣決策層重複前面的步驟。 8. 通過 LPWAN 鏈路連接終端設備和邊緣節點並測試連通性。 9. 評估整個系統的性能。 ### Scenario and Problem Description ![](https://i.imgur.com/hZH9Mft.jpg) 作者配備 (i) 監測種植園狀態的地面傳感器和 (ii) 監測灑水器狀況的傳感器。 這些傳感器都配備了通信模塊,能與邊緣節點相連。 工作原理如下: > 首先每個地面傳感器通過使用其嵌入式 TinyML 模型來決定其感測植物的需求,然後將該決定提交給邊緣節點(而不是傳輸所有原始感測數據)。 一旦邊緣節點收集了通用灑水器下傳感器做出的每個決定,它最終會使用頂層的 TinyML 模型來決定該灑水器的動作 ### DSS Definition * End-Device-Level Decision 每個部署的傳感器都會依據氣溫 (T)、土壤濕度 (M)、土壤 PH (PH) 和土壤電導率 (EC)來評估及監控種植園的狀態,前兩個輸入用於檢測灌溉需求,後兩者則是評估土壤中的養分水平。 有了這些信息,End-Device層級的 TinyML 模型可以推斷出最有利的行動並輸出決策(o),o={a0,a1,a2},其中 a0 表示“無行動”,a1 表示 “灌溉行動”(澆水),a2 象徵“施肥行動”(澆灌養分),其決策會被傳輸到第二級決策所在的邊緣節點。 * Edge-Level Decision ![](https://i.imgur.com/j4C9goN.png) 當End-Device-Level Decision傳至邊緣節點節點後,其每4個傳感器所監控的區域會由一個灑水器作灌溉,將溫室劃分為 6 個區域,如上圖所示,因此在各個邊緣節點中的tinyML模型會接收 4 個輸入參數 {s1,s2,s3,s4},其中 si 表示各傳感器中的在上一步中做出的決策,並對灑水器下達三種命令{A0,A1,A2}:"無動作"、"灌溉"和"灌溉施肥"。 ### Dataset 由於決策層分成兩層,因此需要兩個不同的數據集來訓練各個模型 * End-Device-Level 在End-Device-Level部分,生成了一個包含 10,000 個樣本的大型數據集,當中輸入參數被分配了一定範圍內的隨機值,即 T∈[17∘C,33∘C] , M ∈[0%,100%] , PH∈[0,14] ,EC∈[1.1S/m,6.3S/m],並利用下表中所示的閾值進行自動標記來為每個輸入向量分配適當的動作{a0,a1,a2}。 | Input condition | Plantation need | | -------- | -------- | | Temperature (T)>26∘C | Irrigation | | Soil Moisture (M) < 60% | Irrigation | | Soil PH (PH) < 5.5 | Fertigation | | Soil PH (PH) > 7 | Fertigation | | Soil Electrical Conductivity (EC) < 2.5 S/m | Fertigation | | Soil Electrical Conductivity (EC) > 3.5 S/m | Irrigation | 最後,通過使用 k-fold cross validation method對數據集進行z-score normalized和分區,其中 k = 10。 * Edge-Level 邊際層的輸入格式為({a0,a1,a2}),其組合共有81種,並透過手動修改來獲得每個輸入組合的最終決策({A0,A1,A2}) ### TinyML Models Generation 作者先是利用Python的scikit-learn生成一系列具有不同配置的 ML 模型,有多層感知器(MLP)、決策樹 (DT)、隨機森林 (RF) 和支持向量機 (SVM),並採用了 emlearn4 和 MicroMLGen5 框架,將ML模型縮小成tinyML後移至Arduino Uno 板,並使用LoRA作為連接傳感器和邊緣節點的通信技術,其技術是一種基於 LPWAN 的解決方案,可以實現具有高能效的遠程傳輸,但傳輸時間非常長,在某些配置下甚至超過一秒,此外,鑑於LoRa 使用未經許可的頻段,每台設備每小時最多只能傳輸最多 3.6 秒。 ## Results ### End-Device-Level Decisor 如前所述,作者評估了不同類型的 ML 算法的性能,即多層感知器 (MLP)、決策樹 (DT)、隨機森林 (RF) 和支持向量機 (SVM),並針對運行時的閃存、SRAM 和延遲表現以及準確性進行比較,以選出最適合的模型配置 下表是每個 ML 算法最佳配置時的性能以及分配給它們的基本配置時的參數值 ![](https://i.imgur.com/apGD0Cq.png) * 關於準確性,DT 和 RF 以幾乎完美的 99.9% 的準確性脫穎而出 * 在內存佔用方面,MLP 模型在閃存和 SRAM 方面是最重的,而RF和 DT 則是最輕的,而優化後的 SVM 模型超出了設備上可用的閃存,因此無法部署在設備上 * 在決策延遲方面,與最慢的 RF 和 MLP 相比,DT 算法表現出最好的性能。 以上的表現也顯示出簡單的模型在有限資源的環境下有著更佳的表現。 最後,比較 TinyML 工具包的性能,觀察到在所有情況下,MicroMLGen 生成的模型比 emlearn 生成的模型更輕、更快。 **根據這些結果,MicroMLGen 生成的 DT 模型將是最適合實施End-Device-Level Decisor的模型** ### Edge-Level Decisor 在Edge-Level部分,鑑於這個決策因素不應受到任何不確定性的影響,因此為每個算法選擇了最簡單的模型,其提供了 100% 的完美準確度。而由於 SVM 算法無法為該決策模型提供完美的準確性(使用線性核的最佳結果為 81.5%),因此並未將其包含在以下討論和表格中 * 關於 MLP 算法,為了得到獲得完美決策精度,最簡單的配置是使用 8 個隱藏層,每層 6 個神經元,具有 ReLu 激活函數和 1000 次訓練迭代的限制 * 對於 DT 算法,採用熵函數作為分割標準,並採用 7 級樹深度以獲得完美的精度 * RF 算法配置了與 DT 模型相同的分割準則函數和 3 個估計器 根據以上的配置,每個模型的內存要求及其計算延遲如下表所示 ![](https://i.imgur.com/GBmcE0D.png) 根據上表可知,MLP 在內存需求方面再次比 DT 和 RF 來的多,且也明顯比其他人慢。 而DT 模型比 RF 模型只需更少的內存並且更快。 最後,比較 emlearn 和 MicroMLGen 庫生成的模型,可以看出後者可生成出比前者更小且更快的模型。 **根據獲得的結果,與End-Device-Level Decisor一樣,MicroMLGen 生成的 DT 模型是實施該決策的最方便的模型** ### Overall System Performance 在此章節中,將考慮終端設備和邊緣節點之間的通信活動來探索整個系統的性能 在 LoRa 中,傳輸時間明顯取決於其基礎配置,尤其是擴頻因子 (SF) 參數。 隨著 SF 的增加,傳輸速率會降低,因此傳輸的穩健性會增強,但傳輸時間會顯著增加。 在此篇論文中,使用了兩種極端的 SF 配置,即 SF7(高數據速率,低傳輸可靠性)和 SF12(低數據速率,高傳輸可靠性),其餘 LoRa 配置參數已固定如下:帶寬 (BW):125 kHz,編碼率 (CR):4/5,CRC 校驗:開啟。 其測試結果如下表所示 ![](https://i.imgur.com/giWInce.png) 由上表可知,與傳輸時間相比,決策時間近乎忽略不計(但若使用MLP則會有不可忽略的延遲) 而在能耗方面,下表是收集了Arduino Uno 的微控制器 (ATmega 328p) 和 Semtech SX1272 LoRa 調製解調器在運作時的平均電流,其微控制器工作在 16 MHz 和 5 V 工作電壓,而LoRa則是假設設定在SF7模式和 20 dB 增益的情況下 ![](https://i.imgur.com/abb9mZE.png) 由此表可知,通信活動明顯比計算任務消耗更多能源,但鑒於LoRa每天傳輸的數量有限,使的終端設備有著較長的電池壽命。