導言：作為寫作愛好者，不可錯過為您精心挑選的10篇管理系統論文，它們將為您的寫作提供全新的視角，我們衷心期待您的閱讀，并希望這些內容能為您提供靈感和參考。

篇1

12控制犗犘犆服務器中數據

1．2．1采集OPC項（OPCItem）中數據采集OPCItem中的數據，應該遵守OPC訪問規(guī)范（OPCDA）．客戶端程序應該具有服務器（Server）對象、組（Group）對象和項（Item）對象．軟件實現過程如下：打開MicrosoftVisualStudio2010，創(chuàng)建一個Windows窗體項目，在窗體中添加標簽、按鈕．程序設計首先添加OPC端口引用文件RsiOPCAuto．dll，該文件目錄一般為C：＼ProgramFiles＼CommonFiles＼Rockwell．

1．2．2數據寫入OPCItem數據寫入OPCItem與讀取OPCItem中數據相似，客戶端程序應該具有服務器（Server）對象、組（Group）對象和項（Item）對象，其流程與讀取數據的流程相似，不同點是將讀取數據改為寫入數據．

13存儲犗犘犆服務器中重要數據及存儲數據的調用

對電梯的運行進行統計則需要大量的數據，這些數據來自平時電梯的運行，要得到這些數據，需要將OPC服務器中的重要數據導入到Access數據庫中．為了便于觀察，系統具有顯示、查詢數據功能．

1．3．1存儲OPCServer中重要數據對派梯算法有影響的最直接的數據有呼梯信號所在電梯、轎箱外呼梯層、轎箱內呼梯層、呼梯時間．為了保證將所有的呼梯信號存儲到Access數據庫中，程序的掃描方式設置為實時掃描（不間斷掃描）；為了保證不重復的存儲數據，程序設置為當有信號改變時，則將數據導入到Access數據庫中．首先建立Access數據庫，其中包含用戶表（user）和電梯運行信息表（message）；在原有的項目上添加窗體文件，編寫C＃程序，實現客戶端程序與Access數據庫的連接、OPC中數據存入Access數據庫中．

1．3．2分析、篩選數據為了便于數據統計、管理，開發(fā)有統計、管理數據界面，能夠顯示數據庫中存儲的電梯按鍵的全部信息，還可以查詢在第犖層停車的所有電梯的名稱及時間．首先添加Form窗體，并改名為Management；在窗體中添加相應的Label，Button，TextBox，DataGridView控件，在DataGridView控件中選擇要顯示的數據源；編寫C＃程序，實現數據顯示、查詢等功能．

2電梯群控系統智能算法

派梯算法的優(yōu)化原則有時間最短、能耗最低、時間與能耗相結合3種，核心是評價函數的設定．本文使用的時間與能耗相結合的最優(yōu)原則，需計算以下幾類信息，如樓層、呼叫、轎廂狀態(tài)、曳引機狀態(tài)等，從而完成評價函數或適合度的評估，計算量小于16犖＋犖（犖－1）／2，其中犖為電梯數量．相較于典型的單一時間最短或能耗最低原則，此算法性能更靈活，同時還應該具有在呼梯高峰期派遣相應電梯到相應層待命的功能．

21系統總流程圖電梯運行時，上位機管理系統定時掃描PLC中的數據，針對群梯系統的實時性特點及考慮輸入、輸出電氣元件的特性，設定0．25s掃描1次，流程圖如圖2所示．

22子系統及其流程圖1）判斷電梯運行最高、最低層．運行最高層是電梯上行轉為下行時的轉折層，最底層即電梯下行轉為上行時的轉折層，其實現過程是，在主程序中添加函數犿犪狓＿犿犻狀（），根據轎廂內有無按鍵將其分為2種情況：當無內部按鍵時，根據上下行呼梯信號及呼梯信號所在樓層判斷電梯運行的最高最低層．當有內部按鍵時，比較上下行按鍵所在樓層、電梯所在當前層，得出電梯上下行最高最低層．2）判斷上下行．電梯上下行是電梯運行規(guī)則的一個標志．電梯的運行規(guī)則是順向呼梯時，電梯停車，反向呼梯，則需等電梯運行至最高層，反向后再響應反向呼梯信號．電梯的上下行判斷，即當沒有下行信號時，如果電梯上行最大層大于當前層，則電梯上行，即UP［犻］＝true，否則UP［犻］＝false；同理，可知判斷DOWN［犻］的真假．3）計算電梯的適合度狊狌犻狋（犻）．適合度由計算得出，與數值大小成反比．流程圖如圖3所示．4）選擇適合度最高的電梯．比較各電梯的狊狌犻狋（犻），狊狌犻狋（犻）取最小值，如圖4所示．5）將最適合的電梯所對應的電梯號反饋到OPC服務器中，同時PLC得到相應數據，執(zhí)行派梯．

3系統調試及實驗結果

在管理系統的主界面上點擊“啟動”按鈕，則在主界面的文本框中顯示電梯運行的狀態(tài)信息，如停車次數、電梯上下行狀態(tài)、等待時間、適合度、最高層最低層等，調試時根據這些數據，檢查派梯算法、電梯運行過程是否正確．

31根據電梯的運行過程直觀分析電梯分別停在1層時，在3層、4層分別有一個上行按鈕，結果是電梯1響應3層呼梯信號，電梯2響應4層呼梯信號，與真實要求一致；繼續(xù)調試，分別按下5層上行按鈕、2層下行按鈕，結果為電梯2響應5層呼梯信號，電梯1響應2層呼梯信號，與真實要求一致；再次按順序按下5層下行按鈕、7層上行按鈕、3層上行按鈕，結果是電梯2開門，電梯1響應7層呼梯信號，電梯3響應5層呼梯信號，調試結果與真實情況一致．

32根據數據分析電梯1，2，3，5，6在3層，電梯44層，這時在最短的時間內按下如下按鍵：梯1，內部按鍵2，6，7，梯2，3，5，6分別按下內部按鍵7，外部按鍵按下5層上呼按鈕，其運行數據如圖5所示，數據分析如下．電梯1：下行，響應2層內部按鍵，之后應該響應5層上行按鍵，再響應圖內部按鍵6，7，即響應外呼信號前停車1次，響應外呼信號后停車2次，由于時間差，當按下外呼按鈕后，梯1當前層已經顯示2層，所以其適合度計算為同理狑犪犻狋狋犻犿犲犉［1］＝（5－2）×2＋1×5＝11狑犪犻狋狋犻犿犲犔［1］＝2×5＝10，同理狊狌犻狋［1］＝狑犪犻狋狋犻犿犲犉×0．7＋狑犪犻狋狋犻犿犲犔×0．3＝10．7，同理，可計算梯2，3，4，5，6的適合度，但由于梯4處于檢修狀態(tài)，其適合度為自設值（目的是區(qū)別于其他電梯）．犉犻犵．5犕狅狀犻狋狅狉狑犻狀犱狅狑狊狅犳犲犾犲狏犪狋狅狉狅狆犲狉犪狋犻狅狀經聯機調試，群梯管理系統通過OPCServer與現場設備之間通信，能夠穩(wěn)定讀取現場設備運行時的數據，并將數據導入到Access數據庫中；系統能夠控制現場設備的運行，如電梯按鍵界面控制電梯的上下行，高頻呼梯時間段設置界面控制電梯在某個時間段內有電梯在相應樓層等候．該系統的智能算法使電梯準確響應呼梯信號，滿足候梯時間與能耗最低的綜合優(yōu)化原則．

篇2

2線損管理

2.1所謂的線損的管理就是在電力系統運行的過程中對于傳輸線部分以及各個傳送變壓裝置以及在該過程中總的電能損失之和。電力企業(yè)所售商品的主要的形式就是電能，電能的損失直接關乎到電力企業(yè)的經濟損失，也就是說電力企業(yè)的線損和電力企業(yè)經濟損失之間存在著直接的關系。所以在電力負荷管理的過程中，通過有關數據加強對于線損的管理，減少線損是電力企業(yè)應該著手要解決的問題。

