大型火箭发动机地面试验系统测控软件架构设计

许广柱，吴锦凤

（西安航天动力试验技术研究所，陕西西安710100）

0 引言

大型火箭发动机地面试验测控系统设计分硬件和软件两部分。由于目前国内外大部分工业测控硬件都已有系列化的成品设备仪表，所以在硬件设计过程中，绝大部分工作是这些设备仪表的线路连接和硬件分布式设计，而大部分软件设计都是根据不同类别火箭发动机试验系统特点有针对性地自主编写。因此，地面试验测控系统软件设计在整个试验系统中的重要性和比重越来越大，其难度也与试验系统规模密切相关。对大型火箭发动机地面试验系统而言，由于试验涉及参数种类繁多，其测控设备和子设备数量庞大，所以，软件的结构和开发模式对整个测控系统的使用效率、工作人员配备以及试验效果等有着决定性的影响。

1 大型火箭发动机地面试验系统现状

大型火箭发动机地面试验系统一般包括：火箭发动机、推进剂供应系统、环境模拟系统和测控系统四部分。其中，发动机推进剂供应系统负责提供燃料和氧化剂；环境模拟系统模拟高空或者真空等环境以实现地面的模拟环境试验；测控系统负责发动机试验过程的控制和参数测量。

试验系统概括起来有如下几个特性：

测控系统测量参数种类众多，一般包含压力、温度、流量和振动等参数，几乎涵盖所有的工业测量参数；

参数物理量范围大且同种参数的测量传感器类型繁多。如压力可以从1 Pa～60 MPa、温度可从-260℃～3 000℃；一次试验中测控使用到的温度传感器类型可能有铂电阻、热敏电阻和各种热电偶等多种。

由于以上这些特性，导致了系统分类/分组测控困难及设备数量庞大等问题，相应地也给测控软件设计编写带来很多困难。到目前为止，国内大型火箭发动机地面试验测控系统软件基本上都是直接根据硬件分系统类型一对一的设计编写，也就是说，有多少个测控分系统就有多少个应用软件，而且很多院、所在测控软件设计上都采用一个分系统由一个设计人员从头到尾设计编写整个应用软件的方式，甚至每个设计人员之间没有协作和沟通，编写出来的应用软件风格不同，通用性差。这种软件开发模式很明显不利于维护和操作人员培训交接等后续工作，更不利于软件故障诊断和定位。图1是大多数大型火箭发动机地面试验测控系统设计采用的架构示意图。

对于火箭发动机试验测控系统来说，对象群是指被控制/测量的各种物理参数（如：阀门开关、压力、温度和流量等）分类/分组对象。其中软件部分大多采用以下软件开发模式（以下简称为常规开发模式）：图2是常规控制软件功能框图，图3是常规测量软件功能框图。

常规开发模式中，采用的是过程式程序设计，所有程序流程都是按照操作过程设计编写的。很显然，其中有很多重复功能代码，且由于很多实际设计中不同软件人员设计编写整个程序，无法统一规划和管理，而在软件规模控制上，只有通过减少控制/测量对象，群的数量才能减少，操作人员的数量相应变化。从大型火箭发动机地面试验系统几个特性可以看出，由于控制及测量的参数和对象数量庞大，参数种类繁多，难以按“群组”分组测控，影响测控归一化管理，相应地测控分系统数量n就会多（n≥3）。因此，在不减少测控分系统数量的前提下，这种程序设计范型效率低且控制难度大。

2 面向过程和面向对象设计方法比较

面向过程设计方法是一种自上而下的传统设计方法，上面提到的常规开发模式就是面向过程的设计模式。其特征是以函数为中心，细化函数来划分程序的基本单位，数据在面向过程设计中往往处于从属的位置。这种模式的优点是易于理解和掌握，逐步细化问题的设计方法和大多数人的思维方式比较接近。然而，面向过程设计对于比较复杂的问题，或是在开发需求变化比较多的时候，往往显得力不从心。这是因为过程式设计是自上而下的，它要求设计者在一开始就要对需要解决的问题有一定程度的了解。在问题比较复杂时，要做到这一点比较困难，而当开发中需求变化的时候，以前对问题的理解也许会变得不再适用。事实上，开发一个系统的过程也是对一个系统不断了解和学习的过程，而过程式设计方法忽略了这一点。另外，过程式设计还有个问题就是其设计的程序架构的依赖关系问题。主函数依赖子函数，子函数依赖更细小的子函数。最底层的子函数其实就是需求细节的实现，而这些实现因需求变化而常常变化，这样的结果导致整个程序的核心逻辑依赖于外延的细节，本应该稳定的程序核心逻辑也因此依赖关系变得不稳定。合理的依赖关系应该是反过来：细节实现依赖于核心逻辑。

