郭榮佐，黃 君

(1.四川師范大學(xué) 計算機(jī)科學(xué)學(xué)院，四川 成都 610101； 2.四川工商職業(yè)技術(shù)學(xué)院 經(jīng)濟(jì)管理系，四川 都江堰 611830)

0 引 言

鉆井工程是涉及到諸多主題和大量數(shù)據(jù)的一種技術(shù)密集型的工程。鉆井?dāng)?shù)據(jù)進(jìn)行實(shí)時采集、通信和管理，對鉆井企業(yè)而言，可提高鉆井效率和降低鉆井成本而提高企業(yè)利潤。而隨著信息和通信技術(shù)(information and commu-nication technology，ICT)的發(fā)展和應(yīng)用，各類鉆井平臺也應(yīng)采用信息和通信技術(shù)進(jìn)行裝備，以實(shí)現(xiàn)鉆井現(xiàn)場數(shù)據(jù)的實(shí)時采集。在ICT中的物聯(lián)網(wǎng)及其感知技術(shù)，為鉆井平臺的數(shù)據(jù)采集提供了新的發(fā)展契機(jī)。對鉆井平臺進(jìn)行隨鉆和井場的實(shí)時數(shù)據(jù)采集，可實(shí)時掌控鉆井時的各種工況，對提高鉆井效率和保障安全生產(chǎn)等具有重要意義。

對鉆井及其平臺的數(shù)據(jù)采集進(jìn)行研究，國內(nèi)外研究者們已有相關(guān)研究成果。文獻(xiàn)[1]利用ZigBee技術(shù)，并結(jié)合CAN總線，實(shí)現(xiàn)對空氣鉆井監(jiān)測系統(tǒng)進(jìn)行設(shè)計與實(shí)現(xiàn)。文獻(xiàn)[2]利用鉆井現(xiàn)場的傳感器進(jìn)行現(xiàn)場數(shù)據(jù)采集，主要就數(shù)據(jù)采集管理系統(tǒng)進(jìn)行了研究，但該文獻(xiàn)對鉆井現(xiàn)場感知部分，僅簡單進(jìn)行了描述，而對如何感知、怎么采集的硬件部分未進(jìn)行描述。文獻(xiàn)[3]利用“互聯(lián)網(wǎng)+”，對鉆井平臺進(jìn)行設(shè)計，并對信息流和能量流進(jìn)行優(yōu)化。文獻(xiàn)[4]對鉆井平臺自動化和自動節(jié)流管匯進(jìn)行了設(shè)計，對鉆井現(xiàn)場數(shù)據(jù)采集與分析具有很好的參考價值。文獻(xiàn)[5]對鉆井進(jìn)行更加有效的監(jiān)控，設(shè)計一種具有無線測井的鉆井監(jiān)控系統(tǒng)，并結(jié)合無線傳感器技術(shù)和相關(guān)測量技術(shù)，實(shí)現(xiàn)無線測井。文獻(xiàn)[6]對石油鉆井?dāng)?shù)據(jù)管理進(jìn)行研究，提出了基于數(shù)據(jù)分發(fā)服務(wù)技術(shù)的石油鉆井?dāng)?shù)據(jù)管理優(yōu)化解決方案，且該方案基于實(shí)時數(shù)據(jù)管理的服務(wù)質(zhì)量。這些研究，幾乎都是應(yīng)用ICT于鉆井工程，為進(jìn)一步研究鉆井平臺數(shù)據(jù)采集，提供了有益的參考，但鉆井平臺一般置于野外，若采用有線方式進(jìn)行數(shù)據(jù)采集，勢必帶來如安裝維護(hù)難、攜帶不便和成本高等缺點(diǎn)。

雖有文獻(xiàn)采用無線方式進(jìn)行數(shù)據(jù)傳輸，但未考慮無線方式和本地化管理等的服務(wù)質(zhì)量問題；亦有文獻(xiàn)從數(shù)據(jù)管理的角度研究鉆井管理信息系統(tǒng)的服務(wù)質(zhì)量，但未針對隨鉆和井場數(shù)據(jù)采集端的服務(wù)質(zhì)量問題。因此，利用物聯(lián)網(wǎng)及其感知技術(shù)，設(shè)計一種隨鉆和井場進(jìn)行實(shí)時數(shù)據(jù)采集和無線傳輸?shù)你@井平臺數(shù)據(jù)采集系統(tǒng)，并對感知節(jié)點(diǎn)、網(wǎng)關(guān)和監(jiān)控主機(jī)的軟件進(jìn)行設(shè)計，同時對軟件的QoS(quality of service)進(jìn)行基于虛擬化感知即服務(wù)理念的優(yōu)化與仿真。

