日韩视频在线精品视频免费观看-日韩视频在线观看中字-日韩视频在线观看一区-日韩视频在线观看免费-日韩视频在线观看-日韩视频在线播放

• 關鍵詞： loT參考架構
• 摘要：本篇我們將側重于這一參考架構中的架構和概念實現。需要注意的是，我們不能隨便挑選一個參考架構并立刻“嘗試實現”，而是需要將其作為一種“樣式”，據此定義要在IoT“系統”中使用的不同組件。

　　本篇我們將側重于這一參考架構中的架構和概念實現。需要注意的是，我們不能隨便挑選一個參考架構并立刻“嘗試實現”，而是需要將其作為一種“樣式”，據此定義要在IoT“系統”中使用的不同組件。乍看之下具體實現的結果可能與參考架構本身的結構有較大差異，但如果謹慎地將架構與所要實施的組件一一對應，最終將獲得完全相同的結果。

　　為了將RILA與實際用例相互對應，我們從不同行業挑選了兩個用例，這兩個用例可能很快就會變為現實。下圖展示了第一個用例，就叫它“冰箱”用例吧：

　　這個用例的基本想法是在可能出現電力峰值(電網丟負荷)的時候自動觸發(全城或部分地區的)電冰箱的制冷操作，借此降低電力峰值對電廠造成的危險。因此該用例的目標在于由電廠觸發大量智能電冰箱的“制冷”操作。上圖顯示的虛線代表冰箱到電廠的(可選)反饋環路，借此電廠可以評估共可以觸發多少電冰箱進行制冷，并借此確定冰箱的數量是否足以降低峰值，或是否有必要采取其他(可選)措施。下表列出了該用例涉及的對象，用例想要實現的目標，前提條件，成功場景概括，以及后續情況：

　　涉及的對象最終用戶，冰箱制造商，供電局，冰箱的板載系統，電廠的控制系統

　　目標電廠控制系統 向 冰箱板載系統 發送制冷工作信號，讓冰箱在某個同一控制的集中時間點開始制冷，避免出現電網丟負荷的情況。

　　前提條件冰箱制造商 和 供電局 共同制定一套通信協議，通過這個協議讓冰箱接收控制信號，并發送相關狀態信息。

　　成功場景概括最終用戶 購買 冰箱制造商 生產的冰箱。

　　最終用戶 配置冰箱連接到互聯網。

　　冰箱的板載系統 連接到 電廠的控制系統 。

　　供電局的電廠控制系統 發現出現電力峰值，向 冰箱的板載系統 發送控制信號。

　　冰箱的板載系統 收到這個信號，判斷冰箱內部溫度是否足夠低。

　　冰箱的板載系統 將即將制冷的信息發送給 電廠控制系統 。

　　電廠控制系統 收到 冰箱板載系統 發送來的信息，對其進行處理并保存起來。

　　冰箱板載系統 啟動冰箱壓縮機開始制冷。

　　后續情況冰箱板載系統 開始制冷， 電廠控制系統 知道冰箱已經開始制冷了。

　　冰箱板載系統和電廠控制系統需要構建并監視相關的上下文情境條件。這個用例中主要涉及兩種條件：

　　電廠控制系統的上下文情境

　　冰箱板載系統的上下文情境

　　冰箱板載系統需要管理的上下文情境更為簡單一些，通過這種上下文，冰箱板載系統可以決定是否需要制冷。電廠控制系統的上下文情境更為復雜，需要通過冰箱的上下文情境做出相應決策。然而在這個場景中，電廠的上下文情境無需對外發布，只要將操作命令發送至冰箱即可。

　　看過第一個用例后，可以考慮將我們的參考架構RILA與其進行對應。我們定義了包含下列6層內容的架構：

　　應用程序集成(Application Integration)

　　物件集成(Thing Integration)

　　上下文管理(Context Management)

　　數據管理(Data Management)

　　設備管理(Device Management)

　　設備集成(Device Integration)

　　下圖展示了架構中不同層與這個用例的對應關系。

　　上圖不同層使用不同顏色顯示，分為黑色和灰色。灰色層通常可以用非常簡單的方式設計而來，甚至在某些場景中是不需要的。

　　大致來看，兩端都存在所有6層內容，冰箱和電廠需要通過某種方式實施這6層。然而具體實現的復雜度取決于可用條件和用例要實現的功能。為確定每種物件每層的設計和實施范圍，需要對每種物件(或每種物件對應的領域，如果采用領域驅動的設計方法的話)都有所了解。這里需要注意，上圖所示場景在具體描述上可能有所差異，對冰箱的上下文情境進行管理只是一個范例，實際情況可能更加復雜，因此用黑色表示。這個用例中需要使用“智能”的冰箱，而本例中我們設想的冰箱是相當“笨”的。參考架構與場景的映射是一回事，每一層的設計是另一回事。下文將介紹該場景中不同層面的具體設計。

