畢業(yè)論文——基于物聯網的農田環(huán)境監(jiān)控系統(tǒng)的設計與研究

《畢業(yè)論文——基于物聯網的農田環(huán)境監(jiān)控系統(tǒng)的設計與研究》由會員分享，可在線閱讀，更多相關《畢業(yè)論文——基于物聯網的農田環(huán)境監(jiān)控系統(tǒng)的設計與研究（46頁珍藏版）》請在裝配圖網上搜索。

1、 畢業(yè)設計說明書 基于物聯網的農田環(huán)境監(jiān)控系統(tǒng)的設計與研究院 、 部： 計算機與信息科學學院 學生姓名： 指導教師： 職稱 專 業(yè)： 計算機科學與技術 班 級： 完成時間： 摘 要采用物聯網技術對農業(yè)生產環(huán)節(jié)中農作物的生長環(huán)境監(jiān)控，實現一個輕量級別的輔助管理系統(tǒng)。基于傳感網絡采集的溫度、濕度、光照等相關數據達到對當前實時環(huán)境的遠程監(jiān)控并做出實際的機械操作。整個系統(tǒng)是通過傳感器將基本的監(jiān)控數據利用ZigBee技術傳送到局域網路由器，基于C/S模式，服務器對傳感網絡收集的數據進行容錯篩選，再存儲。管理者通過移動終端向服務器發(fā)出請求命令，服務器收到請求解析并做出相應的反應，從而達到對系統(tǒng)環(huán)境狀況的實

2、時監(jiān)察調度。論文是以當前的物聯網技術作為發(fā)力點，結合農業(yè)溫室作物培植技術，論述并實現了物聯網農田環(huán)境監(jiān)控系統(tǒng)，為種植戶實現一個實時農田作物生長數據監(jiān)控并提供相關技術與數據上的支持，真正實現了農業(yè)管理的智能化，符合現代農業(yè)的發(fā)展。關鍵詞 物聯網；傳感網絡；現代農業(yè)；生產決策ABSTRACTUsing Internet technology to agricultural production in crop growth environment monitor to Implement a lightweight auxiliary management system. Based on dat

3、a of temperature, humidity, light and other sensor networks to achieve the current collection of real-time remote monitoring of the environment and make the actual mechanical operation.The whole system is monitored by basic sensor data utilizing ZigBee technology transfer to the LAN router, based on

4、 C / S mode, the sensor network server data collected fault tolerance screening, and then store. Managers issued through the mobile terminal requests to the server command, the server receives the request parsing and react accordingly, so as to achieve real-time monitoring system scheduling environm

5、ent. This article from the current of things, combined with agronomic techniques, made things overall framework of police dispatch system structure of agriculture.The user real-time monitoring of farmland and production data to support decision-making, truly intelligent management of agriculture, in

6、 line with the development of modern agriculture.Key words epc network; sensor network; modern agriculture; production decision目 錄第一章引 言41.1課題背景和意義41.2國內外研究現狀41.3篇章組織5第二章基于物聯網的農田環(huán)境監(jiān)控系統(tǒng)的設計框架71.1智能家居系統(tǒng)中的環(huán)境監(jiān)控解決思路71.2基于物聯網的農田環(huán)境監(jiān)控系統(tǒng)9第三章硬件環(huán)境的搭建112.1硬件環(huán)境組成框圖112.2服務器端環(huán)境搭建122.2.1開發(fā)與調試工具包安裝122.2.2開發(fā)板開發(fā)與調試環(huán)境配置

7、132.3 數據采集端環(huán)境配置172.3.1硬件資源概覽172.3.2 模塊芯片的選擇182.3.3開發(fā)與調試工具包安裝19第四章軟件設計213.1 服務器端的軟件設計223.1.1 Linux內核移植223.1.2 SQLite數據庫223.1.3 Json文件的格式實現233.1.4 服務器端的通信協(xié)議的設置233.2 數據采集端軟件設計263.2.1總體設計概述263.2.2 數據采集端M0與服務器端A9通信協(xié)議設置273.3 Android客戶端軟件設計29第五章系統(tǒng)實驗與調試304.1 服務器A9模塊的數據接/發(fā)調試的相關過程展示304.2 數據采集M0模塊的調試374.3客戶端測試

8、展示39第六章總結反思41參考文獻42致 謝43第一章 引 言1.1 課題背景和意義物聯網是當今新一代信息技術的核心，作為后互聯網時代具有產業(yè)性潛力的技術，它的定義也是隨著技術的不斷深入發(fā)展而被一次次定義。物聯網是個泛概念，它是多學科、多領域的集合體，它集中體現了后互聯網時代的技術方向，同樣是人類更高層次發(fā)展的切入口。從單純的知識概念上講，這是一個入門很高的學科領域，它所體現的就是當今互聯網理念思想發(fā)展的更高層次的分化與融合。從市場與技術的縱向上看，物聯網實現的是更高生活品質的宜人化的服務層次，它所蘊含的產業(yè)價值也定不會遜色于電商時代。物聯網概念的提出其實是很早的，但是受制于現實技術等因素，它

9、的發(fā)展也總是很緩慢，物聯網展現的是多領域的融合。從這個角度講，它的的發(fā)展同樣是一個面的概念，反而是單個因素成為磕絆發(fā)展的短板！物聯網不是中國首次提出的，卻是在當前背景下發(fā)展最為全面的，而從實際的角度上講，先驅意味著前行，意味著時間與金錢上無限的投入。但是，從長遠角度上講，這些投入都是必須的也是值得的！2009年美國白宮，肯定了在基于物聯網基礎提出的“智慧地球”概念，并在全球經濟下行壓力極大的情況下，大手筆的投入智慧地球。對于高科技美國人歷來是唯快不破，并牢牢把握科技的上游，這也體現了物聯網背后的政治與科技的角逐！1.2 國內外研究現狀物聯網從本世紀出的首次提出到今天，它的應用已經滲入了我們生活