1 系統(tǒng)總體架構(gòu)

對鉆井平臺，需要采集的實(shí)時數(shù)據(jù)較多，如隨鉆數(shù)據(jù)采集、井口數(shù)據(jù)采集和鉆井機(jī)數(shù)據(jù)采集等等。本系統(tǒng)主要完成鉆井平臺的數(shù)據(jù)采集，主要包括隨鉆數(shù)據(jù)采集、井口各種監(jiān)測數(shù)據(jù)采集和鉆井機(jī)監(jiān)測數(shù)據(jù)采集。其系統(tǒng)總體架構(gòu)如圖1所示。

圖1 系統(tǒng)總體架構(gòu)

隨鉆感知是通過圖1中的隨鉆傳感器節(jié)點(diǎn)予以實(shí)現(xiàn)，以采集隨鉆數(shù)據(jù)。隨鉆數(shù)據(jù)采集部分，主要通過隨鉆傳感器，采集井里的瓦斯氣體濃度、溫度、濕度、氧氣，還對鉆井液體積、密度進(jìn)行采集。隨鉆感知到的數(shù)據(jù)，由于井位于地下或其它較為深遠(yuǎn)的山、海下，其傳輸只能采用現(xiàn)場總線，現(xiàn)場總線將數(shù)據(jù)傳輸?shù)骄?，再由鉆井現(xiàn)場的總線轉(zhuǎn)ZigBee協(xié)議的設(shè)備進(jìn)行無線化。

由圖1可知，井口也需要采集數(shù)據(jù)，以便對鉆井平臺進(jìn)行完整的檢測，進(jìn)而實(shí)現(xiàn)有效控制和精準(zhǔn)操作[7]。井口主要采集的數(shù)據(jù)可分為吊鉆大鉤壓力數(shù)據(jù)、排沙管通暢程度、儲沙池中沙漿高度、壓縮空氣進(jìn)入管道的氣壓、環(huán)境溫度濕度和立體主循環(huán)管道的暢通程度等。同樣，鉆井機(jī)及附屬也需要進(jìn)行數(shù)據(jù)采集。對鉆井的數(shù)據(jù)采集主要有發(fā)動機(jī)的轉(zhuǎn)速、功率、帶動鉆桿的轉(zhuǎn)動扭矩和油箱油量等；對鉆井井場的空壓機(jī)，也需要進(jìn)行數(shù)據(jù)感知與采集，主要采集排氣的溫度、空氣儲罐的溫度與壓力和管道的流量等。井場的數(shù)據(jù)感知，采用信息采集處理加ZigBee協(xié)議收發(fā)結(jié)構(gòu)，用專用處理器進(jìn)行數(shù)據(jù)處理，無線發(fā)送與接收裝置進(jìn)行收發(fā)，并與匯聚節(jié)點(diǎn)或網(wǎng)關(guān)進(jìn)行通信。而監(jiān)控主機(jī)則通過專用ZigBee網(wǎng)關(guān)，將感知節(jié)點(diǎn)傳輸而來的ZigBee協(xié)議數(shù)據(jù)，解析并轉(zhuǎn)換為TCP/IP協(xié)議數(shù)據(jù)，并通過防火墻與衛(wèi)星調(diào)制解調(diào)器連接，將監(jiān)控主機(jī)實(shí)現(xiàn)與遠(yuǎn)程端進(jìn)行鏈接；調(diào)試解調(diào)器連接衛(wèi)星收發(fā)天線。

2 系統(tǒng)硬件設(shè)計

系統(tǒng)硬件主要是指各種感知節(jié)點(diǎn)和ZigBee網(wǎng)關(guān)的硬件。由總體結(jié)構(gòu)可知，系統(tǒng)的感知分為隨鉆感知和井場感知，故節(jié)點(diǎn)亦分為隨鉆節(jié)點(diǎn)和井場節(jié)點(diǎn)。

隨鉆節(jié)點(diǎn)由傳感器、微控制器和總線模塊等構(gòu)成，傳感器將隨鉆數(shù)據(jù)進(jìn)行采集，由微控制器進(jìn)行處理并交由總線模塊進(jìn)行傳輸；總線將信息傳輸?shù)絑igBee協(xié)議轉(zhuǎn)換節(jié)點(diǎn)。因此，本部分的感知節(jié)點(diǎn)，僅針對井場的其它數(shù)據(jù)感知節(jié)點(diǎn)。