　　在這個場景中，我們假設用戶可以使用自己的智能手機與冰箱通信。為了與智能手機應用通信，冰箱必須具備應用程序集成層。另外可能還需要在供電局一端實施某種程度的應用程序集成。不過依然有必要考慮該用例是否需要涉及這個問題(畢竟本例只需要考慮電廠控制系統向冰箱發送控制信息)。

　　兩端都需要實現物件集成，具體方式并不復雜。在這樣一個原型中，物件發現模塊可能相當簡單，我們可以假設冰箱隨時都能與電廠通信。最終通信連接的建立則可以使用成熟的規范。

　　在上下文管理方面，首先需要在冰箱的上下文情境和要向冰箱發送的操作指令之間達成一致。電廠端的上下文管理略顯復雜，但冰箱端相對簡單一些。電廠端在這里可以視作一個黑盒子，大部分情況下我們只需要將其與檢測和預測峰值的現有系統集成即可。一旦檢測到峰值便觸發冰箱執行制冷操作，并通過物件集成將指令下發至已注冊的冰箱。冰箱接到操作指令后開始判斷是否需要制冷(在首個原型中可通過簡單的時間約束實現)并將判斷結果發回給電廠。

　　類似的數據管理機制在冰箱上實現起來很簡單，但在電廠端略微復雜。冰箱基本上只需要記錄什么時候溫度足夠低，什么時候需要再次制冷(可通過溫度傳感器實現)。電廠需要決定冰箱制冷到足夠低的溫度之后所耗費的電力是否可以降低峰值。如果還不夠，則需要進一步執行后續的其他操作。

　　冰箱端還需要設備管理和設備集成層。電廠端可以假設已具備負責處理峰值預測和決策的系統，但該系統需要與我們的架構集成在一起(可通過應用程序集成或物件集成的方式實現)。

　　這里需要注意，為了讓這個方案設計投入實用，還需要與兩端(電冰箱制造商和供電局)的領域內專家進行合作，才能更好地理解這兩個領域并開發出足夠好的設計。

　　盡管我們的設計距離完善還很遠，不過依然可以先來看看實現方面的創意(也許可以開始快速創建第一個原型)。上文提過，我們希望最開始的設置盡可能簡單。目前已經有裝備顯示器和各種功能的冰箱，例如新一代 Samsung Family Hub ，此類型號的功能已經遠遠超出需求(不過依然可以用)。在這個場景中，制造商并沒有為冰箱提供完整的平臺，但提供了可與冰箱通信的智能手機應用。這樣的冰箱需要具備：

　　自帶互聯網連接和通信接口，這樣才能隨時與電廠通信(物件集成)。

　　供用戶通過智能手機訪問的接口，這樣才能讓用戶打開或關閉與電廠通信的功能(應用程序集成)。

　　相關傳感器和邏輯，這樣才能讓冰箱在接到電廠指令后決定是否可以開始制冷。

　　實現首個原型的平臺可以考慮配合使用Google App Engine和Google Brillo。雖然Brillo尚未正式發布，但已經可以開始設想基于Brillo操作系統的冰箱了。這里可以使用Google Cloud Messaging在智能手機、云冰箱，以及電廠之間實現通信。下圖展示了使用Google Brillo和Cloud Messaging搭建的簡化環境。請注意，在這里Google只是范例，使用Apple HomeKit、Windows Azure或開源平臺也可以實現類似的效果。

　　在冰箱端我們將整個棧打包到Brillo中。對于物件集成層的通信，可以使用Cloud Messaging API。不過電廠在這里依然被看作黑盒子，因為電廠具體使用什么技術無關緊要(反正電廠里通常已經具備現成的系統)，我們只需要確保電廠的控制系統(或以此為基礎的集成組件)能夠實現Brillo和Cloud Messaging API所實施的通信標準即可。

　　當然整個系統也可以用相互獨立的方式實現。拆箱即用的標準化，是諸如Google Brillo這樣的平臺所提供的優勢之一，用戶可以借此對整個系統輕松進行縮放。

　　至此已經完整介紹了第一個用例。為了證明這套參考架構的靈活性，下文將介紹第二個用例。從中也可以看到RILA所定義的“必備IoT組件”是如何融入整個場景的。

　　在第二個用例中，有一家銷售汽車保險的保險公司希望更清晰地預測(從保險業務的角度來看)哪些客戶是“良性”的，哪些是“惡性”的。這家保險公司希望使用駕駛行為數據實現這一目標(也就是所謂的 數據科學 )。該用例的大致情況如下圖所示。

　　在第一個場景中，這家保險公司需要獲得大量數據，并通過數據科學為保險業務定義“良性”和“惡性”司機的類別。這些數據并不需要對應到具體司機，匿名數據就夠了。數據越多結果越精確。因此這家保險公司希望與汽車制造商合作以獲得所需數據。

　　在第二個場景中，(通過對第一個場景進行擴展)這家保險公司需要根據投保人的個性化駕駛行為進一步定制每份車險的保險策略。這一過程由上圖中虛線箭頭所代表。

