一個完整的物聯網應用方案可能包含許多異質性的裝置，以智能工廠為例，一條生產線可能包含幾個或幾十個工作站，每個工作站可能包含幾部不同功能的生
產設備，每項機器設備上可能配備了電流、震動、應力等不同感測器。在這些機器設備上，各種感測器扮演收集不同資料的功能，甚至根據設定的情境規則
(rule
engine)，有時還必須根據收集到的數據，比如說震動過大，導致金屬切削偏移，造成產品良率下降，而回過頭來對特定機器設備或工作站下令停機檢修。
再以智慧家庭的應用為例：當戶外的溫度感測器察覺戶外溫度已降到23度，室内的冷氣可能會根據溫度感測器採集到的數據停止冷氣運作，改為啟動電風
扇，幾分鐘後窗簾與窗戶自動開啟通風。這種過往仰賴人類體感察覺環境溫度改變時的行為反應，現在都可以因爲物聯網科技的引進而智慧化，從而帶來行動不便老
人的便利或是能源的節省。
想要實現這樣的情境應用，首先要讓機器裝置之間可以＂對話＂。許多國際性組織，例如Open Connectivity Foundation,
Homekit, Thread,
LWM2M等各自制定物聯網通訊協定，目的都是為了編寫一種裝置之間可以溝通的”語言”，只要所有的物聯網應用方案都採用相同的協定，裝置之間的資料蒐
集、傳輸、交換等等都有一個共同的語言。
只是當市場上為了智慧家庭或智能工廠這類命題，有數個巨頭各自推出不同的協定，再加上過往許多產業為了產業內設備早已有許多既有的協定，例如電信業的TR-069等等，使得有志投入物聯網裝置應用方案或開發的廠商在第一時間就面臨選擇哪一種協定的困擾。
縱然選定了某一種特定的協定，緊接著就開發團隊就需要將設定好的使用情境中的各項裝置串連到同一個裝置管理平臺(DM，或者說
Device/Data Management Service –
DMS)。假設每個裝置是一個點，把裝置/設備串連到管理中心就會形成一條線，但要讓許多異質性裝置串連成一個”面”就需要一個物聯網裝置管理平台。根據
Industrial Internet Consortium發佈的IIRA (Industrial Internet Reference
Architecture )，DM是物聯網應用方案的裝置連結與數據集散中心，它往南向(south
bound)肩負起串連感測器/制動器/閘道器，將收集到的資料拋轉給同屬平台層的數據篩選/分類/存儲/分析系統，備供北向(north
bound)的應用軟體(application)及商務管理系統(BSS/OSS)取用，進行決策分析與制定；然後企業層(edge
tier)的應用軟體或商務管理系統做成(自動或半自動)決策制定後，還要對南向的裝置層(edge tier)相關裝置下達指定進行必要行動。
用一個比較具象的形容，DM扮演著人體中樞神經系統中的脊髓。沒有脊髓(及神經，在物聯網中相當於傳輸網路)，人類將無法在眼睛看到棒球飛過來的時候，肌肉自然反應躲避危險。
就像中樞神經可以知道我們感官對外在的察覺，驅動我們的四肢一樣，DM也可以連接感應器，收集感應器數據，與驅動設備。一個投手單純的揮動手臂衹是
練習，但上場時他必須能察覺到捕手的信號、打擊手的姿勢、風向、風速，進而眼手腳交互，最後再投出球，以完成一個好的投球的動作，甚至在打擊手擊出滾地球
時做為內野防守的第一人，接住眼前滾動的球。
所以遙控家電或自動化工廠的單一設備不是物聯網的目標，而是將來自不同類別與來自不同廠商的裝置/設備連結起來，運用收集到的各項必要數據交叉分析或根據情境引擎預設的程式，管理、使用各項裝置/設備，達成提高生產效率、節能或增加便利性等等目的。
為了扮演好中樞神經的角色，一個DM應該具備幾個特色：
- 能連結不同裝置/設備：以文章開頭的例子來說，世界上很難找到一個工廠裡的所有工作站，其中的各項裝置/設備全部都向同一個供應商採購，不同的供應商通常有著不同的韌體或驅動程式，如何讓這些裝置/設備了解互相之間想傳達的資料，本身就是一個重大挑戰；同樣的，家中所有的家電設備，即便是以忠誠度最高著稱的果粉，想來也沒有幾位可以貫徹所有的設備都來自Apple。所以device management的第一個挑戰就是將來自不同硬體製造商的硬體整合在一起。
- 接受不同通訊軟體協定的資料流：如前所述，市場上因為種種原因存在著數量極多的通訊協定。除非整個應用方案的規劃初期，限定採用支援同一種通訊協
定的裝置，否則有的裝置可能在設計之初採用MQTT這種通訊協定，同一個物聯網應用方案中採用的其他裝置可能支援XMPP或LWM2M，這時DM就必須同
時支援兩種以上的通訊協定。而且，不同的物聯網應用方案如果又有需要溝通合作，DM平台必須處理的狀況會更加複雜。試想，在農業0的情境下，身為初級產業
的農場可能採用了某一套物聯網應用方案提升農業生產效率，中間扮演運送保鮮的物流業者也有一套物流業的物聯網方案，再到終端的零售商可能採用了零售業通用
的物聯網應用方案。當政府想實現生產履歷全程貫連，確保消費者健康時，這三套物聯網應用方案之間可能各自採用某幾種通訊協定，因此可能需要一個更大的DM平台，才能讓這三個階段的資訊流與決策相互串連。
- 統一(unified)的管理介面：相信許多朋友都有相同的困擾，大多家庭裡都有電視、家庭劇院、機上盒(set-up
box)、冷氣機、音響等家電，這些設備都各有遙控器，當所有遙控器擺在一起的時候，可能有時會搞不清楚哪個遙控器對應哪一個家電設備。再帶入智慧家庭的
應用後，每個家庭裡面可能還會包括安全監控攝影機、溫度感應的感測器、連結冰箱的感測器、各種智慧插座、燈控裝置等幾十個或上百個感應器及制動器。若是不
能呈現在單一的管理介面上，我們的手機裡面將必須下載無數個app分別控制，不但眾多遙控器同時存在的噩夢加倍放大，我們將很難實現不同裝置間為了同一個
使用情境連動，發揮上文章開頭舉例，因為戶外氣溫下降，市內各項溫度調控裝置配合做動的理想，最佳的解決方案自然就是將所有屋內裝置/設備全部串連在同一
個DM上。
- 提供快速客製的介面：與手機、電腦的需求量可能是一年幾千萬或是幾億台標準裝置相比，物聯網的應用在不同行業，使用的裝置/設備各不相同，甚至不
同的工廠之間，需要的智能工廠方案也必須因人而異、因地制宜，因此客製化程度相對高非常多。DM作為承上啟下的平台(甚至可以說是IoT
enabler)，必須讓系統整合或應用方案開發商輕易地上手，並且迅速為不同的行業客戶設計開發出各類型的應用軟體。
因此兩個訴求支援相同數量通訊協定的DM，但提供更強大的客製化、視覺化開發介面的DM當然會節省更多的開發時間。
- 智能連動：透過資料收集與情境規則設定，DM可讓應用方案開發者輕易設定執行一連串動作。以智能消防爲例，當火災發生時，偵煙器感知到溫度異常上
升速度過快時，警報器會隨之啟動，智能的逃生指示牌也會依人流感測器(people count
sensor)感測到的特定空間人員數量，透過強大的演算法在極短的時間內將人們平均導引至遠離火場的不同逃生出口疏散，當然系統也會同時打電話報警及啟
動滅火系統。所以一個好的DM必須能接受足夠數量的rule engine設定的連動情境。
- 遠程自動維護軟體/韌體升級、遠程改變設定、失能檢測：以智能大樓為例，一棟大樓可能有成千上萬個感應器及制動器，哪些設備的電池電力不足、哪個
偵煙器的已經損壞、是否需要保養？大樓物業管理公司很難用人力隨時、逐個巡檢。如果這些裝置/設備都串連到同一個DM
，這個平台就可以默默進行監控、管理、偵測所有設備，當設備異常時或達到某個閾值時，即時提供告警。甚至，特定的裝置有時會有軟體/韌體升級或設定更改需
求時，管理者只需要在管理平台上一鍵搞定，免去逐一操作的困擾。
- DM/DA的目的在於最終服務的提供：雖然有人把DMS 定義作Device Management Server，
這樣的定義狹義的以為把硬體裝置平台架設好了，開放簡單的API/SDK
就算完成應用方案開發了。事實上，南向的設備接入，不是簡單的下載一個client SDK就能完成的。在整合過程中，往往都會遇到無法預期的困難;
而北向application/BSS/OSS的開發，未來必然有極多需要快速客制化的需求，以因應不同產業需求或商業模式，所以一個好的DM，要能專注
在對南北向需求者的服務上，唯有專注在DM服務的平台，才能真正促進更多更好的物聯網應用方案被開發出來。
物聯網的發展受到舉世期待，DM做為承上啟下的管理平台，可以將整個物聯網應用方案串連成為一個完整的面，而不是一段段不相連的線，避免了實際使用的物聯網服務營運商或管理者必須同時使用多重介面才能達成單一使用情境的窘境。因為唯有讓物聯網應用方案真正提供設想中的便利與智能，物聯網才能真正地走入我們的生活。所以，物聯網應用方案開發者在投入初期選定DM平台時，實在不能不審慎評估，避免進行到一半時發覺怎麼開發速度落後競爭者時的後悔莫及。
