基於ZigBee的家居控制系統的設計與應用

基於ZigBee的家居控制系統的設計與應用

PPT簡介：http://pan.baidu.com/s/1i38PC6D

摘  要

智能家居是將來家居的發展方向，其利用先進的網絡技術、計算機技術和無線通訊技術等將家居中的各類電子電氣設備鏈接起來，統一管理、遠程監控和資源共享，實現了高效、便利的生活環境。近些年互聯網的迅猛發展，網絡的穩定性、安全性和網絡帶寬都有了長足的發展，由互聯網提供的各類服務已經深刻到人們生活的方方面面，所以將智能家居系統同互聯網結合起來，爲用戶提供遠程控制服務，延伸智能家居系統的使用空間，已經成爲智能家居系統發展的一種趨勢。

基於此背景，本文研究了基於ZigBee的智能家居控制系統。論文首先闡述了智能家居的概念及發展趨勢，分析了智能家居系統所涉及的關鍵技術。經過對無線智能家居系統結構的調研和了解，並結合智能家居網關和控制終端的特色，最終肯定了智能家居系統的設計方案：在感知層採用低複雜度、低功耗、低速率、低成本、自組網、高可靠的ZigBee無線網絡技術做爲傳感器節點和控制器節點的通訊方案；在網絡層設計了一種橋接ZigBee無線網絡和以太網的智能網關，智能網關既能夠做爲局域網內的中心控制器，又是底層節點與雲平臺的數據傳輸中樞；最後本文設計了可用於智能家居實現遠程控制及其餘服務的雲平臺，使用HTTP協議做爲通訊協議，JSON格式做爲雲平臺響應數據格式，實現了雲平臺的基本功能和RESTful風格的API。

 

關鍵詞：ZigBee智能家居，網關，雲平臺，物聯網

 

目  錄

基於ZigBee的家居控制系統的設計與應用... i

摘  要... i

1 緒論... 1

1.1 課題背景及來源... 1

1.2 智能家居概述及研究現狀... 1

1.4 智能家居系統關鍵技術... 2

1.4.1 智能家居有線組網技術與無線組網技術... 2

1.4.2 智能家庭網關技術... 4

1.4.3 智能家居雲服務... 5

2 智能家居設計方案與相關技術簡介... 8

2.1 需求分析... 8

2.2 智能家居控制系統方案設計... 8

2.3 ZigBee網絡拓撲結構的選擇者... 10

3 智能家居感知層ZigBee技術分析... 12

3.1 ZigBee技術概述... 12

3.2ZigBee技術的體系結構... 13

3.3 ZigBee節點的創建... 14

3.4 ZigBee通訊網絡的創建... 14

3.4.1 網絡層概況及網絡的造成... 14

3.4.2 網絡的鏈接與斷開... 16

3.4.3 網絡地址的分配機制... 17

3.5 ZigBee個域網中的通訊功能... 19

3.5.1 幀結構... 19

3.5.2 數據傳輸事務... 20

3.5.3 安全性... 22

4. 智能家居網關的設計... 25

4.1 智能家居服務網關概述... 25

4.2 網關整體結構設計... 25

4.3 網關軟硬件設計... 27

4.3.1 網關硬件設計... 27

4.3.2 網關軟件設計... 28

4.4 ZigBee協調器軟件設計... 29

4.4.1 協調器接收無線數據... 29

4.4.2 協調器發送數據到傳感器節點... 29

4.4.3 協調器的工做流程... 30

4.5 網關的通訊設計... 30

4.5.1 LwIP簡介... 30

4.5.2 本地局域網通訊... 32

4.5.3 遠程通訊... 33

5 智能家居雲平臺設計... 35

5.1智能家居雲平臺概述及發展示狀... 35

5.2 智能家居雲平臺設計方案與相關技術... 37

5.2.1 雲平臺需求分析... 37

5.2.2 數據交互格式... 37

5.2.3 雲平臺基本設計方案... 38

5.3 智能家居雲平臺系統設計... 39

5.2.1 數據庫設計... 39

5.2.2 RESTful API設計過程... 40

5.4 智能家居雲平臺功能實現... 41

5.4.1 設備類... 41

5.4.2 傳感器類... 43

5.4.3 數據點類... 44

5.5 雲平臺測試與結果分析... 50

5.5.1 雲平臺測試... 50

5.5.2 雲平臺測試結果分析... 54

5 總結與分工... 55

 

 

1 緒論

1.1 課題背景及來源

網絡的普遍普及和通訊技術的高速度發展，給現在的社會帶來了數字化和信息化的改變。信息化從20世紀80年代開始就滲透到社會的各個領域並加快了各行各業的發展，現在科研、國防、商務、金融、企業管理和辦公都已經離不開網絡和信息技術。經過信息的傳遞實現社會、家居生活和人的融通，這是人們實現更高標準的生活的途徑，也是信息社會發展的必然。

近年來，物聯網成爲全球關注的熱點領域，被認爲是繼互聯網以後最重大的科技創新。物聯網經過射頻識別（RFID）、紅外感應器、全球定位系統、激光掃描器等信息傳感設備，按約定的協議把任何物品與互聯網鏈接起來進行信息交換和通信，以實現智能化識別、定位、跟蹤、監控和管理。

物聯網是互聯網的延伸，M2M是當前的主要應用。物聯網的遠景目標是把全部物品鏈接到互聯網，組成一個超大的智能網絡。通俗地說，物聯網是讓一切物品連上網絡，物品之間能夠直接對話和自動反應，這樣人們能夠在任什麼時候間、任何地點、任意地瞭解到任何物品的情況，而且能夠進行有效的控制。物聯網的發展爲智能家居引入了新的概念及發展空間，智能家居能夠被看做是物聯網的一種重要應用。

本課題來源於實際企業無線智能家居系統的需求。該系統致力於結合物聯網技術及其它無線傳輸技術（Zigbee、RFID、WIFI、藍牙），實現對智能家居設備的無線控制和智能管理。系統由智能家居設備、智能家居嵌入式網關、智能家居雲平臺、智能家居Web平臺和智能家居控制終端（手機等智能設備）組成。

其中智能家居雲平臺做爲數據存儲與交換的平臺，須要協同嵌入式網關和控制終端、Web平臺進行數據傳輸與通訊控制，實現對智能家居設備運行情況的記錄，並輔助控制終端和Web平臺完成對智能家居設備的遠程控制。

1.2 智能家居概述及研究現狀

智能家居概念的起源於20世紀80年代初，隨着大量採用電子技術的家用電器面市，住宅電子化開始實現；80年代中期，將家用電器、通訊設備與安全防範設備各自獨立的功能綜合爲一體，又造成了住宅自動化概念；至80年代末，因爲通訊與信息技術的發展，出現了經過總線技術對住宅中各類通訊、家電、安防設備進行監控與管理的商用系統，這在美國被稱爲Smart Home，也就是如今智能家居的原型。

當前的智能家居就是以住宅爲平臺，集網絡通訊、網絡系統和自動化控制於一體，經過互聯網技術將家庭設備聯繫成家庭網絡，實現遠程操控，爲人們提供了溫馨安全高效和便利的生活居住環境。

目前智能家居在歐美等發達國家獲得普遍應用。可是從嚴格意義上來講，智能家居仍是處於剛剛啓動的探索階段。美國的智能家居主要體如今追求溫馨、豪華感和享受上，它是以數字技術改造而展開的，但很是消耗能源。日本的智能家居主要體如今注重功能、以人爲本、環境保護與兼顧將來發展等幾個方面。並且日本的智能家居還注重施工過程的集團化與規模化，在設計施工中大量採用新技術新材抖。德國的智能家居體如今注重基本的功能性和追求專項功能的開發等方面。韓國的智能家居獲得政府的多項政策扶持，行政規定在首爾等大城市的新建的生活小區必須具有智能家居體系。中國智能家居的發展在經歷了很長時間的探索階段以後，國內的各具特色的智能家居系統也由各你們電巨頭生產商和通訊服務商紛紛推出。智能家居業獲得國內各大城市的政府部門的大力扶持，將智能家居體系包含到城市發展規劃中大大促進智能家居行業的發展。

智能家居行業熱點一波又一波，萬物互聯互通（即IOE，internet of everything）成了當下智能化的標準。互聯互通是指智能家居不受品牌，功能的約束，自動創建聯繫，收發數據信息，自動完成指令。實現這些功能的關鍵點是統一的雲平臺。雖然很早就有云平臺建設，部分企業亦投身到雲平臺建設，但一直沒有突破。

面對當下智能家居互聯互通的新趨勢，雲平臺做爲信息儲存傳輸的紐帶，扮演着重要角色。雲是物聯網的基礎，而統一的雲平臺可兼容各類先進技術，以知足客戶需求爲主，不受品牌的約束，集結各路優秀方案，在最短的時間內，使用戶獲得極致的體驗。智能家居做爲物聯網的重要分支，智能家居的雲平臺也是物聯網雲平臺的重要應用。

1.3 智能家居系統關鍵技術

1.3.1 智能家居有線組網技術與無線組網技術

（1）有線組網技術

在過去組建智能家居網絡通常都採用有線的方式。有線組網技術包括以太網、

HomePNA、電力線通訊(PLC)等。

①以太網:以太網是由美國施樂公司研發一種計算機局域網組網技術，IEEE 制定的 IEEE802.3 標準給出了以太網的技術標準。以太網是當前應用最廣泛的有線局域網技術，其標準拓撲結構爲總線型拓撲。它可使用同軸電纜、雙絞線、光纖等多種傳輸介質進行鏈接。以太網是當今現有局域網採用的最通用的通訊協議標準。該標準定義了在局域網中採用的電纜類型和信號處理方法。以太網在互聯設備之間以 10～100Mbps 的速率傳送信息包，以太網憑藉其低成本高可靠性以及 100Mbps 的速率而成爲應用最爲普遍的有線組網技術。

②HomePNA:HomePNA 是家庭電話線網絡聯盟的簡稱，是一種家庭網絡的計算機互聯標準，利用現有的電話線路進行網絡鏈接。採用電話線組網(HomePNA)方案大大的提升了網絡速度，以 HomePNA1.0 和 HomePNA 2.0 爲例，前者的傳輸速率爲 1Mpbs,後者的傳輸速率很是高，大概是前者的 10 倍，最大的優勢是電話線網絡能夠作到上網打電話兩不誤。

③電力線通訊(PLC):電力線通訊技術是採用電力線傳送數據和語音信號的一種通訊方式。該技術是將載有信息的高頻信號加載到電力線上，經過電力線進行數據傳輸，而後經過專用的電力線調制解調器將高頻信號從電力線上分離開來，傳輸到終端設備。與其它有線組網技術相比較，PLC 的成本較低，傳輸速率也相對比較高。

 這種方式全部的控制信號必須經過有線方式鏈接，控制器端的信號線更是多得嚇人，一但遇到問題排查也至關困難。有線方式缺點很是突出，佈線繁雜、工做量大、成本高、維護困難、不易組網。這些缺點最終致使有線方式的智能家居只停留在概念和試點階段，沒法大規模推廣。有線組網與無線組網的比較以下圖所示。

圖1.1 智能家居有線組網與無線組網的比較

 

