Machine and process to design, validate, and / or test fluid system

Abstract

To provide a machine and process for visualizing a virtual model for a propulsion and / or fluid system and interacting with the virtual model.SOLUTION: A machine (500) for visualizing a virtual model for a propulsion and / or fluid system and interacting with the virtual model includes a display server (502). The display server (502) comprises a socket in communication with a socket in a second server (504) that comprises a piping evaluator (546). The piping evaluator (546) includes a traversal graph (548) that accelerates processing of inputs for an executable block diagram (510) for the propulsion and / or fluid system displayed on a graphical user interface (512). The traversal graph (548) accesses support files generated by a scan shapes tool (506) in communication with a diagram and vector graphic application with tailored stencils.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present disclosure relates generally to fluid systems and rocket science, and more particularly to machines and processes for designing, verifying, and / or testing fluid systems such as propulsion systems, for example, rocket and satellite propulsion systems. [Background technology]

[0002] Systems used in fluid handling, such as propulsion systems, operate using flows, commodities, compositions, and / or pressures that require controlled tolerances, precise design, component manufacturing, assembly, and interaction. At a minimum, systems used in fluid handling, such as propulsion systems, must be designed, tested, and / or validated to a high level of reliability, precision, and predictability to reduce the risk of unintended consequences resulting from the system's design or operation.

[0003] The illustrative embodiments recognize and take into account that, until now, the design and testing of fluid processing, such as propulsion systems, has been a primarily manual process. By way of non-limiting example, space propulsion systems may include manned and unmanned rockets and missiles that travel above Earth. Fluid processing systems, such as propulsion systems, have relied heavily on the experience base of operators and engineers for both their design and process execution. Thus, the illustrative embodiments recognize and take into account that there is a need for techniques that apply model-based engineering (MBE) to incorporate product requirements, functionality, and behavior into machines and processes that verify and validate designs prior to operation of hardware, such as propulsion systems in fluid processing.

[0004] It would therefore be desirable to provide a machine and / or process that takes into account at least some of the considerations set forth above, as well as other potential considerations. For example, it may be desirable to provide a machine and process for the design and / or validation of fluid handling systems, such as propulsion systems. Summary of the Invention

[0005] One embodiment of the present disclosure provides a novel machine and associated process, including, for example, at least a display server, the display server including a graphical user interface configured to generate a block diagram that may include objects that may represent components in a propulsion system; and a first socket configured to communicate with a second socket in the propulsion server associated with a scanshape tool that includes a data extraction program, the data extraction program configured to generate and store translation tables, linkage map tables, and object indexes configured to accelerate a traversal algorithm configured to control a visualizer in the display server. The propulsion server can be configured to design, verify, and validate at least one of the following: design, assembly, or integration of objects in a propulsion system. The block diagram may be, for example, a diagram of a propulsion system.

[0006] The propulsion server may include a command handler configured to update the state of objects in the propulsion system. The propulsion server may include a propulsion piping evaluator configured to recursively update the piping of the propulsion system. The propulsion server may, for example, include the traversal algorithm and be configured to generate and access the conversion table, the interlocking map table, and the object index configured to be input to the traversal algorithm. The propulsion piping evaluator in the propulsion server may include the traversal algorithm.

[0007] Additionally, the propulsion server may include an action log configured to record all activity occurring in the block diagram. The propulsion server may be configured to update at least one of an identity, a status, and a color of each component of the propulsion system, each represented in the block diagram by an object in the block diagram. The objects may include a classification selected from the group consisting of active objects, passive objects, and piping. The objects may include a set of rules and a set of behaviors. The objects may include a classification as an active object, which may include at least one of the following states: on, off, pressure, composition, and product type.

[0008] Thus, the novel machine provides at least a first process for visualizing a propulsion system, which may include: generating a block diagram in a graphical user interface within a propulsion visualization machine that receives input for displaying devices in the propulsion system as objects in a block diagram by a visualizer on the graphical user interface; a display server including the graphical user interface passing the input to a propulsion piping evaluator, for example, within a propulsion server; the propulsion piping evaluator applying an algorithm in response to the input to evaluate flow or pressure within objects or piping in the propulsion system; and generating a traversal graph of all devices and piping within the propulsion system. The first process for visualizing a propulsion system may further include the propulsion server updating the state of each object in the block diagram by executing a traversal algorithm and sending updates to a visualizer in the display server; the display server updating a display of the object state on the block diagram; the propulsion piping evaluator updating object color codes and piping color codes and sending the updates to the display server; and the display server updating a display of the object color codes and the piping color codes on the block diagram.

[0009] The first process may further include the propulsion piping evaluator traversing a particular connector at a source object within the propulsion system and generating a composition or pressure to be sent through the connector to a destination object. The first process may also include verifying whether a composition or pressure is received or not at the connector to the destination object, and, in response to an absence, identifying an individual connector at which an error occurred in receiving the composition or pressure, and identifying the individual connector and specific virtual modules each connected to and including the individual connector. The device state may be selected from a group including at least one of the following: on, off, pressure, composition, and product type. Furthermore, the propulsion server may create a traversal graph tracking all objects traversed within the block diagram during runtime visualization of the propulsion system.

[0010] The first process may also include the propulsion server using traversal logic using states of active objects and behavior definitions of passive objects in the block diagram to create a traversal graph that tracks all objects traversed in the block diagram during runtime visualization of the propulsion system. The propulsion piping evaluator may further classify each object in the block diagram as one of an active object, a passive object, and a piping. An active object may include at least one of the following: an origin of a property state value in the block diagram, or an interactive object in the block diagram that triggers a state change of a subordinate object in the propulsion system shown in the block diagram.

[0011] The piping may, for example, connect two objects of the propulsion system in the block diagram and may be any device that transfers fluid or pressure from one object to a lower object in the block diagram. Additionally, the piping may transfer a value of one of the following from one object to a lower object in the block diagram: pressure, composition, or product type.

[0012] The first process for visualizing a propulsion system may also include recording all activity on the block diagram during runtime in an action log, and using the action log of all activity on the block diagram during runtime to roll back actions of the propulsion system shown in the block diagram to a desired previous point in the runtime. Additionally, the action log of all activity on the block diagram during runtime may be used to establish a new runtime start state for the block diagram.

[0013] The first process for visualizing a propulsion system may also include recording snapshots of the block diagram at selected times at runtime to record the state of all valves in the propulsion system shown in the block diagram and / or the state of all pressure regulators in the propulsion system shown in the block diagram. The first process may further include accelerating the processing of the traversal algorithm through a data extraction program within a scan shape tool that creates support files including translation tables, interlocking map tables, and object indexes, and the traversal algorithm accessing the support files.

[0014] The first process for visualizing a propulsion system may also include receiving input to the propulsion server from an external command and control system in communication with the propulsion server to change the state of the object. The first process may further include a scan shape tool extracting essential elements of data attached to the object in a system diagram of a diagram vector graphics application to create a conversion table, an interlocking map table, and an object index accessed by a propulsion piping evaluator. Finally, the first process for visualizing a propulsion system may further include, for example, creating a block diagram including a propulsion system stencil tailored to the object, the stencil including data indicating component types, connections, and / or characteristics specific to each of the objects.

[0015] At least the second process for visualizing a propulsion system includes constructing a system diagram of the propulsion system in a diagram and vector graphics application that accesses a respective stencil for each object to be placed in the system diagram, the stencil including data associated with the object, including component types, connections, and properties specific to the object; running an error checking program on a scalar vector graphics file constructed by the diagram and vector graphics application from input; and, in response to the absence of errors in the scalar vector graphics file, using a data extraction program to create the following from data associated with objects in the scalar vector graphics file: a conversion table, an interlocking map table, and an object index; converting the system diagram to a scalar vector graphics file and extracting the scalar vector graphics file into a block diagram. The process may include loading a scalar graphics application in a display server to visualize the propulsion system; receiving input for displaying devices in the propulsion system as objects in the block diagram on a graphical user interface by the visualizer; the display server passing the input to a propulsion server; in response to the input, the propulsion server applying an algorithm to evaluate piping in the propulsion system; a scan shape tool generating a list of devices and piping in the propulsion system; the propulsion server executing a traversal algorithm updating a state of the devices in the propulsion server and sending the updates to the display server; the display server updating a display of the state of the objects on the block diagram; the propulsion server updating color codes of the devices and color codes of the piping and sending the updates to the display server; and the display server updating a display of the device color codes and the piping color codes on the block diagram. The second process for visualizing a propulsion system may also include traversing to a specific connector at an origin object and generating a fluid or pressure to be sent through the connector to a destination.

[0016] Furthermore, at least the second process for visualizing the propulsion system may further include verifying whether fluid or pressure is being received at the connection or is not present; and, in response to the absence, identifying individual connections where an error occurred in receiving the composition or the pressure, and identifying the individual connections and specific objects connected to and including the individual connections. The second process may include the state of the objects being selected from a group including at least one of the following: on, off, pressure, composition, and product type. The second process may also include the propulsion server creating a traversal graph that tracks all objects traversed within the block diagram during runtime visualization of the propulsion system, and / or using traversal logic using the states of active objects and behavior definitions of passive objects within the block diagram to create a graph that tracks all objects traversed within the block diagram during runtime visualization of the propulsion system.

[0017] At least the second process for visualizing a propulsion system may further include classifying each object in the block diagram as one of the following: an active object, a passive object, and a pipe. An active object may include at least one of the following: an origin of a value of a property state of the block diagram or an interactive object of the block diagram that triggers a change in the state of a subordinate object in the propulsion system shown in the block diagram. Furthermore, the pipe may be, for example, any device that connects two objects of the propulsion system in the block diagram and transfers fluid or pressure from one object to a subordinate object in the block diagram. The pipe may be any device that connects two objects of the propulsion system in the block diagram and transfers a value of one of the following: pressure, composition, or product type from one object to a subordinate object in the block diagram.

[0018] The second process may include recording all activity on the block diagram during runtime in an action log. The second process may include using the action log of all activity on the block diagram during runtime to roll back actions of the propulsion system shown in the block diagram to a desired previous point in the runtime. The second process may include using the action log of all activity on the block diagram during runtime to establish a new runtime starting state for the block diagram.

[0019] Additionally, at least the second process for visualizing a propulsion system may include recording snapshots of the block diagram at selected times at runtime to record the states of all valves in the propulsion system depicted in the block diagram, and the second process may include recording snapshots of the block diagram at selected times at runtime to record the states of all pressure regulators in the propulsion system depicted in the block diagram.

[0020] The second process may include accelerating the traversal algorithm through a data extraction program within the scanshape tool that creates a support file including a translation table, an interlocking map table, and an object index, and the traversal algorithm accesses the support file. The second process may include receiving input to the propulsion server from an external command and control system in communication with the propulsion server to change the state of the device.

[0021] Furthermore, at least the second process for visualizing a propulsion system may include the scan shape tool extracting essential elements of data attached to each object in a system diagram of a diagram vector graphics application to create the following: a translation table, an interlocking map table, and an object index for access by a fluid piping evaluator. Finally, the second process may further include, for example, creating a block diagram including a tailored propulsion system stencil, where the stencil may include the following: object data including data indicating component types, connections, and / or characteristics specific to each of the objects.

[0022] A further embodiment of the present disclosure provides a machine, the machine including, for example, at least a display server, the display server including a graphical user interface configured to generate a block diagram, which may include objects that may represent components in a fluid system; and a first socket configured to communicate with a second socket in the fluid server associated with a scan shape tool including a data extraction program, the data extraction program configured to generate and store a translation table, an interlocking map table, and an object index configured to accelerate a traversal algorithm configured to control a visualizer in the display server. The fluid server can be configured to design, verify, and validate at least one of the following: design, assembly, or integration of objects in a fluid system. The block diagram may be, for example, a diagram of a fluid system.

[0023] The fluid server may include a command handler configured to update the state of objects in the fluid system. The fluid server may include a fluid piping evaluator configured to recursively update piping in the fluid system. The fluid server may, for example, include the traversal algorithm and be configured to generate and access the conversion table, the interlocking map table, and the object index configured to be input to the traversal algorithm. The fluid piping evaluator in the fluid server may include the traversal algorithm.

[0024] Additionally, the fluid server may include an action log configured to record all activity occurring in the block diagram. The fluid server may be configured to update at least one of an identity, a state, and a color of each component of the fluid system, each represented in the block diagram by an object in the block diagram. The objects may include a classification selected from the group consisting of active objects, passive objects, and piping. The objects may include a set of rules and a set of behaviors. The objects may include a classification as an active object, which may include at least one of the following states: on, off, pressure, composition, and product type.

[0025] Thus, the novel machine provides at least a first process for visualizing a fluid system, which may include generating a block diagram in a graphical user interface within a fluid visualization machine that receives input for displaying devices in the fluid system as objects in the block diagram by a visualizer on the graphical user interface; a display server including the graphical user interface passing the input to, for example, a fluid piping evaluator within a fluid server; the fluid piping evaluator applying an algorithm in response to the input to evaluate flow or pressure within objects or piping within the fluid system; and generating a traversal graph of all devices and piping within the fluid system. The first process for visualizing a fluid system may further include: the fluid server executing a traversal algorithm and updating the state of each object in the block diagram by sending updates to a visualizer in the display server; the display server updating the display of the object state on the block diagram; the fluid piping evaluator updating object color codes and piping color codes and sending the updates to the display server; and the display server updating the display of the object color codes and piping color codes on the block diagram.

[0026] The first process may further include the fluid piping evaluator traversing a particular connection at a source object within the fluid system and generating a composition or pressure to be sent through the connection to a destination object. The first process may also include verifying whether a composition or pressure is received or not at the connection to the destination object, and, in response to an absence, identifying individual connections at which an error occurred in receiving the composition or pressure, and identifying the individual connections and specific virtual modules each connected to and including the individual connections. The device state may be selected from a group including at least one of the following: on, off, pressure, composition, and product type. Furthermore, the fluid server may create a traversal graph tracking all objects traversed within the block diagram during runtime visualization of the fluid system.

