硬體.軟體.物聯網 - (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 有什麼不同。它的目標跟使命是什麼、想幫助誰、想做什麼事情。也會聊一下我們目前到底做到了什麼、哪些被國際標準組織收錄、又有哪些東西被採用。也許會說的有點激動也不一定,不想要在這裡就說出來給大家笑~ 然後要強調一下,我們「不是在做閘道器」,是在做閘道器的開發工具啦 (我要哭了~)
 
你可以鄙視我們的理想,但不能否定我們的存在。
 
 
 
(待續....)
 
 

本系列文章:


 

simen

An enthusiastic engineer with a passion for learning. After completing my academic journey, I worked as an engineer in Hsinchu Science Park. Later, I ventured into academia to teach at a university. However, I have now returned to the industry as an engineer, again.

2 Comments

  1. 版主您好:
    想請教您關於在物聯網環境中,無線通訊標準的定位,據我所知目前在閘道器與感測器之間常用的無線通訊標準是Zigbee, 但還有多通訊標準像是APIAllJoyn, OpenThread或如您本文中提到的LWM2M,這些標準讓我有點困惑它們在物聯網中的定位是什麼角色? OpenThread,APIAllJoyn可以跟Zigbee做比較嗎? 有勞您說明了 謝謝

    ReplyDelete
Post a Comment
Previous Post Next Post