（1）  無線組網技術

 用於智能家居的無線系統須要知足幾個特性：低功耗、穩定、易於擴展併網；至於傳輸速度顯然不是此類應用的重點。目前幾種可用於智能家居的無線方式，無線方式的智能家居有如下幾種！
   藍牙：是一種支持設備短距離通訊（通常10m內）的無線電技術。能在包括移動電話、PDA、無線耳機、筆記本電腦、相關外設等衆多設備之間進行無線信息交換。但這種技術通信距離過短，同時屬於點對點通信方式，對於智能家居的要求來講根本不適用。
  WIFI：其實就是 IEEE 802.11b 的別稱，是由一個名爲「無線以太網相容聯盟」（Wireless Ethernet Compatibility Alliance, WECA）的組織所發佈的業界術語，中文譯爲「無線相容認證」。它是一種短程無線傳輸技術，可以在數百米範圍內支持互聯網接入的無線電信號。它的最大特色就是方便人們隨時隨地接入互聯網。但對於智能家居應用來講缺點卻很明顯，功耗高、組網專業性強。高功耗對於隨時隨地部署低功耗傳感器是很是致命的缺陷，因此wifi雖然很是普及，但在智能家居的應用中只是起到輔助補充的做用。
  315M/433M/868M/915M：這些無線射頻技術普遍運用在車輛監控、遙控、遙測、小型無線網絡、工業數據採集系統、無線標籤、身份識別、非接觸RF等場所，也有廠商將其引入智能家居系統，但因爲其抗干擾能力弱，組網不便，可靠性通常，在智能家居中的應用效果差強人意，泛善可陳，最終被主流廠商拋棄。
  ZigBee：相比433/315技術，解決了同頻干擾、傳送距離短、非雙向通訊、有無線盲區等問題。相比藍牙技術，解決了傳輸距離短（手機、電腦上的藍牙有效通信距離小於10米）、功耗大、成本高等問題。相比WiFi技術，解決了傳輸距離短（信號不能進行路由轉發，通常跨層後信號就微弱到不能使用的程度）、功耗大、成本高等問題。本能夠選用的無線組網技術即爲ZigBee技術。

圖1.2 幾種經常使用無線組網技術的比較

1.3.2 智能家庭網關技術

智能家庭網絡是信息時代帶給人們的又一個高科技產物。它藉助現有的計算機網絡技術，將家庭內各類家電和設備連網，經過網絡爲人們提供各類豐富、多樣化、個性化、方便、溫馨、安全和高效的服務。家庭網絡化也是整個社會信息化的一個重要的部分。實現家庭內部信息與家庭外部信息的交換，無疑是家庭連網的目的所在。它的實現須要設計一個理想的家庭網關。

許多公司都開發了本身的家庭網關產品。然而開發出更多複雜的和具備兼容性的家庭網關，迫切要求制定相應的家庭網關標準。目前已有的相關標準見下表所示。

開放服務網關組織（OSGi）當前正在制訂他們稱之爲服務網關的規範。該規範包含的技術的主要特色是：須要開放的和獨立的平臺；目標是成爲一個標準；應有較高的獨立性和保密性；應支持不一樣類型的家庭連網協議；應具備較高的可靠性。

OSGi標準實質上是一系列API（應用編程接口）的集合。這些API包括核心的API和可選的API，它們共同構成了OSGi的網關規範。若是必要，OSGi可使用已有的Java標準，其重點是如何集成這些相關的標準。

核心的API執行服務傳輸、從屬和週期管理、資源管理以及遠程服務管理。全部核心的API可由開發人員或OSGi的技術工做組來完成。

可選的API定義了向一個基於HTTP Web服務器輸出資源的機制、客戶機與網關的交互做用以及數據管理。

家庭網關接口的有效的解決方案，當前比較統一的觀點是開發一個集中式網關，然而這只是最終的指望。由於不一樣的外部接入網絡的特色不一樣，不一樣的服務提供商有不一樣的商業模式，存在不一樣的已有的或正在研發的網絡接口設備，它涉及許多不一樣的技術或商業問題，所以在不遠的未來是不會有一個單一的家庭網關解決方案出現。另外一方面，儘管一個分佈式或多個網關的方案也有許多支持者、製造商和服務提供商，但其同時也面臨着集成網關方案的挑戰。最終，一個整個家庭集中式網關將提供一個最有效的橋接外部網絡和家庭網絡或設備的解決方案。

1.3.3 智能家居雲服務

傳統的智能家居系統以家庭網關爲核心，全部設備均與家庭網關想鏈接，向家庭網關提供數據，並接受家庭網關的指令。如圖1.3所示。

   圖1.3 傳統的智能家居系統

採用雲計算的服務器爲核心來替代目前以家庭網關爲核心。在智能家居中引入雲計算，基本構想爲由一個儘量簡單低功耗的家庭網關來獲取各類傳感器數據傳送到雲服務器，接受來自雲服務器的指令對家居系統進行控制。此方案具有如下優點:

①  縮減並明確了家庭網關的任務，便於家庭網關的標準化和通用性; 

②  雲服務器能夠接受大量家庭系統的實時數據，在更大範圍內進行統籌安排;

 ③ 雲服務器能夠存儲大量的既往數據，便於將來在此基礎上進行數據挖掘，從而爲整個系統的優化和相關領域的發展提供知識支持。該系統的基本設想如圖1.4 所示。

圖1.4 提供雲服務的智能家居系統

雲計算提供了最可靠、最安全的數據存儲中心，用戶不用再擔憂數據丟失、病毒入侵等麻煩。其次，雲計算對用戶端的設備要求最低，使用起來也最方便。此外，雲計算能夠輕鬆實現不一樣設備間的數據與應用共享。最後，雲計算爲咱們使用網絡提供了幾乎無限多的可能。更快的部署次數，客戶端採用時間縮短;開發資源庫很是豐富;促進營收;改善分類IP服務的整體擁有成本和利潤率;下降應用程序生命週期成本。在智能家居領域，雲計算的優勢也獲得完美體現，成爲智能家居發展最強大的動力。

雲平臺（Cloud platforms）：所謂雲平臺，通常理解爲雲計算平臺，爲用戶提供雲計算服務。這種平臺容許開發者們或是將寫好的程序放在「雲」裏運行，或是使用「雲」裏提供的服務，或兩者皆是。雲平臺提供基於「雲」的服務，供開發者建立應用時採用。你沒必要構建本身的基礎，你徹底能夠依靠雲平臺來建立新的SaaS應用。雲平臺的直接用戶是開發者，而不是最終用戶。

圖1.5 雲計算架構

 

雲計算與物聯網各自具有不少優點，若是把雲計算平臺與物聯網結合起來，就構形成物聯網雲平臺。該平臺經過物聯網技術將傳感器鏈接到一塊兒，再經過雲計算的技術對數據進行分佈式存儲與處理，由此能克服大規模的數據存儲與計算問題，完善了物聯網的構成。就本課題而言，智能家居雲平臺在功能上更接近於物聯網雲平臺。智能家居雲平臺將數據存儲和處理服務置於雲端，經過相應接口提供智能家居設備的相關監控服務。

引入雲計算以後，咱們對當前智能家居的主要功能拓展爲:

( 1) 提升生活環境的安全性 智能家居經過遠程監控技術，使得人們能夠經過網絡攝像頭實時瞭解家庭狀況，方便照顧家中自理能力較弱的老人和孩子。在發現異常狀況時，能及時報警。將瓦斯傳感器等接入系統，可使系統及時採起必要的通風、報警等措施，避免事故的擴大。

 ( 2) 提升生活的溫馨性 智能家居系統經過各類溫度溼度光線傳感器，得到家居環境的實時數據，並調用空調、加溼器、電動窗簾等設備，利用負反饋的控制系統，保持家居環境始終處於令人感受最溫馨的狀態。

( 3) 提升生活的便利性 智能家居系統將各類家用設備集中控制，經過 PC、智能電視機或手機之類的手持設備，人們就能夠方便的控制全部家庭設備，而沒必要使用各類單獨的遙控器。經過接入互聯網，人們也能夠進行遠程的控制。例如在回家的路上開啓家中的空調和廚房設備。

( 4) 提升社會的綜合管理水平 智能家居系統與雲計算相結合，使得雲服務器能夠鏈接成千上萬個智能家居子系統，進行統籌控制。例如在電力緊張時，自動調整公用建築或優先級較低的建築空間的空調溫度，或者在用電谷時開啓電熱水器的加熱。

( 5) 有助於人居技術的進步 經過雲存儲，雲計算系統獲取了大量的智能家居系統的運行數據，並據此造成數據倉庫。基於大量寶貴的數據，咱們能夠在此基礎上進行數據挖掘，或者更多的統計數據，爲家電的開發、電網布局提供研究樣本，對於促進人居技術的發展具備廣闊的前景。

 

2 智能家居設計方案與相關技術簡介

2.1 需求分析

智能家居系統是安裝在家居場所中的通訊系統，經過本地監控和遠程監控兩種方式實現對家居環境的瞭解，從而實現家居設備管理和控制的智能化，實現諸如關聯控制、情景控制、語音控制等諸多服務。用戶經過 PC 或手機登陸智能家居監控系統，實時查看家居內部信息，真正實現了「人在路上，家再手中」這一目標。

①設計要求

目前 ZigBee 技術普遍的應用在 PC 外設、消費類電子產品、智能家居控制、醫療技術以及工業自動化等領域，因爲 ZigBee 無線網絡是自組織網絡，其靈活性較高，所以可將 ZigBee 技術應用到智能家居系統的內部網絡中來，經過對智能家居相關技術和用戶需求的分析，結合本論文對智能家居系統模型提出如下設計要求：

1）無線組網，採用 ZigBee 技術構建智能家居網絡，實現了家居網絡從有線到無線的轉變，並完成對傳感器節點的控制。

2）本地監控，在住宅中用戶能夠經過家居網關對智能家居系統現場監控。

3）遠程監控，在遠離住宅的任何地方，用戶能夠經過 PC 機或智能手機快速接入網絡，進而實現對智能家居系統的遠程監控。

4）下降功耗，充分利用休眠模式來延長傳感器的使用壽命，避免了頻繁更換電池的麻煩。

②主要功能

本智能家居系統擬實現的主要功能以下：

1）嵌入式系統代替 PC 機來構建智能家居網關。

2）構建人機交互界面，方便用戶對傳感器的控制以及設備狀態的查詢和修改。

3）搭建遠程服務雲平臺，用戶經過各類終端便可進行遠程實時控制查看家居環境情況，並提供諸多人性化的服務。

2.2 智能家居控制系統方案設計

物聯網系統通常分爲三層，感知層、網絡層及應用層，如圖2.1所示。

圖2.1 物聯網三層架構

感知層：主要由各類傳感器、執行器、控制終端組成，經過短距離通訊的傳感器網絡鏈接起來，主要做用是採集信息和執行控制命令。

網絡傳輸層：解決的是傳輸和預處理感知層所得到數據的問題。這些數據能夠經過移動通訊網、以太網等進行傳輸，涉及到一個很核心的設備就是網關。

應用層也可稱爲處理層：解決的是信息處理和人機界面的問題。網絡層傳輸而來的數據在這一層裏進入各種信息系統進行處理，並經過各類設備與人進行交互。

智能家居系統也屬於物聯網應用的範疇，其系統設計也能夠參考物聯網的三層架構，將基於ZigBee 芯片的無線網絡收發模塊嵌入到各類家居設備中，從而構建家居無線控制網絡。用戶可根據需求的不一樣選擇接入或移除不一樣功能的終端設備。在無線網絡構建過程當中可選擇因特網或者3G 網絡做爲數據通訊的載體。網絡中的各傳感器節點將採集到的信息發送到全功能協調器上，而後協調器經過特定的接口將信息發送給智能家居網關，隨後經過開發的人機交互界面進行顯示，另外經過 PC 或智能手機能夠實現設備控制與狀態查詢，系統整體架構圖如圖2.2所示。

 

圖2.2 智能家居系統

在感知層採用ZigBee無線網絡組網，ZigBee網絡主要由協調器、傳感器節點和控制接節點組成，實現了Zigbee網絡的組網入網、節點綁定、透明傳輸、自恢復功能等功能。

在網絡層設計了一種嵌入式智能網關，實現了ZigBee網絡與以太網的協議轉換，智能網關同時起到了局域網中心控制器的做用，能夠進行局域網內簡單控制的配置及向雲平臺上傳和下載數據。

在應用層搭建了一個提供遠程監控與控制以及各類個性化服務的雲平臺，使用HTTP協議做爲通訊協議，JSON格式做爲雲平臺響應數據格式，實現了雲平臺的基本功能和RESTful風格的API。

