Next Article in Journal
A Novel Optimization Strategy for Reducing the Initial Error of a Quasi-Steady Algorithm for Conjugate Heat Transfer
Previous Article in Journal
Propagation of Interactions among Aircraft Trajectories: A Complex Network Approach
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Petri Nets Applied in Purge Algorithm Analysis for a Rocket Engine Test with Liquid Propellant

by
Evandro Rostirolla Bortoloto
1,*,
Francisco Carlos Parquet Bizarria
1 and
José Walter Parquet Bizarria
2
1
Instituto Tecnológico de Aeronáutica, São José dos Campos 12228-900, Brazil
2
Departamento de Informática, Universidade de Taubaté, Taubaté 12020-270, Brazil
*
Author to whom correspondence should be addressed.
Aerospace 2023, 10(3), 212; https://doi.org/10.3390/aerospace10030212
Submission received: 15 January 2023 / Revised: 9 February 2023 / Accepted: 22 February 2023 / Published: 24 February 2023

Abstract

:
During the development stage of a space vehicle, instrumented tests are carried out on the ground to prove the operational capacity of each liquid-propellant rocket engine, which is installed in this type of vehicle. The task of elaborating a Test Bench project for a propulsion unit with this application is complex and involves several steps, one of these steps being related to the analysis of this bench capacity to meet the algorithms for the liquid-propellant rocket-engine full run of tests, which is considered fundamental for this project’s operational success. Due to the high costs involved in this project’s elaboration and execution, it is strategic to use computational resources to evaluate, by simulation, the main operational functionalities that are previously established for this bench to perform. In this context, this work presents a model proposal through Petri Nets to evaluate, by computer simulation, an architecture capacity that was designed for the Test Bench to meet an algorithm dedicated to the liquid-propellant pipelines purge during the run of hot tests with the liquid-propellant rocket engine. The method used in this work to carry out the simulation shows the operational response of each module of this architecture, in accordance with the steps contained in the purge algorithm, which allows for analyzing, for each event of the process, the Petri Nets properties, mainly those related to the conservativeness, liveliness, deadlock-type, and confusion-type conflicts. The simulation carried out with the proposed model allows for the portrayal of the physical architecture and the operational states of the purge system according to the steps foreseen in the algorithm, showing that the conservation property is met because the number of marks remains constant, the vivacity property is also met since all positions have been reached, and there is no mortal-type conflict, as the simulation is not stopped; only confusion-type conflict is identified, which was solved with the strategic insertion of resources in the model in order to fix crashes related to the competition for tokens in the transition-enabled entries. The satisfactory results obtained in these simulations suggest that the modules provided for this architecture are sufficient and appropriate for carrying out all the steps contained in the purge algorithm, which will minimize or even eliminate the disorders that may be caused by the presence of foreign elements in the propellant supply lines during the tests with the rocket engine.

1. Introduction

The current level of technological development has enabled space exploration with rockets that mainly use propulsion units based on liquid propellant during space vehicle operation [1,2]. Furthermore, historical experience supports the importance of carrying out instrumented tests on the ground to determine the effectiveness and operational efficiency of these propulsion units. Such activities have to be carried out during the stages of development, qualification, certification, and acceptance, aiming to demonstrate the acceptability of the systems that compose the rocket-engine set [3,4].
Most of these tests are carried out in facilities called Test Benches. These have to be flexible and modular, enabling tests with the aforementioned set and collecting essential performance parameters from the propulsion units [5,6]. In addition to this, elaborating projects to meet structures of this nature is considered a complex task and must be carried out in several stages. One of these steps is related to the established algorithms for the complete performance of tests with a rocket engine, which is considered fundamental for the operational success of this project [7,8].
Among these algorithms, there is a logical sequence of instructions dedicated to the command of the inert gas flow control valves used in the purge system. This procedure is carried out to perform the effective cleaning of the lines, thus avoiding the presence of foreign bodies and volatile mixtures in the ducts used in the tests [9,10,11]. Based on this, and considering the application characteristics, it is possible to use the graphical modeling method, with mathematical support, called Petri Nets. This method can visualize the dependencies of the pairs in the system to test properties, to carry out performance analysis, and to simulate discrete events, among other things [12,13].
Among the several possible applications in the segment at hand are those related to:
  • A distinctive resource for assisting the algorithm analysis that is intended to be used in rocket-engine tests.
  • The use of Petri Nets in the evaluation process of routines used in a Rocket-Engine Test Bench.
  • The introduction of graphical modeling with a mathematical basis for the study of dynamic systems and discrete events applied in the analysis of algorithms dedicated to the purge process.
  • The capacity of the simulation of a model through Petri Nets to show anomalies and/or ambiguities arising from the rocket-engine test process in a Test Bench.
  • The possibility of modeling and simulating systems that encompass the three main levels of system automation.
  • The capacity of evaluating the properties of a system model drafted through Petri Nets and proposing improvements that contribute to making it safer and more robust.
  • The possibility of carrying out simulation analysis as well as implementing new resources and functionalities in the architecture used in order to improve the performance of liquid-propellant rocket-engine tests, among other things.
In this context, this work presents a proposal for a model through Petri Nets to evaluate, by computer simulation, the capacity of an architecture that was idealized for a Test Bench. In addition to this, the method aims to meet an algorithm dedicated to the purge of liquid propellant pipelines during the execution of hot tests with the liquid-propellant rocket engine.

2. Goals

The main goals of this work are: (i) presenting a model proposal through Petri Nets to simulate the steps established in the algorithm that perform the purge of ducts that serve the liquid-propellant supply lines for a rocket engine in a Test Bench and (ii) showing the most relevant results that were obtained with the validation tests of this algorithm.

3. Test Bench

