遠程傳輸范文

導語：如何才能寫好一篇遠程傳輸，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。

篇1

關鍵詞：圖像；抓取；傳送；遠程；實時

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2014）05-1056-02

The Research on Remote Screen Capture and Real-time Image Transmission Method

YANG Hua

（Inner Mongolia University of Technology， Hohhot 010000， China）

Abstract： This article expounds on the remote control and management of computer network for real-time image capture and transmission technology in application and the realization of the way， compared with the current technology， analyzes the advantages and disadvantages and the reasons， gives the remote screen image in the network transmission technology is a kind of method， and combining the practice， to solve the limitation and influence of Resource usage and the stability of the remote screen image transmission， and puts forward some problems that may be encountered in the course of solving problem.

Key words： image； capture； transmission； remote；real - time

隨著計算機網(wǎng)絡應用的迅猛發(fā)展，種類繁多的有關計算機網(wǎng)絡的應用軟件也得以快速發(fā)展。在這些軟件之中，有關計算機網(wǎng)絡的遠程實時控制和管理軟件的應用尤其廣泛，比如在網(wǎng)絡的自動化管理、在線軟件技術支持、計算機遠程輔助教學、實時網(wǎng)絡服務、實時網(wǎng)絡監(jiān)控等方面，這些應用具有不可替代技術含量和無可估量的商業(yè)價值。目前該方面已經(jīng)研發(fā)出的一些此類相關軟件產(chǎn)品大多數(shù)在網(wǎng)絡帶寬占用、系統(tǒng)資源占用、實時性以及可靠性等方面存在一些問題，究其原因就在于服務器和客服端的遠程屏幕圖像的抓取和傳輸上。

通過反復的理論論證以及多次的實踐證明，找到了可以解決以上提到的有關遠程屏幕圖像網(wǎng)絡截取與傳輸?shù)膯栴}之可行辦法。

1 遠程屏幕圖像的實時傳輸

此類軟件在通常情況下都采用基本的C/S結構（客戶機和服務器結構）。客戶端的主要作用有兩個，一個是發(fā)出截取的屏幕圖像的請求，另一個是把接收到的屏幕圖像實時的進行顯示。服務器的主要作用也有兩個，一個是應答發(fā)來的請求，另外一個是發(fā)送屏幕圖像。通常情況下，服務器端截取的屏幕圖像是位圖格式，它具有數(shù)據(jù)量大，直接發(fā)送占用系統(tǒng)資源大、占用網(wǎng)絡帶寬大以及實時性和穩(wěn)定性差的特征，所以在發(fā)送前需要經(jīng)過壓縮。相應的，客戶端要正確的顯示圖像必須要把接收到的圖像數(shù)據(jù)壓縮解壓縮。

要想解決以上提出的問題，主要需要解決的重點是兩點：一點是屏幕圖像的壓縮與解壓縮。另外一點就是屏幕圖像的截取方式的選擇。對于第一個問題，主要需要考慮的是尋求高的壓縮率和快的壓縮與解壓縮的速度，這些可以通過選擇適當?shù)膲嚎s與解壓縮算法來實現(xiàn)，比如比較常用而且有效的算法有Huffman算法、RLE算法、LZW算法等等，目前存在的軟件這些方面處理比較合適，因此提高的余地是非常有限的。而在屏幕圖像的截取這方面上，很多相關軟件的開發(fā)都只采用了最常用到的最一般的圖像截取方法，把屏幕圖像截取方法的選取的重要性忽略了。事實上，屏幕圖像的截取和數(shù)據(jù)的壓縮與解壓縮同樣重要，都會對屏幕圖像的傳輸產(chǎn)生很重要的影響，所以在這一點上，還有很大的提升空間。

2 屏幕截取與圖像傳輸方法的實現(xiàn)

2.1屏幕截取方式的比較與選擇

屏幕截取的方式有很多，目前也有很多現(xiàn)成軟件可以使用，比如picpick、faststonecapture等。在Delphi中，也提供了很多截取模式，比如有cmSrcCopy、mSrcInvert、cmWhiteness等。在這些模式中，最普通最常用的截取方式就是，在這種模式下，要截取的源圖會被直接截取到目的畫圖中，截取之后就馬上進行壓縮處理。另外還有一種截取方式，那就是cmSrcInvert模式，這種截取方式需要將要截取的源圖和已經(jīng)截取到目的畫布中的圖先進行XOR運算，也就是異或運算，運算完成后對運算后的圖再進行壓縮處理，當然這里提到的運算都是位的運算。與之相應的就是顯示過程，首先把傳輸來的壓縮圖進行解壓縮處理，然后把解壓縮后的圖的位值與當前圖的位值進行XOR（異或）運算，那么運算所得到的位圖當然實際需要顯示的圖。

雖然cmSrcInvert模式比cmSrcCopy模式在客戶端與服務端都多了一次圖像位圖的XOR（異或）運算，但是因為在傳輸前都要進行壓縮處理，而后一種模式產(chǎn)生的圖像經(jīng)過壓縮之后的數(shù)據(jù)量要比前一種模式壓縮后得到的數(shù)據(jù)量要小很多，所以后一種截取圖像模式后需要傳輸?shù)臄?shù)據(jù)量就要更小。當然，產(chǎn)生這樣的后果究其原因是因為在通常情況下屏幕圖像的特征決定的，那就是因為屏幕圖像總是在一個或幾個局部發(fā)生變化而不是全部屏幕在不停的發(fā)生變化。所以把當前屏幕的圖像和上一次截取的屏幕圖像進行XOR運算，所得到的屏幕位圖沒有發(fā)生變化的部分的位值就是0，而發(fā)生了變化部分的位值則為1。當屏幕圖像發(fā)生變化的范圍比較小的時候，那么截取的屏幕圖像位圖的大量位值就是0，那么此時待壓縮的數(shù)據(jù)本身在壓縮時就會有很好的壓縮率，傳輸時所占用的帶寬也更小。盡管在cmSrcInvert模式和cmSrcCopy模式下初始截取的屏幕圖像的數(shù)據(jù)是完全一樣的，但是在傳輸前測試所要傳輸?shù)臄?shù)據(jù)就會發(fā)現(xiàn)， cmSrcInvert模式下壓縮后的數(shù)據(jù)量遠遠小于cmSrcCopy模式下壓縮的數(shù)據(jù)量，那么原因也如之前所述。在具體的實驗測試過程中，我們采用了Delphi6.0中自帶的Zlib.pas和Zlibconst.pas兩個文件來對數(shù)據(jù)進行壓縮與解壓縮，通過實驗測試后一種也就是cmSrcInvert模式在傳輸屏幕圖像時占用網(wǎng)絡寬帶方面比cmSrcCopy模式非常明顯的優(yōu)勢。

2.2屏幕的分區(qū)域截取與傳輸

在通常的軟件中，最常用的屏幕截取方式是一次性整屏截取，通常因為截取的數(shù)據(jù)量大而得不到好的實時效果，尤其是在網(wǎng)絡帶寬固定而且有限的時候這個問題就變的更加突出和明顯。事實上，完全可以在服務端把屏幕先劃分成一定數(shù)量的大小相同的矩形，然后再在cmSrcInvert截取模式下對每個矩形分別進行截取和壓縮，最后再把壓縮后的數(shù)據(jù)進行傳輸。當然也可以先比較截取的矩形區(qū)域圖像有沒有發(fā)生變化，再進行后期處理，如果發(fā)生了變化就對變化的區(qū)域進行處理，如果沒有發(fā)生變化就不處理。和上述操作相對應的操作是客戶端的操作，當客戶端接收到數(shù)據(jù)后，首先要把接收到的數(shù)據(jù)隊列中的頭數(shù)據(jù)取出來進行解壓縮，然后再在對應的位置把這個矩形圖像顯示出來。如果在實際編程中需要考慮實時性的要求，當然大部分情況下都需要考慮，那么就可以使用多個線程來對不同位置的屏幕圖像進行處理，也就是我們常提到的多線程程序設計的方案。使用這種方案可以在不同的狀況下獲得好的實時性、好的資源占用性以及好的軟件穩(wěn)定性。但是要引起重視的是劃分屏幕的個數(shù)應該根據(jù)網(wǎng)絡帶寬等因素來設定，劃分的區(qū)域個數(shù)太多的話，對每個區(qū)域圖像進行截取、壓縮、傳輸、解壓所花費時間的和就有可能超過對整屏圖像截取、壓縮、傳輸以及解壓的時間，這樣所造成的結果是，雖然占用的網(wǎng)絡帶寬小了，但是實時性也下降了。當然如果屏幕圖像劃分區(qū)域的個數(shù)太少，那么和整屏處理所占用的網(wǎng)絡帶寬相差無幾，劃分區(qū)域就失去了意義。通過測試，當局域網(wǎng)為10M時，劃分的較為理想的區(qū)域個數(shù)是4-6個，這時基本每個矩形區(qū)域的圖像在壓縮后變?yōu)?～2KB，和整屏處理相比，占用的網(wǎng)絡帶寬低，實時性高，延遲也小于0.8秒。

服務端：

1）對屏幕圖像進行恰當?shù)木匦螀^(qū)域的劃分；

2）對劃分后的區(qū)域進行圖像截取

3）判斷每個矩形區(qū)域的圖像是否發(fā)生變化；

4）對發(fā)生變化的矩形區(qū)域圖像進行壓縮后發(fā)送；

5）執(zhí)行第一步。

客戶端：

1）取出接收到的圖像隊列中的一個數(shù)據(jù)塊；

2）把數(shù)據(jù)塊進行解壓縮

3）確定解壓縮后的矩形區(qū)域數(shù)據(jù)塊的位置；

4）把矩形區(qū)域圖像在該位置進行顯示；

5）執(zhí)行第一步。

3 屏幕圖像數(shù)據(jù)流的壓縮與解壓縮

截取的屏幕圖像要進行壓縮與解壓縮，可以使用的算法有很多，比如Huffman、RLE、LZW等這些屬于第三方提供的壓縮算法。事實上，Del-phi6.0自帶了高效的壓縮與解壓縮的控件包Zlib，編程人員完全可以通過控件包Zlib中的Zlib.pas和Zlibconst.pas這兩個文件提供的接口來實現(xiàn)圖像的壓縮與解壓縮。第一步：使用屏幕拷貝截取當前全部屏幕圖像。第二步：在內存中把截取的圖像文件保存成BMP格式。第三步：當在服務器端壓縮截取的屏幕圖像時，把原始圖像壓縮后保存成自定義變量。第四步：當在客戶端把獲取的屏幕圖像進行解壓縮時，把壓縮的圖像解壓縮后還原成BMP格式的位圖并且及時進行顯示。

4 總結

綜上所述，在軟件設計中考慮遠程圖像截取與實時傳輸?shù)倪^程時，除了考慮上述提到的屏幕截取與數(shù)據(jù)壓縮后傳輸和解壓縮后顯示這兩個主要問題，還要考慮選擇合適的網(wǎng)絡傳輸以及雙方握手協(xié)議。于此同時，指針、內存流和多線程技術都是需要在整

（下轉第1060頁）

（上接第1057頁）

個圖像截取與傳輸?shù)膶崿F(xiàn)過程中需要考慮的問題，只有從多方面共同解決問題才能提高圖像截取與傳輸軟件的效率和穩(wěn)定性。

參考文獻：

[1] 耿增民，余正濤，康海燕；一種提高計算機屏幕圖像傳輸速度的方法[J].計算機工程與應用，2005（1）.

[2] 謝志鵬.基于socket的遠程教學輔導軟件的設計[J].計算機應用，2003（9）.

[3] 魯萍.遠程教學系統(tǒng)中的屏幕圖像實時傳輸技術[J].計算機工程與設計，2005（12）.

篇2

關鍵詞：遠程傳輸 城鎮(zhèn)燃氣 監(jiān)控

中圖分類號：F407文獻標識碼： A

一、遠程監(jiān)控系統(tǒng)介紹

遠程傳輸監(jiān)控系統(tǒng)是以計算機為基礎的生產(chǎn)過程控制與調度自動化系統(tǒng)。它可以對現(xiàn)場的運行設備進行監(jiān)視和控制，以實現(xiàn)數(shù)據(jù)采集、設備控制、測量、參數(shù)調節(jié)以及各類信號報警等各項功能。

流量儀表和站控系統(tǒng)的數(shù)據(jù)通過RTU設備（Remote Terminal Unit遠程測控終端系統(tǒng)）或DTU設備（Data Transfer unit數(shù)據(jù)傳輸單元）經(jīng)由移動公司無線傳輸網(wǎng)絡進行無線傳輸。

1、系統(tǒng)的組成元素

系統(tǒng)包括以下的子系統(tǒng)：

人機界面（human machine interface，簡稱HMI）、（電腦）監(jiān)控系統(tǒng)、遠程終端控制系統(tǒng)（Remote Terminal Unit，簡稱RTU）、可編程邏輯控制器（programmeable logic controller，簡稱PLC）、通信網(wǎng)絡。

2、監(jiān)控用設備

