海量數據的實時通訊

郭 華，吳澗彤，王俊偉

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

海量數據的實時通訊

郭 華，吳澗彤，王俊偉

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

介紹基于多通道的并發傳輸技術，該技術使通訊帶寬由100 K提高到1 M，突破了工業以太網通訊的瓶頸，實現了上位機與PLC之間海量數據的實時通訊。

海量數據；實時通訊；多通道；并發傳輸

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

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

1 問題的產生

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

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

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

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

M：一個周期需要通訊的全部數據量，單位為字節；

T：設定的數據交換周期，單位為s。

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

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

其中，M：一個通道的限定字節數，此處為3 000；

11：一個字節的位數，8個數據網，1個起始位，1個停止位，1個效驗位；

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

海量數據通過OPC進行通訊會產生嚴重的通訊延遲現象，為了解決這個問題，我們做了大量的實驗：

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

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

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

2 基于點的數據策劃方案

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

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

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

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

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

3 基于多通道的并發傳輸技術

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

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

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

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

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

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

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

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

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

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

其中，M：一個通道的限定字節數，此處為900；

11：一個字節的位數8，個數據網，1個起始位，1個停止位，1個效驗位；

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

N：通道數，此處為30。

4 結論

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

（編輯 潘 浪）

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

2.張斌.高波.Linux網絡編程.北京：清華大學出版社，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