These facilities can be segmented into three main parts: (i) the hydraulic system, (ii) the control and supervision system, and (iii) the operation and support infrastructure; this last one contains the gantry responsible for supporting the thrust force generated during the operation of propulsion units [14,15].
Typically, the Test Bench should enable the installation and testing of different models and/or rocket-engine families, in addition to providing integration with other elements of the system, such as tanks, piping, control valves, sensors, actuators, regulators, telemetry instruments, and refrigeration circuits, among others, as shown in Figure 1 [16,17].
Among the different activities that can be carried out in these facilities, those pertinent to the development, integration, validation, and certification of new engines stand out, allowing (mainly) for the evaluation of parameters related to: (i) the thrust, (ii) the mass flow, (iii) the temperature, (iv) the vibration, (v) the stability of the set when subjected to the limit of requests, and (vi) guaranteeing that all hardware and software elements meet the requirements established for the project [18,19].

4. Purge System

In its majority, the system that purges the ducts that serve the rocket-engine liquid-propellant supply lines in the Test Bench is designed to command, monitor, and control the actuation of valves, pressure regulators, and other elements contained in the installation before the specimen ignition, aiming to expel foreign particles and volatile mixtures, effectively cleaning the last section of these ducts that serve the engine [20,21].
After the hot operation of the engine, the system is activated again to remove the residual fuel and oxidant in the supply lines, which represent potential risks of combustion and/or accidental contact due to leakage and evaporation while handling the components connected to the rocket engine [22].

5. Petri Nets

This graphical modeling method, with mathematical reasoning, was presented in the 1960s by Carl Adam Petri in his doctoral thesis Kommunikatin Mit Automaten (Communication with Automata), defended at the Faculty of Mathematics and Physics of the University of Darmstadt, Germany, which addresses the study of dynamic systems and discrete events as an alternative to avoid the existing state explosion in the graphical representation of systems modeled by automata [23].
Considering the mathematical formalism, Petri Nets can be defined as a quintuple, as represented in Equation (1), because they have directed, bipartite, and weighted graphs, containing a position node and another of transition, connected by oriented arcs in the model [24,25].
R P   = P ,   T ,   A ,   W ,   M 0
The nomenclatures contained in Equation (1) have the following meanings:
RP = Petri Nets.
P = {p1, p2, …pm}: finite set of places.
T = {t1, t2, …tn}: finite set of transitions.
A ⸦ (P × T) ∪ (T × P): finite set of arcs.
W: FN+: function that assigns the weight of each arc.
M0: PN: initial selection function.

6. Development

The elaboration of a model proposal through Petri Nets to represent the liquid-propellant supply-lines purge process during the rocket-engine operational evaluation in the Test Bench requires the following definitions to be established in advance: (i) physical architecture that will be used to perform the purge, (ii) algorithm containing the essential steps for the propellant purge, and (iii) computational resources—hardware and software—necessary to perform the pertinent simulations.

6.1. Physical Architecture of the Purging System

In this work, the elements established in the component diagram shown in Figure 2 are considered as an example of physical architecture for carrying out the purge of rocket-engine liquid-propellant-lines ducts in the Test Bench.
The acronyms defined for the elements contained in the aforementioned architecture have the meanings and characteristics shown in Table 1. These definitions are compatible with and similar to those used in rocket-engine test facilities that are used in the Brazilian space sector.

6.2. Purge Algorithm

The specific sequence of macro actions foreseen in the algorithm that performs the ducts purge which serve the liquid-propellant supply lines for the rocket engine in the Test Bench is contained in the synthetic flowchart shown in Figure 3.
The process blocks represented in this flowchart are related to the steps of the algorithm, as shown in Table 2.
It should be mentioned that the conditional decisions contained in the flowchart shown in Figure 3, have outlets indicating 1, 2, 3, 4, 5, and 6, which refer to subroutines containing specific processes for handling each of these events, which are not addressed in this work; however, after the possible performance of these subroutines, the main flow of actions returns to the connector with indication 7.

6.3. Model by Petri Nets

The model to be prepared must represent the Petri Nets in a distinct manner, linked with the following automation layers foreseen for the purge system: (1) HMI—Human–Machine Interface, (2) Control, and (3) Sensor Actuator. The division into levels or layers mainly aims to divide the elements that compose a system into different groups, facilitating the interpretation of the role played by each level or layer established in an automation architecture, as shown in Figure 4.

6.3.1. First Layer Model

The Figure 5 shows an example of a model created through Petri Nets to represent the operational states considered for the set actuator and sensor of the V31 valve, contained in the component diagram shown in Figure 2.
In this figure, position p1 is defined to represent the closed state of valve actuator V31, position p2 is defined to represent the open state of valve actuator V31, position p3 is defined to represent the closed state indicated by valve sensor V31, and position p4 is defined to represent the open state indicated by valve sensor V31. Transition t1 is set to change valve actuator V31 from a closed state to an open state; transition t2 is set to change valve actuator V31 from the open state to the closed state; transition t3 is set to perform the indication change of valve sensor V31 from a closed state to an open state; transition t4 is defined to perform the indication change of valve sensor V31 from an open state to a closed state.

6.3.2. Second Layer Model

The Figure 6 presents an example of the main parts established in the drafted model through Petri Nets (input, algorithm step, and output) to represent the process’ first (1st) step, i.e., valve V31 opening, which will be carried out by the control system, in accordance with the algorithm contained in the synthetic flowchart shown in Figure 3.
In this figure, position p1 is defined to represent the input (I_01) deactivated state of the Controller; position p2 is defined to represent the input (I_01) activated state of the Controller; position p3 is defined to represent the state in which the Controller program is stopped at the beginning of the process’ first (1st) step execution; position p4 is defined to represent the state in which the Controller program is able to perform the process’ first (1st) step; position p5 is defined to represent the output (O_01) disabled state of the Controller; and position p6 is defined to represent the output (O_01) activated state of the Controller. Transition t1 is defined to carry out the change from the disabled state to the enabled state of the input (I_01) of the Controller; transition t2 is defined to carry out the change from the enabled state to the disabled state of the input (I_01) of the Controller; transition t3 is defined to carry out the change from the stopped state to be abled state, to perform the process’ first (1st) step; transition t4 is defined to carry out the change from the disabled state to the enabled state of the output (O_01) of the Controller; and transition t5 is defined to carry out the change from the enabled state to the disabled state of the output (O_01) of the Controller.