[0027] The first process may also include the fluid server using traversal logic using states of active objects and behavior definitions of passive objects in the block diagram to create a traversal graph that tracks all objects traversed in the block diagram during runtime visualization of the fluid system. The fluid piping evaluator may further classify each object in the block diagram as one of an active object, a passive object, and a piping. An active object may include at least one of the following: an origin of a value of a property state in the block diagram, or an interactive object in the block diagram that triggers a state change of a subordinate object in the fluid system depicted in the block diagram.

[0028] The piping is, for example, any device that connects two objects of the fluid system in the block diagram and transmits fluid or pressure from one object to a lower object in the block diagram. Additionally, the piping may transmit a value of one of the following from one object to a lower object in the block diagram: pressure, composition, or product type.

[0029] The first process for visualizing a fluid system may also include recording all activity on the block diagram during runtime in an action log, and using the action log of all activity on the block diagram during runtime to roll back actions of the fluid system shown in the block diagram to a desired previous point in the runtime. Further, the action log of all activity on the block diagram during runtime may be used to establish a new runtime starting state for the block diagram.

[0030] The first process for visualizing a fluid system may also include recording snapshots of the block diagram at selected times at runtime to record the states of all valves in the fluid system shown in the block diagram and / or the states of all pressure regulators in the fluid system shown in the block diagram. The first process may further include accelerating the processing of the traversal algorithm through a data extraction program within a scan shape tool that creates a support file including a translation table, an interlocking map table, and an object index, and the traversal algorithm accessing the support file.

[0031] The first process for visualizing a fluid system may also include receiving input to the fluid server from an external command and control system in communication with the fluid server to change the state of the object. The first process may further include a scan shape tool extracting essential elements of data attached to the object in a system diagram of a diagram vector graphics application to create a conversion table, an interlocking map table, and an object index accessed by a fluid piping evaluator. Finally, the first process for visualizing a fluid system may further include, for example, creating a block diagram including a fluid system stencil tailored to the object, the stencil including data indicating component types, connections, and / or properties specific to each of the objects.

[0032] At least the second process for visualizing a fluid system includes constructing a system diagram of the fluid system in a diagram and vector graphics application that accesses a respective stencil for each object to be placed in the system diagram, the stencil including data associated with the object, including component types, connections, and properties specific to the object; running an error checking program on a scalar vector graphics file constructed by the diagram and vector graphics application from input; and, in response to the absence of errors in the scalar vector graphics file, using a data extraction program to create the following from data associated with objects in the scalar vector graphics file: a conversion table, an interlocking map table, and an object index; converting the system diagram to a scalar vector graphics file and extracting the scalar vector graphics file into a block diagram. The process may include loading a scalar graphics application in a display server to visualize the fluid system; receiving input for displaying devices in the fluid system as objects in the block diagram on a graphical user interface by the visualizer; the display server passing the input to a fluid server; in response to the input, the fluid server applying an algorithm to evaluate piping in the fluid system; a scan shape tool generating a list of devices and piping in the fluid system; the fluid server executing a traversal algorithm updating a state of the devices in the fluid server and sending the updates to the display server; the display server updating a display of the state of the objects on the block diagram; the fluid server updating a color code of the devices and a color code of the piping and sending the updates to the display server; and the display server updating a display of the color code of the devices and the color code of the piping on the block diagram. The second process for visualizing a fluid system may also include traversing to a specific connection at an origin object and generating a fluid or pressure to be sent through the connection to a destination.

[0033] Additionally, at least the second process for visualizing a fluid system may further include verifying whether fluid or pressure is being received at the connection or is not present; and, in response to the absence, identifying individual connections where an error occurred in receiving the composition or the pressure, and identifying the individual connections and specific objects connected to and including the individual connections. The second process may include the state of the objects being selected from a group including at least one of the following: on, off, pressure, composition, and product type. The second process may also include the fluid server creating a traversal graph that tracks all objects traversed within the block diagram during runtime visualization of the fluid system, and / or using traversal logic using states of active objects and behavior definitions of passive objects within the block diagram to create a graph that tracks all objects traversed within the block diagram during runtime visualization of the fluid system.

[0034] At least the second process for visualizing a fluid system may further include classifying each object in the block diagram as one of the following: an active object, a passive object, and a pipe. An active object may include at least one of the following: an origin of a value of a property state of the block diagram or an interactive object of the block diagram that triggers a change in the state of a subordinate object in the fluid system depicted in the block diagram. Furthermore, the pipe may be, for example, any device that connects two objects of the fluid system in the block diagram and transfers fluid or pressure from one object to a subordinate object in the block diagram. The pipe may be any device that connects two objects of the fluid system in the block diagram and transfers a value of one of the following: pressure, composition, or product type from one object to a subordinate object in the block diagram.

[0035] The second process may include recording all activity on the block diagram during runtime in an action log. The second process may include using the action log of all activity on the block diagram during runtime to roll back actions of the fluid system shown in the block diagram to a desired previous point in the runtime. The second process may include using the action log of all activity on the block diagram during runtime to establish a new runtime starting state for the block diagram.

[0036] Additionally, at least the second process for visualizing a fluid system may include recording, at runtime, a snapshot of the block diagram at a selected time to record a state of all valves in the fluid system depicted in the block diagram, and the second process may include recording, at runtime, a snapshot of the block diagram at a selected time to record a state of all pressure regulators in the fluid system depicted in the block diagram.

[0037] The second process may include accelerating the traversal algorithm through a data extraction program within the scanshape tool that creates a support file including a translation table, an interlocking map table, and an object index, and the traversal algorithm accesses the support file. The second process may include receiving input to the fluid server from an external command and control system in communication with the fluid server to change the state of the device.

[0038] Furthermore, at least the second process for visualizing a fluid system may include the scan shape tool extracting essential elements of data attached to each object in a system diagram of a diagram vector graphics application to create the following: a translation table, an interlocking map table, and an object index for access by a fluid piping evaluator. Finally, the second process may further include, for example, creating a block diagram including a tailored fluid system stencil, where the stencil may include the following: object data including data indicating component types, connections, and / or characteristics specific to each of the objects.

[0039] These features and functions may be achieved individually in various embodiments of the present disclosure, or may be combined in other embodiments. Further details of these features and functions will be apparent from the following description and by reference to the drawings. [Brief explanation of the drawings]

[0040] The novel features believed distinctive to the illustrative embodiments are set forth in the appended claims, and the illustrative embodiments and preferred modes of use, as well as their objects and features, will best be understood by reference to the following detailed description of illustrative embodiments of the present disclosure, taken in conjunction with the accompanying drawings, in which:

[0041] [Figure 1] FIG. 1 is a top view of a propulsion system in accordance with an illustrative embodiment. [Figure 2] FIG. 1 is a plan view of a schematic diagram of a design of a portion of a propulsion system in accordance with an illustrative embodiment; [Figure 3] 1 is a flowchart of a process for incorporating virtualization tools for designing, verifying, testing, and monitoring the operation of propulsion and / or fluid systems, according to an example embodiment. [Figure 4] 10 is a diagram illustrating various shapes customized to represent different objects within a propulsion system in accordance with an illustrative embodiment; [Figure 5] FIG. 1 is a plan view of a block diagram of a modular architecture for a propulsion visualization machine and process in accordance with an example embodiment. [Figure 6] FIG. 10 illustrates a node representation of changes in a traversal graph within a forwarding server, according to an example embodiment. [Figure 7] 1 is a block diagram of a data processing system in accordance with an illustrative embodiment; [Figure 8] FIG. 1 is a block diagram of a product management system in accordance with an illustrative embodiment; [Figure 9] FIG. 1 is a block diagram of a manufacturing and operations process in accordance with an example embodiment. [Figure 10]FIG. 1 illustrates a system diagram of a thermal management system according to an example embodiment. [Figure 11] 1 is an illustration of a flowchart of a process for visualizing and interacting with a virtual model of a propulsion system in accordance with an illustrative embodiment; [Figure 12A] 1 is an illustration of a flowchart of a process for visualizing and interacting with a virtual model of a propulsion system in accordance with an illustrative embodiment; [Figure 12B] 1 is an illustration of a flowchart of a process for visualizing and interacting with a virtual model of a propulsion system in accordance with an illustrative embodiment; [Figure 13] 1 is an illustration of a flowchart of a process for visualizing and interacting with a virtual model of a fluid system, in accordance with an illustrative embodiment; [Figure 14A] 1 is an illustration of a flowchart of a process for visualizing and interacting with a virtual model of a fluid system, in accordance with an illustrative embodiment; [Figure 14B] 14B is a continuation of FIG. 14A of a flowchart of a process for visualizing and interacting with a virtual model of a fluid system, according to an illustrative embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0042] The illustrative embodiments recognize and take into account one or more different considerations: The illustrative embodiments recognize and take into account that currently no machine exists that can accurately verify and / or validate the operation of a propulsion system and / or interact with a virtual model of the propulsion process prior to executing the propulsion process on flight hardware; No industry tools exist that can integrate with existing design and test systems and support rapid virtualization development that can be used to develop, verify, integrate, validate by test, and track the reliability of fluid handling systems, such as propulsion systems.

[0043] The illustrative embodiments recognize and take into account that each subsystem for the design, construction, and deployment of a propulsion system, fluid system, and / or satellite launch system must meet individual requirements during assembly, integration, and / or testing, at least with respect to compatibility, functionality, and / or reliability with components of other subsystems, and interaction with other systems. Subsequent verification, validation, and adaptation of each subsystem occurs according to a format dictated by the specific requirements of each subsystem and its interfaces. Verification events may include, for example, analysis, demonstration, testing, or inspection. Verification by test is one method of confirming that requirements are met.

[0044] Validating current fluid and / or propulsion systems through testing of actual physical components can be extremely time-consuming and expensive. The illustrative embodiments recognize and take into account that current analytical techniques are unable to visualize and / or animate / virtualize the interactions between components to a level that allows for the design, validation, and / or validation through testing of fluid handling systems, such as propulsion systems, at least because existing techniques are based on operating components individually / sequentially without holistically integrating the effects of the components on each other.

[0045] Therefore, what is needed is a virtual fluid and / or propulsion system configured to simulate and / or interactively model the mechanical behavior of a physical fluid / propulsion system. What is needed is a virtual fluid and / or propulsion system modeling environment in which initial parameters for the virtual system can be selected and provided via a user interface accessible to a designer, and a virtual test rig configured to simulate a physical test rig, where the modeling environment establishes an executable block diagram for simulating the fluid / propulsion system that is controllable and observable via the user interface.

[0046] Thus, examples of the present disclosure describe machines and processes that enable at least improved quality in all phases of design, construction, and flight by enabling virtualization and interaction with virtual models of at least propulsion and / or fluid subsystems in visual simulations and supporting the engineering community with at least analysis, documentation, integration, and system functionality studies during at least design, manufacturing, and / or operational flight. Furthermore, examples of the machines and processes described herein provide for virtualization and interaction with virtual models that can serve as tools for at least test engineering development, validation by testing, and / or reliability assurance, for example, for propellant supply, high-pressure system testing, and / or any fluid processing of satellites and / or rockets. Finally, examples of the machines and processes described herein can be used as tools for developing at least test engineering development, validation by testing, and / or reliability assurance processes, for example, for propellant supply, high-pressure system testing, and / or any fluid processing of satellites and / or rockets.

[0047] The embodiments herein describe machines and processes that allow propulsion and / or fluid systems and / or their operation to be designed, verified, and validated within a virtual environment. The illustrative embodiments recognize and take into account that such machines and processes can reduce risk and / or human error in the development, writing, and review of propulsion operations, thus achieving both reliability and first-time quality of operation and performance.

[0048] It is recognized and taken into consideration in the illustrative embodiments that such machines and processes provide technical improvements over the existing "Method and Apparatus for Testing RF Performance of a Satellite Wiring Harness and Signal Processing Units" described in U.S. Patent No. 10,389,458, issued to The Boeing Company on August 20, 2019, and incorporated herein by reference in its entirety.

[0049] The illustrative embodiments recognize and take into account that modeling fluid and / or propulsion systems is complex and that the visualization architecture described in U.S. Patent No. 10,389,458 or U.S. Patent Publication No. 2018 / 0276321A1 may not adequately address the processing needs of at least the accuracy and / or reliability desired for modeling fluid and / or propulsion systems. Accordingly, the illustrative embodiments recognize and take into account that the illustrative machine and process embodiments described herein provide technical improvements over the existing “Method and Apparatus for Testing Design of Satellite Wiring Harness and Signal Processing Units” described in at least U.S. Patent Publication No. 2018 / 0276321A1 dated September 27, 2018 or U.S. Patent Publication No. 2018 / 0276321, which are incorporated herein by reference in their entirety.

[0050] The illustrative embodiments recognize and take into account that propulsion and fluid handling systems have different design, verification, and operational complexities than satellite RF (radio frequency) wiring and / or RF cable systems, and that a different virtualization architecture must be built to accommodate such complexities. Accordingly, the novel virtualization machine and process described herein can accommodate the complexities of propulsion and / or fluid systems as well as other systems.

[0051] The novel machine and process technological improvements described herein provide full backward visualization capabilities for the behavior of payloads, such as communications payloads as described in U.S. Patent No. 10,389,458, as well as the behavior of propulsion / fluid systems that may be added to any propulsion / fluid system in the future.

[0052] The illustrative embodiments recognize and consider the need for, and provide novel engineering approaches to, techniques that allow designers to rigorously verify and / or validate proper valve opening and closing sequences in propulsion and / or fluid systems prior to operation, which is clearly important in the development of satellite and / or rocket fueled operations and during testing of sophisticated propulsion and fluid systems.

[0053] The novel machines and processes described herein also enable in-process tracking of design steps, operational functions, and component interactions. Tracking can be performed by engineers and / or system operators. The novel machines and processes described herein also provide quality monitoring that tracks and visually displays every critical operation, as well as the ability to identify and / or intervene when unintended and / or undesired results are predicted and / or confirmed.

[0054] It is recognized and taken into account in the exemplary embodiments herein that a modular design for the propulsion server and propulsion display system allows the visualization components of the propulsion visualization machine to operate independently, and also allows for flexible command and control of the propulsion visualization machine either through direct interaction with the display interface or through connection to an external software application designed to command the system.

