郭 華，吳澗彤，王俊偉

（總裝備部工程設計研究總院，北京 100028）

海量數(shù)據(jù)的實時通訊

郭 華，吳澗彤，王俊偉

（總裝備部工程設計研究總院，北京 100028）

介紹基于多通道的并發(fā)傳輸技術，該技術使通訊帶寬由100 K提高到1 M，突破了工業(yè)以太網(wǎng)通訊的瓶頸，實現(xiàn)了上位機與PLC之間海量數(shù)據(jù)的實時通訊。

海量數(shù)據(jù)；實時通訊；多通道；并發(fā)傳輸

在舉世矚目的北京奧運工程中，在國家體育場“鳥巢”上空的吊掛控制系統(tǒng)、跳躍控制系統(tǒng)、“碗邊”小車控制系統(tǒng)及地面設備控制系統(tǒng)中，上位機和PLC（Programmable Logic Controller，可編程邏輯控制器）之間通過工業(yè)以太網(wǎng)連接進行數(shù)據(jù)交換。有多種方法實現(xiàn)工業(yè)以太網(wǎng)通訊，以往采用的是西門子的Softnet通過OPC（OLE for Process Control，用于過程控制的OLE）規(guī)范實現(xiàn)上位機和PLC之間的數(shù)據(jù)交換。

OPC技術在硬件供應商和軟件開發(fā)者之間搭上了一座橋梁，它提供一種機制從數(shù)據(jù)源并且以一個標準的方式將這些數(shù)據(jù)傳送到任意客戶端應用程序。一個設備供應商現(xiàn)在可以開發(fā)一個可重用、高度優(yōu)化的服務器與數(shù)據(jù)源通信，并且高效地從數(shù)據(jù)源或者智能設備存取數(shù)據(jù)。OPC規(guī)范了接口函數(shù)，不管現(xiàn)場設備以何種形式存在，客戶都以統(tǒng)一的方式去訪問，從而實現(xiàn)系統(tǒng)的開放性，易于實現(xiàn)與其他系統(tǒng)的接口。這是因為OPC按照面向對象的原則，將一個OPC服務器作為一個對象封裝起來，只將接口方法暴露在外面，客戶以統(tǒng)一的方式去調用這個方法。也就是說，客戶程序設計者可以使用相同的OPC客戶端程序代碼，操作不同的硬件裝置，實現(xiàn)軟件重用和軟件的即插即用。

1 問題的產(chǎn)生

在劇院的舞臺機械中，一次同時動作的設備一般不超過30個。同時，設備只有單段運行一種運行模式，也就是只有一組設定數(shù)據(jù)，在程控啟動以前就已經(jīng)將數(shù)據(jù)全部傳送到PLC中去，在程控運行過程中上位機軟件只負責顯示設備的位置、速度、電流、狀態(tài)和故障等信息，而不參與實時控制。

在國家體育場中，一套系統(tǒng)（如跳躍系統(tǒng)）同時動作的設備有近百個。同時，設備除了單段運行模式外，又增加了曲線運行模式，如圖1所示，也就是有多組設定數(shù)據(jù)（最多20組），在程控運行過程中上位機需要實時與PLC通訊，根據(jù)當前位置、狀態(tài)等信息決定下一步應向PLC發(fā)送哪一組設定數(shù)據(jù)。這就使得上位機和PLC之間交換的數(shù)據(jù)量成倍增加，上位機必須參與實時控制。

在調試過程中發(fā)現(xiàn)：當上位機和PLC之間交換的數(shù)據(jù)量達到3 000字節(jié)時，通訊就會有明顯的延遲。此時，如果延長上位機和PLC之間的數(shù)據(jù)交換周期，通訊延遲現(xiàn)象會有改善。也就是說，通訊延遲與數(shù)據(jù)量成正比，與數(shù)據(jù)交換周期成反比，公式如下：

其中，D：完成指定長度的數(shù)據(jù)通訊實際需要的時間，單位為s；

M：一個周期需要通訊的全部數(shù)據(jù)量，單位為字節(jié)；

T：設定的數(shù)據(jù)交換周期，單位為s。

A股下跌主要原因，一方面是受中美貿易摩擦的擾動，另一方面自身內部問題也比較突出。首先，2017年開始整個金融大環(huán)境就是防風險去杠桿。防風險的重要工作是整治金融亂象，2017年以來，先后限制銀行理財、規(guī)范保險資金以及券商資管入市，打壓游資炒作，這些都是政治金融亂象的措施。進入2018年在防風險的基礎上，去杠桿成為首要任務，去杠桿會導致流動性緊縮，進而影響增量資金入市，很明顯觀察到，今年兩市日均成交額基本維持在3000-5000億的地量水平。

上位機和PLC之間的數(shù)據(jù)交換周期不應小于250 ms，否則，會使數(shù)據(jù)刷新滯后，明顯地感覺到數(shù)據(jù)是一個一個地蹦出來的。這里將上位機和PLC之間的海量數(shù)據(jù)定義為：3 000字節(jié)以250 ms的數(shù)據(jù)交換周期盡量進行通訊，換算成通訊帶寬為100 K。