6.3.3. Third Layer Model

The Figure 7 shows an example of the model created through Petri Nets to represent the operational states considered for the virtual element of command contained in the Human–Machine Interface (HMI) layer. This virtual element is used to remotely command the automatic execution start of the algorithm programmed in the second layer Controller, in accordance with the synthetic flowchart shown in Figure 3.
In this figure, position p1 is defined to represent the disabled state of the virtual element of command in the HMI; position p2 is defined to represent the state related to the action of the user in commanding, in the HMI, the beginning of the automatic sequence of the steps of the algorithm applied to the specimen test; and position p3 is defined to represent the enabled state of the virtual element of command in the HMI. Transition t1 is defined to perform the change from disabled to enabled state of the virtual command element on the HMI, and transition t2 is defined to carry out the change from enabled to disabled state of the virtual command element on the HMI.

6.3.4. Complete Model through Petri Nets

The complete model designed though low-level Petri Nets to represent the main operational states that can be established in the system that performs the ducts’ purge, which serve the propellant supply lines for rocket motors in the Test Bench, in accordance with the previously defined physical architecture and algorithm, is shown in Figure 8.
In this context, it should be highlighted that this technique for system modeling is based on area-specific academic publications, which portray, in greater detail, the application real condition, the nature of systems, and the related operational dynamics [26,27].
To elaborate the model through Petri Nets and accomplish the respective analyses presented in this work, the resources of the integrated development environment called CPN Tools were used, which is a software used to model, simulate, and analyze colored Petri Nets, developed by the University of Aarhus, Denmark [28,29,30].
The distribution of positions, the transitions, the connection of arcs, and the number of tokens, shown in the Figure 8 model, comprise the proposed model presented in this work to evaluate the purge system, in which the characteristics listed below are considered.
In the Human–Machine Interface (HMI) layer, the following operating states are foreseen:
  • Initial conditions: indicates that the previous stages for performing the test were met, such as installing the specimen on the gantry, the loading of tanks, the built-in self-test, etc.
  • Turn On: command to start the purge process in the automatic mode.
  • Turn Off: command to finish the purge algorithm sequence.
  • OFF: position that shows the user that the purge system is disabled.
  • ON: position that shows the user that the purge system is in operation.
In the Control layer, shown in the following resources are foreseen to control the architecture shown in Figure 2:
  • I_01 … I_13: Signal inputs related to feedback commands.
  • P_01 … P_15 and T_01 … T_15: the pairs related to the steps established in the algorithm in Figure 3.
  • O_01 … O_R12: signal outputs for activating the actuators of the Actuator/Sensor layer, contained in Figure 2.
In the Sensor/Actuator layer, the following operating states are foreseen:
  • ON: position to show that the valves are open and the pressure regulators are acting according to the previously parameterized value.
  • OFF: position to show that the valves are closed and the pressure regulators are not operating.

6.4. Simulation

