對於冷鏈系統來說，IOT的管理重點在於防範未然，也就是避免溫度都已偏離正常範圍，而管理者卻毫不知情。嚴格來說，IOT就是一種可連上網路的環境資料搜集器(data collector)，然而，光是蒐集環境資料，就能讓冷鏈系統升級嗎？

        冷鏈物流所需要的IOT裝置有很多種，包括GPS、二氧化碳、溫度、濕度、重力加速(G-sensor)、光線、氣壓、車廂艙門啟閉，物流車現存油量、車廂總重量、空調機運轉狀況，有的IOT裝置甚至可用來偵測特定氣味是否存在。

        或許有人認為IOT裝置都很貴，不適合大量佈署，更遑論多品牌佈署，其實這是錯誤觀念，每組IOT的核心裝置其實都不到3元美金，就算再加入電池、無線連網最低都不到5元美金，真正昂貴的並非IOT裝置本身，而是整體的系統整合與數據串聯。

        IOT的導入絕對不是只有買入硬體、把網路導通，然後把數據接到資料庫這麼簡單。IOT硬體只是冰山一角，浮在水面上的是IOT硬體本身，然而藏在水面下的，還包括事件定義與資料格式、傳送與儲存、資訊安全、跨鏈整合、數據分析與應用等五個面向。唯有掌握整座冰山全貌，IOT裝置才能為冷鏈系統創造最大效益。

事件定義與資料格式

        運輸過程中會發生許多事件(event)，大致上可分為正常事件、異常事件、跨鏈交接事件三種。簡單的說就是系統必須要能記錄下幾點幾分，發生了哪個事件，而且重要事件必須能及時警告管理中心。

        例如車廂門開啟/關閉、引擎啟動/關閉、駕駛員下車、空調機啟動/關閉，這類事件必須能由IOT系統全自動記錄並回報，這些是屬於正常事件；當溫度連續三筆記錄到上升、或是溫度已偏離正常範圍超過一分鐘，這類屬於異常事件；最後一種是長距離冷鏈運輸會發生的跨鏈交接，例如從低溫倉交接給運輸公司、運輸公司交給貨棧倉、貨棧倉交給航空公司…等。凡是異常事件，就應該對應指定的訊息管理者，例如A事件發生，就通知甲、乙二個人，這樣才是IOT導入的積極意義。

        在資料格式方面，一般冷鏈車廂溫度再怎麼極端，也頂多介於攝氏-128至127度之間，之前的COVID疫苗，最低的溫度要求是-80攝氏度。因此，在資料庫格式上只需使用如「tiny integer」這樣的資料型態(data type)就可儲存，其儲存空間只佔1byte。

        然而一般的程式設計師可能都會直接使用「integer」這樣的資料型態，這種方式一筆溫度就至少佔據4 bytes，其數字範圍可大到攝氏-2147483648到2147483647度。很明顯的，這就是無意義的設計；也有的工程師會使用浮點數(float)方式記錄溫度，例如22.53、18.7，這種思考立意良善，數據上看起來會比單純的整數要精確，但資料格式也是佔據4 bytes。然後，必要性為何？車廂溫度22.56、22.44、21.1度，相對於22度、21度，是否會使得空調機的控制作為就變得不一樣？

        IOT所儲存的都是大數據，動輒幾億筆資料，如果在設計階段沒有仔細考慮，後續就會經常發生儲存空間不足，或是資料調閱速度慢的狀況。

記錄方式

        IOT數據都是相當瑣碎的資料，與一般訂單資料、生產資料不同，IOT的數據特性就是短期間就會產生大量資料，如果使用傳統的關聯式資料庫例如Oracle、Microsoft SQLserver儲存這類瑣碎資料其實相當不划算，改用新式的NOSQL資料庫如MongoDB才能用最少成本滿足儲存需求。

        每三分鐘記錄一筆溫度，跟每一分鐘記錄一筆溫度，會影響IOT裝置的耗電與傳輸頻寬，越頻繁記錄，耗電量越大，而且所需要儲存的空間也越大。

        另一方面，許多業者會選擇使用第三方雲端系統，例如Amazon的AWS，微軟的Azure、Google Cloud等，儲存的可靠性當然沒話說，但是長期對企業又是一筆負擔，真的有必要把全年度所有的IOT數據都放到第三方雲端上嗎？

        其實最佳的作法是IOT資料發送時，就同時發送雲端，以及企業內部本地端做二份儲存，一旦資料完成分析，並驗證數據無誤，即可刪除雲端資料。也就是說，雲端系統只儲存最近三個月數據，更長期的數據保存其實可企業內部自行處理。如此即可兼顧成本與數據可靠性。

【如欲閱讀全文，敬請訂閱】