在此以井場壓縮空氣進(jìn)入管道后的氣壓監(jiān)測為例進(jìn)行設(shè)計，其它感知節(jié)點(diǎn)類似。

在空壓機(jī)產(chǎn)生壓縮空氣時，空壓機(jī)端能夠進(jìn)行輸出空氣壓力顯示，但進(jìn)入管道后，壓力存在一定的損失，就需要在管道里面進(jìn)行氣壓的采集，以便及時調(diào)整空壓機(jī)的輸出流量[8]。管道氣壓檢測采用PMP131傳感器(Endress+Hauser公司，恩德斯·豪斯，簡稱E+H公司)，該傳感器為壓敏電阻式壓力傳感器，且具有金屬隔離膜片，其量程為0 MPa-60 MPa，具有高穩(wěn)定性和可靠性，同時具有良好的重復(fù)性、長期穩(wěn)定性和高過載能力，非常適合于工業(yè)較高壓力測量。

本系統(tǒng)采用Endress+Hauser公司PMP131壓力傳感器中的兩線制電流型，其輸出電流為4 mA-20 mA。采用多點(diǎn)采集，即在壓縮空氣管道內(nèi)壁，多個點(diǎn)位安裝PMP131壓力傳感器，將各個傳感器的輸出信號使用屏蔽線，輸入到ZigBee處理模塊，其具體結(jié)構(gòu)如圖2所示。其中，ZigBee芯片選用美國TI公司的CC2530，并使用CC2591對其信號進(jìn)行擴(kuò)展，以使收發(fā)端的無線信號更強(qiáng)。在電源方面，使用充電式鋰電池與太陽能板一起構(gòu)成感知部分的電源模塊，傳感器本身電源使用專用電源線路。

圖2 井場壓縮空氣感知原理框架

太陽能電池板使用單晶體硅太陽電池片，其輸出壓降為5.5 V、電流為140 mA/h-160 mA/h，尺寸為90ms×90ms。采用上海如韻電子科技有限公司的太陽能板供電的單節(jié)鋰電池充電管理芯片—CN3063，同時使用該公司的極低功耗電池電壓檢測芯片—CN301；這兩個芯片在本系統(tǒng)中，用作充電和放電的管理與保護(hù)芯片，且放電保護(hù)時與LM1117-3.3芯片一起構(gòu)成感知節(jié)點(diǎn)的電源模塊，其具體電路原理如圖3所示[9]。

圖3 太陽能-鋰電池充電電路及放電保護(hù)電路

ZigBee網(wǎng)關(guān)是本系統(tǒng)的核心設(shè)備之一，主要完成ZigBee信號到以太網(wǎng)或其它形式的轉(zhuǎn)換，以便在系統(tǒng)控制端實(shí)現(xiàn)對系統(tǒng)的控制。ZigBee網(wǎng)關(guān)采用ARM Cortex-A8作為核心處理器，外接SD卡、以太網(wǎng)絡(luò)控制器兩個、相應(yīng)的存儲器芯片和CC2530芯片等構(gòu)成，其具體原理框架如圖4所示。

圖4 ZigBee網(wǎng)關(guān)原理框架

隨鉆感知數(shù)據(jù)經(jīng)總線后，需要轉(zhuǎn)為ZigBee協(xié)議的信息，其原理框架與圖2相似，唯一差異在于輸入信號為總線信號，接口芯片為相應(yīng)的總線控制芯片(如使用Can總線，則可用Philips公司的PCA82C250芯片作為接口芯片)，替代氣壓傳感器，接收總線傳輸來的信號，利用CC2530和CC2591將信號轉(zhuǎn)換為ZigBee信號。同樣，感知匯聚節(jié)點(diǎn)不再進(jìn)行描述。

3 系統(tǒng)軟件設(shè)計

在設(shè)計完硬件后，對系統(tǒng)的各種軟件，如感知節(jié)點(diǎn)軟件、監(jiān)控主機(jī)軟件，進(jìn)行設(shè)計。在此僅對感知節(jié)點(diǎn)及網(wǎng)關(guān)的軟件流程進(jìn)行設(shè)計。

3.1 感知節(jié)點(diǎn)及網(wǎng)關(guān)軟件設(shè)計