監(jiān)控站（Supervisory Station）是指要和現(xiàn)場設備（例如RTU或PLC）及在控制室（或其他地方）工作站上HMI軟件通信所需要的服務器及軟件。在較小的遠程傳輸監(jiān)控系統(tǒng)中，監(jiān)控站就是一臺電腦。較大遠程傳輸監(jiān)控系統(tǒng)的監(jiān)控站可能包括多臺服務器、分散式應用軟件及意外備援系統(tǒng)。為了提高系統(tǒng)的集成性，多個服務器常規(guī)劃為雙冗余或是熱備件（hot-standby），在其中一臺服務器故障時仍然可以繼續(xù)控控制及監(jiān)控整個系統(tǒng)。

二、站控系統(tǒng)應用情況

我公司與2010年建設遠程監(jiān)控系統(tǒng)，目前遠程傳輸監(jiān)控系統(tǒng)主要將門站、大型工商業(yè)用戶等的現(xiàn)場數(shù)據(jù)實時傳輸?shù)秸{度中心，調度中心值班人員了解到監(jiān)測點管道的壓力、溫度、流量的變化，調度各站進出站壓力、調整城市管網(wǎng)壓力和對工商業(yè)用戶的流量監(jiān)控，防止用戶偷盜氣等。

1、門站遠程傳輸?shù)慕ㄔO

我公司現(xiàn)有2座城市門站，2座高中壓調壓站，負責全市工商業(yè)及居民的燃氣供應、壓力調節(jié)、流量控制等。在門站建設遠程傳輸監(jiān)控系統(tǒng)中，我們通過在站內安裝的工控機，配置相對應的站控軟件，再經(jīng)由RS-232轉RS-485裝置把信號傳送到RTU或DTU設備，最后RTU或DTU設備通過GPRS移動網(wǎng)絡（電話卡）發(fā)送至公司調度中心機房的方法，實現(xiàn)門站各項數(shù)據(jù)的實時傳輸。

RTU或DTU傳輸方式的優(yōu)點在于設備安裝上即可傳送數(shù)據(jù)，RTU或DTU設備配置、安裝簡單易行，每月數(shù)據(jù)流量少于40M，投資少。

2、城市管網(wǎng)遠程傳輸系統(tǒng)的建設

城市管網(wǎng)的穩(wěn)定運行與市民還有各個工礦企業(yè)息息相關，管網(wǎng)壓力大小與否直接影響著居民的生活和企業(yè)的生產(chǎn)，然而我公司在管網(wǎng)建設之初并沒有預見到以后會增設遠程傳輸設備，因此直接在管網(wǎng)上采集壓力、溫度、流量等數(shù)據(jù)難以實現(xiàn)。為了能夠了解各處管網(wǎng)的工作狀況，我們想到了監(jiān)控在管網(wǎng)附近工商業(yè)用戶的辦法來解決問題。

這種用戶的選擇不是盲目的，要有針對性，管網(wǎng)的首末兩端一定要有監(jiān)控用戶，中、低壓管線上要有代表性的監(jiān)控點，居民小區(qū)、工業(yè)用戶集中地區(qū)要多選，比較偏僻的地區(qū)也要選，結合城市規(guī)劃與公司輸氣情況，我們選擇了具有代表性的工業(yè)站點10個，商業(yè)站點17個來監(jiān)控城市管網(wǎng)壓力的運行情況。

傳輸設備依然選擇使用RTU或DTU設備，安裝中我們需要向用戶協(xié)調供電、安裝位置、安全防護等事項。此類用戶的安裝，不僅可以實現(xiàn)管網(wǎng)壓力的動態(tài)監(jiān)控，輔助調度人員平衡氣源調度，還可以實現(xiàn)對重要用戶的氣量監(jiān)控。比如，有些工業(yè)用戶與我公司簽訂了供用氣合同，在合同中明確規(guī)定了每月的用氣量，如有了監(jiān)控后，我們能夠及時的掌握企業(yè)的用氣情況，合理調配氣量，保證公司的利益。

3、對一些重點用的監(jiān)控

在已選擇的站點中，我們在主要的監(jiān)控點或用戶處安裝有YCL-Ex型防爆熱質流量開關，它的工作原理是通過與燃氣接觸的兩個探針之間測量的溫差變化，來確定燃氣的流速，當流速低于或高于某一設定值時，其中的繼電器接通或斷開，輸出開關量信號。它和流量儀表一同接入RTU設備，當監(jiān)控點或用戶使用天然氣而流量儀表不工作時，流量開關就會通過RTU設備向調度中心報警，以此來確定監(jiān)控點和用戶是否存在設備損壞或偷盜氣行為，確保公司利益不受損失。

4、在燃氣管道搶險搶修中的作用

燃氣管道雖然深埋于地下，但是隨著城市的建設，各種道路拓寬，新管道、線路敷設，其他部門的道路施工，時常能造成燃氣管道損毀，造成燃氣泄露，管道壓力降低。通過建立的這個監(jiān)控系統(tǒng)，我們能及時的了解到哪個地方的壓力過低，為了確保燃氣的正常供應，調度中心可通知各個服務區(qū)的工作人員進行臨時調壓，保證用氣安全。

三、未來趨勢

1、硬件發(fā)展方面

遠程傳輸監(jiān)控系統(tǒng)將依據(jù)標準的網(wǎng)絡技術，以以太網(wǎng)及TCP/IP為基礎的通信協(xié)定會取代舊的專用協(xié)定。大部份的市場都已經(jīng)接受了以太網(wǎng)的HMI/遠程傳輸監(jiān)控系統(tǒng)，只有一些少數(shù)特殊的應用會因為以幀為基礎的網(wǎng)絡通信特性（如確定性、同步、通信協(xié)定選擇及耐環(huán)境性），無法使用以太網(wǎng)通信。

許多設備商已經(jīng)開始提供特殊應用的遠程傳輸監(jiān)控系統(tǒng)，其主站建設在以太網(wǎng)的遠程平臺上。如此就不用在終端用戶的設備上安裝及規(guī)劃系統(tǒng)，而且可以利用以太網(wǎng)技術、虛擬私人網(wǎng)絡（VPN）及傳輸層安全中已有的安全特性。相關的問題包括安全性[1]、以太網(wǎng)鏈接的可靠度及延遲時間，是需要相關企業(yè)共同來探討和解決的。

2、應用趨勢

遠程傳輸監(jiān)控系統(tǒng)作為生產(chǎn)調度的核心系統(tǒng)，在數(shù)據(jù)統(tǒng)計、分析，管網(wǎng)運行調度模式和配合GIS系統(tǒng)運行方面將發(fā)揮更大的作用。

篇3

This paper discussed the tele-transportation and application of the DICOM format medical images on WEB，and provided a new B/S structure mode of two-way tele-consultation between doctors，and expounded the technologies related to tele-consultation，such as PACS and HIS background connection based on HL7 back standard，tele SSL VPN technology，wireless application，lossless compression，multi-points consultation and logical isolation technology of virtual network.This application provides a new practical scheme for breaking through the limitation of intranet of medical service and full use of medical resource.

Key words

WEB；DICOM；PACS；tele-consultation

摘要： 本文探討DICOM格式的PACS圖像在WEB上的遠程傳輸應用，提出一種基于醫(yī)生間的B/S構架遠程雙向會診模式，并就與遠程會診相關的HIS與PACS的HL7后臺關聯(lián)技術、遠程SSLVPN技術、無線網(wǎng)絡應用技術、圖像無損壓縮、多點會診應用以及虛擬網(wǎng)絡隔離技術等做一闡述。WEB雙向DICOM傳輸?shù)膽茫瑸獒t(yī)療信息突破局域網(wǎng)限制、充分利用醫(yī)療資源，提供了一種新型技術方案。

關鍵詞： WEB；DICOM；PACS；遠程會診

隨著通信和計算機技術的發(fā)展，特別是Internet的普及，WEB網(wǎng)站和IE瀏覽被廣泛采用，使遠程會診在技術層面上有了很大的進步。本文論述的雙向WEB模式PACS圖像傳輸技術，是基于Internet之上、采用B/S模式、IE瀏覽技術，以DICOM格式圖像在WEB上的遠程傳輸。本項技術的應用，使參與會診的各方醫(yī)生真正做到雙向信息交流，使溝通討論成為可能，尤其對距離遙遠或存在技術差異的地區(qū)與上級醫(yī)院專家之間會診更具實用價值。

1 國內外現(xiàn)狀及設計思想

國外遠程醫(yī)療系統(tǒng)的研究和應用主要集中在:(1)醫(yī)療信息集成與交換協(xié)議(如DICOM3、HL7等)［1］；(2)遠程醫(yī)療保健信息服務系統(tǒng)結構［2］；(3)遠程醫(yī)療環(huán)境中的智能圖像管理技術［3］。國內遠程會診初期是基于兩地醫(yī)院間的應用，由于信息技術水平及視頻通道等條件所限，會診病人醫(yī)療信息的數(shù)字化準備工作費時費力，通常要建立專門的遠程會診室，并由管理部門預約時間才能進行點對點的遠程會診［4］。

國內有用DICOM網(wǎng)關在WWW網(wǎng)站上瀏覽PACS圖像的文獻報道［5］，但這種方式尚存在以下缺陷：(1)通過WEB獲取的PACS圖像不是DICOM格式，而是經(jīng)過轉換的GIF或JPEG格式，由于這類格式圖像不能進行窗寬窗位的調整，達不到醫(yī)生精確閱片的要求；(2)WEB瀏覽終端不具有上傳DICOM格式圖像的功能，會診流程是單向的，無法實現(xiàn)基于醫(yī)生間相互溝通而稱之為真正意義上的遠程會診；(3)WEB使用Windows的IE瀏覽軟件，IE是Internet網(wǎng)上最主要的不安全因素之一，所以通常的WEB遠程會診應用存在著安全隱患。

雖然IE存在某些缺陷，卻較實用，其中最主要的原因是使用方便。WEB應用是B/S構架，客戶端不需安裝專門軟件，只要能上網(wǎng)就可使用。醫(yī)療過程中的很多診斷都依賴于醫(yī)學影像學的診斷結果［6］，我們認為，只要能解決在IE上瀏覽DICOM格式的PACS圖像和信息安全問題，那么WEB模式的遠程會診就具有實際應用價值。

2 WEB模式遠程會診框架

WEB對向遠程會診，見圖1圖1 WEB雙向遠程會診示意圖

2.1 會診中心 一般指數(shù)字化水平較高的二級以上醫(yī)院，已經(jīng)建立了HIS、PACS、LIS、CIS等信息系統(tǒng)，并建有1個會診用WEB服務器。

2.2 局域網(wǎng) 會診中心的各信息系統(tǒng)建在同一個局域網(wǎng)上，通過RJ-45網(wǎng)線或WIFI無線網(wǎng)絡與中心的會診專家相連。

2.3 SSL VPN網(wǎng)關 保證在會診中心和會診各方，包括通過Internet聯(lián)入的會診雙方或多方之間建立1個安全的信息通道。

2.4 安全網(wǎng)關 在會診中心局域網(wǎng)中建立虛擬網(wǎng)絡空間，使不同的應用在邏輯隔離的空間中獨立運行，某一空間中所有發(fā)生的信息不會影響到其他空間，從而保證會診中心的各類應用互不干擾。

3 WEB遠程會診模式的特點

3.1 雙向互動 （1）下載：從WEB服務器中將病人的PACS圖像和各種報告下載到遠程會診終端上，供會診專家參考。這里要求IE具有瀏覽DICOM格式PACS圖像的功能，具有實時窗位窗寬調整、放大縮小、拖移、旋轉和測量CT值、距離、角度、形狀等功能。（2）上傳：從遠程客戶端的IE瀏覽器上，將具有DICOM格式的PACS圖像或文字信息上傳到WEB服務器，以便遠程會診專家下載會診，要求IE具有讀取病人資料功能。

3.2 多點會診 WEB服務模式可向多用戶提供服務。一個病人可以通過WEB系統(tǒng)由多位專家參與會診；同樣，一位專家也可通過WEB為多個病人提供會診服務。從而建立一個基于醫(yī)患間靈活方便、多點互動的遠程會診平臺。

4 技術方案

4.1 WEB服務器 為保證安全性和高效率，會診中心的HIS和PACS為相互獨立的系統(tǒng)，各有自己的數(shù)據(jù)庫。WEB服務器具有分別針對PACS和HIS的接口軟件，將PACS圖像等關聯(lián)信息（STIDU_INSTANCE_UID）按照標準的信息交換HL7方式，組織成XML文檔提交給HIS系統(tǒng)。同時，當HIS系統(tǒng)根據(jù)病人ID請求訪問PACS時，完成相關病人的PACS圖像的下載和顯示。這樣，會診中心醫(yī)生就可以方便地在HIS系統(tǒng)環(huán)境中獲取病人的PACS資料，直接關聯(lián)到WEB會診的窗口，向遠程的專家提供接入會診的條件。

