促成物聯網願景的技術

自從網際網路在 20 多年前開放大眾使用後，已經促成多種新的商業模式與工作型態。 如此一來，撼動了傳統的「實體店面」商業模式。 而物聯網 (IoT) 能將實體資產連上網路，促成此趨勢更進一步發展。 若將感測器嵌入到建築物中監測其狀況，實體店面本身也會受到影響。

IoT 在實體世界中運用分散式運算智慧能力，讓人們重新思索傳統的商業模式。 商家會去思考：消費者真正想要的是什麼？我們要怎麼做才能滿足這些需求？ 我們早已見證這種轉型實例，如飛機的噴射引擎。 噴設引擎的主要供應商是物聯網模式的早期採用者；他們不僅透過通訊網路支援自家產品的服務，也藉此支援航空公司購買產品的方式。

這種模式能讓航空公司和噴射引擎製造商朝共同目標邁進，專注在航空運輸業獲利的最重要一環，即縮短地面的停機時間，讓飛機航行最多趟航班。 引擎中的感測器能提供即時的最新資訊，其中包括飛機停在機場閘門時所取得的飛機詳細狀態資訊。 這些資訊能讓引擎製造商瞭解引擎的最新狀態，進而依據航班計畫，安排在最佳的時機執行拆離飛機維護工作。

噴射引擎商業模式本身的設計是為了促進引擎製造商盡可能讓飛機不斷飛行；如此一來，航空公司實際上並非購買引擎，反而是租用引擎讓機隊維持在空中飛行的能力。 引擎製造商透過感測器以及全球通訊達到了此商業模式的承諾。

相同的原則也能套用到其他不同的市場。 例如，汽車製造廠能從傳統的產品供應商角色，轉換成可靠的運輸服務供應商。 汽車價值鏈中的其他供應商也能參與其中。 輪胎製造商無需再被動等待車主不定期更換輪胎，而可透過感測器（有些輪胎已經安裝）來強化租賃模式。

圖 1：採用 NXP Semiconductor FXTH87 系列胎壓監測感測器的系統應用範例圖（資料來源：NXP）。

將胎壓監測系統與駕駛資料連結至物聯網後，雲端應用程式便能通知駕駛在適當時間與地點前往服務站為輪胎打氣。此外若駕駛資料顯示輪胎使用頻繁，亦會提醒檢查胎紋深度以及輪胎狀態。 當磨損情形達到需要更換輪胎的程度時，駕駛便可在方便時到輪胎更換點進行更換，而不是等到年度保養時才更換。 這種方式為消費者提供更高價值，而輪胎製造商也可更準確地預測收益流。

在保險產業上，此轉變可能更為明顯。 保險業者不僅能在擬訂保單時利用精算資料估算風險，也可更積極地降低風險與整體成本，為自己與消費者提供更高的價值。 舉例而言，房屋保險最大的成本之一在於水管破裂導致淹水後，物品的清理與更換。 若是處理水管破裂所需的時間越長，成本就越高。 因此，無人入住的房子可能會產生相當昂貴的清理成本。

若家中的感測器能夠在淹水初期發出警示，自動水閥便能關閉主水管的水，進而大幅降低造成損害的可能性。 感測器還可偵測其他問題，讓保險業者在問題造成過大損失前便加以處理。 這麼一來，保險業者便搖身一變成為保障業者。

目前已有多項支援技術能讓企業充分利用物聯網的好處。 如同上述範例所示，感測器與通訊就是兩項關鍵技術。 但若要讓整體系統成真，也必須將基礎設施列入考量。

在絕大多數既有的物聯網相關應用中，通訊基礎設施的角色比較像是內部網路。 製造商已經部署了感測器，而且通常也會管理網路，即便是租用現有的通訊基礎設施（例如行動網路）也無妨。 IoT 能運用來自眾多來源的資料與網路來打造單一應用，藉此發揮最大價值。

例如，屋主安裝水感測器；水公司則安裝自動化水閥。 兩者協調運作的關鍵則仰賴保險業者開發的軟體（在多個地點運作）。 從水表讀數判斷是否淹水的核心演算法通常是在雲端伺服器中執行。 這些伺服器可能由企業自行擁有，或是向 Amazon Web Services 或 Microsoft Azure Service 等供應商租用。

為了確保即時回應，某些應用程式會在靠近感測器與致動器的物聯網閘道器中執行。 這個閘道器是運算架構最大的變革之一，若要發揮物聯網的最大效益，就必須實現此變革。