10、的方方面面。從飯不離手的智能手機到瘋狂驚叫的VR設備，再到強大的“大狗”機器人，無不體現嵌入式在現代生活元素中的身影。從國內外更廣的視角來看，在農業(yè)上物聯網技術的應用也在不斷的深入。就農業(yè)生態(tài)環(huán)境監(jiān)測領域來講，法國、美國和日本等一些國家運用監(jiān)控衛(wèi)星網絡加地面監(jiān)控站來構建全國性或者全區(qū)域性的先進農業(yè)生態(tài)環(huán)境監(jiān)測網絡，憑借先進的傳感器感知技術、信息融合傳輸技術以及互聯網技術建立區(qū)域性的農業(yè)信息化平臺，實現對農業(yè)生態(tài)環(huán)境的自動監(jiān)測，從宏觀上保證農業(yè)生態(tài)環(huán)境的可持續(xù)發(fā)展，并指導農業(yè)現代化種植與發(fā)展。在農業(yè)生產精細管理領域，美國、澳大利亞、法國等傳統(tǒng)的農畜牧業(yè)比較強大的西方國家建立了完善的指導機制平臺，

11、并形成了廣泛的實用性極強的控制系統(tǒng)。在物聯網農業(yè)的發(fā)展我國其實也是奮起直追，在相關領域也有著不錯的成績，現階段我們在北京、上海、江蘇等地方建立起了很多農業(yè)示范園，同時各地也在 積極推進物聯網農業(yè)的優(yōu)質項目，并且這些項目的到了較好的回應，在保證農民增收的基礎上，對于糧食供給和食品安全領域的助推也是顯而易見的。在全國性的環(huán)境監(jiān)控方面的發(fā)展上我們同樣有我們自己的比較成功的實用案例。但是我們總體層次上相較之國外的發(fā)展，還是存在著很多的問題。物聯網農業(yè)遍地開花的局面并沒有產生，傳統(tǒng)小田農業(yè)結構的弱化甚至是破碎較為嚴重！換言之，我們的傳統(tǒng)的耕作與管理模式都在弱化！國家從2003年就在不斷的加大農業(yè)生產上的

12、補助與扶持，從國家政策層面上來講，我國已經在農業(yè)發(fā)展上出臺了多個國家級文件。但是，從全局縱向上看，我國的傳統(tǒng)農業(yè)的發(fā)展也僅僅是負重式的發(fā)展，整體的發(fā)展速度在區(qū)域上是存在巨大差異的，并且這種差異在進一步擴大！物聯網農業(yè)的成熟應用主要集中在農畜牧業(yè)發(fā)展比較強大的西方國家，這不是偶然卻存在著必然！農業(yè)的發(fā)展是一個循序漸進的過程，它集中體現了一個國家在民生方面的積累與沉淀。對于中國這樣一個傳統(tǒng)的農業(yè)大國來說，農業(yè)發(fā)展是的不平衡性不是一個政策一攬子文件就能解決的，它背后體現的是市場與價值還有實際人文的選擇與轉變，這就意味著農業(yè)的不平衡性將是長期的。一時的大手筆絕對不是解決的方法，一味的放置偏頗更是不可取

13、，在技術與資金上的積極引導才是正道，國家層面的示范建設是標桿，企業(yè)及個人的投入是補充，主體與局部的結合才是物聯網農業(yè)在中國當前的實際技術與地理環(huán)境上的真正選擇！1.3 篇章組織本文面向建立的是小型化的農業(yè)生產環(huán)節(jié)的環(huán)境監(jiān)控的研究平臺。主要就是建立一個核心在局域網的小型農田監(jiān)控系統(tǒng)，主要是對中、近距離數據傳輸與監(jiān)控。整個設計分為三個模塊：服務器模塊，數據采集模塊，應用層模塊。在服務器端將采用Cortex-A9芯片，數據采集模塊采用的是芯片Cortex-M0，應用層是移動終端通過訪問本地路由器建立與通信。在M0模塊將實現光照監(jiān)控子模塊，溫度監(jiān)控子模塊。還有簡單的模擬開關燈子模塊，模擬開關風扇子模塊

14、。在服務器A9端實現數據的處理存儲，同時是通過有線與本地路由器進行連接，服務器A9與M0模塊是通過ZigBee模塊進行通信的。用戶可以通過手機、平板等移動終端通過WIFI與路由器進行通信，從而訪問服務器。針對現實學習需求與知識技能的儲備，本文僅僅是有選擇有裁剪的模擬實現了環(huán)境檢測的簡單框架。本文第二章簡要介紹了智能家居實現監(jiān)控的基本邏輯框架與思路。因為物聯網農業(yè)監(jiān)控與智能家居在起點與數據處理階段同宗同源，同時詳細說明本設計的框架。第三章對整個系統(tǒng)的模塊細分并說明各自的功能與實現邏輯以及硬件部分詳細設計。第四章為整個系統(tǒng)軟件部分詳細設計。第五章是單元測試以及系統(tǒng)綜合驗收測試。第六章指出該系統(tǒng)的特

15、色與反思以及對物聯網農業(yè)的展望。第二章 基于物聯網的農田環(huán)境監(jiān)控系統(tǒng)的設計框架 1.1智能家居系統(tǒng)中的環(huán)境監(jiān)控解決思路這里首先介紹下當前物聯網框架下的智能家居系統(tǒng)的模式與基本實現解決思路。物聯網農業(yè)是基于物聯網發(fā)展而來的，是物聯網應用向農業(yè)的觸及，但是從當前的大環(huán)境上來講，物聯網在農畜牧業(yè)的發(fā)展也僅僅停留在大田示范園的階段，而物聯網在適宜人居環(huán)境的應用、推廣與投入是比較成功也是比較大的。這種現象其實很好找到原因。作為一個商業(yè)性的發(fā)展，利益驅動才是根本，很明顯投資物聯網農業(yè)在成本上與市場回報上周期都是很長的，而研發(fā)成本以及硬件成本是很高的，而做出的產品在市場的普及上又是未知的，利益小風險大，所以