4.2 專用控件 為保證會診專家在IE上看到PACS圖像是DICOM格式，我們開發(fā)了具有處理DICOM圖像功能的OCX控件。當會診專家通過SSL VPN首次接入WEB會診系統(tǒng)時，IE會自動下載這個OCX控件，并插入IE瀏覽器。以后再次進行遠程會診，就可直接下載具有DICOM格式的PACS圖像，并可作各種滿足PACS醫(yī)學診斷的調整操作。

4.3 圖像的有損和無損壓縮 為提高網(wǎng)絡傳輸和會診的效率，系統(tǒng)設計了通過小圖標關聯(lián)，提供分布式后臺下載無損壓縮的DICOM圖像的方式。在速度相對較慢的網(wǎng)絡條件下，首先提供高壓縮比JPG小圖標，單幅容量約30K左右，而同樣的原始DICOM圖像在500K～5M之間。用戶可以首先瀏覽小圖標初看圖像，然后再根據(jù)需要選擇下載瀏覽大圖像。對彩色圖像或者對精度要求不太高的圖像，可以采用JPG2000有損壓縮，最高壓縮比可達1∶20甚至更高，但以保證診斷質量為前提。通過類似多種處理方式，提高了圖像傳輸速度、降低了網(wǎng)絡流量，從而保證了在低速帶寬模式下的使用方便性與合理性。

4.4 信道與帶寬 WEB模式的遠程會診系統(tǒng)適用4類信道和帶寬：有線局域網(wǎng)100M以上帶寬，完全達到PACS傳輸要求；WIFI無線局域網(wǎng)54M帶寬，傳輸1幅CT圖像0.3s，CR圖像1.3s；ADSL寬帶網(wǎng)2M帶寬，傳輸1幅CT圖像4s，CR圖像70s；CDMA1X無線網(wǎng)絡：153.6K帶寬，傳輸一幅CT圖像12s，CR圖像260s；CDMA1X信道屬于窄帶，實驗證明CT圖像傳輸速度在會診可接受的范圍內，但目前CR圖像傳輸還不太理想，我們將進一步研究解決方法。其他信道，已可以滿足WEB遠程會診的要求。

4.5 SSL VPN SSL(secure sockets layer，安全套接層協(xié)議層) VPN(virtual private net，虛擬專用網(wǎng))是最新VPN技術，其優(yōu)點是：(1)移動用戶使用標準瀏覽器，無需安裝客戶端程序，便可通過SSL VPN隧道遠程接入內部網(wǎng)絡；(2)只需維護中心節(jié)點的網(wǎng)關設備，客戶端免維護，降低了部署和支持費用；(3)SSL VPN是基于應用層的VPN，在基于WEB的應用上更有優(yōu)勢；(4)提供細粒度訪問控制，即可以對用戶的權限、資源、服務、文件等控制得更加細致精確。

4.6 虛擬網(wǎng)絡邏輯隔離 醫(yī)院信息系統(tǒng)的發(fā)展正趨向多功能性，內部應用有HIS、PACS、LIS、CIS、OA辦公系統(tǒng)，上Internet瀏覽也是必需的。為保證各應用信息系統(tǒng)的安全，我們引用虛擬網(wǎng)絡概念，將各應用空間邏輯隔離（而不采取物理隔離方式），相互之間的信息不可交互，并對每個接入網(wǎng)絡的終端外設接口（USB、軟驅、光驅等）加以控制，既保障了網(wǎng)絡安全的可靠性，又減少了投入成本。

5 討論

雙向WEB遠程會診模式突破了醫(yī)院局域網(wǎng)限制，醫(yī)生離開醫(yī)院后，不分時間地點，都能隨時了解住院病人的情況并給予及時處理，提高了工作效率；用于遠程會診，在參與會診醫(yī)生之間建立起互動平臺，雙向交流意見，有利于對病情的深入了解和分析；在醫(yī)療條件較差的邊遠地區(qū)或基層，無論何時何地，只要網(wǎng)絡通暢，就能將影像資料等病人信息迅速傳輸?shù)綍\專家的電腦上，進而得到專家的指導性意見。WEB遠程會診模式的推廣應用，為解決因技術力量不平衡帶來的看病難問題，提供了一個良好的解決方案。

致 謝

本課題為上海市浦東新區(qū)信息化應用推進專項資金資助項目（編號：PKX2003-23）。

參考文獻

1 Katehakis DG，Lelis P，Karabela E，et al.An environment for the creation of an integrated electronic health record in HYGEIA net，the regional health telematics network of crete ［C/OL］.ics.forth.gr/ICS/acti/cmihta/publications/papers/2000/tepr2000/tepr2000.html，Proc TEPR，2000：89-98.

2 Dimitios G，Sfakianakis KS，Tsiknakis M，et al.An infrastructure for integrated electronic health record services:the role of XML，(extensible markup language)［ J/OL］.jmir.org/2001/3/e7.Journal of Medical Internet Research，2001，3(1):e7.

3 Tsiknakia M，Cltronaki CE，Kapidakis S，et al.An integrated architecture for the provision of health telematic services based on digital library technologies.Int J Dig Libr，1997；3:257-277.

4 陳金雄.利用“軍字一號”工程和PACS提高遠程會診水平.解放軍醫(yī)院管理雜志，2002;9(3):274-274.

篇4

1系統(tǒng)整體方案

系統(tǒng)主要研究微控制器、GPRS通信網(wǎng)絡和數(shù)據(jù)中心三部分組成。傳感器采集到數(shù)據(jù)經(jīng)過A/D轉換以及相關處理后發(fā)送到STM32微控制器，STM32通過串口將數(shù)據(jù)發(fā)送到GPRSSIM900A模塊，GPRS無線數(shù)據(jù)傳輸系統(tǒng)與數(shù)據(jù)中心之間一般可通過HTTP協(xié)議建立數(shù)據(jù)連接。將數(shù)據(jù)經(jīng)GPRS空中接口接入無線網(wǎng)絡，并由移動通信連接到網(wǎng)絡，通過網(wǎng)關到達遠程數(shù)據(jù)中心，數(shù)據(jù)中心接受數(shù)據(jù)將其分類整理儲存等。

2STM32芯片特性

意法半導體推出的STM32系列32位微控制器基于ARMCortex-M3內核，包括提升性能的同時又提高了代碼密度的Thumb-2指令集、大幅度提高的中斷響應，而且所有新功能都具有非常低的功耗水平。Cortex-M3處理器在高性能內核基礎上，集成了多種系統(tǒng)外設，可以滿足不同應用對成本和性能的要求。處理器是全部可綜合、高度可定制的（包括物理中斷、系統(tǒng)調試等）。處理器內核是ARMv7-M架構的。Cortex-M3內核是建立在一個高性能哈佛結構的三級流水線基礎上的，可滿足事件驅動的應用需求。STM32的優(yōu)勢是低功耗、高性能，程序在不同核之間的兼容性很好。基于Cortex-M3內核的STM32芯片比其他ARM系列芯片運行速度更快，性能也得到很大提高[2]。

2.1STM32最小系統(tǒng)

2.1.1電源控制電路

基于主控制器STM32F103RCT6的最小系統(tǒng)硬件電路包括電源電路、復位電路、晶振電路接口電路等。STM32處理器工作電壓為2.0~3.6V，常用3.3V。通過內置的電壓調節(jié)器為內核、內存和片上外設提供所需的1.8V電源。為了提高轉換的精度，ADC使用一個獨立的電源供電，過濾和屏蔽一些外部干擾。ADC的電源引腳為VDDA，獨立的電源地VSSA當主電源VDD掉電后，可通過VBAT腳為實時時鐘和備份寄存器提供電源，切換VBAT供電由復位模塊中的掉電復位功能控制。

3STM32與SIM900A通訊鏈接方式

MAX232是TTL—RS232電平轉換的典型芯片，按照芯片的推薦電路，取振蕩電容為uF的時候，若輸入為5V，輸出可以達到-14V左右，輸入為0V，輸出可以達到14V，在扇出電流為20mA的時候，處處電壓可以穩(wěn)定在12V和-12V。因此，在功耗不是很大的情況下，可以將MAX232的輸出信號經(jīng)穩(wěn)壓塊后作電源使用。RS232串口通信分配連接在USART2上，由PA2和PA3連接MAX3232電平轉換芯片，以DB9針形座輸出MAXA3232串口電路圖2所示。

3.1SIM900A模塊

SIM900A是ALIENTEK推出的一款高性能工業(yè)級GSM/GPRS模塊。SIM900A模塊板載是工業(yè)級GSM/GPRS模塊：SIM900A，工作頻段雙頻：900/1800Mhz，SIM900A模塊支持RS232串口，并帶硬件流控制，支持5~24V的超寬工作范圍，可以低功耗實現(xiàn)語音、SMS、數(shù)據(jù)和傳真信息的傳輸[3]。GPRS模塊采用內置HTTP協(xié)議的SIM900A作為數(shù)據(jù)傳輸工具，從而保證數(shù)據(jù)傳輸實時性和可靠性，而且非常經(jīng)濟實用。SIM900A模塊的功能特性如表1所示。

3.2GPRS技術的優(yōu)勢

在GSM網(wǎng)絡中，GPRS首先引入了分組交換的傳輸模式，使得原有的采用電路交換模式的GSM傳輸數(shù)據(jù)發(fā)生了根本變換，這在一定程度上解決了無限資源稀缺的問題。用戶只有充分利用這些空隙，才能充分利用無線資源，從而提高信道利用率[4]。傳輸速率高，GPRS可提供高達115Kbit•s-1的數(shù)據(jù)傳輸速率。這意味著通過便攜式電腦GPRS用戶將可以獲得和ISDN用戶一樣的快速上網(wǎng)瀏覽，使快速網(wǎng)絡服務可以隨時隨地。接入時間短，分組交換接入時間小于1秒，能提供快速即時的連接。可以大幅度提高一些事物的效率，并使現(xiàn)有的Internet操作更加方便、快捷、流暢。GPRS支持Internet上應用最廣泛的IP協(xié)議和X.25協(xié)議。支持X.25協(xié)議可使已經(jīng)存在的X.25應用能夠在GSM網(wǎng)絡上繼續(xù)使用。而且由于GSM網(wǎng)絡覆蓋面廣，所以使得GPRS能夠提供Internet和其他分組網(wǎng)絡的全球性無線接入[6]。

3.3GPRSHTTP服務實現(xiàn)步驟

在本系統(tǒng)中，利用STM32串口2發(fā)送AT指令對SIM900A無線數(shù)據(jù)傳輸模塊的工作狀態(tài)進行控制。首先通過串口2與SIM900A串口相連接。啟動STM32的GPRS通信工作狀態(tài)，串口波特率-9600，相應的AT命令控制GSM模塊工作，詳見下圖5串口子程序流程圖。AT+SAPBR=3，1“，Contype”“，GPRS”；//配置承載AT+SAPBR=3，1，“APN”，“CMNET”；//配置GPRS參數(shù)AT+SAPBR=1，1；//打開承載AT+SAPBR=2，1；//請求承載AT+HTTPINIT；//初始化HTTP協(xié)議AT+HTTPPARA=“CID”，1；//測試HTTP設置值AT+HTTPPARA=“URL”，“/get.php?data=%d%d.%d”//域名訪問，提交數(shù)據(jù)AT+HTTPACTION=0；//HTTP激活方式：GET，上傳數(shù)據(jù)由圖3可見，該SIM900A系統(tǒng)實現(xiàn)了GPRSHTTP服務功能。我們通過該SIM900A系統(tǒng)向云服務器提交了傳感器采集的機車工作狀態(tài)的實時數(shù)據(jù)。

3.4系統(tǒng)通信方式與優(yōu)勢

機車遠程數(shù)據(jù)傳輸系統(tǒng)通過GPRS無線數(shù)據(jù)模塊發(fā)送到云服務器處理存儲。服務器具有固定的IP，所以終端查詢客戶端可以在任何一臺或多臺計算機進行數(shù)據(jù)訪問。服務器提供面向連接、可靠數(shù)據(jù)傳輸服務，能夠實現(xiàn)發(fā)送應答機制，數(shù)據(jù)無差錯、無重復的發(fā)送，且按發(fā)送順序接收，數(shù)據(jù)傳輸系統(tǒng)本身就是可靠鏈路傳輸，提供一個實時的雙向的傳輸通道，能很好的滿足傳輸?shù)囊蟆Ｔ摲桨甘褂梅秶鷱V，費用低廉，穩(wěn)定性強等優(yōu)點來滿足數(shù)據(jù)的傳輸[5]。

4系統(tǒng)方案實現(xiàn)

4.1數(shù)據(jù)中心的設計

數(shù)據(jù)中心的設計主要包括網(wǎng)絡通信的實現(xiàn)，數(shù)據(jù)的接受與發(fā)送和數(shù)據(jù)庫的管理及對傳輸終端的控制。在硬件啟動之后，經(jīng)過系統(tǒng)調度，主要包括：初始化、參數(shù)配置、建立連接、數(shù)據(jù)傳輸、斷開連接五個組成部分。如圖4所示，應用程序流程圖。其中對通信配置主要步驟概括如下：（1）將GPRS模塊的串口線與RAM的串口相連。（2）在調制解調器屬性中輸入AT命令，控制GPRS模塊，完成系統(tǒng)的啟動，獲得GPRS內部固定的IP地址。（3）在計算機系統(tǒng)的調制解調器上重新建立一個新的撥號連接，并將之設為斷線重撥模式。（4）成功登錄GPRS網(wǎng)絡之后，采用HTTP協(xié)議傳輸數(shù)據(jù)，進一步降低編程工作量并同時提高系統(tǒng)的穩(wěn)定性。

