基于麒麟操作系统的运载火箭地面测试系统设计

，，

(装备学院 航天装备系，北京 101416)

0 引言

由于我国电子元器件工业基础相对薄弱，运载火箭地面测试系统使用的各类进口软硬件设备、核心元器件和高端通用芯片长期依靠进口，但西方发达国家经常采取禁运、限购等方式遏制该类产品在我国航天领域的应用，同时，国外相关软硬件设备还存在价格高昂、性价比低下、订货周期长、购置渠道不畅、代码不开放、技术服务不可控等问题[1]，对我国运载火箭地面测试系统的安全性、可靠性构成严重威胁。为从根本上解决这一问题，必须对运载火箭地面测试系统进行自主可控设计。麒麟操作系统作为核高基的重点研究项目，以兼容Linux的技术思路开发的高安全、高可用、高性能、高可定制的国产操作系统，目前已成功应用于国防、政务、能源、交通、航天、等众多行业和领域[2-3]，但在运载火箭地面测试领域的研究尚未深入展开。

目前，我国运载火箭地面测试系统主要基于Windows操作系统开发研制，如某型火箭数字笔录仪、数字化箭地信息检测分析系统等。本文结合自主可控技术，在对我国运载火箭地面测试系统研究的基础上，设计了一套基于麒麟系统的运载火箭地面测试系统。系统采用本文提出的数据库+二进制文件的存储方案管理数据，以及数字化的变频采样策略对数据进行采集，并对麒麟系统下采集设备的驱动程序进行了重新设计。经过系统测试，麒麟系统下的运载火箭地面测试系统实时性以及网络性能，与Windows下的同类产品性能相当，满足运载火箭地面测试需求。

1 系统设计

近年来，通过国家“核高基”科技重大专项带动，国内自主可控关键软硬件技术取得了重大突破，研制出了一批具有代表性的基础软硬件产品，例如飞腾处理器、麒麟操作系统、人大金仓数据库等，国产软硬件产品的安全性得到较好的保障，可用性得到较大的提升，性能在一定程度上满足使用要求，为运载火箭地面测试系统的自主可控设计提供了可能。

1.1 系统结构

测试系统包含硬件和软件两部分，其中硬件组成包含基于国产龙芯3A模块的箭上测量设备，银河麒麟计算机的地面测发控系统后端机，以及基于麒麟操作系统的前端CPCI总线工控采集机。

嵌入式箭上测量远置端设备主要负责箭上关键信号的隔离调理、采集、存储与传输；前端CPCI总线工控采集机主要负责箭地测发控系统关键信号的接入、隔离调理、采集、发控配电功能等；后端设备主要用于处理、分析前端发送来的测试结果并将其按要求进行显示。前、后端，嵌入式远置端与后端通过网络交换设备或光纤进行通信。

为了尽可能的对国产化软硬件在航天发射场合的应用进行验证，本系统信号输入包括低频模拟信号、数字脉冲信号。输入信号经前端采集机或嵌入式远置端机箱内的隔离调理模块调理，模拟信号由自主PCI总线或USB总线采集卡采集，数字信号由自主数字I/O卡采集，并与主板模块进行交互，由中央处理器处理。一方面，采集信息将转换成用户可用的图形传输至前端显示模块进行显示，另一方面，测试数据在前端或远置端存储的同时，通过网络传输至后端控制机进行实时显示、控制与在线判读。用户可通过控制机对整个系统进行测试控制，完成测试过程。系统的工作流程如图1所示。

图1 系统工作流程图

1.2 系统硬件设计

系统的嵌入式远置端主要用于模拟未来自主可控的箭上测量系统，其硬件设计包括信号输入插座、隔离调理电路、嵌入式计算机平台(ARM)， USB总线模拟信号采集卡、USB计数/定时器卡、网络接口、存储单元等部分组成。系统前端采集部分硬件由信号输入电缆、接插件、CPCI总线工业控制机箱、计算机卡、激励信号源、信号采集卡、数字I/O卡、信号隔离调理处理模块和继电器组等单元组成。系统前端采集部分通过多条电缆与箭上系统信号转接箱相连。