16、說這個領域的成熟的參考是較少的。但是智能家居與物聯網農業(yè)在模塊化的數據采集與數據的傳輸階段又是相通的，我們基于“用已知去探求未知，化抽象為具體”的解決思想，從當前智能家居的模式與問題解決方案來找到靈感，打趣的說我們是站在巨人的肩膀上看待物聯網農業(yè)前景的！坦率的講，在智能家居領域的產品競爭早已不是單個產品再或者單個系列的小打小鬧，在競爭的背后是對這個行業(yè)甚至是對互聯網+時代的技術與市場的把控與行業(yè)標準的搶占。當前，無論是實力強大的互聯網企業(yè)還是傳統(tǒng)的電商大鱷，更甚是剛步行業(yè)的微小型公司，他們都在利用自己的優(yōu)勢打造自己關于物聯網智能家居的理解和對未來高品質家居生活的闡釋。通俗的講，這些企業(yè)關注點和

17、搶占的先機就是智能家居的控制入口。任何一個標準化的產品都是從竟態(tài)下的考驗最終在市場與利潤的現實驅動因素下走向標準，今天的物聯網產業(yè)正處于竟態(tài)下，都在把握市場與價值的切合點上起舞，不同的性質的企業(yè)對這個舞蹈的欣賞又是各不相同的！智能硬件企業(yè)：手機+智能小部件模式。毫不夸張的說在嵌入式產品中的發(fā)展中，各大手機廠商絕對可以稱得上主要力量。從智能手機的門被打開的那一刻，疙瘩手機更是層出不窮，做情懷產品的時代幾乎是一夜間就消失殆盡了。同時在智能家居的領域這些廠商也是拼勁十足。主要代表的就是小米和華為的智能家居戰(zhàn)略。他們的思路就是在路由器上做文章，將自家的路由器作為智能家居戰(zhàn)略的入口和推廣平臺，并且配置相

18、關系列的智能配件來自我組裝一個可供自己選擇且適合自己的口味的智能家居環(huán)境，同時將自己的平臺做有限的開放，將更多的開發(fā)接口提供出來，為個人的意愿發(fā)展提供現有微小平臺。對于手機制造廠家來說輕車熟路更易于成功，所要解決的問題主要是“點”的定位，而不完全受制于一個完整的平臺約束，擴展性很強，在網絡接入和產品控制上，變得更容易！互聯網企業(yè)：用解決方案來做云上的智能家居。談及對當前科技的把控，互聯網大公司絕對是最為敏感的，對于做服務的互聯網大佬們，利潤的驅動絕對是至上的，從這幾年BAT一系列的收購行為以及對P2P與O2O平臺的大手筆的投入便可看出。對于智能家居，他們也有著自己對未來宜人家居的品質生活的定位

19、與看待。百度通過搭建硬件平臺并推出了自家的云服務；騰訊則是以微信為自己的突破口；阿里則借助視頻盒子和云OS作為智能家居平臺的入口。當我們靜下心去細細想下這些互聯網公司的選擇的突破口，我們會發(fā)現他們最大的優(yōu)勢是其巨大的流量、用戶數據、附帶的系列軟件等，結合當前的云存儲與云計算，為智能家居的提供一個頂層設計也是一種完美的擬合。但是到目前為止也僅僅是百度做出了點成效。在早期的智能家居探索的產品是很多的，但是收益甚微，那一輪的家居熱情就此虎頭蛇尾的結束了。對于智能家居的家居元素的理解的深度還是不夠透徹，由此可見當前市場上充斥著以小米模式噴涌的智能小產品，但是主流價值產品卻是不足！不得不說主流產品布局的

20、智能家居是一個整體框架的必然需要。傳統(tǒng)家電企業(yè)：產業(yè)聯盟式入口模式。不得不說最早嗅到物聯網下智能家居發(fā)展的是傳統(tǒng)的家電廠家。物聯網本身就是一個技術驅動的產業(yè)，很顯然憑借傳統(tǒng)電商的營銷老路子是走不通的，曾經大批家電企業(yè)在轟轟烈烈的進軍PC產業(yè)的教訓是痛在他們心里的?，F實的狀況是，在專業(yè)性技術和推廣策略的限制下傳統(tǒng)家電企業(yè)在智能家居領域的單打獨干顯得很無力。當物聯網的浪潮真正全面襲來的時候，主流的家電公司紛紛選擇他們的方式家電聯盟，去融入并打造他們世界觀下的智能家居。比如海爾的U-home系統(tǒng)為平臺，憑借E家佳聯盟標準達到了多產品的兼容。傳統(tǒng)家電企業(yè)對家用電子設備是真正理解，憑借自己在傳統(tǒng)家電行業(yè)

21、內的威望，組建一個企業(yè)聯盟進而建立拉攏一批小型智能家居制造商，搭建統(tǒng)一的開放平臺，以此來把控智能家居的入口也不失為一個上上策。1.2基于物聯網的農田環(huán)境監(jiān)控系統(tǒng)解決思路這里我主要關注的是小米家的解決模式。手機+智能單品的模式下，小米絕對是獨樹一幟的前行者，小米的產品的營銷模式雖廣受詬病，但是小米產品還算是成功的。回看以智能手機為核心的等一批便攜式的智能硬件的發(fā)展軌跡，4年來，有的企業(yè)倒了，有的市場在不斷萎縮。小米在壯大中，正如小米的技術總監(jiān)孫鵬說的，智能家居的思路想法誰都有，能做出使用的產品在說！在小米的智能家居設計理念中，路由器是數據處理的核心，智能插座等小部件是入口。各種米系列的產品通過無

22、線或者有線鏈接到路由器，米路由器從功能上來說，除了基本路由器常有的網關、Wi-Fi熱點功能之外，還支持小米設備快連、可擴展功能的插件模式、DLNA 方式共享文件、支持 LAMP功能。我的設計就是基于本地路由訪問方式實現數據收集與監(jiān)控的！整個設計是模式探索型的設計，基于這種定位整個系統(tǒng)的模塊是很簡單的，在功能上也進行了相關的裁剪和功能的模擬轉移。這種定位是對實際技術與成本進行相關考量后做出決定的。作為一個畢業(yè)設計受制于個人知識與眼界，我僅僅能做我能勝任的部分，同時當前可以學習參考的模型是有的，但都不是開源的資料，對于當前物聯網來說一切都是在起步上下功夫，一切都是商業(yè)！雖然小米曾承諾將相關協(xié)議開放