The token distribution, shown in the Figure 8 model, portrays a certain state of Petri Nets that is considered in this work as an initial condition to perform the simulation of the steps contained in the purge algorithm.
From this state, the “Initial Conditions” of the test are met, and the “Turn on” command is enabled by the user on the Human–Machine Interface (HMI); this net evolves to a new state, which is shown in Figure 9. In this new state, the “ON” position of the HMI layer is enabled to show the user that the purge algorithm is being simulated in the integrated development environment, with the activation of input I_01 in the Control layer, an action referring to the algorithm’s first step (1st), shown in Figure 3.
To meet the algorithm’s second step (2nd), the net evolves to the state shown in Figure 10. In this state, outputs O_01 and O_02 in the Control layer are enabled, which activate valves V31 and V32, changing from the closed (OFF) to the open (ON) condition, and their respective sensors SV31 and SV32, changing from disabled (OFF) to enabled (ON), with the simultaneous sending of feedback signals to the I_02 and I_03 inputs, which belong to the Control layer. These valves opening releases the inert gas flow, which is under positive pressure in the respective tanks, filling the purge-system pipes of the propellant lines up to the inlets of valves V33, V34, V35, V36, V37, and V38.
The algorithm’s second step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 11.
To meet the algorithm’s third step (3rd), the net evolves to the state shown in Figure 12. In this state, the outputs O_03, O_04, O_05, and O_06 are activated in the Control layer, which trigger the pressure regulators R01, R02, R03, and R04, according to the parameterized values in the “Initial Conditions”, which change from the closed condition (OFF) to the open condition (ON), and their respective sensors SR01, SR02, SR03, and SR04, which change from disabled (OFF) to enabled (ON), with the simultaneous sending of feedback signals to inputs I_04, I_05, I_06, and I_07, which belong to the Control layer. The activation of the regulators R_01 and R_04 sets low inert gas pressure to the propellant lines, which supply the rocket-engine initialization subsystem, while the regulators R_02 and R_03 set high inert gas pressure to the main propellant lines, which supply the rocket engine during its operation.
The algorithm’s third step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 13.
To meet the algorithm’s fourth step (4th), the net evolves to the state shown in Figure 14. In this state, outputs O_07, O_08, O_09, and O_10 are activated in the Control layer, which trigger the valves V33, V36, V37, and V38, changing from the closed condition (OFF) to the open condition (ON), and their respective sensors SV33, SV36, SV37, and SV38, changing from disabled (OFF) to enabled (ON), with the simultaneous sending of feedback signals to the inputs I_08, I_09, I_10, and I_11, which belong to the Control layer.
These valves opening promotes the purge of the initialization-subsystem propellant lines and the main lines, which serve the rocket motor, aiming to effectively clean these lines, thus eliminating the presence of foreign bodies and volatile mixtures.
The algorithm’s fourth step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 15.
To meet the algorithm’s fifth step (5th), the net evolves to the state shown in Figure 16. This state corresponds to maintaining the state represented in the fourth step (4th) for a period of time parameterized in the “Initial Conditions”.
The algorithm’s fifth step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 17.
To meet the algorithm’s sixth step (6th), the net evolves to the state shown in Figure 18. In this state, outputs O_07, O_08, O_09, and O_10 are activated in the Control layer, which deactivate valves V33, V36, V37, and V38, changing from the open (ON) to the closed (OFF) condition, and their respective sensors SV33, SV36, SV37, and SV38, changing from enabled (ON) to disabled (OFF), with the simultaneous sending of feedback signals to the inputs I_08, I_09, I_10, and I_11, which belong to the Control layer.
These valves closing defines the purge-stage end of the initialization-subsystem propellant lines and the main lines which serve the rocket engine.
The algorithm’s sixth step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 19.
To meet the algorithm’s seventh step (7th), the net evolves to the state shown in Figure 20. This state corresponds to the propellant-supply-lines loading procedure, which is not addressed in this work.
The algorithm’s seventh step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 21.
To meet the algorithm’s eighth step (8th), the net evolves to the state shown in Figure 22. In this state, outputs O_07, O_08, O_09, and O_10 are activated again in the Control layer, which trigger the valves V33, V36, V37, and V38, changing from the closed (OFF) to the open (ON) condition, and their respective sensors SV33, SV36, SV37, and SV38, changing from disabled (OFF) to enabled (ON), with the simultaneous sending of feedback signals to inputs I_08, I_09, I_10, and I_11, which belong to the Control layer.
These valves opening promotes the last purge of the initialization-subsystem propellant lines and the main lines that serve the rocket motor before the hot test in the Test Bench.
The algorithm’s eighth step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 23.
To meet the algorithm’s ninth step (9th), the net evolves to the state shown in Figure 24. This state corresponds to maintaining the state represented in the eighth step (8th) for a period of time parameterized in the “Initial Conditions”.
The algorithm’s ninth step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 25.
To meet the algorithm’s tenth step (10th), the net evolves to the state shown in Figure 26. In this state, the outputs O_07, O_08, O_09, and O_10 are activated again in the Control layer, which deactivate valves V33, V36, V37, and V38, changing from the open (ON) to the closed (OFF) condition, and their respective sensors SV33, SV36, SV37, and SV38, changing from enabled (ON) to disabled (OFF), with the simultaneous sending of feedback signals to inputs I_08, I_09, I_10, and I_11, which belong to the Control layer.
These valves closing defines the purge-stage end of the initialization-subsystem propellant lines and the main lines which serve the rocket engine before the hot test in the Test Bench.
The algorithm’s 10th step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 27.
To meet the algorithm’s eleventh step (11th), the net evolves to the state shown in Figure 28. This state corresponds to the procedure for the rocket-engine complete operational test in the Test Bench.
The algorithm’s 11th step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 29.
To meet the algorithm’s twelfth step (12th), the net evolves to the state shown in Figure 30. In this state, outputs O_11 and O_12 are activated in the Control layer, which trigger the valves V34 and V35, changing from the closed (OFF) to the open (ON) condition, and their respective sensors SV34 and SV35, changing from disabled (OFF) to enabled (ON), with the simultaneous sending of feedback signals to inputs I_12 and I_13, which belong to the Control layer.
These valves opening promotes the high-pressure purge of the propellant main lines which serve the rocket engine, aiming to remove residual fuel and oxidants in these lines resulting from the performed test.
The algorithm’s 12th step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 31.
To meet the algorithm’s thirteenth step (13th), the net evolves to the state shown in Figure 32. This state corresponds to maintaining the state represented in the twelfth step (12th) for a period of time parameterized in the “Initial Conditions”.
The algorithm’s 13th step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 33.
To meet the algorithm’s fourteenth step (14th), the net evolves to the state shown in Figure 34. In this state, outputs O_11 and O_12 are activated in the Control layer, which deactivate valves V34 and V35, changing from the open (ON) to the closed (OFF) condition, and their respective sensors SV34 and SV35, changing from enabled (ON) to disabled (OFF), with the simultaneous sending of feedback signals to inputs I_12 and I_13, which belong to the Control layer.
These valves closing defines the purge-stage end of the propellant main lines which serve the rocket engine after the test has been carried out.
The algorithm’s 14th step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 35.
To meet the algorithm’s fifteenth step (15th), the net evolves to the three subsequent states, and in the state shown in Figure 36, outputs O_01 and O_02 are activated in the Control layer, which deactivate valves V31 and V32, changing from the open (ON) to the closed (OFF) condition, and their respective sensors SV31 and SV32, changing from enabled (ON) to disabled (OFF), with the simultaneous sending of feedback signals to inputs I_02 and I_03, which belong to the Control layer.
These valves closing blocks the inert gas flow that has positive pressure in the respective tanks, which is used to serve the propellant-lines purge system up to valves V33, V34, V35, V36, V37, and V38.
The algorithm’s 15th step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 37.
In the state shown in Figure 38, the outputs O_03, O_04, O_05, and O_06 are activated in the Control layer, which deactivate the pressure regulators R01, R02, R03, and R04, which change from the open (ON) to the closed (OFF) condition, and their respective sensors SV01, SV02, SV03, and SV04, which change from enabled (ON) to disabled (OFF), with the simultaneous sending of feedback signals to inputs I_04, I_05, I_06, and I_07, which belong to the Control layer.
After the deactivation of these regulators, the pressure balance occurs in the propellant lines that supply the initialization subsystem and the main lines that serve the rocket engine.
The algorithm’s 15th step, portrayed within the component diagram scope of the first automation layer, is shown in Figure 39.
From the state shown in Figure 38, after the “Turn off” command is activated by the user in the Human–Machine Interface (HMI), the network evolves to the new state shown in Figure 40, in which the HMI layer “OFF” position is enabled to show the user that the purge algorithm simulation has been finished in the integrated development environment, activating the P_01 position in the Control layer, which allows for the start of a new simulation, based on the actions regarding the algorithm’s first step (1st).