[0055] The exemplary embodiments herein recognize and take into account that by constructing a traversal graph for a propulsion visualization machine using respective resource files, the computational operation of the system is improved technically, at least in reducing the processing time of required traversal steps in heavy processing load situations, such as the execution of input scripts and / or sequences, as compared to conventional visualization systems lacking the novel architecture of the machines and processes illustrated in the embodiments herein. The traversal graph resources for the propulsion server technical improvements include at least novel translation tables, ganged map tables, and object indexes in an aspect that reduces the processing cycle time of the traversal algorithms.

[0056] Further, it is recognized and taken into consideration in the exemplary embodiments herein that the addition of novel action logging functionality to the propulsion visualization machine provides technical improvements to the computational operation of the system, enabling rollback actions and selective configuration restoration options with respect to at least the design, visualization, and / or verification and / or validation of the operation of the propulsion system.

[0057] The exemplary embodiments herein recognize and take into account that there is a need for an executable block diagram application that provides a runtime action log for the configuration of a propulsion system, enabling all activity on a propulsion visualization block diagram in a user session to be recorded. Thus, there is a need for a technical improvement that allows a configuration to be rolled back to a particular point in the system state in the event of an unintended action that could lead to a physically irreversible reaction, without the need to restart a new session within the virtual environment of the propulsion visualization machine.

[0058] Additionally, the new action log feature allows a system configuration of the same system block diagram to be restored in a new session using a log file saved from a previous session of the propulsion visualization machine. That is, the new technology enables a rollback / reset capability at run time in the propulsion visualization machine, allowing a designer to modify individual objects and / or groups of objects, or change specific properties of a single object and / or selected objects, through a graphical user interface, and then verify the impact of the changes through testing.

[0059] Furthermore, it is recognized and contemplated in the exemplary embodiments herein that the above action log allows for a new snapshot feature to be incorporated into the configuration of the propulsion visualization machine, which can capture a snapshot of the current state of at least all valves in the system, thereby assisting engineers in test planning and development of fluid systems, such as propulsion systems.

[0060] The exemplary embodiments herein recognize and take into account that current processor technology does not allow for processing scripts and sequences filed with large amounts of commands to change the state of objects within an executable block diagram, for example, to execute a modular test executable, without suffering from image freezes in a visualization of a propulsion system. Current modular test execution protocols do not allow for interaction with the executable block diagram display, a server, and a user, such as an engineer. Current modular test execution protocols do not allow for interaction with the executable block diagram display, a server, and a user, such as an engineer, to process changes in real time to support at least the validation, test planning, and / or development of a fluid system, such as a propulsion system.

[0061] The illustrative embodiments herein recognize and take into account that technological improvements that enhance classification of objects to classifications that are compatible with the design of the propulsion server will improve the processor's ability and efficiency to accept edits that customize the rules and directed actions that characterize the physical hardware components of the propulsion and / or fluid system.

[0062] Thus, the exemplary embodiments herein recognize and take into account that a unique operational sequence for all stencil objects corresponding to the system's design exists when verifying through testing. Having a unique operational sequence for all stencil objects corresponding to the system's design ensures the expected, reliable operational behavior of the system during assembly and testing. Having a unique operational sequence for all stencil objects corresponding to the target system's design also ensures that an artifact that meets the requirements of the target system is provided. An artifact may be, for example, a value that indicates an operating parameter of a fluid or propulsion system, such as propulsion system 100, or a device therein. The device within a fluid or propulsion system, such as propulsion system 100, may be represented by an object in a system diagram and / or executable block diagram of a fluid or propulsion system, such as propulsion system 100.

[0063] Thus, the illustrative embodiments herein recognize and take into account both the requirements placed on the system's test equipment and the requirements placed on the target system. The novel machines and processes described herein provide a comprehensive virtualization approach that supports the safe operation of the system's test equipment, the target system, and the engineer and / or operator.

[0064] Referring now to FIG. 1 , FIG. 1 is a plan view of a propulsion system according to an exemplary embodiment. As will be appreciated by those skilled in the art, a propulsion system is a type of fluid system, and the embodiments provided below with respect to a propulsion system may be generally and specifically applicable to other distinct fluid systems. The illustrated propulsion system 100 provides propulsion 102 from a nozzle 104 via connection components that control the pressure and fluid combination of a particular composition of commodity. For example, the commodity may be fuel or oxidizer, or other fluid or gas. For example, the commodity may be stored in at least a fuel tank 106 or an oxidizer tank 108, with pressure provided by a pressurized tank 110. As shown in FIG. 1 , the propulsion system 100 includes a number of valves, transducers, piping 112, and fittings.

[0065] Figure 1 is not intended to be a detailed or exclusive representation of any particular fluid and / or propulsion system, but rather to provide an overview of the components and configurations typically found in a propulsion system. Each fluid and / or propulsion system requires meticulous design to exacting standards. Once designed, each fluid and / or propulsion system requires verification and validation through testing during assembly and integration, during production, and prior to production and / or operational deployment to ensure proper fit and functional behavior according to the system requirements.

[0066] The illustration of propulsion system 100 in FIG. 1 is not intended to imply physical or architectural limitations to the manner in which an illustrative embodiment may be implemented. Other components may be used in addition to or in place of the illustrated components. Some components may be optional. Additionally, the images of elements in FIG. 1 are intended to illustrate some functional components of propulsion system 100. As will be appreciated by those skilled in the art, one or more of these elements may be combined, divided, or combined and then divided into different blocks in some cases when implemented in an illustrative embodiment.

[0067] Referring now to Figure 2, a plan view of a schematic design of a portion of a propulsion system is shown, in accordance with an illustrative embodiment. Figure 2 shows a plan view of a schematic design 200 of a portion of a propulsion system, such as propulsion system 100 shown in block diagram form in Figure 1.

[0068] Diagram 200 represents the design of a load panel for an oxidizer tank, such as oxidizer tank 108 shown in FIG. 1 . When designing a propulsion system, a design engineer creates a diagram, such as diagram 200, that specifies various objects 202 and their connections 204 in the propulsion system. The labeled objects 202 and connections 204 in diagram 200 are not intended to be limited to the physical components, such as oxidizer tank 108 or propulsion system 100 shown in FIG. 1 , labeled in this example diagram, but rather are presented to suggest, in part, how objects 202 or connections 204 may be used in a design diagram. Object 202 may represent any component, device, or unit that forms part of a propulsion and / or fluid system and / or component thereof, such as propulsion system 100 and / or oxidizer tank 108 shown in FIG. 1 .

[0069] Connections 204 may be, for example, piping configured to allow the movement of a composition from one object within propulsion system 100 to another object within or associated with propulsion system 100. A Word document may be drafted to accompany system diagram 200 to describe the connections between components, operational procedures, and parameters of the elements in the diagram.

[0070] Thus, while a system diagram serves as a plan for manufacturing a propulsion system, it lacks the ability to visualize the system in operation. Therefore, system diagram 200 does not provide functional validation of a design prior to propulsion operation on the actual hardware of a physical propulsion system, nor does it serve as a testing platform for the propulsion system. Furthermore, system diagrams such as system diagram 200 do not serve as agile development tools for evaluating alternative design options. Prior to the processes and machines described herein, no industry tools existed that supported rapid virtual development that could be integrated into existing operational systems for developing, validating, integrating, testing, and tracking the accuracy and reliability of propulsion and / or fluid handling systems.

[0071] Referring now to FIG. 3, a flowchart of a process for incorporating a virtualization tool for designing, verifying, testing, and monitoring the operation of a propulsion and / or fluid system is shown, according to an illustrative embodiment. Process 300 shown in FIG. 3 begins by creating new stencil shapes (step 302) for each object specific to the propulsion and / or fluid system that can be accessed and used by a diagram and vector graphic application. An example of a stencil created in step 302 is shown in FIG. 4. The objects may represent, for example, any component or device or unit that forms part of the propulsion and / or fluid system.

[0072] For each stencil shape, a novel execution table is generated and associated with and / or embedded in the stencil coding to indicate execution essentials for the object represented by that stencil shape so that it can be used in the novel example processes and machines described herein (step 304). The object may represent, for example, any component or device or unit that forms part of a propulsion system and / or a fluid system.

[0073] Execution requirements may include, for example, each individual object's unique identification, configuration, structural and / or performance characteristics, connection and / or functional specifications, and / or state options. Performance characteristics may include, for example, pressure and / or flow rate, required tolerances and / or reliability, triggers, product requirements, functions, and / or behaviors. State options for devices represented by objects in executable block diagram 510 may include, for example, active, passive, and piping. That is, each stencil has associated data, which may be, for example, metadata that may serve as the basis for execution requirements.

[0074] Piping includes, for example, any form of hardware connected to an object. Piping, for example, connects two or more objects and allows for the transfer of goods and / or pressure between those objects. Goods include, for example, fluids and / or gases and / or compositions thereof. Current stencil libraries, such as those described in U.S. Pat. No. 10,389,458, may not have stencil shapes with associated and / or embedded performance requirements, as required by the process and machine embodiments described herein for propulsion and / or fluid systems.

[0075] After the stencil shapes and implementation requirements are created, the designer can draft a system diagram for the propulsion and / or fluid system design (step 306). The designer interfaces with a diagram and vector graphics application via a graphical user interface to generate a scalar vector graphic file representing the system diagram. An error checking tool in the diagram and vector graphics application then performs error checking on the scalar vector graphic file generated by the diagram and vector graphics application (step 308).

[0076] In response to the error check, the system diagram and execution requirement table are converted (step 310) into a scalar vector graphics file formatted to retain and mate with each stencil of the system diagram all of the execution requirements of the associated and / or embedded execution tables. The execution requirements of the associated and / or embedded execution tables, together with each stencil of the system diagram, are configured to provide animated graphics with easy manipulation during execution of the visualization application. The data associated with each stencil may be, for example, metadata.

[0077] In response to the error check finding no errors, the new and unique scan shape tool executes the data extraction program's specially programmed algorithms on the system diagram and execution requirement table to convert them and reformat the execution requirements into a traversal graph. A new resource file including at least a translation table, an object table, and an interlocking map table is generated by the scan shape tool (step 312). The scan shape tool may be, for example, an application and / or program resident on a processor in the support server that is specially programmed to execute the new and unique code of the data extraction program. Each of the translation table, object table, and interlocking map table is configured to be accessed by a visualization tool that interfaces with the propulsion server and / or fluid server, which handles large amounts of data, in visualizing the executable block diagram of the propulsion and / or fluid system, thereby reducing the processing time of the visualization tool. The visualization tool may be as described by visualization tool 318 in U.S. Pat. No. 10,389,458.

[0078] This newly formatted scalar vector graphics file is then loaded onto a display server configured to process an executable block diagram simulation of the virtual operation of the propulsion and / or fluid system (step 314). The display server configured to process the executable block diagram simulation of the virtual operation of the propulsion and / or fluid system can be associated with a graphical user interface configured to receive designer input and / or automated input. For example, the automated input may be generated by another computer processor.

[0079] This scalar vector graphics file is then executed by a display server configured to process an executable block diagram simulation of the virtual operation of the propulsion and / or fluid system (step 316). The display server configured to process the executable block diagram simulation of the virtual operation of the propulsion and / or fluid system may be configured to receive designer-entered and / or automated input commands. Such commands may stop or start the program runtime. Additionally, the propulsion server may communicate with the display server to log all actions related to the virtual execution of the executable block diagram simulation of the virtual operation of the propulsion and / or fluid system and to provide snap-back or reset functionality to the execution of the executable block diagram simulation of the virtual operation of the propulsion and / or fluid system. The snap-back and reset functionality allow for modifications to the system diagram in the design, thereby allowing for modifications to the executable block diagram and virtual operation simulation of the propulsion and / or fluid system, which may aid in identifying alternative configurations and alternative design outcomes of the propulsion and / or fluid system.

[0080] This allows designers, such as user 516 depicted and described in FIG. 5, to rigorously pre-validate the proper valve opening and closing procedures of a propulsion and / or fluid system design, represented by an executable block diagram on the visualization server, against the initial system diagram of the design. This is critical during satellite and / or rocket fuel operations development, where precise tolerances are required for design, installation, and operation, and during testing of delicate satellite and / or propulsion and / or fluid systems. The tool also enables in-process tracking of propulsion and / or fluid systems during operation. Furthermore, the visualization tool visually tracks critical and / or highly accurate and reliable operations, providing quality monitoring that allows intervention if undesirable factors and / or performance are identified. Thus, this novel machine and process allows propulsion and / or fluid system operations to be designed and verified in a virtual environment. These novel capabilities improve upon existing data processing techniques for analyzing the design and operation of propulsion and / or fluid systems to identify and significantly reduce and / or eliminate human error in the development, design, inspection, and / or operation of propulsion and / or fluid operations, thereby achieving quality, reliability, and accuracy in the design, development, analysis, testing, operation, and execution of propulsion and / or fluid systems from the outset.

[0081] Referring now to FIG. 4 , a number of shapes are shown customized to represent various objects within a propulsion system, according to an exemplary embodiment. Each object may represent, for example, any component, device, or unit forming part of the propulsion system and / or fluid system. In view 400, each of these shapes may be a stencil used, for example, by a designer creating a system diagram in a vector graphics application. Each stencil may be associated with a coding in the vector graphics application and / or embedded in the coding to provide an execution table that holds execution requirements for objects within the propulsion and / or fluid system represented by the stencil. The data associated with each stencil may be, for example, metadata. FIG. 4 is not intended to be a comprehensive or exclusive collection of stencils that may be created to represent objects in the design and / or operation of a propulsion and / or fluid system. For example, the shapes shown in FIG. 4 are examples of stencil 524 shown and described in FIG. 5 .

[0082] As used herein, when the phrase "at least one" is used in conjunction with a list of items, it means that various combinations of one or more of the listed items may be used, and that only one of each item in the list may be required. For example, "at least one of item A, item B, or item C" includes item A, item A and item B, and item B. This example also includes item A, item B, and item C, and item B and item C. Of course, these items may be combined in any way. In other examples, "at least one of" may include other suitable combinations, such as two item A, one item B, ten item C, four item B, and seven item C, etc. An item may be a specific object, thing, category, or the like. In other words, "at least one of" means that any number of items from the list may be used in any combination, and not necessarily all of the listed items.