　　下表描述了該用例涉及的對象，用例想要實現的目標，前提條件，成功場景概括，以及后續情況：

　　涉及的對象保險公司、保險公司的系統、汽車制造商、汽車制造商的系統、車主、車載計算機

　　目標保險公司 收集有關具體車型盡可能多的匿名駕駛行為數據，借此針對具體車型的駕駛行為數據調整保險策略。

　　前提條件保險公司 和 汽車制造商 確定數據交換策略和涉及的車型。 保險公司 為 汽車制造商 提供的數據支付一定費用。 車主 通過匿名分享自己數據得到一定好處(例如 汽車制造商提供的低價維修服務)。

　　成功場景概括車主 購買一輛車。

　　車載計算機 詢問 車主 是否要將駕駛行為數據匿名分享給 汽車制造商 (以及可能的第三方)。

　　車主 同意分享某些數據。

　　車載計算機 按照預定義的時間間隔，定期將匿名駕駛行為數據發送到 汽車制造商的系統 。

　　汽車制造商的系統 存儲駕駛行為信息，并通知 保險公司的系統 某一車型有新數據可用。

　　保險公司的系統 通過 汽車制造商的系統 收集駕駛行為數據，并將其存入決策工作使用的數據池。

　　保險公司 的系統將新數據以功能的形式集成于保險策略使用的預測模型。

　　后續情況保險公司 可以使用駕駛行為數據更詳細地計算保險策略。(隨后即可將其用于為保險公司銷售人員提供指導等用途。)

　　這里我們打算專注于第一個場景。與冰箱的用例類似，我們可以將RILA的不同層面映射為下圖所示的系統組件。

　　對于保險公司的用例，只需要在汽車中實施完整的RILA堆棧，因為需要集成的設備都在汽車中，其他操作都是在數據傳輸層面上進行的。在這里可能有人會質疑我們對“物件”的定義。只有設備才算是“物件”嗎?我們的定義并不這樣認為，并非只有設備才是物件。不過此處的合理推論是，并非所有物件都必須具備設備集成和設備管理層(沒有設備，當然也就不需要進行設備集成和管理)。

　　汽車需要在應用程序集成層具備一些接口，這樣車主才能與系統通過某種形式通信(車載系統通常已經具備這樣的能力)。數據傳輸至汽車制造商的系統后，只需要進行少量的上下文情境管理、數據管理，以及物件集成工作即可實現用例需求。保險公司(以及汽車制造商的系統)可能也需要進行應用程序集成，因為還需要使用這些數據執行某些任務，例如運行預測模型的軟件必須能通過某種方式訪問這些數據。

　　這個保險公司用例的實現想法在于：汽車的車載計算機可以充當一種應用平臺。隨后用戶即可下載保險公司(與汽車制造商合作)提供的應用，借此讓用戶控制什么可以分享，什么不能分享。取決于用戶的分享意愿，可以由保險公司或汽車制造商為車主提供一定的好處(這就為我們提供了一種理想的業務模式)。一旦實現最終的個性化，就可以通過了解上下文情境的保險策略實現“駕駛即付費”的業務模式，并進一步擴展為“按照駕駛方式付費”的模式。

　　本文介紹的這兩個用例較為寬泛，除了所描述的場景外，通過本文提供的用例還可以構思出很多不同使用場景。為了針對不同用例打造真正實用、有價值的設計，還需要對相關領域有所了解。

　　確定用例場景后，就可以確定要在參考架構(例如RILA)中使用哪些IoT組件。通信和安全措施的實施方式所實現的標準化程度越高，就能越容易地將IoT系統與以后部署的其他IoT系統相集成。無論其他保險公司或汽車制造商打算使用保險公司用例，或其他電廠或冰箱(制造商)打算使用冰箱用例，只要具備確認有效的合適結構(例如類似Google Brillo這樣的機制)，集成工作就會變得更簡單。參考架構只是為了向大家提供一種通用的模式，幫助大家避免在實際開發中“漏掉”某個重要的組件或設計因素。

　　總之需要強調的是，最重要的第一步始終是一開始就從功能層面上定義要實現的用例，隨后再考慮具體的技術規范細節。

　　為了確定希望通過系統實現的最終目的，還要明確定義涉及的對象和想要實現的目標。雖然這是一種眾所周知的范式，但對IoT世界中的應用程序和系統開發工作，這一點尤為重要，因為具體用例通常更復雜，包含的場景也更多樣。領域驅動的設計指南可以幫您實現更有價值的靈活設計。

　　通過諸如RILA等參考架構，我們可以了解實現IoT應用程序的過程中必不可少的一些組件。通過明確具體用例所要實現的功能規范，就可以確定參考架構中不同組件的具體設計方式。通過功能層面上對用例和設計進行結合，即可確定最終的技術規格和實現方法。隨后便可結合專業技能確定將現有平臺用于何處才能提供一個或多個參考架構組件所要實現的功能，甚至如何使用現有平臺組成某些用例所需的整個技術堆棧。