7. Results

The computational simulation fulfilled with the model proposed in this work to represent the purge process of liquid-propellant line ducts that serve the rocket engine in the Test Bench was fully repeated several times, allowing for the evaluation of the Petri Nets properties mainly related to Liveliness, Conservativeness, Deadlock-type, and Confusion-types, as shown in Table 3.

8. Conclusions

The positive results observed in the tests performed with the computer simulation suggest that the resources and components established in the model proposed in this work, developed through Petri Nets, are compatible with the ducts’ purge system architecture that serves the propellant supply lines for the rocket engine in the Test Bench.
The method used to elaborate the model developed through Petri Nets allows us to: (i) properly portray the purge system’s physical architecture, (ii) perform the steps contained in the previously defined algorithm, (iii) evaluate Petri Nets’ different properties, (iv) represent the system’s operational states, (v) perform individual analyses of each element, (vi) identify possible nonconformities in the structure and net execution, and (vii) mitigate undesirable events during the test routines run.
The method adopted to model the system, in which the layers of the Human–Machine Interface, Control, and Sensor/Actuator, which compose the low-level Petri Nets, are represented in a different way, allows for the clarification of the valves and the regulators operation, which are elements foreseen in the mentioned system architecture.
Among the properties evaluated in the modeled net, only the confusion-type conflict was identified in the system simulation; the solution for this issue was obtained by the strategic insertion of positions such that the algorithm was properly run.
As an essential action for preventing, minimizing, or eliminating disorders that may occur if the system reaches an undesired state, it is necessary, at least, to ensure the existence of feedback signals for the control system and, also, to initially perform a built-in self-test of the components contained in the Sensor/Actuator layer.
The main limit observed in this work’s elaboration is that, considering that the elements contained in all the automation layers are intact and adequate for the correct functioning, this condition must be preliminarily evaluated through a dedicated Built-In Self-Test system (BIST), which is not addressed in this article.

Author Contributions

Conceptualization, E.R.B., F.C.P.B. and J.W.P.B.; methodology, E.R.B., F.C.P.B. and J.W.P.B.; software, E.R.B., F.C.P.B. and J.W.P.B.; validation, E.R.B., F.C.P.B. and J.W.P.B.; formal analysis, E.R.B., F.C.P.B. and J.W.P.B.; investigation, E.R.B., F.C.P.B. and J.W.P.B.; resources, E.R.B., F.C.P.B. and J.W.P.B.; data curation, E.R.B., F.C.P.B. and J.W.P.B.; writing—original draft preparation, E.R.B., F.C.P.B. and J.W.P.B.; writing—review and editing, E.R.B., F.C.P.B. and J.W.P.B.; visualization, E.R.B., F.C.P.B. and J.W.P.B.; supervision, E.R.B., F.C.P.B. and J.W.P.B.; project administration, E.R.B., F.C.P.B. and J.W.P.B.; funding acquisition, E.R.B., F.C.P.B. and J.W.P.B. All authors have read and agreed to the published version of the manuscript.

Funding

This research was funded by Coordination for the Improvement of Higher Education Personnel—Brazil (CAPES) grant number Financing Code 001.

Data Availability Statement