2.3 ZigBee網絡拓撲結構的選擇者

ZigBee 網絡層（Network Wizard Kde）支持星型、樹型和網型網絡拓撲結構，如圖2.3所示。

圖2.3 ZigBee網絡拓撲結構

①  星型拓撲結構

在星型拓撲結構中，網絡由一個單獨的 ZigBee 協調器控制，終端經過協調器的轉發實現與其它終端的通訊，這種結構的優勢是結構簡單，上層路由信息被簡化。缺點是網絡規模小，通訊距離短，全部節點都直接與協調器通訊，增長了協調器的工做負荷，當協調器出現故障時，整個網絡就會癱瘓。此外，網絡覆蓋範圍受到協調器通訊範圍的限制，超出這個範圍的終端將不能處於控制網絡中，所以星型拓撲結構只適用於小型家庭網絡的組建。

②  樹型拓撲結構

在樹型網絡結構中任何FFD均可做爲協調器，爲其它終端和協調器提供同步信息。在某個時刻，終端 RFD 只能和一個 FFD 通訊。RDF通訊時現將數據傳送給 FFD，FFD再將數據傳送到協調器。所以，在樹型網絡結構中，路由信息是由協調器和 FFD 來完成傳輸的。所以，這種類型的網絡對 FFD 的可靠性要求較高，一旦 FFD 出現故障，則其下從屬的 RFD 都會脫離網絡。

③  網型拓撲結構

網型網絡結構是樹型結構的拓展，它實現了全部具備路由功能的節點的信息互通，再也不受協調器和路由節點的限制。在某節點出現故障時，數據可經過其它路徑繼續通訊，從總體上提升了網絡的可靠性。此外，利用網型網絡結構可擴大網絡的覆蓋範圍，爲實現網絡系統的擴容預留了足夠空間。可是它的缺點也隨之凸現出來，好比，存儲空間的開銷增大，構建過程較爲複雜，系統成本較高等等。

因爲在本系統模型中用到的傳感器節點數目相對較少，所以本系統採用星型拓撲結構。它是由一個全功能協調器（FFD），若干個終端節點組建成的。FFD 經過串口與家居網關相連，終端節點被佈置在環境監測區域，採集到的數據經過無線的方式發送給 FFD，因爲 FFD 和家居網關鏈接，這時網關上顯示出當前的環境情況。

 

3 智能家居感知層ZigBee技術分析

3.1 ZigBee技術概述

   ZigBee 技術是一種具備統一技術標準的短距離無線通訊技術，其PHY層和MAC層協議爲 IEEE 802. 15.4 協議標準，網絡層由ZigBee技術聯盟制定，應用層的開發應用根據用戶本身的應用須要，對其進行開發利用，所以該技術可以爲用戶提供機動、靈活的組網方式。

    根據 IEEE 802. 15. 4 標準協議,ZigBee 的工做頻段分爲3個頻段，這3個工做頻段相距較大 ，並且在各頻段上的信道數目不一樣，於是，在該項技術標準中，各頻段上的調製方式和傳輸速率不一樣。它們分別爲 868MHz、915MHz 和 2.4GHz，其中2.4GHz 頻段上，分爲 16 個 信道，該頻段爲全球通用的工業、科學、醫學頻段，該頻段爲免付費、 免申請的無線電頻段，在該頻段上，數據傳輸速率爲250kbps；另外兩個頻段爲915 /868 MHz，其相應的信道個數分別爲10個信道和1個信道,傳輸速率分別爲40 kbps和20 kbps。

在組網性能上,ZigBee 設備可構造爲星型網絡或者多跳網格網絡，在每個ZigBee組成的無線網絡內，鏈接地址碼分爲16 bit 短地址或者64 bit長地址，具備較大的網絡容量。

    在無線通訊技術上，採用免衝突多載波信道接入(CSMA/ CA)方式，有效地避免了無線電載波之間的衝突,此外，爲保證傳輸數據的可靠性，創建了完整的應答通訊協議。

    ZigBee設備爲低功耗設備,其發射輸出爲 0~3. 6dBm，通訊距離爲30~70 m,具備能量檢測和鏈路質量指示能力，根據這些檢測結果，設備可自動調整設備的發射功率，在保證通訊鏈路質量的條件下，最小地消耗設備能量。

    爲保證ZigBee設備之間通訊數據的安全保密性，ZigBee技術採用了密鑰長度爲128位的加密算法，對所傳輸的數據信息進行加密處理。

 

3.2 ZigBee技術的體系結構

   ZigBee技術是一種可靠性高、功耗低的無線通訊技術，在ZigBee技術中，其體系結構一般由層來量化它的各個簡化標準。每一層負責完成所規定的任務，而且向上層提供服務。各層之間的接口經過所定義的邏輯鏈路來提供服務。ZigBee技術的體系結構主要由物理 (PYH) 層、媒體接入控制 （MAC)）層、網絡安全層以及應用框架層組成，其各層之間分佈如圖3.1。

 

圖3.1 ZigBee技術協議組成

    PHY層的特徵是啓動和關閉無線收發器，能量檢測，鏈路質量，信道選擇清除信道評估 (CCA) ，以及經過物理媒體對數據包進行發送和接收。

    一樣，MAC層也提供了兩種類型的服務：經過MAC管理實體服務接入點（MLME SAP）向MAC。層數據和MAC層管理提供服務。MAC層數據服務能夠經過PHY層數據服務發送和接收MAC層協議數據單元（MPDU）。

    MAC層的具體特徵是：信標管理，信道接入，時隙管理，發送確認幀，發送鏈接及斷開鏈接請求。除此以外，MAC層爲應用合適的安全機制提供一些方法。

3.3 ZigBee節點的創建

  Zigbee網絡中包含了協調器、傳感器節點和控制器節點，協調器、傳感器與控制器終端節點均選擇TI公司生產的CC2530F256做爲核心芯片，2.4GHz 的CC253x片上系統解決方案適合於普遍的應用，它們很容易的創建在基於 IEEE802.15.4 標準協議（用於 Zigbee 兼容解決方案的 Z-Stack 軟件）上面。CC2530 集成了業界領先的RF收發器、加強工業標準的 8051MCU，系統可編程256KBFlash存儲器，8KB RAM和許多其餘強大功能。圖2.1顯示了CC2530的系統框圖，結合德州儀器業界領先和Zigbee 聯盟最高業內水平的Zigbee協議棧（Z-Stack），CC2530F256提供了一個強大完整的Zigbee解決方案。

圖3.2 ZigBee節點模塊圖

3.4ZigBee通訊網絡的創建

3.4.1 網絡層概況及網絡的造成

ZigBee網絡層的主要功能就是提供一些必要的函數，確保ZigBee的MAC層正常工做，而且爲應用層提供合適的服務接口。爲了嚮應用層提供其接口，網絡層提供了兩個必要的功能服務實體，它們分別爲數據服務實體和管理服務實體。

    1.網絡層數據實體

    網絡層數據實體爲數據提供服務，在兩個或者更多的設備之間傳送數據時，將按照應用協議數據單元(APDU) 的格式進行傳送，而且這些設備必須在同一個網絡中，即在同一個內部個域網中。

    網絡層數據實體提供以下服務：

    ① 生成網絡層協議數據單元（NPDU），網絡層數據實體經過增長一個適當的協議頭，從應用支持層協議數據單元中生成網絡層的協議數據單元。

    ② 指定拓撲傳輸路由，網絡層數據實體可以發送一個網絡層的協議數據單元到一個合適的設備，該設備多是最終目的通訊設備，也多是在通訊鏈路中的一箇中間通訊設備。

    2. 網絡層管理實體

    網絡層管理實體提供網絡管理服務,容許應用與堆棧相互做用。網絡層管理實體應該提供以下服務：

    ① 配置一個新的設備。爲保證設備正常工做的須要，設備應具備足夠堆棧，以知足配置的須要。配置選項包括對一個ZlgBee協調器和鏈接一個現有網絡設備的初始化操做。

    ② 初始化一個網絡，使之具備創建一個新網絡的能力。

    ③ 鏈接和斷開網絡。具備鏈接或者斷開一個網絡 的能力，以及爲創建一個ZigBee協調器或者ZigBee路由器，具備要求設備同網絡斷開的能力。

    ④ 尋址。ZigBee協調器和ZigBee路由器具備爲新加入網絡的設備分配地址的能力。

    ⑤ 鄰居設備發現。具備發現、記錄和彙報有關一跳鄰居設備信息的能力。

    ⑥ 路由發現。具備發現和記錄有效地傳送信息的網絡路由的能力。

⑦ 接收控制。具備控制設備接收機接收狀態的能力， 即控制接收機什麼時間接收、接收時間的長短，以保證MAC 層的同步或者正常接收等。

  設備經過 NIME NETWORK FORMATION.request 原語來啓動一個新的網絡的創建過程。僅僅當具備ZigBee協調器能力，且當前尚未與網絡鏈接的設備才能夠嘗試着去創建一個新的網絡。若是該過程由其餘的設備開始，則網絡層管理實體將終止此過程，並向其上層發出非法請求的報告。

    當建網過程開始後，網絡層將首先請求MAC層對協議所規定的信道，或由物理層所默認的有效信道進行能量檢測掃描，以檢測可能的干擾。爲了決定用於創建一個新網絡的最佳通道，網絡層管理實體將檢查 PAN 描述符，而且所查找的第一個信道爲網絡的最小編號。若是網絡層管理實體找不到適合的通道，就將終止建網過程，而且嚮應用層發出啓動失敗信息。若是網絡層管理實體找到了適合的通道，則將爲這個新網絡選擇一個PAN標識符。

網絡創建的過程以下圖所示：

圖3.3 網絡構建信息流圖

 

3.4.2 網絡的鏈接與斷開

（1）網絡的鏈接

    在一個網絡中具備從屬關係的設備容許一個新設備鏈接時，它就與新鏈接的設備造成了一個父子關係。新設備成爲子設備，而第一個設備爲父設備。一個子設備經過如下兩個途徑加入到網絡中：

l  子設備用 MAC. 層鏈接程序來加入網絡；

l  子設備直接同一個預先所指定的父設備鏈接來加入網絡。

在這兩個途徑中而又各有下面三種鏈接方式：

l  經過聯合方式請求鏈接網絡；

l  直接請求鏈接網絡；

l  若是成爲孤點設備,請求從新鏈接網絡。

（2）網絡的斷開

    本小節將介紹兩種基於MAC層的斷開網絡流程，將子設備與網絡斷開鏈接的方法，即子設備向父設備發出斷開請求和父設備向子設備發出斷開請求的方法。

    當ZlgBee協調器或路由器接收到子設備斷開鏈接請求後，其 MAC 層將向網絡層發送MLME DISASSOCIATE, indication 原語，開始執行父設備的斷開鏈接流程。僅僅只有ZigBee協調器或者路由器才能夠執行該流程。若是其餘的設備執行該流程， 則設備的網絡層管理實體將終止該流程的執行。

當開始執行該流程後，父設備的網絡層管理實體將首先肯定在網絡中是否存在這個設備，即搜索它的鄰居表,肯定是否存在相匹配的64位擴展地址。若是搜索不到相匹配的64位擴展地址，則將終止該流程執行。若是搜索到相匹配的64位擴展地址，網絡層管理實體將從它的鄰居表中刪除該對應入口，而且嚮應用層發送NLME LEAVE，indication原語, 表示設備斷開鏈接。

3.4.3 網絡地址的分配機制

