現今物聯網系統設計強調邊緣層級的重要性，特別是在處理大量異質裝置和資料整合的挑戰。邊緣運算的興起，讓系統能更有效率地處理來自受限裝置的資料，並在閘道器裝置上進行初步分析和決策，減少雲端負擔並提升系統反應速度。透過整合邊緣層和雲端層，物聯網系統得以實作更複雜的功能，並在資料處理、分析和決策方面達到更好的平衡。考量到系統異質性，設計通用且可移植的程式碼至關重要，同時需確保邊緣裝置與雲端服務之間的通訊協定一致性，以維持系統的穩定性和可擴充套件性。
物聯網系統架構與價值創造
物聯網（IoT）系統的核心價值在於整合物理與邏輯世界，並透過收集與分析時間序列資料來提供改善或增強的結果。以一個典型的家用廚房為例，如果我們能夠每分鐘測量冰箱內部的溫度，便能準確判斷儲存物品在特定溫度下的暴露時間。相反，如果僅每天取樣一次溫度資料，就無法獲得足夠的細節來做出這種判斷。
資料整合與可擴充套件性
要使IoT系統真正發揮價值，資料的整合能力至關重要。開發者必須仔細考慮系統各部分的設計及其資料如何與其他系統互動。此外，可擴充套件性也是價值鏈中的關鍵環節。一個可擴充套件的雲端系統能夠處理從單一閘道器裝置到數千、數百萬甚至數十億個輸入的資料，而不會出現故障。
建構整合IoT系統的挑戰
在建構整合IoT系統時，開發者需要處理每個步驟中的細微差異。系統的異質性使得「即插即用」或一致的行為變得困難。即使嘗試編寫足夠通用的程式碼以跨硬體裝置運作，但在不同平台上仍可能出現問題。本文提供的程式碼範例儘管存在一些例外，但大多可在支援Java虛擬機器或Python 3解譯器的系統上移植和執行。
邊緣運算的複雜性
IoT解決方案通常在邊緣（Edge Tier）表現出最大的複雜性，因為這是大多數（甚至全部）系統異質性存在的區域。本文重點關注兩類別裝置：受限裝置（Constrained Devices）和閘道器裝置（Gateway Devices）。簡而言之，受限裝置具有一定的電源、通訊和處理限制，而閘道器裝置通常不受這些限制。
受限裝置
受限裝置可視為低功耗（有時由電池供電）的單板電腦（SBC），它可以讀取環境資料（如溫度、壓力或濕度）或觸發機械動作（如開啟或關閉閥門）。IETF在RFC 7228中提供了對各種「受限裝置或節點」的詳細定義和術語。
閘道器裝置
閘道器裝置也可以實作為SBC，但其功能更強大。它能夠與許多不同的受限裝置通訊，並具有足夠的處理能力來聚合來自這些裝置的資料、執行一些分析功能，並決定何時（以及如何）將任何相關資料傳送到雲端進行進一步儲存和處理。
物聯網系統架構示意圖
此圖示預設了一個概念性的IoT系統架構，代表了邊緣層中這些裝置型別之間的關係，以及存在於雲端層中的服務和其他功能。
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333
title 物聯網系統架構示意圖
rectangle "資料" as node1
rectangle "聚合資料" as node2
rectangle "儲存與分析" as node3
node1 --> node2
node2 --> node3
@enduml
此圖示說明
此圖示呈現了IoT系統中不同元件之間的邏輯關係。受限裝置收集資料並將其傳輸至閘道器裝置，後者負責聚合資料並將其傳送到雲端服務進行進一步處理和儲存。
物聯網裝置分類別與架構解析
在物聯網（IoT）生態系統中，裝置可大致分為兩類別：閘道器裝置（Gateway devices）與受限裝置（Constrained devices）。本文將對這兩類別裝置進行詳細定義與探討。
閘道器裝置
閘道器裝置主要負責處理、解析及整合邊緣資料，並與雲端進行互動。這些裝置執行「邊緣運算」（Edge Analytics），轉換或轉換協定堆積疊，決定訊息的路由方式（如果有的話），並直接連線到網際網路和各種雲端服務，使 IoT 對業務利害關係人有用。
受限裝置
受限裝置僅處理感測和/或驅動控制，同時處理自身的訊息。如果實施了正確的通訊協定，它們可以傳遞訊息，並將訊息傳送到閘道器裝置。簡而言之，它們的能力有限，可能無法直接連線到網際網路，而是依賴閘道器裝置進行雲端連線。
受限裝置能否直接連線網際網路？
理論上，如果受限裝置具備 TCP/IP 堆積疊、具有可路由的 IP 位址且可從公共網際網路存取，並具備適當的通訊硬體以與網際網路通訊，那麼它可以直接連線到網際網路。
本文對受限裝置的定義
然而，在本文中，受限裝置被定義為具有以下兩個限制：
- 無法直接支援封包路由到或來自公共網際網路：儘管假設它們支援 TCP/IP 和 UDP/IP，但仍需要透過閘道器裝置與 IoT 生態系統互動。
- 缺乏足夠的運算資源：無法根據收集的資料智慧地決定複雜的行動方案。
物聯網連線正規化
本文將重點關注「受限裝置到閘道器裝置再到雲端連線」的正規化，儘管還有其他可行的邊緣運算模型可能更適合特定的使用案例。
本文使用的排版慣例
本文使用以下排版慣例：
- 斜體：表示新術語、URL、電子郵件地址、檔案名稱和檔案副檔名。
等寬字型：用於程式清單，以及在段落中參照程式元素，如變數或函式名稱、資料函式庫、資料型別、環境變數、陳述式和關鍵字。等寬粗體：顯示使用者應逐字輸入的命令或其他文字。等寬斜體：顯示應替換為使用者提供的值或由上下文決定的值的文字。
提示、注意事項和警告
本文使用以下元素來突出顯示重要資訊： This element signifies a tip or suggestion. This element signifies a general note. This element indicates a warning or caution.
使用程式碼範例
本文的補充材料（程式碼範例和檔案範本）可在 https://github.com/programming-the-iot 線上取得。本文中的程式碼範例根據 MIT 許可證授權。
前言
致謝
我認為我們每個人都在不斷探索自我，無論是透過職業發展、人際關係還是使命感驅使的工作。上帝帶領我經歷的那些特定的曲折和轉變，以及祂在我生命中安排的導師和夥伴，是我體驗祂對我的愛的視窗。不言而喻，如果沒有家人的耐心、批評、鼓勵和專業知識，以及朋友和同事願意陪伴我完成這段旅程，這本文就不會誕生。我將嘗試感謝每一位在我身上留下印記的人，但恐怕會無意中遺漏一些人，請原諒任何無意的疏忽。
我在大約 12 歲時開始接觸程式設計，那時我的父親從朋友那裡借來了一台 Atari 400。起初，我嘗試使用 BASIC 程式語言，但每次電源關閉後，我的工作都會丟失。後來，我的父母買了一台 Atari 800XL 給我，配備了磁帶儲存裝置，後來我們又升級到 5¼ 英寸的軟碟儲存裝置，最終還加裝了一個速度驚人的 1200 Kbps 調變解調器。謝謝你們，媽媽和爸爸。爸爸，我希望您現在還在我們身邊。
對於所有曾經有幸教導和與他們合作的「連線裝置」研究生學生，我要表示衷心的感謝！本文中的內容和每章的練習都是受你們的回饋、建議、請求、評論和對我那些爛爛的爹味笑話的容忍所啟發。你們是本文能夠問世的主要原因，也是我能夠實作教學熱情（而不是成為一名單口相聲演員）的原因。
許多課程的助教提供了對書籍的評論和審閱，並幫助我解決了文字與線上練習之間的脫節。在此，我要對這些優秀的同事表示衷心的感謝：Cheng Shu、Ganeshram Kanakasabai、Harsha Vardhanram Kalyanaraman、Jaydeep Shah、Yogesh Suresh 和 Yuxiang Cao。
我的一些業界朋友和同事對初稿提供了詳細的回饋和評論。Tim Strunck 是商業 IoT 解決方案工程方面的專家，他對整體流程和技術內容提供了豐富的回饋——我很感激他的友誼和敏銳的洞察力，以及他為本文撰寫的前言。Steve Resnick 是一家大型顧問公司的董事總經理，也是兩本文的作者，他分享了他的高層視角和對流程、形式和內容的建議，幫助我進一步闡明瞭關鍵概念。Ben Pu 對整本文進行了全面的審閱，這幫助我從未來的讀者角度來看待這本文。我很感謝有像 Tim、Steve 和 Ben 這樣的專業人士組成的網路，並非常感謝他們快速的回饋和意見。
在準備本文、範例程式碼以及練習題目時，使用了大量的開源軟體和開放規範。在此，我要感謝這些專案的所有開發者和貢獻者。
最重要的是，我要感謝我的妻子 Yoon-Hi 和兒子 Eliot：你們是我生命中的依靠，如果沒有你們的鼓勵和支援，我甚至不知道該如何開始這段旅程。感謝你們對我的審閱、語言上的協助（以及編輯）、挑戰、支援以及信任！你們倆讓我在困難的時候得到鼓舞，也讓我在成功的道路上更進一步。你們都很棒，我愛你們倆遠遠超過我所能表達的。
物聯網基礎與開發環境設定
物聯網（IoT）是一個廣泛且複雜的領域，涵蓋了多種不同的裝置和功能。在本章中，我們將專注於一些核心概念，以幫助您建立一個物聯網解決方案的思維地圖，並從裝置到雲端構建一個簡單的端對端物聯網解決方案。
定義您的系統
建立一個問題陳述是整個過程中最重要的部分。讓我們從擬定一個相對簡單但足以涵蓋各種有趣的物聯網挑戰的問題陳述開始： 「我想了解我家中的環境，它如何隨著時間變化，並進行調整以提高舒適度同時節省錢。」
這個目標看似簡單，但實際上它涵蓋了多個層面。我們可以透過定義問題陳述中的關鍵動作和物件來縮小範圍。我們的目標是找出「什麼」、「為什麼」和「如何做」。首先，讓我們關注「什麼」和「為什麼」，然後識別設計中應考慮的任何動作。
剖析問題
本文中的練習將專注於構建一個物聯網解決方案，以幫助您瞭解您的家庭環境並做出適當的反應。假設您希望瞭解家中發生的事情（在合理範圍內），並在必要時採取某種行動（例如，如果溫度過高，則開啟空調）。
這個設計方法包括三個關鍵活動：
- 測量：收集資料
讓我們從可以感知的事物（如溫度、濕度等）來定義這一點。這主要集中在遙測資料的捕捉和傳輸。
# 示例程式碼：讀取溫度和濕度資料
import random
def read_temperature():
# 模擬讀取溫度資料
return random.uniform(20, 30)
def read_humidity():
# 模擬讀取濕度資料
return random.uniform(40, 60)
temperature = read_temperature()
humidity = read_humidity()
print(f"溫度：{temperature}°C，濕度：{humidity}%")
內容解密：
read_temperature()和read_humidity()函式用於模擬讀取溫度和濕度資料。在實際應用中，這些函式會與感測器硬體介面以取得真實資料。random.uniform(20, 30)和random.uniform(40, 60)分別用於生成模擬的溫度和濕度值，範圍分別為20至30攝氏度和40%至60%。
- 分析：處理資料
分析收集到的資料，以確定是否需要採取任何行動。
# 示例程式碼：分析溫度和濕度資料
def analyze_data(temperature, humidity):
if temperature > 28 or humidity > 55:
return "溫度或濕度過高，建議開啟空調。"
else:
return "環境舒適，無需調整。"
analysis_result = analyze_data(temperature, humidity)
print(analysis_result)
內容解密：
analyze_data()函式根據溫度和濕度的閾值進行判斷。如果溫度超過28°C或濕度超過55%，則傳回建議開啟空調的訊息。- 這裡的邏輯是簡單的閾值判斷，實際應用中可能會涉及更複雜的分析邏輯，例如使用機器學習模型進行預測。
- 行動：執行決策
根據分析結果，採取相應的行動。
# 示例程式碼：根據分析結果執行決策
def take_action(action_message):
if "開啟空調" in action_message:
# 模擬開啟空調的動作
print("正在開啟空調...")
else:
print("無需採取行動。")
take_action(analysis_result)
內容解密：
take_action()函式根據分析結果決定是否執行某個動作。在這個例子中，如果分析結果建議開啟空調，則模擬開啟空調的動作。- 在實際應用中，這可能涉及到控制實際的裝置，例如透過IoT協定（如MQTT、CoAP）向裝置傳送控制指令。
物聯網系統設計：從問題定義到架構規劃
在設計物聯網（IoT）系統時，首先需要明確定義問題陳述並確定相關的行動類別。以下將根據既定的步驟，探討如何從問題定義轉向系統架構設計。
明確問題陳述與行動類別
針對「提高舒適度」和「節省能源」的目標，我們可以識別出五個關鍵的行動類別：
- 資料收集（Data Collection）：蒐集溫度、濕度、氣壓和系統效能等資料。
- 資料管理（Data Management）：儲存和趨勢分析時間序列資料，將資料轉換為有用的資訊。
- 系統觸發（System Triggers）：根據預設的閾值觸發相應的動作，例如調整溫控裝置。
- 組態管理（Configuration Management）：管理多個房間的使用情況和環境引數，以達到最佳的舒適度。
- 分析（Analytics）：進行高階分析以最佳化能源使用，考慮到季節變化、水電費率等因素。
物聯網系統的資料流程
圖 1-1 展示了一個簡單的物聯網資料流程圖，涵蓋了上述五個行動類別。大多數物聯網系統都需要這些類別，因此可以定義一個通用的架構來實作這些功能。
架構設計：平衡靈活性與結構
在進行架構設計時，需要在組織結構和未來擴充套件性之間取得平衡。物聯網系統通常採用多層架構，如圖 P-1 所示，主要分為：
- 邊緣層（Edge Tier）：包含受限裝置和閘道器裝置，負責資料收集、部分資料管理和裝置觸發等功能。
- 雲端層（Cloud Tier）：提供雲端服務，用於資料管理、組態管理和進階分析。
圖 1-2 展示瞭如何將簡單的資料流程對映到分層架構中。
為何邊緣層和雲端層會有重疊的功能？
隨著計算能力的提升和業務需求的變化，邊緣層和雲端層之間的界限變得模糊。邊緣層可以處理一些不需要與雲端互動的自主決策，從而提高系統的反應速度和效率。
重點解讀
- 多層架構的重要性：有助於功能的分離和靈活佈署。
- 邊緣層與雲端層的功能分配：根據具體需求，將功能分配到最合適的層級，以實作最佳效能。
- 未來的擴充套件性：設計時需考慮未來可能的變更和擴充套件需求。