系統(tǒng)軟件部分包含內(nèi)容較多，主要有感知節(jié)點(diǎn)的軟件、ZigBee網(wǎng)關(guān)的軟件和監(jiān)控主機(jī)的軟件。其中感知節(jié)點(diǎn)的軟件部分，無論是井場感知節(jié)點(diǎn)，還是隨鉆感知轉(zhuǎn)換，其軟件差異在于感知到的數(shù)據(jù)傳輸方式不同而已。

對感知節(jié)點(diǎn)軟件，采用Z-Stack協(xié)議棧+Tiny OS操作系統(tǒng)，在用Nes C編程[10]。對感知節(jié)點(diǎn)而言，軟件啟動之初，首選屏蔽所有中斷源，進(jìn)入節(jié)點(diǎn)的芯片級、板載級和系統(tǒng)級的硬件初始化，然后進(jìn)行Tiny OS的初始化及其相關(guān)設(shè)置，再進(jìn)入事件處理的循環(huán)，其具體軟件流程如圖5(a)所示。

如圖5(b)所示，為感知節(jié)點(diǎn)的井場感知和隨鉆感知轉(zhuǎn)ZigBee協(xié)議數(shù)據(jù)的具體數(shù)據(jù)處理流程圖[11]。依據(jù)Tiny OS操作系統(tǒng)的相關(guān)規(guī)范，應(yīng)用Nes C進(jìn)行程序設(shè)計時，數(shù)據(jù)處理依事件觸發(fā)而進(jìn)行調(diào)度，從而實(shí)現(xiàn)感知數(shù)據(jù)轉(zhuǎn)ZigBee協(xié)議數(shù)據(jù)；圖中虛線表示UART(universal asy-nchronous receiver/transmitter)數(shù)據(jù)流動方向。

圖5 感知節(jié)點(diǎn)及網(wǎng)關(guān)軟件流程

網(wǎng)關(guān)軟件主要完成與后端監(jiān)控主機(jī)交換感知信息，同時還要與各匯聚節(jié)點(diǎn)間進(jìn)行ZigBee通信來實(shí)現(xiàn)感知數(shù)據(jù)的傳輸和監(jiān)控主機(jī)命令的下達(dá)。網(wǎng)關(guān)在完成初始化后，即刻進(jìn)入監(jiān)聽ZigBee網(wǎng)絡(luò)狀態(tài)，并等待外部事件中斷的發(fā)生，通過判決中斷事件是否為感知型，來確定相應(yīng)的處理過程。若網(wǎng)關(guān)收到的為以太網(wǎng)數(shù)據(jù)，則判決是否為監(jiān)控主機(jī)下達(dá)的管理命令；若通過匯聚節(jié)點(diǎn)收到感知數(shù)據(jù)，則對感知數(shù)據(jù)進(jìn)行解析，解析后轉(zhuǎn)發(fā)到監(jiān)控主機(jī)[12]。其具體流程如圖5(c)所示。

3.2 監(jiān)控主機(jī)軟件設(shè)計

監(jiān)控主機(jī)通過網(wǎng)絡(luò)連接控制中心，一方面要將感知數(shù)據(jù)通過網(wǎng)關(guān)進(jìn)行采集，另一方面要將相應(yīng)的命令通過網(wǎng)關(guān)下達(dá)給感知節(jié)點(diǎn)和上傳現(xiàn)場感知信息給遠(yuǎn)程控制中心。物聯(lián)網(wǎng)是一種新的數(shù)據(jù)交互模式，可實(shí)現(xiàn)多個智能感知對象間的遠(yuǎn)程鏈接，使得任何可感知的對象均能相互獨(dú)立的實(shí)現(xiàn)信息交互；同時，避免了潛在的大規(guī)模崩塌和癱瘓風(fēng)險，而提高系統(tǒng)的可信性[13]。因此，在監(jiān)控主機(jī)的軟件部分，使用基于物聯(lián)網(wǎng)的QoS優(yōu)化的虛擬感知即服務(wù)技術(shù)，以使各個感知節(jié)點(diǎn)的QoS最優(yōu)化。