在ZigBee網絡層中，採用分佈式地址分配方案來分配網絡地址，即該方案爲每個父設備分配一個有限的網絡地址段。這些地址在一個特殊的網絡中是惟一的，而且由父設備分配給它的子設備。ZlgBee協調器決定在其網絡內容許鏈接的子設備的最大個數。對於這些子設備，參數nwkMaxRouters爲路由器最大個數，而剩下的設備數爲終端設備數。每個設備具備一個鏈接深度，即鏈接深度表示僅僅採用父子關係的網絡中，一個傳送幀傳送到ZigBee 協調器所傳遞的最小跳數。ZlgBee協調器自身深度爲0，而它的子設備深度爲1。對應多跳網絡，其深度大於1。ZlgBee協調器決定網絡的最大深度。

    假定父設備擁有子設備數量的最大值爲nwkMaxChildren (Cm)，網絡的最大深度爲nwkMaxDepth (Lm)，父設備將路由器做爲它的子設備的最大數爲nwkMaxRouters(Rm)，則可計算偏移函數Cskip(d) ，該函數爲在給定網絡深度和路由器以及子設備個數的條件下，父設備所能分配子區段地址數爲

（3.1）

    若是一個設備的Cskip(d)值爲0，則它沒有接收子設備鏈接的能力，而且將這樣的設備看做爲一個ZigBee網絡的終端設備。

    若是父設備的Cskip(d)值大於 0，則能夠接受子設備，而且將根據子設備是否具備路由器能力來向子設備分配不一樣的地址。

    利用 Cskip (d)做爲偏移，向具備路由器能力的子設備分配網絡地址.父設備爲它的第一個路由器子設備分配一個比它本身更大的地址，隨後所分配給路由器子設備的地址將以Cskip(d) 爲間隔,依此類推爲全部的路 由器分配地址。

第n個終端設備的網絡地址將按照以下公式進行分配：

（3.2）

其中 ，Aparent 爲父設備地址。

    下圖給出了一個具備最大子設備數Cm爲4, 最大路由器數Rm爲4，網絡最大深度 Lm爲 4 的ZigBee網絡，則利用上述公式計算出的Cskip(d)值如表所列。

圖3.4 網絡地址分配圖 

表3.1 深度與對應偏移值

 

因爲在設備之間不能共享一個地址段，所以，當第二層的父設備所具備的地址不用時，則第一層的父設備有可能用盡它的全部地址一個不具有可用地址的父設備將不容許新設備加入該網絡。在這種狀況下，新設備將尋找另外一個父設備。若是在其傳輸範圍內設備找不到有效的父設備，則該設備將不能加入該網絡，除非物理移動它或者網絡有一些其餘的變化。

3.5 ZigBee個域網中的通訊功能

3.5.1 幀結構

在通訊理論中，一種好的幀結構就是在保證其結構複雜性最小的同時，須要在噪聲信道中具備很強的抗干擾能力。在ZigBee技術中，每個協議層都增長了各自的幀頭和幀尾，在PAN網絡結構中定義了4種幀結構：

l  信標幀——主協調器用來發送信標的幀；

l  數據幀——用於全部數據傳輸的幀；

l  確認幀——用於確認成功接收的幀；

l  MAC 層命令幀——用於處理全部 MAC 層對等實體間的控制傳輸。

下圖給出了四種幀結構的在MAC層和物理層上的描述。

圖3.5 幀結構圖

如圖中所示，其中三種幀的結構很是類似，分別爲信標幀、數據幀、命令幀，相同之處在於MAC層幀頭和幀尾，即MHR和MFR，MHR中分別包含幀控制、序列碼和尋址，MFR均是16位的FCS，不一樣的是三者的MAC層數據單元載荷（MSDC）不一樣，信標幀相對複雜，包含超幀、GTS、未處理的事務地址以及信標載荷四部分，數據幀只有數據載荷一部分，而命令幀包含命令類型和命令數據，三者的MSDC加上MHR及MFR以後合成爲MPDU發到物理層，而確認幀的MPDU沒有MSDC只有幀控制、序列碼和FCS，這樣四種幀的MPDU在物理層（PHY）添加上同步幀頭（SHR）和物理層幀頭（PHR）和物理層幀尾就能夠組成物理層包（PPDU），其中SHR包含前同步碼和定界符，PHR爲幀的長度。

3.5.2 數據傳輸事務

ZigBee 技術的數據傳輸模式分爲3種數據傳輸事務類型：

l  從設備向主協調器送數據

l  主協調器發送數據，從設備接收數據

l  在兩個從設備之間傳送數據

    對於星型拓撲結構的網絡來講，因爲該網絡結構只容許在主協調器和從設備之間交換數所以，只有兩種數據傳輸事務類型。而在對等拓撲結構中，容許網絡中任何兩個從設備之間進行交換數據，所以，在該結構中，可能包含這3種數據傳輸事務類型。

1. 數據傳送到主協調器

    這種數據傳輸事務類型是由從設備向主協調器傳送數據的機制。

    當從設備但願在信標網絡中發送數據給主設備時，首先，從設備要監聽網絡的信標,當監聽到信標後，從設備須要與超幀結構進行同步，在適當的時候，從設備將使用有隙的CSMA CA向主協調器發送數據幀， 當主協調器接收到該數據幀後，將返回一個表數據已成功接收的確認幀，以此代表已經執行完成該數據傳輸事務，圖 2.4 描述了該數傳輸事務執行的順序。

2. 主協調器發送數據

    這種數據傳輸事務是由主協調器向從設備傳送數據的機制。

當主協調器須要在信標網絡中發送數據給從設備時，它會在網絡信標中代表存在有要傳輸的數據信息，此時，從設備處於週期地監聽網絡信標狀態，當從設備發現存在有主協調器要發送給它的數據信息時，將採用有時隙的CSMA CA機制，經過MAC層指令發送一個數據請求命令。主協調器收到數據請求命令後，返回一個確認幀,並採用有時隙的CSMA CA 機制， 發送要傳輸的數據信息幀。從設備收到該數據幀後，將返回一個確認幀，表示該數據傳輸事務巳處理完成。主協調器收到確認幀後，將該數據信息從主協調器的信標未處理信息列表中刪除。圖2.4描述了該數據傳輸事務的執行順序。

 

圖3.6數據傳輸事務的執行順序

3.5.3 安全性

   在無線通訊網絡中，設備與設備之間的通訊數據的安全保密性是十分重要的，在ZigBee技術中，在MAC層採起了一些重要的安全措施，以保證通訊最基本的安全性，經過這些安全措施，爲全部設備之間的通訊提供最基本的安全服務，這些最基本的安全措施用來對設備接入控制列表(ACL)進行維護，並採用相應的密鑰對發送數據進行加解密處理，以保護數據信息的安全傳輸。

    雖然MAC層提供了安全保護措施，但實際上，MAC層是否採用安全性措施由上層來決定， 並由上層爲MAC層提供該安全措施所必須的關鍵資料信息。此外，對密鑰的管理、設備的鑑別以及對數據的保護、更新等都必須由上層來執行。在本小節中， 簡要介紹了一些 ZigBee 技術安全方面的知識。

    1.安全性模式

    在ZigBee技術中，能夠根據實際的應用狀況，即根據設備的工做模式以及是否選擇安全措施等狀況，由MAC層爲設備提供不一樣的安全服務。

    (1) 非安全模式

    在三ZigBee技術中，能夠根據應用的實際須要對傳輸的數據是否採起安全保護措施，顯然，若是選擇設備工做模式爲非安全模式,則設備不能提供安全性服務，對傳輸的數據無安全保護。

    (2) ACL 模式

    在 ACL 模式下，設備可以爲同其餘設備之間的通訊提供有限的安全服務。在這種模式下,經過MAC層判斷所接收到的幀是否來自於所指定的設備，如不是來自於指定的設備，上層都將拒絕所接收到的幀。在這種模式下，MAC層對數據信息不提供密碼保護，須要上層執行其餘機制來肯定發送設備的身份。在ACL模式中，所提供的安全服務即爲前面所介紹的接入控制。

    (3) 安全模式

    在安全模式條件下，設備可以提供前面所述的任何一種安全服務。具體的安全服務取決於所使用的一組安全措施，而且，這些服務由該組安全措施來指定。在安全模式下，可提供的安全服務以下所示：

 

• 接入控制
• 數據加密
• 幀的完整性
• 有序刷新

 

    2. 安全服務

    在ZigBee技術中，米用對稱密鑰的安全機制，密鑰由網絡層和應用層根據實際應用須要生成，並對其進行管理、存儲、傳送和更新等。密鑰主要提供以下幾種安全服務。

    (1) 接入制

    接入控制是一種安全服務，爲一個設備提供選擇同其餘設備進行通訊的能力。在網絡設備中， 如採用接入控制服務，則每個設備將創建一個接入控制列表，並對該列表進行維護，列表中的設備爲該設備但願通訊鏈接的設備。

    (2) 數據加密

    在通訊網絡中，對數據進行加密處理，以安全地保護所傳輸數據，在ZlgBee技術中，採用對稱密鑰的方法來保護數據，顯然，沒有密鑰的設備不能正確地解密數據從而達到了保護數據安全的目的。數據加密多是一組設備共用一個密鑰（一般做爲默認密鑰存儲）或者兩個對等設備共用一個密鑰（通常存儲在每一個設備的ACL實體中）。數據加密一般爲對信標載荷、命令載荷或數據載荷進行加密處理，以確保傳輸數據的安全性。

    (3) 幀的完整性

在ZigBee技術中，採用了一種稱爲幀的完整性的安全服務，所謂幀的完整性是利用一個信息完整代碼 (MIC) 來保護數據，該代碼用來保護數據免於沒有密鑰的設備對傳輸數據信息的修改，從而，進一步保證了數據的安全性。幀的完整性由數據幀、信標幀和命令幀的信息組成。保證幀完整性的關鍵在於一組設備共用保護密鑰（通常默認密鑰存儲狀態）或者兩個對等設備共用保護密鑰（通常存儲在每一個設備的ACL實體中）。

    (4) 有序刷新

    有序刷新技術是一種安全服務，該技術採用一種規定的接收幀順序對幀進行處理。當接收到一個幀信息後，獲得一個新的刷新值，將該值與前一個刷新值進行比較，若是新的刷新值更新，則檢驗正確，並將前一個刷新值刷新成該值。若是新的刷新值比前一個刷新值更舊，則檢驗失敗。這種服務可以保證設備接收的數據信息是新的數據信息，可是沒有規定一個嚴格的判斷時間，即對接收數據多長時間進行刷新，須要根據在實際應用中的狀況來進行選擇。

 

4. 智能家居網關的設計

4.1 智能家居服務網關概述

隨着物聯網技術的飛速發展，將傳統的Internet與新型的無線傳感器網絡整合的趨勢愈來愈明顯，嵌入式服務網關既是無線傳感器網絡的協調器網關，又是遠程WEB 的服務器，它實現兩個不一樣協議的網絡之間的通訊。同時也是將無線傳感器網絡接入Internet，從而實現物聯網概念的關鍵設備。物聯網服務網關在將來的物聯網時代將會扮演很是重要的角色，它將成爲鏈接物聯網感知層網絡與傳統通訊網絡的紐帶。物聯網網關可實現感知網絡和基礎網絡以及不一樣類型的感知網絡之間的協議轉換，既能夠實現廣域互聯，也能夠實現局域互聯。而且具備普遍的感知網接入、通訊協議轉換和強大的系統管理等特色[1]。利用嵌入式系統設計的服務網關能夠有效下降成本，利用家庭智能化的普及。

智能家居系統的網關，至關於遠程服務器，網關模塊是整個智能家居控制系統的核心模塊，它不只具備數據信息彙總功能，同時又具備數據分析處理的能力，經過對採集到的數據進行集中式分析實現對家庭智能化設備的統一管理。網關不只是數據彙總的模塊，同時也是家庭內部網和外部網絡，如Internet，GRPS，手機等外部網絡進行數據交互的橋樑。[3]家居網關做爲智能家居控制系統不可缺乏的一部分，嵌入式GUI軟件能夠爲用戶提供清晰直觀的家居使用狀況，並方便用戶輕鬆控制各個家電。隨着嵌入式系統的技術日趨成熟，發展速度愈來愈迅速，將其用於網關服務器上，是監控系統將來發展的方向之一。目前智能家居的主流技術也是嵌入式，在 TCP/IP協議和WWW規範的支持下，合理組織軟硬件結構，使客戶端經過訪問網關服務器來及時獲取本身權限下的全部數據並作出響應。所以，本系統的網關採用嵌入式技術。