4.2終端界面

設計的終端經(jīng)過機車開始工作后，通過傳感器采集到的數(shù)據(jù)監(jiān)測機車田間的工作狀態(tài)、溫度、油耗等，在數(shù)據(jù)中心的界面進行監(jiān)測[6-7]。如圖5所示對溫度測試。GSM模塊定時發(fā)送采集到的數(shù)據(jù)，將作業(yè)狀態(tài)、作業(yè)速度、地理位置信息實時上傳給數(shù)據(jù)中心。機車工作中勻速行駛，遠程數(shù)據(jù)采集以定時采集的模式向遠程監(jiān)測中心上傳數(shù)據(jù)，時間間隔設定值最小為20s，最大達到24小時。這樣作業(yè)時間間隔與實時間隔一致，使系統(tǒng)數(shù)據(jù)傳輸穩(wěn)定性好，實時性強。機車作業(yè)過程中，遠程數(shù)據(jù)中心通過讀取數(shù)據(jù)采集器發(fā)送的地理位置信息，實時對機車進行作業(yè)軌跡的動態(tài)跟隨（如圖6所示）。

5結論

篇5

【關鍵詞】WITSML；隨鉆測井；分布式系統(tǒng)設計

A Type of WITSML Based Teletransmission System of LWD Operating Data

DENG Xiao-qing LU Hua-tao YIN Bo

（China Oilfield Service Ltd，Sanhe Hebei 065201，China）

【Abstract】The Drilog LWD System， which was developed by COSL and applied successfully in oilfield， has realized the function of realtime teletransmission of LWD operating data from wellsite to the base. This paper has stated the design and implement of a type of WITSML based teletransmission system of LWD operating data.

【Key words】WITSML； LWD； Distribute System； Design

0 引言

在油田開發(fā)作業(yè)中，要將作業(yè)數(shù)據(jù)實時傳輸?shù)焦净氐姆掌魃希＜液凸芾碚邔崟r監(jiān)控，提供決策支持。由BP和Statoil發(fā)起，并與Baker Hughes，Halliburton/Landmark以及Schlumberger等主要油田服務公司合作，發(fā)展形成了WITSML（Wellsite Information Transfer Standard Mark-up Language 井場信息傳遞標準標記語言）協(xié)議[1]。

由中海油服自主研發(fā)的隨鉆測井系統(tǒng)Drilog 進入了商業(yè)化海上作業(yè)階段。隨鉆作業(yè)數(shù)據(jù)的實時傳輸功能也納入到了該系統(tǒng)的IDEAS隨鉆測井地面系統(tǒng)軟件之中，并在現(xiàn)場得到運用。

1 系統(tǒng)功能與組成

Drilog系統(tǒng)在作業(yè)中，基于WITSML的隨鉆作業(yè)數(shù)據(jù)傳輸系統(tǒng)將作業(yè)數(shù)據(jù)，包括井場信息、鉆井數(shù)據(jù)、測井數(shù)據(jù)從IDEAS系統(tǒng)提取出來轉化為WITSML格式數(shù)據(jù)，然后以SOAP協(xié)議[3]發(fā)送到基地的作業(yè)信息服務器。服務器按照WITSML協(xié)議將數(shù)據(jù)保存并提供訪問接口。基地技術支持和專家們通過Web客戶端，實時訪問最新或者歷史數(shù)據(jù)，監(jiān)控油田開發(fā)，提供決策支持。

根據(jù)以上場景描述，我們將系統(tǒng)劃分為三個部分：發(fā)送終端、數(shù)據(jù)服務器和Web瀏覽服務。系統(tǒng)架構如圖1所示。

2 發(fā)送終端

發(fā)送終端WitsmlSender運行于作業(yè)現(xiàn)場。主要功能為提取地面系統(tǒng)數(shù)據(jù)或第三方WITSML文件，按照WITSML格式發(fā)送。

技術方案上，WitsmlSender程序采用.Net平臺進行開發(fā)，采用輕型開源數(shù)據(jù)庫SQLite作為緩存數(shù)據(jù)庫。使用WITSML標準制定方官網(wǎng)提供的開發(fā)者工具包組件DevKit作為格式轉換的主要工具。程序主要分為：界面顯示層、業(yè)務邏輯層和數(shù)據(jù)訪問層。界面顯示層主要負責程序界面的顯示及交互，業(yè)務邏輯層主要負責基本數(shù)據(jù)及操作邏輯的實現(xiàn)。數(shù)據(jù)訪問層主要負責底層數(shù)據(jù)的讀寫。WitsmlSender程序的主界面如圖2所示：

WitsmlSender由8個庫模塊和2個第三方庫組成。部分為WITSML標準委員會官方提供的封裝了WITSML協(xié)議的通信以及WITSML對象的序列化、反序列化操作的類庫。

3 數(shù)據(jù)服務器

數(shù)據(jù)服務器提供WITSML數(shù)據(jù)讀寫接口服務。WITSML服務器以Web Service的方式進行實現(xiàn)。根據(jù)WITSML標準的規(guī)定，需實現(xiàn)以下公共接口[4]：WMLS_AddToStore、

aseMsg、WMLS_GetCap、WMLS_GetFromStore、WMLS_GetVersion、WM-

LS_UpdateInStore。在實現(xiàn)接口的過程中，涉及到WITSML文件的解析、WITSML與數(shù)據(jù)對象的轉換、數(shù)據(jù)存儲等功能[5]。

數(shù)據(jù)服務器程序用.Net平臺開發(fā)。以SQL Server作底層數(shù)據(jù)庫。主要設計層次為：公共接口層、業(yè)務邏輯層和數(shù)據(jù)訪問層。公共接口層主要負責WITSML標準接口的實現(xiàn)和公開；業(yè)務邏輯層主要負責基本數(shù)據(jù)結構及邏輯的實現(xiàn)；數(shù)據(jù)訪問層主要負責底層數(shù)據(jù)的讀寫。

數(shù)據(jù)存儲的功能為實現(xiàn)WITSML的標準接口，主要為WITSML對象的表結構設計。表結構設計如圖3所示。其中：井表（Well）：用于存儲井相關數(shù)據(jù)。井筒表（WellBore）：用于存儲井筒相關數(shù)據(jù)。測井表（WellLog）：用于存儲測井相關數(shù)據(jù)。測井曲線表（WellLogCurve）：用于存儲測井曲線相關數(shù)據(jù)。公共數(shù)據(jù)表（CommonData）：用于存儲公共數(shù)據(jù)相關數(shù)據(jù)。

4 數(shù)據(jù)瀏覽服務

數(shù)據(jù)瀏覽服務將WITSML格式的數(shù)據(jù)綁定到網(wǎng)頁中進行曲線、儀表等多種形式的展示，并為用戶提供多種顯示方案。同時提供用戶瀏覽權限管理。

瀏覽服務程序是按照Browser/Server客戶端設計模式，使用ASP開發(fā)。為了達到理想效果，曲線和儀表樣式都通過第三方控件來實現(xiàn)。測井曲線等復雜控件則是以SVG（Scalable Vector Graphics）[6]格式繪制，需要8.0及以上版本IE瀏覽器支持。數(shù)據(jù)模板是用XML文件靈活配置。數(shù)據(jù)顯示區(qū)域頁面圖4所示。

圖4 數(shù)據(jù)顯示頁面

用戶權限控制由用戶信息數(shù)據(jù)庫支持。用戶信息庫與隨鉆作業(yè)數(shù)據(jù)庫是隔離的。這樣既保證了作業(yè)數(shù)據(jù)的安全性，也達到低耦合的設計原則。用戶管理、權限分配、數(shù)據(jù)顯示模板分配頁面只有管理員用戶才能看到。

5 總結

這種隨鉆作業(yè)數(shù)據(jù)遠程傳輸系統(tǒng)，利用分布式系統(tǒng)設計模式，實現(xiàn)了隨鉆作業(yè)數(shù)據(jù)從專用模式，轉化為標準格式數(shù)據(jù)，并實現(xiàn)了實時遠程傳輸。進而實現(xiàn)了WITSML格式的隨鉆作業(yè)數(shù)據(jù)的遠程瀏覽，為實時地質導向決策等服務奠定了基礎。

系統(tǒng)在實現(xiàn)完成后，已隨Drilog隨鉆測井系統(tǒng)在渤海油田累計完成了29井次的海上油田生產(chǎn)作業(yè)任務。系統(tǒng)的穩(wěn)定性與數(shù)據(jù)實時性都得到了驗證。

【參考文獻】

[1]M.A Kirkman， SPE，BP； M.E Symmonds， SPE， Schlumberger等，Wellsite Information Transfer Standard Mark-up Language， WITSML， an Update（SPE 84066）.

[2]王智明，尚捷，菅志軍，等.SPOTE 隨鉆測井系統(tǒng)的試驗研究[J].承德石油高等專科學校學報，2012，14（3）：25-30.

[3]D Box. Simple Objext Access Protocol（SOAP） I.1.World Wide Web Consortium （W3C）[EB/OL].http：///TR/SOAP 2000.

[4]Web Services 安全規(guī)范[EB/OL]. http：///developerworks/library/ws-secure/ 2002.

篇6

【關鍵詞】數(shù)據(jù)傳輸；VB6.0；Winsock控件；協(xié)議

在遠程數(shù)據(jù)采集和傳輸系統(tǒng)中，傳統(tǒng)的方法有2 種：一是采用RS-485進行遠程控制；二是通過調制解調器進入電話線來實現(xiàn)遠程控制，然而這2 種方法都有自己的缺點。這樣一來就限制了它們的應用范圍。

本文介紹了在VB6.0中利用Winsock控件來實現(xiàn)服務器端與遠程客戶端建立連接并進行數(shù)據(jù)傳輸?shù)姆椒ā?/p>

一、基于Winsock控件的遠程數(shù)據(jù)傳輸

（一） Winsock控件簡介

Microsoft提供的Winsock控件，是ActiveX控件的一種。在VB中可以將其添加到工具箱中以便使用。在程序運行時，Winsock控件是不可見的，但通過對其屬性、方法、事件的設置及應用可輕松地實現(xiàn)計算機間的遠程連接，該控件為用戶提供了訪問TCP和UDP網(wǎng)絡及其方便的途徑，不需要了解低級Winsock API調用實現(xiàn)的細節(jié)。VB的Winsock控件內部幾乎封裝了所有的Internet協(xié)議，以類的形式提供了屬性、方法、事件，使得程序得到了極大的簡化。

Winsock控件的常用屬性如表1。

（二）傳輸協(xié)議

在使用Winsock控件時，首先要考慮使用什么通信協(xié)議。可供選擇的協(xié)議有傳輸控制協(xié)議（TCP）和用戶數(shù)據(jù)報協(xié)議（UDP），都是位于傳輸層的協(xié)議、使用端口號來識別應用程序，區(qū)別在于連接的狀態(tài)。TCP協(xié)議是一個基于連接的協(xié)議，在收發(fā)數(shù)據(jù)前必須建立連接，并且該連接可靠性強，使數(shù)據(jù)無差錯地傳輸，適合有確認信息的、重要的、數(shù)據(jù)量大（如聲音和圖像）的文件。UDP協(xié)議是不與對方建立連接而是直接就把數(shù)據(jù)報發(fā)送過去。傳輸速度較快也較便宜，適用于少量數(shù)據(jù)傳送、可靠性

要求不高的文件傳輸。本文中均選用TCP協(xié)議。

（三）遠程數(shù)據(jù)傳輸系統(tǒng)軟件設計

1、遠程傳輸系統(tǒng)軟件流程

軟件在Visual Basic環(huán)境下開發(fā)，利用Winsock控件完成客戶端與服務器端的相互通訊。

創(chuàng)建客戶端程序時，必須知道服務器端的IP地址（RemoteHost屬性）和服務器“偵聽”的端口（RemotePort 屬性）然后調用 Connect 方法請求與服務器連接。

創(chuàng)建服務器端程序時，必須設置一個收聽端口（LocalPort屬性）并調用Listen方法偵聽端口，本論文中使用的IP地址為202.205.84.222，使用的端口號為2020。當客戶端請求連接時就會發(fā)生ConnectionRequest事件。為了完成連接，可調用ConnectionRequest事件內的Accept方法與客戶端進行連接。

連接建立后，雙方就可以相互收發(fā)數(shù)據(jù)。通過調用 SendData方法完成數(shù)據(jù)發(fā)送。接收數(shù)據(jù)時會觸發(fā)DataArrival事件，調用DataArrival事件內的 GetData方法獲取數(shù)據(jù)。

2、服務器端程序設計

（1）服務器端窗體加載事件

利用Private Sub Form_Load（）加載，并且設置本地

