IoT概念打通技術障礙 自動控制走進尋常人家
物聯網(IoT)概念興起前，自動控制(Automation)已經有相當長的發展歷史，從工廠、辦公大樓、附屬設施到住家，都是自動控制的應用範圍。早期相關元件布建成本、軟硬體整合技術門檻較高，自動控制多半僅出現在工廠、較大型的商辦大樓或設施等場所，對於家庭應用一直未能普及。
近年來隨著低成本感測與控制元件的出現、網路擷取技術的蓬勃發展，還有各種智慧型裝置的快速普及，使得IoT概念被提出，不僅智慧家庭普及露出曙光，對於整個自動控制領域也出現新的契機。但本該是一脈相承的自動控制與IoT領域，有時觀察起來卻存在著一種「代溝」，因此本文將從自動控制、IoT的應用需求，探討相關技術、解決方案的發展趨勢。
自動控制 逐步向IP網路靠攏
相信較早進入建築物自動控制領域的人應該都對Modbus協定不陌生，由Modicon公司於1979年提出的Modbus協定因為資料格式簡單易懂，快速地成為早期控制網路的共通標準。
包含Modbus在內的早期控制網路，在實體層均使用有線序列通訊(Serial)的線路標準布建，較為常見的是RS422與RS485兩種。這類序列通訊需要注意的問題相當多，諸如訊號本身的位元率(Baud-rate)、奇/偶函數檢查(Parity)、停止位元(Stop Bit)與訊息間的間隔時間等，還有線材的材質、長度、絞線規格、串接方式、干擾隔離與終端電阻等，均可能對通訊品質造成影響。這些因素也使得傳統序列通訊的控制網路有較高的布建、維護成本與實作技術門檻。
隨著電腦網路發展，TCP/IP逐漸成為電腦網路上共通的通訊協定架構，一些傳統的控制網路也漸漸發展為以TCP/IP為基礎的架構。因應這樣子的趨勢，Modbus協定也由以往使用序列通訊的Modbus RTU，進化到使用Ethernet搭配TCP/IP通訊協定架構，利用傳輸控制協議(TCP)傳輸層協定承載原本序列通訊內容的Modbus TCP。
拜Ethernet架構的簡單、維護成本低廉且在電腦網路中被大量應用等優勢所賜，與舊有架構比起來，Modbus TCP毋須擔心複雜的序列通訊的訊號、線材規範，使得布建與維護的成本、技術門檻均降低不少。
也因為使用TCP/IP通訊協定架構，可以使用網路層IP協定進行定址(Addressing)、選徑(Routing)，也使得Modbus TCP有較大範圍的定址空間與支援較大型網域的能力。若搭配網路橋接器(Bridge)，也可經由無線、電力線、光纖等網路型態傳輸，讓Modbus TCP適用於更複雜的網路環境(圖1)。
 |
