4 數據平臺
爲什麼會有物聯網的數據平臺呢？從某種程度上說，數據平臺纔是最具物聯網特色的東西。雖然提到物聯網，很多人腦海中第一個閃現的是傳感網絡，但實際上，如果你讀過前幾章就會發現，實際上所謂物聯網，獲得表徵物體的數據是關鍵，而表徵物體數據的獲取辦法很多，並不見得要另外加裝傳感網絡——這一點在工業領域尤爲明顯。這是因爲，因爲工業領域自動化控制的需求，實際上很多關於機器的數據已經被獲取了，只不過，這些數據暫時還侷限在直接控制機器的控制系統中，沒有被更大內涵的系統所用於更廣泛的目的罷了。既然物聯網的而核心在於表徵物體的數據的使用，那麼數據平臺位於核心地位也就順理成章了。
數據平臺還有一個使其成爲物聯網核心商業模式和產品形態的潛質：數據平臺是最容易產品化的。沒錯，雖然不同的業務對數據的最終利用方式千差萬別，而不同行業現場對數據的採集獲取手段也千差萬別，但是數據的獲取、存儲和基本處理邏輯卻是驚人的相似。
4.1 數據收發方式
在第1章中，我們把數據分爲以下幾類，從平臺的角度上看，其手法方式一般也不同。
4.1.1 時序數據
時序數據是物聯網數據平臺的基本數據，也是物聯網之區別於普通的面向人的聯網應用的地方。時序數據的特點是，一般是均勻的數據流。也就是說，對於一個物體、設備，一旦開始發送數據，則一般是按照一定的採樣週期發送的均勻、持續的數據。但是這並不是說物聯網就沒有一般面向人的互聯網那種數據峯值-估值的變化。就以工業互聯網爲例，因爲多數工廠是白天工作，所以很明顯白天的日常工作時間端，比如說從8點到18點之間，數據處於一個高位的平臺，因爲一般這個時候設備都在上電運行。但是這種高位相對難以出現尖峯，因爲設備時序數據一般都是均勻採集併發送到平臺的。但是這也造成了另外一個問題：類似電網的峯谷差，我們在構建數據平臺的時候，計算能力和帶寬也必須按照預測的峯值來設計。對於油氣管道之類的物聯網，這個數據峯谷差可能基本上是不存在的，因爲油氣、城市水網等系統是全天24小時都處於工作狀態的，其相關的數據也一直在向平臺提交，而且和水網、油氣的負載沒有關係。但是對於離散製造業，一般是白天大家都在加工，所有的機器都在提交數據，而晚上只有少部分工廠在輪班工作，纔會提交數據。總之，在構建數據接收模塊乃至整個服務端的時候，物聯網系統所服務的業務和客戶的特點需要加以考慮。
時序數據在出現的時候一般是一個均勻的數據流。借鑑實時數據庫的實現方式，我們在接收過程中要考慮數據在內存中的緩存，以防因爲雲端系統的算力問題丟失數據。所幸的是，目前大多數數據庫都具有這種緩存能力。
另外需要注意的一點就是數據的重發。數據重發是數據平臺和設備端之間的互動。當網絡通道出現問題的時候，設備端可能會選擇丟棄數據，但更好的實現方法也許是在就地存儲未能發送到服務端的數據，並在網絡信道暢通後集中發出。這樣的策略雖然無法緩解數據的實時性所面臨的挑戰，但至少保證了數據在時間軸上的完整性。考慮到物聯網服務端很多應用四基於統計和分析的，這種對數據完整性的保障經常是值得投資的，甚至是必須的。
4.1.2 事件數據
類似設備告警等數據是偶發的，雖然也帶有時間戳，但是其一般沒有特別的規律。此類數據的接受對及時性和完整性都非常強調，因爲一個沒能及時收到或者乾脆被丟失的報警數據可能是致命的。當然也未必需要過度地追求，因爲很多場合下並沒有那麼糟糕：現場的自動化控制系統還有第一道防線。也正是如此，在設計自動化系統的時候，必須要注意不能因爲有更上一個層次的物聯網系統而有任何的疏忽；而將原本屬於自動化系統的安全保障工作轉移到物聯網系統中，更是不可原諒的錯誤。
4.1.3 指令數據
指令數據主要是從服務器發送到設備的。可能並不帶時間戳，但是建議最好是帶有，因爲有時指令的有效性和時間可能有關係：互聯網並沒有保證數據包按照你預想的次序到達的能力，如果你的應用中很強調這一點就要自己建立識別指令次序或指令發出的時間的機制，以便拋棄過期的指令，或者按照正確的次序來執行指令。
4.1.4 文件數據
文件類數據是雙向的，但是一般不強調及時性。只要文件被完整無誤地傳遞即可。FTP等現成的協議很多，所以此類數據一般並不需要過多關注。但是無論如何，“無誤”還是要關注的，起碼的校驗，如MD5，還是有必要的。
4.1.5 媒體數據
實際上爲了配合組建完整的業務平臺，有時還要加上媒體數據。主要是視頻、音頻的採集。此類數據，尤其是視頻數據，實際上已經有很完善的解決方案。但是之前一般是在安防等領域應用的，並不太被理解爲物聯網數據。但是最近幾年，隨着AI識別等技術的應用，從視頻圖像中自動識別設備狀態也成爲一項設備故障診斷技術，所以此類數據也開始和物聯網平臺發生關聯。比如某數控機牀廠商開發的關於斷刀的在線診斷，就是在加工中心中附加一個攝像頭採集實時視頻上傳到服務器，由服務器判斷是否發生了刀具斷裂的事故。一旦系統判定發生斷刀，會立即向加工中心發送停機指令以防止故障影響的進一步擴大。
4.2 數據存儲
當然是採用各種數據庫來實現。此時的選項其實很多。無論是SQL類關係型數據庫還是NoSQL類菲關係型數據庫都有自己的用武之地。典型的情況是將二者結合，兩個數據庫分別存儲不同的數據類型，以期達到整個系統的最優化。物聯網業務目前在各類企業中都還處於較新的業務，所以不確定性較大，數據庫內部架構也可能會因此發生持續的調整。因此在設計關係型數據庫表結構的時候要有一定的預見性，或者採用某些對此類情景有設計考量的數據庫。
4.3 數據模型
爲什麼要提到數據模型？主要是我們要考慮到進一步的數據整合、交換和業務開發的過程。實際上數據模型在非物聯網業務中已經開始了應用，因爲大家都在力圖尋找一種可以對不斷變化的業務具有一定自適應能力的系統。而一個具有一定自解釋能力的數據模型對開發普適的數據處理工具至關重要。以製造業爲例，OPC UA協議就包含了一個可以自定義數據模型的機制，但是遺憾的是其並沒有爲各行業提供標準或者流行的模型。這種模型一般是某個企業、行業協會甚至國家標準組織來定義並在一定範圍內執行的。而MTConnect協議則自帶了一個建議的標準的機牀模型，使得開發機牀聯網系統的時候，做一個可以對接不同廠商的機牀的系統成爲一種可能。
數據模型方面的工作迄今爲止還是需要各行業不斷努力去完善。
4.4 數據整合
數據整合的發起者實際上是上層的應用平臺的各類業務邏輯，雖然人們因爲這個過程叫做數據整個而將其歸爲數據平臺。當然，這麼做的原因也因爲數據整合雖然與具體的業務邏輯息息相關，但實際上是可以抽象爲各種可配置的算法和自動觸發的服務的。市場上這種面向開開發者的物聯網平臺，其核心技術之一，如果不是最核心的技術的話，就是各種數據自動處理的引擎。這些引擎有的可以在人機界面上進行配置，類似工業自動化中廣泛使用的組態軟件，也有的只是一系列的API，需要採用某種開發語言去調用。而後一種情況下，開發者往往會在應用平臺爲數據整合提供一個自己定義的配置界面。
4.5 數據平臺的計費
較早出現的數據平臺一般採取虛擬機銷售的方式。所以實際上是按照虛擬機的配置來收費的。虛擬機上的服務無論你是否使用、使用的量如何，並不影響費用的計算。而隨着可配置化的數據整合引擎的出現和各類功能的服務化，越來越多的物聯網平臺開始採用按照服務收費的，更加細的粒度的收費模式。
4.6 數據平臺案例
實際上，很多互聯網背景的物聯網平臺基本上都是數據平臺模式。如Amazon的AWS雲。國內一些電信運營商的物聯網平臺，如中國移動的OneNET也是。此類業務的運營主體的特點是自身並沒有可最終交付的物聯網業務，但是具有網絡帶寬、計算能力等資源，另外業務層面追求規模，所以一般會走這條道路，也往往只能走這條道路。
上一篇：工業物聯網：3 網絡層（2）
下一篇：工業物聯網：5 業務平臺