23、，就是BAT也曾說將平臺開放，但是實際對于個體用戶的測試學習還是很困難的。本設計主要分為三個模塊，服務器模塊，數據采集模塊，移動控制端模塊。服務器端選擇的是三星以ARM的cortex-A9系列為核心開發(fā)的Exynos 4412。這款芯片采用了三星最新的32nm HKMG工藝，主頻最高為1.4GHGz，是三星的第一款四核處理器。因為采用了新的工藝實現相同性能的同時功耗控制更加出色。此外，三星Exynos 4412支持雙通道LPDDR2 1066內存，這款芯片在同期同層次的芯片中算是最優(yōu)的，特別在很多媒體的測試中，搭載了這款芯片的移動設備的跑分都是很高的。數據采集模塊采用的以Cortex-M0為核

24、心板的LPC11C14芯片。數據傳輸模塊用的是ZigBee技術。LPC11C14集成了溫濕度度傳感器，光照傳感器，可調速小風扇等小模塊，通過這些模塊 對周圍環(huán)境的溫濕度，光照強度數據進行收集，然后通過組合的ZigBee模塊將數據傳輸到Exynos 4412服務器端，服務器端對數據容錯，存儲。服務器一端通過ZigBee與LPC11C14模塊通信，另一端通過有線與本地路由器進行鏈接通信。當用戶通過設置固定IP訪問本地路由器的移動端向服務器發(fā)出服務請求，服務器端對相關請求進行解析，做出開關燈、風扇的邏輯操作。約定：以下Cortex-A9表示服務器，簡稱A9；以下Cortex-M0表示數據采集模塊,簡

25、稱M0；以下APP表示智能家居 Android 客戶端應用程序。第三章 硬件環(huán)境的搭建2.1硬件環(huán)境組成框圖本設計主要分為三個大模塊，服務器模塊，數據采集模塊，移動控制端模塊，服務器模塊與數據采集都集成了數據傳輸模塊。服務器端選擇的是三星公司開發(fā)的Exynos 4412。數據采集模塊采用的LPC11C14芯片。數據傳輸模塊用的是ZigBee技術。LPC11C14集成了溫濕度度傳感器，光照傳感器，可調速小風扇等小模塊，這些模塊獲得的數據通過組合的ZigBee模塊傳輸到Exynos 4412服務器端，服務器端對數據容錯，存儲。服務器一端通過ZigBee與LPC11C14模塊通信，另一端通過有線與本

26、地路由器進行鏈接通信。用戶通過設置固定IP訪問本地路由器，服務器端對相關請求進行解析，做出及時響應。整體系統(tǒng)組成框圖如圖2-1：圖2-1 整體系統(tǒng)組成框圖2.2服務器端環(huán)境搭建2.2.1開發(fā)與調試工具包安裝對于整個系統(tǒng)來講環(huán)境的配置是至關重要的，整個系統(tǒng)將會把大把的時間花在硬件的調試，以期獲得一個穩(wěn)定的性能，（1）安裝gcc編譯工具：yagarto-bu-2.21_gcc-4.6.2-c-c+_nl-1.19.0_gdb-7.3.1_eabi_20111119.exe。（2）安裝tools工具：yagarto-tools-20100703-setup.exe。（3）安裝FS-JTAG工具：（4

27、）安裝JTAG驅動：把JTAG 接入計算機USB口，會提示發(fā)現新硬件，選擇從列表或指定位置安裝。（這個過程需要安裝3次）2.2.2開發(fā)板調試與開發(fā)環(huán)境配置服務器A9中跑的不是裸機是一個裁剪了小型化的Linux內核，下邊就是往開發(fā)板上配置相關環(huán)境。我們板子上跑的是Linux系統(tǒng)所以我們開發(fā)調試階段也要在這樣一個環(huán)境中進行，所以開發(fā)的階段必須在Linux虛擬機上通過調試工具建立一個相關聯的環(huán)境。模擬一個同板子環(huán)境相似的環(huán)境。在產品開發(fā)并測試完成后在將板子與虛擬機環(huán)境徹底分離。Exynos 4412開發(fā)板如圖：圖2-2 Exynos 4412整個A9模塊開發(fā)的過程分為兩個三個階段：階段一進行相關環(huán)境

28、的配置，主要是對開發(fā)環(huán)境與開發(fā)板環(huán)境的配置；階段二進行軟件層次的設計，諸如服務器端的數據庫的設計；階段三將進行A9單個模塊的調試以及整體組合后的調試，這個過程是最為關鍵的，關乎整個系統(tǒng)的穩(wěn)定性能，同是也是復雜程度最高的模塊。在階段一，我們將開發(fā)環(huán)境與開發(fā)板環(huán)境分別稱為Host端開發(fā)與Target端開發(fā)，在Host端開發(fā)我們要安裝一系列的開發(fā)調試工具包，并且配置Host與Target開發(fā)的服務器環(huán)境。在Target端我們主要是對目標機環(huán)境簡單設置，同是進行相關功能的實驗。當三個階段做好之后將做好的Boot Loader和Kernel還有Roofs燒寫到開發(fā)板上，至此一個裁剪的嵌入式小型數據處理服

29、務器做好了！嵌入式Linux開發(fā)模式如圖2-3：圖2-3 嵌入式Linux開發(fā)模式框圖開發(fā)板調試模式如圖2-4：圖2-4 開發(fā)板調試模式框圖這里將X86機器作為開發(fā)服務器機器，開發(fā)板作為目標機或者調試機。tftp服務器的配置：TFTP（Trivial File Transfer Protocol,簡單文件傳輸協(xié)議）是TCP/IP協(xié)議族中的一個用來在客戶機與服務器之間進行簡單文件傳輸的協(xié)議，提供開銷不大且不復雜的文件傳輸服務。端口號為69。TFTP是一個傳輸文件的簡單協(xié)議，它基于UDP協(xié)議而實現。在調試開發(fā)階段我們使用tftp服務器目的就是可以將我們在Host機中編譯開發(fā)好的內核高速的下載到Ta