[0083] Referring now to FIG. 5, a plan view of a block diagram of a modular architecture for a propulsion visualization machine and process, according to an exemplary embodiment, is shown. FIG. 5 illustrates a propulsion visualization machine 500 for developing, evaluating, implementing, and / or testing a propulsion and / or fluid system, such as the propulsion system 100 shown in FIGS. 1-4. The propulsion visualization machine 500 may be referred to as a visualization tool. The propulsion visualization machine 500 may be referred to as a tool for virtualizing a fluid and / or propulsion system, such as the propulsion system 100. The propulsion visualization machine 500 facilitates a construction process for creating and visualizing a propulsion and / or fluid system design, as well as a run-time process that enables the virtualization of the operational activity of the propulsion and / or fluid system, visualization of at least the flow, functional interactions, and outputs of the equipment and piping, represented by objects in an executable block diagram 510, in a propulsion and / or fluid system, such as the propulsion system 100, and their evaluation, verification, and / or testing.

[0084] That is, the propulsion visualization machine 500 facilitates the process of building a virtual model of a system tester that supports a fluid system and / or a flight propulsion system. The propulsion visualization machine 500 allows a user 516 to interface with an executable block diagram 510 and verify reliable operational requirements while ensuring correct test procedures and a reliable and accurate test process.

[0085] The propulsion visualization machine 500 is composed of modular components including a display server 502, a propulsion server 504, and a scanshape tool 506. The display server may include coding in QT, C++, and / or JavaScript. The display server 502 includes a scalar vector graphics application 508 configured to present and manipulate executable block diagrams 510 through a graphical user interface 512. The graphical user interface 512 may be configured to receive input 514 from a user 516 and / or automated input 518 from other servers 520.

[0086] For example, user 516 may be a designer who directs the creation and / or modification of schematic diagram 522 using stencil 524 in diagram and vector graphics application 526. Diagram and vector graphics application 526 may thus be referred to as a schematic construct tool. For example, user 516 may be an engineer or technician who verifies, analyzes, evaluates, or tests the design, reliability, accuracy, and / or operating parameters of a propulsion system, such as propulsion system 100.

[0087] The modular configuration of the components of the propulsion visualization machine 500 allows the display server 502 to function independently, and this configuration also allows for flexibility in that the propulsion server 504 can be commanded and controlled either through direct interaction with a user 516 using a graphical user interface 512, or by connecting to external software applications in other servers 520 designed to command specific portions of interest within the propulsion server 504. For example, the propulsion server 504 may include coding in C#.

[0088] Similarly, the graphical user interface 512 may be configured in a modular manner with the display server 502. Thus, the graphical user interface 512 may be incorporated as a modular portion of the display server 502, as shown in Figure 5. Alternatively, the graphical user interface 512 may be a module physically separate from the display server 502, and may be associated with and communicate with the display server 502, which in turn may be associated with and communicate with the propulsion server 504, the scan shape tool 506, the other servers 420, and the diagram and vector graphics application 526.

[0089] Similarly, as shown in Figure 5, vector graphics application 526 may be physically separate from, but associated with and communicating with, graphical user interface 512. Alternatively, vector graphics application 526 may reside within display server 502 or may be stored within graphical user interface 512. Graphical user interface 512 may include, for example, a display, a data processing system such as that described in Figure 7, and / or an input device.

[0090] The scan shape tool 506 includes an error check 560, a program that checks for errors in the system diagram 522. Errors found and highlighted by the error check 560 include, for example, defects or incompatibilities in the continuity between components connected in the system diagram 522 and / or missing prerequisites for objects in the scalar vector graphics file 526 of the system diagram 522 generated by the diagram and vector graphics application 526. In response to the error check 560 finding no errors, a data extraction program 532 in the scan shape tool 506 generates support files 530 from prerequisite tables 528 associated with objects in the system diagram 522.

[0091] Stencils 524 are associated with and / or include an embedded execution essentials table 528, as shown, for example, in FIG. 5, which provides metadata that is mined from diagram and vector graphics applications 526 and converted into support files 530 by a data extraction program 532 within scan shape tool 506. Stencils are associated with data associated with the fluid and / or propulsion system devices they represent. Metadata may include, for example, component types, one or more connections, and / or properties specific to each object represented in one of stencils 524. FIG. 4 shows non-limiting examples of shapes that may be used in stencils 524.

[0092] Stencil 524 is novel and different from stencils used in current system diagramming tools at least in that it is individually adapted to represent all of the components of a propulsion system, such as propulsion system 100. Similarly, if FIG. 5 were modified to represent a fluid system (in which case the term "propulsion" in FIG. 5 would be replaced with the term "fluid"), stencil 524 would be novel and different from stencils used in current system diagramming tools at least in that it is individually adapted to represent all of the components of the fluid system. Thus, system diagram 522 using stencil 524, as well as scalar vector graphic (SVG) files and executable block diagram 510, may also include novel objects individually adapted to represent the components of the propulsion and / or fluid systems associated with this novel stencil.

[0093] The support files 530 include at least the following novel elements: a translation table 534, an interlocking map table 536, and an object table 538, which are generated and formatted by specially programmed, proprietary algorithms within the data extraction program 532 of the scan shape tool 506. The scan shape tool 506 may, for example, be a server separate from, but in communication with, the promotion server 504, as shown in FIG. 5. For example, the scan shape tool 506 may communicate with the promotion server 504 via at least an Ethernet connection. Alternatively to the relationship shown in FIG. 5, the scan shape tool 506 may be incorporated into the promotion server 504 as an integral component thereof.

[0094] Support file 530 acts as a relational database and contains information specific to each of stencils 524 (e.g., as shown in FIG. 4 ) or each object in a schematic diagram. A specially programmed algorithm coded in data extraction program 532 is configured to identify a unit tag for each object in schematic diagram 522 and then associate the object information with a schematic location for visualization. The unit tag is, for example, metadata in execution requirements table 528 associated with an object in schematic diagram 522 and readable by data extraction program 532. The metadata includes, for example, a component type, one or more connections, and / or properties specific to each object represented in one of stencils 524. A component is, for example, a device in a fluid and / or propulsion system, such as propulsion system 100.

[0095] Support file 530 is configured and operates to act as an address book for command handler 544 and propulsion piping evaluator 546 in propulsion server 504 to look up directions that improve the efficiency of the traversal algorithm. Translation table 534 is a specially programmed file configured and operates to act as a lookup table containing information for every object in the propulsion system represented in system diagram 522. This information includes, for example, the object's unique identification, unit type, and number of ports / connections.

[0096] Interlocking map table 536 is a specially programmed file configured and operatively serves as a lookup table that identifies every connection between objects in system diagram 522. A connection may be, for example, a pipe between objects, or any object that conveys goods and / or pressure from one object to another. That is, for example, interlocking map table 536 lists all units at the beginning and / or end of every pipe in system diagram 522 and, by extension, every pipe in executable block diagram 510 representing a propulsion system, such as propulsion system 100 shown and described in FIG. 1. Object table 538 is a specially programmed file configured and operatively serves as an index file that identifies the page in the set of pages in interlocking map table 536 and translation table 534 in which an object is located.

[0097] The traversal graph 548 improves the processing power of the propulsion server 504. Without the support files 530, the propulsion server 504 would not be able to build the new traversal graph 548 that allows the propulsion server 504 to receive and process hundreds of batch commands to update the image on the graphical user interface 512 without freezing the display on the graphical user interface 512. The increased processing power provided by the traversal graph 548 allows the propulsion server 504 to receive and process 200 commands in a single batch without any degradation in the display updates on the graphical user interface 512. That is, the propulsion piping evaluator 546 uses the support files 530 to create the runtime traversal graph 548. The support files 530 may be flat files pre-constructed from the individual stencil objects in the stencil 524. The separate processing of the propulsion server 504 and the display server 502 helps to handle large amounts of updates to the executable block diagram 510 on the graphical user interface 512 without freezing the display. An algorithm in the propulsion piping evaluator 546 recursively updates the status and / or classification of each object and all piping in the executable block diagram 510 of the propulsion system 100.

[0098] The other server 520 may be, for example, part of an external command and control system that may send automated 518 input directly to the propulsion server 504. The automated 518 input may send requests and / or commands to change the state of objects represented in the executable block diagram 510. The other server 520 may function independently of the user 516 or may additionally or alternatively respond to interactions with the user 516. As a non-limiting example, the other server 520 may be a modular test executive that supplies batches of commands to the propulsion server 504. For example, the other server 520 may represent a program that may send automated 518 input to a diagram and vector graphics application 526.

[0099] Thus, the propulsion piping evaluator 546 receives commands from the command handler 544 to update the state and process of the objects and piping in the executable block diagram 510 on the graphical user interface 512. Specially programmed code in the propulsion piping evaluator 546 then calculates updates to the state of each object or piping shown in the executable block diagram 510, as well as updates to the associated classification, ID, and display color of each object and piping shown in the executable block diagram 510. The updates are sent via a socket in the propulsion server 504 to a socket in the display server 502 and then to the visualizer 550. The visualizer 550 formats the updates so that they can be received and animated and / or displayed on the graphical user interface 512. That is, the visualizer 550 is the program logic that receives the command "update ID with color" and causes it to be displayed on the executable block diagram 510 on the graphical user interface 512. This will therefore cause the display server to update the display of the state of the objects on the executable block diagram 510, as well as the color coding of the objects and the color coding of the piping on the executable block diagram 510.

[0100] This allows the propulsion visualization machine 500 and the processes executed thereon to verify whether simulated fluid, simulated pressure, and / or their simulated compositions are being received or not at the connections to the destination object, and, if not verified, identify the individual connections where an error occurred in receiving the fluid, pressure, and / or their compositions, and identify the individual connections and the specific virtual modules each connected to and containing the individual connections.

[0101] As such, the propulsion visualization machine 500 provides a technical improvement over previous visualization systems in that it provides a machine and process by which input 514 is received at a propulsion server 504 from interactions via a graphical user interface 512. The propulsion server 504 is configured such that, during operation, the propulsion server 504 receives input 514 via the graphical user interface 512 and a command handler 542 within the display server 502. For example, the input 514 may be a request to change the state of an object within the executable block diagram 510. The command handler 542 can convert the input 514 into commands readable by the propulsion server 504.

[0102] During operation, the propulsion server 504 is configured such that the propulsion server 504 receives commands from the display server 502, and a command handler 544 within the propulsion server 504 provides commands, such as commands to update the states of objects represented in the executable block diagram 510, to the propulsion piping evaluator 546. The propulsion piping evaluator 546 is a portion of the propulsion server 504 that contains specially programmed, proprietary algorithms that improve upon previous server technology by providing a real-time, animated visual display of the status of each object in a propulsion system, such as the propulsion system 100 shown in FIG. 1, at a snapshot in time at any selected point in operation in the system's graphical user interface 512.

[0103] Additionally, during operation, propulsion server 504 is configured to provide visual confirmation via graphical user interface 512 of any command sent to any object within a propulsion system, such as propulsion system 100. Visual confirmation may be provided by a visual modular test system hosted on other server 520, such as for any individual command issued as input 514 to graphical user interface 512 and / or automated 518 input.

[0104] Specially programmed proprietary algorithms within the propulsion server 504 are further configured and operate to classify each object in the executable block diagram 510 of the propulsion system 100. Such object classification performed by the propulsion server 504 allows for customization of the rules and behaviors executed by each object of the propulsion system 100 represented in the executable block diagram 510.

[0105] Categories assigned to each object include, for example, active, passive, and piping. The "active" classification defines an object in the executable block diagram 510 that can trigger a change in the state of another object in the executable block diagram 510. The active classification defines an object in the executable block diagram 510 that has an "on" or "off" state and / or more complex property states, such as pressure, commodity type, or composition. As one skilled in the art will appreciate, the propulsion visualization machine 500 performs a visualization that simulates the operation of a fluid and / or propulsion system, such as the propulsion system 100. Thus, references to pressure, commodity type, and / or composition, as described with respect to the executable block diagram 510 presented in the graphical user interface 512, refer to the simulation and not to actual values ​​on the physical hardware that performs the function. One active object may be the origin of all property state values ​​for multiple objects in the executable block diagram 510. Objects may be interactive. Interactive objects within executable block diagram 510 may trigger state changes in subordinate objects of the propulsion system represented in executable block diagram 510.

[0106] The "passive" classification defines objects that are not "active" and are not piping. Each object classified as passive may, for example, be a pass-through device or may have a set of inherent rules and / or behaviors that may affect properties such as pressure and / or composition of goods and / or fluids as they are passed to the next object. That is, objects classified as "passive" are configured to change the pressure and / or state of goods within propulsion system 100 and may do so during operation.

[0107] The "Plumbing" classification defines objects that connect one object to another within the executable block diagram 510. That is, objects classified as "Plumbing" are configured to move pressure or goods from one object to another, and do so during operation.

[0108] The novel algorithm of the propulsion piping evaluator 546 includes rules that give the propulsion server 504 a new ability to access the support files 530 and create a traversal graph 548 that is configured and operationally tracks the state of every object in the executable block diagram 510. The logic of the rules in the support files 530 is based on the state of each object classified as active and the definition of the specific behavior assigned to each object classified as passive. Figure 6 shows an example of the shifting of the traversal graph 548 during runtime of the propulsion server 504 controlling the executable block diagram 510 of a propulsion system such as the propulsion system 100.

[0109] That is, the propulsion piping evaluator 546 has a specially programmed code algorithm that, during an initialization phase, builds a traversal graph 548 by correlating values ​​in the translation table 534, the interlocking map table 536, and the object table 538. After initialization, during runtime, in response to input, the command handler 544 can request the propulsion piping evaluator 546 to change the state of an object. The propulsion piping evaluator 546 then traverses the traversal graph 548 and updates all relevant objects as requested by the input. The propulsion piping evaluator 546 then creates a list of newly formed "update IDs with colors" commands and sends them to the visualizer 550. Using the list of "update IDs with colors" commands, the visualizer 550 updates the display of the executable block diagram 510 on the graphical user interface 512.