其中，M：一個通道的限定字節(jié)數(shù)，此處為3 000；

11：一個字節(jié)的位數(shù)，8個數(shù)據(jù)網(wǎng)，1個起始位，1個停止位，1個效驗位；

4：通訊頻率，數(shù)據(jù)交換周期的倒數(shù)，1 000 ms / 250 ms= 4；

海量數(shù)據(jù)通過OPC進行通訊會產(chǎn)生嚴重的通訊延遲現(xiàn)象，為了解決這個問題，我們做了大量的實驗：

首先想到的是：會不會是OPC造成的瓶頸？于是做了第一個實驗，采用PRODAVE繞過OPC進行直接通訊。PRODAVE是西門子的C語言編程接口，可以實現(xiàn)上位機和PLC之間的直接通訊，由于OPC規(guī)范要考慮各種硬件、軟件之間的兼容性，因此，從速度和效率上來說，理論上PRODAVE要比OPC快，實驗的結果是：在數(shù)據(jù)交換周期為250 ms的情況下，3 000字節(jié)的通訊實際需要380 ms的時間，可見，采用PRODAVE通訊速度并沒有明顯的改善。

第二個實驗，采用FETCH/WRITE（塊讀寫）協(xié)議進行通訊。FETCH/WRITE（塊讀寫）協(xié)議是PLC內部的一種通訊協(xié)議，顧名思義就是數(shù)據(jù)整塊地傳送，和字節(jié)傳送相比，速度能提高很多倍。實驗的結果如下：3 000字節(jié)的數(shù)據(jù)量，數(shù)據(jù)交換周期為250 ms，可以接收到400或者800個字節(jié)（FETCH/WRITE協(xié)議內部默認是以400為一塊），將數(shù)據(jù)交換周期改成350 ms，可以接收到2 400個字節(jié)或者2 800個字節(jié)，將數(shù)據(jù)交換周期改成500 ms，每次都可以接收3 000個字節(jié)。結論是FETCH/WRITE（塊讀寫）協(xié)議和PRODAVE的通訊速度差不多。

我們知道工業(yè)以太網(wǎng)的帶寬是100 M，為什么實際使用中只能達到100 K呢？于是做了第三個實驗，采用一臺計算機模擬PLC，運行第二個實驗中的服務器端程序，另一臺計算機運行第二個實驗中上位機端程序。結果發(fā)現(xiàn)：在數(shù)據(jù)交換周期為250 ms的情況，每次都可以接收3 000個字節(jié)。這個實驗證明：通訊的瓶頸不在以太網(wǎng)上，而在于PLC內部。

2 基于點的數(shù)據(jù)策劃方案

編寫上位機軟件主要有兩種方式：一種是選用組態(tài)軟件進行組態(tài)，另一種是使用各種編程語言（如Visual C++、Visual Basic）直接編寫。我們采用的是第二種方法，通過Visaul C++編程實現(xiàn)OPC驅動。如果采用第一種方法，即選用組態(tài)軟件進行組態(tài)，還會有通訊延遲的問題嗎？

目前市場上主流的組態(tài)軟件是這樣實現(xiàn)數(shù)據(jù)交換的：對數(shù)據(jù)進行策劃，按點來管理數(shù)據(jù)，根據(jù)每個點的實際要求來決定其通訊周期。也就是說每個點的通訊周期都不同，有的點可以僅在每次程序進入時讀入一次即可，還有的點幾分鐘讀一次也能滿足要求，只有個別需要實時刷新的數(shù)據(jù)才每個周期都進行通訊。這樣，上位機和PLC之間每個周期進行交換的數(shù)據(jù)就大大減少。比如當前位置（一個長整數(shù)），如果按字節(jié)傳送，就是8個數(shù)據(jù)項，如果改成按點傳送，就是一個數(shù)據(jù)項，這就減少了7/8的數(shù)據(jù)量。

如圖2所示：原來12個點（數(shù)據(jù)項）變成2個點（數(shù)據(jù)項），且每個點可以有自己獨立的數(shù)據(jù)交換周期。

像“組態(tài)王”這樣的組態(tài)軟件還采取了一些其他技巧來減少數(shù)據(jù)通訊量，比如：只刷新當前屏幕上顯示的點。這樣，每個周期必須讀取的點的數(shù)量就顯著減少，通訊速度就能明顯提高。

一般的控制系統(tǒng)中采用這種方案完全可以滿足要求，不會出現(xiàn)通訊延遲的現(xiàn)象。因為通常上位機只完成參數(shù)設定、數(shù)據(jù)及圖形顯示等功能，不直接參與實時控制。在一些大型化工項目中，即使數(shù)據(jù)量很大，能多到幾萬個點，但對其中很多實時性要求不高的點，比如溫度、液位等數(shù)據(jù)，完全可以若干個周期讀取一次。而在國家體育場中，數(shù)據(jù)量大，數(shù)據(jù)交換周期要求高，完全采用上述方案無法徹底解決通訊瓶頸問題。

3 基于多通道的并發(fā)傳輸技術

