海量数据的实时通讯

郭 华，吴涧彤，王俊伟

（总装备部工程设计研究总院，北京 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