物聯網工程設計1第七章物聯網軟件設計最少學時：6學時；知識點

：物聯網軟件的特點和分類；物聯網感知層核心技術及軟件設計；物聯網接入層核心技術及軟件設計；物聯網應層核心技術及軟件設計；物聯網中間件分類及設計；學習目標：掌握物聯網軟件的特點和分類；掌握物聯網感知層核心技術及軟件設計；

熟悉物聯網接入層核心技術及軟件設計；掌握物聯網應層核心技術及軟件設計方法和步驟；

熟悉并能撰寫合格的軟件設計報告；2第七章物聯網軟件設計3物聯網軟件技術的發展離不開系統架構和硬件的支持。完整的物聯網系統包含感知層、傳輸層和應用層（包括處理子層和應用領域子層），涉及的技術基礎包括：標準化、感知材料和標識技術、安全和隱私、功率和能量存儲技術、發現和搜索技術、組網激素、通信技術、數據流及數據處理技術、軟件和算法等。物聯網軟件設計也分散在這些層次中，協助硬件一起完成特定層次功能。本章簡要介紹物聯網各層涉及的軟件的設計方法、特點和注意事項。主要內容4物聯網軟件設計概述物聯網應用層軟件設計方法物聯網中間件技術面向構件及服務的設計技術以APP為中心的物聯網軟件生態系統物聯網部署物聯網應用軟件設計與部署案例教學物聯網感知層核心技術與軟件設計物聯網接入層核心技術與軟件設計7.5物聯網中間件技術傳統的中間件是一種獨立的系統軟件或服務程序，是伴隨著網絡技術的產生、發展而興起的，為網絡分布式計算環境提供通信服務、交換服務、語義互操作服務等系統之間的協同集成服務，解決系統之間的互連互通和資源共享問題。在物聯網中采用中間件技術，是為實現多個系統和多種技術之間的資源共享，最終組成一個資源豐富、功能強大的服務系統。從本質上看，物聯網中間件是物聯網應用的共性需求（全面感知、互聯互通和智能處理），與已存在的各種中間件及信息處理技術，包括信息感知技術、下一代網絡技術、人工智能與自動化技術的聚合與技術提升。7.5物聯網中間件技術目前階段，一方面，受限于底層不同的網絡技術和硬件平臺，物聯網中間件研究主要還集中在底層的感知和互聯互通方面，現實目標包括屏蔽底層硬件及網絡平臺差異，支持物聯網應用開發、運行時共享和開放互聯互通，保障物聯網相關系統的可靠部署與可靠管理等內容；另一方面，當前物聯網應用復雜度和規模還處于初級階段，物聯網中間件支持大規模物聯網應用還存在環境復雜多變、異構物理設備、遠距離多樣式無線通信、大規模部署、海量數據融合、復雜事件處理、綜合運維管理等諸多仍未克服的障礙。

7.5.1中間件概述7.5.2物聯網中間件分類7.5.3基于中間件的物聯網應用軟件設計案例7.5物聯網中間件技術77.5.1中間件概述IDC曾經給中間件的定義：一種獨立的系統軟件或服務程序，分布式應用軟件借助這種軟件在不同的技術之間共享資源，位于客戶機服務器的操作系統之上，管理計算資源和網絡通信主機一

中間件分布式應用中間件API操作系統API操作系統處理存儲通信主機二

中間件分布式應用中間件API操作系統API操作系統處理存儲通信網絡圖7-6中間件在應用系統中的位置7.5物聯網中間件技術87.5.1中間件概述許多物聯網體系架構中，經常把中間件單獨劃分一層，位于感知層與網絡層或網絡層與應用層之間。物聯網中采用中間件技術，可以實現多個系統和多種技術之間的資源共享，最終組成資源豐富、功能強大的服務系統，最大限度地發揮物聯網系統的作用。物聯網中間件的主要作用在于將實體對象轉換為信息環境下的虛擬對象，因此數據處理是中間件最重要的功能。同時，中間件具有數據的搜集、過濾、整合與傳遞等特性，以便將正確的對象信息傳到后端的應用系統。7.5物聯網中間件技術97.5.1中間件概述物聯網中間件的特點（1）獨立于架構。中間件獨立于物聯網設備與后端應用程序之間，并能與多個后端應用程序連接，降低維護的復雜性；（2）數據流。物聯網的目的是將實體對象轉換為信息環境下的虛擬對象，因此數據處理是中間件最重要的功能。（3）處理流。物聯網中間件采用程序邏輯及存儲轉發功能提供順序信息流，具有數據流設計與管理的能力。（4）標準化。7.5物聯網中間件技術107.5.1中間件概述按照技術發展的階段劃分，物聯網中間件發展主要分成3個階段應用程序中間件階段；架構中間件階段；解決方案中間件階段；目前，物聯網中間件最主要的代表是RFID中間件，其他的還有嵌入式中間件、數字電視中間件、通用中間件等。7.5物聯網中間件技術117.5.1中間件概述RFID中間件RFID中間件是RFID標簽和應用程序之間的中介，從應用程序端使用中間件提供的一組通用的API，能夠讀寫RFID標簽。RFID中間件在系統中的位置和作用參見下圖7-17所示。RFID中間件是為了實現每個小的應用環境或系統的標準化以及它們之間的通信，在后臺應用軟件和讀寫器之間設置的一個通用的平臺和接口。圖7-18典型的嵌入式Web服務器系統模型7.5物聯網中間件技術127.5.1中間件概述嵌入式中間件位于嵌入式操作系統、數據庫與應用軟件之間的一種軟件，使用嵌入式操作系統所提供的基本功能和服務，并為上層的應用系統提供運行開發環境。嵌入式系統的優點在于軟件和硬件的可裁剪性，結構靈活性、穩定性和經濟性。嵌入式中間件有兩個重要的平臺：嵌入式Web和JavaVM平臺。7.5物聯網中間件技術137.5.1中間件概述數字電視中間件指位于數字電視機頂盒內部實時操作系統與應用程序之間的軟件部分；以應用程序接口API的形式存在，整個API集合被存儲在機頂盒的閃存FLASH中，針對機頂盒的應用程序基于API進行開發，能夠支持豐富的應用。7.5物聯網中間件技術147.5.1中間件概述下面以RFID中間件的發展為例，簡單介紹其3個發展階段：應用程序中間件階段多以整合、串接RFID讀寫器為目的，RFID廠商提供簡單的API，以供用戶將后端與RFID讀寫器串接，用戶需要花費較多成本處理前后端之間的連接問題；架構中間件階段是RFID中間件發展的關鍵階段，不但已經具備基本的數據搜索、過濾功能，同時也滿足企業多對多的連接需求，并具備平臺的管理與維護功能；解決方案中間件階段是在RFID標簽、讀寫器與中間件發展成熟過程中，各廠商針對不同領域提出的創新應用解決方案，如ManhattanAssociates提出的RFIDinaBox，企業不需再為前端的RFID硬件和后端應用系統的連接而煩惱，該公司與AlienTechnologyCorp在RFID硬件端合作，發展中間件，針對該公司的900多家已有的供應鏈客戶群發展供應鏈執行方案。7.5物聯網中間件技術157.5.2物聯網中間件分類按物聯網底層感知及互聯互通，和面向大規模物聯網應用兩方面介紹當前物聯網中間件的相關研究現狀：物聯網底層感知與互聯互通方面：