30、rget中。對于產品的快速開發(fā)調試是至關重要的。Tftp服務器的具體配置如圖2-5：圖2-5 tftp服務器配置流程圖nfs服務器的配置：nfs是Network File System的縮寫，即網絡文件系統(tǒng)。一種使用于分散式文件系統(tǒng)的協(xié)定，它的最大的功能就是通過網絡讓不同的機器、不同的操作系統(tǒng)能夠彼此分享個別的數據，它的基本原則是“容許不同的客戶端及服務端通過一組RPC分享相同的文件系統(tǒng)”，它是獨立于操作系統(tǒng)，容許不同硬件及操作系統(tǒng)的系統(tǒng)共同進行文件的分享。也正是nfs簡單實現但功能相對健壯的特點，給調試和文件系統(tǒng)的制作過程帶來極大的快捷、方便。具體搭建過程詳見圖2-6：圖2-6 nfs服務器

31、配置流程圖整個過程必須保證完整且正確，在實際的配置的過程會出現很多調試配置上的問題，一定要克服解決！做好A9開發(fā)和調試后環(huán)境后就是具體的內核移植的過程了。內核移植主要工作就是U-Image的制作，這個制作過程在第三章講解，下邊大體介紹整個開發(fā)板的啟動流程如圖2-7：圖2-7 開發(fā)板的啟動流程圖2.3 數據采集端環(huán)境配置2.3.1硬件資源概覽數據采集模塊采用的是基于ARM Cortex-M0 內核的LPC11C14 微控制器 ，集成多種傳感器、RFID、ZigBee、OLED 顯示模塊等的一款芯片。配套有開放的CoLink仿真器，使用者可以在不另外配置U-LINK2仿真器的情況下進入開發(fā)。本設計

32、中我選擇了溫濕度傳感模塊、光照傳感模塊、ZigBee數據傳輸模塊。LPC11C14芯片整體框架如圖2-8：圖2-8 LPC11C14芯片整體框架本套架構設計是用于Exynos 4412服務器端與LPC11C14之間的程序設計的整體框架和數據的處理過程。Exynos 4412通過發(fā)送操作請求數據包到LPC11C14來完成相應的用戶希望得到的操作與數據，同時LPC11C14給Exynos 4412回復相應的確認包，表示LPC11C14已經完成了這項操作。這樣就可以完成一次交互。LPC11C14的實物展示如圖 2-9：圖2-9 LPC11C14芯片實物展示2.3.2 模塊芯片的選擇溫濕度傳感器DHT

33、11的基本原理：DHT11是一款有校準數字信號輸出的溫濕度傳感器。精度濕度+-5%RH，溫度+-2，量程濕度20-90%RH，溫度050。它采用的是簡化的單總線通信，系統(tǒng)中的數據交換、控制均由單總線完成。DATA用于微處理器與DHT11之間的通訊和同步,采用單總線數據格式，一次傳送40位數據，高位先出。數據格式: 8bit 濕度整數數據 + 8bit 濕 度小數數據+8bit 溫度整數數據 + 8bit 溫度小數數據+8bit 校驗位。原理圖如圖 2-10：圖 2-10光照感應器ISL29003的基本原理：ISL29003內部有兩個光電管。光電管1對可見光和紅外光都是敏感的，光電管2主要是對紅

34、外光敏感的。這兩個的光譜反應是獨立的。兩個光電管將光信息轉換為電流，然后通過二極管的電流輸出會被一個16位的A/D轉換為數字信號。原理圖如圖 2-11：圖 2-112.3.3開發(fā)與調試工具包安裝在這個階段開發(fā)環(huán)境是Keil Real View MDK，這個軟件是ARM公司推出的。Real View MDK 集成了業(yè)內最領先的技術，包括 Vision4 集成開發(fā)環(huán)境與Real View編譯器，它支持 ARM7、ARM9和最新的Cortex-M0、Cortex-M1、Cortex-M3 和 Cortex-M4核處理器，自動配置啟動代碼，集成Flash 燒寫模塊，強大的 Simulation 設備模

35、擬，性能分析等功能在LPC11C14開發(fā)過程我們同樣需要調試工具，這里我們選用的是CoLink仿真器，該仿真器上有Colink固件。Colin實物展示如圖2-12：圖2-12 Colin實物展示Colin的安裝調試如圖2-13：圖2-13 Colin的安裝調試流程圖第四章 軟件設計整個系統(tǒng)的軟件設計部分主要有四個部分：服務器端，數據采集端，數據傳輸模塊，APP模塊，在服務器端主要的工作將集中在對Linux系統(tǒng)移植和數據傳輸階段，前者是一些固化的操作，僅僅是在驅動的實現階段有點難度，相較之后者要比較麻煩要不斷的進行測試才可以穩(wěn)定的數據傳輸通信。數據采集端主要實現的是數據通信與光照傳感器與溫濕度傳

36、感器的驅動，這個過程都算可以，還是傳輸數據的階段最為反復。在移動APP設計，用的是Android進行開發(fā)的，主要解決的問題是數據的展示與請求命令的解析處理。在服務器端采用的是Json格式數據進行存儲的。整個系統(tǒng)的軟件框架如圖3-1：圖3-1 系統(tǒng)的軟件框架3.1 服務器端的軟件設計3.1.1 Linux內核移植內核移植是這個模塊的核心工作，也同樣是嵌入式產品的核心，我們是在一個固定的框架下做東西，是在開源代碼的基礎上裁剪出自己需要的模塊，在根據自己實際的需求，去實現相應的模塊的驅動，這個過程在這里不詳細說明，這個過程的框架流程如圖3-2：圖3-2 Linux內核移植跨職能流程圖3.1.2 SQ

37、Lite數據庫SQLite，是一款關系型數據庫管理系統(tǒng)，它的設計目標是嵌入式的，目前在嵌入式領域絕對不二選擇。這個數據庫占用資源非常的低，很符合嵌入式內存有限的基本現狀。這里使用SQLite3來對APP傳輸來的登錄數據進行存儲。這里的建表很簡單就是為了存儲用戶的登錄信息。LogName，PassWord, PhoneNumber，UserToken這些字段，其中UserToken是Key值。圖3-3 sqlite3用戶數據庫設計3.1.3 Json文件的格式實現這里數據通信中的數據格式都是采用的Json，這是一種輕量級的數據交換格式，它采的是用完全獨立于語言的文本格式，但同時又保留了類C的習慣