The data presented in this study are available on request from the corresponding author.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Almeida, D.S. Projeto motor foguete a propelente líquido L75. In Proceedings of the 7th Seminário de Projeto de Pesquisa e Desenvolvimento em Veículos Espaciais e Tecnologia Associadas, São José dos Campos, SP, Brazil, 11–13 September 2013; p. 50. [Google Scholar]
  2. Nosseir, A.E.S.; Cervone, A.; Pasini, A. Review of State-of-the-Art Green Monopropellants: For Propulsion Systems Analysts and Designers. Aerospace 2021, 8, 20. [Google Scholar] [CrossRef]
  3. Rahman, S. Liquid Rocket Engines. In Proceedings of the 41st Joint Propulsion Conference, Tuscon, AZ, USA, 10–13 July 2005; p. 57. [Google Scholar]
  4. Deng, L.; Cheng, Y.; Shi, Y. Fault Detection and Diagnosis for Liquid Rocket Engines Based on Long Short-Term Memory and Generative Adversarial Networks. Aerospace 2022, 9, 399. [Google Scholar] [CrossRef]
  5. Beck, P. Payload User’s Guide; Rocket Lab: Long Beach, CA, USA, 2018; p. 53. [Google Scholar]
  6. Palacz, T.; Ciéslik, J. Experimental Study on the Mass Flow Rate of the Self-Pressurizing Propellants in the Rocket Injector. Aerospace 2021, 8, 317. [Google Scholar] [CrossRef]
  7. Iannetti, A.; Marzat, J.; Piet-Lahnier, H.; Ordonneau, G.; Vingert, L. Fault diagnosis benchmark for a rocket engine demonstrator. Elsevier 2015, 48, 895–900. [Google Scholar] [CrossRef]
  8. Huang, P.; Wang, T.; Ding, L.; Yu, H.; Tang, Y.; Zhou, D. Comparative Analysis of Real-Time Fault Detection Methods Based on Certain Artificial Intelligent Algorithms for a Hydrogen–Oxygen Rocket Engine. Aerospace 2022, 9, 582. [Google Scholar] [CrossRef]
  9. Schwabacher, M. Machine Learning for Rocket Propulsion Health Monitoring. SAE Trans. 2005, 114, 1192–1197. [Google Scholar]
  10. Turner, M.J.L. Rocket and Spacecraft Propulsion: Principles, Practice and New Developments, 3rd ed.; Springer: Chichester, UK, 2009. [Google Scholar]
  11. Cai, X.; Schild, T.; Kümpel, A.; Müller, D. MODI: A Structured Development Process of Mode-Based Control Algorithms in the Early Design Stage of Building Energy Systems. Buildings 2023, 13, 267. [Google Scholar] [CrossRef]
  12. Cardoso, J.; Valette, R. Redes de Petri, 1st ed.; UFSC: São Carlos, Brazil, 1997; p. 157. [Google Scholar]
  13. Li, A.; Li, B.; Gao, M.; Yung, K.L.; Andrew, W.H. Chapter 7— Colored Petri net modeling of the manufacturing processes of space instruments. Aerospace Engineering. In IoT and Spacecraft Informatics; Elsevier: Amsterdam, The Netherlands, 2022; pp. 219–253. [Google Scholar]
  14. Favaro, L.F.; Junior, P.A.A.M. Análise Pelo Método de Elementos Finitos da Estrutura do Banco de Testes de Motor de Foguete. In Proceedings of the 35th Iberian Latin-American Congress on Computational Methods in Engineering, Fortaleza, Brazil, 23–26 November 2014; p. 15. [Google Scholar]
  15. Santivañez, J.; Blas, O.; Saenz, C.; Espinoza, L.; Solis, W.; Cornejo, J.; Estela, J. Design of low-cost solid propellant engine test bench and electronic embedded system used for small rockets. In Proceedings of the 2021 International Conference on Electrical, Computer, Communications and Mechatronics Engineering (ICECCME), Mauritius, Mauritius, 7–8 October 2021; p. 6. [Google Scholar]
  16. Darpa-Defense Advanced Research Projects Agency. Experimental Spaceplane Program Successfully Completes Engine Test Series. Available online: https://www.darpa.mil/news-events/2018-07-10 (accessed on 10 December 2022).
  17. Pauw, J.D.; Veggi, L.; Wagner, B.; Mondal, J.; Klotz, M. Design Procedure of a Turbopump Test Bench. In Proceedings of the 17th International Symposium on Transport Phenomena and Dynamics of Rotating Machinery (ISROMAC2017), Maui, HI, USA, 16–21 December 2017; p. 12. [Google Scholar]
  18. Sarotti, C.; Marzat, J.; Piet-Lahanier, H.; Galeotta, M. Cryogenic liquid rocket engine teste beach fault-tolerant control system: Cooling system application. Elsevier 2019, 52, 280–285. [Google Scholar]
  19. Schäfer, K.; Zimmermann, H. Development and Operational Conditions of VINCI Altitude Simulation Test Bench P4.1. In Proceedings of the 42nd AIAA/ASME/SAE/ASEE Joint Propulsion Conference & Exhibit, Sacramento, CA, USA, 9–12 July 2006. [Google Scholar]
  20. Murata, T. Petri nets: Properties, analysis and applications. IEEE 1989, 77, 541–580. [Google Scholar] [CrossRef]
  21. Zhang, Q.; Fan, W.; Wang, K.; Lu, W.; Chi, Y.; Wang, Y. Impact of nozzles on a valveless pulse detonation rocket engine without the purge process. Appl. Therm. Eng. 2016, 100, 1161–1168. [Google Scholar] [CrossRef]
  22. Deyna, A. (Instituto Nacional de Pesquisas Espaciais). Concepção e Projeto de uma Bancada de Testes Para Injetores de Fluídos Criogênicos em Condições Críticas. 2013. Available online: http://mtc-m21c.sid.inpe.br/col/sid.inpe.br/mtc-m21c/2020/07.14.18.47/doc/Arthur%20Deyna.pdf (accessed on 10 December 2022).
  23. Barreto, F.M. Uma abordagem baseada em Redes de Petri para modelagem, análise e simulação de cenários de vídeo games singlepauer e multiplayer. Doctoral Thesis, Universidade Federal de Uberlância, Uberlândia, Brazil, 2020. [Google Scholar]
  24. Pádua, S.I.D.; Silva, A.R.Y.; Porto, A.J.V. O potencial das Redes de Petri em modelagem e análise de processos de negócio. Rev. De Gestão Produção 2004, 11, 109–119. [Google Scholar] [CrossRef] [Green Version]
  25. Moraes, C.C.; Castrucci, P.L. Engenharia de Automação Industrial, 2nd ed.; LTC: Rio de Janeiro, Brazil, 2018; p. 347. [Google Scholar]
  26. Bizarria, F.C.P.; Bizarria, J.W.P.; Villani, E.; Rangel, A.P. Redes de Petri aplicadas na análise de sistema de adição de agente oxidante no processo de fabricação de propelente sólido. In Proceedings of the 5th Congresso Nacional de Engenharia Mecânica, Salvador, BH, Brazil, 25–28 August 2008; p. 8. [Google Scholar]
  27. Bizarria, F.C.P.; Bizarria, J.W.P.; Rosario, J.M. Petri Nets applied to the analysis of algorithm for space vehicles integration tower self-test. Glob. J. Reserches Eng. 2011, 11, 7. [Google Scholar]
  28. Borges, R.; Santos, E.A.P.; Loures, E.D.F.R.; Romano, C.A. Use of technology in industrial maintenance management: Simulation framework to aid decision making. Rev. Gestão Tecnol. 2022, 22, 225–252. [Google Scholar]
  29. Bozek, A.; Rak, T.; Rzonca, D. Timed Colored Petri Net-Based Event Generators for Web Systems Simulation. Appl. Sci. 2022, 12, 2385. [Google Scholar] [CrossRef]
  30. Dechsupa, C.; Vatanawood, W.; Poolsawasdi, W.; Thongtak, A. An Applying Colored Petri Net for Computerized Accounting System and Ledger Accounts Instruction. Computers 2021, 10, 169. [Google Scholar]