端口，打開偵聽，獲取并顯示本地狀態(tài)信息。

（2）與客戶端的連接

客戶端發(fā)出連接請求時，觸發(fā)ConnectionRequest事件，并調用Accept方法完成連接。如果本地有連接，則斷開，因為不能同時接受兩組數(shù)據(jù)

（3）建立連接

利用socks.Accept requestID接收當前連接，并顯示遠程計算機名、客戶端IP及遠程端口名稱等遠程狀態(tài)信息。

（4） 接收數(shù)據(jù)

當客戶端發(fā)送的數(shù)據(jù)到達時，觸發(fā)DataArrival事件，并調用GetData方法獲取數(shù)據(jù)

（5）確認信息

當客戶端數(shù)據(jù)發(fā)送完畢，觸發(fā)SendComplete事件，服務器端會將發(fā)送的內容回發(fā)作為接收到數(shù)據(jù)的確認信息。

1、客戶端程序設計

（1）客戶端窗體加載事件

利用Private Sub Form_Load（）加載，并且指定欲建立連接的服務器IP及端口名稱，并隨時偵測連接是否成功。

（2）客戶端向服務器端發(fā)送連接請求

利用Private Sub sockcl_Connect（）進行偵測，一旦成功連接，便向服務器發(fā)送客戶端數(shù)據(jù)。

（3）服務器接收客戶端發(fā)送的數(shù)據(jù)

當客戶端端發(fā)送的數(shù)據(jù)到達時，觸發(fā)DataArrival事件，并調用GetData方法獲取數(shù)據(jù)。

（4）確認信息

二、實驗結果及分析

（一）實驗環(huán)境描述

實驗中的客戶端是遠程數(shù)據(jù)采集系統(tǒng)，利用單片機作為主控制芯片，利用各種傳感器采集現(xiàn)場數(shù)據(jù)，通過A/D轉換送到單片機中。單片機通過串口與GPRS模塊連接，實現(xiàn)與移動網(wǎng)的連接，再與Internet連接。

（二）實驗結果及分析

實驗只采用8路差分模擬輸入的3路――AI 6、AI 7、AI 8，因為存在干擾，固前5路的數(shù)值還有一些誤差。顯示的數(shù)值不表示實際溫度、濕度值，需經(jīng)過轉換，轉換后與實際測量值進行比較，證實該方法傳輸數(shù)據(jù)的可

靠性。程序和整個系統(tǒng)均有待改進。

三、結束語

Winsock是編制各種C/S程序的利器，不僅很好地解決了分散的溫度、濕度遠程數(shù)據(jù)采集系統(tǒng)，并能有效可靠地進行傳輸，還能開發(fā)聊天程序、搶答系統(tǒng)[9]等。算法具有簡單性，且易實現(xiàn)。

參考文獻：

[1]葉紀聽.基于VB編程實現(xiàn)網(wǎng)絡文件數(shù)據(jù)傳遞的實現(xiàn)[J]. 電腦知識與技術，2014，22：5235-5239.

[2]陳萍，高騰，劉兆峰，高雪為，詹鵬飛.基于GPRS的熱力管網(wǎng)監(jiān)測軟件設計[J].山東建筑大學學報，2011，04：403-406+410.

篇7

引 言

每一個油田都擁有眾多的油氣井, 并且分布在山川曠野里，油氣井的管理方式多為由人工每日值守，定時檢查設備運行情況，記錄相關數(shù)據(jù)。這種方式增加了用工人數(shù)，加大了護井工勞動強度，最重要的是影響對設備的監(jiān)控。當抽油機、電泵出現(xiàn)微小故障時，往往很難被人工及時發(fā)現(xiàn)，從而得不到有效地防護與控制［9］。

為了能有效地發(fā)現(xiàn)油井、地層、油藏的變化，可用油井遠程測控系統(tǒng),通過在抽油機上安裝位移傳感器和載荷傳感器，檢測抽油機的工況，實時在線監(jiān)測抽油機工作參數(shù)，及時發(fā)現(xiàn)故障并報警，及時維護。本文提出了一種基于rtu的油井遠程測控系統(tǒng)的數(shù)據(jù)采集與傳輸層設計方案，并將該方案用于實際的井場應用中。

1 油井遠程測控系統(tǒng)總體架構

油井遠程測控系統(tǒng)的總體架構如圖1所示，整個測控系統(tǒng)的組網(wǎng)架構分為現(xiàn)場局域網(wǎng)、企業(yè)信息網(wǎng)兩大部分。網(wǎng)絡拓撲采用分層星型拓撲，是為了在中央測控室的中央測控服務器與現(xiàn)場局域網(wǎng)的各個測控服務器的測控對象之間建立更有效的連接方式。每個測控分站設測控服務器，實時發(fā)送或讀取的井場設備數(shù)據(jù)先經(jīng)測控服務器處理后再并行傳輸?shù)街醒霚y控服務器，這樣既讓等級高的設備預警信號得到現(xiàn)場級的及時響應，又減輕了中央測控服務器處理數(shù)據(jù)的壓力。web服務器與中央測控服務器通過數(shù)據(jù)庫服務器連接，這種連接方式使web服務器面向的對象是數(shù)據(jù)庫服務器，有利于web服務器在處理管理用戶的指令時與中央監(jiān)控服務器保持一定的時差，避免了相互動作間的沖突［2］。而所有這些數(shù)據(jù)來自于測控服務器通過井場數(shù)據(jù)采集與傳輸層得到的。it目前最常見的數(shù)據(jù)采集與傳輸層的工作方式有圖1所示的兩種情況。其中井場1針對安裝多個傳感器的油氣井，在每個油氣井處安裝一個rtu從站,能夠對該油氣井的傳感器進行統(tǒng)一管理，并在每個井場設置一個rtu主站，采用主叫/從響應的方式，采集各從站的傳感器數(shù)據(jù)，然后將各從站數(shù)據(jù)上傳到上位機(測控服務器)；井場2針對安裝幾個傳感器的油氣井，在每個井場放置一個rtu,直接將傳感器的數(shù)據(jù)采集后發(fā)送到上位機；為了能夠兼容這兩種工作方式，本文設計了一個基于rtu的數(shù)據(jù)采集與傳輸層系統(tǒng)軟件。

2 數(shù)據(jù)采集與傳輸層硬件基礎——rtu

有些油氣田由于地理原因，不易鋪設電纜，本系統(tǒng)引入物聯(lián)網(wǎng)技術，加入無線通信zigbee模塊,并利用其自組織原理，實現(xiàn)在井場無線自組織尋址和數(shù)據(jù)傳輸,可以簡單、方便地實現(xiàn)井場實時數(shù)據(jù)采集，利用這些有效數(shù)據(jù)指導油田油氣生產(chǎn),提高產(chǎn)量,其構成一個物聯(lián)網(wǎng)回路,改變了油田生產(chǎn)方式［5］。

油井遠程測控系統(tǒng)rtu采用samsung公司的s3c2440a，具有400 mhz的工作頻率，主要控制數(shù)據(jù)流的輸入輸出；采用具有2 mb存儲能力的nor flash (en29lv160ab)存儲程序；用有128 mb存儲能力的nand flash(k9f2g08u0b)存儲數(shù)據(jù)；利用ad轉換器ads7952采集8通道12位模擬數(shù)據(jù)；系統(tǒng)環(huán)境溫度由溫度傳感器tmp100獲得；考慮到zigbee模塊的接口以及有線方式下的長距離傳輸?shù)纫蛩兀瑀tu的串行鏈路口為rs 232及rs 485；為與測控服務器pc機相連，rtu采用dm9000實現(xiàn)以太網(wǎng)連接；rtu的初始配置信息采用e2prom存儲；rtu內還包含隔離電路、控制單元等幾個部分。rtu的硬件框圖如圖2所示。

3 數(shù)據(jù)采集與傳輸層系統(tǒng)軟件

3.1 數(shù)據(jù)采集與傳輸層通信協(xié)議

modbus通信協(xié)議已經(jīng)非常廣泛地應用于自動控制和通信領域中，通過此協(xié)議，控制器相互之間、控制器經(jīng)由網(wǎng)絡(例如以太網(wǎng))和其它設備之間可以實現(xiàn)通信。modbus網(wǎng)絡屬于一種主從網(wǎng)絡，允許一個主站和一個或多個從站通信。它采用命令/應答方式，每種命令報文都對應著一種應答報文。網(wǎng)絡中的每個從站都必須分配一個唯一的地址。主站發(fā)出的命令中含有要求訪問的從站地址，只有具有該地址的從站才會對該命令響應。

3.1.1 modbus/rtu通信協(xié)議

rtu主/從站串口通信時，通常使用的是modbus/rtu傳輸模式。在modbus報文rtu幀中，如果兩個字符之間的空閑間隔大于1.5個字符時間，那就認為報文幀不完整，此時接收站應該丟棄這個報文。時長至少為3.5個字符時間的空閑間隔將報文幀區(qū)分。rtu消息幀的典型格式如表1所列。

表1 modbus/rtu消息幀典型格式

地址設備功能碼數(shù)據(jù)crc校驗

8 bits8 bits8n bits16 bits

轉貼于

3.1.2 modbus/tcp通信協(xié)議

modbus/tcp是一種應用層的協(xié)議，上層為 modbus協(xié)議,下層為 tcp協(xié)議，它規(guī)定了網(wǎng)絡互聯(lián)節(jié)點間的請求/應答的通信方式。幀格式必須嚴格遵守協(xié)議所規(guī)定的adu(application data unit)格式，才能在以太網(wǎng)上實現(xiàn)數(shù)據(jù)的傳輸。圖3所示即為 modbus/tcp的數(shù)據(jù)幀格式［3］。

mbap報文頭 (modbus application protocol header)是tcp/ip使用的專用報文頭，用來識別modbus的應用數(shù)據(jù)單元。mbap共有 7個字節(jié)，其具體組成及含義如表 2所列。

國際互聯(lián)網(wǎng)編號分配管理機構iana(internet assigned numbers authority)專門為其賦予了一個tcp端口號502端口，利用tcp發(fā)送所有的modbus/tcp adu［1］。

3.1.3 modbus/tcp與modbus rtu數(shù)據(jù)幀的區(qū)別

modbus/tcp雖然包括了從站地址、功能碼和傳輸?shù)臄?shù)據(jù)，但是沒有校驗控制碼，這是因為modbus/tcp校驗功能已經(jīng)在下面的四層如 tcp/ip協(xié)議和鏈路層的校驗機制得到了保證。

3.2 數(shù)據(jù)采集與傳輸層系統(tǒng)軟件設計

油井遠程測控系統(tǒng)的數(shù)據(jù)采集與傳輸層主要完成的功能：傳感器數(shù)據(jù)的采集、傳輸和對繼電器的控制。圖1中提到了兩種常見的工作方式。在井場1中存在rtu主站和從站：主站主要負責對各從站進行輪詢、數(shù)據(jù)打包和向上位機發(fā)送數(shù)據(jù)，從站主要負責數(shù)據(jù)的采集、繼電器的控制和輪詢命令的響應，主從站之間的通信使用的是modbus/rtu。在井場2中只存在一個rtu，主要完成數(shù)據(jù)的采集、繼電器的控制和向上位機發(fā)送數(shù)據(jù)，通信使用的是modbus/tcp。在數(shù)據(jù)采集與傳輸層的工作過程中，考慮到系統(tǒng)的兼容性，對rtu軟件設計提出了可配置的要求，不需要重新下載程序，只需要使用系統(tǒng)配置軟件就可選擇不同的工作方式和通信方式，這就保證了系統(tǒng)的可操作性和兼容性，系統(tǒng)的適應性大大加強。

在軟件開發(fā)過程中，考慮到串行通信速度較慢的特點，采用多線程技術，故引入實時操作系統(tǒng)μc/os_ii，將modbus/rtu通信、modbus/tcp通信等放在單獨的線程中進行，而數(shù)據(jù)采集和控制等則采用另外的線程實現(xiàn)。

3.2.1 μc/os_ii的移植

μc/os_ii是可移植、可剪裁的搶占式實時多任務操作系統(tǒng)內核，適用于工業(yè)控制中的實時監(jiān)控。本系統(tǒng)成功地將實時操作系統(tǒng)μc/os_ii移植到s3c2440a微處理器上，并實現(xiàn)了modbus通信協(xié)議。

μc/os_ii可以管理64個任務，具有信號量、互斥信號量、消息隊列、任務管理、時間管理和內存塊管理等系統(tǒng)功能。μc/os_ii的移植主要包括三部分代碼：μc/os_ii核心代碼、μc/os_ii配置代碼、μc/os_ii移植代碼。其中μc/os_ii移植代碼包括1個匯編文件、1個c程序文件和1個頭文件。這部分代碼與微處理器相關，是移植的關鍵［6］。

3.2.2 modbus通信的實現(xiàn)