本家居網關旨在設計一個智能家居節點的統一訪問接口，使用戶可以在該網關上很方便的看到家居節點的各類信息並進行控制，更爲重要的是，該網管對上層提供GPRS及/或3G接口，使用戶可以經過移動終端設備（如手機、平板電腦）等隨時隨地訪問家居節點進行查看和控制，包括基礎控制和視頻監控等等。

4.2 網關整體結構設計

ZigBee網絡所涉及的網關, 按軟硬件平臺可分爲兩部分: 運行在ZigBee無線模塊中的ZigBee協議棧程序和運行在主處理器STM32中的嵌入式以太網服務器程序. 本文討論了ZigBee網絡和以太網兩類網絡鏈接問題, 兩個不一樣的網絡使用兩類協議: TCP /I P 協議和ZigBee協議. 相應的網關結構見圖4.1,ZigBee無線傳 感器網絡有三種經常使用拓撲結構:星狀、 串狀和網狀. 每一個ZigBee網絡中都必須有一個協調器節點, 至關於局域網中的服務器. 協調器節點做爲整個無線網絡的傳輸與控制中心, 具備對本無線網絡的管理能力. 另外, 做爲物聯網的網絡傳輸基礎, 網絡中還須要有若干路由器節點和傳感器採集節點。星狀方式鏈接比較簡單, 能組建較少節點的無線網絡, 各個傳感器節點經過位於中心的協調 器節點實現網絡鏈接; 網狀方式中, 任意兩個節點之間均可以發送信息; 串狀方式中增長了路由器節點, 用於對數據進行多跳方式的轉發考慮到系統的簡便實用性, 本文采用星狀的鏈接方式, 協調器節點模塊與嵌入式以太網服務器整合在一塊兒構成網關。

                     圖4.1 網關結構

本文設計的網關是創建在應用層上的協議轉換器, 鏈接ZigBee和以太網兩個相對獨立的網絡, 其無線傳感器網關協議轉換模型如圖4.2所示. 傳感器節點採集到的數據按照ZigBee協議傳送到網關, 網關上的ZigBee協調器節點負責解析出數據的有效載荷, 交由STM32處理器控制以太網卡芯片負責將數據發送到雲平臺上。

圖4.2 網關協議轉換模型

4.3 網關軟硬件設計

4.3.1 網關硬件設計

服務網關硬件框圖如圖4.3所示。由ARM 主控制器、Zigbee 模塊、以太網PHY、TFT-LCD 液晶觸摸屏、及最小系統模塊5 部分組成。

 

圖 4.3 服務網關硬件框

 

  主控制器採用基於ARM(Cotex-M3) 核的STM32F107 互聯型微控制器。它擁有64K SRAM、256K FLASH、以太網MAC 等豐富的存儲器及外設資源。Zigbee 模塊是由TI 公司的CC2430做爲主控芯片，在服務網關中它是WSN 的協調器，經過USART 實現與主控制器之間的數據通訊。以太網模塊採用以太網的物理層芯片DM9161A，經過RMII與主控制器相鏈接，其50M 時鐘由ARM 的MCO提供。液晶觸摸屏經過I/O 接口與ARM 相連，實現人機對話。

圖4.4 STM32系列對比

4.3.2 網關軟件設計

系統軟件分爲運行於ARM 上的服務網關軟件和運行於CC2530 模塊上的WSN 網關軟件。考慮到服務網關軟件的整體設計的複雜程度以及層次性模塊化的設計理念，系統採用嵌入式操做系統uCOS-II 做爲系統資源的管理，對系統功能任務化。服務網關軟件整體設計框圖如圖4.5 所示。

圖4.5 服務網關軟件整體設計框

 

服務網關軟件層次結構分爲：底層驅動層，系統層，應用層。
（1）底層驅動層
底層驅動層包括FWLib 和BSP。FWLib 是ST公司爲了對其ARM 的支持而推出的驅動支持軟件，提供系統初始化函數，對中斷和操做系統的支持，存儲器分配以及全部片內外設的驅動，從而方便軟件的開發。此外，用戶還應開發針對應用的板級支持包(BSP)，在本系統中BSP 的內容主要是應用開發板相關的硬件驅動。

（2）系統層

系統層包括了操做系統和中間件軟件LwIP，操做系統是對軟硬件資源的管理，其餘各部分軟件都要以操做系統爲中心。操做系統移植的過程當中，主要任務是改寫針對處理器和編譯器相關的部分，向上爲應用任務提供支持，向下鏈接驅動程序來實現對硬件的操做。LwIP 是一個針對嵌入式系統的TCP/IP 協議棧，本程序包含其基本功能：TCP、IP、UDP、ICMP。LwIP 的操做系統模擬層提供了向操做系統移植的方便，因其包括了任務間通訊的機制：信號量、消息郵箱。
（3）應用層

本設計根據模塊化和功能獨立性原則，將全部的應用程序分紅7 個應用任務，分別是引領全局的根任務，與輸入輸出有關的按鍵任務和LCD 顯示任務，與嵌入式WEB 相關的TCP發送任務和TCP 超時重傳任務，與WSN 協調器相關的串口數據發送任務和Zigbee 控制命令任務。

4.4 ZigBee協調器軟件設計

本文采用了TI公司免費提供的Z-S tack ZigBee協議棧做爲CC253 0的開發平臺,大大簡化了應用程序的開發過程STM32 處理器由一個輪詢式操做系統管理, 基於任務調度機制把 CC2530內部的每個操做都當作一個事件處理，根據任務和事件的標識號來調用某一個事件處理函數。 ZigBee協調器和 STM32處理器用串口鏈接, 因此在 Z - Stack的基礎上須要修改串口通訊的事件。

4.4.1 協調器接收無線數據

當有傳感器節點數據經過無線發送到協調器時，協調器的應用層會產生一 個AF _INCOMI NG _MSG _ CMD 事件。

CaseAF _ INCOMING_MSG_CMD :

{ 

App_ MessageMSGCB(MSGpkt) ;

break ; 

}

該事件處理函數表示有AF_INCOMING_MSG_CMD 事件發生後將調用事件處理函數 App _MessageMSGCB(MSGpkt) , 開始接收數據, 而後經過串口發送函數 HalUARTWrite ( ) 將數據發給STM32的串口。

4.4.2 協調器發送數據到傳感器節點

當主處理器STM32有控制信息經過串口傳輸給ZigBee協調器時, 協調器的應用層會產生1個APP _SEND _ MSG _ EVT 事件。

if ( even & tAPP _SEND _ MSG _ EVT )

{ 

A pp _Send Th eMessage( ) ;

}

協調器將調用App _SendTheMessage( ) 函數將控制信息發送到相應的無線傳感器節點中。

4.4.3 協調器的工做流程

ZigBee網絡協調器做爲整個ZigBee網絡的中心, 負責網絡的的創建, 信息的接收、彙總及控制指令的發送。協調器上電初始化後啓動程序, 經過調用

函數 aplFro mN et w or k ( ) 建立一個網絡, 選定一個PANID做爲協調器的網絡標識, 建立路由表, 而後對外發布廣播幀, 通知傳感器節點能夠加入該網絡Zig Bee協調器的工做流程見圖 4.6 。

圖 4.6   ZigBee協調器的工做流程

4.5 網關的通訊設計

4.5.1 LwIP簡介

LwIP是Light Weight (輕型)IP協議，有無操做系統的支持均可以運行。LwIP實現的重點是在保持TCP協議主要功能的基礎上減小對RAM 的佔用，它只需十幾KB的RAM和40K左右的ROM就能夠運行，這使LwIP協議棧適合在低端的嵌入式系統中使用。

LwIP協議棧主要關注的是怎麼樣減小內存的使用和代碼的大小，這樣就可讓LwIP適用於資源有限的小型平臺例如嵌入式系統。爲了簡化處理過程和內存要求，LwIP對API進行了裁減，能夠不須要複製一些數據。

Lwip提供三種API：1)RAW API 2)lwip API 3)BSD API。

RAW API把協議棧和應用程序放到一個進程裏邊，該接口基於函數回調技術，使用該接口的應用程序能夠不用進行連續操做。不過，這會使應用程序編寫難度加大且代 碼不易被理解。爲了接收數據，應用程序會向協議棧註冊一個回調函數。該回調函數與特定的鏈接相關聯，當該關聯的鏈接到達一個信息包，該回調函數就會被協議棧調用。這既有優勢也有缺點。優勢是既然應用程序和TCP/IP協議棧駐留在同一個進程中，那麼發送和接收數據就再也不產生進程切換。主要缺點是應用程序不能使本身陷入長期的連續運算中，這樣會致使通信性能降低，緣由是TCP/IP處理與連續運算是不能並行發生的。這個缺點能夠經過把應用程序分爲兩部分來克服，一部分處理通信，一部分處理運算。

Lwip API把接收與處理放在一個線程裏面。這樣只要處理流程稍微被延遲，接收就會被阻塞，直接形成頻繁丟包、響應不及時等嚴重問題。所以，接收與協議處理必須分開。LwIP的做者顯然已經考慮到了這一點，他爲咱們提供了tcpip_input() 函數來處理這個問題， 雖然他並無在 rawapi 一文中說明。 講到這裏，讀者應該知道tcpip_input()函數投遞的消息從哪裏來的答案了吧，沒錯，它們來自於由底層網絡驅動組成的接收線程。咱們在編寫網絡驅動時，其接收部分以任務的形式建立。 數據包到達後， 去掉以太網包頭獲得IP包， 而後直接調用tcpip_input()函數將其 投遞到mbox郵箱。投遞結束，接收任務繼續下一個數據包的接收，而被投遞得IP包將由TCPIP線程繼續處理。這樣，即便某個IP包的處理時間過長也不 會形成頻繁丟包現象的發生。這就是lwip API。

BSD API提供了基於open-read-write-close模型的UNIX標準API，它的最大特色是使應用程序移植到其它系統時比較容易，但用在嵌入式系統中效率比較低，佔用資源多。這對於咱們的嵌入式應用有時是不能容忍的。

LwIP的特性以下：

(1) 支持多網絡接口下的IP轉發

(2) 支持ICMP協議 

(3) 包括實驗性擴展的的UDP（用戶數據報協議）

(4) 包括阻塞控制，RTT估算和快速恢復和快速轉發的TCP

(5) 提供專門的內部回調接口（Raw API）用於提升應用程序性能

(6) 可選擇的Berkeley接口API（多線程狀況下）

(7) 在最新的版本中支持ppp

(8) 新版本中增長了的IP fragment的支持.

(9) 支持DHCP協議,動態分配ip地址。

爲了移植到μC/OS系統中，須要進行如下調整。

(1) 信號量

LwIP中須要使用信號量進行通訊，因此在sys_arch中應實現相應的信號量結構體struct sys_semt和處理函數sys_sem_new() 、sys_sem_free() 、sys_sem_signal ( ) 和sys_arch_sem_wait ( ) 。因爲μC/OS已經實現了信號量OSEVENT的各類操做，而且功能和LwIP上面幾個函數的目的功能是徹底同樣的，因此只要把μC/OS的函數從新包裝成上面的函數，就可直接使用。

(2) 消息隊列

LwIP 使用消息隊列來緩衝、傳遞數據報文，所以要實現消息隊列結構sys_mbox_t ，以及相應的操做函數：sys_mbox_new() 、sys_mbox_free () 、sys_mbox _post () 和sys_arch_mbox_fetch() 。μC/OS實現了消息隊列結構及其操做，可是μC/OS沒有對消息隊列中的消息進行管理，所以不能直接使用，必須在μC/OS的基礎上從新實現。具體實現時，對隊列自己的管理利用μC/OS本身的OSQ操做完成，而後使用μC/OS中的內存管理模塊實現對消息的建立、使用、刪除和回收，兩部分綜合起來造成了LwIP的消息隊列功能。