Figure 1. Rocket engine test bench.
Figure 1. Rocket engine test bench.
Aerospace 10 00212 g001
Figure 2. Purge-system component diagram.
Figure 2. Purge-system component diagram.
Aerospace 10 00212 g002
Figure 3. Purge algorithm flowchart.
Figure 3. Purge algorithm flowchart.
Aerospace 10 00212 g003
Figure 4. Established automation layers.
Figure 4. Established automation layers.
Aerospace 10 00212 g004
Figure 5. Model of the actuator and valve sensor V31 for the closed state.
Figure 5. Model of the actuator and valve sensor V31 for the closed state.
Aerospace 10 00212 g005
Figure 6. Model for the second process.
Figure 6. Model for the second process.
Aerospace 10 00212 g006
Figure 7. Model for the virtual element of command in the HMI.
Figure 7. Model for the virtual element of command in the HMI.
Aerospace 10 00212 g007
Figure 8. Complete Petri Nets for the purge system.
Figure 8. Complete Petri Nets for the purge system.
Aerospace 10 00212 g008
Figure 9. Algorithm’s first step—Start simulation.
Figure 9. Algorithm’s first step—Start simulation.
Aerospace 10 00212 g009
Figure 10. Algorithm’s second step—Open valves.
Figure 10. Algorithm’s second step—Open valves.
Aerospace 10 00212 g010
Figure 11. Algorithm’s second step diagram.
Figure 11. Algorithm’s second step diagram.
Aerospace 10 00212 g011
Figure 12. Algorithm’s third step—Activate regulators.
Figure 12. Algorithm’s third step—Activate regulators.
Aerospace 10 00212 g012
Figure 13. Algorithm’s third step diagram.
Figure 13. Algorithm’s third step diagram.
Aerospace 10 00212 g013
Figure 14. Algorithm’s fourth step—Open valves.
Figure 14. Algorithm’s fourth step—Open valves.
Aerospace 10 00212 g014
Figure 15. Algorithm’s fourth step diagram.
Figure 15. Algorithm’s fourth step diagram.
Aerospace 10 00212 g015
Figure 16. Algorithm’s fifth step—Timer.
Figure 16. Algorithm’s fifth step—Timer.
Aerospace 10 00212 g016
Figure 17. Algorithm’s fifth step diagram.
Figure 17. Algorithm’s fifth step diagram.
Aerospace 10 00212 g017
Figure 18. Algorithm’s sixth step—Close valves.
Figure 18. Algorithm’s sixth step—Close valves.
Aerospace 10 00212 g018
Figure 19. Algorithm’s sixth step diagram.
Figure 19. Algorithm’s sixth step diagram.
Aerospace 10 00212 g019
Figure 20. Algorithm’s seventh step—Load propellant lines.
Figure 20. Algorithm’s seventh step—Load propellant lines.
Aerospace 10 00212 g020
Figure 21. Algorithm’s seventh step diagram.
Figure 21. Algorithm’s seventh step diagram.
Aerospace 10 00212 g021
Figure 22. Algorithm’s eighth step—Open valves.
Figure 22. Algorithm’s eighth step—Open valves.
Aerospace 10 00212 g022
Figure 23. Algorithm’s eighth step diagram.
Figure 23. Algorithm’s eighth step diagram.
Aerospace 10 00212 g023
Figure 24. Algorithm’s ninth step—Timer.
Figure 24. Algorithm’s ninth step—Timer.
Aerospace 10 00212 g024
Figure 25. Algorithm’s ninth step diagram.
Figure 25. Algorithm’s ninth step diagram.
Aerospace 10 00212 g025
Figure 26. Algorithm’s 10th step—Close valves.
Figure 26. Algorithm’s 10th step—Close valves.
Aerospace 10 00212 g026
Figure 27. Algorithm’s 10th step diagram.
Figure 27. Algorithm’s 10th step diagram.
Aerospace 10 00212 g027
Figure 28. Algorithm’s 11th step—Rocket engine test.
Figure 28. Algorithm’s 11th step—Rocket engine test.
Aerospace 10 00212 g028
Figure 29. Algorithm’s 11th step diagram.
Figure 29. Algorithm’s 11th step diagram.
Aerospace 10 00212 g029
Figure 30. Algorithm’s 12th step—Open valves.
Figure 30. Algorithm’s 12th step—Open valves.
Aerospace 10 00212 g030
Figure 31. Algorithm’s 12th step diagram.
Figure 31. Algorithm’s 12th step diagram.
Aerospace 10 00212 g031
Figure 32. Algorithm’s 13th step—Timer.
Figure 32. Algorithm’s 13th step—Timer.
Aerospace 10 00212 g032
Figure 33. Algorithm’s 13th step diagram.
Figure 33. Algorithm’s 13th step diagram.
Aerospace 10 00212 g033
Figure 34. Algorithm’s 14th step—Close valves.
Figure 34. Algorithm’s 14th step—Close valves.
Aerospace 10 00212 g034
Figure 35. Algorithm’s 14th step diagram.
Figure 35. Algorithm’s 14th step diagram.
Aerospace 10 00212 g035
Figure 36. Algorithm’s 15th step—Close valves.
Figure 36. Algorithm’s 15th step—Close valves.
Aerospace 10 00212 g036
Figure 37. Algorithm’s 15th step diagram.
Figure 37. Algorithm’s 15th step diagram.
Aerospace 10 00212 g037
Figure 38. Algorithm’s 15th step—Deactivate regulators.
Figure 38. Algorithm’s 15th step—Deactivate regulators.
Aerospace 10 00212 g038
Figure 39. Algorithm’s 15th step diagram.
Figure 39. Algorithm’s 15th step diagram.
Aerospace 10 00212 g039
Figure 40. Algorithm’s 15th step—End simulation.
Figure 40. Algorithm’s 15th step—End simulation.
Aerospace 10 00212 g040
Table 1. Architecture elements.
Table 1. Architecture elements.
NameDescription
V01Valve applied in controlling the fuel flow supplied to the rocket engine.
V03Valve applied in controlling the oxidant flow supplied to the rocket engine.
V07Valve applied in controlling the fuel flow supplied to the engine ignitor.
V09Valve applied in controlling the oxidant flow supplied to the ignitor.
V31Valve applied in controlling the inert gas flow of the fuel-lines purge system.
V32Valve applied in controlling the inert gas flow in the oxidant-lines purge system.
V33Valve applied in controlling the inert gas flow during the purge process in low pressure of the rocket-engine fuel line.
V34Valve applied in controlling the inert gas flow during the purge process in high pressure of the rocket-engine fuel line.
V35Valve applied in controlling the inert gas flow during the purge process in high pressure of the rocket-engine oxidant line.
V36Valve applied in controlling the inert gas flow during the purge process in low pressure of the rocket-engine oxidant line.
V37Valve applied in controlling the inert gas flow during the purge process in low pressure of the engine igniter fuel line.
V38Valve applied in controlling the inert gas flow during the purge process in low pressure of the engine igniter oxidant line.
R01Regulator applied in the adjustment of the inert-gas low pressure that serves the fuel purge lines of the rocket engine and engine igniter.
R02Regulator applied in the adjustment of the inert-gas high pressure that serves the rocket-engine fuel purge line.
R03Regulator applied in the adjustment of the inert-gas high pressure that serves the rocket-engine oxidant purge line.
R04Regulator applied in the adjustment of the inert-gas low pressure that serves the oxidant purge lines of the rocket engine and engine igniter.
PT03Inert gas pressure transducer that serves the rocket-engine fuel purge line.
PT04Inert gas pressure transducer that serves the rocket-engine oxidant purge line.
D01Valve applied in the fuel drain of the line that serves the rocket engine.
D02Valve applied in the oxidant drain of the line that serves the rocket engine.
Table 2. Description algorithm blocks.
Table 2. Description algorithm blocks.
StepNameDescription
1stInitial conditions and startProcess regarding the initial stages, such as the test program selection, tanks supply, specimen assembling, valve testing, and visual inspection, among others, and activating the start command on the HMI—Human–Machine Interface.
2ndOpen V31 and V32Process regarding the simultaneous opening of the valves located at the outlet of the tanks, making it possible to load the ducts of the purge system lines with inert gas.
3rdSet R01, R02, R03, and R04Process regarding the inert gas pressure adjustment in the ducts of the purge system lines.
4thOpen V33, V36, V37, and V38Process regarding the simultaneous opening of the valves that release the inert gas flow in the last section of the rocket engine propellant and engine ignitor lines, initiating the low-pressure purge.
5thTimerProcess regarding the programmed control of time for the event contained in the fourth step of the algorithm.
6thClose V33, V36, V37, and V38Process regarding the simultaneous closing of the valves that block the flow of inert gas in the last section of the rocket engine propellant and engine ignitor lines, finalizing the low-pressure purge.
7thPropellant-lines loadingProcess regarding the liquid propellant loading in the ducts that connect the tanks to the rocket engine and the engine ignitor.
8thOpen V33, V36, V37, and V38Process regarding the simultaneous opening of the valves that release inert gas flow in the last section of the rocket engine propellant and engine ignitor lines, initiating the low-pressure purge.
9thTimerProcess regarding the programmed control of time for the event contained in the eighth step of the algorithm.
10thClose V33, V36, V37, and V38Process regarding the simultaneous closing of the valves that block the flow of inert gas in the last section of the rocket engine propellant and engine ignitor lines, finalizing the low-pressure purge.
11thRocket engine testProcess related to the specimen hot test.
12thOpen V34 and V35Process regarding the simultaneous opening of the valves that release the inert gas flow in the last section of the rocket engine propellant lines, initiating the high-pressure purge.
13thTimerProcess regarding the programmed control of time for the event contained in the 12th step of the algorithm.
14thClose V34 and V35Process regarding the simultaneous closing of the valves that block the inert gas flow in the last section of the rocket engine propellant lines, finalizing the high-pressure purge.
15thShutdown processProcess regarding the shutdown sequence established for elements of the systems and the termination of the rocket-engine test activities in the Test Bench.
Table 3. Property valuation.
Table 3. Property valuation.
PropertyDescriptionResults
LivelinessShows that all net transactions may be triggered from a trigger sequence.All transitions were enabled and triggered during the simulation performed with the model developed through Petri Nets proposed in this work.
ConservativenessShows the existence of a weighting vector of marks, in which everywhere has an integer and positive number.During the simulation’s entire performance, the number of tokens remained constant in the Petri Net model proposed for this work.
Confusion-type conflictShows that multiple transitions connected and enabled on the same input compete for the token contained therein.In the simulation performed, it was observed that the confusion-type conflict in the model developed through the Petri Nets proposed in this work.These situations were solved with strategic insertions of positions, allowing the correct algorithm to run.
Deadlock-type conflictShows the stop of all net transitions in a given state.In the simulations performed, the deadlock-type conflict was not observed in the model developed through the Petri Nets proposed in this work.
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Bortoloto, E.R.; Bizarria, F.C.P.; Bizarria, J.W.P. Petri Nets Applied in Purge Algorithm Analysis for a Rocket Engine Test with Liquid Propellant. Aerospace 2023, 10, 212. https://doi.org/10.3390/aerospace10030212

AMA Style

Bortoloto ER, Bizarria FCP, Bizarria JWP. Petri Nets Applied in Purge Algorithm Analysis for a Rocket Engine Test with Liquid Propellant. Aerospace. 2023; 10(3):212. https://doi.org/10.3390/aerospace10030212

Chicago/Turabian Style

Bortoloto, Evandro Rostirolla, Francisco Carlos Parquet Bizarria, and José Walter Parquet Bizarria. 2023. "Petri Nets Applied in Purge Algorithm Analysis for a Rocket Engine Test with Liquid Propellant" Aerospace 10, no. 3: 212. https://doi.org/10.3390/aerospace10030212

APA Style

Bortoloto, E. R., Bizarria, F. C. P., & Bizarria, J. W. P. (2023). Petri Nets Applied in Purge Algorithm Analysis for a Rocket Engine Test with Liquid Propellant. Aerospace, 10(3), 212. https://doi.org/10.3390/aerospace10030212

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop