電子、通訊科技發展迅速，與居家生活關係之密切，已是有目共睹的事實。資策會Foreseeing Innovative New Digiservices(FIND)2014年台灣家庭寬頻現況與需求調查結果顯示，在家戶方面有83.4%的家庭至少擁有一台電腦、連網率為83.6%、使用「寬頻」的普及率為76.2%。
另一份資策會FIND結合Mobile First調查發現，2014年上半年，台灣民眾持有智慧型手機的普及率達65.4%。在智慧手持裝置功能性越趨多元及無線寬頻普及的加持下，使用新載具，包括無線網路、平板、智慧型手機、行動APP等，不僅為人們帶來許多方便，更改變人們對智慧手持裝置的使用習慣。
如今使用網路的目的，已遠超越三十年前網際網路發展是為了政府機構不同單位間資料交換，眾多人的生活已離不開這個方便的工具。
近幾年來物聯網(IoT)概念興起，生活、家庭中的裝置能藉由通訊網路得知彼此的狀態並交換訊息，人們可透過智慧手持裝置即時掌握物件最新狀態與做適當之處理，將使網路的效力發揮得更廣泛，硬體裝置透過網路溝通逐漸備受重視。
由於各不同裝置處理資訊之方式未必相同，如何完整地串聯與整合各裝置間資料交換與資訊傳遞，儼然成為一重要之議題。本文將探討裝置透過既有網路進行資料交換的通訊協定，首先描述硬體裝置，接著闡述透過既有網路架構的通訊協定之訂定、實現與正確使用之重要性。
通訊協定訂定/實現/正確使用 MCU應用再加值
廣泛描述的硬體裝置一定有一個微控制器(MCU)，再搭載週邊裝置來實現特定應用，如圖1與圖2所示。
 |
| 圖1 傳統MCU應用週邊 |
 |
| 圖2 因應IoT更新的MCU應用週邊 |
傳統應用上，MCU搭載特定感測器以達到特定目的，例如溫度、壓力、氣體感測器，以達到生存環境要素的偵測；使用者配戴裝置，藉由觀看螢幕判斷是否適合活動。
環境偵測只是一例，若MCU搭配無線網路與安卓(Android)作業系統，即可成為智慧型手機雛型，因此MCU應用可視情況搭配不同週邊達成多樣性應用。
在IoT應用上，乙太網路(Ethernet)、藍牙(Bluetooth)及ZigBee等聯網功能已不可或缺，因此可將生存環境偵測組態轉化為智慧家庭領域，可採定點偵測，家庭成員就可在有網路的環境下得知住家室內狀況與執行遠端監控。
使用網路介面進行溝通是物聯網應用所不可避免的，通訊協定的訂定、實現及正確使用是MCU進軍IoT領域重要的一環，也是MCU再次加值的關鍵，以下將說明基於既有網路協定上所開發的通訊協定。
IoT透過通訊協定控制MCU
一般而言，MCU與週邊感測裝置通常採用固有協定，如I2C、SPI、GPIO、UART等，在物聯網的應用上要將週邊感測裝置讀數放上網路，即等同於使用網路透過MCU以I2C、SPI、GPIO、UART與週邊感測裝置溝通後，再將其讀數回傳至網路。
因此MCU必須解析從網路來的需求是什麼，IoT網路端亦須知道如何正確使用MCU通訊協定。範例如下：
假設有一通訊協定是IoT透過網路控制MCU RS485的讀寫，只要MCU透過網路接收開頭為0xAA、0xBB的資料，即表示IoT網路欲進行RS485讀寫，再配合參數進行細部設定，各參數定義如下：
正確地使用上述協定須設定各參數，並充分了解各參數的意義，例如secTimeout表示命令MCU等待多少秒數，在確定RS485裝置並無回應後，再將資料回傳給IoT網路，在MCU仍在等待RS485裝置時，若IoT仍命令MCU再次存取RS485裝置時，此時MCU將會回覆RS485忙碌中。接下來將說明若IoT網路開發者無法充分理解通訊協定參數的意義時，所會發生之情況。
當MCU收到RS485讀寫命令時，會依據secTimeout數值作為Timeout時間設定，當Timeout未逾期又再次收到RS485讀寫命令時，MCU將會回傳Busy訊息，表示再次收到的RS485讀寫命令不被接受，此時正確的作法是等待secTimeout過後再傳送上次不被接受的RS485讀寫命令。如果網路忽略Busy訊息而繼續傳送，則會發生有些命令被忽略以及誤解如下：
如圖3，假設有三個溫度計由MCU經RS485讀取後，再以網路回傳給IoT使用者，因此有三筆溫度讀數必須被讀取，而每一筆讀取皆需要一段時間。當第一筆1st CMD(欲讀取第一個溫度計之讀數)進入MCU之後，MCU就處於忙碌狀態直到處理完第一筆1st CMD，並回傳1stReSponse Protocol(RSP)，故隨之而來的2nd CMD、3rd CMD與再次詢問的1st CMD就會被MCU通知Busy狀態。
 |