2.2線損的類型有很多根據不同的分類標準可以將其分為很多的類型，包括由于技術原因造成的線損和管理原因所造成的線損。所謂的電力線損就是電力系統中各個元器件所造成的線損，除了上述所講的兩種線損之外還包括計算線損。在對線損進行管理的過程中，從理論上來講線損都能夠通過相應的計算來得到并且能夠進行避免。由于管理問題所造成的線損稱為管理線損，比如由于抄表的失誤或者是用戶的竊電都屬于管理線損的范疇。從上述兩種情況來進行劃分的話管理線損還可以分為有意的線損和無意的線損。供電企業(yè)給用戶所供給的電能和用戶所使用的電能的差值就是統計電能，為了更加方便的管理線損，一般在計算線損的過程中要考慮到高壓線損和配網線損。

2.3對于電力企業(yè)來講線損管理的常用方法在電力企業(yè)線損管理中占據著統治地位，其對于線損的管理地位是非常重要的，首先對于電網的網絡結構進行分析。要再利用常規(guī)管理方法的基礎上，結合可能產生線損的各個因素進行分析，包括配送線路上的線損，變壓過程中的線損等。然后在進行線損管理的過程中加強對于我國電網的改造對于電網的結構進行改造和管理，形成較為電網網絡。其次是計算理論上的線損。在進行理論線損計算的過程中要綜合考慮電網輸電過程中的各個可能造成線損的各個環(huán)節(jié)，特別是電網的負荷情況以及相應的網絡參數等。將理論計算值和實際的估算值進行比較，通過計算來發(fā)現發(fā)生線損的主要的原因，然后采取相應的措施來對電網負荷進行相應的改進。傳統的從線損的管理方式還能夠對于用戶的用電量用電功率進行檢查。對于用戶使用的較大功率的設備進行驗證，然后進行相應的查表作業(yè)，通過上述方式來對用戶的用電量進行核算，使得整個電網系統始終運行在較為合理的狀態(tài)上。這種線損計算和管理方法能夠有效的減少用戶的竊電行為最大限度的減少電力企業(yè)的經濟損失。采用傳統的線損的管理的方式能夠在很大程度上降低線損。在線損的管理工作中可以結合電網實際線損的情形指定為較為合理的線損管理方案，規(guī)劃好輸電的線路、供電所的相應的線損，大力推行線損管理過程中的責任制度來有效做好線損的管理工作。在線損管理的過程中還應不失時機的加強電力企業(yè)對于電力的調度。在對電力系統進行線損管理的過程中應該將工作的重點放到節(jié)能上來，在可以對電網系統進行優(yōu)化的過程中，還能夠實現遠距離的輸電，使得電網的運作效率大大提高。通過有效的管理和調度能夠大大減少電網上所產生的線損。

3電力負荷管理系統在降低線損管理中的應用

3.1變電所始端的線損管理

在對線損進行管理的過程中，變電所有效的采用了電力負荷管理系統，采用電力負荷管理的系統能夠對用戶用電進行監(jiān)測還可以實現遠程的抄表作業(yè)。能夠實現抄表作業(yè)的自動化，使得相關工作人員的勞動強度大大降低了。在這種情況下抄表的時間以及抄表的精確性都避免了人工的誤差使得抄表的精度增加。通過這種管理系統的自動化實現可以更好地對于線損的管理，并且能夠使得上述線損降低到很低的程度。

3.2末端電力用戶的線損管理

在電力系統運行的過程中末端的電表也是非?？傄囊粋€環(huán)節(jié)，在安裝的過程中一定要做好相應的工作，可以是的整個系統連接在一起避免了數據不一致的現象。以此為基礎可以較為方便的對線損量進行計算。針對不同用戶電力使用不同的實際情況，對線損進行管理盡量保證所采集數據的科學性和合理性。

3.3配電網絡的線損管理

在配電網絡中一般都要相對應的配電網絡管理系統，通過無限的方式實現對于配電網絡系統的集成和管理，對于運行狀態(tài)進行遠程的監(jiān)測，采用這種方式能夠在技術和管理兩個方面上實現對于配電網絡的線損的管理。在實際管理的過程中可以對較為典型的配電網絡安裝相應的終端來實現對于線損的管理使得線損降到最低。

3.4電力負荷管理系統對公用變壓器的監(jiān)測

電力負荷管理系統還能夠對于公用變壓器相關的數據進行采集、監(jiān)測和管理，各種電表以及其他種類的終端數據都可以進行集成然后進行綜合分析。電力負荷管理系統通過采集到的實時數據還能夠對于變壓器進行狀態(tài)以及線損的監(jiān)測，通過對于變壓器中的電壓以及電流等參數的監(jiān)測實現對于線損的監(jiān)測。

篇3

2、ALM系統基礎建設

ALM系統平臺基礎數據的統一定義是整個系統的基礎。通過對設備樹、數據分類、數據庫體系、告警體系等的統一定義，形成各個應用系統共有的基礎數據，減少各應用模塊及線路問的接口，有效提高維保系統的整體性能和數據共享。因此，應進行設備基礎信息庫、標準設備狀態(tài)監(jiān)測模型及上層管理系統接口這3大基礎建設。

2．1設備基礎信息庫與ALM系統

接口的子系統包括各種不同的設備。ALM系統監(jiān)控的基本對象是設備，大多數的需求都是結合設備的監(jiān)控、管理和維護提出的。因此，應建立基于ALM系統的設備管理功能，以支持通信系統的建設和運營維護。同時為地鐵設備管理提供支持?；贏LM系統的設備管理，其主要管理對象為通信系統設備信息，因此應為設備管理功能體系建立標準的設備信息顯示模型、完整的基于ALM系統的沒備信息庫和用于設備信息管理的接口。設備信息庫是ALM系統建設和運行的基礎，所有的設備信息顯示模型均通過設備信息庫生成。在系統調試階段，大量設備信息由各子系統承包商提供，而ALM系統承包商將這些信息整理并歸檔于設備信息庫。設備信息庫存儲于歷史數據庫中。設備信息庫是基于ALM系統多個基礎表而建立的，包括站點表、子系統表、設備類型表、告警分級表等。由于ALM系統站點眾多，每個站點的子系統眾多，設備信息庫是一個數據量非常龐大的表格，因此，必須建立合理的基礎信息體系，這樣才能保證數據錄入和檢索的完整和高效。同時，需采用海量實時性能較高的歷史數據庫產品，以支撐數據基礎體系的建立。設備信息庫是一個完整的信息中心，包括了所有專業(yè)／子系統的設備信息，因此ALM系統的建設和維護需要眾多專業(yè)／子系統的人員支持。為了便于每個專業(yè)／子系統人員對本專業(yè)的設備信息進行管理，必須建立一個通用的接口，使各專業(yè)／子系統人員不必直接面對數據量龐大的設備信息庫，而是通過接口進行本專業(yè)的數據錄入和檢索。設備信息管理接口是人機界面的一部分，是系統維護人員的工具之一。該接口往往被運營人員所忽視，由此會導致設備信息管理的雜亂無章。

2．2標準設備狀態(tài)監(jiān)測模型

2．2．1設備狀態(tài)判斷

不同的設備具有自身的專業(yè)特點。ALM系統需要針對每一類設備進行告警分級、維修方式設定，以形成標準的設備狀態(tài)監(jiān)測模型體系，然后通過高性能的軟件數據處理功能實現對設備維修信息的快速處置。一般將設備的狀態(tài)分為維持服務、暫停服務和•14f1•中斷服務，根據該設備的狀態(tài)判斷其是否完全具備維持運營的能力。1)維持服務：指設備雖然存在導致服務能力下降的故障，但仍然可以繼續(xù)向乘客提供服務，如某個攝像頭無法獲取圖像而乘客并不能感受到。2)暫停服務：指設備的故障導致無法滿足乘客需求，但乘客可以選擇其它設備代替或故障可以短時恢復。如站臺某個PIS(乘客信息系統)顯示單元無法開啟。3)中斷服務：指設備的故障導致無法滿足乘客需求，進而導致某個運營服務能力完全失去。如站臺廣播失效需人工喊話。ALM系統需根據設備實時信息自動判斷告警級別并采用不同的方式提供推送或輔助決策，由運營維護人員根據建議處理?？赡艿奶幚矸绞接校汉雎?，不做處理；記錄維修相關信息，在運營后維修；需更換備品備件；緊急搶修。

2．2．2數據處理方式