38、。易于人編寫和閱讀，于此同時讀，解析和生成都比較快速。也正是這些特性使之成為使用比較方便的數據交換格式。3.1.4 服務器端的通信協(xié)議的設置服務器A9的通信主要是與客戶端通信、M0進行通信，雙方之間通信通過 TCP 協(xié)議通信，在應用層指定自己的數據包格式，并且?guī)в写_認機制，這個模塊講解說明的是Android的APP與服務器A9進行通信。這里根據實際的功能需求進行了通信協(xié)議的設置如表3-1，表3-2：表3-1 JSON格式的KEY值數據包格式JSON格式的KEY值如下：userName用戶名oldPassword 舊密碼newPassword 新密碼password 密碼phoneNumber手

39、機號userToken 用戶身份識別碼randomCode 驗證碼（6 位大小寫字母和數字組成）stateCode狀態(tài)值（int）temperature溫度humidity 濕度light 光照deviceNumber 設備號deviceCode 設備操作碼deviceState 設備狀態(tài)碼videoList 獲取視頻文件列表表3-2服務器與客戶端通信的狀態(tài)碼格式服務器返回給客戶端的狀態(tài)碼：stateCode ：0 客戶端請求成功stateCode ：1 客戶端請求失敗stateCode ：2 客戶端用戶名錯誤stateCode ：3 客戶端密碼錯誤stateCode ：4 客戶端手機號錯誤s

40、tateCode ：5 客戶端驗證碼錯誤stateCode ：6 客戶端 userToken 錯誤stateCode ：7 客戶端 userToken 過期服務器返回給客戶端的設備狀態(tài)：deviceState:0 設備處于打開狀態(tài)deviceState:1 設備處于關閉狀態(tài)deviceState:2 設備處于故障狀態(tài)客戶端請求設備操作碼：deviceCode:0 請求打開設備deviceCode:1 請求關閉設備deciceCode:2 請求獲取當前設備的狀態(tài)表3-3服務器與客戶端通信數據包格式數據包格式如下:報文類型 功能號 數據長度 數據內容 數據包格式的詳細說明(1)報文類型 : 表示誰

41、跟誰通信,大小為1byte報文類型 表示誰跟誰通信 0 xaa AndroidAPP-A90 xffA9-AndroidAPP(2)功能號 : 表示要干什么事情,大小為1byte 功能號(大小為1byte)用戶操作 0 x00用戶注冊 0 x01用戶登陸 0 x02忘記密碼 0 x21發(fā)送用戶原密碼 0 x03修改密碼 0 x04請求獲取溫度0 x05請求獲取濕0 x06請求獲取光照 0 x07請求獲取三軸數據 0 x08打開關閉燈 0 x09打開關閉風扇 0 x0a打開關閉門 0 x0b得到視頻文件 0 x0c獲取設備狀態(tài)(3)數據長度:數據包攜帶大小為 2byteJSON格式的數據（4）數

42、據內容：JSON格式的字符串數據包3.2 數據采集端軟件設計3.2.1總體設計概述本套架構設計是用于的Exynos 4412（Cortex-A9）與 LPC11C14（Cortex-M0）之間的程序設計的整體框架和數據的處理過程。這里采用的是“三次握手”的機制進行可靠傳輸的，首先A9 通過發(fā)送操作請求數據包到M0完成相應的用戶希望得到的操作，同時M0給 A9回復相應的確認包，表示M0已經完成了這項操作，這樣就可以完成一次交互。具體實現如圖3-4：圖3-4 M0與A9通信的框架模型圖一 ：（1）設計思路：A9與 M0之間是用 ZigBee 來進行數據的傳輸，ZigBee 有兩個模塊，一個是協(xié)調器

43、，它與A9是通過串口相連接。另一個是終端，它與M0也是通過串口相連接。 所以我們通過讀和寫串口的函數接口就可以得到我們想要的數據包。（2）設計講解：在圖中分別有發(fā)出的數據包和獲得數據包兩種包，這里的包是由之前我們自己定義的通信協(xié)議來決定的。圖中標為淺藍色的字體，數據包是從M0發(fā)送到A9。紅色字體說明處理的是溫濕度的數據包，當A9請求M0發(fā)送溫濕度或者是光照的時候，M0 采集到溫濕度或光照的信息之后，通過寫串口函數接口把數據寫入ZigBee的寫緩沖區(qū)中，終端ZigBee再通過從電磁波上分離出的數據包發(fā)送到協(xié)調器ZigBee，此時的協(xié)調器將數據包搬移到串口的讀緩沖區(qū)，A9通過讀串口的函數接口獲取到

44、希望得到的傳感器數值。圖二 （1）設計思路：M0中程序的執(zhí)行邏輯，因為數據都是通過串口來發(fā)送和獲取的，所以我們可以采用輪詢的方式來查詢終端ZigBee的讀緩沖區(qū)是否有A9數據包請求。如果有， 則解析這個數據包，從而做出客戶想要得到的操作效果；如果沒有，則需要溫度的數據實時（1ms）的寫入終端ZigBee的寫緩沖區(qū)中，目的是為了客戶可以隨時獲取和感知家里的溫度信息。（2）設計講解：在圖中的第一個分支，當檢測到終端ZigBee的讀緩沖區(qū)中有數據，表 明客戶希望操作家里的硬件設備（風扇、燈）或者是獲取當前家里的溫濕度、光照信息。在這時M0就要解析這些從A9發(fā)來的數據包，完成客戶的操作后返回一個確認包

45、，表明已經完成此項操作。當檢測到終端 ZigBee 的讀緩沖區(qū)中沒有數據，表明客戶沒有操作請求， 需要M0實時的將信息發(fā)送到終端 ZigBee的寫緩沖區(qū)，再通過ZigBee把數據包發(fā)送到A9，實時的對周圍環(huán)境行監(jiān)控。M0模塊對數據發(fā)送與請求命令的解析過程如圖3-5：圖3-5 M0模塊對數據發(fā)送與請求命令的解析過程3.2.2 數據采集端M0與服務器端A9通信協(xié)議設置這里的協(xié)議是涉及的是M0與A9進行通信的，這些協(xié)議是根據實際的硬件需要建立的比較簡單的一個協(xié)議。如圖 表3-4,3-5：表3-4 .請求數據包格式1.請求數據包格式如下報文類型 功能號 設備編號 數據內容 (1)報文類型 : 表示誰跟