目前我們遇到的問題，打個比方來說，上位機和PLC之間的通訊就像馬路上的交通流量。到此為止一直在一條路上“跑”，如果這條路太堵了，能否多修幾條路？于是自然而然地想到了多線程技術。

線程都是操作系統(tǒng)的概念。進程是應用程序的執(zhí)行實例，每個進程是由私有的虛擬地址空間、代碼、數(shù)據(jù)和其它各種系統(tǒng)資源組成，進程在運行過程中創(chuàng)建的資源隨著進程的終止而被銷毀，所使用的系統(tǒng)資源在進程終止時被釋放或關閉。線程是進程內部的一個執(zhí)行單元。系統(tǒng)創(chuàng)建好進程后，實際上就啟動執(zhí)行了該進程的主執(zhí)行線程，主執(zhí)行線程以函數(shù)地址形式，比如說main或WinMain函數(shù)，將程序的啟動點提供給Windows系統(tǒng)。主執(zhí)行線程終止了，進程也就隨之終止。

每一個進程至少有一個主執(zhí)行線程，它無需由用戶去主動創(chuàng)建，是由系統(tǒng)自動創(chuàng)建的。用戶根據(jù)需要在應用程序中創(chuàng)建其他線程，多個線程并發(fā)地運行于同一個進程中。一個進程中的所有線程都在該進程的虛擬地址空間中，共同使用這些虛擬地址空間、全局變量和系統(tǒng)資源，所以，線程間的通訊非常方便，多線程技術的應用也較為廣泛。

多線程可以實現(xiàn)并行處理，避免了某項任務長時間占用CPU時間，大大地提高CPU的工作效率。

在典型的單處理器主機上，任務實際上并不是同時執(zhí)行的。內核中稱為調度程序的部分將工作換進換出，從而讓所有工作都獲得一輪執(zhí)行。在同一個時間間隔內，并發(fā)模型常常基于事件的編程實現(xiàn)。

通常情況下，線程數(shù)量取決于應用程序的特定需要，理想情況下線程數(shù)量與處理器數(shù)量相當為好，雖然線程數(shù)量無法保證傳輸質量，但線程太少又會造成傳輸效率低，特別是用戶數(shù)量較多的情況下更為明顯。

基于多通道的并發(fā)傳輸技術的原理是這樣的：將上位機和PLC之間通訊的數(shù)據(jù)等分成N塊，上位機軟件生成N個線程，每個線程建立一個通訊通道，一個通道只傳輸N分之一的全部數(shù)據(jù)量。如圖3所示。

上位機作為客戶機，PLC作為服務器，在客戶機/服務器傳輸方式中，服務器需要打開監(jiān)聽端口，監(jiān)聽網(wǎng)絡上其它客戶機向該服務器發(fā)出的連接請求，當收到一個請求信號時與該客戶機建立一個連接通道，一個通道其實就是一個獨立的線程，每個通道傳輸?shù)臄?shù)據(jù)限定為900字節(jié)。

服務器提供的并發(fā)連接通道是有限定的。因為并發(fā)連接數(shù)量越多，所消耗的未分頁內存池也越多；等候處理的發(fā)送調用越多，被鎖定的內存頁面也越多，極易超過系統(tǒng)資源的極限。并發(fā)連接通道限定為30。

由此可以計算出基于多通道的并發(fā)傳輸技術的帶寬：

其中，M：一個通道的限定字節(jié)數(shù)，此處為900；

11：一個字節(jié)的位數(shù)8，個數(shù)據(jù)網(wǎng)，1個起始位，1個停止位，1個效驗位；

4：通訊頻率，數(shù)據(jù)交換周期的倒數(shù)，1 000 ms / 250 ms= 4;

N：通道數(shù)，此處為30。

4 結論

基于多通道的并發(fā)傳輸技術填補了國內主流組態(tài)軟件的空白，解決了海量數(shù)據(jù)的實時通訊問題，使上位機和PLC之間的實時控制成為可能，實現(xiàn)了威亞曲線運行模式，保證了奧運會、殘奧會開閉幕式四次演出中“星星五環(huán)”、“飛天仙女”、“藍天白云”、“碗邊郵遞員”等復雜節(jié)目的順利完成。該項技術可以廣泛地應用于各種海量數(shù)據(jù)的實時控制系統(tǒng)中。

（編輯 潘 浪）

1.胡道元.計算機網(wǎng)絡（高級）.北京：清華大學出版社，1999.8 （107）

2.張斌.高波.Linux網(wǎng)絡編程.北京：清華大學出版社，2000.1（2-8）

3.RFC 1889.RTP: A Transport Protocol for Real-Time Applications, 1996.1

4.Runtime: Synchronizing processes and threads http://www-900.ibm.com/developerWorks/cn/linux/sdk/rt/part5/index_eng.shtml

The Instant Communication for Mass Data

GUO Hua, WU Jian-tong, WANG Jun-wei
(Center for Engineering Design and Research under the General Equipment Department, Beijing 100028, China)

This paper presents a parallel transmission technology based on the multi-channel service, which improves the

bandwidth from 100K to lM so as to make a communication-breakthough of industrial Novell system and realize.The instant communication for mass data between position machine and PLC .

data, instant communication; multi-channel; parallel transmission technology