現場采集的設備狀態(tài)數據非常多，應對這些數據進行過濾、篩選、加工處理，以獲得維修決策的基礎數據。根據不同的管理需求，有不同的數據處理模型，如告警設置、趨勢分析等。1)告警設置：包括限值告警、區(qū)間告警、統計告警、百分比變化告警等。2)設備趨勢分析：是以定量、可視的形式對設備狀態(tài)進行管理，包括檢查設備的狀態(tài)是否處于控制界限之內，觀察設備狀態(tài)的變化傾向或狀況，預測設備狀態(tài)發(fā)展到危險水平的時間，早期發(fā)現設備異常并進行預維修或定修?？刹捎脝沃第厔莘治觥⒄龖B(tài)分布趨勢分析、公式或統計方法趨勢分析等技術。

2．3決策支持

通過采集設備的現場狀態(tài)數據和基于歷史數據的分析，ALM系統可對維修決策提供支撐。按照設備、系統、網絡等不同維度對數據進行統計分析，對指標體系進行梳理，形成通信系統設備的評價體系；通過儀表、圖形、趨勢分析等形式，構建地鐵運營維護平臺的管理“駕駛艙”。

3、ALM系統與維修業(yè)務的結合

典型的設備維修業(yè)務流程如圖1所示。ALM系統主要在故障報告、報修、數據分析環(huán)節(jié)中起關鍵作用。ALM系統在整個維修管理業(yè)務流程中的作用如圖2所示。

篇4

2火車來料信息管理

火車來料信息管理不同于汽車來料信息管理，比汽車來料信息管理要簡單。火車行駛的路線固定，而汽車行駛的路線很隨便。實現火車來料信息管理的重點，在于識別火來運載物料進入企業(yè)時，需正確地識別出每列火車的車廂號碼，并準確的記錄。我們采用應用很廣泛的RFID火車車號識別天線，對火車車廂號碼的識別?；疖噥砹闲畔⒐芾戆▽疖囓囂柕淖詣幼R別、采樣過磅處數據接口的采集、翻車機動作信息的采集等。

3受煤坑卸料控制管理

受煤坑卸料控制管理是對進入受煤坑的汽車，通過螺旋卸料機將汽車運載的原料，卸載在受煤坑上，在打開受煤坑閥門后，通過輸送帶運輸至料場或料倉。

4料場設備控制管理

料場設備控制管理分為兩個主部分：一個是堆取料機控制管理；另一個是無軌機車位置識別及卸料管理。堆取料機控制管理采用千盟專利技術——感應無線車上位置檢測技術，通過在堆取料機、軌道、中控室安裝一套車上位置檢測系統，即可實現堆取料機與中控室之間的數據通信、數據交換等。無軌機車位置識別及卸料管理采用無線及GPS定位技術，通過GPS實現無軌機車在料場區(qū)域的定位，由便攜式PDA實現無軌機車卸料管理，并以無線的方式將無軌機車卸料數據發(fā)送到中控室。系統實現料場的設備控制管理采用兩種不同的通信方式，感應無線通信和工業(yè)無線通信。感應無線是通過鋪設在堆取料機軌道邊沿，由安裝堆取料機上的天線箱發(fā)出頻率，與編碼電纜多處交叉位置產生磁場，而達到識別機車位置。感應無線通信主要實現堆取料機的位置檢測，堆取料機狀態(tài)信號的采集等。無線通信具有通信速率快、數據傳輸安全等優(yōu)點，主要實現汽車卸料數據的傳送、堆取料機堆取數據的傳送等。

5布料設備自動控制管理

布料設備自動控制管理主要是根據采集輸送帶狀態(tài)信息、布料小車狀態(tài)信息、料倉料位信息，并根據布料工藝流程，實現料倉與中控室、布料小車與中控室的相互通信，PLC將所有的信息連接在一起，通過程控的方式，實現布料小車自動操作。

篇5

1．1無線串口透傳模塊為了增加無線傳輸的距離，并改進通信質量和可靠性，采用無線串口透傳模塊E17－TTL100－SMA。其由高性能無線射頻芯片構成，工作的中心頻率為開放的433MHz，供電電壓為1．8～3．6VDC，最大發(fā)射功率高達100mW，接收電流為35uA，休眠模式下的待機電流僅為2．1uA;可以接受串口命令，在空曠的場地最大傳輸距離為1800m;具有標準的TTL接口，收發(fā)雙方相當于連接了一條串口電纜，免去了復雜的通信協議，在命令模式下可設置多種通信波特率。模塊通過串口與控制器STM32F103的USART接口相連，采用默認的9600波特率進行通信交互［7］。從節(jié)能角度考慮，無線模塊在平時會一直處于接收模式。當收到主節(jié)點發(fā)來的指令后，處理先執(zhí)行收到的命令，然后再將模塊設置為發(fā)送模式，把采集到的數據上傳到管理主機。

1．2溫濕度傳感器AM2302由于蔬菜大棚內的作物的光合作用，會蒸發(fā)很多水分，并伴隨產生熱量，導致棚內的溫濕度變化較大，如果控制不好，作物非常容易出現病害，故需要一款高精度和靈敏度的傳感器來完成數據的采集工作。數字溫濕度模塊AM2302是一款含有己校準數字信號輸出的溫濕度復合傳感器，包括1個電容式感濕元件和1個高精度測溫元件，采用3引線連接方式，供電電壓范圍為3．5～5．5V，單總線數據線SDA引腳為三態(tài)結構用于數據的交換和控制均，確保其具有超快的響應和極高的可靠性與抗干擾能力。處理器STM32F103把數據總線SDA拉低至少800μs后，會從休眠模式轉換到高速模式，從數據總線SDA串行輸出40Bit數據，數據依次為濕度高位、濕度低位、溫度高位、溫度低位及校驗位，發(fā)送數據結束后自動轉入休眠模式［8］。

1．3土壤水分傳感器SM2802M由于蔬菜大棚人為對土壤管理措施的不同和土壤本身的各種理化性不同會對土壤含水率產生影響。為更加精準地調節(jié)土壤的含水情況，采用新一代土壤水分測量傳感器SM2802M。它具有工業(yè)級精密核心元件，并利用了世界先進的FDR原理制作而成，可長期埋于土壤中，具有高精度和高可靠的特點。電源電壓范圍為DC12～24V，測量范圍0～100%，測量精度3%FSD，響應時間＜1s，輸出信號4～20mA，分別對應設定的滿量程。通過增加一個10Ω的高精度電阻，則4～20mA就轉換成40～200mV的電壓信號，直接通過處理器STM32F103的ADC口進行數字化后測量。

2輪詢查詢通信與最大通信節(jié)點數

由于系統內的所有節(jié)點都工作在同一個頻率上，為保證通信的可靠性，避免出現干擾或者阻塞，采用了以主節(jié)點為主導的輪詢查詢通信方式。

2．1從節(jié)點輪詢查詢通信方式軟件流程考慮到功耗和通信的可靠性問題，輪詢查詢的發(fā)起者為主節(jié)點，從節(jié)點會一直工作在接收數據模式，直到接收到主節(jié)點對其發(fā)出的指令，才進行工作模式轉換。從節(jié)點的軟件流程如圖3所示。從節(jié)點上電工作后，首先進行系統各功能模塊的初始化，然后將無線通信模塊的設置在接收數據模式，等待主節(jié)點發(fā)送的數據。當接收主節(jié)點發(fā)送的數據時，提取主節(jié)點的發(fā)送目標地址編碼，并與自身的地址編碼進行匹配:如果不是發(fā)給自己的就丟棄，繼續(xù)等待接收數據;如果是發(fā)給自己的，就根據主節(jié)點的對應指令進行處理，處理完畢后將通信模塊設置為發(fā)送數據模式，將數據打包并發(fā)送出去。為了節(jié)能，最后再把通信模式設置為接收模式。

2．2系統最大支持從節(jié)點個數系統支持的最大節(jié)點數N與采集周期T需要滿足關系為其中，Δt為每個從節(jié)點與主節(jié)點之間的通信保護間隔，一般設置為50～200ms;t表示每個從節(jié)點對主節(jié)點發(fā)送指令的處理時間。從式(1)可看出，系統支持的最大節(jié)點數N與采集周期T成正比關系，即當采集周期越大時，支持的節(jié)點數越多。

3上位機管理軟件