面向对象（Object Oriented）设计是一种自下而上的设计方法。设计过程一般从问题的一部分着手，逐步构建出整体。面向对象设计以数据为中心，类作为表现数据的工具，是划分程序的基本单位。函数在面向对象设计中成为了类的接口。由于面向对象这个自下而上的特性，允许开发者从问题的局部开始，在开发过程中逐步加深对系统的理解。这些新的理解以及开发中遇到的需求变化，都会再作用到系统开发本身，形成一种螺旋式的开发方式。面向对象程序设计中，类封装了数据，类的成员函数作为其对外的接口，抽象地描述了类。用类将数据和操作这些数据的函数放在一起，就是面向对象设计方法的本质。引入面向对象的继承特性，可以将设计中越来越多的模块之间的依赖型简化，使整体设计的核心健壮稳定，架构清晰明朗。

由于面向对象设计体现了数据的封装，避免以前过程式设计方法中任何代码都可以随便操作数据而造成的缺陷，而查找修改这种缺陷是非常困难的。面向对象设计方法在软件体系结构方面是强制性的，从而在程序编译阶段就可以解决惰性问题，而不用在程序运行阶段再去查找问题。

3 RUP和“4+1”视图建模简介

RUP （Rational unified process）即 Rational统一过程（又称统一软件开发过程），是一个面向对象且基于网络的程序开发方法论，其核心思想是：尽早并且持续地化解重大风险，确保满足客户需求，重点放在可执行软件上，尽早在项目中适应变化，在早期确定一个可执行的架构。基于RUP进行软件建模带来的好处也在于此。

Philippe Kruchten提出的“4+1”视图模型由5个主要视图构成：用例（场景）、逻辑视图、过程视图、物理视图和开发视图，目前已被RUP采纳，成为架构设计的标准。通过此视图模型进行软件面向对象分解后建模，可以提高软件的复用性、扩展性和可维护性。

4 地面试验测控系统软件建模

综合面向对象、基于RUP的“4+1”视图模型和地面试验系统测控软件开发经验，对大型火箭发动机地面试验测控系统软件进行“4+1”视图建模，可以得到很好的软件架构。由于控制和测量在原理上有较大区别，所以在设计上还是采用相对独立的原则。

设计从各个基本功能元素入手，编制相对独立的完整功能类（class）或结构（struct），通过各自的接口函数构成程序各功能结构模块。图4是控制系统软件过程视图，控制时序部分是控制程序的中心，它对系统主控逻辑进行分析、判读和逻辑输出，板卡的控制采用命令方式，解析后通过硬件接口与硬件板卡交互数据，控制命令是根据硬件配置生成的规范化硬件控制命令包，比如：主控时序需要控制参数Param1对应的电磁阀关闭 2 s，命令包就如 CLOSE@SLOT_1@Param1@2这种形式，经过命令解析后发送给硬件接口，板卡就会执行此命令关闭SLOT 1槽位上板卡中Param 1电磁阀对应端口电平2 s；通过板卡的数据反馈及时获取数据后进行数据处理并存储，再通过消息的方式实时显示主控时序的执行过程，实时显示的具体形式是根据事先配置定制的诸如流程显示的图形。

测量软件中心是数据处理功能块，所有的数据都是通过它与其他模块交互。图5是测量系统软件过程视图。所有实时数据的获取都是通过数据实时采集模块进行的，它直接控制硬件并交互数据；内存池非常重要，它作为采集数据的缓冲区临时存储数据，是所有功能模块的数据源；数据算法根据需求定制不同的数据处理函数，包括各种处理公式、数据输入接口、数据输出接口和异常数据剔出处理等，由数据处理模块根据人机交互的请求实现不同的数据处理功能；数据处理模块将众多的功能请求（比如：试验数据采集、参数校准、存储数据和打印报表等）集中，通过主线程人机交互模块中介，实现相应的处理；实时显示通过消息的方式从主界面获得数据并显示相应的需求图形；数据存储模块分为实时数据存储和事后数据存储，实时数据通过本地硬盘进行二进制文件形式存储，事后数据处理的数据一般采用数据库存储方式，模块必须实现所有的数据库操作和数据的封装。测量软件与控制软件设计不同在于数据处理需求多且复杂，因此，在数据处理需求分析过程中，必须细化各种需求，分类汇总，构建健壮的类模块。

