网络通信技术在燃气流超声速风洞测控系统中应用研究

(北京航天长征飞行器研究所 高超声速飞行器防隔热技术中心，北京 100076)

0 引言

燃气流试验是防热系统地面考核的关键环节，它具有能量密度高、总温高、热环境恶劣的特点，是防热材料及结构热考核不可替代的试验手段。而大尺寸的防热结构试件考核需要依托于燃气流超声速风洞进行。

燃气流超声速风洞涉及到燃气发生器、试验舱、扩压器、降温装置、抽真空设备等风洞主体设备，还包括配套的能源供应、冷却水供应等一系列附属设备[1-2]。风洞设备功能组成庞大、布局分散，传统的单机本地系统已无法满足要求，需要采用分布式的测控架构[3-6]。但是如何实现各分系统数据的可靠存储，同时又能保证与总控指挥调度系统、数据库系统的有效数据交互，实现数据的分布存储、集中显示和管理，成为该测控系统需要重点考虑的问题。

本文针对上述问题，通过网络流数据传输技术、网络共享变量技术、OPC技术、NTP网络授时技术等一系列网络通信技术的运用，实现了试验过程中大量数据的分布式实时存储、数据集中显示和试验后的数据集中管理。

1 系统结构及原理

本研究依托于某燃气流高温超声速风洞试验系统，该风洞利用氧气和煤油在加热器内混合燃烧，产生高温超声速燃气，利用抽真空设备在试验舱内形成低压试验环境，对模型进行热考核，考核后的燃气通过扩压器减速增压，并通过喷水降温和喷淋冷凝的联合作用后排入大气。

该风洞测控系统根据功能和布局划分为总控指挥调度系统和几个主要的测控分系统，结构如图1所示。网络拓扑采用星型结构，基于工业以太网为通信平台，并且将控制网络和数采网络分开布局，既保证了大量高速数据采集的高带宽传输，又保证了控制信号的可靠传递，提高了整个网络的可靠性和传输效率。

图1 风洞测控网络组成结构图

各系统均采用上下位机的控制结构，下位机系统主要由PLC可编程控制器、NI cRIO控制器和PXI控制器组成，遍布于风洞现场，用于风洞运行前期状态调节、启动时序控制、风洞状态监测、安全急停控制和试验数据采集等。上位机系统主要由工作站、服务器等设备组成，位于风洞控制中心，用于风洞状态监控、试验运行管理、试验命令下发、信号测量管理、数据处理与分析、试验数据显示等。

2 分布式运行控制

由于燃气流超声速风洞的运行涉及到诸多系统，设备布局分散，控制和测量节点众多，采用单机本地系统已远远无法满足对测控系统的要求，因此需要采用分布式的测控架构，考虑到控制的实时性和可靠性，每个分控系统均采用了上位机+控制器的控制结构。

为了保证控制动作的可靠实施，分控系统控制器基于西门子PLC300实现，采用Step7软件进行控制程序的开发。上位机程序则采用的LabVIEW软件进行开发，利用其强大的可视化功能模块和丰富的网络通信接口，可以很好地实现上位机操作所需的人家交互功能和与总控系统之间的数据和指令交互。但是LabVIEW软件并不能直接访问PLC工控设备，需要借助OPC服务程序[7-9]。

这里选择了KEPWARE公司的KEPServerEX OPC Server连接平台，相比于NI LabVIEW软件自带的NI OPC Server连接平台，OPC服务器通道配置和PLC设备配置过程基本一致，但是KEPServerEX软件支持程序动态创建OPC变量，这样就可以将OPC变量名称和PLC通信地址存储于配置文件中，通过软件自动读取配置文件并建立OPC变量，省去了在OPC连接平台逐个手动建立OPC变量的过程，之后软件程序维护只需维护对应的配置文件即可，这样可以大大提高软件的可维护性和移植性，特别适用于大型控制软件程序的编写。

LabVIEW软件中创建OPC变量和读写OPC变量的程序如图2所示。OPC Server通过标准OPC协议，访问对应PLC地址空间，并根据变量与PLC地址的映射关系，将访问结果存储于对应变量中，而基于LabVIEW开发的上位机程序则作为客户端直接读取对应变量，并在人机交互界面上进行显示和后台数据存储。同样地，写入PLC时则是由客户端修改对应变量数值，由OPC Server按照对应关系将数值写入PLC地址空间中。这里OPC Server的读写频率设置为每秒10次，足以满足常规人机交互程序的控制时效性要求。

图2 OPC变量创建和读写

这样借助OPC Server这个软件接口平台，即可以实现LabVIEW开发的客户端程序和PLC本地数据之间的双向数据传输。这种架构形式既利用了可编程逻辑控制器PLC的硬件稳定性，保证了下位机控制程序的可靠执行，同时也充分发挥了LabVIEW软件强大的图形界面开发优势。

3 分布式数据存储

鉴于现场采集点众多，且布局分散，本系统数据记录采用的是一种分布式的采集存储方式。并且采用NI PXI数据采集系统对传感器数据进行实时采集和存储[10-12]。首先由多功能数据采集卡对多路调理后的传感器数据进行实时采集，采样率设置为1kHz。由于是高速采集模式，这里采用高速数据缓冲存储器的方式向控制器进行数据传送，多通道的高速数据存于A/D板卡的大容量高速存储器上，缓冲大小设置为200个数据点，并且这里采用波形数据的传送方式，第一时间基于PXI控制器的时间为数据打时间标识，避免传送延迟对数据时间的影响，有效保证数据时间的精准，便于试验后的数据回看和分析。

PXI控制器实时系统定时访问高速存储器，一方面将实时数据高速流盘，另一方面采用NI的端到端网络流技术，将数据高速传输到上位机中进行数据存储，保证每次试验数据的双备份存储，即使出现网络异常情况，仍能保证数据的可靠存储。

这里采用了端到端网络流方式进行数据传输，通过创建网络流写入/读取端、向流中写入/读取数据、刷新流、销毁写入/读取方端点几步便可轻松实现数据的传送，并且每个网络流端点均通过FIFO缓存传输数据，可以有效保证数据无损耗，避免数据的丢失，适合于数据的高速连续传输。

图3 网络流数据传输示意

数据文件存储格式采用的为NI的TDMS文件格式，该格式为一种二进制记录文件，存储效率高、速度快，便于实现高速流盘。并且存储数据的同时可以存储相应通道或通道组的信息，可以方便的实现数据有效管理，其性能明显优于传统的文本文件和电子表格文件存储方式。

4 多系统数据对时同步

分布式数据存储虽然解决了设备布局分散、节点众多的问题，但是多系统数据如何保证采集时间的一致性，可以在同一个时间轴下做时域分析，就成为了新的需要解决的问题。

这里参考时钟网络同步NTP的方式对各测控子系统进行统一授时，采用最为典型的Client/Server授时方式，总控计算机作为授时服务器Server，各测控子系统PXI控制器作为授时客户端Client，原理如图4所示。

图4 NTP授时原理

各测控系统(授时客户端Client)与总控系统(授时服务器Server)之间通过网络共享变量方式进行时间信息的传递，具体过程如下：

1) 试验前Server首先开启授时服务程序，进行NTP授时变量簇中标志位的实时监测；

2) 之后Client基于事件驱动更新其中Client—Server标志位为真，同时记录Client的时间戳T1；

3) 当Server监测到Client—Server标志位为真时，更新变量簇中的Server_T2变量为Server当前时间T2，并且将Client—Server标志位更新为假；

4) 之后Server立刻更新Server—Client标志位为真，同时更新变量簇中的Server_T3变量为Server当前时间T3；

5) 当Client监测到Server—Client标志位为真时，读取变量簇中的Server_T2和Server_T3变量的值，并且记录Client的时间戳T4，之后清空相关变量的值，以备下次对时。

这样Client获得了4个时间戳T1、T2、T3和T4，当认为双向传输延迟d1和d2近似相等时，根据时间关系可以计算出往返延迟d和Client与Server之间的时钟偏差t。

(1)

可以看出，t、d只与T2、T1差值及T3、T4差值相关，而与T2、T3差值无关，即最终的结果与Server处理请求所需的时间无关。据此，各测控系统即可通过T1、T2、T3、T4计算出时差t去调整本地时钟与总控系统保持一致。

为了验证NTP对时同步的效果，这里利用多个系统按照1 kHz的采样率同时采集同一个压力传感器输出的电压信号，并将数据以TDMS文件形式存储在分系统本地空间，TDMS文件数据的横轴即为系统时间。这样测试后将多个系统采集的传感器数据置于时间域下进行数据回看分析，波形之间错开的时间即为系统之间的对时时间偏差。经测试各系统之间时间偏差能够控制在10 ms以内，证明了该对时方法的有效性。

5 数据集中显示

在试验运行阶段，为了保证指挥调度系统能够及时获得各分系统的相关工艺设备运行情况，便于指挥人员的统一调度协调，需要各分系统关键点数据能够在指挥调度系统界面进行集中显示。由于各测控系统数采上位机均是基于LabVIEW进行软件开发，这里可以很方便的通过LabVIEW共享变量的方式实现网络通信。

这里将各测控子系统上位机设为共享变量的服务器，提前完成共享变量的设置和部署，将总控指挥调度系统上位机设为共享变量的客户端，调用变量连接函数，通过打开变量连接、写入或读取变量、关闭变量连接等一系列操作实现各测控子系统共享变量的访问和读取。具体程序如图5所示。

图5 网络变量连接程序框图

这是LabVIEW的网络通信最简便的方法，用户不需要了解任何网络协议，就可以实现网络数据变换，而且为共享变量分配缓存器，避免了因读写不同步而导致的数据丢失，传输效率高，传输延迟低，支持多点对多点通信，广泛地应用于大型系统之中。

这里为了规范管理，提高程序可读性，变量格式采用簇的形式，簇内包括：采样时间、通道标签数组、通道名称数组以及通道数据数组。程序通过计算相邻两次的采样时间间隔，判断测控子系统的共享变量数据是否更新成功。如果不成功给出消息提示。如果更新成功，则根据界面显示需要，搜索对应显示控件在通道标签数组中的索引，并根据该索引提取通道数据数组中的数据赋值给对应显示控件，从而实现总控显示界面数据的更新。

为了保证各分系统关键点数据在试验时传给指挥调度系统进行显示，同时又不过多地占用网络带宽，各分系统以5 Hz频率更新共享变量数据。总控整体显示效果如图6所示。

图6 总控数据集中显示效果

总控指挥调度系统需要同时与多个测控子系统进行网络共享变量方式的数据交互，为了避免由于某个测控子系统未运行，造成共享变量连接程序报错的情况发生，这里总控指挥调度系统与每个测控子系统通信均采用一个独立的程序线程执行，并且每个线程均是基于队列消息处理器实现，程序首先通过互连接口面板中的“执行系统命令”vi调用CMD指令，利用“ping”命令检查对应IP设备是否连通，只有ping通才继续进行共享变量的连接和读取，并将数据保存至对应的全局变量中，以备总控显示程序调用，否则间隔一定时间继续进行连通测试。

为了验证多个分控系统与总控系统同时运行，进行大量数据存储和数据传输时的效果，同时开启总控系统和多个分控系统，各分控系统按照1 kHz采样率采集并以TDMS文件形式存储数据于本地，同时将数据抽点成5 Hz频率的低速数据以共享变量形式分享给总控系统，由总控系统进行显示，同时总控系统也以TDMS文件形式存储数据于本地。试验后提取分控系统和总控系统同一段时间内的数据进行展开分析，效果如图7所示。

图7 总控与分控系统数据对比

从图中可以看出，虽然由于总控系统数据的存储速率比较低，数据波形上的一些细节没有清晰呈现出来，但是还是能够较为完整地呈现数据的整体变化趋势。同时由于网络共享变量的数据传输延迟，造成总控系统数据存在100 ms左右的数据滞后，但是该延迟对于总控系统进行分系统的状态监控和指挥调度是完全能够接受的。

6 结论

本测控系统采用基于网络的分布式控制架构，通过运用OPC技术和网络流数据传输技术等一系列网络通信技术，实现了风洞系统的分布式运行控制和分布式数据采集存储，同时通过网络共享变量技术和NTP网络授时技术的运用，实现了风洞系统数据的集中显示和管理。该风洞测控系统已配合完成全系统多次联合调试，验证了上述各种网络通信技术的可靠性，解决了大型风洞系统大量数据交互的技术难题。