rtu與上位機使用modbus/tcp進行以太網(wǎng)通信時，需不斷接收上位機發(fā)送的查詢命令，處于服務器(從站)狀態(tài)。rtu在使用modbus/rtu進行串口通信時，需單獨完成主從站功能。在實際應用中，不存在modbus/tcp和modbus/rtu的從站并存在同一rtu的情況，因而在程序編寫過程中，modbus/tcp和modbus/rtu的從站使用同一個modbus從站庫，但對其幀頭的處理略有不同。以下分別講述modbus/tcp服務器(從站)在tcp/ip協(xié)議棧上的實現(xiàn)以及modbus/rtu主站在串口通信上的實現(xiàn)。

(1) modbus/tcp通信協(xié)議實現(xiàn)

由于操作系統(tǒng)μc/os_ii本身沒有tcp/ip協(xié)議棧，故先移植嵌入tcp/ip協(xié)議棧，再編寫modbus/tcp服務器(從站)程序。在μc/os_ii下嵌入了tcp/ip協(xié)議棧后就監(jiān)聽tcp502端口的連接請求，只有在與客戶機建立了連接之后才能進行數(shù)據(jù)處理。服務器端在收到客戶機的請求之后，會確認和客戶機的連接，同時接收并分析客戶機的請求報文。如果 mbap報文頭正確，則讀完所有的報文，只有協(xié)議類型值為0x00時才對請求幀進行下一步操作，否則直接丟棄報文。接著分析 pdu中的功能代碼，不同的功能對參數(shù)要求也不同，最后根據(jù)數(shù)據(jù)域中的參數(shù)規(guī)定，執(zhí)行相應的操作。若有錯誤出現(xiàn)，直接丟棄報文，仍繼續(xù)處理 pdu的數(shù)據(jù)顯得不必要，影響實時性。根據(jù)對客戶端請求報文的分析處理，有兩種響應結果，一種是正常的響應報文，另一種是異常響應報文，即返回的是錯誤信息。其modbus/tcp的從站通信流程如圖4所示。

圖4 modbus/tcp服務器(從站)設計流程圖

(2) modbus/rtu通信協(xié)議實現(xiàn)

modbus主站需要處理發(fā)送請求幀、等待應答、處理應答、處理差錯和等待轉換延時等事件。其主站設計流程如圖5所示。

modbus/rtu報文幀是否完整和幀與幀之間的區(qū)分可以通過空閑間隔來實現(xiàn)，但這需要使用定時器完成1.5個字符和3.5個字符的定時，并在定時到后，進入接收處理函數(shù)，然后實現(xiàn)adu數(shù)據(jù)到pdu數(shù)據(jù)的處理。

3.2.3 系統(tǒng)軟件的實現(xiàn)

系統(tǒng)上電后，首先進行初始化操作，主要包括設置串口、定時器等內容，并讀取eeprom中的配置信轉貼于

息，對rtu進行配置，包括主從工作模式選擇、ip地址設置、輪詢的通信方式選擇、傳感器的開關狀態(tài)、繼電器輸出狀態(tài)等。若處于主站狀態(tài)，還可以獲取從站配置信息并配置從站，配置成功后，主站開始對各從站進行掃描，并對從站報文進行處理；每掃描完一個從站，主站就對輪詢到的數(shù)據(jù)進行存儲；在掃描從站的同時，如果主站傳感器和外部繼電器處于開狀態(tài)，會同時采集模擬通道和數(shù)字通道的數(shù)據(jù)并控制外部繼電器，采集到的數(shù)據(jù)存于相應寄存器中，等待上位機請求命令，按照modbus協(xié)議將相應數(shù)據(jù)打包，并上傳到上位機。若處于從站，采集模擬通道和數(shù)字通道的數(shù)據(jù)并控制外部繼電器，采集到的數(shù)據(jù)存于相應寄存器中，并等待rtu主站輪詢命令，當輪詢到該從站時，按modbus協(xié)議打包數(shù)據(jù)并發(fā)送到rtu主站。不管該rtu是主站還是從站，其tcp/ip的服務器程序一直等待系統(tǒng)配置軟件的配置信息，當收到配置信息后，將數(shù)據(jù)存入eeprom并復位系統(tǒng)程序，整個系統(tǒng)設計流程圖如圖6所示。

從圖6中可以同時看到modbus/rtu和modbus/tcp的從站處理函數(shù)，在實際應用中，rtu處于modbus/rtu主站時，其modbus/rtu從站的處理任務不運行，modbus/tcp從站的處理任務運行,該狀態(tài)下rtu可用于圖1中井場1的rtu主站和井場2的rtu兩種情況;處于modbus/rtu從站時，該狀態(tài)下rtu可用于圖1中井場1的從站情況，以太網(wǎng)服務器任務只等待配置信息。

4 測試

本系統(tǒng)的測試采用了第三方的modbus測試工具modbus poll v4.3.3、modbus slave v4.3.1和實驗室自主開發(fā)的配置軟件。

4.1 輪詢測試

利用系統(tǒng)配置軟件的界面如圖7所示，設置一個rtu主站和兩個rtu從站，在一臺pc機上運行modbus poll程序，模擬modbus/tcp客戶機，通過以太網(wǎng)與rtu主站相連，rtu主從站之間通過無線zigbee模塊(或rs 485模塊)相連。串行通信的波特率設置為38 400 b/s，無校驗位，停止位為1位。

pc端的modbus/tcp客戶機可向rtu主站發(fā)送命令，并讀取存于rtu主站輸入寄存器的從站數(shù)據(jù)。當從站的數(shù)字輸入端接高電平(24 v)時，從modbus poll的對應地址可讀取到1，圖8所示是modbus/tcp客戶機接收到的輪詢數(shù)據(jù)，其中地址500~507為從站1中8通道數(shù)字輸入端對應的狀態(tài)值；地址508~515為從站2中8通道數(shù)字輸入端對應的狀態(tài)值。經(jīng)多次測量，均正確無誤。

4.2 控制測試

pc端模擬的modbus/tcp客戶機向rtu的保持寄存器寫入數(shù)據(jù)，rtu會將對應寄存器的數(shù)據(jù)輸出到對應的數(shù)字輸出端口，例如地址100對應數(shù)字輸出端口0，當對地址100置1時，對應指示燈亮，輸出高電平。

4.3 數(shù)據(jù)采集測試

轉貼于

rtu模擬輸入端0接一定頻率的正弦波，數(shù)字輸入端接高電平信號，利用modbus poll查詢rtu模擬輸入端與數(shù)字輸入端的數(shù)據(jù)。

圖9所示為modbus/tcp客戶機所接收到的采集數(shù)據(jù)。

rtu采集到數(shù)字輸入端的脈沖值以及開關狀態(tài)，地址0~7對應相應通道的脈沖值，地址8~15對應相應通道的開關狀態(tài)值；地址19為rtu板上的溫度傳感器的值，當前rtu的溫度是24 ℃；地址20~49為模擬通道0采集到的正弦波信號，之后為其他通道采集到的ad值，每個通道的采樣點數(shù)和頻率可調。

篇8

成型機的機械化、聯(lián)動化、自動化發(fā)展很快.目前,成型設備已由完備的成型鼓、帶束層貼合鼓、功能齊全的供料架、傳遞環(huán)、壓輥裝置及自動的激光指示燈系統(tǒng)組成.在成型過程中的各種布料及橡膠部件的導開、定長、截斷、送頭、貼合、接頭以及鋼絲圈的輸送就位等工序均由機械化、聯(lián)動化的功能來執(zhí)行.這些動作又通過各種傳感元件將信號輸送到PLC,由電腦進行控制,用以實現(xiàn)一定程度的自動化生產(chǎn)過程.現(xiàn)在的成型機每個鼓擔負許多功能,很多工序必須在一個鼓上完成,這勢必導致供料架的復雜化以及聯(lián)動動作的相互干擾,不利于成型過程的全自動化控制.如果將每個工序由一個鼓來完成,則供料機構也可以分解,這對全自動化技術的設計將帶來很大方便.

工業(yè)化國家已投入了大量的人力、物力、財力對全自動化輪胎成型技術及設備進行了多年研究,目前有些技術和成型設備已經(jīng)具備投產(chǎn)條件,但是他們對這些技術都進行了嚴格保密.從一些資料中可以看出目前國內外新技術具有如下共同點:以成型為中心,全面鋪開自動化操作;采用低溫連續(xù)混煉工藝;撤并部件預制及停放工序.可見,全自動化輪胎成型技術將是最具有發(fā)展前景和最活躍的發(fā)展動向[1].

為進一步提高輪胎企業(yè)綜合自動化水平,使綜合自動化技術深入到輪胎成型各生產(chǎn)設備,實現(xiàn)及時掌握成型設備運轉狀況,力求達到無人值守,全面提高輪胎生產(chǎn)的管理水平,開發(fā)設計了組合成型生產(chǎn)線綜合數(shù)據(jù)采集與監(jiān)控系統(tǒng).在該系統(tǒng)中,由于移動鼓存在移動工作特性,其電氣參數(shù)的傳輸需采用無線收發(fā)方式與監(jiān)控系統(tǒng)聯(lián)網(wǎng).隨著通信技術的發(fā)展,信息的獲取與傳輸方式逐步從有線過渡到無線.作為無線通信方式的一種,無線數(shù)傳技術近年來得到了廣泛關注及應用,相應的產(chǎn)品也已滲透到社會生活的各個領域,如工業(yè)數(shù)據(jù)采集、無線抄表、區(qū)域報警系統(tǒng)、城市路燈監(jiān)控、水文監(jiān)測、熱網(wǎng)與氣網(wǎng)監(jiān)控、環(huán)境監(jiān)測等[2].在移動成型鼓上,通過連線的方法得到傳感器的信號顯然有一定難度.采用無線方式來實現(xiàn)信號的傳送,可以較好地解決這一問題[3].

1新概念成型生產(chǎn)線單元組成

成型生產(chǎn)線是一個復雜的系統(tǒng),系統(tǒng)輸入的是與制造有關的物料、設備、工具、能源、人員、制造理論、制造工藝和制造信息等,輸出的是一個合格的產(chǎn)品[4],新概念組合式成型生產(chǎn)線在模型建立的過程中考慮系統(tǒng)的可重構性,目的在于改進系統(tǒng)的內部架構,更加適應于市場需求的變化,更好地滿足客戶的需求,最大限度延長系統(tǒng)的生命周期,包含可重構特性設計的生產(chǎn)線在系統(tǒng)發(fā)生故障時可以通過系統(tǒng)內部的一次重組來切換或替換故障單元,起著補充和冗余的作用.組合式生產(chǎn)線具有全自動化的因素,在系統(tǒng)發(fā)生故障后,可以通過故障檢測和定位采取相應的故障處理策略使系統(tǒng)從故障狀態(tài)恢復到正常工作狀態(tài).組合式可重構成型系統(tǒng)連續(xù)工作模擬流程以及內部動態(tài)重構如圖1和圖2所示。

基于上述思想在成型工藝流程中對各個環(huán)節(jié)進行分解,如圖3所示,依據(jù)分解環(huán)節(jié)建立組合式生產(chǎn)線模型.組合生產(chǎn)線中移動鼓是帶有地面安裝軌道的傳遞式設備,圍繞輪胎成型生產(chǎn)線可配置一些不同部件的供料裝置,例如:帶束層供料裝置;冠帶層供料裝置;供胎面裝置;胎體供料裝置;壓合裝置.所有這些設備和供料裝置可組成一個完整的組合輪胎成型生產(chǎn)線.系統(tǒng)的設計所要達到的第一個目的是減少人工操作的含量,這不僅僅為了增加生產(chǎn)能力,也是為了改善重構性.組合輪胎成型生產(chǎn)線是高度自動化的生產(chǎn)線,人工操作含量被減到最小,具有高生產(chǎn)能力.帶束層自動供料裝置設計成具有自動測量(沒有變形),定長切割,精確導向定位功能等單元,包括:①主機架結合件,上面裝有兩個驅動滾道輸送裝置,同時每個輸送裝置的頂部有帶束層裁斷系統(tǒng);②兩個導開工位,用標準的或定做的卷軸;③帶束層裁斷系統(tǒng);④帶束層導向對中系統(tǒng),可實現(xiàn)精確的對接.冠帶層供料裝置包括:①導開,適合操作靈活寬度的冠帶層;②環(huán)路控制;③具有前端導向的貼合裝置;④冠帶層切刀;⑤布卷卷軸.胎面供料裝置配置在帶束胎面貼合鼓的前面,容易放置胎面膠,包括帶有滾道和導向裝置的主架,可以借助于中心的溝槽或者胎面膠的邊沿來導向.胎面供料裝置適用寬度可調的胎面膠,胎面導向裝置高度可調.控制單元可用工業(yè)上的可編程序邏輯控制器,采用伺服傳動實現(xiàn)精確的同步,可以把故障診斷、輪胎規(guī)范和維護指南存儲在上位機中.

2移動成型鼓單元的協(xié)議統(tǒng)一無線通信