監(jiān)控中心的主機上運行著專業(yè)的管理軟件，管理軟件在VisualStudio2013．NET編程環(huán)境下開發(fā)，利用C#語言編寫而成，運行在Window操作系統下;采用SerialPort串口控件實現了與主節(jié)點的串口通信，利用TeeChart繪圖控件實現了數據的實時曲線顯示，并使用Thread類完成了任務的多線程處理，采用數據庫SQLServer2008存儲接收到的溫濕度、土壤含水率和設備狀態(tài)參數等信息。管理軟件具有用戶權限管理、系統參數配置、節(jié)點管理、數據實時顯示、曲線分析、歷史數據查詢、分析預測、報表統計打印、聲光報警與日志管理等。管理軟件結構與功能如圖4所示。管理主機通過USB接口直接與無線透傳模塊相連，接收來自各從節(jié)點的數據，并可下發(fā)控制指令。系統剛投入使用時，需要逐個添加從節(jié)點，并對每個接入系統的節(jié)點進行配置，包括節(jié)點命名、節(jié)點分類、串口波特率、無線頻率、地址編碼、數據的采集周期和報警上下限值等。節(jié)點被加入系統后，會在現實界面統一出現其運行狀態(tài)和采集到的數據值，如果1頁放不下，還會進行自動的滾動顯示。在顯示界面處選中節(jié)點，雙擊或者單擊右鍵會彈出對話框，對話框里包括了該節(jié)點的所有參數，可以對其進行配置，顯示該從節(jié)點所有配置參數，還有該節(jié)點的采集到的實時數據曲線;通過修改顯示的日期時間段，會自動調用數據庫數據，讓歷史數據再現，繪制出每天的均值、最大值和最小值的曲線圖，并可生成月報打印輸出。

4作物生長環(huán)境分析與實驗結果

為了驗證系統的性能和功能，對一個面積為80m×15m的蔬菜溫室大棚進行測試實驗，大棚的作物全部為西紅柿。實驗前，需要充分了解西紅柿在各個生長階段對最佳環(huán)境的要求。

4．1西紅柿最佳生長環(huán)境分析西紅柿屬于喜溫作物，其根系發(fā)達、莖葉繁茂、光合作用旺盛，在整個生長發(fā)育過程中要求較高的土壤濕度和較低的空氣相對濕度。西紅柿的生長主要分為發(fā)芽期、幼苗期、坐果期、果實膨大期和果實成熟期5個階段［9］。1)發(fā)芽期:為保證種子發(fā)芽整齊，需使種子充分吸水膨脹，土壤含水率要達到80%以上，棚內溫度控制在25～30℃，空氣濕度保持在75%～80%。2)幼苗期:由于根系小，吸收力差，不需大量灌溉。土壤含水率以60%～70%為宜，并逐步降低棚溫，加大放風量，白天溫度維持在21～25℃，夜間維持在12～15℃，空氣濕度要求在45%～55%為宜。3)坐果期:最為關鍵，如果濕度過大、通風不及時、溫度太低或太高，都會引起病害，需保持土壤含水率65%～80%，白天溫度控制在25～28℃，夜間控制在13%～15℃，空氣濕度50%～60%。4)果實膨大期:總需水量顯著增多，土壤含水率以80%～90%為宜，空溫度要適當提高，白天26～28℃，夜間15～17℃，空氣相對濕度45%～65%。5)果實成熟期:果實發(fā)育快、植株蒸騰量大、水分供應不足或不及時，都會影響果實的正常發(fā)育，此時要求土壤含水率在80%～85%，白天28～30℃，夜間17～18℃，空氣相對濕度40%～60%。

4．2實驗結果將大棚的土壤水分檢測區(qū)域分為4塊，每塊的面積為15m×20m，并在大棚東西南北的四個墻壁上安裝4個溫濕度監(jiān)控節(jié)點(帶風機)。土壤水分含量傳感器埋入10～20cm土層中，這是西紅柿根系的最發(fā)達的區(qū)域，代表其生長狀況［10］。同時，對棚內的西紅柿的坐果期白天的生長環(huán)境進行監(jiān)測，測得的數據結果如表1和表2所示。由表1可以看出:大棚內白天的溫度控制在25～28℃，濕度控制在50%～60%，且最大和最小值也沒有超出范圍，避免了由于濕度過大、通風不及時、溫度太低或太高引起作物的病害。由表2可以看出:棚內被劃分的4塊土壤含水率的均值、最大值和最小值也均沒有超出預設的范圍(65%～80%)。這表明，該系統能夠自動對這些環(huán)境參數進行智能調節(jié)，且測得的數據準確可靠。

篇6

1.1用戶、終端、網絡的研究

為了研究用戶模型，首先研究用戶如何使用云平臺下的圖書檔案管理系統，用戶接入到圖書檔案管理系統，必須使用終端，通過網絡接入。在這個過程中，終端呈現異構化、復雜化、多樣化的特征，①終端目前可能使用電視網、電信網和計算機網中的任何一網，可以通過WLAN、WWAN、Internet、PLMN、HFC、傳統CATV、Ethernet和OAN中任何一網，隨著時代和科技的發(fā)展也可能使用其他網絡，其網絡方面的特征呈現異構化、多樣化；②終端類型和型號都很多，其功能、用途等明顯不同，造成構造的不同和復雜化；終端和網絡的異構化、復雜化、多樣化，造成了其效果差異化很大，主要體現在：①顯示效果方面；②音效效果方面；③網絡方面；④計算復雜度方面；⑤可用空間方面。從顯示效果的角度來看，需要注意以下幾點：①終端不同，其顯示屏幕的大小不同，從這個角度來說，手機和電視的差距是最為顯著的之一，筆記本、PC等終端設備屏幕往往適中，顯示屏幕大小的不同一方面和用戶持有終端是否便利有關，另一方面關系著用戶瀏覽信息資源時屏幕的尺寸和效果。②終端不同，其顯示所使用的分辨率不同，體現為顯示時的效果明顯不同，如顯示時的清晰細膩程度、拍照取景和視頻播放的效果等等，而且部分終端的分辨率是固定不變的，無法進行調節(jié)。③文件的格式不同，其顯示效果可能不同，例如常見的視頻格式有AVI、MPEG、DIVX、MOV、ASF、WMV、RM等，不同的格式記錄相同的視頻信息，其顯示效果也可能完全不同。④顯示效果的程度決定了用戶視覺角度質量的高低，其對于文本、圖片、圖像、單一的視頻是有決定性作用的，同時對多媒體信息資源的效果也是有一定影響的。⑤顯示效果的程度所帶來的影響，對于不同的用戶是不同的，其高度影響高度依賴視覺的用戶，但當用戶不依賴于視覺的時候影響則不大。從音效效果方面來看，需要注意以下幾點：①終端硬件不同，其發(fā)聲所用的效果不同，即使終端硬件相同其發(fā)聲的效果也可能不同，例如一臺筆記本電腦，如果其聲卡是集成的則往往沒有獨立的聲卡效果好，同樣不同廠商所生產的聲卡效果往往也有一定的差別，不同時間、不同技術所生產的聲卡效果也往往不同，但音效效果在設備、設置、播放內容等完全相同的前提下是一致的。②不同的音頻文件，其效果可能不同，首先數字音頻技術指標采樣率、壓縮率、比特率、量化級，分別控制單位時間內波形采樣的數據數量、音樂文件壓縮前后大小的比值、記錄每記錄音頻數據一秒鐘所消耗的比特值的平均值、用多少位二進制的數據描述的聲音波形；其次，不同的音頻文件格式不同，其音效的效果也可能不同，常見的音頻文件格式有WAV、MP3、WMA、OGG、APE等。③對于部分終端來說，音效效果是可以調節(jié)的，但依然存在音效無法調節(jié)的終端。④音頻效果的程度所帶來的影響，對于不同的用戶是不同的，其高度影響高度依賴聽覺的用戶，但當用戶不依賴于聽覺的時候影響則不大。從網絡的角度來看，①目前大部分的電視網依然是單向的，也就是說存在單向和雙向的問題，雖然隨著時代的發(fā)展和技術的進步，單向和雙向的問題最終會被解決，但是目前一段來說其依然是問題的一部分。②網絡不同登陸方式可能不同，例如如果用戶借助電信網登陸和使用服務有兩種模式，其一是通過以點播為基礎的短信息服務，需要利用短信服務的平臺來傳輸信息，由于其平臺經常是第三方提供的，因而實時性往往較差；第二種方式則是通過GPRS網絡，這種方案的缺點是覆蓋率較差、傳輸速度低、費用高，但可以實現實時。從計算復雜度方面來看，終端之間的差異很大，以電視網的機頂盒和電視機來說，即使運行一個非常簡單的動畫也會非常困難，而相同的困擾在計算機上往往不存在，換句話說計算復雜度高的資源無法在部分終端上運行，但同時部分終端上如果使用計算復雜度低的文件則也會浪費資源。從某種程度上來說，不同的終端適合使用的信息資源在內容、格式等方面是完全不同的。從可用空間的角度看，如果可用空間的大小無法支持對應的操作，則后續(xù)的操作無法進行，同時可用空間較小也會在一定程度上降低運算速度。對于可用空間的大小，不同的用戶可能會有不同的定義，部分用戶可能對終端的最小可用空間有自己的要求；還有一部分人對最小可用空間沒有要求，但是最小可用空間不夠用的時候會有自己期望的行為和操作。