為便于處理感知節(jié)點(diǎn)通過ZigBee方式傳輸而來的感知信息，采用基于感知即服務(wù)的虛擬化框架來處理感知信息。在框架中，屏蔽了用戶與感知節(jié)點(diǎn)的直接聯(lián)系，并以最大限度的透明度來提高服務(wù)的QoS質(zhì)量。前端感知節(jié)點(diǎn)構(gòu)成的物聯(lián)網(wǎng)與后端遠(yuǎn)程中心之間通過OpenIoT實(shí)現(xiàn)服務(wù)集成；對遠(yuǎn)程中心而言，通過OpenIoT實(shí)現(xiàn)了完整的智能云特性，且集成了需求效用、感知數(shù)據(jù)和遙感等服務(wù)[14]。圖6 為基于此設(shè)計的系統(tǒng)監(jiān)控主機(jī)軟件框架圖，該圖主要基于物聯(lián)網(wǎng)QoS優(yōu)化的虛擬感知即服務(wù)技術(shù)，框架能夠處理各種感知數(shù)據(jù)和遠(yuǎn)程中心的請求，相應(yīng)請求時隱藏了極其復(fù)雜的處理細(xì)節(jié)。由圖6可知，該框架按照層次結(jié)構(gòu)，給出了感知層、語義層、回溯搜索優(yōu)化算法層和感知即服務(wù)虛擬層，應(yīng)用程序建立于感知即服務(wù)虛擬層之上。

圖6 監(jiān)控主機(jī)軟件框架

感知層通過OpenIoT和ZigBee網(wǎng)關(guān)，與井場感知節(jié)點(diǎn)、隨鉆感知節(jié)點(diǎn)和其它感知節(jié)點(diǎn)建立感知數(shù)據(jù)，且通過數(shù)據(jù)庫管理各種感知數(shù)據(jù)。感知層相當(dāng)于一個輕量級的服務(wù)總線，用于進(jìn)行現(xiàn)場感知數(shù)據(jù)的表示和與上層進(jìn)行數(shù)據(jù)信息的交互。通過感知層能完善服務(wù)，增加新的定制服務(wù)和新感知節(jié)點(diǎn)時，無需改變監(jiān)控主機(jī)軟件而能方便進(jìn)行新服務(wù)的集成，即該層基于發(fā)布/訂閱模型來增加物聯(lián)網(wǎng)與感知層的透明性。

語義層采用面向服務(wù)思想以統(tǒng)一整個監(jiān)控主機(jī)軟件框架。該層提供語義模型，來查找、共享和翻譯下層所傳輸來的數(shù)據(jù)，主要解決描述、解釋和利用下層信息和事件；能提供獨(dú)立的服務(wù)；能處理異構(gòu)信息和數(shù)據(jù)、能完成與上層交互與兼容；為感知層提供訪問安全策略。而回溯搜索優(yōu)化算法層，該層的目標(biāo)是實(shí)時提高框架服務(wù)性能，主要通過以下3個方面來實(shí)現(xiàn)：一是對下層輸入的各種服務(wù)請求進(jìn)行過濾和向上層輸入的服務(wù)請求；二是對各種服務(wù)的QoS進(jìn)行計算和度量，并按照相關(guān)約束條件，如可用性、可靠性和響應(yīng)時間，進(jìn)行服務(wù)排序；三是為上層提供最優(yōu)化QoS服務(wù)解決方法；該層具體算法及其仿真驗(yàn)證，將在下一個部分予以詳細(xì)論證。感知即服務(wù)虛擬層主要功能是將應(yīng)用程序輸入的各種同構(gòu)、異構(gòu)的服務(wù)請求，進(jìn)行服務(wù)創(chuàng)建和組合，使服務(wù)的QoS達(dá)到最優(yōu)化，同時將感知數(shù)據(jù)進(jìn)行虛擬化。

應(yīng)用程序建立在感知即服務(wù)虛擬層之上，主要為監(jiān)控主機(jī)提供各種操作界面和應(yīng)用處理程序。應(yīng)用程序生成各種服務(wù)請求，提交給感知即服務(wù)虛擬層進(jìn)行處理，而完成對鉆井現(xiàn)場的監(jiān)控和遠(yuǎn)程中心的實(shí)時處理等工作。

4 QoS優(yōu)化算法與系統(tǒng)測試

上文所述，回溯搜索優(yōu)化算法層的主要目的是依據(jù)各種請求的優(yōu)先級進(jìn)行請求過濾和重新建立隊列，且為上層提供服務(wù)QoS優(yōu)化算法。因此，本部分將對算法進(jìn)行設(shè)計和仿真驗(yàn)證，同時對監(jiān)控主機(jī)的數(shù)據(jù)采集軟件進(jìn)行實(shí)現(xiàn)。

4.1 算法設(shè)計

回溯搜索優(yōu)化算法(backtracking search optimization algorithm，BSOA)是文獻(xiàn)[15]中提出的一種基于種群的新型進(jìn)化算法。在此，將BSOA算法應(yīng)用于物聯(lián)網(wǎng)感知領(lǐng)域，以提高本系統(tǒng)監(jiān)控主機(jī)軟件框架的性能。