[0110] Propulsion piping evaluator 546 is configured to, and during operation, calculates a new state for each node of traversal graph 548 used to orchestrate updates to one or more objects in executable diagram 510. Propulsion server 504 communicates updates to one or more objects in executable diagram 510 via a socket to visualizer 550 in display server 502. Visualizer 550 is configured to, and during operation, translates the updates from propulsion piping evaluator 546 to update the image of executable diagram 510 displayed in graphical user interface 512, which runs scalar vector graphics application 508.

[0111] An update may include, for example, a change in the state of an object in executable block diagram 510, which may be visualized, for example, by a change in the color of an object representing that object in executable block diagram 510. The visualization of an object that changes in executable block diagram 510 due to an update may include plumbing between other objects displayed in executable block diagram 510 on graphical user interface 512.

[0112] In FIG. 5 , arrows within and between the display server 502 and the propulsion server 504 indicate processes executed during runtime to visualize the performance of the operating propulsion system 100 on the executable block diagram 510. Additionally, the propulsion piping evaluator 546 incorporates the functionality of an action log 552 and a configuration snapshot 554 to enhance current performance in the visualization of the fluid and / or propulsion system. The action log 552 records, along with a date / time stamp, all activities and changes to the executable block diagram 510 during the runtime modeling of the propulsion system 100 as directed via the propulsion server 504 and the display server 502. That is, the action log 552 is configured to record all activity occurring on the block diagram. Thus, the action log 552 of all runtime activity on the executable block diagram 510 enables the rollback of the propulsion system 100 depicted in the executable block diagram 510 to a desired previous point in the runtime simulation of the operating propulsion system 100. Additionally, an action log 552 of all activities during runtime on the executable block diagram 510 allows the promotion visualization machine 500 to establish a starting condition for a new runtime on the executable block diagram 510 .

[0113] Special programming of the action log 552 and the propulsion piping evaluator 546 can enhance visualization of fluid and / or propulsion systems, such as the propulsion system 100, by allowing rollback to a desired previous state during runtime of a simulation of the executable block diagram 510 of operations representing the actual performance of the propulsion system 100. Thus, if any undesired or unintended changes or results appear in the executable block diagram 510 on the graphical user interface 512 during runtime, the runtime can be stopped, changes can be made to the design of the conditions and / or states within the executable block diagram 510, and the runtime can be resumed. Thus, a full runtime reset or new session of the simulation is not necessary and can be avoided, thereby reducing the time and expense required for design, validation, and / or testing.

[0114] Additionally, runtime action log 552 can be used to select a previously reached point as the starting point for a new session for designing, verifying, and / or testing propulsion system 100. Additionally, configuration snapshot functionality 554 is configured to implement the functionality of capturing and recording snapshots of the current state and associated values, such as pressures, commodities, and / or compositions, associated with each object represented in executable block diagram 510 during operation. That is, during runtime, a configuration snapshot 554 captured for executable block diagram 510 at a selected time records the state of all valves of a fluid and / or propulsion system, such as propulsion system 100, represented in executable block diagram 510.

[0115] The state of an object may include, for example, the position of a valve. The configuration snapshot 554 record of the state / value of each object represented in the executable block diagram 510 may be used to assist at least an engineer in the design, planning, development, and / or testing of a fluid and / or propulsion system, such as the propulsion system 100.

[0116] 6, a node representation of changes in a traversal graph within a propulsion server is shown, according to an example embodiment. A node representation 600 of traversal graph 548 within propulsion server 504 illustrates the change in state of objects A1 and A2 classified as active, objects P1 and P2 classified as passive, and connecting pipes Pg1, Pg2, and Pg3 for a pressure change scenario 602 in response to input 514 that changes initial state 604 from object A1 off to object A1 on.

[0117] Referring to Figure 7, a block diagram of a data processing system according to an exemplary embodiment is shown. Data processing system 700 is an example of a computer, such as promotion server 504 in Figure 5, and computer readable program code or instructions implementing the digital certificate and key management process of the exemplary embodiment are stored on the data processing system, for example. In this example, data processing system 700 includes a communications fabric 702 that provides communications between a processor unit 704, memory 706, persistent storage 708, a hardware security module 710, a communications unit 712, an input / output (I / O) unit 714, and a display 716.

[0118] The processor unit 704 is responsible for executing instructions of software applications and programs, for example, loaded into memory 706. The processor unit 704 may be a set of one or more hardware processor devices or may be a multi-processor core, depending on the particular implementation.

[0119] Memory 706 and persistent storage 708 are examples of storage 718. As used herein, a computer-readable storage device or computer-readable storage medium is any hardware capable of temporarily or persistently storing information, such as data, computer-readable program code in the form of functions, and / or other suitable information. Also, computer-readable storage device or computer-readable storage medium does not include propagating media, such as transient signals. A computer-readable storage device or computer-readable storage medium may also be a set of computer-readable storage devices or a set of computer-readable storage media. Memory 706, in these examples, is random access memory (RAM) or any other suitable volatile or non-volatile storage device, such as flash memory. Persistent storage 708 may take various forms, depending on the particular embodiment. For example, persistent storage 708 may include one or more devices. For example, persistent storage 708 may be a disk drive, a solid-state drive, a rewritable optical disk, a rewritable magnetic tape, or a combination thereof. The media used for persistent storage 708 may be removable. For example, a removable hard disk drive may be used for persistent storage 708.

[0120] Hardware security module 710 is a physical computing device that protects and manages cryptographic keys and performs encryption and decryption functions for digital signatures. In this embodiment, hardware security module 710 is a plug-in card. Alternatively, hardware security module 710 is an external device connected to data processing system 700. Hardware security module 710 contains a set of secure crypto-processor chips.

[0121] In a heterogeneous distributed computing environment, such as a hybrid multi-cloud and edge environment consisting of multiple clouds corresponding to different cloud providers and multiple edge devices, hardware security module 710 provides exclusive control of a cryptographic private key corresponding to an enterprise, thereby enabling the protection of secure data in transit over a network, including, for example, display server 502. The cryptographic private key is generated within the security boundary of hardware security module 710 and never leaves the boundary throughout the key's lifecycle.

[0122] As a result, data processing system 700 operates as a special-purpose computer system that enables secure management of digital certificates and keys in hybrid multi-cloud and edge environments due to hardware security module 710 within data processing system 700. In particular, hardware security module 710 transforms data processing system 700 into a special-purpose computer system, unlike currently available general-purpose computer systems that do not have hardware security module 710.

[0123] In this embodiment, the communication unit 712 enables communication with other computers, data processing systems, and devices over a network, including, for example, the display server 502. The communication unit 712 can provide communication using both physical and wireless communication links. The physical communication links may utilize, for example, wires, cables, a universal serial bus, or any other physical technology for establishing a physical communication link for the data processing system 700. The wireless communication links may utilize, for example, shortwave, radio frequency, very high frequency, microwave, wireless fidelity (Wi-Fi), Bluetooth®, global system for mobile communications (GSM), code division multiple access (CDMA), second generation (2G), third generation (3G), fourth generation (4G), 4G Long Term Evolution (LTE), LTE Advanced, fifth generation (5G), or any other wireless communication technology or standard for establishing a wireless communication link for the data processing system 700.

[0124] Input / output unit 714 allows for the input and output of data to and from other devices connected to data processing system 700. The sockets shown in FIG. 5 may be part of input / output unit 714. For example, input / output unit 714 may provide a connection for user input via a keyboard, keypad, mouse, microphone, and / or other suitable input device. Display 716 provides a mechanism for displaying information to a user and may include touch screen functionality to allow a user to make on-screen selections or enter data through a user interface.

[0125] Instructions for the operating system, applications, and / or programs may be stored in storage devices 718, which are in communication with processor unit 704 via communications fabric 702. In this illustrative example, the instructions are stored in functional form in persistent storage 708. The instructions may be loaded into memory 706 and executed by processor unit 704. The processes of the various embodiments may be performed by processor unit 704 using computer-implemented instructions, which may be stored in a memory, such as memory 706. These instructions are referred to as program code, computer-usable program code, or computer-readable program code, and may be readable and executable by a processor within processor unit 704. The program instructions in the various embodiments may be embodied in various physical computer-readable media, such as memory 706 or persistent storage 708.

[0126] Program code 720 is stored in a functional form on removable computer readable medium 722 and may be loaded or transferred to data processing system 700 and executed by processor unit 704. Program code 720 and computer readable medium 722 constitute computer program product 724. In one example, computer readable medium 722 may be computer readable storage medium 726 or computer readable signal medium 728.

[0127] In these illustrative examples, computer readable storage media 726 is a physical or tangible storage device used to store program code 720, rather than a medium that propagates or transmits program code 720. Computer readable storage media 726 includes, for example, an optical or magnetic disk that is inserted into or placed into a drive or other device that is part of persistent storage 708 for transfer to a storage device, such as a hard drive that is part of persistent storage 708. Computer readable storage media 726 may be a form of persistent storage, such as a hard drive, a thumb drive, or a flash memory connected to data processing system 700.

[0128] Alternatively, program code 720 may be transferred to data processing system 700 using computer readable signal media 728. Computer readable signal media 728 may be, for example, a carrier data signal containing program code 720. For example, computer readable signal media 728 may be an electromagnetic signal, an optical signal, or any other suitable type of signal. These signals may be transmitted over communications links such as wireless communications links, fiber optic cable, coaxial cable, a wire, or any other suitable type of communications link.

[0129] Also, as used herein, "computer-readable medium 722" may refer to one or more than one computer-readable medium. For example, program code 720 may be stored on computer-readable medium 722 in the form of a single storage device or system. As another example, program code 720 may be stored on computer-readable medium 722 distributed across multiple data processing systems. That is, some instructions of program code 720 may be stored in one data processing system, while other instructions of program code 720 may be stored in one or more other data processing systems. For example, part of program code 720 may be stored on computer-readable medium 722 in a server computer, and another part of program code 720 may be stored on computer-readable medium 722 in a set of client computers.

[0130] The illustrated components of data processing system 700 are not meant to provide architectural limitations to the manner in which various embodiments may be implemented. In some illustrative examples, one or more of these components may be incorporated into or form other components. For example, memory 706, or portions thereof, may be incorporated into processor unit 704 in some illustrative examples. Various illustrative embodiments may also be implemented in data processing systems including other components in addition to or in place of the components illustrated for data processing system 700. Other components illustrated in FIG. 7 may also be modified from the illustrated examples. Various embodiments may be implemented using any hardware device or system capable of executing program code 720.

[0131] In another example, communications fabric 702 may be implemented using a bus system which may be comprised of one or more buses, such as a system bus or an input / output bus. Of course, the bus system may be implemented using any suitable type of architecture that provides for a transfer of data between different components or devices attached to the bus system.

[0132] It should be noted that while the disclosure herein can be implemented using cloud computing, the disclosure is not limited to cloud computing environments. Rather, exemplary embodiments can be implemented in conjunction with any other type of computing environment, whether now known or later developed. Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources, such as networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services, that can be rapidly provisioned and released with minimal administrative effort or interaction with the service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0133] Characteristics include on-demand self-service, broad network access, resource sharing, rapid scalability, and scalable services. On-demand self-service allows cloud users to unilaterally configure computing capabilities, such as server time and network storage, automatically as needed without interacting with the service provider. Broad network access provides the ability to access resources available on the network through standard mechanisms that encourage use by heterogeneous thin- or thick-client platforms, such as mobile phones, laptops, and personal digital assistants. Resource sharing pools providers' computing resources and dynamically allocates and reallocates various physical and virtual resources based on demand to serve multiple users using a multitenant model. Resources are location-independent, in the sense that users generally cannot control or know the exact location of the resources provided, but may be able to identify them at a more abstract level, such as a country, state, or data center. Rapid scalability provides the ability to rapidly, flexibly, and sometimes automatically configure resources to scale out quickly and release quickly and scale in quickly. To the consumer, the available features for configuration appear unlimited, and any amount can be purchased at any time. Measuring services allows cloud systems to automatically control and optimize resource usage by leveraging metering at a level of abstraction appropriate to the type of service, such as storage, processing power, bandwidth, or active user accounts. Resource usage can be monitored, controlled, and reported, providing transparency to both the provider and consumer of the service being used.

[0134] Service models include, for example, Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). SaaS is the ability for a consumer to use a provider's applications running on cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface, such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even the functionality of individual applications, although limited user-specific application configuration settings may be an exception to this. PaaS is the ability for a consumer to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto the cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of the application hosting environment. Infrastructure as a Service (IaaS) is the provision of processing power, storage, networking, and other basic computing resources that allow consumers to deploy and run any software, such as operating systems and applications. While customers do not manage or control the underlying cloud infrastructure, they do have control over the operating systems, storage, deployed applications, and in some cases, limited control over some network components, such as the host firewall.

[0135] Deployment models include private cloud, community cloud, public cloud, and hybrid cloud. A private cloud is cloud infrastructure operated solely for a single organization. It is managed by that organization or a third party and can be located on- or off-premises. A community cloud is cloud infrastructure shared by multiple organizations to support a specific community with shared interests, such as mission, security requirements, policies, or compliance concerns. It is managed by those organizations or a third party and can be located on- or off-premises. A public cloud is cloud infrastructure available to the general public or large industry groups and is owned by an organization that sells cloud services. A hybrid cloud is a cloud infrastructure consisting of two or more clouds, such as private, community, and public clouds, that are unique but connected by standardized or proprietary technologies that enable data and application portability, such as cloud bursting for load balancing between clouds.

[0136] In some alternative implementations of the exemplary embodiments, the functions noted in the blocks may be performed in a different order than that shown in the figures. For example, two blocks shown as successive may be performed substantially concurrently, or the blocks may be performed in the reverse order, depending on the functionality involved. Also, other blocks may be added to the blocks shown in the flowcharts or block diagrams. Some blocks may be optional.

[0137] 8, a block diagram illustrates a product management system 800 in accordance with an illustrative embodiment. Product management system 800 is a physical hardware system. In this illustrative example, product management system 800 includes at least one of a manufacturing system 802 or a maintenance system 804.

[0138] Manufacturing system 802 is configured to manufacture products. Manufacturing system 802 may be used to manufacture propulsion visualization machine 500 and / or fluid and / or propulsion systems designed, verified, and / or tested / evaluated by propulsion visualization machine 500. As shown, manufacturing system 802 includes manufacturing facility 806. Manufacturing facility 806 includes at least one of fabrication facility 808 or assembly facility 810.

