硬體．軟體．物聯網 - (IV) 物聯網閘道器

　
本文的一開始，請容我先稍稍介紹一下閘道器 (Gateway) 這個東西。雖然在一些特定領域，閘道器是有它嚴謹的定義與功能的，但我想寫的是一種粗略的說法，也是日常口語上大家比較能理解的意思 (註：網通領域的人士，可能會以嚴謹的定義來理解它們，那就是專業溝通需要了)。
　
這篇文章我構思了很久，也刪了很多東西，內容已經夠多了，再多下去，我反而說不清我們到底在想什麼、在做什麼了。
　

什麼是閘道器

粗略地說：
　　它是一台打通「內網」跟「外網」的機器，對岸稱為「網關」。

　　你在家用來上網的那台 WiFi 分享器(實體稱呼)，也可以說是你家的網路閘道器 (概念稱呼)。內網是你家，外網是另外一個網路世界。你從這個門出去，別人從這個門進來；暗通款曲、互通有無 (@@ 不要亂用成語~~)。
　　
　　在工業領域中，不管走有線還是無線的，閘道器更是比比皆是。例如，一群由 RS485 串起來的機器網路，透過一台閘道器接到 Internet (或另一種型態的網路)。嗯！閘道器還肩負起了通訊協定轉換的工作呢！

(由於 Internet 的普及，一般講閘道器大部分情況都是指，將內網接到 Internet 的設備。)

傳統閘道器

以工業的角度來看，「物聯網」早就不是什麼新鮮事，透過閘道器將內網中的裝置弄上 web 平台來管理或監測，也是老早就做得到了。

　　真的！的確是這樣。所以如果有人說，物聯網是從工業領域滲透到民生領域的，我也會蠻認同的。不過，由於工業裝置與設備的特殊性，那樣的物聯網，要全部移置到民生或消費性電子用途，那肯定是很花功夫的，也有點不實際，這中間的問題多多呀！
　　
　　傳統的閘道器，概念就大概是這樣。我並不是說「傳統」就是不好，只是為了要跟我後面要講的閘道器類型做一下區隔。接下來講的物聯網閘道器，會越來越靠近我們想像中，未來那種普及化的物聯網，所使用的閘道器。

目前常見的物聯網閘道器

由於物聯網三個字大鳴大放的關係，現在市面上也出現了很多物聯網閘道器，google 一下，不管是工業用還是商用的，琳瑯滿目。但是，其中有絕對大部分，可以說是傳統閘道器的延伸，然後各家「打通任督二脈」的做法可能不一樣，也許還會搭配自家的「(雲) 平台」一起賣，收取服務費。這樣的觀念是既行的、不是很新穎，但也沒有什麼好不好，特別是在工控那種很獨特性的領域，有些方案有它存在的必要性。
　　
　　比起傳統，可以讓你有多一點彈性的 IoT Gateway 就如同 ubiworx 這種閘道器，它也提供 RESTful APIs 讓開發者可以做一些有趣的應用，不過它背後還是綁了自家的雲平台。不過比起我等一下要講的 Cloud Gateway，ubiworx 的好處是本地端有一台物聯網閘道器，好歹也能做一點訊息數據的聚合 (aggregation)，降低頻寬與雲的資源消耗。這類型的閘道器，也越來越多了。
　　

雲端型的閘道器

另一種 IoT Gateway，是一套軟體，讓你安裝在雲端伺服器上，Microsoft (Azure)、Oracle 或 VMWare 等等等，都有提供這樣的軟體。

　　這有一點像是把雲端服務變成 API Gateway 的味道，但又多了資料儲存與裝置資料模型的定義。其實這樣的方案，最陽春的作法就是在雲端來個 MQTT Broker，機器端則做為 MQTT Client 接入雲端。那麼 topic (或資源存取點) 與資料模型，就隨人自己定義了。因為機器節點可以直接上 Cloud，所以當然就是跑 IP-based 的協定，你家的 WiFi 分享器，也就相當於是物聯網閘道器了 (它才不管內網是電腦、手機還是機器)。比如常見的說 ESP8266、Linkit Smart 7688 (還有很多....)，開發者也很常採取這種用法。
　
　　這種雲閘道有個問題，那就是未來物聯網裝置真的開始大爆發時，會相當吃資源，而且網路壅塞也將是個大問題 (對於佈建基礎設施的電信商也許是好消息吧？)，再來就是裝置控制與訊息傳遞即時性也會是個問題。再者，要求所有裝置都走 IP-based 的協定也有點為難大家啊 (跑其他協定的裝置，可以透過一台本地端的閘道器來克服此問題，例如 SIG 官方就有推出 BLE 的閘道器，可以讓 BLE 裝置上雲端)。
　