46、誰通信，大小為 1byte。 報文類型 源端（發(fā)送端） 目標端（接收端） 0 xdd Exynos4412（cortex-A9） LPC11C14（cortex-M0） (2)功能號: 表示要干什么事情，大小為 1byte。 功能號 功能說明0 x04 FS4412 請求 LPC11C14 控制燈0 x05 FS4412 請求 LPC11C14 控制風扇0 x06 FS4412 請求 LPC11C14 控制門(3)設備編號：區(qū)分同類的每個設備，大小為 1byte。如 LED1：0 x00；LED2：0 x01(4)數據內容:數據大小溫度（1byte） 濕度（1byte） 三軸信息（3byte）

47、光照（2byte） 7byte 門禁狀態(tài)（1byte）: 0 x00 表示打開 0 x01 表示關閉 1byte 燈光狀態(tài)（1byte）: 0 x00 表示打開 0 x01 表示關閉 1byte風扇狀態(tài)（1byte）: 0 x00 表示打開 0 x01 表示關閉 1byte 表3-5應答數據包格式2.應答數據包格式如下報文類型 功能號 設備編號 數據內容 (1)報文類型: 確認包,報文類型固定為 0 xcc,占用 1 個字節(jié)。報文類型 源端（發(fā)送端） 目標端（接收端） 0 xcc LPC11C14（cortex-M0） Exynos4412（cortex-A9）(2)功能號: 確認的是什么事情

48、。功能號（1byte） 功能說明0 x00LPC11C14 響應溫度數據到 Exynos44120 x01LPC11C14 響應濕度數據到 Exynos4412 0 x02LPC11C14 響應光照數據到 Exynos44120 x03LPC11C14 響應三軸數值到 Exynos44120 x04LPC11C14 響應燈狀態(tài)到 Exynos44120 x05請求 LPC11C14 響應風扇狀態(tài) Exynos44120 x06請求 LPC11C14 響應門的狀態(tài) Exynos4412(3)設備編號：區(qū)分同類的每個設備，大小為 1byte。如 LED1：0 x00；LED2：0 x01(4)狀態(tài)

49、：成功還是失敗，占用 1 個字節(jié)。狀態(tài) 說明0 x00門打開 0 x01門關閉 0 x00燈打開 0 x01燈關閉 0 x00風扇打開 0 x01風扇關閉 3.3 Android客戶端軟件設計如圖3-6：所示，這個是整個客戶端軟件的功能展示與通信流程：圖 3-6 Android客戶端軟件模塊設計圖 3-7 是整個客戶端執(zhí)行流程：圖 3-7 Android客戶端執(zhí)行流程圖第五章 系統(tǒng)實驗與調試4.1 服務器A9模塊的數據接/發(fā)調試的相關過程展示依據前面對服務器與客戶端約定的協(xié)議進行通信測試：表 4-1 注冊數據包收發(fā)格式注冊發(fā)送數據包 APP向服務器A9發(fā)送注冊數據包數據流向 APPA9報文類型

50、 功能號 數據長度 數據內容 0 xaa 0 x00 APP 那邊發(fā)送 的JSON長度用戶名，密碼,手機號發(fā)送數據包 A9向服務器APP發(fā)送注冊數據包數據流向 A9APP報文類型 功能號 數據長度 數據內容 0 xff0 x002byte 狀態(tài)的JSON格式字符串數據內容：“stateCode” : 0 成功 數據內容：“stateCode” : 1 失敗圖 4-1 服務器端注冊測試表 4-2 登錄時數據包格式登錄發(fā)送數據包 APP向服務器A9發(fā)送注冊數據包數據流向 APPA9報文類型 功能號 數據長度 數據內容 0 xaa0 x01 2byte userToken( 唯 一 標識符號)+狀態(tài)

51、注意:登陸成功后，服務器端需要給客戶端返回一個 ID(唯一身份識別碼)。 客戶端去解析。userToken 為 JSON 格式的字符串。數據長度為 JSON 格式的數據 內容長度.數據內容：“userToken”:”Qrt3T4”,“stateCode”： 0-登錄成功。 數據內容：“userToken”:“null”,“stateCode”： 2-用戶名錯誤 數據內容：“userToken”:“null”,“stateCode”： 3-密碼錯誤圖 4-2 服務器端登錄時測試表 4-3 找回密碼時數據收發(fā)格式忘記密碼發(fā)送數據包 APP向服務器A9發(fā)送注冊數據包數據流向 APPA9報文類型 功能

52、號 數據長度 數據內容 0 xaa0 x02APP那邊發(fā)送的JSON長度 用戶名，手機號碼APP 給服務端發(fā)送用戶名和手機號，服務端會通過用戶名和手機號生成一個唯一驗證碼并將其與此用戶名對應起來。圖 4-3 找回密碼時服務器端驗證碼測試表 4-4 獲取溫濕度時數據收發(fā)格式獲取溫度發(fā)送數據包 APP向服務器A9發(fā)送注冊數據包數據流向 APPA9報文類型 功能號 數據長度 數據內容 0 xaa0 x04APP 那邊發(fā)送 的JSON長度用戶名 ，userToken服務器分配的數據內容： “userName”:”Qrt3T4”,“userToken”: ”Qr5T4Y” , ”deviceNumber

53、”:0 發(fā)送數據包 A9向服務器APP發(fā)送注冊數據包數據流向 A9APP報文類型 功能號 數據長度 數據內容 0 xff0 x04 FS4412發(fā)送的 JSON長度溫度JSON字符串數據內容：獲得到溫度并返回狀態(tài) “temperature ”：20,“stateCode”: 0 數據內容：未獲取到溫度 “ stateCode” : 1 獲取濕度 發(fā)送數據包 APP向服務器A9發(fā)送注冊數據包數據流向 APPA9報文類型 功能號 數據長度 數據內容 0 xaa0 x05APP 那邊發(fā)送 的JSON長度用戶名 ，userToken服務器分配的數據內容： “userName”:”Qrt3T4”,“us