[0139] Fabrication facility 808 is a facility that may be used to fabricate propulsion visualization machine 500 and / or the fluid and / or propulsion systems designed, verified, and / or tested / evaluated by propulsion visualization machine 500. Multiple or multiple versions of propulsion visualization machine 500 and / or the fluid and / or propulsion systems designed, verified, and / or tested / evaluated by propulsion visualization machine 500 may be fabricated.

[0140] Fabrication facility 808 may be used to fabricate a number of different structures. For example, fabrication facility 808 may be used to fabricate propulsion visualization machine 500 and / or a fluid and / or propulsion system designed, verified, and / or tested / evaluated by propulsion visualization machine 500, or any component of such a machine or fluid and / or propulsion system, such as propulsion system 100, as well as other components shown in FIGS. 1-7.

[0141] Assembly facility 810 is a facility used to assemble parts to create propulsion visualization machine 500 and / or the fluid and / or propulsion system product, computer, aircraft, or other product being designed, verified, and / or tested / evaluated by propulsion visualization machine 500. Assembly facility 810 may also include machines and tools, which may be, for example, at least one of a robotic arm, a spinner system, a spray system, an elevator system, a rail-based system, or a robot.

[0142] In this exemplary embodiment, maintenance system 804 includes maintenance facility 812. Maintenance facility 812 includes any equipment necessary to maintain and evaluate products. Maintenance facility 812 may include tools for performing various operations on parts and products. Such operations may include disassembling parts, remanufacturing parts, repairing parts, reworking parts, manufacturing replacement parts, or other operations to perform maintenance on products. These operations may be performed for routine maintenance, inspections, upgrades, repairs, or other types of maintenance work.

[0143] In an exemplary embodiment, maintenance facility 812 may include optical inspection equipment, x-ray imaging systems, surface profile measurement systems, drills, vacuum leak checkers, continuity checkers, display and / or interface analysis and repair tools, computer software and hardware, and other suitable equipment. In some cases, maintenance facility 812 may include fabrication facility 808, assembly facility 810, or both, to fabricate and assemble parts required for maintenance.

[0144] Product management system 800 also includes a control system 814. Control system 814 is a hardware system and may also include software or other types of components. Control system 814 is configured to control the operation of at least one of manufacturing system 802 or maintenance system 804. In particular, control system 814 may control the operation of at least one of fabrication facility 808, assembly facility 810, or maintenance facility 812.

[0145] The hardware of control system 814 may be implemented using hardware including, for example, computers, circuits, networks, and other types of equipment. Control may take the form of directly controlling manufacturing equipment 806. For example, control system 814 may control robots, computer-controlled machines, and other equipment. In other illustrative examples, control system 814 may manage the activities performed by personnel 816 when manufacturing or maintaining a product. For example, control system 814 may assign tasks, send instructions, display models, or perform other operations to manage the activities performed by personnel 816. In these illustrative examples, various processes for fabricating propulsion visualization machine 500 and / or the fluid and / or propulsion systems designed, verified, and / or tested / evaluated by propulsion visualization machine 500 using appropriate equipment may be performed using processes implemented in control system 814.

[0146] In various illustrative examples, workers 816 may operate or interact with at least one of manufacturing facility 806, maintenance facility 812, or control system 814. This interaction may occur to manufacture propulsion visualization machine 500 and / or fluid and / or propulsion systems designed, verified, and / or tested / evaluated by propulsion visualization machine 500, or other components used in products such as aircraft, spacecraft, communication systems, computing systems, and sensor systems.

[0147] Additionally, control system 814 may be used to dynamically adjust the production of propulsion visualization machine 500 and / or the fluid and / or propulsion systems designed, verified, and / or tested / evaluated by propulsion visualization machine 500 during the manufacturing process. For example, there are numerous points in the fabrication process of propulsion visualization machine 500 and / or the fluid and / or propulsion systems and other components designed, verified, and / or tested / evaluated by propulsion visualization machine 500 where adjustments can be made to adjust the properties of propulsion visualization machine 500 and / or the components within the fluid and / or propulsion systems designed, verified, and / or tested / evaluated by propulsion visualization machine 500.

[0148] 9, of a manufacturing and operation process 900 for the propulsion visualization machine 500 and / or a fluid and / or propulsion system, such as the propulsion system 100, that is designed, verified, and / or tested / evaluated by the propulsion visualization machine 500. Referring to FIG. 9, a block diagram of a manufacturing and operation process is shown, according to an example embodiment. Prior to the start of production, the manufacturing and operation process 900 includes specification and design 902 and material procurement 904 of the propulsion visualization machine 500 and / or a fluid and / or propulsion system, such as the propulsion system 100, that is designed, verified, and / or tested / evaluated by the propulsion visualization machine 500.

[0149] During production, component and subassembly manufacturing 906 and system integration 908 of the propulsion visualization machine 500 and / or the fluid and / or propulsion system, such as propulsion system 100, designed, verified, and / or tested / evaluated by the propulsion visualization machine 500 occurs. The propulsion visualization machine 500 and / or the fluid and / or propulsion system, such as propulsion system 100, designed, verified, and / or tested / evaluated by the propulsion visualization machine 500 then undergoes certification and delivery 910 and enters operation 912. During customer operation 912, the propulsion visualization machine 500 and / or the fluid and / or propulsion system, such as propulsion system 100, designed, verified, and / or tested / evaluated by the propulsion visualization machine 500 is scheduled for periodic maintenance and repair 914, which may include, for example, modifications, reconfigurations, refurbishments, or other suitable maintenance and repair.

[0150] Each step of manufacturing and operating method 900 may be performed or implemented by a system integrator, a third party, and / or an entity. In these examples, the entity may be a customer. Note that system integrators include, for example, any number of aircraft manufacturers and major system subcontractors. Third parties include, for example, any number of vendors, subcontractors, and suppliers. An entity may be, for example, an airline, a leasing company, a military entity, a service organization, etc.

[0151] In some alternative implementations of the exemplary embodiments, the functions noted in the blocks may be performed in a different order than that shown in the figures. For example, two blocks shown as successive may be performed substantially concurrently, or the blocks may be performed in the reverse order, depending on the functionality involved. Also, other blocks may be added to the blocks shown in the flowcharts or block diagrams. Some blocks may be optional. For example, any of steps 902 through 914 may be optional.

[0152] The flowcharts and block diagrams in the various depicted embodiments illustrate the architecture, functionality, and operation of some possible implementations of machines and processes in the illustrative embodiments. In this regard, each block in the flowcharts or block diagrams may represent at least one of a module, a segment, a function, or a portion of a process or step.

[0153] As noted above, all figures and the foregoing description apply to the propulsion visualization machine 500 as one example of a larger class of fluid systems. Accordingly, the description of the components and technical improvements of the propulsion visualization machine 500 may be applied more broadly to enhance the capabilities of the fluid visualization machine. That is, all components and concepts described above for a propulsion system such as the propulsion system 100 may be equally applied to other fluid systems. That is, in all figures and descriptions, the term "fluid" may be substituted with the term "propulsion" with equal fidelity.

[0154] FIG. 10 illustrates a non-limiting example of a fluid system other than a propulsion system. FIG. 10 illustrates a system diagram of a thermal management system according to an illustrative embodiment. FIG. 10 illustrates a non-limiting alternative to the system diagram of propulsion system 100 illustrated in FIG. 1. FIGS. 2-9 may be derived from and related to a system diagram such as that illustrated in FIG. 10 for thermal management system 1000, just as they are derived from and related to propulsion system 100. Thus, all of the components and concepts described above for the propulsion system are equally applicable to thermal management system 1000, with the term "propulsion" replacing the term "thermal management" in the above example.

[0155] A diagram similar to Figure 10 could be selected from, for example, a system diagram for a hydroelectric power generation system, a refinery, a spacecraft or ship fluid control system, or even a fluid distribution system in a high-rise building as an equivalent alternative fluid system. Figures 2-9 may similarly illustrate and relate to the flow of a system diagram such as that shown in Figure 10, but without the thermal management system 1000. Thus, all of the components and concepts described above for a propulsion system such as propulsion system 100 may be similarly applied to the alternative fluid system, with the term "propulsion" in the above example being replaced with the appropriate term for the alternative fluid system, such as "refinery."

[0156] Thus, at least the propulsion visualization machine 500 described above provides novel hardware for implementing a novel process for visualizing a propulsion system. Referring now to Figure 11, a flowchart of a process for visualizing a propulsion system and interacting with a virtual model thereof is shown, according to an illustrative embodiment. Process 1100 shown in Figure 11 begins by generating a block diagram in a graphical user interface within the propulsion visualization machine (step 1102), which receives input for displaying devices in the propulsion system as objects in the block diagram by a visualizer on the graphical user interface.

[0157] Process 1100 then continues by passing the input to a propulsion piping evaluator in the propulsion server using a display server including the graphical user interface (step 1104). Process 1100 may also include the propulsion piping evaluator applying an algorithm to evaluate flow or pressure in objects or piping in the propulsion system in response to the input (step 1106). Process 1100 may further include generating a traversal graph in the propulsion server for all devices and piping in the propulsion system (step 1108). Process 1100 may further include running the traversal algorithm in the propulsion server and updating the state of each object in the block diagram by sending updates to a visualizer in the display server (step 1110).

[0158] Process 1100 may include updating, by a display server, a display of the object's state on the block diagram (step 1112), and updating, by a promotion piping evaluator, object color codes and piping color codes and sending the updates to the display server (step 1114). Process 1100 may further include updating, by the display server, a display of the object color codes and the piping color codes on the block diagram.

[0159] Additionally, at least the propulsion visualization machine 500 described above provides novel hardware for implementing a novel process for visualizing and interacting with a virtual model of a propulsion system. Referring now to FIGS. 12A and 12B, a flowchart of a process for visualizing and interacting with a virtual model of a propulsion system is shown, according to an exemplary embodiment. Process 1200 shown in FIGS. 12A and 12B begins, for example, by constructing a propulsion system diagram in a diagram and vector graphics application that accesses a respective stencil for each object to be placed on the diagram, the stencil containing data associated with the object, including the object's specific component type, connections, and properties (step 1202). Process 1200 then continues by running a check error program against the scalar vector graphics file constructed by the diagram and vector graphics application from the input (step 1204).

[0160] Process 1200 may also include, in response to the scalar vector graphics file being free of errors, using a data extraction program to create the following from data associated with objects in the system diagram creation tool: a conversion table, an interlocking map table, and an object index (step 1206). Process 1200 may also include converting the system diagram into a scalar vector graphics file and loading the scalar vector graphics file into a scalar graphics application in a display server for displaying a block diagram (step 1208), and receiving input for displaying devices in a propulsion system as objects in the block diagram on a graphical user interface by a visualizer (step 1210).

[0161] Process 1200 may also include passing the input, by the display server, to a propulsion server (step 1212). Process 1200 may include applying, by the propulsion server, an algorithm to evaluate piping in the propulsion system in response to the input (step 1214). Process 1200 may further include generating, by a scan shape tool, a list of all equipment and piping in the propulsion system (step 1216).

[0162] Further, process 1200 may include the promotion server executing a traversal algorithm to update the device states in the promotion server and sending the updates to the display server (step 1218), and updating, by the display server, the display of the object states on the block diagram (step 1220). Further, process 1200 may include the promotion server updating the device color codes and the piping color codes and sending the updates to the display server (step 1222), and updating, by the display server, the display of the device color codes and the piping color codes on the block diagram (step 1224).

[0163] As noted above, at least the propulsion visualization machine 500 described above functions as a fluid visualization machine for a fluid system in a manner similar to that described and illustrated above for the fluid system. Thus, a fluid visualization machine has been described above that provides novel hardware for implementing novel processes for visualizing and interacting with virtual models of fluid systems.

[0164]

[00130] Referring now to Figure 13, a flowchart of a process for visualizing a fluid system and interacting with a virtual model thereof is shown, according to an example embodiment. The process 1300 shown in Figure 13 begins by creating a block diagram in a graphical user interface within a fluid visualization machine (step 1302) that receives input for displaying devices within the fluid system by a visualizer on the graphical user interface as objects within the block diagram.

[0165] Process 1300 then continues by passing the input to a fluid piping evaluator in the fluid server using a display server including the graphical user interface (step 1304). Process 1300 may also include the fluid piping evaluator applying an algorithm to evaluate flow or pressure in objects or piping in the fluid system in response to the input (step 1306). Process 1300 may further include generating a traversal graph in the fluid server for all devices and piping in the fluid system (step 1308). Process 1300 may further include running the traversal algorithm in the fluid server and updating the state of each object in the block diagram by sending updates to a visualizer in the display server (step 1310).

[0166] Process 1300 may include updating, by a display server, a display of the object's state on the block diagram (step 1312), and updating, by a fluid piping evaluator, the object's color code and the piping color code and sending the update to the display server (step 1314). Process 1300 may further include updating, by the display server, a display of the object's color code and the piping color code on the block diagram.

[0167] Additionally, at least the fluid visualization machine described above provides novel hardware for implementing a novel process for visualizing and interacting with a virtual model of a fluid system. Referring now to Figures 14A and 14B, a flowchart of a process for visualizing and interacting with a virtual model of a fluid system is shown, according to an exemplary embodiment. Process 1400, as shown in Figures 14A and 14B, begins by constructing a fluid system diagram in a diagram and vector graphics application that accesses a respective stencil for each object to be placed on the diagram, where the stencil contains data associated with the object, including the object's specific component type, connections, and properties (step 1402). Process 1400 then continues by running a check error program against the scalar vector graphics file constructed by the diagram and vector graphics application from the input (step 1404).

[0168] Process 1400 may also include, in response to the scalar vector graphics file being free of errors, using a data extraction program to create the following from data associated with objects in the system diagram creation tool: a translation table, an interlocking map table, and an object index (step 1406). Process 1400 may also include converting the system diagram into a scalar vector graphics file and loading the scalar vector graphics file into a scalar graphics application in a display server for displaying a block diagram (step 1408), and receiving input for displaying devices in a fluid system as objects in the block diagram on a graphical user interface by a visualizer (step 1410).