EPC中間件相關規范、OPC中間件相關規范已經過多年的發展，相關商業產品在業界已被廣泛接受和使用；WSN中間件，以及面向開放互聯的OSGi中間件，正處于研究熱點；大規模物聯網應用方面：面對海量數據實時處理等的需求，傳統面向服務的中間件技術將難以發揮作用，而事件驅動架構、復雜事件處理CEP中間件則是物聯網大規模應用的核心研究內容之一。7.5物聯網中間件技術167.5.2物聯網中間件分類

（一）EPC(ElectronicProductCode)中間件EPC中間件是電子產品標簽和應用程序之間的中介。應用程序使用EPC中間件所提供的一組通用應用程序接口，讀取RFID標簽數據。EPC中間件的標準接口，可以解決應用程序和RFID標簽之間多對多連接的維護復雜性等問題。EPC電子標簽標準化方面，美國在世界領先成立了EPCGlobal(電子產品代碼環球協會)。EPCGlobal主要針對RFID編碼及應用開發規范方面進行研究，其主要職責是在全球范圍內對各個行業建立和維護EPC網絡，保證供應鏈各環節信息的自動、實時識別采用全球統一標準。國際上，目前比較知名的EPC中間件廠商有IBM、Oracle、SAP、Microsoft、Sun（Oracle）、Sybase、BEA（Oracle）等的相關產品。7.5物聯網中間件技術177.5.2物聯網中間件分類（二）OPC(OLEforProcessControl,用于過程控制的OLE)中間件OPC是一個面向開放工控系統的工業標準，基于微軟的OLE(ActiveX)、COM(構件對象模型)和DCOM(分布式構件對象模型)技術，包括一整套接口、屬性和方法的標準集，用于過程控制和制造業自動化系統，現已成為工業界系統互聯的默認方案。OPC是連接數據源(OPC服務器)和數據使用者(OPC應用程序)之間的軟件接口標準。