(3) 定時器函數

LwIP中每一個和TCP/IP相關的任務的一系列定時事件組成一個單向鏈表，每一個鏈表的起始指針存在lwip_timeouts 的對應表項中，如圖2所示。移植時須要實現struct sys_timeouts *sys_arch_timeouts (void) 函數，該函數返回正處於運行態的線程所對應的timeout 隊列指針。

(4) 建立新線程函數

在μC/OS 中，沒有線程(thread) 的概念，只有任務(Task) 。它提供了建立新任務的系統API調用OSTaskCreate，所以只要把OSTaskCreate封裝一下，就能夠實現sys_thread_new。須要注意的是LwIP中的thread並無μC/OS中優先級的概念，實現時要由用戶事先爲LwIP中建立的線程分配好優先級。

4.5.2 本地局域網通訊

在本地局域網中，網關起到中心控制器的做用，爲客戶端提供服務，所以至關於一個服務器，基於LwIP，能夠很容易搭建一個簡單的服務器，如圖4.7所示。

圖4.7 網關局域網通訊

服務器部分代碼以下所示

/*********************************************************************

　　***功能簡介：做爲服務器端創建一個監聽,等待鏈接

　　***    參數：3

               param1：structtcp_pcb *pcb，TCP鏈接控制塊

                                    param2：u16 port ，本地端口號

                                    param3：err_socket (*server_accepted)(void *arg, struct tcp_pcb *tpcb, err_socket err)，有鏈接到來時

                                                                      執行的回調函數

　　****   說明： 調用該API的應用程序應該本身定義並實現回調函數,在回調函數中進行相關數據收發處理

　***********************************************************************/

 

voidServer_Socket( struct tcp_pcb *pcb, u16 port, 

                                                        err_socket(* server_accepted)(void *arg, struct tcp_pcb *tpcb, err_socket err))

{

 

   pcb =tcp_new();

  tcp_bind(pcb, IP_ADDR_ANY, port);

   pcb =tcp_listen(pcb);

  tcp_accept(pcb, server_accepted);   

}

4.5.3 遠程通訊

相對於雲平臺，網關充當一個客戶端的角色，一方面上傳數據到雲平臺，另外一方面從雲平臺服務器下載或接受推送的數據。

圖4.8 網關遠程通訊

使用LwIP構建客戶端的部分代碼以下所示

/*********************************************************************

　　***功能簡介：做爲客戶端與指定了ip地址的服務器的對應端口創建一個鏈接

　　***    參數：

               param1：structtcp_pcb *pcb，TCP鏈接控制塊

                                    param2：struct ip_addr *ip_remote, 服務器IP地址

                                    param3：u16 port ，本地端口號

                                    param4：u16 remote_port ，服務器端口號

                                    param5：err_t (* client_connected)(void*arg, struct tcp_pcb *tpcb, err_t err)，鏈接服務器成功時

                                                                      執行的回調函數

　　****   說明： 調用該API的應用程序應該本身定義並實現回調函數,在回調函數中進行相關數據收發處理

　***********************************************************************/

voidClient_Socket( struct tcp_pcb *pcb,struct ip_addr *ip_remote, u16 port, u16remote_port,

                                                               err_socket(* client_connected)(void *arg, struct tcp_pcb *tpcb, err_t err))

{

       

   pcb =tcp_new();

 tcp_bind(pcb, IP_ADDR_ANY, port);

 tcp_connect(pcb,ip_remote,remote_port,client_connected);                                                                     

}

 

 

5 智能家居雲平臺設計

5.1 智能家居雲平臺概述及發展示狀

智能家居發展到如今，用戶再也不知足於「家庭小網」的簡單體驗，傳統的智能家居雖然具有必定的系統性，提供了諸多應用，但沒有突出與物聯網技術的融合，雲技術的運用愈來愈普遍，開始深刻地影響咱們生活的方方面面，雲計算在智能家居領域的應用，已經打破了空間及時間上的限制，造成了一個統一的大系統，爲個性化的需求提供了豐富的產品和體驗。應用雲技術的家居系統成爲物聯網中崛起的新生力量，並迅速成爲智能家居系統中不可或缺的一部分。

圖5.1 智能家居雲平臺示意圖

當前的智能家居就是以住宅爲平臺，集網絡通訊、網絡系統和自動化控制於一體，經過互聯網技術將家庭設備聯繫成家庭網絡，實現遠程操控，爲人們提供了溫馨安全高效和便利的生活居住環境。

面對當下智能家居互聯互通的新趨勢，雲平臺做爲信息儲存傳輸的紐帶，扮演着重要角色。雲是物聯網的基礎，而統一的雲平臺可兼容各類先進技術，以知足客戶需求爲主，不受品牌的約束，集結各路優秀方案，在最短的時間內，使用戶獲得極致的體驗。智能家居做爲物聯網的重要分支，智能家居的雲平臺也是物聯網雲平臺的重要應用。

現今較成熟的物聯網雲平臺有「Yeelink雲平臺」、「京東智能雲」和「Ninja Platform」等。這些雲平臺將API公開給開發者，爲開發者提供數據處理和存儲服務。而開發者經過給定的API，用相應的方法將本身的設備信息傳遞到雲端進行處理，實現對設備的監控。

其中Ninja Platform以其自身的產品Ninja Block（智能家居網關）爲核心，將智能家居設備經過Ninja Block組成一個統一的總體，再鏈接到Ninja Platform實現遠程監控。Ninja Platform只支持本身的網關產品的接入，而且隱藏了網關與平臺鏈接的細節，只是簡單地提供一個接口用於鏈接。由於只支持本身的網關產品的接入，能夠實現不少複雜的控制細節，而且這些徹底由自身控制。所以，Ninja Platform在功能上顯得十分豐富，邏輯也十分合理，安全性也作的很好，更接近於一個完善的商業產品。而其開放API的意義在於，使用Ninja Block的用戶能夠經過使用這些API進行本身的控制終端的開發，用於實現一些本身但願的功能和擴展。

相比Ninja Platform，國內的Yeelink雲平臺的功能顯得有些簡陋。但Yeelink雲平臺的特色仍是很明顯的：他是一個幾乎徹底開放的物聯網雲平臺。雖然Yeelink雲平臺也有本身的設備提供，但它也支持其它設備的接入，這些接入的設備也不限制於家居網關。全部可以實現HTTP請求方法的設備，甚至一個實現HTTP請求的程序，均可以鏈接到Yeelink雲平臺，做爲被控對象。Yeelink雲平臺的API顯得更加抽象，全部具體的功能都抽象成對數據的操做。

雲計算與物聯網各自具有不少優點，若是把雲計算平臺與物聯網結合起來，就構形成物聯網雲平臺。該平臺經過物聯網技術將傳感器鏈接到一塊兒，再經過雲計算的技術對數據進行分佈式存儲與處理，由此能克服大規模的數據存儲與計算問題，完善了物聯網的構成。就本課題而言，智能家居雲平臺在功能上更接近於物聯網雲平臺。智能家居雲平臺將數據存儲和處理服務置於雲端，經過相應接口提供智能家居設備的相關監控服務。

經過智能家居雲平臺解決了傳統智能家居存在的如下問題：

（1）傳統智能家居的各子系統之間基本上是「信息」孤島，因爲沒有開放的協議、統一的接口和數據庫，使得技術協調和系統整合都比較困難，因此各子系統之間尚未實現互聯、互通和互操做，也難以實現真正智能化。 

（2）當前智能家居的各子系統，從自動化的角度來說，更多的是執行器。執行器的智能化執行，必須依靠對家庭的全面感知。感知設備的缺少嚴重影響了智能家居的智能化程度的提高，且自動執行的大可能是簡單的感知動做，缺少對感知數據的進一步分析和人工智能的推理計算，從而就不能提供更多的服務。 

（3）用戶在後期要增長新的子系統，且設備需從新進行佈線施工和調試系統，擴展性低，且用戶運行多個不一樣的軟件，系統的聯動及關聯操做需在每一個系統重複設置，使用極不方便。

（4）傳統智能家居未真正實現家居的遠程監控與控制，也未給用戶提供多元化可定製的服務。且傳統智能家居將數據存儲和處理置於智能家居網關或控制中心內，毫無疑問將加大智能家居設備的成本，也加大了開發難度，不利於商業推廣。而創建雲平臺以後，能夠將功能集中，方便系統開發與服務升級。只要保證雲平臺基本API不變，雲平臺內部的功能能夠很方便的進行開發和升級。而對於嵌入式設備（智能家居網關等），一旦生產出來，因爲硬件方面的限制，只能進行有限的軟件更改；而一旦售出以後，更難進行全面系統的修正。

5.2 智能家居雲平臺設計方案與相關技術

5.2.1 雲平臺需求分析

智能家居雲平臺是爲了實現智能家居系統的遠程監控而搭建的。智能家居網關必須接入互聯網，而且按照必定的格式將被控設備的狀態信息實時發送給雲平臺，才能保證信息的實時性。雲平臺處理數據以後，將之暫時保存在數據庫中。當終端訪問雲平臺時，雲平臺可以將設備的數據提供給終端，終端以可視化的形式展示給用戶。雲平臺要求能接受終端發出的控制命令，將之保存並轉發給家居網關，完成對設備的控制。

雖然該課題中的雲平臺並非直接面向用戶，但設計時也要爲考慮到用戶的需求，這樣才能保證方案的可行性。

雲平臺要實現的最終的功能是對智能家居設備的監控：

(1)     接受智能家居網關發送設備的狀態信息，並進行處理和存儲；

(2)     接受控制終端的請求，返回設備的狀態信息；

(3)     協調控制終端和智能家居網關之間控制命令的交互。

雲平臺更具體的功能則相似於通常的信息管理系統：

(1)     用戶認證：設備都有本身的歸屬，用戶只能控制本身的設備，只有經過認證以後才能查看和控制設備；

(2)     設備管理：應該容許用戶本身添加須要的設備，移除再也不須要的設備；

(3)     運行記錄（或稱歷史記錄）：全部的監控系統都應該記錄設備的運行狀態。

對於開發者而言，爲了運行維護的方便，錯誤日誌功能是必須的。不管是記錄在數據庫中仍是以文件的形式保存，都要能將相應的錯誤時間和錯誤信息記錄下來，以供調試和測試時查看。

5.2.2 數據交互格式

對於本課題的雲平臺而言，須要一種結構化的描述語言做爲數據格式，用以承受結構明確的請求數據和返回數據。

經過調研現有的物聯網雲平臺的設計方案以及API設計，可以發現現有的幾個成熟的雲平臺都在使用JSON做爲數據交互格式。而且在移動端的應用中，JSON也是做爲數據交互格式被普遍使用。而XML一樣做爲一種功能強大的標記語言被普遍用在Web服務中，天然也是一種不錯的選擇。

 

JSON簡單說就是JavaScript中的對象和數組，因此這兩種結構就是對象和數組兩種結構，經過這兩種結構能夠表示各類複雜的結構。

(1)     對象：對象在JavaScript中表示爲「{}」括起來的內容，數據結構爲 {key：value, key：value,...}的鍵值對的結構，在面向對象的語言中，key爲對象的屬性，value爲對應的屬性值，因此很容易理解，取值方法爲 對象.key 獲取屬性值，這個屬性值的類型能夠是數字、字符串、數組、對象幾種。

(2)     數組：數組在JavaScript中是中括號「[]」括起來的內容，數據結構爲["java","javascript","vb",...]，取值方式和全部語言中同樣，使用索引獲取，字段值的類型能夠是 數字、字符串、數組、對象幾種。

JSON與XML的比較：