图4和图5的视图模型适用于测控分系统软件设计和整体设计。如果测控硬件设备属于同一公司产品，因软件平台统一，一般情况下可以将所有分系统软件合并为一个应用软件，设计中只需对各个模块功能依据板卡驱动或者板卡执行命令来扩展功能即可，整体设计建模完全不需要改动，软件的扩展维护很显然是非常容易的。如果测控分系统硬件设备分属不同公司，软件平台可能不一致，导致不能合并分系统软件程序，但每个分系统软件的设计模型仍可采用上述建模，因建模统一，在使用过程中扩展维护也比较简便。

通过在硬件结构上的调整，采用分布式测控设备和以太网构建局域网的方式，相应测控软件在以上视图模型基础上稍作调整即可形成高效的软件架构。图6是基于以太网的控制系统软件体系结构示意。考虑到控制系统的实时性，将软件配置和逻辑控制通过主控端分发给各控制分系统软件，分系统对时序分析后直接进行实时控制操作。

基于以太网的测量系统软件体系结构如图7所示。测量分系统机将测量所得数据通过以太网传送给服务端，所有数据分析和处理均由服务端程序执行。

通过统一软件建模，不论控制系统软件还是测量系统软件，由设计人员根据需求制定编写规范和接口，每个功能模块都应分解并采用面向对象编程进行数据封装设计。利用面向对象编程语言（如：C++和C#等）进行类模块代码编写，规范化类实例继承特性。在代码编写过程中，避免大量使用全局变量；对于父类的设计，注意总结归纳，利用面向对象的多态特性，在子类里编写细节实现代码。对于模块的发布方式，尽量采用动态链接库的方式，这样可以做到改动一个对象实例功能代码，只需要重新编译此对象模块即可，其他模块完全不需要改动。为了规范化代码编写过程，有必要制定统一的代码编写规范，按要求注释代码功能，建立代码修改日志文档，这对于系统软件的功能修改、扩展和发布等有很大的帮助。图8是基于“4+1”视图模型建模后整个火箭发动机地面试验测控系统的架构示意图。

由图可看出：将以前复杂众多的分系统软件分解和归纳，总结其特征并统一设计结构，可做到所有控制分系统和测量系统也只由一套测量软件进行后台操作，最终在整体层面上，只需要两个系统应用软件和相应的操作人员即可。

参考开发规范，火箭发动机地面试验测控系统软件设计需确定一个设计小组分工设计软件，每个模块设计都需要分工协作，好的模块接口是整体应用便利、日后维护和故障定位的前提。

基于RUP的“4+1”视图模型建模方法给出了粗线条的整体设计方式，在实际操作中，各系统的功能模块还需要根据需求再分解，以达到整体设计的高重用性、高可靠性和高效性的效果。

5 结束语

综上所述，依据统一软件开发过程和面向对象设计思想，借助目前各种优秀的面向对象编程语言，可以为大型火箭发动机地面试验测控系统软件设计带来较好的效果，在设计过程中就能最大程度地避免风险和适应工程项目的需求变化，从而在工程早期就确定一个可执行的软件架构，提高测控软件使用效率、减少操作和维护人员、更好的故障定位和系统扩展。

[1]比约尼尔（德）.软件工程卷1～3[M].刘伯超,译.北京:清华大学出版社,2010.

[2]何炳林,张焕文,梁柱扬,等.基于ADS1252的数据采集模块设计[J].现代电子技术,2011,34(13):139-141.

[3]邵维忠,杨芙清.面向对象的系统分析,面向对象的系统设计[M].北京:清华大学出版社,2003.

[4]KRUCHTEN P.The 4+1 view model of architecture[J].IEEE Software,1995,12(6):42-50.

[5]张磊.基于FPGA与PCI总线的实时控制计算机的设计与实现[J].电子设计工程,2011,19(20):173-180.

[6]KRUCHTEN P H,THOMPSON C H.An object-oriented,distributed architecture for large scale Ada systems[C]//Proceedings of the TRI-Ada'94 Conference.Baltimore,USA:ACM,1994:262-271.

[7]张春祥.软件体系结构理论与实践[M].北京:中国电力出版社,2011.

[8]毛顿,郭庆平.LabVIEW中用DataSocket技术实现网络化应用[J].现代电子技术,2002(3):70-71,85.

[9]杨海成.航天型号软件工程[M].北京:中国宇航出版社,2011.

[10]孙诚,王雪梅,张艳红.连接计算机并口的数据采集系统[J].电子设计工程,2011,19(16):48-50.