OPCClient/Server運行關系示意圖7.5物聯網中間件技術187.5.2物聯網中間件分類（三）WSN中間件相比RFID和OPC中間件產品的成熟度和業界廣泛應用程度，WSN中間件還處于初級研究階段，所需解決的問題也更為復雜。WSN中間件主要用于支持基于無線傳感器應用的開發、維護、部署和執行，其中包括復雜高級感知任務的描述機制，傳感器網絡通信機制，傳感器節點之間協調以在各傳感器節點上分配和調度該任務，對合并的傳感器感知數據進行數據融合以得到高級結果，并將所得結果向任務指派者進行匯報等機制。7.5物聯網中間件技術197.5.2物聯網中間件分類（三）WSN中間件針對WSN中間件的上述目標，目前的WSN中間件研究提出了諸如分布式數據庫、虛擬共享元組空間、事件驅動、服務發現與調用、移動代理等許多不同的設計方法。1、分布式數據庫基于分布式數據庫設計的WSN中間件把整個WSN網絡看成一個分布式數據庫，用戶使用類SQL的查詢命令以獲取所需的數據。分布式數據庫方法把整個網絡抽象為一個虛擬實體，屏蔽了系統分布式問題，使開發人員擺脫了對底層問題的關注和繁瑣的單節點開發。然而，建立和維護一個全局節點和網絡抽象需要整個網絡信息，這也限制了此類系統的擴展。7.5物聯網中間件技術207.5.2物聯網中間件分類（三）WSN中間件2、虛擬共享元組空間指分布式應用利用一個共享存儲模型，通過對元組的讀、寫和移動以實現協同。在虛擬共享元組空間中，數據被表示為稱為元組的基本數據結構，所有的數據操作與查詢看上去像是本地查詢和操作一樣。虛擬共享元組空間通信范式在時空上都是去耦的，不需要節點的位置或標志信息，非常適合具有移動特性的WSN，并具有很好的擴展性。但它的實現對系統資源要求也相對較高，與分布式數據庫類似，考慮到資源和移動性等的約束，把傳感器網絡中所有連接的傳感器節點映射為一個分布式共享元組空間并非易事。典型實現包括TinyLime，Agilla等。7.5物聯網中間件技術217.5.2物聯網中間件分類（三）WSN中間件3、事件驅動基于事件驅動的WSN中間件支持應用程序指定感興趣的某種特定的狀態變化。當傳感器節點檢測到相應事件的發生就立即向相應程序發送通知。應用程序也可指定一個復合事件，只有發生的事件匹配了此復合事件模式才通知應用程序。4、服務發現基于服務發現機制的WSN中間件，可使得上層應用通過使用服務發現協議，來定位可滿足物聯網應用數據需求的傳感器節點。7.5物聯網中間件技術227.5.2物聯網中間件分類（三）WSN中間件----5、移動代理移動代理（或移動代碼）可以被動態注入并運行在傳感器網絡中。這些可移動代碼可以收集本地的傳感器數據，然后自動遷移或將自身拷貝至其他傳感器節點上運行，并能夠與其他遠程移動代理（包括自身拷貝）進行通信。除上述提到的WSN中間件類型外，還有許多針對WSN特點而設計的其他方法。另外，在無線傳感器網絡環境中，WSN中間件和傳感器節點硬件平臺（如ARM，Atmel等）、適用操作系統（TinyOS，ucLinux，ContikiOS，MantisOS，SOS，SenOS，MagnetOS，PEEROS，AmbitentRT，Bertha等）、無線網絡協議棧（包括鏈路、路由、轉發、節能）、節點資源管理（時間同步、定位、電源消耗）等功能聯系緊密。但由于篇幅關系，本文對上述內容不做贅述。7.5物聯網中間件技術237.5.2物聯網中間件分類（四）OSGi(OpenServicesGatewayinitiative)中間件OSGi是一個1999年成立的開放標準聯盟，旨在建立一個開放的服務規范，一方面，為通過網絡向設備提供服務建立開放的標準，另一方面，為各種嵌入式設備提供通用的軟件運行平臺，以屏蔽設備操作系統與硬件的區別。OSGi規范基于JAVA技術，可為設備的網絡服務定義一個標準的、面向組件的計算環境，并提供已開發的象HTTP服務器、配置、日志、安全、用戶管理、XML等很多公共功能標準組件。OSGi組件可以在無需網絡設備重啟下被設備動態加載或移除，以滿足不同應用的不同需求。7.5物聯網中間件技術247.5.2物聯網中間件分類（五）復雜事件處理CEP中間件復雜事件處理（ComplexEventProgressing）技術是90年代中期由斯坦福大學的DavidLuckham教授所提出是一種新興的基于事件流的技術，它將系統數據看作不同類型的事件，通過分析事件間的關系如：成員關系、時間關系以及因果關系，包含關系等，建立不同的事件關系序列庫，即規則庫，利用過濾、關聯、聚合等技術，最終由簡單事件產生高級事件或商業流程。不同的應用系統可以通過它得到不同的高級事件。7.5物聯網中間件技術257.5.2物聯網中間件分類（五）復雜事件處理CEP中間件（續）復雜事件處理代表一個新的開發理念和架構，具有很多特征，例如分析計算是基于數據流而不是簡單數據的方式進行的。它不是數據庫技術層面的突破，而是整個方法論的突破。目前，復雜事件處理中間件主要面向金融、監控等領域，包括IBM流計算中間件InfoSphereStreams，以及Sybase、Tibico等的相關產品。7.5物聯網中間件技術267.5.2物聯網中間件分類（六）其他相關中間件國際電信聯盟對物聯網提出的任何時刻、任何地點、任意物體之間互聯，無所不在的網絡和無處不在的計算的發展愿景，在某種程度上，與普適計算的核心思想是一致的。普適計算（Ubiquitouscomputing或pervasivecomputing），是一個強調和環境融為一體的計算概念，而計算機本身則從人們的視線里消失。在普適計算的模式下，人們能夠在任何時間、任何地點、以任何方式進行信息的獲取與處理。有關普適計算中間件及物聯網應用方面的研究內容，可參閱其他相關文獻。另外，由于行業應用的不同，即使是RFID應用，也可能因其在商場、物流、健康醫療、食品回溯等領域的不同，而具有不同的應用架構和信息處理模型。針對智能電網，智能交通，智能物流，智能安防，軍事應用等領域的物聯網中間件，也是當前物聯網中間件研究的熱點內容。7.5物聯網中間件技術277.5.2物聯網中間件分類（七）物聯網國際研究項目中間件ASPIRE旨在將RFID應用滲透到中小型企業。為了達到這樣的目的，ASPIRE完全改變了現有的RFID應用開發模式，它引入并推進一種完全開放的中間件（即設置一個通用的平臺和接口，以實現每個小的應用環境或系統的標準化以及它們之間的通信），同時完全有能力支持原有模式中核心部分的開發。ASPIRE的解決辦法是完全開源和免版權費用，這大大降低了總的開發成本。歐盟Hydra物聯網中間件項目致力于開發可廣泛部署的智能網絡嵌入式中間件平臺，使之可運行于新的或已存在的分布式有線/無線網絡設備中。Hydra是定位于操作系統和應用之間的中間件，包含了設計用于處理各種任務的眾多軟件組成成分，以完成一個有效利用成本低智能物聯網應用開發過程。7.5物聯網中間件技術287.5.2物聯網中間件分類（七）物聯網國際研究項目中間件歐洲IOT-A（InternetofThingsArchitecture）項目致力于當前物連網向未來物聯網的轉變，以及物聯網業務流程建模、原型實現，并對物聯網工業應用作出貢獻。其具體內容包括搭建物聯網系統互操作模型，建立有效的服務層響應機制，提供基于開放協議的服務協議，定義官方物聯網體系結構以及設備平臺組件等。7.6物聯網中間件技術297.5.3基于中間件的物聯網應用軟件設計案例基于中間件的體系結構指的是通過中間件隱藏硬件和網絡平臺的復雜性和異質性的架構。本節針對醫療保健應用提供了一個基于中間件的物聯網體系架構，為嵌入式設備和節點，如計算機或數據服務器，提供簡單、統一的配置和操作。該模型把整個系統看作一個分布式系統，把任何計算設備，無論硬件還是操作系統，都看作為一個節點，該架構要求每個節點有必須包含一個獨立于設備的中間件，并給出基于該中間件進行應用實例開發的架構和方法。7.6物聯網中間件技術307.5.3基于中間件的物聯網應用軟件設計案例一個簡單的醫療保健應用場景：（中間件需求）在醫療保健這個特殊場景中，通常需要在被治療者身上設置包含若干傳感器的嵌入式設備節點，在某個突發實例觸發對數據的使用需求之前，每個節點都需要存儲數據。該場景中，節點的存儲和處理能力是最重要的方面，以供決策支持系統使用。例如，如果患者去醫院并使用人體感應器來監測一天的心跳，節點必須能存儲它一天收集的數據，并且只有當患者返回醫院時才卸載檢節點測到的數據。考慮上面的場景，我們可從中提取出幾個中間件需求：數據采集和處理、系統配置作為功能性需求，而異質性、互操作性和適應性被視為非功能性需求。7.6物聯網中間件技術317.5.3基于中間件的物聯網應用軟件設計案例數據采集和處理：數據必須被獲取和存儲、處理（例如，格式適應、過濾），轉移、進一步加工或合并并交付給用戶。異質性：中間件應當模塊化并基于驅動程序和接口，這些允許它運行在不同的硬件和軟件平臺。互操作性：必須為所有的節點提供標準的接口來訪問數據（不同的節點必須被抽象并使用通用API以相同的方式訪問）。靈活性：中間件必須具有靈活性和適應性。每個應用上下文（例如血壓、血糖水平的測量）將要求一個稍微不同的操作、采樣率和響應時間的組合。系統配置和適應性：部署系統應該是必要的，配置系統，系統應該就啟動和運行。在其他情況下，可能有必要使用共同的方言和調用標準API函數，編程應用程序的一部分。針對上述醫療保健應用場景及中間件需求的物聯網體系結構7.6物聯網中間件技術327.5.3基于中間件的物聯網應用軟件設計案例架構中定義了節點構件（NCeH），該節點構件必須被包括在所有節點裝置，包括計算機和數據服務器中。該節點構件NCeH主要目的是提供一些機制來處理節點的引用、異質性和平臺和通信協議的獨立性。該例中血糖儀裝備有節點組件NCeH二進制文件，運行Android的智能手機裝備有面向Android的NCeH，而服務器運行NCeH的Linux版本。用戶發送配置命令（每秒讀葡萄糖；發送到智能手機，存儲1天；發送到服務器）。每個關鍵詞-葡萄糖、智能手機、服務器-使用一種簡單的機制來定義。其中物聯網中間件NCeH的一種體系結構可以參考下圖所示。7.6面向構件及服務的設計技術構件是系統中實際存在的可更換部分，代表系統中的一部分物理實施，其發展在某種程度上極大依賴于中間件技術，同時，構件技術是支持復用的核心技術。服務相當于構件化編程模型中的構件。面向服務的架構是一種松耦合的軟件構件技術，將應用程序的不同功能模塊化，并通過標準化的接口和調用方式聯系起來，實現快速可重用的系統開發和部署。面向服務的架構模型使得構建在不同系統中的同類服務可以通過統一和通用的方式進行交互。本節討論構件化架構或面向服務架構方式設計開發物聯網系統時的相關設計技術。337.6.1面向構件的物聯網應用設計7.6.2面向服務的物聯網應用設計7.6面向構件及服務的設計技術347.6.1面向構件的物聯網應用設計構件具有以下幾個特點：

