物聯網的一種參考架構
本文是兩篇系列文章中的第一篇，我們在將這一系列文章中首先從一個抽象的角度了解IoT的參考架構，然后分析具體的架構與所選擇的用例的實現。第一篇文章將涵蓋更具體與完整的架構中的各種定義，而第二篇文章將通過實際的用例應用這種架構。
我們正處在一個嶄新的互聯世界的入口，處于“物聯網”(IoT)或者說是“第四次工業革命”浪潮之中的公司正在開發一種新型的網絡，讓我們在每日生活中所接觸到的事物可以實現互通。IoT實現了“物”(Thing)的互聯，通過信息交換的方式，為用戶完成各種任務。各種新穎的思想將逐漸變為現實，例如讓家里的冰箱不僅能夠與你的智能手機通信，甚至還能夠與生產者的服務器場或是能源發電廠進行通信。在背后推動這次新技術與通信變革的公司來自于各行各業，不僅像Google、微軟或Apple這樣的大數據軟件巨頭正走在這條道路上，此外還有保險公司巨頭、外圍設備廠家乃至汽車制造商也紛紛投入IoT的懷抱。
在各種不同的“Thing”之間實現通信的關鍵在于實現標準化。標準化在研究環境中說起來很容易，但要在真實的世界中實現卻是相當困難的。參考架構對于實現標準化能夠帶來很大的幫助，在對于IoT系統實現進行計劃工作時，可以參考由這些架構所定義的指南。
為了實現標準化，必須創建高層次的參考架構，正如IoT-A所完成的工作一樣。不過，由于高層次的參考架構過于抽象，因而造成了難以理解的現狀。如果你正在從事咨詢顧問工作就會發現，要為行業中的實際客戶展示這種高層次的參考架構是不可能的。
我們希望做到更進一步，通過我們提供的指南，使你了解如何從IoT-A參考架構中生成一個更為具體的架構。我們的想法是為這個抽象的IoT-A參考架構創建一個較低層次的架構，你甚至可以將它寫到“管理總結”中，這也正是這篇文章的主體。此外，我們還將選擇部分用例，在這個引用架構中進行舉例說明，以展示一個完整的生命周期，包括在IoT中實際系統的實現。這一部分將在下一篇文章中進行講解。
首先，讓我們定義一些術語：
1.Thing：這是我們在每日生活中所接觸到的某個物體，它就存在于我們的生活環境中。Thing既可以是一輛汽車或一臺冰箱，但也可以被抽象為一個完整的房屋或是城市，這取決于我們的用例。
2.設備：可以表示一個傳感器(Sensor)、一個制動器(Actuator)或是一個標識(Tag)。通常來說，設備是Thing的一個組成部分。Thing將處理設備中的上下文信息，并將選定的信息與其他Thing進行通信。此外，Thing還可以將行為傳遞給制動器?/p>
在每一種IoT參考架構中(例如Google的Brillo、IoT-A或Z-Wave)，你都會(以某種形式)發現大量“無法回避的IoT組件”：
1.Thing與設備的互操作性以及集成組件。
2.上下文感知計算技術，例如上下文模型或行為模型的定義，以及規則引擎的目標定義。
3.與整個架構相關的安全性指南。
在某種形式上，當前的IoT架構可以被視為由Anind K. Dey所提出的Context Toolkit框架在更大規模上應用的一種版本。Context Toolkit的設計屬于應用層面，因為它是為地理信息系統(GIS)所設計的。而在IoT環境中，我們必須對Context Toolkit在物物互聯方面進行擴展。不過，目標、上下文信息以及行為等基本概念在IoT世界中同樣適用。
在IoT的世界中，不僅我們能夠在用戶層面(即來自于應用程序)定義目標，Thing本身也可以在沒有用戶積極參與的情況下實現某種目標。最終來說，設備依然是為用戶服務的，但他們可以在后臺進行自治的工作，這也正是普適計算(Ubiquitous Computing)的思想。
為了更好地理解“上下文”這個術語，我們首先將介紹一個上下文模型，然后再對參考架構進行介紹。上下文定義了處于某個場合、某個時間點上的某個環境的狀態(通常來說即用戶環境)。上下文模型通常分為上下文元素與上下文情境。上下文元素通常會在設備層面定義特定的上下文，上下文元素的一個例子可以是處于某個具體時間與位置的溫度。
位置與時間本身就屬于上下文元素，但他們還扮演了一種特殊的角色，因為要在空間與時間上定位傳感器的值，必須了解這些信息。如果不了解某個溫度是在哪里、在何時測量的，那么這個溫度對于決策來說并沒有什么幫助。
某些上下文元素是可以立即實現標準化的(舉例來說，一個溫度值已經被定義為一個雙精度的數值加上一個測量單位，例如攝氏或是華氏溫度)。而其他上下文元素則是特定于應用程序的(即“特定于Thing”)，因而無法立即實現標準化。這些元素被定義為“高層次”的上下文，對于每個Thing來說，需要一種機制以定義他們。
上下文情境(Context Situation)則是多個上下文元素的一種聚合。因此，上下文情境是對于某個環境在某一位置、某一時間的一種視角。
正如上文所說，某些上下文元素是可以立即標準化的(因為他們已經實現了標準化)，而另一些無法立即標準化(因為他們是特定于用例的)。為了了解某個Thing與另一個Thing之間能否進行通信，需要他們對于某種通信標準達成一致。出于這個原因，我們需要引入上下文情境模式(Schema)。上下文情境模式將以上下文的方式定義某個物的能力。
你可以進一步擴展這個上下文模型，定義某種所有的Thing都必須具備的“標準功能”，以及需要由每種Thing自行定義的“額外功能”，例如Z-Wave標準的做法。
與上下文模型類似，你也可以定義一個行為模型，該模型將定義Thing可以觸發的行為(例如打開一個窗口，或是拍攝一張圖片)。行為必須由上下文信息(例如某個上下文情境)和已定義的目標的組合所觸發。目標通常由規則引擎中的規則進行描述(例如 IF temperature > 25* THEN open window)。當某個上下文情境具體對應到某個Thing之后，這個Thing就需要根據它的已定義目標(即規則)評估是否要觸發某個行為。根據用例的不同，與某個Thing對應的上下文、行為與目標模型的復雜度也有所不同。有些Thing只會使用行為的信息，而不會發布上下文信息，而其他Thing則會發布上下文信息(甚至是目標)，讓其他Thing進行使用。
現在，我們已經理解了上下文感知計算在IoT世界中所扮演的角色，接下來我們可以討論這個參考IoT分層架構(簡稱“RILA”)的定義了。在IoT的語境中，RILA將連接Thing、設備與用戶，正如下圖所示。
RILA包含6個層，除了這6個層之外，還有兩個“橫切面層”，他們將影響其他所有層。這兩個層即“安全層”與“管理層”。
讓我們來看一看RILA中的每個層與其中的組件。我們將從最底層(設備集成層)開始，隨后逐步向上層推進。
設備集成層(Device Integration Layer)負責連接所有不同的設備類型、獲取設備的測量數據，并(在設備層面上)實現行為的通信?？梢詫⑦@一層視為一種能夠講多種不同語言的翻譯器。傳感器與標識的輸出取決于他們所實現的協議，而制動器的輸入同樣由他們所實現的協議所定義。
設備集成層包含三個主要的組件。最底層的組件是驅動組件，它負責通過低層次的、特定于供應商以及通信協議的方式在不同的傳感器、標識以及制動器之間進行通信。對于系統已知的每種低層設備類型，它都提供了對應的驅動實例。下一個組件是設備發現組件，它能夠由兩種事件觸發，一種事件來自于設備管理層，告訴這個組件需要添加一種新的設備。另一種事件來自于驅動組件，如果添加了某種新的設備，驅動組件就會通知設備發現組件。與之類似，設備發現組件還要處理設備的撤消注冊操作。最后一個組件是設備通信組件，它負責在設備管理層與驅動組件之間起到橋梁作用。當設備管理層找到某個設備后，該組件將決定要調用哪個驅動。
設備管理層(Device Management Layer)負責從設備集成層中獲取設備的注冊信息以及傳感器的測量數據。此外，它還負責將制動器的狀態變化向下傳遞給設備集成層。設備集成層隨后將對狀態的變化進行校驗(即行為)，保證它與制動器相一致，并將解釋后的狀態變化發送給制動器。
設備管理層負責控制設備，以了解有哪些設備已連接到系統中。對于設備注冊信息的更改，以及傳入的測量數據必須通過設備集成層與設備管理層進行通信，從而實現信息的更新與保存。設備集成層通過這種方式管理設備的注冊(包括添加元數據，例如傳感器所發送數據的單位或頻度)以及設備的通信(將實際的測量數據傳遞給數據管理層，并將行為向下傳遞給制動器設備)。
可以將數據管理層視為一種中央式的數據庫，它保存著一個“Thing”的所有數據，但這只是一種可能的實現方式。對于系統中較大的Thing(例如從其他Thing中收集數據的某個設備生命周期監控系統)，數據管理層可以扮演一種數據倉庫，甚至是一個完整的數據場的角色。數據管理層的實現很大程度上取決于特定的Thing的用例。
上下文管理層(Context Management Layer)定義了RILA中的核心業務邏輯，并負責完成這6種任務：
1.定義Thing的目標。
2.取其他Thing的上下文情境。
3.為Thing生成(自有的)上下文情境。
4.評估(自有的)上下文情境是否符合目標。
5.根據評估的規則觸發各種行為，以促進目標的實現。
6.向其他Thing發布上下文情境。
根據以上的任務，我們可以將上下文管理層分解為8種組件，如下圖所示。
規則引擎與人工智能(AI)：定義及管理上下文評估所必需的規則。包括目標(它本質上就是規則的一種集合)及用于創建上下文情境和行為的規則。
上下文情境集成模塊：偵聽其他Thing的上下文情境，并與傳入的上下文情境相集成。
行為集成模塊：通過這個組件對其他Thing所傳入的行為進行評估，并傳遞給設備管理層。在這個過程中需要考慮到規則的問題，它定義了在哪種情境下可以將來自另一個物的行為進行傳遞，以觸發制動器。
上下文情境創建模塊：從系統中收集數據，并構建上下文情境。這一過程也可以由規則進行驅動。
行為創建模塊：與上下文情境創建模塊相似，在規則評估過程中觸發的行為必須創建相應的行為對象。
上下文情境發布模塊：為Thing集成層提供上下文情境。根據實現的復雜度不同，上下文情境發布者可以為已訂閱的不同Thing提供一系列的上下文情境，或者為所有Thing提供一個單一的上下文情境。上下文情境發布模塊必須注意其他Thing的數據權限級別。只有可信的其他Thing才能夠收到經過選擇的上下文信息。此外，該模塊還要負責定義上下文情境模式，這些模式需要與其他訂閱的Thing進行通信，它將評估某個Thing是否能夠與其他Thing進行通信。
行為發布模塊：與上下文情境發布模塊類似，該模塊負責將行為傳遞給Thing集成層，讓其他Thing能夠與行為進行通信。此外，行為模式也是由這個組件負責管理的。
上下文評估模塊：對使用(現有的)上下文情境的規則進行評估，并觸發那些與底層的設備或行為創建模塊進行通信的行為。行為創建模塊將把這些創建的行為傳遞給行為發布者，后者負責將行為傳遞給其他Thing。評估規則的一種簡單方式是為由規則引擎所定義的規則構建相應的決策樹。
具體的架構與所提供的功能的復雜度很大程度上取決于所開發的Thing的具體用例。對于在智能方面要求較低的Thing(例如一臺冰箱)，規則引擎與人工智能組件也不必設計得很復雜。而對于需要從其他設計中收集上下文信息的Thing來說，這些組件將變得非常復雜。高復雜性的例子包括數據科學以及數據挖掘技術。
Thing集成層(Thing Integration Layer)將負責找到其他物，并與其進行通信。
一旦兩個Thing找到彼此之后，他們就需要經歷一種注冊機制。Thing集成層必須評估與另一個Thing之間的通信是否可能。因此，必須對上下文情境及行為模式進行比較，這一功能是由上下文管理層所提供的。
如果對于模式匹配的評估結果是正面的，那么該Thing就能夠向另一個Thing發送創建新的上下文情境或行為的通知。傳遞給其他Thing的上下文情境和行為將由上下文管理層提供。
Thing的注冊必須由一個集中式的組件，或是由Thing本身完成(例如自發現的網絡掃描)。
用戶將通過應用集成層(Application Integration Layer)與物進行連接。(直接)建立在RILA架構上的應用屬于這一層?？梢詫玫募煽醋鲆粋€服務層，甚至是一個簡單的UI。這一層具體的實現取決于實際的用例。
到此為止，我們終于講完了每個層的作用?，F在讓我們來面對那些跨層的挑戰，首先從安全層開始。在構建IoT系統時，我們必須在每個層上全盤考慮安全性問題。系統必須找到攻擊的來源，以找到合適的安全標準。
我們可以列舉出以下攻擊來源：
用戶：終端用戶有可能會成為一種攻擊來源，因為這種攻擊有可能會人為地、或是無意地影響整個系統。這種類型的攻擊中最常見的方式是釣魚攻擊，即嘗試從受攻擊者那里獲取敏感信息。
Web界面：如果應用本身提供了一個web界面，那么它就有可能遭受到一些“傳統的”攻擊，例如SQL注入或XSS攻擊。OWASP(開放式Web應用安全項目)列舉了網站最容易遭受的10種攻擊的場景。
Thing：智能設備經常會通過某個應用與外部系統進行通信，而這種應用依賴于某種形式的操作系統。這就存在兩種主要的受攻擊的可能。一是應用本身或許沒有采取適當的安全機制，二是底層的操作系統可能會被侵入或感染。
低層次的硬件組件：在考慮硬件組件及其提供的安全措施時，用戶必須考慮到計算能力的問題。一個主要的風險在于低運算能力的設備不具備進行安全加密通信所需的CPU能力。在支持多個傳感器的場景中，系統可以選擇消除異常值，以獲得一個準確的值，但這種方式無法保證安全性。如果由傳感器所提供數據的準確性對于系統來說十分重要，那么則需要使用更強大的硬件，而這將使系統的成本上升一個數量級。
通信信道：對于通信信道的安全性設置取決于所使用的協議，我們將討論與IoT相關的協議，以及這些協議為通信的加密所提供的功能。
1.RFID與NFC：標識與讀取裝置之間的通信是通過無線連接實現的，它很容易被竊聽，因此對于數據的加密至關重要。當前能夠保證足夠安全性的對稱式加密算法包括3DES與AES-128。在向新的標識寫入數據時，應當更改默認的認證密鑰。對于標識的密鑰管理是由控制讀取裝置的系統所完成的。RFID標識本身具有很大的差異性，因此在購買時必須要考慮到安全性的問題。舉例來說，Mifare Plus標識就是Mifare Classic標識的一個升級版本，因為前者提供了基于AES-128的加密功能，而Mifare Classic標識使用了一種具有專利權的、基于48位的密鑰的算法，但這種算法已經被攻破了。
2.Zigbee：Zigbee設備與應用之間的通信信道是安全的，因為它所采用的加密算法是AES-128。但與對方所進行的初次密鑰交換必須被視為不安全的。當某個新的設備加入網絡中時，密鑰將以明文的方式進行發送，只要時機掌握好，就有可能被嗅探工具所捕獲。
3.Thread：兩臺Thread設備之間的通信將由AES加密保證安全性，一臺新設備與應用之間的密鑰生成將通過一種密鑰交換算法保證安全性。
攻擊來源也可以分組為更為技術性的攻擊來源，它們將針對系統中的特定組件，包括：
1.認證
2.授權
3.真實性驗證：信息的簽名
4.密鑰交換策略
5.加密
6.配置 —— 糟糕的或默認的配置可能會造成安全威脅
7.第三方庫 —— 可能會包含安全隱患，而如果沒有及時更新，還可能包含一些已為人所知的漏洞。
8.網絡安全
下圖中的安全性三角形展現了在根據用例選擇合適的安全性時所遇到的困境。
這個安全性三角性一定程度上反映了每個用例都需要面對的一種妥協。你只能根據你的目的及需求，在三角形所代表的安全性、成本與業務需求之間選擇其一。讓我們看一下幾個例子：
示例1：Acme銀行建立了一個銀行金庫：在這個用例中選擇安全的硬件是至關重要的，這方面沒有商量的余地。為了實現對業務與安全性需求的最大涵蓋，成本必然會極大地上升。
示例2：農場主Billy Bob希望通過某些高大上的傳感器，在他的智能手機上了解收成的情況，但他對于安全性沒有很高的要求。目前來說，農場主Billy Bob的需求確實已經滿足了，他只用了較少的成本，并且結果令他滿意。不過，這種好日子等到另一個農場主小Jimmy的兒子小小Jimmy開始學習計算機工程之后就到頭了……
因此，為整個架構找到合適的安全措施永遠像是走鋼絲一樣，因為業務需求和成本總是和高度的安全措施相抵觸的。此外，某些技術需求可能會限制我們使用最高級安全措施的能力，例如運算能力不足的設備在發送數據包時可能無法接受某種程度上的額外開銷，因為這意味著要消耗更多的資源。
到此為止，我們即將結束對于引用架構的介紹。通過本文，我們希望能夠為你展示如何將一個IoT系統分解為更具體的層次。上下文感知的計算技術將使這個世界中的某些部分更容易理解。在后續的文章中，我們將為你展示如何通過本文介紹的RILA參考架構派生出對應的用例，以更完整地了解RILA如何實際地幫助我們實現IoT系統。