1.2用戶行為研究

用戶的行為，①指用戶使用云平臺下圖書檔案管理系統的行為，其根據用戶的身份、目的、習慣、興趣等不同而不同，用戶可能是進行檢索、獲得、修改、保存信息資源，也可能是對圖書檔案管理系統的管理，如計費等；既包括其行為的種類、參數，同時還應該包括其行為所導致的結果。②用戶的行為受到其本身的制約，既要受到其身份影響，又受到其興趣和目的影響，但最終通過行為表現出來，可以通過用戶的行為獲得用戶的信息，并做出調整，以便更精確地認識和了解用戶。

1.3用戶偏好研究

用戶偏好，指用戶在考慮服務或者商品的時候按照其自身意愿所做出的帶有傾向性的符合理性的選擇，是用戶理性、認知和心理感受權衡后的綜合結論，是用戶個性化的體現。在云計算平臺下的圖書檔案管理系統中，其可以作為個性化服務推薦的基礎，主要包括以下幾個方面的內容，①由終端、網絡等帶來的與視頻、音頻、可用空間等有關的偏好信息，此偏好信息用于確認用戶偏好的信息資源的模態(tài)類信息，在此類偏好中用戶往往偏愛一種或者幾種終端，同時對于不同終端參數設置有不同的偏好；②用戶偏好的信息資源內容方面的信息，包括學科、方向、難度等，這種偏好主要來源于用戶原有的背景如職業(yè)、專業(yè)、知識層次等，并隨著用戶的發(fā)展而改變；③其他偏好，主要包括終端、所途經的網絡、所在的位置等；④用戶ID,用以唯一地標識和區(qū)別用戶。

2用戶模型研究

2.1用戶基本信息模型

根據對用戶、終端、網絡的研究，建立用戶基本信息模型，包括三類信息，分別是用戶信息、終端信息和網絡信息（詳見圖1）。其一是用戶信息如用戶ID、姓名、身份、年齡、知識層次、密碼、密碼提示問題、組別，其中①用戶ID、密碼是不可以省略的，其需要在用戶登陸的時候確定用戶的基礎信息，同時用戶ID對于整個系統來說是唯一的，也就是說所有用戶的ID是沒有重復的，是“獨一無二”的；②身份、年齡、知識層次三項可以用于輔助確定用戶的身份，以便在后續(xù)用戶偏好模型未獲得具體信息之前初步判斷和獲得用戶的偏好信息，但鑒于部分用戶的特殊性某些情況下是允許被省略的；③用戶信息可以通過組別確定用戶的權限的確認。其二是終端信息包括終端ID、終端參數等，其中①終端ID用于確定接入和登陸到圖書檔案系統的終端的身份，通過檢索對應于終端的數據表可以獲得包括其使用者、終端的類型、終端的基本參數及范圍、終端的可能配置等的信息，可以初步確定終端的信息；②終端參數包括的是顯示參數、音效參數、計算復雜度參數、可用空間參數，顯示參數和音效參數分別是用戶提供的其習慣使用的顯示、音效參數的設置，而計算復雜度參數需要通過終端ID判斷用戶終端的具體計算復雜度獲得，可用空間則需要在圖書檔案系統運行的時候通過其與終端之間的通訊獲得；③終端信息中終端ID是不可以缺省的，但終端參數是可以缺省的，在缺省的狀態(tài)下，系統依然可以通過終端ID獲得終端的類型及基礎的參數范圍，再根據參數范圍進行其他的判斷，同時由于計算復雜度參數和可用空間參數不需要用戶提供，因而也可以在缺省的情況下獲得。其三則是網絡信息如網絡類型、常見位置等，其中①電視網的單雙向問題可能會帶來新的問題需要給予重點關注；②常見位置，是用戶通常使用終端接入和使用圖書檔案管理系統服務的位置；③網絡ID，用以唯一地標識和區(qū)別網絡。關于用戶基本信息模型，需要注意的有：①用戶基本信息模型雖然是由三個部分組成的，但是其是一個整體，可以通過數據庫表示出來，其中的每一條記錄都只說明的是在某一種情況下用戶使用某種終端通過某種網絡接入和使用圖書檔案管理系統的具體設置以及由此而來的各種參數，每個用戶的具體信息可以不只一條而是若干條記錄的組合。②用戶基本信息模型的三個子模型，可以通過一個數據表體現，也可以分成用戶信息表、終端信息表、網絡信息表三個數據表的組合來實現。

2.2用戶行為模型

用戶行為模型，主要用于記錄用戶的行為、狀態(tài)等信息，其由用戶ID、用戶行為、行為參數、狀態(tài)參數三個部分組成，其中①用戶的行為用于記錄用戶狀態(tài)變化的原因，同時可以從中獲得用戶基本信息模型的部分信息，同時也可以完善用戶偏好模型；②用戶行為參數用于說明用戶行為的細節(jié)，是用戶行為有機的補充；③狀態(tài)參數，用于表明經過用戶的行為之后用戶的變化。

2.3用戶偏好模型

用戶偏好模型是用戶服務推薦的基礎，其主要包括3個方向，其一是對所獲取資源的模態(tài)傾向性，是與終端相關的，其中包括格式、顯示性能、音效性能等,其大多數屬性是范圍；其二則是對信息資源內容的傾向性，主要包括用戶的身份、年齡、知識層次、專業(yè)等；其三則是用戶通常所在的位置區(qū)域，可以用于以就近原則對其提供服務。

3關鍵技術分析

3.1用戶模型應用研究

從用戶登陸并使用系統服務的角度看用戶模型，用戶通過終端接入計算機網、電信網和電視網三網中的一網，可以利用一體化標識網絡技術連接到系統，通過終端ID確定終端的身份（終端信息模型），通過終端所在的位置、IP等可以獲得對應的網絡信息（網絡信息模型），通過用戶ID和密碼登陸系統進而系統可以確定登陸的用戶（用戶信息模型），如果需要調用用戶偏好模型可以根據用戶ID在用戶偏好模型中檢索相應的記錄則找到對應用戶偏好的信息（用戶偏好模型），用戶使用過程中會有所操作記錄下用戶ID、相關操作及對應參數則可以將信息添加到用戶行為模型，根據用戶ID可以從用戶行為模型獲取相關的參數則可以獲得對應信息據此可以修改和完善其他模型。對于用戶模型的應用，本文認為：①對于信息資源的檢索和使用，既涉及到用戶對信息資源模態(tài)的偏好，又要涉及到用戶對信息資源內容的偏好，同時還涉及到用戶所使用的終端；在檢索的時候首先要根據終端信息模型和網絡信息模型判斷終端和網絡的特性，獲得支持的模態(tài)的信息，獲得顯示、音效、網絡、計算復雜度、可用空間等信息，再根據這些信息和模態(tài)結合結合用戶的偏好以集合的形式進行交的運算進而縮小可以接受的信息資源的模態(tài)范圍并將其作為用戶即時信息資源模態(tài)的偏好，再通過用戶偏好模型內容傾向類偏好可以獲得用戶對信息資源內容的偏好。②顯示、音效、網絡、計算復雜度、可用空間等的變化會帶來很多不同的情況，需要形成對應的策略，該策略既要符合用戶的意愿，又要符合運營商等商家的利益，同時必須符合法律法規(guī)并受到相關部門的監(jiān)管。在實踐的過程中，可以設置相應的閾值來劃分對應的范圍，根據閾值與當前值差別的組合來判斷當前所處的情況，當差距過大或者達到閾值的時候可以按照對應的既定策略采取行動，如在許可的情況下重新生成對應的信息資源、只發(fā)送部分信息資源、壓縮等。③用戶基本信息模型中用戶信息模型、終端信息模型和網絡信息模型需要相互結合，是一個有機的整體，在使用的時候相互輔助；同時用戶基本信息模型、用戶行為模型和用戶偏好模型也是一個有機整體，其通過用戶ID彼此關聯。用戶ID在整個模型中是唯一的，其作用是唯一地標識一個用戶，以便與其他用戶區(qū)別。