| 圖1 傳統的自動控制網路往TCP/IP協定架構靠攏後，能夠與電腦網路、其他IoT網路整合，創造更多元化的應用。 |
另一方面，隨著電子元件大量生產、成本降低，各種更貼近電腦網路，並標榜成本低廉、容易開發的感測器、控制器和相關整合架構如雨後春筍般出現。例如各種使用ZigBee、藍牙低功耗(BLE)的微型感測器、Arduino、樹莓派(Raspberry Pi)等，其中也不乏大廠投入。這類解決方案都大量使用無線傳輸、容易相容於電腦網路，並打著IoT的旗號，儼然成為新的兵家必爭之地。
物聯網促成自動控制軟/硬體現代化
要建構一套能用於生活週遭、串連各種裝置的網路，因為要長時間穩定提供服務，無法避免需要考量可靠度與能源效率。已在自動控制領域被廣泛應用的各類工業規格控制器、感測器，因架構單純且經過長時間產品開發，在可靠度與能源效率上皆有不錯表現。
步入IoT時代後，因有更大量的通訊需求、更多元化的通訊內容、模式與功能應用，使得可靠度與能源效率又面臨新挑戰。
建立標準化、支援體系豐富的架構或許是不錯的方式，目前可以觀察到一些軟/硬體廠商正積極朝這個方向布局，例如蘋果(Apple)推出的HomeKit、Google主導的Thread Group、英特爾(Intel)發起的OCF IoTivity與高通(Qualcomm)為首的AllSeen AllJoyn等，這些都是針對IoT通訊協定架構(Protocol Stack)還有應用程式執行環境(Application Runtime)推出的整合服務架構(Framework)解決方案，甚至已經有部分開始商品化。
有整合的服務架構解決方案，最方便的莫過於軟體開發與商品整合。軟體開發人員可以基於所提供的應用程式介面(API)開發應用程式，除可少花點心思在整合問題外，可靠度與資訊安全等也得以確保。
設備廠商只需要在感測器、控制器上部屬適當的服務架構並滿足相關的規範，即可讓產品有不錯的相容性。而在商品整合的部分，有相容於某種服務架構的標示，對於相關人員選擇產品進行部署，甚至是消費者選購，都會更加方便。
除整合服務架構外，更往硬體層面看，就是控制器、感測器所使用的微型作業系統了。早期的產品多半使用廠商自行開發，或是委由軟體廠商開發的封閉式微型作業系統。近年來出現一些基於UNIX-like、POSIX作業系統架構開發的開放原始碼微型作業系統，例如Mbed、Contiki、FreeRTOS等。
這類型作業系統功能較為單純，同時間須執行的處理程序也比一般電腦少很多，但須考慮資料處理的即時性，不能有太大的延遲。因此除核心、軟體模組的檔案大小都很小外，架構上也是針對指令集較為精簡的控制器晶片設計並最佳化，且多採用事件觸發導向(Event-driven)、即時作業系統(Real-time OS)等概念設計，以滿足需求。
就控制晶片的設計層面，也出現許多更省電、又有強大運算能力的晶片，搭配適當作業系統、服務架構與應用程式，都是未來IoT普及所需的重要元素。目前軟、硬體廠商，甚至是開源社群，皆投入不少心力在整合解決方案上，合作比單打獨鬥帶來更大的力量，透過軟/硬體整合、優化，將讓新型態的IoT感測、控制元件在可靠度與能源效率上更容易達到實用需求。
不論是IoT還是自動控制，與裝置通訊時最基本的動作都是讀取、寫入，讀取感測器擷取的值、控制器的開關狀態或是裝置的設定值等，當有控制需求時寫入開關狀態、設定值等。每個裝置可視為是一個擁有多個屬性值的實體。
早期相當流行的Modbus使用暫存器(Register)的概念進行管理，每個裝置上有數個暫存器，每個暫存器代表不同的開關狀態、感測值、設定值等。讀/寫暫存器上的值即代表讀取感測值或狀態，或是控制開關的狀態、寫入新設定值等動作。而裝置實作層面只須將感測器、開關等狀態與暫存器進行對應。
同樣的概念也應用在BLE上，BLE提供ATT協定(Attribute Protocol)與GATT架構(Generic Attribute Profile)，每個裝置可以定義數個屬性質，用讀寫屬性質的方式達到存取、控制的目的。
在資料庫與軟體工程領域常使用到ER模型(Entity-Relation Model)，這樣的概念也可套用在IoT中，每一個裝置可視為一個實體(Entity)，每個實體擁有若干屬性(Attribute)，而這些實體與屬性間的互動關係(Relation)，就是IoT所實作的。
在IoT的概念中，將有更多數量、更多種類的裝置同在網路上，這意味著IoT網路比起傳統控制網路，需要更大的定址空間與更強的定址甚至是選徑能力，同時需要支援更多元化的資料型態(圖2)。
 |
| 圖2 生活中一些常見的IoT應用裝置與其屬性範例 |
網路匯聚與資源管理
網路匯聚與資源管理
在擁有許多裝置的IoT網路中，可能會有多種不同的實體網路介面，例如IEEE 802.11、IEEE 802.15、電力線網路等，如何匯聚這些網路將成為重要的課題。
在現存的連接層(Link Layer)解決方案中，常使用的解決方式為將不同網路橋接(Bridge)起來，使得不同類型的網路可形成連通的網域。但對於裝置同時擁有多種網路介面、網路拓撲較為複雜的網路環境，就需要一些異質網路整合方案的協助。
舉例來說，高通Hy-Fi解決方案所實作的IEEE 1905.1即是一種異質網路匯聚的協定，透過抽象連接層(Abstract Layer)的幫助，讓上層架構更容易實作，並且達到更高的網路效率。
在網路層(Network Layer)的部分，使用IP網路的好處除前面所述的擁有更大定址空間、具有良好的選徑能力、容易整合外，也可以使用如IPSec、TLS等網路層、傳輸層(Transport Layer)安全機制。這也是6LoWPAN會興起的原因之一，6LoWPAN為針對IEEE 802.15成員設計的輕量化網路層協定，標頭(Header)較短、且賦予很有彈性的標頭定義方式，使得6LoWPAN可以在不浪費頻寬資源的情況下具備如IP網路的定址、選徑功能，且6LoWPAN標頭具有擴充與IP網路相容的能力，使得與整個區域網路整合也相當容易。
在下層都整合到TCP/IP通訊協定架構範圍後，剩下的就是應用層(Application Layer)了。基於IoT架構，Dominique Guinard等人於2009年提出WoT(Web of Things)概念，許多IoT的通訊都將會以HTTP、JSON等協定架構下進行，並搭配CoAP、MQTT或JSON-RPC作為事件發生時的通知訊息推播機制。
目前一些整合服務架構，如HomeKit、IoTivity、AllJoyn等都提供類似架構，而相關的控制器作業系統，也提供輕量的HTTP伺服器與瀏覽器滿足這種需求。這個現象也呼應了前面所提用屬性值看待每樣東西的概念，在使用HTTP當作應用層協定的情況下，每一個裝置上的每一個屬性，都可以使用URI(Universal Resource Indicator)進行定址、存取，而JSON使用精簡純文字表達多種資料型態的概念，也正好滿足了IoT通訊所需(圖3)。
 |