定義1 設(shè)G=(V,R) 為一幾何隨機(jī)圖，則G表示感知節(jié)點(diǎn)的拓?fù)浣Y(jié)構(gòu)圖，其中：V表示n1個感知節(jié)點(diǎn)和n2個匯聚節(jié)點(diǎn)構(gòu)成的感知頂點(diǎn)集合，V=Vn1∪Vn2={vi,vj} 且?≠0,i,j∈{1,2,…,N}；

在物聯(lián)網(wǎng)感知服務(wù)的監(jiān)控主機(jī)軟件框架中，任何服務(wù)都具有實(shí)時性要求[16]。感知服務(wù)S的最優(yōu)QoS值，與定義1的R相關(guān)，即要求服務(wù)的可用性和可靠性最大，響應(yīng)時間最短[17]。另一方面，物聯(lián)網(wǎng)中，服務(wù)S為串行服務(wù)SSm、 并行服務(wù)PSm、 分支服務(wù)BSm和循環(huán)服務(wù)CSm的最優(yōu)組合，使得服務(wù)S的QoS值最大，即

(1)

因此，主要的目的是改進(jìn)系統(tǒng)監(jiān)控主機(jī)軟件框架的QoS屬性，使其達(dá)到最優(yōu)化。

而每個服務(wù)，又可描述為服從定義1所定義的屬性指標(biāo)，即

(2)

又由于服務(wù)SSi的可用性為s1,s2,…,sn所有服務(wù)均可用而得到的；服務(wù)SSi的可靠性也與服務(wù)s1,s2,…,sn中的每個均可靠才能使得其可靠；服務(wù)SSi的響應(yīng)時間為s1,s2,…,sn所有服務(wù)的響應(yīng)時間之和；由此得到

(3)

同理可得PSm,BSm,CSm， 在此就不再予以詳細(xì)描述。

因此，依據(jù)BSOA算法，得到基于BSOA算法的系統(tǒng)監(jiān)控主機(jī)軟件響應(yīng)時間算法流程如圖7所示，其具體步驟為：

步驟1 初始化。對初始種群的規(guī)模、交叉概率、搜索空間范圍和最大進(jìn)化次數(shù)等進(jìn)行初始化。初始化種群H為下層的歷史請求數(shù)量和新的下層請求數(shù)，即為

(4)

其中，HPR和NLR分別表示歷史請求數(shù)和新的下層請求數(shù)；i,k=1,2,…,M1,M1表示這群規(guī)模；j=1,2,…,A,A表示種群維數(shù)；lowj,highj分別為搜索空間的下限值和上限值；U(lowj,highj) 表示隨機(jī)函數(shù)，在此為均勻分布。

圖7 基于BSOA算法流程

步驟2 選擇I。選擇I的目的就是選擇一新的歷史種群。依據(jù)HPR中的歷史數(shù)據(jù)，利用式(2)、式(3)計算得到SSm服務(wù)最小值、次最小值等對應(yīng)的服務(wù)，從而得到SSm服務(wù)響應(yīng)時間由短到長的序列；并按照同樣的方法，得到PSm、BSm和CSm的序列；將此4個序列作為一個歷史種群H1， 直到該歷史種群發(fā)生改變。

步驟3 種群變異。依據(jù)新的請求數(shù)，重新組成請求隊列；從隊列取出請求，與H1一起重新構(gòu)成歷史種群H2， 并對進(jìn)行QoS屬性中定義1的Q檢查而進(jìn)行變異。變異如式(5)所示

H3(s)=QoS(s2)+F·(QoS(s2)-QoS(s1))

(5)

其中，QoS(s) 服從式(1)；s1,s2表示種群H1,H2的QoS屬性度量；F表示控制種群變異系數(shù)，其大小為F=3·RD，RD～U(0,1)。

若H3(s)≤b， 則轉(zhuǎn)為第一步；若H3(s)>b， 則繼續(xù)進(jìn)行下一步；其中b為設(shè)定的閾值。

步驟4 種群交叉。BSOA的種群交叉是通過交叉率來控制兩種交叉方式，使其在等概率條件下，得到復(fù)雜的聯(lián)合交叉方法，其目的是得到新一代種群[18]。依據(jù)第三步得到的結(jié)果和BSOA算法，得到新的種群。新種群產(chǎn)生如式(6)所示

(6)

其中，Z是M1×A的整數(shù)矩陣，初值為1，由式(7)予以確定

(7)