[0169] Process 1400 may also include passing the input to the fluid server by the display server (step 1412). Process 1400 may include applying, by the fluid server, an algorithm to evaluate piping in the fluid system in response to the input (step 1414). Process 1400 may further include creating, by a scan shape tool, a list of all devices and piping in the fluid system (step 1416).

[0170] Further, process 1400 may include the fluid server executing a traversal algorithm to update the state of the devices in the fluid server and sending the updates to the display server (step 1418), and updating the display of the object states on the block diagram by the display server (step 1420). Further, process 1400 may include the fluid server updating the device color codes and piping color codes and sending the updates to the display server (step 1422), and updating the display of the device color codes and piping color codes on the block diagram by the display server (step 1424).

[0171] The present application has described above at least the exemplary embodiments set forth in the appendices below.

[0172] Clause 1. A machine containing a display server: The display server a visualizer configured to update a block diagram including objects representing components in the propulsion system; a first socket configured to communicate with a second socket in a promotion server associated with a scan shape tool including a data extraction program, the data extraction program configured to generate and store translation tables, interlocking map tables, and object indexes configured to accelerate traversal algorithms configured to control the visualizer in the display server.

[0173] Clause 2. The machine of Clause 1, wherein the propulsion server is configured to design, verify, and validate at least one of the following: design, assembly, or integration of objects within a propulsion system.

[0174] Clause 3. The machine of Clause 1, wherein the block diagram is an executable block diagram of the propulsion system.

[0175] Clause 4. The machine of Clause 1, wherein the propulsion server includes a command handler configured to update a state of an object within the propulsion system.

[0176] Clause 5. The machine of Clause 1, wherein the propulsion server includes a propulsion piping evaluator configured to recursively update piping of the propulsion system.

[0177] Clause 6. The machine of clause 1, wherein a propulsion piping evaluator within the propulsion server includes the traversal algorithm.

[0178] Clause 7. The machine of Clause 1, wherein the forwarding server includes the traversal algorithm and is configured to access the translation table, the linking map table, and the object index configured to be input to the traversal algorithm.

[0179] Clause 8. The machine of Clause 1, wherein the promotion server includes an action log configured to record activity occurring in the block diagram.

[0180] Clause 9. The machine of Clause 1, wherein the propulsion server is configured to update at least one of an identity, a state, and a color of components of the propulsion system each represented in the block diagram by an object in the block diagram.

[0181] Appendix 10. The machine of Appendix 1, wherein the object includes a classification.

[0182] Clause 11. The machine of clause 1, wherein the object comprises a classification selected from the group consisting of an active object, a passive object, and a pipe.

[0183] Clause 12. The machine of clause 1, wherein the object includes a set of rules and a set of behaviors.

[0184] Clause 13. The machine of Clause 1, wherein the object includes a classification as an active object that includes at least one of the following states: on, off, pressure, composition, and product type.

[0185] Clause 14. A process for visualizing a propulsion system, comprising: generating a block diagram in a graphical user interface within a propulsion visualization machine that receives input for causing devices in the propulsion system to be displayed by a visualizer on the graphical user interface as objects in the block diagram; a display server including the graphical user interface passing the input to a propulsion piping evaluator in a propulsion server; a propulsion piping evaluator applying an algorithm in response to the input to evaluate flow or pressure within an object or piping within the propulsion system; the propulsion piping evaluator generating a traversal graph of equipment and piping in the propulsion system; the forwarding server executing a traversal algorithm and updating the state of objects in the block diagram by sending updates to a visualizer in the display server; the display server updating a display of the state of the object on the block diagram; the propulsion piping evaluator updates object color codes and piping color codes and sends the updates to the display server; the display server updating the display of the object color code and the piping color code on the block diagram.

[0186] Clause 15. The process of clause 14, further comprising the propulsion piping evaluator generating a composition or pressure within the propulsion system that traverses to a particular connection at a source object and is delivered through the connection to a destination object.

[0187] Appendix 16. Verifying whether a composition or pressure is received or not at the connection to the destination object; 15. The process of claim 14, further comprising: in response to the absence of a component, identifying individual connections at which an error occurred in receiving the composition or the pressure; and identifying the individual connections and specific virtual modules each connected to and including the individual connections.

[0188] Clause 17. The process of Clause 14, further comprising: the state of the device is selected from the group consisting of at least one of the following: on, off, pressure, composition, and product type.

[0189] Clause 18. The process of Clause 14, further comprising the propulsion server creating a traversal graph that tracks objects traversed within the block diagram during runtime visualization of the propulsion system.

[0190] Clause 19. The process of Clause 14, further comprising the propulsion server using traversal logic using states of active objects and behavior definitions of passive objects in the block diagram to create a traversal graph that tracks objects traversed within the block diagram during runtime visualization of the propulsion system.

[0191] Clause 20. The process of Clause 14, further comprising classifying objects in the block diagram as one of active objects, passive objects, and plumbing.

[0192] Appendix 21. The process of Appendix 14, further comprising: active objects comprising at least one of the following: an origin of a value of a property state of the block diagram; or an interactive object of the block diagram that triggers a change in state of a subordinate object in the propulsion system shown in the block diagram.

[0193] Clause 22. The process of Clause 14, further comprising the piping being any device that connects two objects of the propulsion system within the block diagram and transfers fluid or pressure from one object to a subordinate object within the block diagram.

[0194] Addendum 23. The process of Addendum 14, further comprising: the piping being any device that connects two objects of the propulsion system within the block diagram and communicates a value of one of the following from one object to a lower object within the block diagram: pressure, composition, or commodity type.

[0195] Clause 24. The process of Clause 14, further comprising recording activity on the block diagram during runtime in an action log.

[0196] Appendix 25. The process of Appendix 14, further comprising using an action log of activity on the block diagram during runtime to roll back actions of the propulsion system shown in the block diagram to a desired previous point in the runtime.

[0197] Clause 26. The process of Clause 14, further comprising establishing a new runtime starting state for the block diagram using an action log of activity on the block diagram during runtime.

[0198] Clause 27. The process of Clause 14, further comprising recording snapshots of the block diagram at runtime at selected times recording states of valves in the propulsion system shown in the block diagram.

[0199] Clause 28. The process of Clause 14, further comprising recording a snapshot of the block diagram at runtime at a selected time to record a state of a pressure regulator in the propulsion system shown in the block diagram.

[0200] Appendix 29. Accelerating the processing of the traversal algorithm through a data extraction program within the scanshape tool that creates a support file containing a translation table, an associated map table, and an object index; 15. The process of claim 14, further comprising: the traversal algorithm accessing the supporting file.

[0201] Clause 30. The process of Clause 14, further comprising receiving input to the promotion server from an external command and control system in communication with the promotion server to change the state of the object.

[0202] Addendum 31. The process of Addendum 14, further comprising the scan shape tool extracting essential elements of data attached to objects in the system diagram of the diagram vector graphics application and creating a conversion table, interlocking map table, and object index for access by the propulsion piping evaluator.

[0203] Addendum 32. The process of Addendum 14, further comprising creating a block diagram including a propulsion system stencil tailored to the objects, the stencil including data indicating component types, connections, and / or characteristics specific to each of the objects.

[0204] Annex 33. A process for visualizing a propulsion system, comprising: constructing a diagram of the propulsion system in a diagram and vector graphics application accessing respective stencils of objects to be placed on the diagram, the stencils including data associated with the objects and including component types, connections, and properties specific to the objects; Run a check error program against a scalar vector graphic file constructed by a diagram vector graphic application from the input, responsive to said scalar vector graphics file being free of errors, using a data extraction program to create the following from data associated with objects in said scalar vector graphics file: a translation table, an associated map table, and an object index; converting the system diagram into a scalar vector graphics file and loading the scalar vector graphics file into a scalar graphics application in a display server for displaying the block diagram; receiving input for causing the visualizer to display devices in the propulsion system as objects in the block diagram on a graphical user interface; the display server passes the input to a promotion server; In response to the input, the propulsion server applies an algorithm to evaluate piping within the propulsion system; a scan shape tool generating a list of equipment and piping within the propulsion system; the promotion server executing the traversal algorithm updates the state of the device within the promotion server and sends the updates to the display server; the display server updates the display of the state of the object on the block diagram; the promotion server updates the device color codes and the piping color codes and sends the updates to the display server; A process in which the display server updates the display of the equipment color codes and the piping color codes on the block diagram.

[0205] Clause 34. The process of clause 33, further comprising generating a fluid or pressure at the origin object that traverses to a particular connection and is sent through the connection to the destination.

[0206] Clause 35. Verifying whether fluid or pressure is received or not at said connection; 34. The process of claim 33, further comprising: in response to the absence of the composition or the pressure, identifying the individual connections at which an error occurred in receiving the composition or the pressure; and identifying the individual connections and specific objects each connected to and including the individual connections.

[0207] Clause 36. The process of Clause 33, further comprising: the state of the object being selected from the group comprising at least one of the following: on, off, pressure, composition, and product type.

[0208] Clause 37. The process of Clause 33, further comprising the propulsion server creating a traversal graph that tracks objects traversed within the block diagram during runtime visualization of the propulsion system.

[0209] Clause 38. The process of Clause 33, further comprising the propulsion server using traversal logic using states of active objects and behavior definitions of passive objects in the block diagram to create a graph that tracks objects traversed within the block diagram during runtime visualization of the propulsion system.

[0210] Clause 39. The process of Clause 33, further comprising classifying objects in the block diagram as one of the following: active objects, passive objects, and plumbing.

[0211] Appendix 40. The process of Appendix 33, further comprising: active objects comprising at least one of the following: an origin of a value of a property state of the block diagram; or an interactive object of the block diagram that triggers a change in state of a subordinate object in the propulsion system shown in the block diagram.

[0212] Addendum 41. The process of Addendum 33, further comprising the piping being any device that connects two objects of the propulsion system within the block diagram and transfers fluid or pressure from one object to a subordinate object within the block diagram.

[0213] Addendum 42. The process of Addendum 33, further comprising: the piping being any device that connects two objects of the propulsion system within the block diagram and communicates a value of one of the following from one object to a lower object within the block diagram: pressure, composition, or commodity type.

[0214] Clause 43. The process of Clause 33, further comprising recording activity on the block diagram during runtime in an action log.

[0215] Clause 44. The process of Clause 33, further comprising using an action log of activity on the block diagram during runtime to roll back actions of the propulsion system shown in the block diagram to a desired previous point in the runtime.

[0216] Addendum 45. The process of Addendum 33, further comprising establishing a new runtime starting state for the block diagram using an action log of activity on the block diagram during runtime.

[0217] Clause 46. The process of clause 33, further comprising recording snapshots of the block diagram at runtime at selected times recording states of valves in the propulsion system shown in the block diagram.

[0218] Clause 47. The process of Clause 33, further comprising recording a snapshot of the block diagram at runtime at a selected time to record a state of a pressure regulator in the propulsion system shown in the block diagram.

[0219] Appendix 48. Accelerating the processing of the traversal algorithm through a data extraction program within the scanshape tool that creates a support file containing a translation table, an associated map table, and an object index; 34. The process of claim 33, further comprising: the traversal algorithm accessing the supporting file.

[0220] Clause 49. The process of Clause 33, further comprising receiving input to the promotion server from an external command and control system in communication with the promotion server to change the state of the device.

[0221] Addendum 50. The process of Addendum 33, further comprising the scan shape tool extracting essential elements of data attached to objects in a system diagram of a diagram vector graphics application to create the following: a conversion table, an interlocking map table, and an object index for access by a fluid piping evaluator.

[0222] Addendum 51. The process of Addendum 33, further comprising creating a block diagram including respective tailored propulsion system stencils, the stencils including object data including data indicating component types, connections, and / or characteristics specific to each of the objects.

[0223] Clause 52. A machine containing a display server, The display server a visualizer configured to update a block diagram including objects representing devices in a fluid system; a first socket configured to communicate with a second socket in a fluid server associated with a scan shape tool including a data extraction program, the data extraction program configured to generate and store translation tables, linkage map tables, and object indexes configured to accelerate a traversal algorithm configured to control a visualizer in the display server.

[0224] Clause 53. The machine of Clause 52, wherein the fluid server is configured to design, verify, and validate at least one of the following: design, assembly, or integration of an object within a fluid system.

[0225] Clause 54. The machine of Clause 52, wherein the block diagram is an executable block diagram of the fluid system.

[0226] Clause 55. The machine of Clause 52, wherein the fluid server includes a command handler configured to update a state of an object in the fluid system.

[0227] Clause 56. The machine of Clause 52, wherein the fluid server includes a fluid piping evaluator configured to recursively update piping of the fluid system.

[0228] Clause 57. The machine of clause 52, wherein a fluid piping evaluator includes the traversal algorithm.

[0229] 58. The machine of claim 52, wherein the fluid server includes the traversal algorithm and is configured to access the translation table, the linkage map table, and the object index configured to be input to the traversal algorithm.

[0230] Clause 59. The machine of Clause 52, wherein the fluid server includes an action log configured to record activity occurring in the block diagram.

[0231] Addendum 60. The machine of Addendum 52, wherein the fluid server is configured to update at least one of the identity, status, and color of components of the fluid system each represented in the block diagram by an object in the block diagram.

[0232] Addendum 61. The object is an active object that includes at least one of the following states: on, off, pressure, composition, and product type; Passive objects and 53. The machine of claim 52, comprising a classification selected from the group consisting of: piping;

[0233] Clause 62. The machine of Clause 52, wherein the object includes a set of rules and a set of behaviors.

[0234] Clause 63. A process for visualizing a fluid system, comprising: constructing a diagram of the fluid system in a diagram and vector graphics application accessing respective stencils of objects to be placed on the diagram, the stencils including data associated with the objects and including component types, connections, and properties specific to the objects; Run a check error program against a scalar vector graphic file constructed by a diagram vector graphic application from the input, creating a support file in response to the scalar vector graphics file being free of errors; converting the system diagram into a scalar vector graphics file and loading the scalar vector graphics file into a scalar graphics application in a display server for displaying the block diagram; receiving input for causing the visualizer to display devices in the fluid system as objects in the block diagram on a graphical user interface; the display server passes the input to a fluid server; In response to the input, the fluid server applies an algorithm to evaluate piping within the fluid system; a scan shape tool generating a list of devices and piping within the fluid system; the fluid server running the traversal algorithm updates the state of the device within the fluid server and sends the updates to the display server; the display server updates the display of the state of the object on the block diagram; the fluid server updates the device color code and the piping color code and sends the updates to the display server; A process in which the display server updates the display of the equipment color codes and the piping color codes on the block diagram.

