2.4    智慧裝置 當我們理解了閘道器，理解所謂智慧裝置就容易得多了。如果一個閘道器僅連線了一個傳統裝置，我們甚至就可以將這個裝置和閘道器的新的組合成為智慧裝置。這些正是一些小型、廉價的工業閘道器被用於裝置智慧化的附加部件的情形。對於原本已經具有了必要的硬體（如可連線網路層的網口）的傳統數字化裝置（如機床的數控系統），因為其本身就已經是一個計算裝置，那麼只要增加必要的軟體就可以在其中實現閘道器的功能。

2.5    邊緣計算 有一個很普遍的誤解，就是認為物聯網系統中既然資料主要向服務端匯聚，那麼業務邏輯一定也都是在部署在服務端。實際上並不是這樣，一些業務邏輯實際上主要面對該閘道器管理的感知層的區域性的幾個裝置，這幾個裝置之間的資料流轉和相互協作，沒有什麼必要一定要通過服務端來時間。比如：一個車間內除了機床還有一個可燃物報警器，當可燃物報警器報警的時候，需要機床必須停機以避免事故。如果在這種情況下，報警訊號要從服務端繞一圈再下發到各個機床，那麼如果此時連線服務端的網路有問題，那麼這個報警訊號的作用可能因為時間延遲損失了應對時間，甚至因為網路問題乾脆就丟了——這顯然是不可接受的。工業閘道器必須具有一定業務邏輯的就地處理能力，而這種能力又被稱為邊緣計算。

總的來說，邊緣計算有以下作用： 一、確切而及時地響應就地業務邏輯。這一點前面已經說明。不同的業務場景的業務不同，有的工業閘道器甚至為此內建PLC常用的梯形圖等邏輯程式設計工具，從而可以實現更加複雜的就地邏輯。而一些成熟的商用基礎雲服務平臺，如亞馬遜AWS雲服務，所提供的面向物聯網的邊緣計算工具中也明確提供了相關的指令碼程式設計和部署工具。

二、降低服務端計算和儲存負載。這個很好理解，既然部分業務邏輯從服務端轉移到裝置端的閘道器上執行，伺服器計算負載自然也就減輕了。有些情況下，甚至因為部分資料僅對就地業務邏輯有關而無需上傳和儲存在服務端，從而有而節省了服務端的儲存壓力。

三、降低網路層頻寬需求。

四、資料安全和保密考量。有些資料本身比較敏感，不適合直接傳輸到部署在雲端的服務端中。但是因為就地業務邏輯本身和雲端有協同作用，所以還是需要將本地業務邏輯的一些較為巨集觀的執行狀態和結果反饋給服務端——因為這些邊緣計算的狀態和結果沒有暴露原始資料的細節，對資料安全和保密的需求就大大降低了。

五、分散式儲存。這一點和前面的情況有一定的差別，而時僅僅針對就地的資料的。一些情況下，就地資料的價值很稀薄，表現在僅僅是在偶然的情況下才對物聯網系統中的其他組成部分有用。如系統在收集裝置的執行狀態，但僅僅在發生事故時才有必要分析事故前半小時之內的資料。如果這些資料一直在向服務端傳輸和儲存，浪費的資源可能是巨大的。這種情況下可以選在在裝置端儲存足夠可回溯的歷史資料，但僅在裝置故障時再選擇向服務端傳送，以便提黑部署在服務端的故障分析應用使用和作為系統的故障診斷知識庫使用。

那麼是不是計算負載應該追求儘可能地下放到邊緣（工業閘道器或者智慧裝置）呢？回答是否定的。這主要有幾方面的原因：  一、系統總成本控制。將計算負載過度下方到裝置端可能會造成裝置端的計算能力需求大幅度提升，而作為嵌入式裝置，超過一定的計算負荷，如果再提升，其代價可能要遠高於服務端。

二、演算法的資料依賴性。有些資料分析過程，比如人工智慧，為了擁有一個大樣本來訓練演算法，也必須利用整個系統內的所有個體裝置的資料，而這些資料及其分析程式也許只有部署在服務端才是可行。

由於邊緣計算的興起，在某些應用場景下物聯網服務端變得很“薄”，甚至僅具有關鍵資料儲存和子系統之間的溝通、監控作用，而這些儲存於服務端的關鍵資料的組成可能是以裝置端邊緣計算得出的結果為主而不是以原始資料為主。如一些基於區塊鏈技術的分散式能源結算系統，所謂的中心主要負責接入裝置的身份驗證和用電量結算結果的儲存，有關結算的大量非結算點的原始資料已經在裝置端（智慧電錶）的邊緣計算中隨用隨棄了。