| 圖3 應用情境 |
此時若IoT使用者無視Busy狀態，片面認知若無RSP即是MCU Timeout，即可再傳送CMD，就會產生圖4的似是而非結果，即誤以為1st RSP是最近的CMD回傳的結果，而最近的CMD即是再次傳送的1st CMD，但該RSP應對應到的是第一筆的1st CMD，這結果將會導致誤解第一次的1st CMD、2nd CMD、3rd CMD產生Timeout，若IoT使用者又加上timeout即是無連接溫度計的判斷，將會產生溫度計連線斷斷續續的錯覺。
 |
| 圖4 應用範例一 |
以上範例是1st RSP剛好對應到再次詢問的1st CMD，如果無法剛好對應到，又會產生怎樣的認知呢？此情況即為圖5的應用範例二，第一次的1st CMD、2nd CMD、3rd CMD傳送完成後，1st RSP回傳，如果不參考Busy資訊，又片面誤解1st RSP是最近CMD回傳的結果，會產生把1st CMD回應當成3rd CMD回應，而2nd CMD、3rd CMD的回應永遠不存在。
 |
| 圖5 應用範例二 |
舉例來說，假設有三個防火災煙霧偵測器，分別安置在1、2、3樓，1st CMD、2nd CMD、3rd CMD分別對應讀取1、2、3樓的防火災煙霧偵測器，上述情形將會形成1樓煙霧偵測狀態將永遠被誤認為3樓的狀態，而2、3樓偵測將是永遠失效的，這結果將會導致當火警發生時錯將1樓當成3樓、而2、3樓無法偵測，延誤救災時機。
以上之舉例說明或許一時不易理解，我們再以寓言故事之方式，講解上述實例。
將軍下令：「斥候長，去一號城門查看是否有敵軍來襲，若有速回，去偵查大約一個單位時間，確定沒有再回來稟告。」
斥候長：「諾」(領兵前往)。
19分鐘過去(時間點第19分鐘末)：
將軍下令：「斥候長，去二號城門查看是否有敵軍來襲，若有速回，去偵查大約一個單位時間，確定沒有再回來稟告。」
眾將士：「將軍，斥候軍隊尚未回營。」
(將軍充耳不聞....)
再19分鐘過去(時間點第38分鐘末)：
將軍下令：「斥候長，去三號城門查看是否有敵軍來襲，若有速回，去偵查大約一個單位時間，確定沒有再回來稟告。」
眾將士：「將軍，斥候軍隊尚未回營。」
(將軍充耳不聞....)
再20分鐘過去(時間點第58分鐘末)：
將軍下令：「斥候長，去一號城門查看是否有敵軍來襲，若有速回，去偵查大約一個單位時間，確定沒有再回來稟告。」
眾將士：「將軍，斥候軍隊尚未回營。」
(將軍充耳不聞....)
再2分鐘過去(時間點第60分鐘末)：
斥候長：「將軍，一號城門無敵軍來襲。」
將軍：「知道了，斥候長，去二號城門查看是否有敵軍來襲，若有速回，去偵查大約一個單位時間，確定沒有再回來稟告。」
斥候長：「諾」(領兵前往)。
在時間點第79分鐘末、第98分鐘末時亦發生對話如下：
將軍下令：「斥候長，去三(一)號城門查看是否有敵軍來襲，若有速回，去偵查大約一個單位時間，確定沒有再回來稟告。」
眾將士：「將軍，斥候軍隊尚未回營。」
(將軍充耳不聞....)
再20分鐘過去(時間點第118分鐘末)：
將軍下令：「斥候長，去二號城門查看是否有敵軍來襲，若有速回，去偵查大約一個單位時間，確定沒有再回來稟告。」
眾將士：「將軍，斥候軍隊尚未回營。」
(將軍充耳不聞....)
再2分鐘過去(時間點第120分鐘末)：
斥候長：「將軍，二號城門無敵軍來襲。」
將軍：「知道了，斥候長，去三號城門查看是否有敵軍來襲，若有速回，去偵查大約一個單位時間，確定沒有再回來稟告。」
斥候長：「諾」(領兵前往)。
10分鐘過後(時間點第130分鐘末)：
斥候長：「敵人已兵臨城下，城門已破。」
將軍：「快，全軍迎敵。」
事後：城破。
戰後檢討：
元帥：「將軍，在時間點0分時已見敵軍來襲，為何在時間點第130分鐘末城門破才帶兵援救？」
將軍：「我每隔19分鐘均會要求斥候輪巡每個城門，一定是斥候偷懶，來人，斬了！」
斥候長：「冤枉啊元帥....每個時間單位是1小時，我根本沒聽到時間點第38分鐘末的命令阿....」(已被斬)。
上述故事說明應用範例一之實際運作情況，「將軍充耳不聞」指的就是不看Busy資訊，「一個單位時間」指的就是Busy Time，該敘述說明將軍(也就是IoT使用者)的錯誤認知，進而發生無可挽回之狀況。
元帥覺得守城或許不是該將軍的專長，故令該將軍攻城，出征途中遇到三條路。
新斥候長：「將軍，我想將一個單位時間修改為18分鐘，但由於18分鐘有點趕，可能會有些延遲。」
將軍依然下令：「斥候長，去一號道路查看是否有敵軍埋伏，若有速回，去偵查大約一個單位時間，確定沒有再回來稟告。」
新斥候長：「諾」(領兵前往)。
19分鐘過去(時間點第19分鐘末)：
將軍下令：「斥候長，去二號道路查看是否有敵軍埋伏，若有速回，去偵查大約一個單位時間，確定沒有再回來稟告。」
眾將士：(知道提醒也沒用)。
再2分鐘過去(時間點第21分鐘末)：
新斥候長：「將軍，一號道路沒有敵軍埋伏。」
將軍：「很好，快，眾將士快進入二號道路前往目的地，我剛剛問的是二號道路狀況，回應沒有敵軍埋伏，二號道路安全！！」
(結果遇到埋伏)
第二個故事說明偵查結果對應錯誤而導致危機。
上述兩個故事看似荒誕，但在IoT軟硬體整合確實時常發生類似狀況；將軍如果對於士兵調遣規則不熟稔，也就是IoT使用者，在IoT軟硬體整合就會產生誤解。
如何避免上述的狀況呢？主要有兩個關鍵：IoT使用者必須注意到，不能忽略Busy訊息；當RSP回來時要確定該RSP是對應哪個時間點的CMD。
由上述探討可知，無論MCU與IoT通訊協定訂定得如何完整，只要IoT使用者對通訊協定存在錯誤認知，即會產生錯誤的資訊整合結果。故使用IoT網路時，一定要建立對通訊協定之完整認知，以避免不必要的誤解與裝置非預期之行為。
(本文作者皆任職於工研院資通所)