3.2用戶模型的初始化與完善

本文認為用戶模型的初始化信息可以從以下幾個方面獲得：①用戶注冊的信息②利用調查研究等方式從側面獲得的用戶信息；③利用公眾的大眾化特征獲得，其實質是首先獲得用戶基礎信息模型，然后再從用戶基礎信息模型獲取數據，以基礎信息模型數據為基礎結合概率歸類和整理，去生成用戶偏好模型和用戶行為模型的初始數據。本文認為用戶模型的信息完善與補充，是一個不斷學習和修正的動態(tài)反饋過程，通過機器學習對參數的重新估計和修正提高了預測的精度，進而提高服務的質量，可以為個性化服務推薦打下基礎。其實質是通過訓練來逐漸完善用戶行為模型，再根據用戶行為模型逐步完善用戶基礎信息模型和用戶偏好模型。具體的實現上，本文認為①用戶行為模型可以作為執(zhí)行單元，學習單元通過用戶行為模型提供的信息根據用戶基本信息模型和用戶偏好模型建立并改進知識庫，執(zhí)行單元格局知識庫中的知識執(zhí)行任務，再將執(zhí)行后的信息反饋到用戶行為模型作為下一步學習的資源。②可以用命令序列作為最小單元描述用戶行為，通過定義兩個序列、兩個狀態(tài)之間的相似度來代表和判斷行為模式之間、狀態(tài)之間的相似程度；模型工作的時候，計算序列相似度來判斷行為和狀態(tài)的變化。

篇7

系統數據處理模塊實現對節(jié)點信息的封裝/拆封處理、消息應答和收發(fā)規(guī)則處理以及對數據的過濾與管理。主要完成對節(jié)點加入網絡的消息、網絡管理類消息和節(jié)點網絡信息的實時處理，確保網絡監(jiān)視和管理的時效性。

1．2節(jié)點信息顯示

系統顯控模塊對網絡中的節(jié)點信息要實時更新顯示。網絡節(jié)點通過對信息的圖形化、形象化和逼真化顯示，便于網絡管理者和網絡參與節(jié)點直觀地了解、分析和判斷網內各節(jié)點狀態(tài)。系統將節(jié)點信息進行解析后實時顯示網內節(jié)點的網絡責任、指揮控制信息、位置信息、通信狀態(tài)等信息。

2系統實現

2．1系統與網絡

網絡是由多個節(jié)點組成的，每個節(jié)點都配有數據源真實設備和網絡監(jiān)視管理系統終端，每個系統終端又將節(jié)點信息處理模塊和節(jié)點信息顯示模塊分開設置在兩臺任務計算機執(zhí)行。模塊之間、終端與數據源真實設備之間均通過以太網進行數據傳輸，節(jié)點之間采用射頻網絡進行信息的交互，如圖1所示。圖1系統結構

2．2關鍵技術

2．2．1節(jié)點狀態(tài)監(jiān)視原則

網絡監(jiān)視管理系統監(jiān)視的對象為當前網絡內所有的在網節(jié)點，掌握各節(jié)點的狀態(tài)變化情況從而動態(tài)監(jiān)視當前網絡的運行狀態(tài)。系統從數據源設備周期上傳的節(jié)點網絡信息中提取出當前在網節(jié)點的狀態(tài)信息，并對在網節(jié)點周期性上傳的狀態(tài)信息進行解析分類，然后更新原有的節(jié)點狀態(tài)信息。對超過設定時間長度仍未上傳網絡狀態(tài)信息的節(jié)點判定為脫離網絡，并變更其網絡狀態(tài)予以警示。

2．2．2特殊節(jié)點身份確定和轉移

網絡監(jiān)視管理系統中需要指定一些特殊節(jié)點作為網絡中重要責任的擔任者。這些節(jié)點擔任的角色可能是網絡中的某種基準或網絡信息傳播過程中的中轉站，不同的角色所需選取的節(jié)點具有不同的準則，要綜合考慮節(jié)點的存在形態(tài)(固定節(jié)點或移動節(jié)點)和節(jié)點的傳播能力等要素來確認某一節(jié)點是否適合擔任網絡內的重要責任。當特殊責任節(jié)點脫離網絡后會導致網絡的運行障礙，這就要求網絡管理者在網絡設計中或網絡運行伊始就要預先指定替補節(jié)點，選取原則應盡量與原角色相似。當網絡監(jiān)視到特殊節(jié)點脫離網絡后就可以由替補節(jié)點繼續(xù)承擔相應的網絡責任，維持網絡的正常的運行。

2．2．3信息的圖形化顯示

網絡監(jiān)視管理系統呈現給使用者的顯示界面上應對各類節(jié)點的信息進行分類顯示。數據源設備周期上傳的節(jié)點狀態(tài)信息量龐大且內容繁雜，而使用者關心的是一些關鍵點信息，并希望能對關鍵點信息進行分類匯總，從不同角度了解當前節(jié)點構成的網絡狀態(tài)。除此之外，對使用者關注度較高的信息種類還應進行展開顯示，便于對特殊信息的進一步細致了解。

2．2．4注冊和身份識別

網絡監(jiān)視管理系統必須通過注冊認證才能運行，對每個運行系統的終端綁定唯一的注冊碼，保證了系統使用范圍的確定性。系統的使用對象主要分為網絡管理者與網絡參與者兩大類，對于網絡管理者不僅賦予對全網的狀態(tài)監(jiān)視權，還同時承擔網絡的管理責任;對于網絡參與者僅有網絡查看監(jiān)視權，無權對其他網絡節(jié)點進行管理。

2．2．5動態(tài)鏈接庫

網絡監(jiān)視管理系統是基于LINUX操作系統開發(fā)完成的，其采用QT作為界面開發(fā)框架，QT是一個用C++編寫的、成熟的、跨平臺的GUI工具包，支持動態(tài)鏈接庫工程。系統中的節(jié)點信息顯示就是將其界面以動態(tài)鏈接庫的形式嵌入到其他通信軟件的界面中。在LINUX系統下的動態(tài)鏈接庫編譯后生成的是后綴名為．so的到共享庫的鏈接文件，主調工程需要包含動態(tài)鏈接庫工程的所有頭文件和所有到共享庫的鏈接文件后方可使用動態(tài)鏈接庫工程里的文件。動態(tài)鏈接庫將類的整體作為一個EXPORT進行封裝打包，可以把其想象成一個大的信封，信封里定義各種類及函數，但是它的初始類型只作為一個大的容器，不具有QT的基本信號槽機制和事件觸發(fā)機制。

2．2．6多線程通信

在系統進行節(jié)點信息處理時，需要涉及到多線程通信。在Linux系統中，線程的調度是由內核來完成的，每個線程都有自己的編號，由于在使用線程的軟件項目中，總體消耗的系統資源比較少，加之線程間相互通信比較容易，因此采用該方式完成節(jié)點信息處理可以提高系統的信息處理速度。QT有一個線程類叫做QThread，一般需要啟用多個線程通信時會從QThread繼承一個類，并重新實現QThread中的run函數，將其填寫所需功能代碼。依靠QT的信號槽機制完成子線程向主線程的數據傳遞，在所繼承的線程類里定義一個信號函數，然后讓它在run函數中被觸發(fā)，并且在主線程里定義一個負責接收子線程數據的槽函數，在主線程里對這對信號和槽進行關聯，這樣信號觸發(fā)時，槽函數就會響應，相應的就把子線程的數據傳遞給了主線程。