（1）自描述：構件必須能夠識別其屬性、存取方法和事件，這些信息可以使開發環境將第三方軟件構件無縫地結合起來；

（2）可定制：允許提供一個典型的圖形方式環境，軟件構件的屬性只能通過控制面板來設置；

（3）可集成：構件必須可以被編程語言直接控制。構件也可以和腳本語言或者與從代碼級訪問構件的環境連接，這個特點使得軟件構件可以在非可視化開發項目中使用；

（4）連接機制：構件必須能產生事件或者具有讓程序員從語義上實現相互連接的其他機制。7.6面向構件及服務的設計技術357.6.1面向構件的物聯網應用設計構件技術是由基于面向對象技術而發展起來的，與面向對象的設計中的對象相類似，但它們之間存在很大差異，構件不是對象，只是與對象類似。物聯網應用范圍、規模及種類的多樣性使得物聯網應用環境具有開放、動態和難控等特性，也造成構成系統的軟件實體也具有異構、智能和自主等特點。我們把適應環境變化，且能夠自主進行決策的構件稱為自主構件一方面，從構件角度來看，自主構件與普通構件相同，它具有相對獨立的功能，能夠被復用和組裝，成為系統的有機構成成分。另一方面，從自主性的角度來看，自主構件行為受到自身策略的驅動向外提供服務，并且可以在運行時刻收集系統的信息，感知變化從而做出決策。7.6面向構件及服務的設計技術367.6.1面向構件的物聯網應用設計針對物聯網應用環境的特點，構成物聯網應用的構件不能只被看作被動的受管對象，而應將其建模為具有主動能力的軟件實體，即自主構件。自主構件同時具備了構件以及Agent的關鍵性質，從能力要求來看，除了對外提供服務，自主構件區別于傳統構件的能力主要：(1)功能性：能對外提供服務，可以通過調用外部構件的服務來實現自身的功能性需求；并具有質量屬性評估的功能。(2)自決策性：對功能性和非功能性目標的實現和改進具有決策能力。(3)自適應性：自主構件對于不同應用環境具有適應能力，在不同場景下，對外所展現的行為會有所不同。能夠決定如何選擇和使用外部資源(依賴服務)，并規范依賴服務的行為。(4)交互性和協同性：能參與交互和合作，多個自主構件可以協作完成復雜的任務。7.6面向構件及服務的設計技術377.6.1面向構件的物聯網應用設計自主構件的功能模塊構成一個執行循環：“監控→分析→決策→執行”來動態的監控環境變化并做出實時響應。以上4部分使用的數據作為共享的知識存儲在知識庫中，共享的知識包括網絡拓撲信息、系統日志、策略庫等。在開放物聯網環境中，構件所依賴的服務質量和數量、鏈接的狀態等都是動態變化的。理想狀態下，具有自適應能力的構件能夠在網絡環境不斷變化的情況下，無需外界進行顯式控制，就能調整其自身內部行為或結構保證正常對外提供服務。自主構件將數據、操作、質量屬性封裝在一起。自主構件是部署在網絡上、能被第三方復用的軟件實體。7.6面向構件及服務的設計技術387.6.1面向構件的物聯網應用設計自主構件主要由以下8個部分組成：(1)接口：即自主構件對外部提供的服務接口。主要由感知器和效應器2個接口組成，用于感知環境和作用于環境。(2)質量屬性：影響質量的各種因素的評估函數；(3)內部數據：由數據名、類型,以及允許的取值范圍定義。往往用于記錄自主構件內部和外部環境的動態變化。(4)外部依賴服務：定義了自主構件對外部計算資源的依賴，以及對計算資源的計算能力和服務質量的期待。(5)交互對象：定義了自主構件在合作過程中，對交互對象的期望列表。(6)交互協議：定義自主構件能夠支持的交互方式。(7)動作：定義了自主構件的具體行為。(8)決策：決定是否采取行動，以及如何采取行動，以便更好地實現自身的目標。7.6面向構件及服務的設計技術397.6.1面向構件的物聯網應用設計自主構件的基本構成及其運行機理7.6面向構件及服務的設計技術407.6.1面向構件的物聯網應用設計自主構件的生命周期經過設計、實施、測試、驗證，經過安裝和配置，自主構件需要向系統注冊安裝和配置信息，以便在進行后續自決策時使用。安裝配置完成后，自主構件進入自己的生命周期。7.6面向構件及服務的設計技術417.6.2面向服務的物聯網應用設計面向服務的體系結構(ServiceOrientedArchitecture,SOA)是一種構件模型，可以根據需求通過網絡對松散耦合的粗粒度應用構件進行分布式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中與軟件代理交互的人為依賴性。SOA是軟件工程中提出來旨在提高軟件構件重用功能的體系架構，但其特征無疑同樣適合于物聯網系統的體系結構設計與開發。SOA的5大基本特征為構件的功能重用提供了解決的辦法。7.6面向構件及服務的設計技術427.6.2面向服務的物聯網應用設計①服務之間通過簡單、精確定義的接口進行通信，不涉及底層編程接口和通信模型。②粗粒度性：粗粒度服務提供一項特定的業務功能，采用粗粒度服務接口的優點在于使用者和服務層之間不必再進行多次的往復，一次往復就足夠了。③松耦合性：松耦合性要求SOA架構中的不同服務之間應該保持一種松耦合的關系。④位置透明性：位置透明性要求SOA系統中的所有服務對于其調用者來說都是位置透明的。⑤協議無關性：協議無關性要求每一個服務都可以通過不同的協議來調用。7.6面向構件及服務的設計技術437.6.2面向服務的物聯網應用設計本節以一個基于服務的物聯網EPCIS設計來介紹面向服務的物聯網應用設計。本節的物聯網流程即按照EPCglobal框架設計RFID讀寫器讀取商品標簽中的EPC碼并傳送到RFID過濾收集中間件，中間件負責收集從識讀器上傳的數據。在EPCIS捕獲應用程序和EPCIS存儲系統之間定義EPCIS信息捕獲接口，捕獲中間件的事件報告，并存儲到EPCIS存儲系統，在EPCIS存儲系統和EPCIS訪問系統之間定義EPCIS查詢接口，負責查詢EPCIS事件報告。上述流程可知，EPC信息系統處于系統最高抽象層次，負責和RFID過濾收集中間件進行交互7.6面向構件及服務的設計技術447.6.2面向服務的物聯網應用設計分析：EPCIS訪問系統相當于電子商務中的供應商，EPCIS存儲系統相當于電子商務中經營規模較大的經銷商，經銷商從供應商購買商品后出售，售出商品后，經銷商的系統接收RFID過濾收集中間件從讀寫器讀來的數據存到數據庫，為經銷商查詢商品銷售情況提供依據，供應商可以從經銷商處及時、準確了解到自己所訂閱商品的銷售情況，從而及時調整生產，避免產量過?；蛘卟蛔?。7.6面向構件及服務的設計技術457.6.2面向服務的物聯網應用設計設計：用兩個系統分別代表供應商和經銷商。在EPCIS的實現中引入面向服務的架構設計后，經銷商登錄供應商的系統選購完商品并提交訂單后，訂單中的商品信息自動存儲在以本次訂單號為文件名的XML文件中，系統將根據訂單號獲取訂單中商品信息的操作發布為服務，經銷商根據訂單號去調用這個服務就可以獲取本次購物袋商品信息。7.6面向構件及服務的設計技術467.6.2面向服務的物聯網應用設計設計（續）：供應商登錄經銷商的系統，填寫訂閱請求表單，需要填寫的訂閱信息為商品編號、商品名稱、開始時間、結束時間，提交訂閱表單后得到一個訂閱號。經銷商端的系統跟過濾收集中間件相連，售出商品時，識讀器掃描售出商品的標簽中的商品信息，經過ALE中間件的處理后傳遞到經銷商，經銷商系統根據供應商的訂閱信息，將訂閱商品的信息存儲在以訂閱單號為文件名的XML文件中，并根據訂閱單號獲取訂閱商品信息，發布為服務，供應商根據訂閱單號直接調用該服務就可以得到該訂閱商品信息。供應商和經銷商這兩個系統之間交互是以相互調用服務的形式進行交互，真正實現了SOA中的松耦合。7.6面向構件及服務的設計技術477.6.2面向服務的物聯網應用設計實現：經銷商系統中需要錄入商品的屬性為商品編碼、商品名稱、商品種類、商品價格、商品數量，則供應商在暴露的獲取商品清單的服務中的商品應包括這些內容，由于這個服務中商品的屬性來自商品清單XML文件，則商品清單XML文件里也應包括這些屬性，并以元素名代表這些屬性，元素的內容為商品的屬性。供應商系統中需要訂閱的商品屬性為商品編碼、商品名稱、商品種類、商品價格、商品數量、交易地點、交易時間。則經銷商在獲取訂閱商品信息的服務中也應該包括這些內容，由于該服務中商品的屬性來自訂閱商品XML文件，則訂閱商品XML文件也應包括這些屬性，以元素名代表這些屬性，元素的內容為商品的屬性。7.6面向構件及服務的設計技術487.6.2面向服務的物聯網應用設計實現（續）：WebServices作為SOA的實現技術，充分利用Web分布式編程模型的松散耦合性，允許各種平臺和各種編程語言的應用程序彼此交換數據，從而將其無縫地整合在一起。WebServices涉及到的技術有SOAP，WSDL和UDDI。SOAP基于兩種已經廣泛使用的技術：HTTP和XML，其中HTTP用于SOAP消息傳輸，而XML文檔則是SOAP的編碼模式，SOAP可以非常方便地解決異構系統中互相通信的問題。一條SOAP消息就是一份特定的XML文檔，包含如下三個元素：必需的<Envelop/>根元素，可選的<Head/>元素，包含SOAP消息的頭消息，必需的<Body/>元素，包括所有的調用和響應消息。7.6面向構件及服務的設計技術497.6.2面向服務的物聯網應用設計實現（續）：WSDL文檔是一份與平臺無關的XML文檔，詳細定義了WebServices的位置、所提供的操作以及調用這些操作的方式，WebServices調用者根據該WSD文檔調用WebServices的服務。WSDL模型充分運用了規范和實現分離的原則，將WebServices的服務和實現分成兩個部分定義。第一部分定義了服務接口，由<message/>元素和<portType/>元素組成，而<portType/>元素則包含任意數量的<operation/>子元素，每個<operation/>子元素代表一個允許遠程調用的操作。第二部分定義了服務實現，由<binding/>和<service/>兩個元素組成，其中<binding/>元素定義了使用特定的通信協議，而<service/>元素則包含了一系列的<port/>元素，把綁定機制、服務訪問協議和端點地址結合在一起。7.6面向構件及服務的設計技術507.6.2面向服務的物聯網應用設計實現（續）：基于服務的EPCIS實現可以采用Apache的CXF開源框架來簡化用戶開發WebServices操作，并可與JavaEE項目實現無縫整合，因此選用Java中的Struts2+Spring3+Hiberate3框架實現供應商和經銷商這兩個系統，并通過CXF框架為這兩個系統增加Web服務功能來實現上述設計。其中，Web服務的發布需要首先聲明一個接口，再通過具體類來實現該接口。接口和實現類的代碼如下所示：//獲取商品清單服務的接口@WebServicepublicinterfaceOrderWs{publicList<Commodity>getCommodities(Stringid,Stringusername,Stringpassword);}7.6面向構件及服務的設計技術517.6.2面向服務的物聯網應用設計實現（續）：//獲取商品清單服務的實現@WebService(endpointInterface=“com.service.ws.order.OrderWs”,serviceName=“OrderWs”)publicclassOrderWsImpimplementsOrderWs{publicList<Commodity>getCommodities(Stringorderid,Stringusername,Stringpassword){//具體實現代碼（略）}}其中具體實現代碼就是解析文件“訂單號.xml”中<商品>元素的內容，得到訂單中的商品信息。在Spring配置文件ApplicationContex.xml中利用CFX框架提供的<jaxws:endpoint>元素，用下面一行代碼<jaxws:endpointid=“order”implementor=“orderWs”address=“/order”></jaxws:endpoint>就能將getCommodities方法暴露成獲取清單的服務(前提是將該元素的<scheme>元素包含在配置文件ApplicationContex.xml中)7.7以APP為中心的物聯網軟件生態系統以APP應用程序為中心的軟件生態系統指的是使用軟件生態系統作為軟件架構。這種架構有兩部分主要的構成要素，一部分是基礎軟件模塊——APP應用程序；另一部分是管理和運行這些應用程序的環境。其中，APP也表示最主要的實體類型。以APP為中心的軟件生態系統當前最成功的應用是在移動領域。然而，這些平臺的成功已經導致建立應用商店的一個廣泛的領域，并通過一系列的產品，甚至延伸到近期SMART平臺的電子病歷（EMR）領域。527.7.1以APP為中心的軟件生態系統架構7.7.2APP與構件之間的比較7.7.3APP與服務之間的比較7.7.4APP環境7.7.5以APP為中心的物聯網軟件系統實例7.7.1以APP為中心的軟件生態系統架構以APP為中心的軟件生態系統的眾多組成中，存在兩個普通的元素：一組APP以及用來管理和執行這些APP的環境。這兩個子系統構成了以APP為中心的軟件生態系統的體系結構。一個應用程序APP是一種小型、單一用途的軟件工具。APP在概念上與大型、單一廠商的軟件即服務（SaaS）所提供的產品的模塊或插件類似。但是，一個APP比插件或模塊更加獨立于其環境：APP一般與APP環境中的基礎的、通用的功能沒有沒有依賴。537.7以APP為中心的物聯網軟件生態系統7.7.1以APP為中心的軟件生態系統架構一般地，如果一個模塊或插件滿足以下要求，就可以被認為是APP：（1）APP具有用戶界面。也就是說，APP的設計是為與系統的人類用戶交互的。他們還可以通過該APP環境彼此互動。（2）APP在其生態系統中服務于一個或幾個目的（如電子郵件，日歷，待辦事項列表）。（3）APP是可以被APP環境發現和加載的。這些因素也有助于從組件和服務中區分APP。在軟件模塊的抽象層次，APP可能被認為是在和服務相似的抽象層次，而組件存在于較低層。547.7以APP為中心的物聯網軟件生態系統7.7.2APP與構件之間的比較APP對構件就像構件和對象的對比：是上面抽象的統一層次。APP可以由構件，以及對象、功能和原始程序代碼來組成。構件存儲他們的大部分數據，而APP幾乎不存儲自己的數據。不是在內部存儲數據，APP操作的數據是存儲在共享數據總線上，由APP環境提供，以方便與類似用途的APP之間共享。不像構件，APP通過在一個APP環境中托管以組合成更大的軟件系統。構件的組合通常需要在各個構件之間配置一系列的接口調用。557.7以APP為中心的物聯網軟件生態系統7.7.3APP與服務之間的比較APP和服務在軟件模塊抽象層次中處于同一層。然而，APP和服務在鏈接數據和可執行代碼時采用相反的方法。服務一般要求數據在服務之間來回傳輸；在Web服務的情況下，這種傳輸的發生是通過數據網絡向遠程服務的主機。另一方面，使用APP需要傳送可執行代碼，即APP，到包含數據的執行環境。APP和服務這兩者都是由對象、組件、功能和源程序代碼組成。和APP不同，服務是通過一組數據的鏈接的轉換而集成和組合成較大的解決方案。567.7以APP為中心的物聯網軟件生態系統7.7.4APP環境一個以APP為中心的軟件生態系統的APP環境提供發現、管理和執行APP的必要資源。APP的發現往往是通過一個集中的Web服務----APP商店來管理。AppStore中包含的環境的安裝，配置和刪除APP的能力構成了它來管理它所包含的APP的能力。而APP被執行時，環境提供到共享數據存儲、外部通信（如網絡服務）、以及訪問連接到該應用環境中的物理設備的接口，例如相機，GPS接收器和加速計。577.7以APP為中心的物聯網軟件生態系統7.7.4APP環境在APP為中心的軟件體系結構中，數據在APP之間通過由環境提供的共享數據總線共享。共享數據總線的使用允許特定類型的APP的多個實例在生態系統中存在，允許用戶選擇他們更喜歡使用的實例。例如，蘋果公司的iOS應用環境提供訪問日歷數據庫，應用程序可以用它來管理日歷數據（如約會）。IOS設備的用戶可能會從各種日歷管理應用程序選擇，根據自己的喜好，如對于給定的用戶接口的偏好。587.7以APP為中心的物聯網軟件生態系統7.7.4APP環境由APP環境提供的共享數據總線還可以使得APP即使沒有相互之間的直接調用時，也能響應其他APP的活動。返回到IOS中的日歷數據示例，一個APP可以監視在不久的將來的約會，與導航和GPSAPP交互來確定從設備當前地點旅行到預約地點所需的時間，并且當設備用戶需要開始動身到他們的下一個約會時觸發警報。在這個例子中，用戶不必直接將他們的約會輸入到警報APP。取而代之的是，報警APP對共享數據總線上的日歷數據作出反應。值得注意的是，在以APP為中心的軟件生態系統環境的描述中沒有包含生態系統環境對于單一設備的描述。如果共享數據總線，就像在Web3.0資源描述框架總線或無線傳感器網絡，能夠跨越多個設備，在多個物理設備的APP應用程序仍然可以被認為是相同的APP環境的一部分。597.7以APP為中心的物聯網軟件生態系統7.7.5以APP為中心的物聯網軟件系統實例需求：我經常去家門口的一家餐館吃飯，而且每次去，點的餐食基本都一樣。但現在的問題是，每次去都要排隊、點餐、交錢，然后拿餐牌、找座位、等待。顯然這是一個重復乏味的過程，如果能夠通過自動化的物聯網應用，使得這個過程簡化或者自動化，那就很理想了。解決方案：我們開發一種通用的智能手環，智能手環上運行物聯網操作系統。手環除了具備通用的鬧鐘提醒、身體生物指標測量和報告等功能外，還具備RFID功能，該功能的打開與否，由用戶控制，比如甩一下手環、按一個按鈕等。在餐館門口，安裝一套ID識別設備，一旦一個帶手環的人進入餐館，并打開了RFID功能，就立即被檢測到。檢測設備把進入者的ID上報給后端服務器，后端服務器進一步判斷這個人是否已經有消費記錄。如果沒有，OK，遵循通常的點餐、交錢、等待等流程，但是這個過程中，后臺系統會建立針對這個人的檔案，并記錄其點餐列表、等待時間、座位號等信息。607.7以APP為中心的物聯網軟件生態系統7.7.5以APP為中心的物聯網軟件系統實例解決方案（續）：如果這個人第二次來就餐，那好了，運行在手環上的APP（由餐館開發并上傳到M2MAPPStore，由用戶安裝到手環上）會立即震動提醒消費者，并通過自帶的小屏幕，自動把上一次點的餐食列表等信息呈現給消費者，讓消費者確認是否點同樣的餐食。如果確認點同樣的餐食，則消費者只需要找個空閑的位置坐下，然后等待即可，手環上的APP會自動檢測出座位號，并聯系餐館的后臺服務器下訂單。吃完后，通過手環確認一下，可自動完成支付，甚至可以對本次消費滿意度點評。顯然，排隊、點餐、交錢等過程完全省略了，大大提升了就餐方便程度。617.7以APP為中心的物聯網軟件生態系統7.7.5以APP為中心的物聯網軟件系統實例實現：實現這個過程，最關鍵的一點就是，手環上需要運行一個餐館特定的APP，這個APP能夠跟RFID聯動，并跟餐館后臺交互，完成就餐過程的自動化。這樣的APP可能有多個，因為你可能要去很多餐館就餐。如果沒有物聯網操作系統的支持，這是無法做到的。或者說也可以做到，但是你的手腕上需佩戴很多手環，一個餐館一個。這樣的話，你的職業也變了，變成餐館的活體廣告牌了。627.7以APP為中心的物聯網軟件生態系統7.7.5以APP為中心的物聯網軟件系統實例分析：這個餐飲行業的應用，幾乎把上面生態模型中的每個模塊都涉及到了：手環與餐館檢測系統的交互，屬于端端通信，手環上運行的APP，需要從M2MAPPStore下載。具體下載哪些餐館的APP，由消費者通過智能手機控制。手環上的任何一個APP，都需要跟自己的后臺進行通信。假設手環上的某個配件（比如某個按鈕、甚至RFID等）壞了，需要更換一個新的，這時候手環需要跟終端管理后臺進行通信，下載新配件的驅動程序。上述過程的最核心需求，就是物聯網操作系統支持的兩大分離特性：應用軟件和硬件分離，操作系統內核和硬件設備驅動程序的分離。637.7以APP為中心的物聯網軟件生態系統7.7.5以APP為中心的物聯網軟件系統實例分析（續）：在物聯網領域，很多情況下，硬件終端的功能比手環簡單得多，無需或者無法運行第三方開發的APP。這種場景下，上述架構也可以很好的實現人與物的交互。舉例來說，為了實現對環境的實時檢測，未來可能會開發很多依靠太陽能供電、無顯示屏等外設的“環境監測器”，以公共服務的形式，安裝到任何可以安裝的地方。用戶通過智能手機，可以隨時讀取這些小玩意兒上的檢測數據。這時候，如果是第一次讀取某種型號監測器上的數據，則首先用手機上的M2MAPPStore客戶端軟件，掃一下監測器上的二維碼，客戶端會自動根據二維碼中記錄的信息，到M2MAPPStore上下載一個應用程序。這個應用程序調用藍牙、Zigbee等無線服務，從監測器上獲取數據，然后顯示出來。647.7以APP為中心的物聯網軟件生態系統7.8物聯網應用部署657.8.1成功部署物聯網應用的十個步驟7.8.2物聯網平臺的三種部署方式7.8.3應用在末梢終端上的部署7.8.4應用在服務器上的部署7.8.5基于云計算的應用部署7.8物聯網應用部署667.8.1成功部署物聯網應用的十個步驟物聯網應用項目開發完成后，應用的部署也是一項非常重要的工作。下面是成功部署物聯網項目的10個步驟，可供我們部署之前參考。1:學習他人經驗2:制定戰略3:先實現較容易的目標4:清理你的數據5:想想你的客戶6:不要忘記故障轉移7:加強安全防范8:結合IoT數據與現有數據9:設置基線和指標10:定義你的下一代IoT應用程序7.8物聯網應用部署677.8.2物聯網平臺的三種部署方式本節簡單介紹三種物聯網平臺部署模式，給出三種物聯網平臺的安全接入方案，并分別對這三種方案的安全性進行討論，目的是為利用現有技術從傳輸安全出發為感知數據安全地傳輸到物聯網平臺提供建議和參考。運營商在物聯網產業鏈中扮演重要角色，因為它們擁有用戶和網絡資源，大部分物聯網的感知數據需要經過運營商掌握的網絡資源進行傳輸。國外運營商或聯合平臺提供商推出物聯網平臺，或自己開發物聯網平臺。國內運營商正在加緊各自物聯網平臺的研發。7.8物聯網應用部署687.8.2物聯網平臺的三種部署方式1