針對組合成型生產(chǎn)線中移動鼓單元的運動特性,將傳感器技術與無線通信技術相結合,研制適用于各類傳感器的無線數(shù)傳模塊以實現(xiàn)對被監(jiān)測點的無線測量.采用RS-485總線作為數(shù)據(jù)傳輸鏈路,把無線終端設備和其它終端設備通過統(tǒng)一協(xié)議掛接到總線上[5].先將移動鼓PLC的RS485通信接口與無線發(fā)射裝置進行有效電氣對接,然后將無線接收裝置安裝在現(xiàn)場監(jiān)控分站固定部分,從而使移動鼓的數(shù)據(jù)采集與控制實現(xiàn)無線傳輸模式,最后經(jīng)RS485通信接口與成型系統(tǒng)通信主站聯(lián)網(wǎng).

2.1移動成型鼓的移動載體控制方案設計

移動成型鼓的運動載體是一個半自主移動四輪小車,小車的整個控制系統(tǒng)在結構上是分布式的,由上位機和下位機兩部分構成.上位機是一臺PC,作為監(jiān)控中心,其作用是實現(xiàn)控制策略,進行路徑跟蹤以及路徑規(guī)劃,發(fā)出控制指令進行遠程監(jiān)控.下位機采用可編程控制器,固定在小車移動車體上,負責接收主控計算機指令并分配給各個子系統(tǒng),同時把各個子系統(tǒng)的傳感信息發(fā)送到計算機,兩者通過無線模塊進行通信[6].小車底層控制系統(tǒng)根據(jù)接收到的來自監(jiān)控中心的指令以及傳感器信息控制小車的運動,完成小車前進、后退、轉彎、停止等動作.為了滿足在復雜環(huán)境下對小車的有效控制,控制系統(tǒng)必須具有良好的機動性和靈活性,使小車具有向各個方向行駛的能力和可控能力,最終實現(xiàn)小車的平穩(wěn)運動.采用無線通信方式從上位機監(jiān)控中心接收指令信息,根據(jù)指令信息實現(xiàn)小車的運動控制.在這個過程中需要對通過無線通訊接收到的指令信息進行通信協(xié)議解算,得到小車下一步的位置信息和速度信息,并且需要把小車當前位置信息與下一步的位置信息進行比較得到小車下一步的運動方向,最后根據(jù)解算信息進行運動判斷,完成閉環(huán)運動控制,返回后繼續(xù)接收下一步的指令信息.將解算信息中的速度信息和位置信息作為給定輸入進行閉環(huán)運動控制,主要完成對驅動小車的直流電機進行運動控制,使小車能夠平穩(wěn)運行.對驅動小車的直流電機采用電流環(huán)和位置環(huán)構成的全數(shù)字雙閉環(huán)PID控制策略,如圖4所示.小車啟動、停轉或者大幅度增減設定值的時候,短時間系統(tǒng)會出現(xiàn)較大的偏差,引起積分飽和效應,造成系統(tǒng)震蕩.為消除積分飽和,在控制系統(tǒng)中可采用抗積分飽和控制策略.工作時時監(jiān)控中心將移動小車的運行路線通過無線通訊以指令的形式傳給小車,小車解算指令后響應指令做出相應的動作.

2.2通信協(xié)議選擇

輪胎行業(yè)的工業(yè)控制模式已從單機走向集中監(jiān)控.工業(yè)控制器聯(lián)網(wǎng)也為網(wǎng)絡管理提供了方便.Mod-Bus協(xié)議就是工業(yè)控制器網(wǎng)絡協(xié)議中的一種,通過此協(xié)議,控制器相互之間、控制器經(jīng)由網(wǎng)絡(例如以太網(wǎng))和其它設備之間可以進行通信.它的開放性、可擴充性和標準化使它成為一個通用工業(yè)標準.ModBus可以應用在支持ModBus協(xié)議的PLC和PLC之間、PLC和個人計算機之間、計算機和計算機之間、遠程PLC和計算機之間以及遠程計算機之間(通過Modem連接).由于ModBus是一個事實上的工業(yè)標準,許多廠家的PLC和HMI、組態(tài)軟件都支持ModBus,因此,ModBus有著廣泛的應用基礎.在實際應用中,可以使用RS232、RS485/422、Modem加電話線、甚至TCP/IP來聯(lián)網(wǎng).本文聯(lián)網(wǎng)通信總線采用RS485傳輸,通信協(xié)議采用ModBus標準通信協(xié)議.

組合式成型生產(chǎn)線監(jiān)控系統(tǒng)的終端設備可以分別選用三菱公司的F2NX系列PLC、西門子公司的S7200系列PLC以及LG公司的K120系列PLC,這幾種終端設備在移動鼓上應用具有較高的性價比.可以采用LG公司PLC提供的RS485通訊接口,激活其通訊模式,因LG本身支持ModBus標準通信協(xié)議,所以可突破LG聯(lián)網(wǎng)瓶頸.西門子S7-200PLC支持ModBus標準通信協(xié)議,但需要進行軟件設置,通過軟設置可實現(xiàn)其聯(lián)網(wǎng)功能.三菱FX2N系列PLC本身不支持ModBus標準通信協(xié)議,可通過擴展通訊模塊以硬設置的方式完成其聯(lián)網(wǎng)功能.

2.3移動鼓無線通信技術設計方案及實現(xiàn)

確立通信協(xié)議后就可以設計無線通信聯(lián)網(wǎng)方案.組合成型生產(chǎn)線移動鼓選用三菱FX2N-64MR型PLC可編程控制器進行各種動作控制.移動鼓運行狀態(tài)數(shù)據(jù)包括運行速度、定位角度、牽引電流、液壓系統(tǒng)壓力、故障狀態(tài)等,可通過RS485通訊接口實時向外傳輸.基于移動成型鼓PLC控制器裝載在移動部位,難以通過通信電纜介質與成型機系統(tǒng)現(xiàn)場總線網(wǎng)絡聯(lián)接,方案采用無線通信網(wǎng)絡方式,通過無線收發(fā)裝置收發(fā)狀態(tài)數(shù)據(jù),依據(jù)所選擇的協(xié)議模型設定通訊協(xié)議,實現(xiàn)與其它終端設備聯(lián)網(wǎng)[7].

1)移動成型鼓無線通信技術方案設計首先將移動鼓PLC的RS485通信接口與無線發(fā)射裝置設置在移動設備上,如圖5所示.然后再將無線接收裝置設置在現(xiàn)場監(jiān)控分站固定位置,如圖6所示.通過此種通信方式使移動成型鼓的狀態(tài)信息上傳下達.無線數(shù)傳模塊通信收發(fā)功率為1W,開闊地域發(fā)收距離為4km,具有抗強干擾的有效距離也可以達到300m,成型生產(chǎn)線現(xiàn)場使用無線方式通信足以滿足要求.無線數(shù)據(jù)傳輸模塊通過RS-485總線獲取現(xiàn)場終端設備的參數(shù),并依無線方式發(fā)送出去,現(xiàn)場監(jiān)控分站的無線數(shù)據(jù)接收模塊接收數(shù)據(jù),并經(jīng)RS-232總線發(fā)送到中心數(shù)據(jù)服務器,服務器記錄、存儲采集的參數(shù)形成報表.

2)移動成型鼓無線通信技術方案實現(xiàn)正常數(shù)據(jù)采集通信時序為:發(fā)射端的無線數(shù)據(jù)傳輸模塊通過RS-485總線間隔lS循環(huán)發(fā)送數(shù)據(jù)采集命令(命令字符串中包含數(shù)據(jù)采集模塊的地址),相應地址的數(shù)據(jù)采集模塊接收命令后將采集到的參數(shù)回送至無線數(shù)據(jù)傳輸模塊,無線數(shù)據(jù)傳輸模塊立即將接收到的數(shù)據(jù)發(fā)出,接收端的無線數(shù)據(jù)傳輸模塊接收這些數(shù)據(jù)并轉送到中心數(shù)據(jù)服務器.無線通訊系統(tǒng)起著核心作用的部分選用上海某公司的某型號無線數(shù)傳開發(fā)模塊,對其進行二次開發(fā),其提供標準RS-232,RS-485和UART(TTL電平)3種接口方式,可與計算機、用戶的RS-485設備、單片機或其它UART器件直接連接使用,該型號無線數(shù)傳模塊應用原理如圖7所示.無線數(shù)傳模塊使用直流電源,電壓為+9.0V±0.5V,根據(jù)用戶的需要可以與其它設備共用電源,模塊提供1個9針的連接器(JP1),一個天線接口(ANT),一組調線短路器(JP2),可以根據(jù)終端設備的設定進行連接和跳線調整.無線模塊端口的定義及配置方法,如圖8所示:圖8無線數(shù)傳模塊端口定義Fig.8Portdefinitionofwirelesscommunicationmodule①GND電源地;②VCC電源DC9V;③RXD/TTL串行數(shù)據(jù)接收端;④TXD/TTL串行數(shù)據(jù)發(fā)射端;⑤SGND信號地;⑥A(TX)RS-485的A,RS-232的TX;⑦B(RX)RS-485的B,RS-232的RX;⑧SLEEP休眠控制(輸入);⑨RESET復位控制(輸入).系統(tǒng)采用KDW-0.6/12型隔爆兼本安直流穩(wěn)壓電源,采用精密鑄造,鑄鋼外殼,箱蓋設有電源指示燈,機芯與電源變壓器為一整體,采用雙重過流、過壓保護,輸出DC10-DC12V,額定電流700mA.為完成供電電源與無線模塊的電壓匹配,選用廣州普田電子有限公司的DC/DC電源模塊.該模塊性能穩(wěn)定,工作壽命長,采用SIP封裝,體積小,溫度特性好,可直接焊在PCB上.

3)移動成型鼓無線通信工作模式設定考慮到無線數(shù)傳模塊的電源電壓為9V,為簡化設計,使接口電平兼容、統(tǒng)一,無線數(shù)據(jù)傳輸模塊的所有芯片采用9V供電.RS-485電平轉換芯片采用低功耗半雙工收發(fā)器,RS-485網(wǎng)絡為“單主/多從”通信方式,任一時刻只能有一個RS-485發(fā)送器工作在“發(fā)送”狀態(tài),其余節(jié)點必須工作在“接收”狀態(tài),如果同時有2個或以上RS-485收發(fā)器工作在“發(fā)送”狀態(tài)將會導致通信數(shù)據(jù)紊亂,甚至損壞RS-485收發(fā)器[7].采用高效前向糾錯信道編碼技術,提高了數(shù)據(jù)抗突發(fā)干擾和隨機干擾的能力,數(shù)據(jù)傳輸采用實時同步,32B的同步結構和完善的通訊協(xié)議使該產(chǎn)品更加穩(wěn)定可靠.在視距情況下,采用吸盤天線,在天線擺放合理的條件下,通信距離可以達到2km以上.設計透明的數(shù)據(jù)接口,適應任何標準或非標準的用戶協(xié)議,自動過濾掉空中產(chǎn)生的噪音信號及假數(shù)據(jù),所發(fā)即所收.配置8個信道滿足用戶多種通信組合方式的需求.通過短路器設定接口方式為單一協(xié)議的RS-485接口.傳輸速率設定為9600bit/s,數(shù)據(jù)位設為8b,結束位設為1b,采用偶校驗.

3基于無線通信的移動成型鼓數(shù)據(jù)采集與控制

建立起移動成型鼓無線通信模式后,組合成型生產(chǎn)線就可以通過綜合數(shù)據(jù)采集與控制系統(tǒng)把移動成型鼓的運行速度、定位信息、牽引電流、液壓系統(tǒng)壓力、故障狀態(tài)等信息在現(xiàn)場監(jiān)控分站進行顯示與控制.借助于無線通信方式,監(jiān)控系統(tǒng)可顯示移動成型鼓的總體運行狀況,包含歷史曲線、報警記錄、參數(shù)設置、狀態(tài)查看、操作幫助信息、設備運行統(tǒng)計等.帶束層供料裝置、冠帶層供料裝置、供胎面裝置、胎體供料裝置、壓合裝置等設備的電氣參數(shù)采用有線組網(wǎng)的方式與現(xiàn)場監(jiān)控分站聯(lián)網(wǎng),利用自主開發(fā)的通訊程序,通過現(xiàn)場總線的方式與主站通訊.上位監(jiān)控畫面以及實時數(shù)據(jù)顯示畫面如圖9所示.數(shù)據(jù)顯示區(qū)實時顯示現(xiàn)場采集的數(shù)據(jù),監(jiān)控畫面設備以動畫形式與現(xiàn)場設備同步,用鼠標點擊任一個設備框圖均會顯示該設備的工作狀態(tài),顯示實時數(shù)據(jù)、歷史曲線以及報警信息.

篇9

【關鍵詞】告警直傳；遠程瀏覽；源端維護

0 引言

電網(wǎng)的告警信息處理是調度監(jiān)控的日常重要工作之一，告警信息的智能化水平對于提升調度全面感知電網(wǎng)運行狀態(tài)、快速應對電網(wǎng)異常告警具有重要意義。隨著經(jīng)濟不斷發(fā)展和電網(wǎng)規(guī)模的擴大，傳統(tǒng)的廠站端與調度主站的遠動數(shù)據(jù)傳輸已不能滿足調度監(jiān)控集約化發(fā)展的需求。本文主要介紹在地區(qū)電網(wǎng)調度中采用告警直傳和遠程瀏覽技術，以滿足電網(wǎng)調度、集中監(jiān)控的需求。