2．2．7遠程信息掛載

一般LINUX系統下的開發(fā)流程是在開發(fā)機上完成源碼開發(fā)，編譯后將可執(zhí)行程序通過網口或其他途徑拷至目的機上運行即可。但在實際開發(fā)中可能存在以下開況:開發(fā)機與目的機CPU架構不同;出于保密需求不允許將開發(fā)機源碼拷至目的機編譯。若開發(fā)機為X86架構而目的機為PowerPC架構，二者架構不同在開發(fā)機上編譯后的可執(zhí)行程序便無法在目的機上運行;在這種情況下若還不允許將開發(fā)機中的源碼拷至目的機編譯生成可執(zhí)行程序，那么可以考慮的解決方法便是將開發(fā)機作為硬盤掛載于目的機，允許目的機訪問開發(fā)機上的某個指定文件夾，對文件夾內的源碼進行編譯，在開發(fā)機上生成適用于目的機的可執(zhí)行程序，再由開發(fā)機將可執(zhí)行程序拷至目的機。

3系統監(jiān)控指標

對網絡監(jiān)視管理系統而言，根據設計的系統監(jiān)測指標體系，數據處理和評估的內容如表1所示。網絡監(jiān)視管理系統的監(jiān)視功能可以實時監(jiān)控當前網內節(jié)點的數目，從而可以統計監(jiān)視網內節(jié)點的在網率;系統對在網節(jié)點的網內時間長度和它脫離網絡的時間長度進行統計;通過對節(jié)點狀態(tài)信息的實時更新監(jiān)控當前網內節(jié)點的實時位置信息和網絡責任擔任情況，如經緯度、高度等信息;系統對當前在網節(jié)點的組織關系實時更新和監(jiān)控，指揮者可以及時了解各組織結構下的網絡節(jié)點分布情況;網絡監(jiān)視管理系統在管理功能中主要可以監(jiān)控的指標是所有網絡管理消息的發(fā)送情況及網內節(jié)點對指令的執(zhí)行應答情況。

篇8

水利施工工程，施工過程較復雜，需要很多種類的工種相互配合。比如土建、鋼筋、高空作業(yè)、爆破、防水、水下作業(yè)等技術工作和特殊工作。在水利施工工程中，對施工班組安排，交叉并且復雜，如果不好好對現場進行管理，則很容易使管理與施工陷入混亂的狀態(tài)。一旦管理混亂，那么對工序的安排則會出錯，班組之間在施工過程中就會發(fā)生沖突等等問題就會接二連三的出現，進而對施工的質量與進度產生負面影響。這種由于人員冗雜，帶來的難以管理的問題，需要進行水利施工管理的單位或者部門對班組關系進行一個有序且高效的樹立，對公共順序等方面進行合理的安排，這就對水利施工建設在此方面提出了高于一般工業(yè)建筑的要求。

1．2危險性高

在水利施工過程中，存在很多為危險因素［1］。一方面在水利施工過程中，爆破、隧道開挖、水下作業(yè)、高空作業(yè)等本就是危險系數極高的作業(yè)工種，其危險因素在于不僅是本身就具有高危險性，如果管理和監(jiān)督上出現微小的失誤也會帶來極大的危險性。另一方面是由于其所處地理環(huán)境的特殊性，水利施工建設工程在選址是多選擇偏遠、交通不便的地區(qū)，因此醫(yī)療衛(wèi)生條件有限，如果在水利施工過程中不慎發(fā)生安全事故，或者在運輸過程中發(fā)生交通事故，那么對于人員救治相對而言就會比較困難，因而水利施工過程中的安全管理安全管理是其十分突出且受到國家相關部門高度重視的一個環(huán)節(jié)。

24D施工管理系統應用

2．1實行進度管理

通過4D施工管理系統對水利工程項目施工進行4D施工過程模擬中，可以動態(tài)管理施工進度。水利工程管理人員可以控制和調整施工進度，圖形界面中的4D模型會隨著系統中的施工進度計劃的修改，而發(fā)生變化，之后統計結果與4D顯示圖像會自動更新。4D進度管理包括對比進度、調整計劃、進度追蹤以及進度分析等功能。進度對比是指將錄入的施工實際進度信息，與計劃進度對比分析。實際進度和計劃進度的不同對比情況用不同顏色的圖形表現，具體包括未輸入、準時、推后以及提前四種狀態(tài)，使施工進度一目了然。進度調整則是通過連接項目管理系統，遠程調整進度計劃，從而改變圖形界面中的4D模型。進度追蹤功能可以按照規(guī)定的日期，跟蹤工程的施工段或WBS節(jié)點的進度計劃執(zhí)行情況，并且可以根據計劃和實際百分比進行統計［2］。進度分析功能自動統計規(guī)定時間段內施工進度的詳細信息，并用列表的方式將施工段的具體狀態(tài)表現出來，用圖與數字的形式對不同狀態(tài)的施工段的進行統計。

2．2進行過程模擬

將4D施工管理系統應用在水利工程項目施工中，可以用動態(tài)的三維模型將水利工程的實際施工情況以及進度展現出來，使其形成4D動態(tài)模擬。工程管理人員可以通過直接控制4D模擬過程，將具體的天、周、月設定為為時間單位［3］，并以此為依據對施工進度進行順序以及倒序模擬。三維視圖中不同的施工狀態(tài)用不同顏色的模型代表，用指定的WBS顏色顯示已完成的構件。工程管理人員可以通過4D施工過程模擬，了解水利施工各個階段詳細施工情況?？梢员容^各種施工方案，最終選擇操作性較強的施工方案。

2．3管理動態(tài)資源

通過應用4D施工管理系統可以將水利工程項目的資源需求、三維模型以及施工進度相結合，從而在施工過程中實現對消耗資源進行動態(tài)管理。動態(tài)資源管理是指材料人力、以及器械的管理和工程量統計［4］。人力、材料以及器械的管理功能可以自動計算水利工程項目的人力、材料以及器械的消耗量和成本，并可以將資源在不同的施工階段的需求計算出來。工程量統計功能可以通過施工的實際進度和計劃進度準確計算出施工單元、各個WBS節(jié)點以及整個工程的工程，最后采用統計圖的方式將其完成情況進行分析和統計。

2．4查詢施工屬性

4D施工管理系統運用在水利施工過程中可多個施工屬性進行查詢，水利工程項目的管理人員可以通過其收集施工過程中的相關信息，比如資源、質量、進度等進行綜合分析進而實現統一管理。其具體有以下幾個功能［5］:對于水利施工工段或者構件，可先在建立的3D模型中選擇出來，并在視圖中進行放大，并且可采用多視角進行三維瀏覽;對于3D模型可以通過不同的角度和不同的試圖對進行全方位查看;對于施工項目的詳細信息，可以通過分析WBS節(jié)點、施工段等，對其進行進行實時查詢，詳細信息具體包括資源用量和成本、質檢表、施工單位、施工時間、施工工序、工程量以及結構類型等。通過對施工信息和工程構件的實時查詢，從而實現對水利工程項目施工的可視化管理。

篇9

1．1數據處理模塊開發(fā)數據處理模塊是服務器端開發(fā)的核心，其負責接受設備端發(fā)送的數據并將數據及時更新到數據庫，同時向設備端發(fā)送數據。數據處理模塊還負責與移動終端建立連接。移動終端主動向數據處理模塊發(fā)送指令，其接收到指令后對其解析并根據指令向移動終端返回相應的數據包，采用客戶／服務器通信模式，如圖5所示。數據處理模塊要求能同時為多個設備端提供服務，并且對每個設備端做出快速的響應，故要求其具有較高的并發(fā)性能。此外在通信的過程中，ServerSocket的accept（）方法和Socket的read（）方法都有可能使運行過程中發(fā)生阻塞。當與多個設備端同時通信時，就必須開啟多個線程，就有可能發(fā)生多個通信線程阻塞，而且線程的多少與服務器的并發(fā)能力有如圖6所示。由圖6可以看出線程數目達到一定值反而會降低系統能力，原因是較多的線程會消耗很多系統資源，加大了系統的管理難度，且對于開啟最優(yōu)線程數目不易把握，故需對系統的并發(fā)能力進行優(yōu)化。本模塊在反復調試的基礎上采取JDK類庫提供的線程池和java．nio包提供的非阻塞通信機制實現系統的開發(fā)。在多設備端請求連接時，開啟兩個線程，一個線程負責與設備端的連接操作，另一個線程專門負責數據的接受和發(fā)送操作。負責連接的線程采取阻塞的工作模式，當有設備端連接時，就向Selector類注冊讀就緒和寫就緒事件，沒有連接就進入阻塞狀態(tài)，直到有新的連接請求。負責收發(fā)數據的線程采用非阻塞的工作模式，當讀寫就緒事件發(fā)生時就執(zhí)行相應的讀寫操作［7］。