54、erToken” : ”Qr5T4Y” ”deviceNumber”:0發(fā)送數據包 A9向服務器APP發(fā)送注冊數據包數據流向 A9APP報文類型 功能號 數據長度 數據內容 0 xff0 x04 FS4412發(fā)送的 JSON長度濕度JSON字符串數據內容：獲得到濕度 “humidity” ：21,“stateCode” : 0 數據內容：未獲取到濕度 “ stateCode” : 1 圖 4-4 獲取溫濕度時數據測試表4-5 獲得光照數據收發(fā)格式獲取光照 發(fā)送數據包 APP向服務器A9發(fā)送注冊數據包數據流向 APPA9報文類型 功能號 數據長度 數據內容 0 xaa0 x06APP 那邊發(fā)送

55、的JSON長度用戶名 ，userToken服務器分配的數據內容： “userName”:”Qrt3T4”,“userToken” : ”Qr5T4Y”, ”deviceNumber”:0 發(fā)送數據包 A9向服務器APP發(fā)送注冊數據包數據流向 A9APP報文類型 功能號 數據長度 數據內容 0 xff0 x06 FS4412發(fā)送的 JSON長度濕度JSON字符串數據內容：獲得到光照 “l(fā)ight” ：300,“stateCode”: 0 數據內容：未獲取到光照 “ stateCode” : 1 圖4-5 獲得光照數據測試表4-6 控制LED開關的數據收發(fā)格式控制LED燈 發(fā)送數據包 APP向服務

56、器A9發(fā)送注冊數據包數據流向 APPA9報文類型 功能號 數據長度 數據內容 0 xaa0 x08APP 那邊發(fā)送 的JSON長度0：開燈 1：關燈數據內容： “userToken”:”Qr5T4Y”,”deviceNumber”:0, “deviceCode” : 0, “userName”: ”Qrt3T4” -開燈 “userToken”: ”Qr5T4Y” ,”deviceNumber”:0, “deviceCode” : 1,“userName”: ”Qrt3T4” -關燈發(fā)送數據包 APP向服務器A9發(fā)送注冊數據包數據流向 A9APP報文類型 功能號 數據長度 數據內容 0 xff

57、0 x08APP 那邊發(fā)送 的JSON長度狀態(tài)JSON格式的字符串 數據內容：“stateCode”: 0,”deviceState”:0 用 戶操作成功 設備處于打開狀態(tài) 數據內容： “stateCode” : 1，deviceState:1 用 戶操作失敗 設備處于關閉狀態(tài)圖4-6 控制LED開關的測試表4-7 控制風扇開關的數據收發(fā)格式控制風扇 發(fā)送數據包 APP向服務器A9發(fā)送注冊數據包數據流向 APPA9報文類型 功能號 數據長度 數據內容 0 xaa0 x09APP 那邊發(fā)送 的JSON長度0：開風扇 1：關風扇數據內容： “userToken”:”Qr5T4Y”,“deviceC

58、ode” :0,“userNa me”: ”Qrt3T4”,”deviceNumber”:0-開風扇 “userToken”: ”Qr5T4Y” ,“deviceCode” :1,“userN ame”: ”Qrt3T4”,”deviceNumber”:0-關風扇發(fā)送數據包 APP向服務器A9發(fā)送注冊數據包數據流向 A9APP報文類型 功能號 數據長度 數據內容 0 xff0 x09APP 那邊發(fā)送 的JSON長度狀態(tài)JSON格式的字符串 數據內容：“stateCode”:0,”deviceState”:0 用戶 操作成功 設備處于打開狀態(tài)數據內容： “stateCode” : 1,”devi

59、ce圖4-7 控制風扇開關的數據收發(fā)格式4.2 數據采集M0模塊的調試如圖4-8 光照傳感器測試：圖4-8 光照傳感器測試如圖 4-9 溫濕度傳感器測試：圖 4-9 溫濕度傳感器測試4.3客戶端測試展示圖 4-10 客戶端注冊圖 4-11 客戶端登錄圖 4-12 客戶端找回密碼圖 4-13 客戶端主界面第六章 總結反思整個系統(tǒng)選擇定位的就是一個輕量級別的輔助系統(tǒng)，所以在實際的開發(fā)中也是很方便簡單的，我參照的就是小米智能家居的模式，在實際的開發(fā)中，模塊靈活的度高，拓展性較強。但是在實際的開發(fā)的過程的時候，能夠參考的資料并不多。整個系統(tǒng)采用的是以路由器為核心的管理模式。但是問題也來了，路由器中心論

60、從產品層面看，路由必須做到全天候在線監(jiān)控，對穩(wěn)定性要求無疑是極高的。從另一個角度講路由器這個東西是單一性質的，本地中一般僅一個。這也意味著，你的產品好呢一切大吉，一旦一款產品不好，甚至整個產品鏈都會被消費者拋棄。在當前物聯網發(fā)展的過程中，無論是傳統(tǒng)電商還是互聯網公司，他們都在做平臺推廣平臺，從而爭奪物聯網的話語權。對于物聯網的在宜人家居的發(fā)展模式，可謂是仁者見仁智者見智，他們認為智能家居沒有天生的中心，也不會產生入口，它所提供給我們的是一個以服務為核心的架構。在當前市場背景下作為一個企業(yè)來說，能夠生存下去，要么賣服務要么賣產品，對于一個互聯網科技公司，我們能夠為農業(yè)提供什么樣的優(yōu)質服務?。孔鐾茝V服務的時代已經是活不下去了，對于硬件產品的投入的也是遙遙無期的，單純農業(yè)領域的硬件投入是不科學的，無論是從使用價值上還是現實的技術條件都是一蹴而就的。生活是生命的一部分，工作是生活的一部分。這些硬件僅僅是工作的一部分，家電卻是是我們優(yōu)質生活的一部分，在追求優(yōu)質的生活的時候必須考量的因素，但是對于這些物聯網硬件來說也僅僅是你工作的一部分，只要能夠高效的輔助工作我們在實際的理念上已經屏蔽掉的具體硬件的選擇。所