-
關(guān)鍵詞：
loT參考架構(gòu)
- 摘要：本篇我們將側(cè)重于這一參考架構(gòu)中的架構(gòu)和概念實(shí)現(xiàn)。需要注意的是，我們不能隨便挑選一個(gè)參考架構(gòu)并立刻“嘗試實(shí)現(xiàn)”，而是需要將其作為一種“樣式”，據(jù)此定義要在IoT“系統(tǒng)”中使用的不同組件。
本篇我們將側(cè)重于這一參考架構(gòu)中的架構(gòu)和概念實(shí)現(xiàn)。需要注意的是，我們不能隨便挑選一個(gè)參考架構(gòu)并立刻“嘗試實(shí)現(xiàn)”，而是需要將其作為一種“樣式”，據(jù)此定義要在IoT“系統(tǒng)”中使用的不同組件。乍看之下具體實(shí)現(xiàn)的結(jié)果可能與參考架構(gòu)本身的結(jié)構(gòu)有較大差異，但如果謹(jǐn)慎地將架構(gòu)與所要實(shí)施的組件一一對應(yīng)，最終將獲得完全相同的結(jié)果。
為了將RILA與實(shí)際用例相互對應(yīng)，我們從不同行業(yè)挑選了兩個(gè)用例，這兩個(gè)用例可能很快就會(huì)變?yōu)楝F(xiàn)實(shí)。下圖展示了第一個(gè)用例，就叫它“冰箱”用例吧：
這個(gè)用例的基本想法是在可能出現(xiàn)電力峰值(電網(wǎng)丟負(fù)荷)的時(shí)候自動(dòng)觸發(fā)(全城或部分地區(qū)的)電冰箱的制冷操作，借此降低電力峰值對電廠造成的危險(xiǎn)。因此該用例的目標(biāo)在于由電廠觸發(fā)大量智能電冰箱的“制冷”操作。上圖顯示的虛線代表冰箱到電廠的(可選)反饋環(huán)路，借此電廠可以評估共可以觸發(fā)多少電冰箱進(jìn)行制冷，并借此確定冰箱的數(shù)量是否足以降低峰值，或是否有必要采取其他(可選)措施。下表列出了該用例涉及的對象，用例想要實(shí)現(xiàn)的目標(biāo)，前提條件，成功場景概括，以及后續(xù)情況：
涉及的對象最終用戶，冰箱制造商，供電局，冰箱的板載系統(tǒng)，電廠的控制系統(tǒng)
目標(biāo)電廠控制系統(tǒng) 向 冰箱板載系統(tǒng) 發(fā)送制冷工作信號，讓冰箱在某個(gè)同一控制的集中時(shí)間點(diǎn)開始制冷，避免出現(xiàn)電網(wǎng)丟負(fù)荷的情況。
前提條件冰箱制造商 和 供電局 共同制定一套通信協(xié)議，通過這個(gè)協(xié)議讓冰箱接收控制信號，并發(fā)送相關(guān)狀態(tài)信息。
成功場景概括最終用戶 購買 冰箱制造商 生產(chǎn)的冰箱。
最終用戶 配置冰箱連接到互聯(lián)網(wǎng)。
冰箱的板載系統(tǒng) 連接到 電廠的控制系統(tǒng) 。
供電局的電廠控制系統(tǒng) 發(fā)現(xiàn)出現(xiàn)電力峰值，向 冰箱的板載系統(tǒng) 發(fā)送控制信號。
冰箱的板載系統(tǒng) 收到這個(gè)信號，判斷冰箱內(nèi)部溫度是否足夠低。
冰箱的板載系統(tǒng) 將即將制冷的信息發(fā)送給 電廠控制系統(tǒng) 。
電廠控制系統(tǒng) 收到 冰箱板載系統(tǒng) 發(fā)送來的信息，對其進(jìn)行處理并保存起來。
冰箱板載系統(tǒng) 啟動(dòng)冰箱壓縮機(jī)開始制冷。
后續(xù)情況冰箱板載系統(tǒng) 開始制冷， 電廠控制系統(tǒng) 知道冰箱已經(jīng)開始制冷了。
冰箱板載系統(tǒng)和電廠控制系統(tǒng)需要構(gòu)建并監(jiān)視相關(guān)的上下文情境條件。這個(gè)用例中主要涉及兩種條件：
電廠控制系統(tǒng)的上下文情境
冰箱板載系統(tǒng)的上下文情境
冰箱板載系統(tǒng)需要管理的上下文情境更為簡單一些，通過這種上下文，冰箱板載系統(tǒng)可以決定是否需要制冷。電廠控制系統(tǒng)的上下文情境更為復(fù)雜，需要通過冰箱的上下文情境做出相應(yīng)決策。然而在這個(gè)場景中，電廠的上下文情境無需對外發(fā)布，只要將操作命令發(fā)送至冰箱即可。
看過第一個(gè)用例后，可以考慮將我們的參考架構(gòu)RILA與其進(jìn)行對應(yīng)。我們定義了包含下列6層內(nèi)容的架構(gòu)：
應(yīng)用程序集成(Application Integration)
物件集成(Thing Integration)
上下文管理(Context Management)
數(shù)據(jù)管理(Data Management)
設(shè)備管理(Device Management)
設(shè)備集成(Device Integration)
下圖展示了架構(gòu)中不同層與這個(gè)用例的對應(yīng)關(guān)系。
上圖不同層使用不同顏色顯示，分為黑色和灰色。灰色層通常可以用非常簡單的方式設(shè)計(jì)而來，甚至在某些場景中是不需要的。
大致來看，兩端都存在所有6層內(nèi)容，冰箱和電廠需要通過某種方式實(shí)施這6層。然而具體實(shí)現(xiàn)的復(fù)雜度取決于可用條件和用例要實(shí)現(xiàn)的功能。為確定每種物件每層的設(shè)計(jì)和實(shí)施范圍，需要對每種物件(或每種物件對應(yīng)的領(lǐng)域，如果采用領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)方法的話)都有所了解。這里需要注意，上圖所示場景在具體描述上可能有所差異，對冰箱的上下文情境進(jìn)行管理只是一個(gè)范例，實(shí)際情況可能更加復(fù)雜，因此用黑色表示。這個(gè)用例中需要使用“智能”的冰箱，而本例中我們設(shè)想的冰箱是相當(dāng)“笨”的。參考架構(gòu)與場景的映射是一回事，每一層的設(shè)計(jì)是另一回事。下文將介紹該場景中不同層面的具體設(shè)計(jì)。
在這個(gè)場景中，我們假設(shè)用戶可以使用自己的智能手機(jī)與冰箱通信。為了與智能手機(jī)應(yīng)用通信，冰箱必須具備應(yīng)用程序集成層。另外可能還需要在供電局一端實(shí)施某種程度的應(yīng)用程序集成。不過依然有必要考慮該用例是否需要涉及這個(gè)問題(畢竟本例只需要考慮電廠控制系統(tǒng)向冰箱發(fā)送控制信息)。
兩端都需要實(shí)現(xiàn)物件集成，具體方式并不復(fù)雜。在這樣一個(gè)原型中，物件發(fā)現(xiàn)模塊可能相當(dāng)簡單，我們可以假設(shè)冰箱隨時(shí)都能與電廠通信。最終通信連接的建立則可以使用成熟的規(guī)范。
在上下文管理方面，首先需要在冰箱的上下文情境和要向冰箱發(fā)送的操作指令之間達(dá)成一致。電廠端的上下文管理略顯復(fù)雜，但冰箱端相對簡單一些。電廠端在這里可以視作一個(gè)黑盒子，大部分情況下我們只需要將其與檢測和預(yù)測峰值的現(xiàn)有系統(tǒng)集成即可。一旦檢測到峰值便觸發(fā)冰箱執(zhí)行制冷操作，并通過物件集成將指令下發(fā)至已注冊的冰箱。冰箱接到操作指令后開始判斷是否需要制冷(在首個(gè)原型中可通過簡單的時(shí)間約束實(shí)現(xiàn))并將判斷結(jié)果發(fā)回給電廠。
類似的數(shù)據(jù)管理機(jī)制在冰箱上實(shí)現(xiàn)起來很簡單，但在電廠端略微復(fù)雜。冰箱基本上只需要記錄什么時(shí)候溫度足夠低，什么時(shí)候需要再次制冷(可通過溫度傳感器實(shí)現(xiàn))。電廠需要決定冰箱制冷到足夠低的溫度之后所耗費(fèi)的電力是否可以降低峰值。如果還不夠，則需要進(jìn)一步執(zhí)行后續(xù)的其他操作。
冰箱端還需要設(shè)備管理和設(shè)備集成層。電廠端可以假設(shè)已具備負(fù)責(zé)處理峰值預(yù)測和決策的系統(tǒng)，但該系統(tǒng)需要與我們的架構(gòu)集成在一起(可通過應(yīng)用程序集成或物件集成的方式實(shí)現(xiàn))。
這里需要注意，為了讓這個(gè)方案設(shè)計(jì)投入實(shí)用，還需要與兩端(電冰箱制造商和供電局)的領(lǐng)域內(nèi)專家進(jìn)行合作，才能更好地理解這兩個(gè)領(lǐng)域并開發(fā)出足夠好的設(shè)計(jì)。
盡管我們的設(shè)計(jì)距離完善還很遠(yuǎn)，不過依然可以先來看看實(shí)現(xiàn)方面的創(chuàng)意(也許可以開始快速創(chuàng)建第一個(gè)原型)。上文提過，我們希望最開始的設(shè)置盡可能簡單。目前已經(jīng)有裝備顯示器和各種功能的冰箱，例如新一代 Samsung Family Hub ，此類型號的功能已經(jīng)遠(yuǎn)遠(yuǎn)超出需求(不過依然可以用)。在這個(gè)場景中，制造商并沒有為冰箱提供完整的平臺，但提供了可與冰箱通信的智能手機(jī)應(yīng)用。這樣的冰箱需要具備：
自帶互聯(lián)網(wǎng)連接和通信接口，這樣才能隨時(shí)與電廠通信(物件集成)。
供用戶通過智能手機(jī)訪問的接口，這樣才能讓用戶打開或關(guān)閉與電廠通信的功能(應(yīng)用程序集成)。
相關(guān)傳感器和邏輯，這樣才能讓冰箱在接到電廠指令后決定是否可以開始制冷。
實(shí)現(xiàn)首個(gè)原型的平臺可以考慮配合使用Google App Engine和Google Brillo。雖然Brillo尚未正式發(fā)布，但已經(jīng)可以開始設(shè)想基于Brillo操作系統(tǒng)的冰箱了。這里可以使用Google Cloud Messaging在智能手機(jī)、云冰箱，以及電廠之間實(shí)現(xiàn)通信。下圖展示了使用Google Brillo和Cloud Messaging搭建的簡化環(huán)境。請注意，在這里Google只是范例，使用Apple HomeKit、Windows Azure或開源平臺也可以實(shí)現(xiàn)類似的效果。
在冰箱端我們將整個(gè)棧打包到Brillo中。對于物件集成層的通信，可以使用Cloud Messaging API。不過電廠在這里依然被看作黑盒子，因?yàn)殡姀S具體使用什么技術(shù)無關(guān)緊要(反正電廠里通常已經(jīng)具備現(xiàn)成的系統(tǒng))，我們只需要確保電廠的控制系統(tǒng)(或以此為基礎(chǔ)的集成組件)能夠?qū)崿F(xiàn)Brillo和Cloud Messaging API所實(shí)施的通信標(biāo)準(zhǔn)即可。
當(dāng)然整個(gè)系統(tǒng)也可以用相互獨(dú)立的方式實(shí)現(xiàn)。拆箱即用的標(biāo)準(zhǔn)化，是諸如Google Brillo這樣的平臺所提供的優(yōu)勢之一，用戶可以借此對整個(gè)系統(tǒng)輕松進(jìn)行縮放。
至此已經(jīng)完整介紹了第一個(gè)用例。為了證明這套參考架構(gòu)的靈活性，下文將介紹第二個(gè)用例。從中也可以看到RILA所定義的“必備IoT組件”是如何融入整個(gè)場景的。
在第二個(gè)用例中，有一家銷售汽車保險(xiǎn)的保險(xiǎn)公司希望更清晰地預(yù)測(從保險(xiǎn)業(yè)務(wù)的角度來看)哪些客戶是“良性”的，哪些是“惡性”的。這家保險(xiǎn)公司希望使用駕駛行為數(shù)據(jù)實(shí)現(xiàn)這一目標(biāo)(也就是所謂的 數(shù)據(jù)科學(xué) )。該用例的大致情況如下圖所示。
在第一個(gè)場景中，這家保險(xiǎn)公司需要獲得大量數(shù)據(jù)，并通過數(shù)據(jù)科學(xué)為保險(xiǎn)業(yè)務(wù)定義“良性”和“惡性”司機(jī)的類別。這些數(shù)據(jù)并不需要對應(yīng)到具體司機(jī)，匿名數(shù)據(jù)就夠了。數(shù)據(jù)越多結(jié)果越精確。因此這家保險(xiǎn)公司希望與汽車制造商合作以獲得所需數(shù)據(jù)。
在第二個(gè)場景中，(通過對第一個(gè)場景進(jìn)行擴(kuò)展)這家保險(xiǎn)公司需要根據(jù)投保人的個(gè)性化駕駛行為進(jìn)一步定制每份車險(xiǎn)的保險(xiǎn)策略。這一過程由上圖中虛線箭頭所代表。
下表描述了該用例涉及的對象，用例想要實(shí)現(xiàn)的目標(biāo)，前提條件，成功場景概括，以及后續(xù)情況：
涉及的對象保險(xiǎn)公司、保險(xiǎn)公司的系統(tǒng)、汽車制造商、汽車制造商的系統(tǒng)、車主、車載計(jì)算機(jī)
目標(biāo)保險(xiǎn)公司 收集有關(guān)具體車型盡可能多的匿名駕駛行為數(shù)據(jù)，借此針對具體車型的駕駛行為數(shù)據(jù)調(diào)整保險(xiǎn)策略。
前提條件保險(xiǎn)公司 和 汽車制造商 確定數(shù)據(jù)交換策略和涉及的車型。 保險(xiǎn)公司 為 汽車制造商 提供的數(shù)據(jù)支付一定費(fèi)用。 車主 通過匿名分享自己數(shù)據(jù)得到一定好處(例如 汽車制造商提供的低價(jià)維修服務(wù))。
成功場景概括車主 購買一輛車。
車載計(jì)算機(jī) 詢問 車主 是否要將駕駛行為數(shù)據(jù)匿名分享給 汽車制造商 (以及可能的第三方)。
車主 同意分享某些數(shù)據(jù)。
車載計(jì)算機(jī) 按照預(yù)定義的時(shí)間間隔，定期將匿名駕駛行為數(shù)據(jù)發(fā)送到 汽車制造商的系統(tǒng) 。
汽車制造商的系統(tǒng) 存儲(chǔ)駕駛行為信息，并通知 保險(xiǎn)公司的系統(tǒng) 某一車型有新數(shù)據(jù)可用。
保險(xiǎn)公司的系統(tǒng) 通過 汽車制造商的系統(tǒng) 收集駕駛行為數(shù)據(jù)，并將其存入決策工作使用的數(shù)據(jù)池。
保險(xiǎn)公司 的系統(tǒng)將新數(shù)據(jù)以功能的形式集成于保險(xiǎn)策略使用的預(yù)測模型。
后續(xù)情況保險(xiǎn)公司 可以使用駕駛行為數(shù)據(jù)更詳細(xì)地計(jì)算保險(xiǎn)策略。(隨后即可將其用于為保險(xiǎn)公司銷售人員提供指導(dǎo)等用途。)
這里我們打算專注于第一個(gè)場景。與冰箱的用例類似，我們可以將RILA的不同層面映射為下圖所示的系統(tǒng)組件。
對于保險(xiǎn)公司的用例，只需要在汽車中實(shí)施完整的RILA堆棧，因?yàn)樾枰傻脑O(shè)備都在汽車中，其他操作都是在數(shù)據(jù)傳輸層面上進(jìn)行的。在這里可能有人會(huì)質(zhì)疑我們對“物件”的定義。只有設(shè)備才算是“物件”嗎?我們的定義并不這樣認(rèn)為，并非只有設(shè)備才是物件。不過此處的合理推論是，并非所有物件都必須具備設(shè)備集成和設(shè)備管理層(沒有設(shè)備，當(dāng)然也就不需要進(jìn)行設(shè)備集成和管理)。
汽車需要在應(yīng)用程序集成層具備一些接口，這樣車主才能與系統(tǒng)通過某種形式通信(車載系統(tǒng)通常已經(jīng)具備這樣的能力)。數(shù)據(jù)傳輸至汽車制造商的系統(tǒng)后，只需要進(jìn)行少量的上下文情境管理、數(shù)據(jù)管理，以及物件集成工作即可實(shí)現(xiàn)用例需求。保險(xiǎn)公司(以及汽車制造商的系統(tǒng))可能也需要進(jìn)行應(yīng)用程序集成，因?yàn)檫€需要使用這些數(shù)據(jù)執(zhí)行某些任務(wù)，例如運(yùn)行預(yù)測模型的軟件必須能通過某種方式訪問這些數(shù)據(jù)。
這個(gè)保險(xiǎn)公司用例的實(shí)現(xiàn)想法在于：汽車的車載計(jì)算機(jī)可以充當(dāng)一種應(yīng)用平臺。隨后用戶即可下載保險(xiǎn)公司(與汽車制造商合作)提供的應(yīng)用，借此讓用戶控制什么可以分享，什么不能分享。取決于用戶的分享意愿，可以由保險(xiǎn)公司或汽車制造商為車主提供一定的好處(這就為我們提供了一種理想的業(yè)務(wù)模式)。一旦實(shí)現(xiàn)最終的個(gè)性化，就可以通過了解上下文情境的保險(xiǎn)策略實(shí)現(xiàn)“駕駛即付費(fèi)”的業(yè)務(wù)模式，并進(jìn)一步擴(kuò)展為“按照駕駛方式付費(fèi)”的模式。
本文介紹的這兩個(gè)用例較為寬泛，除了所描述的場景外，通過本文提供的用例還可以構(gòu)思出很多不同使用場景。為了針對不同用例打造真正實(shí)用、有價(jià)值的設(shè)計(jì)，還需要對相關(guān)領(lǐng)域有所了解。
確定用例場景后，就可以確定要在參考架構(gòu)(例如RILA)中使用哪些IoT組件。通信和安全措施的實(shí)施方式所實(shí)現(xiàn)的標(biāo)準(zhǔn)化程度越高，就能越容易地將IoT系統(tǒng)與以后部署的其他IoT系統(tǒng)相集成。無論其他保險(xiǎn)公司或汽車制造商打算使用保險(xiǎn)公司用例，或其他電廠或冰箱(制造商)打算使用冰箱用例，只要具備確認(rèn)有效的合適結(jié)構(gòu)(例如類似Google Brillo這樣的機(jī)制)，集成工作就會(huì)變得更簡單。參考架構(gòu)只是為了向大家提供一種通用的模式，幫助大家避免在實(shí)際開發(fā)中“漏掉”某個(gè)重要的組件或設(shè)計(jì)因素。
總之需要強(qiáng)調(diào)的是，最重要的第一步始終是一開始就從功能層面上定義要實(shí)現(xiàn)的用例，隨后再考慮具體的技術(shù)規(guī)范細(xì)節(jié)。
為了確定希望通過系統(tǒng)實(shí)現(xiàn)的最終目的，還要明確定義涉及的對象和想要實(shí)現(xiàn)的目標(biāo)。雖然這是一種眾所周知的范式，但對IoT世界中的應(yīng)用程序和系統(tǒng)開發(fā)工作，這一點(diǎn)尤為重要，因?yàn)榫唧w用例通常更復(fù)雜，包含的場景也更多樣。領(lǐng)域驅(qū)動(dòng)的設(shè)計(jì)指南可以幫您實(shí)現(xiàn)更有價(jià)值的靈活設(shè)計(jì)。
通過諸如RILA等參考架構(gòu)，我們可以了解實(shí)現(xiàn)IoT應(yīng)用程序的過程中必不可少的一些組件。通過明確具體用例所要實(shí)現(xiàn)的功能規(guī)范，就可以確定參考架構(gòu)中不同組件的具體設(shè)計(jì)方式。通過功能層面上對用例和設(shè)計(jì)進(jìn)行結(jié)合，即可確定最終的技術(shù)規(guī)格和實(shí)現(xiàn)方法。隨后便可結(jié)合專業(yè)技能確定將現(xiàn)有平臺用于何處才能提供一個(gè)或多個(gè)參考架構(gòu)組件所要實(shí)現(xiàn)的功能，甚至如何使用現(xiàn)有平臺組成某些用例所需的整個(gè)技術(shù)堆棧。