1．2Web服務器和MySQL數據庫的搭建Web服務器是基于網站架設的服務器，主要作用是提供網上信息瀏覽服務，只需打開瀏覽器向Web服務器發(fā)送指定鏈接便可在線查看橫機信息，本系統使用Apache開源軟件組織的Tomcat進行服務器端的配置開發(fā)。Tomcat服務器是當今進行JavaWeb開發(fā)使用最廣泛的Servelt／JSP服務器，因為它運行穩(wěn)定，性能可靠。結合Java語言強大的網絡功能開發(fā)出B／S架構Web服務器，Web服務器也能夠操作后臺數據庫。B／S架構的通信原理是基于應用層的HTTP協議實現的，HTTP是一種請求／響應式的協議。客戶端向服務器端發(fā)送請求（在瀏覽器地址欄輸入鏈接網址），服務器返回響應。HTTP協議嚴格規(guī)定了HTTP請求和HTTP響應的數據格式，其請求包括：請求方法，URI，HTTP協議的版本，請求頭，請求征文；響應包括：HTTP協議的版本，狀態(tài)代碼，描述，響應頭，響應正文［8］。MySQL是一個關系型數據庫管理系統，可以將數據分類保存在一張張表中，并且其體積小、運行快、具有較高的查詢速度，故本系統選擇MySQL數據庫保存橫機信息。

1．3遠程監(jiān)控終端的開發(fā)隨著Android智能手機的普及，開發(fā)手機端的軟件監(jiān)控橫機生產更加方便快捷，手機APP與服務器端采用C／S架構的通訊模式，服務器根據手機APP發(fā)送的請求標志返回相應的數據，這樣便可隨時隨地在手機端查看橫機數據。Android智能手機分辨率眾多，移動端監(jiān)控APP必須要適應多種分辨率的手機設備，其編程思想是：首先利用WindowManager獲取手機屏幕的分辨率的高和寬，然后根據分辨率在各個界面上采取相應的比例繪制界面布局，并將從服務器端獲取的參數顯示到相應的位置。

2通信協議開發(fā)

采用TCP／IP協議與服務器端數據處理模塊進行通信，通過Socket編程，將橫機的運行狀態(tài)和編織的花型數據以字節(jié)的方式發(fā)送到數據處理模塊。該模塊采用多線程機制不斷地接受客戶端的連接請求并將接收到的數據寫入后臺數據庫。通訊數據包主要字節(jié)的定義如表1所示。其中，包頭標志符由系統固定為某一值，作為驗證該數據是否安全的標志，驗證通過服務器端才能接受此包數據；包長度表示一個包的長度；包命令字是核心內容，支出這一包數據的功能。包命令字的定義見表2。

3系統調試

本系統在杭州與非科技有限公司提供的橫機控制器上進行測試。在設備端設置CNT文件的參數如圖7所示，然后將參數通過網絡發(fā)送到服務器端，服務器端的數據處理軟件接收到數據后，將其保存到后臺數據庫的相應的表中，通過查看數據處理軟件的CNT界面（如圖8所示），可以看出服務器端已成功的接收到設備端發(fā)送的數據。在手機端監(jiān)控軟件能夠實時獲取橫機運行參數數據，系統基本達到橫機生產控制的預期效果。

篇10

單位管理包括設備制造單位、設備使用單位及設備安裝單位管理，目的是為了將檢驗相關單位的信息統一管理并可以為以后各檢驗相關系統提供基礎統一的信息來源。單位管理記錄所有單位信息，主要包括單位代碼、單位名稱、地區(qū)代碼、上級主管單位、單位地址、郵政編碼、所屬國家、聯系人／主要負責人、聯系電話以及電子信箱，其中單位代碼用于規(guī)則號生成。

1.2設備管理

設備管理包括檢驗設備管理和管道設備管理。檢驗設備有一套標準的管理規(guī)范，出檢人員到設備庫提取設備到現場檢驗，并在檢驗報告中注明檢驗使用的設備相關標識，在信息系統中如何保持與現實設備狀態(tài)一致至關重要，檢驗設備管理就可以提供一個統一的設備狀態(tài)設置功能，以避免填寫報告時人工誤錄非正常狀態(tài)的檢驗設備，避免在質量監(jiān)管過程中產生不必要的麻煩。檢驗設備管理包括檢驗設備的基礎信息維護、設備狀態(tài)的維護、檢驗過程中對檢驗設備的選擇和查詢等功能。管道設備管理包括管道類型管理、管道信息管理，所有檢驗中涉及到的管道全部納入到管道設備管理庫中。

1.3檢驗員資質管理

系統維護檢驗員、高級檢驗員等資質人員的信息，以供信息系統中出具報告時能自動匹配到相關檢驗員資質，避免出具不符合規(guī)范的報告，并統一管理人員資質，對相關資質期限給予提醒，更有助于檢驗業(yè)務的信息化工作。檢驗員資質管理包括檢驗員分類維護、檢驗員信息維護、資質相關信息維護、資質到期提醒、資質信息查詢及資質信息使用等。

2管道安裝監(jiān)檢管理模塊

根據《壓力管道安裝安全質量監(jiān)督檢驗規(guī)則》，首先由管道安裝單位辦理開工申請，其次監(jiān)察部門審核資料出具受理單，然后檢驗機構根據受理單安排具體檢驗工作。管道安裝監(jiān)檢涉及到使用單位、檢驗機構、政府監(jiān)察部門3個單位，信息量大，手續(xù)繁瑣。本系統中設置了監(jiān)察部門、檢驗機構、使用單位3種角色，根據角色開放不同的權限，配置不同的頁面。安裝監(jiān)檢申請信息包括管道級別、申請單位組織信息等基礎信息，可通過組織機構檢索使用已錄入組織，也可添加新的單位組織信息，上傳申請材料信息及相關指標信息。如果選擇已錄入工程單位，要素會自動帶入對應工程單位信息。相關檢驗信息進入流程后，在不同的流程節(jié)點對相應的審批者開放對應的可填寫要素。

3管道在用檢驗管理模塊

根據《壓力管道使用登記管理規(guī)則》，在用壓力管道應定期檢驗，確定安全狀況等級。本系統根據上次檢驗結果和下次檢驗時間設置到期檢驗自動提醒功能，如果管道使用單位未能如期網上報檢，則系統會自動以短信和郵件通知使用單位聯系人。檢驗機構受理使用單位的網上報檢申請，并將受理情況和檢驗安排生成檢驗工作通知單發(fā)送到網站和使用單位。使用單位根據通知單上的編號可在檢驗網站上查閱應檢管道的基礎信息，跟蹤檢驗步驟，查詢檢驗結論等信息，第一時間了解管道的安全狀況。

4管道監(jiān)察統計分析模塊

目前壓力管道檢驗檢測機構擁有大量的檢驗、檢測數據和檢維修記錄，但由于缺乏系統的綜合統計分析功能，致使許多有用的信息不能充分地為企業(yè)生產和安全監(jiān)察部門服務。例如，對于影響壓力管道系統安全的薄弱環(huán)節(jié)不明確，在壓力管道數量多、檢測難度大的現實條件下，有限的檢驗費用和檢驗力量無法應用于真正影響壓力管道運行風險的主要部位，從而使檢驗結果對安全運行的影響作用下降，法定的定期檢驗變成了完成國家規(guī)定檢驗指標或應付任務。本系統的監(jiān)察統計分析模塊根據時間段、完成情況，按照流程環(huán)節(jié)對安裝、在用、改造分別進行統計，并生成統計結果，為監(jiān)察部門和管理部門提供準確的壓力管道安全監(jiān)察技術統計信息。