本白皮书为火箭发动机测试设施的设计和实现提供了全面指导。内容涵盖火箭发动机测试过程、火箭测试架构的关键要素以及测试设计的关键考虑因素,如系统延迟、定时和冗余问题。本文详细介绍了实现步骤,包括系统识别、技术选择和系统性能验证。还着重介绍了gRPC和iDDS等新兴技术,用于增强测试系统中的通信和数据管理
2021年是有史以来进行轨道发射尝试次数最多的一年。1世界各地的公司和政府共进行了146次飞行,其中135次成功入轨。1967年,正值美苏太空竞赛的高峰期,两国在太空探索和其他领域展开了激烈竞争,共计进行了139次发射尝试,2021年则再创新高。本世纪20年代的太空竞赛不仅限于这两个国家。目前,美国、英国、欧洲、俄罗斯、中国、印度、土耳其、伊朗、以色列等国家都参与其中;仅在2022年上半年,世界各国就已成功发射72次,这一趋势仍在继续。此类竞赛不再是政府主导项目,许多私有航天公司也在参与其中,吸引了大量投资者的资金进入市场。
新兴火箭技术正在推动空间发射次数的激增。2021年SpaceX成功进行了31次猎鹰9号火箭发射任务。由于采用了新的火箭设计方法,这些任务全部使用了之前用过的火箭芯级,只引入了两个新猎鹰9号一级火箭来进行发射。随着各公司和国家持续投资于提高空间发射的可靠性、可重用性和可负担性,发射次数和范围将继续增加。
支持发射的基础设施也在增加。目前有35个活跃的宇航基地和发射设施可支持亚轨道、轨道和轨道外任务。这些设施遍布全球,包括各大洲和超过13个国家,2其他国家也正在建设新设施。此外还有一些场所用于测试从这些设施发射的火箭。现在正是参与航天产业的大好时机。
美国联邦航空局(FAA)对在美国境内或美国境外由美国公民或实体进行的火箭发射行为进行监管。3其他国家也有类似的法规和监管机构;企业必须采取适当的工程步骤才能向太空发射火箭。其中一个关键步骤是测试火箭运载器,并证明其成功概率足够高。
测试火箭首先应测试火箭的各个组件。工程团队分别测试构成火箭结构、燃料和电子设备的材料和组件。这些组件随后作为子系统进行组装和测试,最后完全组装为完整多级进行验收测试。
NI产品用于运载器的各个方面。静态和疲劳结构测试平台是测试燃油箱承受飞行压力强度的理想选择。NI基于PXI的模块化仪器和自动化测试软件为测试航空电子设备电路提供了功能强大的平台。NI LRU HIL测试架构是生成各种测试用例来测试航空电子控制器的理想工具。
本文主要介绍火箭发动机的测试,但许多内容也适用于最终的整机测试。
火箭发动机测试是测试所有火箭发动机类型的重要组成部分;该测试必须符合FAA法规。但测试的价值不仅仅在于符合法规。美国航空航天局(NASA)的一份报告表明,测试火箭发动机所需的时间与这些发动机的可靠性之间存在正相关关系。4每个发动机制造商都必须决定如何平衡额外测试的投入和成本以及测试带来的预期效益。
火箭发动机测试台是一种用于固定和测试火箭发动机的结构,它提供必要的支撑和控制系统,包括压紧推力结构、推进剂、冷却系统、排气分流装置的地面支持设备,以及用于在测试过程中保证安全和操作管理的自动化控制系统。要测试火箭发动机,就需要将发动机安装在测试台中并在有限的时间内点火。火箭发动机测试台必须提供必要的压紧推力结构、推进剂、冷却系统、排气分流装置的地面支持设备,以及用于自动化测试和在整个操作和测试过程中保持安全的控制系统。工程师必须决定火箭是垂直安装还是水平安装,这两种安装方式各有优势。对于垂直安装的发动机,因为力的方向更接近于飞行时的情况,测量结果更易于与实际飞行情况进行对比。垂直安装的发动机在测试过程中存在的问题是会将废气排出火箭,这通常使用火焰分流器来解决。
图1.火箭发动机测试台的各个元素
排气会为测试设施带来若干挑战。除热量外,排气管噪声大且脏污。在排气装置处增加喷水散热装置可减轻热量对发动机的影响,同时还可以形成屏障来降低噪音和污染物对周围设施的影响。
火箭发动机测试有很多不同的形式。标准海平面测试可以在测试台上进行,无需大量其他设备,但其他测试可能需要专门的测试环境。例如,要测试用于空间卫星姿态控制的火箭推进器,测试台需要真空室来模拟发动机的预期工作条件。其他测试可能需要热真空室或其他机械设备来测试发动机万向节。
测试站也因发动机开发阶段而有所不同。因为工程师试图捕捉发动机性能的更多动态情况,所以早期开发阶段中的发动机测试可能包含许多其他传感器。在飞行前进行资格测试或验收测试时,测试台可测试较少的信号组,以验证发动机的正常运行。
负责设计火箭测试的工程团队在设计新的测试台时必须考虑所有这些潜在需求。随着火箭技术的不断发展,工程师还必须为未来可能需要的测试做好规划。测试设计必须足够强大以满足当前需求,同时也需要足够灵活以满足未来的需求。
30多年来,NI工程师一直与火箭测试系统设计工程师密切合作。随着新技术和软件技术的引入,架构逐渐成熟。相关应用(喷气发动机测试、风洞测试和其他大型测试设施)的最佳实践也影响了火箭发动机测试系统的设计。一些关键原则已成为成功设计火箭发动机测试架构的核心。
一个火箭测试设施可支持单个测试台或多个测试台。每个测试台需要不同子系统或发射台提供支持,这些子系统或发射台可能专为某一个测试台服务,也可能由测试设施内的多个测试台或地点共享。整个设施的地面控制系统主管将所有发射台和测试台集中在一起,协调设施资源的操作管理。
图2.火箭测试设施子系统
支持发射台控制系统必须提供控制可靠性,以及跟踪和改进性能的测量功能。
成功实现火箭测试场需要在多个系统之间进行仔细协调。多年来,针对主要空间设施已经开发出一种控制方案,其设计模式具有灵活性,可满足这些系统的通信以及测试间的系统变化。对于同时管理测试和发射设施的太空公司而言,可共享使用此类设计模式的许多组件,以减少测试内容和发射方式之间的差异。
该架构使用所有测试台和发射台通用的系统设计模式。该模式提供每个系统所需的本地控制,同时在系统间共享信息,确保测试操作保持同步。
图3.通用控制系统设计模式
下文会详述在这种模式中,控制系统如何从通信过程中读取输入。
换算过程用于将这些原始单位转换为适用于子系统的科学单位。同时,也能将多个通道合并为单个计算通道,例如,将全部推力测压元件求和以计算单个推力值。因为仪器可能会在测试之间或操作期间发生变化,换算过程还会应用可重配置的校准。
警报过程评估换算过程中的数据点输出,用以识别警报。警报可分为多个类别,例如立即中止测试的警报或通知操作员潜在问题的警报。警报过程可以管理测试序列的成功关闭,也可以向其他系统发送命令来管理这些操作。测试操作员可以使用此架构设计紧急停止或正常关闭。
如无阻止测试进度的警报,逻辑过程会分析来自读取、换算和警报过程中获取的值,以确定下一步操作。例如,逻辑过程可用于确定流体歧管的温度是否已达到可以打开阀门让流体流过管道的值(即在液氧歧管中进行冷却),因此它会向另一个远程子系统发出命令,或者将命令传递给顺序过程以在本地打开阀门。
然后,顺序过程根据测试操作员制定的条件(限制、边界和红线)以及飞行要求(模拟飞行控制)或发射/设施要求(模拟发射或正常测试操作),来有序执行确定的操作和定时事件。简单操作可立即执行;复杂操作可拆分为并行过程来处理顺序执行。顺序过程使用从读取、逻辑和警报过程中获取的值作为输入,并根据需要更新并行顺序过程的输出。
如图3所示,这些功能为一系列步骤;但在实际应用中,这种模式支持独立的并行模块运行自有线程,但与主操作编排线程同步。因此,主线程可以以一致的速度运行,而无需停下来等待操作完成。控制系统循环通常在1 Hz和400 Hz之间运行,具体取决于被控制的系统。
该通用设计模式可应用于任何控制系统,但在简单系统中,某些元素可能是可选的,也可能由其他系统处理。例如,一个简单的电机控制器可能没有警报过程,相反,基于控制电机的系统的输出,报警条件可能由另一个系统处理。 简单系统可能没有顺序过程,而是由非常基本的控制系统的逻辑过程直接控制,或通过iDDS或gRPC等方式由另一个控制系统的顺序过程进行控制。
图4.通信服务
控制系统通过通信服务读取和写入远程命令和遥测数据(例如,命令阀门打开或在另一个控制支持发射台的远程控制系统上启动序列)。这些服务是后台运行的守护程序或微服务,而非直接在主应用程序中执行。使用服务进行通信,而不是依赖于读取输入函数本身,从而主应用程序能够监控微服务的指标,因此任何问题都不会影响主应用程序的执行。该操作可将通信从主控制循环中抽象出来,随着搭载新通信接口的新设备不断出现,更新设备和配置会变得更加容易。
图4列出了一些通信服务的范例,但实际上有许多通信选项可供选择。设施设计团队可为设施建立自定义通信协议,或选择支持设施所用设备的标准协议。
购买新设备时,一个关键因素是该设备是否支持设施中现有的通信服务。控制现场通信协议的数量可简化软件的开发和维护。如果支持新的通信协议,使用服务可优化流程。
图5.通信服务设计模式
每项通信服务都应设计为可满足设备和协议的需求。
典型的通信服务包含一些常见的元素。服务的核心是状态机,用于跟踪硬件的当前状态,确定下一个预期状态。例如,设备可能需要在发送命令之前进行初始化,状态机跟踪设备的初始化状态,请求初始化,然后请求发送命令。该服务提供可由其他网络应用程序监控的指标,例如,步骤超时或与设备失去通信。这些指标可以提示其他系统执行相应的操作。
图6.操作员控制台
硬件接口使用供应商的API与硬件进行通信。
通信接口为协议打包数据,可能包括特定格式、元数据、加密或压缩。某些协议需要握手或配置管理,然后传输至状态机进行管理。
为便于操作员访问,每个控制系统可能都有一个操作员控制台或多个控制台。为避免控制系统混乱,通常只有一个活动控制台。这可能是一个专用控制台或带控制仲裁功能的控制台,支持操作员请求控制。
其中,需要考虑的一个设计特点是控制台的可重配置性。由于测试之间或测试期间测试需求会发生变化,测试工程师通常需要访问这些控制台中的其他数据。因为所需的大部分数据都可以通过通信服务获得,可以创建支持用户订阅新数据点的控制台,而无需更改实际软件代码。这为需要数据的工程师提供了灵活性,同时保护系统的其他部分不受软件更改的影响。例如,控制台可订阅通信服务中的所有数据通道,并让控制台用户选择要查看的信号。NI使用NI G Web开发软件创建Static Data Viewer时就采用了这种设计模式。
同样,设计人员应考虑是否以可配置的方式将命令信号公开给操作员控制台。如此,测试工程师无需更新软件就能更改控制功能,从而在快节奏的火箭测试环境中提高工作效率。在设计通信服务时应包含该功能,用于在读取输入步骤期间将数据传递至控制系统。
控制台可以是特定控制系统的专用设备或屏幕,也可以与其他控制台组合为操作员站。操作员站支持在单个位置查看和控制整个测试台。
所有这些结合在一起,就形成了一个完整的架构。
图7.火箭测试设施架构
该架构具有下列优点:
最后,完全组装好火箭测试设施后,可能与图8所示类似:
图8.火箭测试设施
本文所述的架构为火箭测试系统设计提供了一种设计模式。实现该架构需要做出许多工程决策。本文的目的是引导团队了解架构的各个方面,确保在设计过程之初就考虑到最重要的方面。
在决定如何实现架构时,经证明,以下主题是在过程早期需要考虑的最关键问题。
每个子系统以及整个测试设施中,为了保持测试区域的正常运行和安全,可接受的最大延迟时间是多少?
整个系统的延迟是多个设计决策的结果。更快的循环速度可以提高不同系统之间组件的通信速度。但工程师还必须考虑系统间的跳跃节点数,如果数据必须经过多个系统传递才能到达最终终端,则累积延迟会比数据直接在控制系统之间传递的延迟要多。进行设计决策时,应考虑如何将数据提供给其他系统:直接传递还是在多个系统间多次复制。
设施内分布的系统具有不同的时间时钟。那么,测量中可接受的时滞是多少?
大多数系统使用本地设备的系统时钟标记测量。如需跨系统分析数据,则跨系统关联数据非常有帮助。常见的解决方案是使用IEEE-1588或类似协议为所有系统提供绝对时间。时间可由设施监控系统提供,或系统可依赖GPS信号作为时基。
另一个相关的考虑因素是如何关联过程计算机和地面系统之间的数据。在火箭测试中,这相当简单,但在发射情况下,由于地面系统和火箭之间的任何连接都将在发射时丢失,就会变得更加复杂。由于测试系统会模拟发射条件,因此设计测试台时应考虑这一点。
哪些子系统在测试台之间共享,哪些子系统专用于特定的测试台?
考虑共享资源时需要平衡两种成本:复制资源的成本和共享资源的成本。安装低温液罐系统需要大量资金。但将低温流体输送至两个不同的测试台也会产生巨额成本,提高复杂程度。如果两项操作都需要使用该资源,共享资源还可能限制两项操作同时进行。
如何保护共享资源免受控制系统中竞争指令的影响?
由于通信系统缺乏纪律性,任何可由多个命令系统控制的控制系统都面临执行非预期操作的风险。例如,阀门可能根据测试台的请求开始操作,但如果第二个测试台覆盖了设定值,则两个测试台都将发生灾难性故障。
设计团队必须仔细检查系统的潜在竞争状态,确保系统中的任何命令信号都有适当的锁定程序。
如果数据在存储系统检索数据之前被覆盖,竞争状态也会影响测量数据,即获取的数据可能并非预期数据。
哪些系统必须具有冗余控制?采用何种级别的冗余?
冗余可以应用于系统中的许多位置,例如,冗余传感器、布线、采集设备、处理器、算法或电源。某些太空公司要求系统全程三重冗余,以实现最大程度的安全性。其他公司则识别最高风险的故障点,并将其视为冗余工作重点。
设计团队可为系统中的每个点选择多种冗余模型。备用冗余是指相同的次级单元会备份主单元。在闲置备用系统中,次级单元处于空闲状态,仅在看门狗发现主单元发生故障时运行。在活跃备用系统中,次级单元上电并主动监控系统,但其输出在看门狗切换控制之前不会被使用。这可以缩短故障时的停机时间,但由于次级单元处于活动状态,因此不会保持其可靠性。
模块化冗余类似于活跃备用方法,但两个系统并行运行,均为系统生成输出。投票系统(有时称为拍卖器或表决器)决定使用何种输出。当控制器之一发生故障时,可实现无扰传输。该模型可从两个控制器扩展至多个控制器。NI冗余系统基本概念白皮书对这些内容以及其他范例进行了讨论。
测量设备会受到哪些环境的影响?需要哪些其他基础设施来保护测量和控制设备?
在推进测试期间,测试台上或附近的设备将处于极端环境条件下。其中可能包括突然冲击、持续振动和高温。
在两次测试之间,设备也将面临环境的极端变化。高温或低温、湿度和盐雾都是对设备可用性构成威胁的具体因素。
工程师必须了解测试台的环境条件。根据这些信息,他们必须选择或设计超出系统潜在需求的设备。这可能需要购买坚固耐用的设备、增加防护措施(如保形涂层)或将设备放置在机柜或可控环境的建筑物中。
哪些网络技术可为网络上的数据传输提供最佳性能,包括组件故障时的冗余?
设计网络拓扑时有许多选项可供选择。成功的设施拓扑需要IT基础架构团队和测试工程团队之间进行详细的讨论。测试团队需要描述数据带宽、延迟和技术需求。IT团队需要了解加密、布局和冗余,以规划网络布局。
在设计网络进行决策时,设计团队必须确定冗余模型,包括在整个设施中运行冗余网线、使用快速生成树协议(RSTP)以及使用多个分配交换机。
需要测量或控制哪些信号?
工程团队面临的首要任务之一是收集测试台中需要测量或控制的信号列表。记录信号时,需列出信号类型、位置、分辨率、数据速率、激励需求、安全需求以及电压和电流水平。
通过这些信息,工程师可以将信号收集到测量组,然后选择合适的硬件来访问所有信号。
网络拓扑能否处理测试期间预期的数据量?
网络设计(包括计算设备、交换机硬件和子网架构)决定了可在网络上传输的数据量上限。设计团队必须仔细检查网络组件,查找系统中的瓶颈。
理论计算可为系统设计提供指导,但网络应用程序永远无法达到全部理论数据速率。数据开销和延迟会影响网络的总吞吐量。设计网络时,建议数据速率保持在显著低于理论极限的水平。
需要安装哪些安全系统?
火箭设施存在许多危险条件。系统设计、实现或操作中的任何错误都可能导致灾难性事故。设计团队必须了解联邦和地方法律要求的安全协议。设计团队还必须考虑如何保护测试站相关的人员、设备和区域安全,方法不仅限于法律规定。
考虑到火箭发动机使用的气体,火箭设施的某些区域属于危险区域。部分气体无法完全封闭,产生电火花即可能引发火灾或爆炸。为防止出现这种情况,危险区域内的任何设备必须都是本质安全的,即不会产生火花。这可通过将电气设备移出危险区域来管理。电控阀可置于区域外,因此区域中的唯一设备就是连接区域外阀门的管道。
如设备必须位于危险区域内,设备供应商必须对其进行本质安全认证。在美国,这意味着需要通过Class 1 Div 1认证。在欧洲,这意味着需要根据气体类型进行ATEX认证。
如设备位于危险区域外,但其信号进入危险区域,则设备必须具有本质安全屏障,以防止设备中产生的火花进入危险区域。即使是低电平设备(如热电偶测量仪器),也需要本质安全屏障,以防止设备的电源(如连接的电源)进入该区域。本质安全屏障可以安装在设备与危险区域之间的信号路径中,提供电压和电流峰值保护。注意,本质安全屏障因信号类型而异,因此专为热电偶设计的屏障不适用于阀门控制器。
设施、支持系统和测试台需要满足哪些认证?
根据人口、设施用途、当地法律和火箭设备用途,不同地区需要不同的认证。例如,在美国空军基地进行的火箭测试在执行任何火箭活动之前,均需获得AFSPCMAN 91-7108认证。
除了执行测试所需的认证外,认证还会影响测试的目标。如测试的目的是验证火箭发动机的可用性,测试台的设计必须满足该认证的要求。例如,MIL-STD-8109可确保被测设备满足产品使用的预期条件。MIL-STD-20210可确保重量在300磅以下的组件满足严苛应用中的电气和环境要求。如果美国国防部是被受测技术的预期客户,这些可能都是必备条件。
带有测试台和支持系统的火箭测试设施设计项目不仅工程量大,还需要注重细节。本文旨在提供一种通用的设计模式和设计过程方法。概述每个步骤不在本文的讨论范围之内,但设计过程均遵循这些基本步骤。如果此过程超出了设计团队的能力范围,请参考以下服务章节,获取有关如何与NI及其合作伙伴合作进行设计过程的信息。
输出:设计要包含在设施中的系统和子系统的结构框图
首先布局设施系统。根据设施的当前和未来需求,规划测试台和支持系统的位置。规划系统间的传输和连接。决定共享哪些支持系统,哪些专用于测试台。
输出:设施中每个系统和子系统的详细设计要求
对于每个已确定的系统,记录其要求。列出预期的输入和输出,包括更新速率和通信协议。记录系统的预期功能,包括所需的性能。确定公司中负责设计每个系统的职能团队。
输出:用于连接设施的系统和基础设施的详细要求
根据系统要求,确定设施系统支持这些系统所需的性能。记录满足所有系统和组件延迟要求所需的更新速率。与IT团队合作,概述满足系统要求的网络基础设施要求。计算系统中最差情况的数据速率。
输出:涵盖系统和设施要求的技术列表
利用系统和设施要求,确定为满足记录需求而需要获取或开发的特定技术。与供应商会面,确定可用的现成技术。与工程团队合作,为系统中剩余的空白部分确定自定义工程方法。可能的话,测试系统的性能,确保系统满足要求。
输出:记录系统和设施设备使用的每项通信服务的要求和实现
充分了解系统的可用技术后,记录每项通信服务的需求。确定每项服务的输入、输出和处理过程。确定全面实现服务所需的专业知识。
输出:设施中每个系统控制器的设计文档
将系统要求应用于为系统和设施选择的技术。根据特定性能标准记录所需的输入、输出和功能。确定实现系统控制器所需的专业知识。
输出:每个系统控制器和系统间运行的代码
开发在每个系统控制器和每项通信服务上运行的代码。记录要求文档中的任何更改,并验证更改不会影响其他系统。在开发过程中,应用适当的工程原则,包括单元测试,以验证每个组件是否符合记录的要求。
输出:在控制系统间更新值
连接系统控制器和通信服务。验证系统是否正常工作并在预期性能范围内运行。连接组件、子系统和系统后,继续对其进行单元测试。
输出:验证每个系统组件、系统和互连系统的性能
整个系统就绪后,对所有系统和系统整体进行全面测试。查看要求,验证是否满足所有要求。向开发人员报告任何非预期行为,并反复迭代直至获得预期的性能。
输出:操作员屏幕和工作站用于控制和查看系统
操作员控制台随系统一起开发;改进控制台应用可用性并创建最终操作员控制台。
在火箭测试架构中,可使用的现有技术均有几项最新进展。
gRPC是一个开源的高性能框架,可在任何环境中运行。gRPC由Google开发,基于远程过程调用(RPC),作为一种在系统不同部分间传输数据的方法,gRPC在过去五年中迅速发展。使用gRPC,客户端应用程序可像调用本地对象一样直接调用其他机器的服务器应用程序中的方法。这简化了创建分布式架构的过程,比如火箭测试架构。NI软件和硬件工具可与gRPC配合使用。获取有关gRPC支持资源和兼容性的信息。
iDDS是劳斯莱斯(Rolls Royce)和MDS Aero为喷气式涡轮发动机测试共同开发的数据抽象协议。它提供从仪器节点收集数据的通信服务,供网络订阅者使用。iDDS基于数据发布服务(DDS)主干和对象管理组(OMG)标准而构建。iDDS定义了DDS网络上仪器数据的打包,包括通道元数据、时间戳、配置和运行状况监测等测量数据。因为设备间的通信在iDDS模型中是标准化的,所以特定供应商的功能被抽象化,即使设备来自新的供应商,新技术出现时也易于替换设备。
NI为火箭发动机测试提供量身定制的硬件和软件解决方案,其中集成了不断变化的安全要求、新型传感器和基于市场需求的技术。我们的软件提供自定义测试解决方案、实时数据可视化、数据记录和自动化测试序列生成的工具。这些软件解决方案通过强大的自适应平台,增强了数据分析、设施管理和整体测试效率。
NI PXI、NI CompactDAQ和NI CompactRIO等硬件平台能够承受极端条件并支持多种信号,确保在火箭发动机测试期间进行可靠、精确的测量和控制。这些坚固耐用的模块化系统提供分布式测量和本地处理能力,提高了测试精度和灵活性。了解我们的火箭发动机推进测试解决方案,了解如何在更短的时间内测试更多发动机。