在某種程度上，物聯網閘道器的功用就如同家中、辦公室或工業行動網路中的路由器。 會從多個感測器節點收集資料，將命令轉送到致動器，再將資訊送到雲端。 閘道器與不同物聯網節點之間的連線會構成部份「霧」層，使其與雲端中更廣泛的網際網路連線有所區隔。

閘道器設計可能的未來發展方向之一，是成為物聯網應用的主機。 以 Hypervisor 為中心所建立的虛擬化架構，能讓核心的路由和網路管理功能，與來自不同服務供應商以及設備供應商的可下載應用程式區隔開來。 Prpl group 已經展示了這種架構，並且開發出能以開放原始碼形式提供支援的虛擬化管理程序。 因此能讓製造商輕鬆地實作物聯網閘道器的核心功能，讓應用程式開發人員打造可在閘道器上運作的軟體。

至於霧網路方面，整合廠商與開發人員皆有眾多選擇，無論是種類、數據傳輸率以及其他功能上皆有所不同。 物聯網的種類相當廣泛，因此沒有一體適用的解決方案。

即便是在新興的智慧型農業領域，也有相當多種方案。 有些方案應用在相對小型的開發不良區，作物是在溫室中生長。 雖然在溫室環境中比較容易控制植物的灌溉，但這種農業型態的封閉結構，容易導致疾病快速蔓延。

以農田為主的傳統農業，則面臨完全不同的挑戰。 病蟲害固然是一項問題，但要讓作物有效地生長而不會浪費過多水資源，其關鍵在於監控土壤層的灌溉效果。 感測器能監測土壤中的濕度，然後將資料傳送給應用程式，對灌溉進行嚴密監控。 只有農田特定區域的濕度過低時，才會開始灌溉。 農地的其他部份則不會澆水，以免過度灌溉。 這類技術已在乾燥地區採用，如近年來飽受乾旱之苦的加州。

在溫室環境中，土壤資料相當重要。 但水份可以回收，因此省水相對不那麼重要。 在此情況下可採用水耕栽培，透過不同類型的感測器來監測流速，維持良好的養份分配。 為了監控疾病，可使用無人飛行載具 (UAV) 來檢查作物，並且辨識急需照顧或剷除的作物，以免其他作物感染。

這兩種農業型態的通訊需求相當不同。 高頻寬通訊在溫室環境中格外重要，能讓雲端或閘道應用程式更有效地辨識疾病徵兆。 但侷限環境則可使用短距離、更高頻寬的通訊協定，像是藍牙或 Wi-Fi。 傳統農場的開放環境不太適合距離受限的霧網路，但仍有其他部署選項可考慮，像是 LoRaWan 或行動網路。

雖然藍牙主要是針對個人區域網路所開發以便裝置與手機通訊，但是其應用空間已透過一連串通訊協定強化而大幅擴充，並且仍在持續發展中。 藍牙技術聯盟 (SIG) 正在研發一項變革，未來會將 100 公尺的正常傳輸範圍延伸四倍。 範圍擴大會降低資料傳輸速率，但通訊協定具有調適性，因此距離較近的節點可以使用較高的傳輸速率。 由於這項變革，間距較近的裝置，其數據傳輸率可提升至 2 Mbit/s。

還有另一項變革，就是新增網狀網路的支援，能讓藍牙與其他物聯網導向網路（如 6LowPAN 與 Zigbee）並駕齊驅。 6LowPAN 與 Zigbee 是以 IEEE 802.15.4 無線網路通訊規格為基礎進行設計，可支援網狀網路，能用來延伸霧網路等通訊協定的有效範圍和靈活性。

網狀網路能讓封包透過短距通訊方式進行長距離傳輸。 達成此效果的方式在於，讓封包在來源與目的地間的多個節點之間進行短距離跳躍。 網狀技術能提升應用靈活性，若某個節點故障，通常還會有另一個節點可轉送資料。 網狀技術能將感測器放在一般人難以觸及的地方（如溫室屋頂），即便不在物聯網閘道器節點的直接傳輸範圍內也無妨。

藍牙的多次改版也考慮到物聯網本身的異質性，讓支援此通訊協定的感測器節點，都能與 6LowPAN 裝置互動。 雖然 6LowPAN 引進的時間比 Zigbee 更晚，但因為獲得 Thread 聯盟的採用，因此在物聯網架設上更容易普及。 Thread 將驗證與加密等功能加到 6LowPAN 中，以改善整體安全性。