(1)     編碼難度：XML有豐富的編碼工具，好比Dom4j、JDom等，JSON也有提供的工具。在沒有工具的狀況下，相信熟練的開發人員同樣能很快的寫出想要的XML文檔和JSON字符串，不過，XML文檔要多不少結構上的字符。

(2)     可讀性：XML有明顯的優點，畢竟人類的語言更貼近這樣的說明結構。JSON讀起來更像一個數據塊，讀起來就比較費解了。不過，咱們讀起來費解的語言，偏偏是適合機器閱讀。

(3)     有效數據率。JSON做爲數據包格式傳輸的時候具備更高的效率。這是由於JSON不像XML那樣須要有嚴格的閉合標籤，這就讓有效數據量與總數據包比大大提高，從而減小同等數據流量的狀況下，網絡的傳輸壓力。

 

本課題搭建的雲平臺的主要任務是完成數據的處理、存儲和轉發。雖然，PHP對XML和JSON這兩種格式的數據都有支持，但在考慮數據傳輸效率的狀況下，包含大量冗餘標籤的XML明顯沒有JSON方便。顯然這也是其餘物聯網雲平臺選擇JSON格式做爲數據交互格式的重要緣由之一。

5.2.3 雲平臺基本設計方案

經過以上雲平臺需求和通訊協議方面的分析，咱們初步肯定了如下的雲平臺設計方案：

(1)智能家居網關和智能家居控制終端同雲平臺之間的通訊協議使用應用層的HTTP協議，使用HTTP請求來向雲平臺請求服務（包括保存數據和發出控制命令等）。

(2)雲平臺僅實現純粹的數據處理服務，不涉及界面實現，提供統一的API接口，供智能家居網關、智能家居控制終端、智能家居Web控制平臺使用。

(3)雲平臺將使用PHP語言進行開發，使用JSON做爲數據交互格式，來實現雲平臺各項功能。

 

以上設計方案的特色有：

(1)對外而言，雲平臺提供的接口是一致的，訪問的方式也是相同的。所以，雲平臺能同時支持B/S（智能家居Web控制平臺）和C/S（智能家居遠程控制終端）架構的開發。

(2)使用HTTP協議做爲通訊協議，使用HTTP基本方法（GET，POST，PUT，DELETE等）進行服務請求，不一樣平臺訪問API的方法具備一致性。

(3)雲平臺僅負責數據處理，不涉及界面實現，使得各個控制平臺都能根據本身的平臺特色進行界面開發，並且不影響功能的實現。

5.3 智能家居雲平臺系統設計

5.2.1 數據庫設計

對於實際的一個設備，能夠有多個傳感器，用來表示設備不一樣的狀態；也能夠有多個執行器，用來接受發出的控制命令。好比，對於無線智能家居系統中現有的可調顏色的RGB燈而言，它有一個開關型的傳感器來獲取燈的開關狀態，一個用於保存RGB值的傳感器來獲取RGB燈的顏色。固然，RGB燈的開關和RGB值都是可控的，因此須要有兩個執行器用於接受這兩個設定值。

對於傳感器而言，通常來講其值由智能家居網關獲取並上傳至雲平臺，而控制終端只有讀取的權限；對於執行器而言，在遠程控制時，通常由控制終端來上傳設定值，發送控制命令，由智能家居網關讀取值，執行控制命令。

由以上分析可知，對於傳感器和執行器，通常都只有一方（智能家居網關或控制終端）寫入數據，另外一方讀取數據。咱們能夠將傳感器和執行器統一爲傳感器，但爲之分配不一樣的類型，用來標記傳感器類型的差異，由智能家居網關和控制終端負責根據其類型，進行不一樣的處理。

這樣作的目的在於，做爲一個面向後續開發的系統，充分保證智能家居網關和控制終端的靈活性。同時也弱化雲平臺系統的特異性，儘可能使全部的操做統一，並退化爲對數據的操做，方便功能的擴展。固然，在後續的面對客戶的版本發佈時，應該完善這些操做方面的限制。

數據點應該由時間戳和數值組成，同時還要有個字段標記數據點所屬的傳感器。對於不一樣類型的傳感器，其值的類型和範圍都會有差異，爲了提升數據庫空間的利用效率，能夠將不一樣類型的傳感器的數據點保存在不一樣的表中。

由此，智能家居系統中的基本結構可肯定爲：一個具體設備（device）由多個傳感器（sensor）構成，每一個傳感器有本身的類型（type），每一個傳感器同時還有對應不一樣時間的多個數據點（datapoint）。每一個具體的設備屬於不一樣的用戶（user），特定的用戶只能操做屬於本身的設備。

通過初步的分析以及其它方面的補充，得出如下數據庫E-R圖：

圖5.2 數據庫E-R圖

 

5.2.2 RESTfulAPI設計過程

在本課題的雲平臺設計方案中，默認使用而且暫時只支持JSON格式的響應數據，在使用API的時候仍然要將在HTTP請求報文的首部中設置「Accept: application/json」選項以確保之後雲平臺功能擴展時返回錯誤類型的響應數據。

雲平臺接受數據的形式根據HTTP請求方法不一樣略有差別。對於GET和DELETE請求，附加參數附在URI後面，即經過GET方式傳遞的參數；對於POST和PUT請求，數據經過HTTP表單的形式傳遞過來，即「Content-Type: application/x-www-form-urlencoded」。

如今初步定義RESTful API的功能，接口的功能和說明見下表5.1。

表5.1 API請求方法與功能定義

請求方法	URI/URL	功能
用戶接口
POST	/api/login	用戶登陸，用戶認證
GET	/api/user/<user_id>	獲取用戶的詳細信息
PUT	/api/user/<user_id>	更改用戶的詳細信息
設備接口
GET	/api/devices	獲取全部設備列表
POST	/api/devices	添加一個新的設備
GET	/api/device/<device_id>	獲取設備的詳細信息
PUT	/api/device/<device_id>	更改設備的詳細信息
DELETE	/api/device/<device_id>	刪除設備
傳感器接口
GET	/api/sensors/<device_id>	獲取指定設備下的全部傳感器
POST	/api/sensors/<device_id>	在指定設備下添加一個新的傳感器
GET	/api/sensor/<sensor_id>	獲取傳感器的詳細信息
PUT	/api/sensor/<sensor_id>	更改傳感器的詳細信息
DELETE	/api/sensor/<sensor_id>	刪除傳感器
數據點接口
GET	/api/datapoints/<sensor_id>	獲取指定傳感器的數據點（多個）
POST	/api/ datapoints/<sensor_id>	爲指定傳感器建立數據點（多個）
GET	/api/datapoint/<sensor_id>	獲取指定傳感器的最新數據
POST	/api/datapoint/<sensor_id>	爲指定傳感器建立單個數據點
DELETE	/api/datapoint/<dp_id>	刪除數據點（保留，暫不用）

 

5.4 智能家居雲平臺功能實現

接下來介紹智能家居雲平臺具體功能的開發過程，以及逐個的RESTful API的實現過程。

5.4.1 設備類

設備和用戶屬於多對一的關係，即一個用戶能夠有多個設備，每一個設備必然歸屬於某一個用戶。所以在數據庫設計中，設備表中使用了外鍵約束，用戶ID（user_id）引用用戶表（tb_user）中的用戶ID（id）欄。

對設備的操做都須要檢查用戶的權限：首先檢查HTTP請求報文中的APIKEY，而後再檢查操做的設備中的用戶ID是否與之對應。不對應，就認爲該設備不屬於該用戶，用戶沒法請求API進行操做。檢查設備歸屬的函數也是經常使用的共有函數。

(1)   獲取設備列表

請求方法：GET

請求URI：/api/devices

響應內容：返回JSON格式的對象數組

設計方法：

首先調用公有函數_check_apikey()檢查用戶狀態並獲取用戶ID，使用用戶ID在設備表（tb_device）中查詢全部屬於該用戶ID的設備，進行JSON編碼後返回數據給用戶。

(2)   添加新的設備

請求方法：POST

請求URI：/api/devices

響應內容：成功或失敗的提示性信息

設計方法：

首先調用公有函數_check_apikey()檢查用戶狀態並獲取用戶ID。使用基本的Web表單的形式將設備信息提交到雲平臺，由雲平臺獲取表單數據，在結合已獲取的用戶ID，進行數據庫的插入操做，返回操做成功的提示信息。

(3)   獲取設備信息

請求方法：GET

請求URI：/api/device/<device_id>

響應內容：設備詳細信息

設計方法：

首先調用公有函數_check_device()檢查設備的歸屬，而後直接使用URI中的參數在數據庫中查詢該設備的信息。

(4)   更改設備信息

請求方法：PUT

請求URI：/api/device/<device_id>

響應內容：成功或失敗的提示信息

設計方法：

首先調用公有函數_check_device()檢查設備的歸屬（同時也會確認設備的存在性）。使用基本的Web表單的形式將新的設備信息提交到雲平臺，由雲平臺獲取表單數據，進行數據庫的更新操做，返回操做成功的提示信息。

(5)   刪除設備（停用設備）

請求方法：DELETE

請求URI：/api/device/<device_id>

響應內容：成功或失敗的提示信息

設計方法：

首先調用公有函數_check_device()檢查設備的歸屬，再使用URI中的參數進行數據庫的更新操做，將設備表中符合要求的一條記錄的狀態（status）列設爲1，返回操做成功的提示信息。因爲存在外鍵約束，不能直接刪除設備。同時真正的系統中，對數據的刪除都應當心操做，由於一旦刪除沒法恢復。所以使用狀態（status）字段來表示設備的刪除狀態。所以，前面的API獲取設備列表和獲取設備信息功能中，查詢數據庫都要添加對狀態（status）字段的判斷。在用戶看來已被刪除（實際上在表中沒有刪除）的設備不該出如今列表中，也不能被獲取詳細信息，不能更改設備信息。

 

5.4.2 傳感器類

傳感器和設備屬於多對一的關係，即一個設備能夠包含多個傳感器，每一個傳感器必然屬於某一個設備。所以在數據庫設計中，傳感器表中也使用了外鍵約束，設備ID（device_id）引用設備表（tb_device）中的設備ID（id）欄。

建立傳感器時應該指定該傳感器所屬於的設備（建立設備時，自動設置所屬用戶爲API使用者），所以API雖大部分相似與設備類，但依舊有些許不一樣。

對於傳感器的操做，權限和歸屬的檢查同時也要深刻到傳感器的層次，同時也要檢查傳感器所屬設備的歸屬。

(1)   獲取傳感器列表

請求方法：GET

請求URI：/api/sensors/<device_id>

響應內容：返回JSON格式的對象數組

設計方法：

首先調用公有函數_check_device()檢查設備狀態，使用該設備ID在傳感器表（tb_sensor）中查詢全部屬於該設備ID的傳感器，進行JSON編碼後返回數據。

(2)   添加傳感器（向特定設備添加）

請求方法：POST

請求URI：/api/sensors/<device_id>

響應內容：返回成功或失敗的信息

設計方法：

首先調用公有函數_check_device()檢查設備狀態。使用基本的Web表單的形式將傳感器信息提交到雲平臺，由雲平臺獲取表單數據，在結合已有的URI參數設備ID，進行數據庫的插入操做，返回操做成功的提示信息。

(3)   獲取傳感器信息

請求方法：GET

請求URI：/api/sensor/<sensor_id>

響應內容：返回傳感器詳細信息

設計方法：

首先調用公有函數_check_sensor()檢查傳感器狀態，再直接查詢該傳感器的信息，並返回數據。

(4)   更改傳感器信息

請求方法：PUT

請求URI：/api/sensor/<sensor_id>

響應內容：返回成功或失敗的信息

設計方法：

首先調用公有函數_check_sensor()檢查傳感器狀態。使用基本的Web表單的形式將傳感器信息提交到雲平臺，由雲平臺獲取表單數據，進行數據庫的更新操做，返回操做成功的提示信息。