式中：RD～U(0,1) 表示[0,1]上的均勻分布；cp為交叉概率，在此取值為1；m2,m3服從[0,1]均勻分布；由此得到規(guī)模受控的新種群T。

步驟5 選擇Ⅱ。由步驟3、步驟4，得到了新種群T和歷史種群H2， 然后依據(jù)類型進(jìn)行選擇Ⅱ，即將T和H2中適應(yīng)度值較好的個體Ti作為當(dāng)前的最優(yōu)解，否則進(jìn)行種群更新并返回到步驟2。定義式(8)描述新種群T與歷史種群H2的最優(yōu)解，即

(8)

又由前可得到適應(yīng)度函數(shù)為

(9)

式中：M表示在新種群T和歷史種群H2中選取的樣本；Pi表示新種群T和歷史種群H2的統(tǒng)稱；F服從步驟3的定義。

步驟6 輸出最優(yōu)解。輸出當(dāng)前得到的最優(yōu)解，繼續(xù)執(zhí)行，直到達(dá)到最大進(jìn)化次數(shù)才停止，并從輸出的結(jié)果中，將式(9)值最小的個體序列，作為整個算法的最優(yōu)解。

由此，利用BSOA算法提高系統(tǒng)監(jiān)控主機(jī)軟件相應(yīng)時間，減少系統(tǒng)實(shí)時采集的計算時間[19]。接下來，對算法進(jìn)行仿真實(shí)驗(yàn)與分析，以驗(yàn)證算法的有效性，從而提高健康主機(jī)軟件的可伸縮性和響應(yīng)速度。

4.2 算法實(shí)驗(yàn)與仿真分析

對設(shè)計的QoS算法進(jìn)行實(shí)驗(yàn)與仿真分析時，使用專業(yè)網(wǎng)絡(luò)實(shí)驗(yàn)平臺NS2(network simulator version 2，NS2)和Matlab模擬器[20]。實(shí)驗(yàn)時，將BSOA算法與GA(genetic algorithm)算法的性能進(jìn)行比對，同時使用蟻群算法(ant colony algorithm，ACA)進(jìn)行性能評價。Matlab模擬器主要評估BSOA算法、GA算法和ACA算法，在執(zhí)行相同任務(wù)時的時間上的差異[21]。

實(shí)驗(yàn)時，依據(jù)鉆井平臺所使用到的傳感器網(wǎng)絡(luò)類型和特點(diǎn)，建立基于特定按需距離矢量協(xié)議(hoc on-demand distance vector protocol，HODVP)的傳感器網(wǎng)絡(luò)區(qū)域。先基于HODVP，編寫實(shí)現(xiàn)GA算法、ACA算法和BSOA算法的代碼，建立一個可靠的具有QoS屬性約束的無線感知網(wǎng)絡(luò)；然后設(shè)置和調(diào)整網(wǎng)絡(luò)容量，使其感知節(jié)點(diǎn)由10個到100個，場景模擬時間為12 s。實(shí)驗(yàn)主要比較不同感知節(jié)點(diǎn)下的平均感知任務(wù)結(jié)束延遲、吞吐率、數(shù)據(jù)傳輸率和抖動等。具體實(shí)驗(yàn)與仿真結(jié)果如圖8所示。

圖8 3種算法實(shí)驗(yàn)與仿真對比

由圖8可知，BSOA算法在任務(wù)平均結(jié)束時間延遲、吞吐率、數(shù)據(jù)傳輸率和抖動等方面，較GA算法和ACA算法而言，具有較好的優(yōu)勢。另一方面，通過Matlab模擬器仿真的3種算法的時間復(fù)雜度，其比較圖如圖8(e)所示。

4.3 監(jiān)控主機(jī)軟件實(shí)現(xiàn)

由上文設(shè)計可知，系統(tǒng)對鉆井平臺的隨鉆數(shù)據(jù)和井場數(shù)據(jù)進(jìn)行感知與采集，而具體執(zhí)行采集任務(wù)由相應(yīng)的傳感器完成。

數(shù)據(jù)分為隨鉆感知和井場感知。在測試時，隨鉆數(shù)據(jù)主要有鉆井深度、瓦斯?jié)舛?、扭矩、進(jìn)井液體速度、出井液體速度、進(jìn)井液體密度和出井液體密度等。井場感知數(shù)據(jù)主要有鉆井發(fā)動機(jī)監(jiān)測、空壓機(jī)數(shù)據(jù)感知和泥漿池等。