系统采集的模拟、数字即开关信号多达700余路。其中，模拟信号由两块PCI采集卡获取，数字、开关信号则通过以FPGA为核心的数字I/O卡以及脉冲计数卡采集。

模拟信号需要显示的通道数较多，数据量比较大，传统但缓存采集数据处理效率低，数据处理量受设置的缓冲区大小的限制，为提高数据处理效率，模拟信号的采集采用双缓冲采集模式。双缓冲模式是将缓冲区以循环的方式分成上下两半。双缓冲采集开始时，设备开始写数据到上半缓冲区，在设备开始写下半缓冲区时，可以处理上半缓冲区的数据，上下缓冲区交替存储，可以存储无限多的数量，提高了缓冲区利用率。

所有测量信号在调理输入端设计隔离电路，保证箭体和采集设备之间完全电气隔离，减少箭体和采集设备两者之间的串扰。系统硬件框图如图2所示。

图2 系统硬件框图

1.3 系统软件设计

麒麟操作系统为整个软件系统提供包括内核、设备驱动、通信协议、图形引擎等，是应用软件运行环境的重要组成部分，为上层应用软件提供对底层物理硬件的抽象和封装，组织和管理软硬件资源，控制程序执行流程，提供系统调用接口、驱动程序等，为方便与其他软件(如嵌入式数据库、集成部署框架)集成，操作系统还为上层软件提供标准的硬件访问接口和其他的基本操作系统服务。

为了实现系统长时间大容量采集以及综合处理分析的需要，系统使用支持国产麒麟操作系统的QT集成开发环境进行软件开发。为了缩短开发周期及便于后期维护，系统软件采用自顶向下与模块化设计相结合的方法[4]，采用单文档结构，并提供各种快捷工具条和按钮等，完成采集、图形实时显示与存储、事后回放、数据判读等功能，实现采集过程中的无人值守自动监测与人工控制相结合。

软件主要包括文件操作、参数设置、采集显示、数据处理4个功能模块。其中，单个视图利用qwtplot插件完成信号曲线的显示，单屏4*4共16个视图，并且利用XianshiSetDialog类进行界面X方向和Y方向视图数量的显示。利用XinhaoSetDialog类对信号的显示区域，信号曲线颜色以及通道的测量范围进行设置。QTcpSocket类实现前后端的信息通信，软件发出的所有动作均通过信号与槽的方式与相应函数连接。软件功能总框图如图3所示。

图3 系统软件功能总框图

2 关键技术

运载火箭地面测试系统采集的信号通道数达700余路，将产生大量的数据信息，并且不同通道间采样频率不同，给测试数据存储及变频采样带来很大难度。另外，系统硬件与软件之间连接的核心部分是驱动程序，需要进行麒麟操作系统下的驱动程序设计。因此，在具体设计过程中会遇到多方面技术难点，例如：测试数据存储、变频采样、驱动设计等。

2.1 测试数据存储

目前，运载火箭地面测试系统的前端和后端主要以二进制文件形式保存数据，这种方式不利于数据的查询与管理，数据库在数据管理方面具有独特的优势，在工业测试系统中广泛应用。国产数据库有达梦、神通、人大金仓等[5]。神通数据库支持SQL通用数据库查询语言，提供标准的ODBC、JDBC、OLEDB/ADO和.Net DataProvider等数据访问接口，并具有海量数据管理和大规模并发处理能力，已经在政府、电信、电力、国防、军工、教育等行业得到了大量应用。为了解决现有地面测试系统不便于数据管理问题，笔者设计了一种数据库+二进制文件的测试数据管理方法。