1 地區(qū)電網(wǎng)調度系統(tǒng)的運行現(xiàn)狀及存在問題

1.1 地區(qū)電網(wǎng)調度系統(tǒng)的運行現(xiàn)狀

目前，地區(qū)電網(wǎng)調度中心值班人員監(jiān)控到的信息是由變電站的遠動裝置將采集到的設備信息通過報文規(guī)約傳輸?shù)秸{度主站系統(tǒng)，主站維護人員負責在系統(tǒng)中繪制變電站一次接線圖，修改遙信、遙測、遙控表等方式，經(jīng)過主站服務器處理后，將這些信息直觀地反映給監(jiān)控值班人員，以實現(xiàn)對電網(wǎng)的監(jiān)視和控制。

隨著電網(wǎng)運行規(guī)模的擴大、電網(wǎng)的運行和控制特性日趨復雜，對調控中心信息判斷和事故處理能力的及時性和準確性提出了更高的要求。為此，當事故發(fā)生時，調度監(jiān)控人員不能再花費時間從大量告警信息中尋找告警源，而是直接獲得告警信息，縮短事故處理時間；處理分析復雜問題時，往往還需要瀏覽變電站內更詳細的情況，因此站端應提供更多有效手段給調度監(jiān)控人員遠程調閱變電站的全景信息。

1.2 目前的運行模式中存在的問題

調度自動化系統(tǒng)在告警處理方面存在展示手段單一、信息繁雜等問題，調控中心對電網(wǎng)整體運行狀態(tài)的掌握能力略顯不足；尤其是在惡劣天氣、自然災害、電網(wǎng)出現(xiàn)故障的情況下，調控中心短時間內涌入大量信息，調度監(jiān)控人員需要從上百條的告警中分析得出問題的根源和關鍵信息，無形中增加了故障處理的壓力。

目前調度主站和變電站間實時數(shù)據(jù)業(yè)務基本上是采用IEC101和IEC104兩種傳輸規(guī)約，這兩種傳輸規(guī)約安全可靠，因此得到了廣泛應用。但是上述兩種規(guī)約是按照點號來匹配主、子站間的信息，因此若要接收變電站側的相關數(shù)據(jù)，必須在站端和主站分別維護各自數(shù)據(jù)的點號，并嚴格核對以保證主、子站的統(tǒng)一。一般情況下單個500kV變電站的遙信量在5000個左右，甚至更多，對處理全區(qū)所有變電站信息的主站服務器來說負荷巨大；主站界面的電網(wǎng)一次設備圖是由主站維護人員負責繪制，每次運行方式變更以及遙信、遙測點表調整，都要在調度員界面修改圖形和關聯(lián)量測。對于自動化系統(tǒng)維護人員來說，這些重復的維護操作占據(jù)了大部分的日常工作量。

基于以上分析，為了減少調度自動化主站系統(tǒng)的日常維護工作量，降低主站服務器的負荷，提高調度監(jiān)控人員的工作效率，全面、及時地對站端情況進行監(jiān)控，在電網(wǎng)調度中采取告警直傳、遠程瀏覽技術來滿足目前“大集中、大運行”的需求。

2 告警直傳和遠程瀏覽技術簡介

2.1 告警直傳簡介

告警直傳是將變電站監(jiān)控系統(tǒng)收到的告警信息以文本形式，采用標準化、規(guī)范化的告警描述語言格式形成直傳信息，經(jīng)變電站圖形網(wǎng)關機通過DL476規(guī)約、調度數(shù)據(jù)網(wǎng)直接上送到調度主站，從而實現(xiàn)告警信息的源端維護、自動解析的技術。主站收到的告警直傳信息是變電站處理過的格式，不需要再使用傳統(tǒng)的按照點號進行信息匹配的傳輸模式；通過對變電站告警直傳信息的整合，調度監(jiān)控員可以全面掌握變電站的詳細保護動作情況，為調度事故處理提供了重要的信息支撐，提高了主站側在線故障診斷功能的實用性。

2.2 遠程瀏覽簡介

遠程瀏覽是將變電站監(jiān)控系統(tǒng)的畫面（包括一次接線圖、間隔圖、光字牌、曲線等）轉為標準G文件格式，經(jīng)圖形網(wǎng)關機上傳到主站，主站系統(tǒng)提供遠程瀏覽客戶端，來監(jiān)視變電站全景信息的技術。調度監(jiān)控人員需要查看變電站的詳細信息時，可以使用遠程瀏覽界面調閱相應的實時畫面和數(shù)據(jù)，這樣一來主站維護人員就不用再重復地繪制，便能瀏覽到變電站的完整信息。

3 告警直傳、遠程瀏覽功能建設

3.1 總體架構

如圖1所示，以江門地調EMS為例，我們在調度自動化主站E8000系統(tǒng)中增加功能擴展，在變電站增加一臺圖形網(wǎng)關機，作為告警直傳、遠程瀏覽模塊的部署設備，且獨立于變電站遠動裝置、監(jiān)控后臺運行。

3.2 告警直傳功能實施

在調度主站端瀏覽變電站告警信息，需要在主站增加告警采集模塊、告警處理模塊，作為TCP連接的客戶端；站端圖形網(wǎng)關機增加告警信息轉發(fā)模塊，通過DL476/IEC104協(xié)議直接傳輸告警信息，作為TCP連接的服務器端。

3.2.1 告警直傳數(shù)據(jù)流程

一般來說，告警直傳的工作流程如下：有告警信息產(chǎn)生時，變電站監(jiān)控系統(tǒng)先將本地后臺的告警信息轉換為標準格式的告警信息，再傳輸給主站；主站告警采集模塊對接收到的報文進行解析，并發(fā)送消息給告警處理模塊；主站告警處理模塊對收到的站端信息進行處理、顯示、存盤，及歷史查詢。如圖2所示。

3.2.2 告警直傳格式

為減輕傳輸數(shù)據(jù)量，傳送的字符串里變電站名電壓等級設備等不直接傳輸，采用編碼上傳； 在E8000系統(tǒng)設計告警直傳時，采用八段式上傳：“事項編號告警時間設備名稱告警內容告警級別責任區(qū)量測類型告警代碼”。

如：577 2014-11-06 10：25：56.031 鶴山上南變/110kV鶴上線1616開關 正常變位（人工置數(shù)）：合 3 3 701 B146.110kV.1616.B146161Cb。表示鶴山上南變的110kV鶴上線1616開關于2014-11-06 10：25：56.031合上，原因為人工置數(shù)。

3.3 遠程瀏覽功能實施

遠程瀏覽的關鍵技術是“G語言”，即電力系統(tǒng)圖形描述規(guī)范。站端監(jiān)控系統(tǒng)的圖形由程序轉換生成G格式文件，保存在圖形網(wǎng)關機上；調度主站瀏覽變電站數(shù)據(jù)時，通過DL476/IEC104協(xié)議向站端發(fā)送獲取相應G文件的請求；圖形網(wǎng)關機收到主站的請求后，按通信格式要求將請求的文件分多幀發(fā)送，上送完成后，按G文件中關聯(lián)的元件ID號取出對應的變化數(shù)據(jù)，發(fā)送給主站，并等待下一個請求。

我們在沿用國家電網(wǎng)模式的前提下，還對遠程瀏覽的傳輸機制進行了擴展：改進通信協(xié)議，在主站服務器增加G文件緩存，開發(fā)對比程序、斷點續(xù)傳技術，提高了圖形召喚的效率；采用版本控制的機制，保證了遠程瀏覽結果的實時性和一致性。

4 告警直傳、遠程瀏覽的實用效果

目前，基于E8000平臺的告警直傳和遠程瀏覽技術自開展研究以來，經(jīng)過不斷磨合和優(yōu)化完善，如今已經(jīng)在江門電網(wǎng)中實現(xiàn)，并在調度主站以及變電站系統(tǒng)中得到應用，運行效果顯示具備良好的實用性，為無人值班變電站提供了重要保障。

通過告警直傳，有效解決了在當前集約化大背景下重要信號容易被大量信號淹沒的問題，一個500kV變電站遙測、遙信信息大幅減少，從近5000個點縮減到不到1000點，主站系統(tǒng)可以利用告警直傳的全面性，對從其他渠道獲得的告警信息加以輔助，幫助調度監(jiān)控人員了解故障原因，做出合理判斷。

通過遠程瀏覽，調度自動化系統(tǒng)從傳統(tǒng)意義上的單一主站擴展到納入所有調控變電站的監(jiān)控系統(tǒng)，是調度自動化的一次飛躍。主站系統(tǒng)無需人為維護，信息表編制、數(shù)據(jù)庫制作、畫面繪制等工作實現(xiàn)源端維護，極大減輕了主站維護人員的工作量。

篇10

古柏先生曾談到：“學校教育的大班上課，小學、中學、包括大學本科，教授的都是基本知識，是普及教育，而真正的研究式的學習階段是在研究生以后。教育發(fā)達國家的教授，通常帶的研究生就幾個，并且往往并不由我們書面考試的方法錄取，而是采取推薦自薦、觀察考察的方法揀拔。這和中國藝術文化、武術文化傳承的師傅選擇徒弟的方法，師傅對徒弟選擇的重視天賦、品行，師傅注重對徒弟的言傳身教，有著某種程度上的相似”。古柏先生還談到：“科學研究出成就的，有可能是年輕人；但文化事業(yè)上出成就的，則往往多為高齡者。沒有漫長時間的‘悟道’，沒有老師長期的和手把手的教授，后進何以成為大師。學者、作家、藝術家、武術家，莫不如此。掌握精品文化或上位文化的，就是這些大師們”。古柏先生的意見應說頗有見地。在我們沒有找到更好的方式之前，原有的方式應該鼓勵，保障、保證它的存在。原有的師徒承傳方式得到了保存，那么原有的理論體系、技術體系、選材方式、訓練方法、禮書儀式、組織形式等，無疑也都將得到保存。

儒學理論的核心，一個是“仁”，一個是“禮”，仁是內容，禮是形式。我們現(xiàn)在常說的是：內容最重要，形式則不那么重要，可以靈活變通因時而異。但孔子不這么認為，他認為仁是原則，禮也是原則，禮如果不存在，仁也就不存在了。所以他的弟子避免浪費要減少祭祀用的羊的數(shù)目，孔子堅決反對，于是說了那句有名的話：“爾愛其羊，我愛其禮”。孔子把禮上升到原則的高度來堅持，有著深刻的道理。這尤其值得今天的我們深思。

諸如拜師儀式正式拜師遞大紅帖子，行跪拜口口頭大禮；諸如清明節(jié)在師祖墳前，燒香磕頭，頂禮膜拜，長跪不起等等。對一個信仰無神論的人，對一個受過現(xiàn)代教育的人，說實話，第一次，從面子到心中，我們恐怕都難以適應，會極為難堪，坦率說甚至有點荒唐感。但如果逐漸地深入其中，我們就不難感覺和領悟到它的道理。它對于建立中國武術武學傳統(tǒng)的神圣的感情，維護傳統(tǒng)武術宗師老師的德望不口威信，維護本門派武功的威嚴尊嚴和對它的力量的信心，密切師徒間徒弟間的關系，強調徒弟遵從傳統(tǒng)的門規(guī)和道德，增強該團體的向心力凝聚力，其實有著深刻和極大的影響力。但是，若非置身其中身I臨其境，你很難明白它的本意與要旨。有同樣感覺的有李拜天先生，他在太原長大，在北京上了大學，從此在北京工作，但2002年他回山西平遙農(nóng)村參力口了他爺爺?shù)膫鹘y(tǒng)的隆重而繁復的葬禮，他的看法改變了。他說：“這一天，我不知道自己磕了幾千個頭”；“原來儀式上每一個瑣碎的環(huán)節(jié)都有它特定的意義在里面，沒有一樣是純粹的花樣子”；“我第一次用心感覺著腦9下的這片黃土地，第一次發(fā)覺它是如此堅韌和沉重。我們都從這片土地上走出來，被這方水土養(yǎng)育了數(shù)年之后，最終將自己的一切又原原本本地又還給了它。從我出生的那天起，就注定了我無論走多遠，這塊土地都會象磁石一樣緊緊吸附著我的靈魂”。

從這個意義講，唐豪考證少林附會達摩沒錯，那是歷史學的考證；考證是科學；但少林派供奉達摩也沒錯，供奉達摩是尊祖，尊祖是一種信仰，信仰不是科學，信仰自有它深刻的道理。都說我們中國是“禮儀之邦”，但打倒孔家店快百年了，那些或許是繁文縟節(jié)的禮節(jié)我們早就拋到了九霄云外，于是我們往往起碼的禮貌都缺乏，哪里還能尋到我們是“禮儀之邦”的多少影子；都說我們是“文明古國”自古重教育，但“天地君親師”的牌位早砸了，學生有多少明白原來意義上的“師”，老師有多少明白原來意義上的“道”，于是我們哪里還能尋到我們的“師道尊嚴”的多少影子。