[0235] Clause 64. The process of clause 63, further comprising generating a fluid or pressure at the origin object that traverses to a particular connection and is sent through the connection to the destination.

[0236] Clause 65. Verifying whether fluid or pressure is received or not at said connection; 64. The process of claim 63, further comprising: in response to the absence, identifying individual connections at which errors in receiving fluid or the pressure occurred; and identifying the individual connections and specific objects each connected to and containing the individual connections.

[0237] Clause 66. The process of Clause 63, further comprising: the state of the object being selected from the group comprising at least one of the following: on, off, pressure, composition, and product type.

[0238] Addendum 67. The process of Addendum 63, further comprising the fluid server creating a traversal graph that tracks objects traversed within the block diagram during runtime visualization of the fluid system.

[0239] Addendum 68. The process of Addendum 63, further comprising the fluid server using traversal logic using states of active objects and behavior definitions of passive objects in the block diagram to create a graph that tracks objects traversed within the block diagram during runtime visualization of the fluid system.

[0240] Addendum 69. The process of Addendum 63, further comprising classifying objects in the block diagram as one of the following: active objects, passive objects, and piping.

[0241] Addendum 70. The process of Addendum 63, further comprising: active objects comprising at least one of the following: an origin of a property state value in the block diagram; or an interactive object in the block diagram that triggers a change in state of a subordinate object in the fluid system depicted in the block diagram.

[0242] Addendum 71. The process of Addendum 63, further comprising the piping being any device that connects two objects of the fluid system within the block diagram and transmits fluid or pressure from one object to a subordinate object within the block diagram.

[0243] Addendum 72. The process of Addendum 63, further comprising: the piping being any device that connects two objects of the fluid system within the block diagram and transmits a value of one of the following from one object to a lower object within the block diagram: pressure, composition, or commodity type.

[0244] Clause 73. The process of Clause 63, further comprising recording activity on the block diagram during runtime in an action log.

[0245] Addendum 74. The process of Addendum 63, further comprising using an action log of activity on the block diagram during runtime to roll back actions of the fluid system shown in the block diagram to a desired previous point in the runtime.

[0246] Addendum 75. The process of Addendum 63, further comprising establishing a new runtime starting state for the block diagram using an action log of activity on the block diagram during runtime.

[0247] Clause 76. The process of Clause 63, further comprising, at runtime, recording snapshots of the block diagram at selected times to record states of valves in the fluid system depicted in the block diagram.

[0248] Clause 77. The process of Clause 63, further comprising, at runtime, recording snapshots of the block diagram at selected times to record the state of a pressure regulator in the fluid system depicted in the block diagram.

[0249] Addendum 78. Accelerating the processing of the traversal algorithm through a data extraction program within the scanshape tool that creates a support file containing a transformation table, an associated map table, and an object index from the object data in the scalar vector graphics file; 64. The process of claim 63, further comprising: the traversal algorithm accessing the supporting file.

[0250] Addendum 79. The process of Addendum 63, further comprising receiving input to the fluid server from an external command and control system in communication with the fluid server to change the state of the device.

[0251] Addendum 80. The process of Addendum 63, further comprising the scan shape tool extracting essential elements of data attached to objects in the system diagram of the diagram and vector graphics application to create the following: a conversion table, an interlocking map table, and an object index for access by a fluid piping evaluator.

[0252] Addendum 81. The process of Addendum 63, further comprising creating a block diagram including a fluid system stencil tailored to each of the objects, the stencil including object data including data indicating component types, connections, and / or properties specific to each of the objects.

[0253] CLAUSE 82. A process for visualizing a fluid system, comprising: generating a block diagram in a graphical user interface within the fluid visualization machine that receives input for causing devices in the fluid system to be displayed by a visualizer on the graphical user interface as objects in the block diagram; a display server including the graphical user interface passing the input to a fluid piping evaluator in a fluid server; the fluid piping evaluator applying an algorithm in response to the input to evaluate flow or pressure in an object or piping in the fluid system; the fluid piping evaluator generating a traversal graph of devices and piping in the fluid system; the fluid server executing a traversal algorithm and updating the state of objects in the block diagram by sending updates to a visualizer in the display server; the display server updating a display of the state of the object on the block diagram; the fluid piping evaluator updating object color codes and piping color codes and sending the updates to the display server; the display server updating the display of the object color code and the piping color code on the block diagram.

[0254] Clause 83. The process of clause 82, further comprising the fluid piping evaluator generating a composition or pressure within the fluid system that traverses to a particular connection at a source object and is delivered through the connection to a destination object.

[0255] CLAUSE 84. Verifying whether fluid or pressure is received or not at the connection to the destination object; 83. The process of claim 82, further comprising: in response to the absence of a connection, identifying the individual connection at which an error occurred in receiving the fluid or pressure; and identifying the individual connection and specific virtual modules each connected to and including the individual connection.

[0256] Clause 85. The process of Clause 82, further comprising: the state of the device is selected from the group consisting of at least one of the following: on, off, pressure, composition, and product type.

[0257] Addendum 86. The process of Addendum 82, further comprising the fluid server creating a traversal graph that tracks objects traversed within the block diagram during runtime visualization of the fluid system.

[0258] Addendum 87. The process of Addendum 82, further comprising the fluid server using traversal logic using states of active objects and behavior definitions of passive objects in the block diagram to create a traversal graph that tracks objects traversed within the block diagram during runtime visualization of the fluid system.

[0259] Clause 88. The process of Clause 82, further comprising classifying objects in the block diagram as one of active objects, passive objects, and plumbing.

[0260] Addendum 89. The process of Addendum 82, further comprising: active objects comprising at least one of the following: an origin of a value of a property state of the block diagram; or an interactive object of the block diagram that triggers a change in state of a subordinate object in the fluid system depicted in the block diagram.

[0261] Addendum 90. The process of Addendum 82, further comprising the piping being any device that connects two objects of the fluid system within the block diagram and transmits fluid or pressure from one object to a subordinate object within the block diagram.

[0262] Addendum 91. The process of Addendum 82, further comprising: the piping being any device that connects two objects of the fluid system within the block diagram and transmits a value of one of the following from one object to a lower object within the block diagram: pressure, composition, or product type.

[0263] Clause 92. The process of Clause 82, further comprising recording activity on the block diagram during runtime in an action log.

[0264] Addendum 93. The process of Addendum 82, further comprising using an action log of activity on the block diagram during runtime to roll back actions of the fluid system shown in the block diagram to a desired previous point in the runtime.

[0265] Addendum 94. The process of Addendum 82, further comprising establishing a new runtime starting state for the block diagram using an action log of activity on the block diagram during runtime.

[0266] Clause 95. The process of clause 82, further comprising recording a snapshot of the block diagram at runtime at selected times recording the states of valves in the propulsion system depicted in the block diagram.

[0267] Clause 96. The process of clause 82, further comprising recording a snapshot of the block diagram at runtime at a selected time to record a state of a pressure regulator in the propulsion system shown in the block diagram.

[0268] Addendum 97. Accelerating the processing of the traversal algorithm through a data extraction program within the scanshape tool that creates a support file containing a transformation table, an associated map table, and an object index from the object data in the scalar vector graphics file; 83. The process of claim 82, further comprising the traversal algorithm accessing the supporting file.

[0269] Addendum 98. The process of Addendum 82, further comprising receiving input to the fluid server from an external command and control system in communication with the fluid server to change the state of the object.

[0270] Addendum 99. The process of Addendum 82, further comprising the scan shape tool extracting essential elements of data attached to objects in a system diagram of the diagram vector graphics application and creating conversion tables, linkage map tables, and object indexes accessed by the fluid piping evaluator.

[0271] Addendum 100. The process of Addendum 82, further comprising creating a block diagram including a fluid system stencil tailored to the objects, the stencil including data indicating component types, connections, and / or characteristics specific to each of the objects.

[0272] The description of the various exemplary embodiments has been presented for purposes of illustration and description and is not intended to be exhaustive or to limit the embodiments to the form disclosed. Many modifications or variations will be apparent to those skilled in the art. Furthermore, various exemplary embodiments may provide different features than other exemplary embodiments. The foregoing embodiments were chosen and described to best explain the principles and practical applications of the embodiments and to enable those skilled in the art to understand the disclosure for the various embodiments with various modifications suited to the particular applications envisioned.

Claims

1. A machine containing a display server, The display server a visualizer configured to update a block diagram including objects representing devices in a fluid system; a first socket configured to communicate with a second socket in a fluid server associated with a scan shape tool including a data extraction program, the data extraction program configured to generate and store translation tables, interlocking map tables, and object tables configured to accelerate a traversal algorithm configured to control the visualizer in the display server.

2. The machine of claim 1 , wherein the fluid server is configured to design, verify, and validate at least one of the following: design, assembly, or integration of objects in the fluid system.

3. The machine of claim 1 , wherein the block diagram is an executable block diagram of the fluid system.

4. The machine of claim 1 , wherein the fluid server includes a command handler configured to update states of objects representing devices in the fluid system.

5. The machine of claim 1 , wherein the fluid server includes a fluid piping evaluator configured to recursively update piping of a fluid system.

6. The machine described in claim 5, wherein the fluid piping evaluator includes the traversal algorithm.

7. 2. The machine of claim 1, wherein the fluid server includes the traversal algorithm and is configured to access the translation table, the linkage map table, and the object table configured to be input to the traversal algorithm.

8. The machine of claim 1 , wherein the fluid server includes an action log configured to record all activity occurring in the block diagram.

9. 2. The machine of claim 1, wherein the fluid server is configured to update at least one of an identification, a status, and a color of each component of the fluid system represented in the block diagram by an object in the block diagram.

10. The object is an active object that includes at least one of the following states: on, off, pressure, composition, and product type; Passive objects and 10. The machine of claim 1, comprising a classification selected from the group consisting of: piping.

11. The machine of claim 1 , wherein the object comprises a set of rules and a set of behaviors.

12. 1. A process for visualizing a fluid system, comprising: generating a block diagram in a graphical user interface within the fluid visualization machine that receives input for displaying devices in the fluid system by a visualizer on the graphical user interface as objects in the block diagram; a display server including the graphical user interface passing the input to a fluid piping evaluator in a fluid server; In response to the input, the fluid pipe evaluator applies a traversal algorithm to evaluate flow or pressure within the object or pipe in the fluid system; the fluid piping evaluator generating a traversal graph of all devices and piping in the fluid system; the fluid server executing the traversal algorithm and updating the state of each object in the block diagram by sending updates to the visualizer in the display server; the display server updating a display of the state of the object on the block diagram; the fluid piping evaluator updating object color codes and piping color codes and sending the updates to the display server; the display server updating the display of the object color code and the piping color code on the block diagram.

13. The process of claim 12 , further comprising the fluid piping evaluator generating a composition or pressure within the fluid system that traverses to a particular connection at a source object and is delivered through the connection to a destination object.

14. Verifying whether fluid or pressure is received or not at the connection to the destination object; 13. The process of claim 12, further comprising: in response to the absence, identifying the individual connection at which an error occurred in receiving the fluid or the pressure; and identifying the individual connection and specific virtual modules each connected to and including the individual connection.

15. 13. The process of claim 12, further comprising: the device state being selected from the group comprising at least one of the following: on, off, pressure, composition, and product type.

16. The process of claim 12 , further comprising the fluid server creating a traversal graph that tracks all objects traversed within the block diagram during runtime visualization of the fluid system.

17. The process of claim 12, further comprising the fluid server using traversal logic using states of active objects and behavior definitions of passive objects in the block diagram to create the traversal graph that tracks all objects traversed in the block diagram during runtime visualization of the fluid system.

18. The process of claim 12 , further comprising classifying each object in the block diagram as one of an active object, a passive object, and a plumbing.

19. The process of claim 12, further comprising: active objects comprising at least one of the following: a source of a value for a property state of the block diagram; or an interactive object of the block diagram that triggers a change in the state of a subordinate object in the fluid system depicted in the block diagram.

20. The process of claim 12 , further comprising the piping being any device that connects two objects of the fluid system within the block diagram and transmits fluid or pressure from one object to a subordinate object within the block diagram.

21. 13. The process of claim 12, further comprising: the piping being any device that connects two objects of the fluid system within the block diagram and transmits a value of one of the following from one object to a lower object within the block diagram: pressure, composition, or product type.

22. The process of claim 12 further comprising recording all activity on the block diagram during runtime in an action log.

23. The process of claim 12 , further comprising: rolling back actions of the fluid system shown in the block diagram to a desired previous point in the runtime using an action log of all activity on the block diagram during runtime.

24. The process of claim 12 , further comprising establishing a new runtime starting state for the block diagram using an action log of all activity on the block diagram during runtime.

25. 13. The process of claim 12, further comprising recording a snapshot of the block diagram at runtime at a selected time that records the state of all valves in the propulsion system shown in the block diagram.

26. 13. The process of claim 12, further comprising recording a snapshot of the block diagram at runtime at selected times that records the status of all pressure regulators in the propulsion system shown in the block diagram.

27. Accelerating the processing of the traversal algorithm through a data extraction program within the scanshape tool that creates a support file containing a transformation table, an associated map table, and an object table from the data for each object in the scalar vector graphics file; The process of claim 12 , wherein the traversal algorithm further comprises accessing the supporting file.

28. The process of claim 12 , further comprising receiving input to the fluid server to change the state of the object from an external command and control system in communication with the fluid server.

29. 13. The process of claim 12, further comprising a scan shape tool extracting essential elements of data attached to each object in a system diagram of a diagram vector graphics application to create a conversion table, an interlocking map table, and an object table for access by the fluid piping evaluator.

30. The process of claim 12, further comprising creating a block diagram including a fluid system stencil tailored to each of the objects, the stencil including data indicating component types, connections, and / or properties specific to each of the objects.

Images