測試基于某高校鉆井實(shí)驗(yàn)平臺進(jìn)行數(shù)據(jù)采集，并微軟Visual Studio 2015集成開發(fā)系統(tǒng)，用微軟基礎(chǔ)類庫(Microsoft foundation classes，MFC)和Visual C++結(jié)合，利用前面設(shè)計的框架與模塊化并重的方式，開發(fā)系統(tǒng)監(jiān)控主機(jī)測試軟件。界面如圖9所示，采用下拉菜單方式進(jìn)行設(shè)計，主要有數(shù)據(jù)采集、系統(tǒng)設(shè)置和數(shù)據(jù)操作等功能。其中數(shù)據(jù)操作有當(dāng)前數(shù)據(jù)識別、未來鉆井預(yù)測、鉆井約束條件、數(shù)據(jù)初步分析和鉆井事故預(yù)測。監(jiān)控主機(jī)軟件啟動后，點(diǎn)擊界面中的“啟動”，則實(shí)時動態(tài)顯示各種感知數(shù)據(jù)；若點(diǎn)擊“停止”，則暫停實(shí)時動態(tài)顯示，而僅顯示停止時刻的各傳感器瞬態(tài)時值，但后臺自動記錄實(shí)時感知數(shù)據(jù)。

圖9 監(jiān)控主機(jī)軟件界面

在圖9中，顯示了大部分傳感器的鉆井參數(shù)及其實(shí)時變化情況，顯示的參數(shù)間隔時間可設(shè)置，最小為3 s；并將數(shù)據(jù)自動進(jìn)行保存于如表1樣式所示的數(shù)據(jù)文件中。

在監(jiān)控主機(jī)軟件中，可實(shí)現(xiàn)對現(xiàn)場感知數(shù)據(jù)的初步分析和鉆井事故的預(yù)測，同時可對鉆井未來工況進(jìn)行預(yù)測。通過對感知數(shù)據(jù)的分析，若發(fā)現(xiàn)鉆井現(xiàn)場存在事故可能，則啟動現(xiàn)場預(yù)警，并指示某個感知數(shù)據(jù)異常。若對隨鉆感知數(shù)據(jù)進(jìn)行分析，可預(yù)測鉆頭損壞與裹死情況、鉆桿斷裂情況、鉆具是否卡死和鉆井液漏失與溢流等。如圖9右邊曲線所示，為所選擇的某個傳感器感知數(shù)據(jù)的實(shí)時變化曲線；截圖為泵壓力感知曲線。若泵壓力和扭矩都增大，且數(shù)據(jù)曲線急劇波動，鉆機(jī)轉(zhuǎn)速先上升后加劇下降，泵壓力導(dǎo)致鉆壓力波動非常劇烈，則為鉆頭損壞。由此，要預(yù)測某種鉆井事故，必須對多個感知數(shù)據(jù)進(jìn)行綜合分析，而得到鉆井事故預(yù)測結(jié)果；監(jiān)控主機(jī)軟件對鉆井事故預(yù)測樣式表格見表2。

表1 監(jiān)控主機(jī)保存數(shù)據(jù)樣式

表2 鉆井事故預(yù)測情況

5 結(jié)束語

利用物聯(lián)網(wǎng)感知技術(shù)，對鉆井平臺的數(shù)據(jù)采集進(jìn)行設(shè)計。對鉆井現(xiàn)場數(shù)據(jù)采集系統(tǒng)的總體結(jié)構(gòu)進(jìn)行了設(shè)計，還對各種感知節(jié)點(diǎn)、隨鉆感知節(jié)點(diǎn)和ZigBee網(wǎng)關(guān)等的硬件進(jìn)行了設(shè)計；對感知節(jié)點(diǎn)、網(wǎng)關(guān)和監(jiān)控主機(jī)等軟件進(jìn)行了設(shè)計，并對監(jiān)控主機(jī)軟件進(jìn)行了實(shí)現(xiàn)。利用基于物聯(lián)網(wǎng)的QoS優(yōu)化的虛擬感知即服務(wù)技術(shù)，對系統(tǒng)監(jiān)控主機(jī)軟件進(jìn)行層次化設(shè)計，并對監(jiān)控主機(jī)的軟件服務(wù)QoS進(jìn)行回溯式搜索優(yōu)化算法，提高感知即服務(wù)的質(zhì)量和時間響應(yīng)特性，在QoS的延遲、分組投遞率和吞吐量等方面的仿真實(shí)驗(yàn)結(jié)果表明，該算法對提高系統(tǒng)監(jiān)控主機(jī)的實(shí)時性。