| 圖3 網路匯聚架構式意圖，匯聚不同類型的網路技術，不僅能將各種裝置都納入網域中，也將讓上層應用程式、管理機制等更容易開發。 |
結合雲端改變圖控軟體
圖形、視覺化的監看、控制介面對人類是最為直覺的。傳統的自動控制，會將各個開關、感測器接到中控面板集中監控，電腦化作業興起後，這樣的工作被電腦圖控軟體取代，使用視覺化圖形介面讓使用者對各個感測器、開關進行監控或設定一些條件動作、排程等。
但傳統的圖控軟體有較高的採購與開發成本，且變化彈性也不高，所以一直以來圖控軟體皆由少數軟體廠商掌握，在IoT架構中更是鮮少聽到有人提傳統的圖控軟體。
但圖形化操作介面的需求仍然是存在的，前面提到的WoT概念提供一個很好的切入點。網頁，動態網頁、瀏覽器端網頁程式、網頁美工等領域入手較為簡單且有廣大的開發者，參考資料、各類素材、應用程式介面也非常豐富，且網頁可在大部分人機互動裝置上呈現。
WoT架構等於是用開發網頁的概念來開發IoT使用者介面，可使用送出URI的方式要求讀取某個開關狀態或感測器、改變開關狀態。解析裝置端回傳的JSON資料，除能夠取得某個屬性值外，更可以透過豐富的視覺化套件以酷炫的方式呈現。這些特性都足以讓網頁介面取代傳統的圖控軟體。
另外一大好處就是可以輕鬆整合雲端介面(API)，目前許多雲端服務也都是以HTTP、JSON等共通性很高的機制當作傳輸協定與資料格式。結合雲端服務的好處除可用更多種裝置，或是在遠端存取IoT網路上的裝置外，還可以透過雲端提供如能源管理、健康照護、安全監控、物業管理等等服務，讓IoT的應用更加廣泛(圖4)。
 |
| 圖4 IoT設備端擁有與電腦網路相同的通訊協定架構，並搭配具IoT概念的閘道器，將有助於整合區域網路端各種設備，並介接雲端服務。 |
本文從通訊需求為出發點，從自動控制到IoT、從獨立控制網路到整合區域網路，探討IoT的發展脈絡。在可預見的未來，具有IoT的裝置會更加普及，連網技術與網際網路接取方式也將趨於多元化，雲端服務市場也會趨於成熟。
如此的整體架構下，閘道器(Gateway)的角色也比以前更加重要，以往閘道器主要提供區域網路內的電腦或裝置存取網際網路，有IoT後，閘道器將扮演起整合不同裝置、不同類型網路，並提供整合管理、雲端網際服務接取等服務的角色。
從最早的自動控制，到現在的IoT，本質上有許多地方相似，都是以屬性值看待每個裝置，並且對於這些裝置、屬性加以定址、管理。因此，在早期的自動控制與現在的IoT之間，「代溝」其實並不存在，某些程度上來說IoT甚至是自動控制的舊瓶新裝，當然其中又添加一些新概念。
各類工具與技術發展的出發點無非是希望對於使用者可以更方便使用，對於開發者、營運者能夠方便開發、維護。現存的IoT解決方案大致上包裝到應用層底部，開發者可輕鬆基於這些解決方案開發應用程式，使用者也可因此享受更方便的功能。