、

物聯網平臺的部署模式物聯網平臺搭建在通信網絡上，為網絡和應用層業務邏輯提供連接，其部署模式主要有三種，即行業專網模式、電信網模式和Internet模式。1)行業專網模式：即物聯網應用部署在行業專網上，甚至某些感知設備也是行業專用的。這種模式的物聯網應用只針對行業內的用戶，不對外公開，典型案例如煤礦、機場等重要區域的安防類應用。2)電信網模式：即物聯網應用部署在PSTN(PublicSwitchedTelephoneNetwork,公共交換電話網)、3G/4G等由運營商嚴格管控的公用電信網絡上，這種模式的物聯網應用針對具有電信網通信功能的感知設備(如帶有3G/4G通信模塊)和用戶，典型案例如電力抄表。7.8物聯網應用部署697.8.2物聯網平臺的三種部署方式1、

物聯網平臺的部署模式3)Internet模式：即物聯網應用部署在Internet上。由于Internet是一個連接各種網絡的網絡，它與電信網絡、行業專網也是互聯互通的。這種模式與電信網模式的最大區別是運營商無法對Internet實施嚴格管控，而運營商可以對電信網絡實施嚴格管控。這種模式的典型案例如通過LAN(LocalAreaNetwork，局域網)接入Internet的家庭網絡，運營商可以對家庭網關進行管控，但是對網關以下的節點就有些力不從心了。7.8物聯網應用部署707.8.2物聯網平臺的三種部署方式2、三種接入方案感知數據(包括視頻、音頻、傳感數據)在網絡上傳輸，要保證較高的安全級別，否則錯誤的數據是沒有意義的，在某些對安全性要求較高的領域(如安防監控)，錯誤的數據甚至是危險的。對應三種物聯網平臺的部署模式，可以采用三種方式實現感知數據的安全傳輸，第一種是提供物理上與公共網絡隔離的專線連接網絡，第二種是基于移動通信網絡的安全通道，第三種是基于Internet的安全通道。7.8物聯網應用部署717.8.2物聯網平臺的三種部署方式2、三種接入方案----2.1專線接入該方式適合于物聯網平臺的行業專網模式。以機場、銀行、監獄等重要區域安防類應用為例。這類重要區域不僅需要各種傳感器采集防區的信息，視頻監控更是不可缺少的監控手段，提供最直觀的視頻信息和視頻復查功能。由于視頻具有高帶寬大碼流的特點，同時眾多的其它感知設備也會造成大量的感知數據，所以本節中的方案采用光纖作為傳輸介質，具體組網結構如圖7-35所示。感知層采集視頻、聲音和各類傳感數據，通過物聯網網關接入光端機，然后通過環狀的光纖交換網絡接入重要區域內部網絡7.8物聯網應用部署727.8.2物聯網平臺的三種部署方式2、三種接入方案----2.1專線接入光端機實現對采集視頻、聲音和各類傳感數據的數據處理及光電轉換，能夠支持各種高分辨率視頻信號，自動兼容各種視頻圖像制式。除視頻信號，還提供雙向音頻信號，雙向RS232(或其它數據通信接口)數據信號。雙向RS232數據信號用于傳輸攝像機云臺控制或視頻矩陣切換。光纖交換機組成自愈環網，連接光端機和物聯網平臺。7.8物聯網應用部署737.8.2物聯網平臺的三種部署方式2、三種接入方案----2.1專線接入該方案的安全性體現在：1)感知設備通過專線接入物聯網平臺，其承載網絡實現與公眾網絡物理上的隔離。物聯網的業務數據不易受到來自公眾網絡的威脅。2)光纖交換機作為重要區域內部傳輸網絡的核心，采用自愈環網組網方式，可在各種環境下實現數據傳輸的穩定性、可靠性和實時性。7.8物聯網應用部署747.8.2物聯網平臺的三種部署方式2、三種接入方案----2.2基于WCDMA網絡的安全通道一、WCDMA電路域接入圖7-36中感知終端和物聯網網關都具有WCDMA通信模塊，二者統稱作感知設備。二者的主要區別是，其它不具備WCDMA通信能力的感知設備可以通過近距離通信(Zigbee，藍牙，WiFi等)與物聯網網關相連，然后通過網關接入WCDMA網絡。而圖中帶WCDMA通信模塊的感知終端不具備近距離組網能力，且可以直接連接WCDMA網絡?；赪CDMA電路域接入物聯網平臺可以通過USSD(UnstructuredSupplementaryServiceData，非結構化補充數據業務)和短消息兩種方式。7.8物聯網應用部署757.8.2物聯網平臺的三種部署方式2、三種接入方案----2.2基于WCDMA網絡的安全通道一、WCDMA電路域接入1）感知設備或手機用戶USSD流程：①感知設備或手機用戶向USSD平臺呼叫；②USSD平臺接收到呼叫請求后，經過路由判斷，把請求按照SRE(ServiceRuntimeEnvironment業務運行環境，它用內部接口與USSD網關交互)格式打包向SRE提交；③SRE根據業務觸發規則找到對應的動態庫；④動態庫執行對應的業務邏輯，生成處理結果；⑤SRE將數據提交到USSDC，USSDC轉換產生USSD數據發回感知設備或用戶。7.8物聯網應用部署767.8.2物聯網平臺的三種部署方式2、三種接入方案----2.2基于WCDMA網絡的安全通道一、WCDMA電路域接入2）感知設備或手機用戶短消息流程：①感知設備開機后，首先使用AT命令對通信模塊進行初始化，然后定時地采集本地各種感知信息；②采集后數據經過數據處理單元(如單片機)處理，以短消息的形式發送到物聯網平臺；7.8物聯網應用部署777.8.2物聯網平臺的三種部署方式2、三種接入方案----2.2基于WCDMA網絡的安全通道一、WCDMA電路域接入（續）2）感知設備或手機用戶短消息流程（續）：③平臺將收到數據整理比較，同時把各種感知數據在平臺用戶接口上進行顯示。如果接收的某些數據達到設定的閥值，感知設備向平臺發出報警信號，平臺可以對收到的告警信息進行處理，并采取相應的措施進行補救。短信息(SMS)具有隨時在線、不需撥號、價格便宜、覆蓋范圍廣等特點，特別適合于傳送小流量數據。將數據處理單元(如單片機)和SMS結合，利用單片機系統采集本地數據并作出相關判斷，再通過SMS傳輸感知數據，并且物聯網平臺利用發送SMS實現對感知設備的遠程控制，是一種行之有效的物聯網業務開展方式。7.8物聯網應用部署787.8.2物聯網平臺的三種部署方式2、三種接入方案----2.2基于WCDMA網絡的安全通道一、WCDMA電路域接入（續）2）感知設備或手機用戶短消息流程（續）：該方案的安全性體現在：基于現有移動網絡安全接入機制使用信令信道傳輸數據，實時性、交互性好，減少數據被截獲、篡改的可能性；但該方案數據傳輸帶寬小，僅適用于少量數據的安全傳輸。7.8物聯網應用部署797.8.2物聯網平臺的三種部署方式2、三種接入方案----2.2基于WCDMA網絡的安全通道一、WCDMAVPDN接入（續）WCDMAVPDN業務全稱是VirtualPrivateDial-upNetwork，又稱為虛擬專用(或私有)撥號網，是VPN的一種，是基于撥號用戶的虛擬專用撥號網業務。該技術使感知設備或用戶能通過WCDMA網絡無縫和安全地連接到物聯網平臺。VPDN的具體實現是采用隧道技術，即將感知數據封裝在隧道中進行傳輸。本文VPDN的隧道封裝采用L2TP(Layer2TunnelProtocol)封裝。7.8物聯網應用部署807.8.2物聯網平臺的三種部署方式2、三種接入方案----2.2基于WCDMA網絡的安全通道一、WCDMAVPDN接入呼叫建立流程如下。1）感知設備或用戶通過物聯網平臺專用APN呼叫到SGSN。運營商為物聯網平臺分配專用APN(AccessPointName，接入點)信息，該APN信息會寫入的HLR中，保證只有物聯網平臺授權的號碼才能進行該APN的撥號，獲取相關IP地址信息及網絡訪問權限。2）SGSN通過DNS解析APN接入歸屬GGSN的IP地址。可采用專用的GGSN等核心網設備進行VPDN業務(該GGSN只進行VPDN業務，不進行大眾應用)，實現在物理上與大眾應用的隔離，確保安全。7.8物聯網應用部署817.8.2物聯網平臺的三種部署方式2、三種接入方案----2.2基于WCDMA網絡的安全通道一、WCDMAVPDN接入（續）呼叫建立流程如下（續）。3）GRPS/WCDMA網絡在SGSN和GGSN間啟動相應的GTP隧道協議，實現GPRS/WCDMA骨干網內的安全傳輸。4）物聯網平臺所對應的GGSN針對該APN發起RADIUS(RemoteAuthenticationDialInUserService，遠程撥號用戶認證服務)認證請求，同時GGSN(具有LAC即L2TPAccessConcentrator，L2TP接入集中器的功能)通過APN的用戶標識實現L2TP隧道選擇，由AAA服務器或LNS(LNS表示L2TP網絡服務器L2TPNetworkServer，是PPP端系統上用于處理L2TP協議服務器端)對用戶名和密碼進行認證。7.8物聯網應用部署827.8.2物聯網平臺的三種部署方式2、三種接入方案----2.2基于WCDMA網絡的安全通道一、WCDMAVPDN接入（續）呼叫建立流程如下（續）。5）如果物聯網平臺部署在企業內部網絡，企業將私有IP地址事先在GGSN或LNS上面配置好，這樣就可以通過GGSN或LNS根據APN給GRPS/WCDMA用戶分配企業內部的IP地址。6）感知設備或用戶發起數據業務，在GGSN通過APN的用戶標識實現數據的L2TP隧道封裝安全傳輸，最后在企業外部網關完成L2TP隧道的解封裝，還原為企業內部網絡的數據包。7）企業內部網絡到感知設備或用戶的L2TP隧道封裝數據包，經過GGSN隧道解封裝后，通過GRPS/WCDMA網絡轉發到感知設備或用戶。7.8物聯網應用部署837.8.2物聯網平臺的三種部署方式2、三種接入方案----2.2基于WCDMA網絡的安全通道一、WCDMAVPDN接入（續）呼叫建立流程如下（續）。該方案的安全性體現在：1)撥號用戶使用VPDN業務時有兩種認證情況，一種是一次認證；另一種是二次認證,一般情況下，為了保證VPDN的安全性，通常需要采用二次認證。所謂二次認證是指在接入服務器LNS和企業安全服務器上分別進行用戶認證。接入服務器進行初步認證，確定該用戶是否為合法的VPDN用戶以及是否建立隧道。隧道建立后，企業安全服務器對用戶進行第二次認證，再次確認用戶是否為企業的合法用戶。一般來說，二次認證方式要比一次認證方式的安全性高。7.8物聯網應用部署847.8.2物聯網平臺的三種部署方式2、三種接入方案----2.2基于WCDMA網絡的安全通道一、WCDMAVPDN接入（續）呼叫建立流程如下（續）。該方案的安全性體現在：2)可以結合IMSI(InternationalMobileSubscriberIdentificationNumber，國際移動用戶識別碼)認證與IP地址綁定、專用APN