本地型的閘道器

這種閘道器，負責管理內網(本地端) 的機器節點。傳統型延伸而來的閘道器也是在本地端的，但我現在講的這種，比較有開發性質參雜在裡面，開發完後就有點像傳統型延伸而來的產品了。
　　
　　這種閘道器開發方式，你只要試著搜尋 「Raspberry Pi IoT Gateway」、「樹梅派打造智慧家庭閘道器」之類的關鍵字，就會有一大堆教學文章，教大家這樣玩。拿 MQTT 當例子好了，你可以在 RaspPi 上安裝 Broker (例如使用 Mosquitto 或 Mosca)，區網內的機器 (使用 Paho 或 mqtt.js) 透過本地 Broker 來互動。當然，你也可以把內網的這些裝置，再接到雲端服務上面去。開發者也可以選擇自己喜愛的雲服務來收集與管理裝置。
　　
　　這應該也是很多公司或 Maker 打造物聯網雛形或產品的方式，因為彈性會比雲閘道來的高一些。而且好處是，本地端的閘道器上可以實作一些自家產品特別的服務或應用程式。雖然優點多多，不過我現在想很嚴肅、也很認真地想要對這些產品開發者提出一些忠告，我並不是在批評這種做法不好，僅僅是以一個物聯網開發者的角度，做出提醒。
　　

真心忠告

這樣的作法，貌似你運用了 CoAP、MQTT 或其他標準(不管)，就好像一切就沒問題了，但實際情況並非如此。

　　先不管各種可運用於物聯網的眾多協定，到底成熟了沒，現今都開始往「統一管理或存取介面」的方向在演化，Open Mobile Alliance 的 LWM2M (Lightweight Machine-to-Machine) 正是這樣的協定。LWM2M 定義了一種裝置管理與存取的標準介面，它將自己定義成一種機器網路管理的「應用層」協定。它背後採用了 IP-base 智慧物件 (IP-based Smart Object, IPSO) 作為裝置資料模型，目標是為了讓大家可以將裝置資料抽象成統一的結構，以達到相容的目的。這個模型的出現，也是跟 CoAP 標準的制定過程密不可分。

　　CoAP 標準是由 IETF CoRE 工作小組所制定的，它走的是 REST 的架構；當初這個標準草案是由芬蘭 SensiNode 這家公司提出的，後來被 ARM 併購，接著 ARM 的 mbed 就出現基於 CoAP 機器網路的方案與自家的雲平台。目前 IETF 持續在制定另一種 Pub/Sub 的架構，還在草案階段，未來 LWM2M 除了 CoAP 外，也會支援 Pub/Sub 架構的機器網路。

　　我在這裡先說明，以免說到最後，讓你誤會我是在鼓吹你用我們的東西。我們公司做的事情，都是在 follow 這些國際標準。假使你們的物聯網產品、提供的服務或價值，真的很棒的話，我真心請大家務必思考一下，把追隨國際標準納入開發的考量，特別是新創團隊 (大公司當然不需要我多嘴)。除非你們真的有信心能像 Apple 或 Google 那樣培養出很大坨的使用者，否則用自己的方式硬幹出來的產品，終究還是會面臨到相容性的問題。我真的很不想看到，有台灣團隊做了很棒的產品，幾年後竟然因為這種很鳥的原因，被市場淘汰。
　　
　　真心不騙，你不一定需要用我們做的開發框架。大家可以自己讀讀白皮書，根據規範去實作那些東西，其實也有很多支援這些標準的開源專案，大家都可以使用。我的忠告僅止於此，就當成是我在雞婆好了，其實選擇權還是在大家身上啦！
　　

新世代物聯網閘道器

剛剛我們講到了 RaspPi，也講到了大家可以在本地閘道器實作應用或服務，這聽起來很棒，但就是作法五花八門，做出來的產品，各家也都無法相容。做產品，也是在拚人品。
　　
　　在本地端閘道器做應用服務，也不是全新的觀念。幾年前開始，Eclipse 基金會就已經在提倡，物聯網面對更複雜的應用業務邏輯，機器網路的管理應該要跟應用邏輯區分開來。並且，本地閘道器應該要提供自己的應用服務，而雲端、或是智慧手機等，也提供自己擅長的應用服務。這樣就變成，並不是什麼東西都通通上雲端處理，有些事情由本地端的小型服務器來處理就好了。例如，有些需要很即時處理的事，就讓本地閘道器來負責，雲端就負責長期的資料收集與分析，諸如此類。　　

