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

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].

$$RP =\left(P, T, A, W, M_0\right)$$

(1)

The nomenclatures contained in Equation (1) have the following meanings:

RP = Petri Nets.

P = {p₁, p₂, …p_m}: finite set of places.

T = {t₁, t₂, …t_n}: finite set of transitions.

A ⸦ (P × T) ∪ (T × P): finite set of arcs.

W: F → N+: function that assigns the weight of each arc.

M₀: P → N: 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. Architecture elements.

Name	Description
V01	Valve applied in controlling the fuel flow supplied to the rocket engine.
V03	Valve applied in controlling the oxidant flow supplied to the rocket engine.
V07	Valve applied in controlling the fuel flow supplied to the engine ignitor.
V09	Valve applied in controlling the oxidant flow supplied to the ignitor.
V31	Valve applied in controlling the inert gas flow of the fuel-lines purge system.
V32	Valve applied in controlling the inert gas flow in the oxidant-lines purge system.
V33	Valve applied in controlling the inert gas flow during the purge process in low pressure of the rocket-engine fuel line.
V34	Valve applied in controlling the inert gas flow during the purge process in high pressure of the rocket-engine fuel line.
V35	Valve applied in controlling the inert gas flow during the purge process in high pressure of the rocket-engine oxidant line.
V36	Valve applied in controlling the inert gas flow during the purge process in low pressure of the rocket-engine oxidant line.
V37	Valve applied in controlling the inert gas flow during the purge process in low pressure of the engine igniter fuel line.
V38	Valve applied in controlling the inert gas flow during the purge process in low pressure of the engine igniter oxidant line.
R01	Regulator applied in the adjustment of the inert-gas low pressure that serves the fuel purge lines of the rocket engine and engine igniter.
R02	Regulator applied in the adjustment of the inert-gas high pressure that serves the rocket-engine fuel purge line.
R03	Regulator applied in the adjustment of the inert-gas high pressure that serves the rocket-engine oxidant purge line.
R04	Regulator applied in the adjustment of the inert-gas low pressure that serves the oxidant purge lines of the rocket engine and engine igniter.
PT03	Inert gas pressure transducer that serves the rocket-engine fuel purge line.
PT04	Inert gas pressure transducer that serves the rocket-engine oxidant purge line.
D01	Valve applied in the fuel drain of the line that serves the rocket engine.
D02	Valve applied in the oxidant drain of the line that serves the rocket engine.

. 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. Description algorithm blocks.

Step	Name	Description
1st	Initial conditions and start	Process 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.
2nd	Open V31 and V32	Process 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.
3rd	Set R01, R02, R03, and R04	Process regarding the inert gas pressure adjustment in the ducts of the purge system lines.
4th	Open V33, V36, V37, and V38	Process 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.
5th	Timer	Process regarding the programmed control of time for the event contained in the fourth step of the algorithm.
6th	Close V33, V36, V37, and V38	Process 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.
7th	Propellant-lines loading	Process regarding the liquid propellant loading in the ducts that connect the tanks to the rocket engine and the engine ignitor.
8th	Open V33, V36, V37, and V38	Process 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.
9th	Timer	Process regarding the programmed control of time for the event contained in the eighth step of the algorithm.
10th	Close V33, V36, V37, and V38	Process 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.
11th	Rocket engine test	Process related to the specimen hot test.
12th	Open V34 and V35	Process 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.
13th	Timer	Process regarding the programmed control of time for the event contained in the 12th step of the algorithm.
14th	Close V34 and V35	Process 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.
15th	Shutdown process	Process regarding the shutdown sequence established for elements of the systems and the termination of the rocket-engine test activities in the Test Bench.

.

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 p₁ is defined to represent the closed state of valve actuator V31, position p₂ is defined to represent the open state of valve actuator V31, position p₃ is defined to represent the closed state indicated by valve sensor V31, and position p₄ is defined to represent the open state indicated by valve sensor V31. Transition t₁ is set to change valve actuator V31 from a closed state to an open state; transition t₂ is set to change valve actuator V31 from the open state to the closed state; transition t₃ is set to perform the indication change of valve sensor V31 from a closed state to an open state; transition t₄ 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 p₁ is defined to represent the input (I_01) deactivated state of the Controller; position p₂ is defined to represent the input (I_01) activated state of the Controller; position p₃ is defined to represent the state in which the Controller program is stopped at the beginning of the process’ first (1st) step execution; position p₄ is defined to represent the state in which the Controller program is able to perform the process’ first (1st) step; position p₅ is defined to represent the output (O_01) disabled state of the Controller; and position p₆ is defined to represent the output (O_01) activated state of the Controller. Transition t₁ is defined to carry out the change from the disabled state to the enabled state of the input (I_01) of the Controller; transition t₂ is defined to carry out the change from the enabled state to the disabled state of the input (I_01) of the Controller; transition t₃ is defined to carry out the change from the stopped state to be abled state, to perform the process’ first (1st) step; transition t₄ 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 t₅ 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 p₁ is defined to represent the disabled state of the virtual element of command in the HMI; position p₂ 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 p₃ is defined to represent the enabled state of the virtual element of command in the HMI. Transition t₁ is defined to perform the change from disabled to enabled state of the virtual command element on the HMI, and transition t₂ 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. Property valuation.

Property	Description	Results
Liveliness	Shows 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.
Conservativeness	Shows 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 conflict	Shows 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 conflict	Shows 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.

.

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.