在数据存储方面有文件存储和数据库存储两种方式。文件存储中，由于二进制文件具有占空间小、读取和存储速度快等优点，在容量数据存储中被广泛使用，但不便于数据的检索。数据库存储具有便于数据管理、数据查询等优点，其机制主要是先将数据写入缓存空间，然后再从缓存空间写入到数据库中[6]，如通过内存缓存机制，由于运载火箭地面测试系统数据实时采集时，需要频繁的对数据库进行操作，而数据存入数据库所消耗的时间较长，容易造成数据丢失。因此在存储频率高的情况下使用内存缓存机制并不合适。将1 000个float数据写入数据库需要约13 s，而文件只需要2 ms。就存储空间而言，文件存储100个数据需要1 KB空间，因此存储5 000到10 000个数据只需要50～100 KB的空间。

鉴于以上问题，为了兼顾二者优点，系统前端由于空间有限仍然采用二进制文件存储方案，系统后端采用二进制文件与数据库结合的方式存储数据，即测试数据保存在二进制压缩文件中，而数据的索引保存在神通数据库中。地面测试系统数据采集的通道号是唯一的，将某次的二进制数据文件以相应通道号命名，建立起二进制数据文件与索引之前一一对应的关系，对数据文件进行索引。这种数据库+二进制文件的存储方案兼顾了二者的优点，可更加高效的管理数据。

2.2 运载火箭测试系统数字变频采样方法

目运载火箭地面测试系统采集的信号包括模拟电压信号、脉冲计数信号、不带电触点信号和时序开关信号，共计700余路，测试时间长达10小时以上，将产生大量数据信息，并且不同通道间采样频率不一样。因此，变频采样技术是研究的重点。

变频采样一般有两种实现方式：一种通过改变底层配置函数、AD时钟的方法，属于传统变频采样策略。这种方式一般是对所有通道频率整体修改，工作效率低，不能适应采集通道数多，频率改变频繁的测试试验要求。同时频繁改变硬件的采集频率，可能降低采集系统的可靠性。另一种是数字变频采样方式，核心思想是高速采样、选择性存储，即以固定采样频率进行采集，得到完整的数据源，根据不同采样频率需求，改变数据写入存储器的频率实现抽点存储，达到变频采样的目的[7]。这种方式避免了频繁的硬件底层操作，工作效率以及系统可靠性更高，相比传统变频采样，数字变频采样更加适用于运载火箭地面测试系统。

运载火箭地面测试系统变频采样实现方法如下。以1 000 Hz实际频率采集数据，将数据按通道分别存储至相应缓存中，根据各通道设置的采样频率获取每次需要存储的有效数据，达到变频采样的目的。数字变频采样的数据先存储至缓存空间，再存储至存储器，通过改变存入存储器的频率实现变频采样。采样频率在低速和高速之间变换时，会存在数据丢失问题[7]。由低速采样过程到高速采样过程中，当t1时刻触发时，数据以高速存入存储器，此时t1时刻之前的一段数据保存在缓存器，保证了两个交替子过程之间数据的有效存储，保证信号完整、有效。由高速采样过程到低速采样过程中，当触发后以较低速率存入存储器的数据时，会造成触发时刻之前的高速采样数据丢失，此时延迟改变存储器的写入速率，保证缓存器中的数据(触发时刻之前的一段高速采样数据)正确、有效的写入存储器，这样可保证信号完整、有效。

2.3 驱动解决方案

系统硬件与软件之间连接的核心部分是驱动程序，然而由于通用采集设备多依赖Windows操作系统，其驱动程序与应用函数库多是基于Windows操作系统定制，为了能够使自研或通用数据采集设备能够在基于麒麟操作系统的平台上顺利运行，必须要对相关的驱动程序进行匹配或者重新开发。

为提高系统工作效率，实现高速稳定传输目的，驱动采用DMA传输方式[8]。这种基于Linux 设备驱动的一大特点是可以以模块的形式加载各种设备类型。用户根据需要，在不对内核重新编译的情况下，将设备驱动模块动态地载入内核或从内核移出。采用模块化的设计方案，主要分为初始化模块、内存读写模块、I/O操作模块、配置空间访问模块以及中断模块。

基于Linux的麒麟操作系统中，中断服务并不是直接从中断向量表中调用，而是先接受来自硬件的中断，再由系统调用中断服务子程序。数据采集数量满足采集要求后，采集卡会产生一个中断，通知进程启动DMA传输，进行读写操作。

在运载火箭地面测试中需要大量的数据传输，这就需要若干轮次的DMA传输。每一轮的DMA传输完毕后，驱动便处于外部中断等待状态。外部中断触发后，应用程序接受中断并判断是否需要续传，若需要DMA进行新一轮的数据传输，否则释放资源关闭设备，结束传输。DMA传输及中断流程图如图4所示。

图4 DMA传输及中断流程图

3 系统测试

由于自主可控软硬件技术水平还有待完善，并且系统中核心元器件难以替代，因此系统各模块间的匹配会存在很多问题，系统的测试工作十分重要。对系统进行以下测试：

3.1 实时性验证

利用Cyclictest实时性能测试工具，利用麒麟操作系统提供的定时器和计数器，通过设置线程的数量以及优先级等参数，测试计算机的响应能力，其中最小时延20 μs，最大时延280 μs，平均时延32 μs。Windows平台下的地面测试系统最

小时延8 μs，最大时延215 μs，平均时延21 μs，麒麟系统下的地面测试系统时延较大，但是满足地面测试需求。

3.2 基于网络的远程化测试能力验证

地面测试系统前端作为服务器端，后端作为客户端，IP地址设置完成后，在测试系统各台计算机上，通过应用ping手段测试和检查网络连接正常，前端和后端数据收发正常。同时利用支持国产系统和Linux系统的Iperf网络性能测试工具对数据收发负载相应能力和组播能力进行测试。对于TCP协议，可以测量网络带宽，报告MSS/MTU值的大小和观测值，支持多线程。经测试，麒麟系统下的运载火箭地面测试系统网络带宽约为50 Mbit/s，Windows平台下的地面测试系统网络带宽约为45 Mbit/s，二者网络性能相当。

3.3 数据存储与查询功能测试

由于数据仍以二进制文件的形式保存，因此数据存储速度与现有地面测试系统存储速度相当，满足每秒1000个数据的存储需求，同时，系统兼有了数据查询功能，实现了以通道、日期、数据类型查询数据的功能，增强了系统的数据管理能力。

4 结论

本文结合我国运载火箭地面测试需求，设计了一套基于麒麟操作系统的运载火箭地面测试系统，对系统结构，硬件设计以及软件设计进行了详细介绍，并针对其中涉及到的关键技术提出了解决方案。测试结果表明，麒麟系统下的运载火箭地面测试系统的实时性以及网络性能满足运载火箭地面测试需求，对运载火箭地面测试系统的自主可控研究具有重要的现实意义。

[1] 毕锦栋, 郑丽香, 周军连,等. 电子元器件国产化替代工作探讨[J]. 质量与可靠性, 2015(3):35-40.

[2] 赵正旭. 麒麟操作系统使用与推广[M]. 北京：科学出版社, 2015.

[3] 刘 涛. 基于国产软硬件平台下办公软件插件的设计与开发[D]. 北京工业大学, 2014.

[4] 马永青, 谢 平, 陈宜成. 采用统一测试策略的运载火箭测试系统[J]. 航天控制, 2004, 22(4):87-90.

[5] 段 荣. 国产数据库在军事信息系统中的应用[J]. 电子技术与软件工程, 2015 (8): 208-209.

[6] 王加乐. 内存数据库存储管理设计与实现[D]. 复旦大学, 上海：2013.

[7] 陈昌鑫, 靳 鸿, 马铁华. 冲击加速度存储测试的变频采样策略分析[J]. 爆炸与冲击, 2015, 35(4):501-506.

[8] 裴喜龙, 童 莉. 基于PCI总线的高速数据采集卡系统设计与实现[J]. 微计算机信息, 2006, 22(19):129-131.