　　如此，也將雲端中央集權式的統治，稍微將責任分散到本地區域網路的閘道器身上，同時本地端的機器數據，也能聚合後再送到雲端，減輕外網建設的負擔。這樣的概念，一刀將雲端與本地的職責給劃分開了，兩者是相互合作、是包容的，而不是分庭抗禮的。未來的物聯網，區域網路有自己擅長的事情要做，而雲端也可以專注在它擅長的服務上面。Eclipse 對此已經有個基於 Java 的閘道器開發框架，稱為 Kura，我也推薦給大家 (不知道是否有國內公司開始採用了，我還蠻想知道的)。Kura 也是遵循 LWM2M 標準的閘道器(跑 CoAP)，它也有 MQTT (但我不知有無帶 LWM2M 的介面)，它也支援 BLE。
　　
　　我們公司也在做同樣觀念的事情，但是跟 Kura 還是有點不一樣。說真的，目前我們也很難找到一個跟我們做類似事情的「競爭對手」，如果有的話，那就是 Kura (或許我了解還不夠，印象中是還有，但不多就是了，請知道其他框架的朋友，可以告訴我)。但因為又不是很相同，所以我們的心態也不把對方當競爭對手，反而是以比較包容的心態，尋求以後能夠大家整合或包容的方法或機會。總之，Eclipse IoT 工作小組有在關注我們，我們也有在關注他們，然後彼此沒講過一句話就是了 XDD....
　
　　下面這張是我畫的概念圖，每個區域機器網路將自成一格，可自我管理，也有一些本地端的應用為人們提供服務，雲端也變成選項，不一定必要。而每個區域網路內的機器們，可以是同質的 (Homo LAN) 也可以是異質的 (Hetero LAN)。

　　在我的想像中，也許未來也會出現 LAN Gateway 的 App Store，或許可以稍微紓解一下智慧手機 APP 的飽和狀況吧？誰知道呢？或許你覺得這是門可以做的生意，那麼這個 idea 可以拿去用沒關係。這樣子的架構下，到底哪個層級是可以用來賺服務費的，好像都可以 XDD，我沒有認真想過這個問題。
　

我們真的在作夢嗎？

我曾經在有些場合，提過上圖的構想與理念。呵呵，然後大家也只能祝我成功了！更難聽的話也不是沒有聽過，總之就是叫我趕快醒來，不要再做夢了。
　
　　我想，可能是因為我表達得不好，或是大家沒聽懂。我只是提出未來的可能性與想像，況且這也不只是我這樣想啊 =.=。很大的架構，不是我們公司做得來的，我們很有自知之明，知道自己的斤兩。很大很大的東西，就留給大廠去煩惱吧！我們專注的事情其實只有一個：

遵循標準的 本地跨協定 IoT Gateway 開發框架

這才是我們公司可以做、能做的。如果這樣，還有人說我在作夢的話，那我也沒辦法了。也許你還搞不是很懂，我在前面有提到 ubiworx 這種物聯網方案對吧，你就這樣想，我們做的是「讓你開發出 ubiworx」那種東西的開發工具。
　

說到這裡

文章已經有點長了。我不打算在這一篇文章聊我們的開發框架，以免變成一篇自 high 文，因為我寫這一篇是想要「給所有做 IoT 或有興趣做 IoT 的朋友們」參考用的。主要是很淺地說一下 IoT Gateway 這個東西大概有什麼類型。而且我希望，能夠分享給你身邊有需要的朋友，或許有點兒幫助。
　
　　下一篇文章，我會講一下我們做的框架，然後它跟 Kura 有什麼不同。它的目標跟使命是什麼、想幫助誰、想做什麼事情。也會聊一下我們目前到底做到了什麼、哪些被國際標準組織收錄、又有哪些東西被採用。也許會說的有點激動也不一定，不想要在這裡就說出來給大家笑～　然後要強調一下，我們「不是在做閘道器」，是在做閘道器的開發工具啦 (我要哭了~)
　
你可以鄙視我們的理想，但不能否定我們的存在。
　
　
　
(待續....)
　
　

本系列文章：

• (I) 紅色陸橋
• (II) 靈魂之窗
• (III) 創業競賽