6LowPAN 等通訊協定不僅能在藍牙與 Wi-Fi 所採用的 2.4 GHz 頻段下運作，而且也能在免執照的 Sub-GHz 頻段使用（如 868 MHz）。 這類較低頻段因為使用窄頻傳輸，因此可支援相對較低的傳輸速率。 然而，傳輸範圍增加的同時，有可能會稍微影響耗電量。 因此，在不適用網狀網路，但需要長距離傳輸的情況下，可部署 Sub-GHz 頻段操作的無線感測器節點。 舉例而言，可沿著道路部署感測器，並以固定間隔放置閘道器，即可向雲端傳輸或接收訊息。

轉換到 LoRaWan 或 SIGFOX 等通訊協定，單一閘道器就可與散佈於鄉間一公里或以上範圍內的眾多感測器維持通訊。

圖 2：Semtech 的 SX1272/73 860 MHz 至 1020 MHz 的低功率長距收發器之方塊圖。

LoRaWan 通訊協定是由 Semtech 所開發，該公司協同 Microchip Technology 和 STMicroelectronics 一起供應相容的收發器。 由於矽晶片可隨時供應，物聯網應用開發人員與整合廠商可選擇多種不同的霧網路性質。 他們可以部署自己的閘道器硬體或使用公眾網路（無論公開或私人）。 LoRaWan 網路目前不僅只有商業部署，更有自願者免費部署。 荷蘭的阿姆斯特丹便是其中一個例子，The Things Network 組織僅僅部署了十一個閘道器，網路就幾乎覆蓋了整個城市。

絕大多數針對 868 MHz 與類似頻段而開發的通訊收發器，都能使用 SIGFOX 通訊協定。 此通訊協定主要是用於與協定開發商所安裝之閘道器節點進行單向低傳輸速率的通訊。

長距通訊的另一項選擇是使用 3G 或 4G 行動網路。 3GPP 標準化組織已開發出適合物聯網應用的 4G LTE 通訊協定，並且正在開發另一種窄頻 IoT，能降低複雜度與耗電量。

透過通訊基礎設施的開發，物聯網裝置將有多種方式能連接到霧網路與雲端。 其中的關鍵在於將這些不同的系統串連，而軟體與資料的標準又是最為關鍵之處。

受限應用通訊協定 (CoAP) 等協定能讓網際網路標準（如超文本傳輸協定，HTTP）的優勢透過霧網路延伸到感測器節點。 CoAP 能針對記憶體及運算處理資源有限的微控制器提供適合的方式，以便存取 HTTP。 CoAP 同樣支援「具象狀態傳輸」(REST) 編程模式，這種模式已經成為網頁應用程式的開發標準。 但是這種模式使用二進位，而不是文字格式，資料量比傳統 HTTP 更小，因此適合低傳輸速率的連線。

圖 3：MQTT 服務品質 (QoS) 功能（資料來源：MQTT - 適合物聯網的實用通訊協定：IBM MessageSight Solutions）

其他通訊協定，例如 MQ Telemetry Transport (MQTT)，則可支援替代的應用架構。 MQTT 支援「發佈與訂閱」模式，與 CoAP 的「用戶端與伺服器」架構不同。 「發佈與訂閱」架構適合物聯網，因為可提供來自不同應用之個別感測器節點的資料，而無需直接存取各個節點。 如此即可降低對霧網路的需求，並且具有擴充性。 CoAP 與 MQTT 彼此並不排斥。 閘道器可使用 CoAP 來收集資料，然後使用 MQTT 或其他新興通訊協定，提供其他應用的存取方法。

關鍵在於已經部署的架構能支援互通性，也因如此，將可實現物聯網的關鍵承諾：快速開發出創新且可獲利的應用，而不用每次都投資必要的基礎設施。

舉例而言，部署 UAV 與其他感測器監控作物後，農夫即可根據市場資料或運輸狀況來調整採收策略。 雲端式應用可追蹤特定糧食作物的需求，讓耕作系統得以加速收成，以應付需求的提升。 另一項應用則可操作及時採收系統，以確保最高的新鮮度。 只有在卡車位於農場附近時，才會開始進行當天的收成；當卡車抵達時，便可確保作物已準備好送上車；這都要歸功於預測軟體使用來自 UAV 的資料，藉此判斷已有多少作物準備好等待搬運。

卡車上不需要額外加裝感測器以判定其位置與可能的抵達時間，因為已經內建了。 唯一的要求是讓應用程式可取得資料，這則可透過 CoAP 及 MQTT 等通訊協定來達成。

物聯網涵蓋通訊、感測器技術、雲端智能以及開放軟體通訊協定。 在商業模式的驅動下，物聯網勢必可塑造全新的世界；若非這些技術的結合，根本無法想像會有此前景。