(5)   刪除傳感器

請求方法：DELETE

請求URI：/api/sensor/<sensor_id>

響應內容：返回成功或失敗的信息

設計方法：

首先調用公有函數_check_sensor()檢查傳感器的狀態，其它處理相似於設備的刪除操做，不直接刪除記錄，只是將記錄標記爲已刪除。

 

5.4.3 數據點類

數據點和傳感器屬於多對一的關係，即一個傳感器能夠有多個數據點，每一個數據必然歸屬於某一個傳感器。所以在數據庫設計中，數據點表中也使用了外鍵約束，傳感器ID（sensor_id）引用傳感器表（tb_sensor）中的傳感器ID（id）欄。

數據點的字段有四項：編號（id）、傳感器ID（sensor_id）、時間戳（timestamp）、值（value）。

對於數據點的數據庫設計曾經有多種方案，最終暫時採起了最簡單、最直接的一種設計方案：只使用一個表保存不一樣類型數據傳感器的數據，而且使用可變長度字符串（varchar）直接保存數值。這樣設計的優勢在於，數據點的插入和查詢都比較簡單，而且數值的類型幾乎沒有限制，傳感器的值甚至可使用一個字符串（一句話）。但缺點也很明顯：首先，傳感器類型的區分就沒有太多意義了；存儲空間的使用效率可能會比較低。

在MySql中，對於可變字符串（varchar）而言，真實佔用的空間爲字符串的實際長度n+1 Byte。對於開關量，以0和1表示的話，則每一個值須要佔用2 Bytes；對於整型數值，位數n越長，佔用Byte數就越多，爲n+1 Bytes；對於浮點數來講，以兩位整數、兩位小數爲例，須要佔6 Bytes。

總的來講，只有在數值爲位數較少的整型時，才勉強佔用空間略小；其它狀況下，都多佔了不少的存儲空間。

另外一種設計方案則是爲每種數據類型的傳感器設計不一樣的表存儲數據。如開關量，將value列設爲布爾型；整型數值，將value列設爲int型；浮點型數值，將value列設爲float型。這樣的確充分利用了存儲空間，但在某些功能的設計時遇到了很大的麻煩，尤爲是批量上傳數據、批量獲取數據時。故而，這種數據庫設計方案被置爲保留方案，暫時使用最方便的方案。

(1)   建立數據點

請求方法：POST

請求URI：/api/datapoint/<sensor_id>

響應內容：返回成功或失敗的信息

設計方法：

首先調用公有函數_check_sensor()檢查傳感器狀態和權限。使用基本的Web表單的形式將數據點信息提交到雲平臺，由雲平臺獲取表單數據，在結合已有的URI參數傳感器ID，進行數據庫的插入操做，返回操做成功的提示信息。

該功能的數據庫操做涉及3個表：數據點表（tb_datapoint_lite）、傳感器表（tb_sensor）、設備表（tb_device）。在建立數據點的時候，時間戳使用的是服務器自動生成的時間戳，不須要再單獨上傳。在爲傳感器建立數據點的時候，咱們認爲傳感器數據獲得更新，因而同時更新傳感器表（tb_sensor）中的最禁更新時間（last_update）和最近數據（last_data）爲數據點的時間戳和數據值。同時，咱們認爲設備是活動的，因而將設備表中的活動時間（last_acitve）設置爲當前時間戳。至此，建立數據點及其連帶的操做纔算完成。

(2)   獲取傳感器最新數據點

請求方法：GET

請求URI：/api/datapoint/<sensor_id>

響應內容：返回時間戳和數據

設計方法：

首先調用公有函數_check_sensor()檢查傳感器狀態和權限，而後直接從傳感器表中讀出最近（最新）的數據和時間戳，並返回。

(3)   批量上傳數據點（網關用）

請求方法：POST

請求URI：/api/datapoints/<device_id>

響應內容：成功或失敗的信息

設計方法：

該功能主要面向智能家居網關開發，用於批量上傳某個設備內全部傳感器的數據。這個操做只會修改URI中指定的設備的最後活動時間（不是根據傳感器再來判斷更新哪一個設備）。由於數據處理比較複雜，因此對網關上傳數據時有必定的要求：上傳時在URI中指定傳感器所屬設備，上傳數據的全部傳感器都應屬於該設備，不然不會爲它建立數據點；上傳數據時依然使用表單的形式，設置json值爲要提交的數據的JSON字符串（即將數據組織成JSON數據再經過表單傳遞過來）。

處理流程爲：

調用公有函數_check_device()檢查用戶權限。雲平臺接受經過表單傳遞過來的JSON數組，對之進行解析成PHP索引數組。遍歷數組每個元素，而後組織出兩個數組：一個用於批量更新傳感器表的數據，一個用於批量插入數據點。執行SQL語句，返回結果。

(4)   批量獲取數據

請求方法：GET

請求URI：/api/datapoints/<type>/<id>

響應內容：JSON格式的對象數組

設計方法：

當<type>=device時，<id>表明的是設備ID，該接口用於獲取某個設備下全部傳感器的最新數據；當<type>=sensor時，<id>表明的是傳感器ID，該接口用於獲取某個傳感器的歷史數據。

經過必定時間間隔獲取數據的SQL語句分析：

 

核心在於，將數據點的時間戳減去開始時間，而後與時間間隔取餘，而後與系統要求的上傳數據的最小時間間隔（30s）比較。若是取餘以後，小於30s，則取出該記錄。加入採用默認的時間間隔60s，且數據上傳間隔正好是30s，那麼1個60s內，顯然取餘以後，只會有一個數據符合要求，達到60s取一個點的要求。對於時間間隔，若是小於30s，顯然全部的點都會被取出來。

雲平臺全部基本功能接口均已測試經過，但可能也存在遺漏的BUG，這須要在更多、更完善的測試以後纔可以發現並修正。

由於報告篇幅有限，不可能將全部的測試實例及測試結果都羅列出來，故只給出幾個重要模塊的測試結果。

(1)     登陸成功的響應結果

響應正文（格式化以後的JSON）：

(2)     獲取設備列表成功的響應結果

響應正文（格式化以後的JSON）：對象數組。

結果相似的還有獲取傳感器列表成功時的響應。

(3)     獲取單個設備信息的響應

響應正文（格式化以後的JSON）：

(4)     建立設備成功的響應

響應正文：

(5)     刪除設備成功的響應

響應正文：

(6)     獲取單個設備全部傳感器數據的響應

響應正文：

 

(7)     獲取單個傳感器的歷史數據的響應

響應正文：

5.5 雲平臺測試與結果分析

5.5.1 雲平臺測試

爲了完成雲平臺API的測試，須要一個可以快速高效組織HTTP請求報文，併發送HTTP請求的工具。經過調研，咱們選擇了使用Google的Chrome瀏覽器結合其擴展應用Postman – REST Client來進行測試，經過Chrome瀏覽器開發者工具獲取更詳細的HTTP請求報文（Request Message）和響應報文（Response Message）的具體內容。

下面是以雲平臺中用戶類的登陸API進行測試的實例。在示例中，咱們展現了使用Postman進行RESTful API測試的基本方法，以及使用Chrome瀏覽器開發者工具獲取完整的請求報文和響應報文的方法。

 

圖5.3 Postman-REST Client界面

圖5.4 Google Chrome瀏覽器開發者工具

雲平臺全部基本功能接口均已測試經過，但可能也存在遺漏的BUG，這須要在更多、更完善的測試以後纔可以發現並修正。

由於論文篇幅有限，不可能將全部的測試實例及測試結果都羅列出來，故只給出幾個重要模塊的測試結果。

(8)     登陸成功的響應結果

響應正文（格式化以後的JSON）：

 

(9)     獲取設備列表成功的響應結果

響應正文（格式化以後的JSON）：對象數組。

結果相似的還有獲取傳感器列表成功時的響應。

 

(10) 獲取單個設備信息的響應

響應正文（格式化以後的JSON）：

(11) 建立設備成功的響應

響應正文：

(12) 刪除設備成功的響應

響應正文：

(13) 獲取單個設備全部傳感器數據的響應

響應正文：

 

(14) 獲取單個傳感器的歷史數據的響應

響應正文：

5.5.2 雲平臺測試結果分析

雲平臺的基本功能已經實現，而且具有了基礎的錯誤控制能力以及錯誤信息提示功能，可以以JSON格式返回請求的數據，而且完成對設備、傳感器的添加、查看、修改和刪除功能。

本課題中的雲平臺的設計方案中並無涉及界面的實現，並且就無線智能家居系統而言，控制界面的實現徹底由控制終端和Web控制平臺自主實現。該課題中的雲平臺僅負責完成數據的處理、存儲與請求，負責協調控制終端、Web控制平臺與智能家居網關之間的數據交互。因此，在雲平臺基礎功能測試經過，可以返回正確的數據以後，咱們認定該智能家居雲平臺基本方案設計已經完成。

對於無線智能家居系統而言，接下來須要智能家居網關、控制終端和Web平臺實現同雲平臺的數據提交和獲取，而後實例化設備，實現對實際設備的控制。    (1)數據的安全性

使用普通HTTP報文傳遞的數據是透明的，咱們經過抓包獲取了HTTP報文以後，就能夠獲取報文中傳遞的內容。例如登陸接口使用POST方法，用戶名與密碼都直接包含在請求報文內。爲了保證數據的安全性，通常來講會使用HTTPS協議。但由於涉及跨平臺的請求，我不肯定在網關、控制終端訪問使用HTTPS協議的接口時，是否會出現某些錯誤。

(2)測試的侷限性

因爲無線智能家居系統沒有徹底實現，咱們沒有使用實際的設備來測試雲平臺的接口，雲平臺只測試了基本的數據提交和返回是否正確。也沒有對多併發的請求進行測試，所以在實際使用中，出現不少請求時，雲平臺系統的穩定性並無確切保證。

(3)數據庫結構的優化

在設計過程當中，進行功能設計的時候，咱們結合具體功能的要求屢次修改了數據庫結構。爲了方便系統的實現，咱們優先採用了簡單有效的實現方法，數據庫結構也相對簡單。在下一步完善系統功能時，須要對數據庫結構進行修正與完善，確保結構的合理性和完備性。

 

6 總結

 

本文圍繞新興物聯網智能家居的產品進行了深刻詳細的調查，研究併成功設計了一套完整的基於ZigBee技術智能家居系統，涵蓋了ZigBee無線組網技術、嵌入式智能網關設計、並設計了能提供遠程監控和控制以及個性化服務的智能家居雲平臺。本文主要完成的工做內容以下：

1、對家居組網的有線技術和無線技術進行分析比較，採用無線技術來設計智能家居內部網絡，對目前市場上常見的幾種無線通訊技術作了詳細比較，肯定選用ZigBee 做爲智能家居的內部網絡通訊技術，對 ZigBee 協議架構及各協議層功能進行了研究。

2、構建智能家居系統的總體框架，肯定家居內部網絡的拓撲結構，完成了家居網關的總體設計、傳感器節點的佈設及網絡標識，實現了外部網絡的接入功能。

3、對家居網關進行軟、硬件設計，完成各功能模塊的嵌入。本文使用ARM 開發板代替PC做爲家居網關，將STM32與LwIP結合搭建家居網關的軟、硬平臺，選用 CC2530 做爲家居內部網絡傳感節點的主芯片。家居系統軟、硬件設計完畢後，將家居內部網絡與家居網關相連，家居網關與外部網絡相連，進而實現內外網相通，完成信息的交互。

4、本文設計了用於協做控制終端和智能家居網關實現智能家居遠程監控功能的雲平臺, 採用應用層的HTTP協議做爲通訊協議，JSON格式做爲雲平臺響應數據格式，經過PHP編程，實現了雲平臺的基本功能和RESTful風格的API。雲平臺面向的用戶羣爲開發者，爲無線智能家居系統後期開發服務。

來自爲知筆記(Wiz)

附件列表