Matrix verification for system requirements

Abstract

This disclosure provides a framework that integrates a simulation model and algorithm for determining whether system requirements are met across multiparameter scenarios in a complex system. The complex system may include, for example, a life support system, thermal control system, nuclear power system, control system for vehicle dynamics, telecommunications system, finance system, chemical refining system, or propulsion system. A graphical display such as a scenario result matrix may visually represent compliance / non-compliance for each criterion for each multiparameter scenario. In some implementations, perturbations such as noise or load deviations may be introduced to special scenarios, and stability assessments may be verified for each of the special scenarios in the complex system.

Description

MATRIX VERIFICATION FOR SYSTEM REQUIREMENTSINCORPORATION BY REFERENCE

[0001] A PCT Request Form is filed concurrently with this specification as part of the present application. Each application that the present application claims benefit of or priority to as identified in the concurrently filed PCT Request Form is incorporated by reference herein in its entirety and for all purposes.TECHNICAL FIELD

[0002] This disclosure relates computational models for simulating multiparameter scenarios, and more particularly to computational models for simulating multiparameter scenarios and automated system requirement verification.BACKGROUND

[0003] Many complex systems such as an environmental control and life support system (ECLSS) may involve multiple process variables. ECLSS is a system that provides a habitable environment for humans and ensures a comfortable, life- sustaining environment, which can be applicable in space or in terrestrial environments. System components such as an air revitalization system (ARS) may be designed to provide a habitable environment with a tightly coupled multiple-input multiple-output system, where various components such as an actuator can impact one or more process variables. The ARS may control parameters such as temperature, humidity, carbon dioxide concentration, and trace contaminant concentration. Other parameters for control can include oxygen concentration and absolute pressure, which can be critical to spacecraft life support and life support in general. Additionally, the ARS can support other modes such as cabin depressurization and fire recovery. The complex system may be a complex technical system configured to be assessed in a binary or quantitative manner. Examples of complex systems involving multiple process variables include thermal control systems, nuclear power systems, and dynamic vehicle control systems, telecommunications systems, finance systems, chemical refining systems, propulsion systems, among other possible systems.

[0004] Computational models and simulations can be developed to study behaviors, interactions, characteristics, performance, and other criteria in a system using mathematics, physics, and computer science. Computational models can be leveraged to gain an understanding of a complex system involving multiple parameters and variables.Computational models can accurately predict system outcomes obviating the need to conduct hundreds or thousands of experiments. Computational models and simulations are used in a variety of industries including but not limited to weather forecasting, flight simulators, earthquake simulations, chemical reactions, infectious disease tracking, clinical decision support, drug side effects, engineering models such as finite element analysis, and molecular protein folding. Complex systems, including tightly-coupled multiple-input multiple-output systems like an ECLSS, can be described using physics-based models and control algorithms.

[0005] The background description provided herein is for the purpose of generally presenting the context of the present technology. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present technology.SUMMARY

[0006] The systems, methods and devices of this disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

[0007] One innovative aspect of the subject matter described in this disclosure can be implemented in a method of verifying system requirements against a plurality of scenarios. The method includes generating, in a computing device, a plurality of scenarios that are defined within an operating envelope, where each scenario comprises multiple parameters for monitoring, generating, in the computing device, data associated with each scenario using a simulation model and control algorithm, where the data tracks one of the parameters over a duration of time, and determining, using the computing device, whether system requirements are met for each of the parameters for each of the plurality of scenarios.

[0008] In some implementations, the method further includes presenting a graphical display that shows a performance of each of the plurality of scenarios against the system requirements. In some implementations, the graphical display comprises a scenario result matrix, where each cell of the scenario result matrix shows whether one of the parameters meets the system requirements for one of the corresponding scenarios. In some implementations, the method further includes iterating on designs associated with one or more of the simulation model, the control algorithm, and the operating envelope to improve on the performance of each of the plurality of scenarios against the system requirements. In some implementations, the method further includes generating cross-scenario statistics using the data for the plurality of scenarios.In some implementations, the operating envelope is used as simulation inputs for the simulation model and control algorithm to generate the data. In some implementations, generating the data associated with each scenario using the simulation model and control algorithm includes running each scenario in parallel using the simulation model and control algorithm. The system requirements may be associated with system requirements for complex technical systems configured to be assessed in a binary or quantitative manner. In some implementations, the system requirements include system requirements associated with life support system requirements in a spacecraft. In some implementations, the multiple parameters for monitoring comprise two or more of the following: relative humidity, cabin temperature, cabin pressure, cabin dewpoint, CO2 concentration, trace contaminant concentrations, vacuum isolation valve position, fan speed, heat transfer, ammonia flow rate, water generation rate, and water removal rate. In some implementations, the system requirements include system requirements associated with dynamic vehicle control systems. In some implementations, the system requirements include system requirements associated with nuclear power system requirements. In some implementations, the system requirements include system requirements associated with thermal control systems. In some implementations, the system requirements include system requirements associated with telecommunications systems. In some implementations, the system requirements include system requirements associated with finance systems. In some implementations, the system requirements include system requirements associated with chemical refining systems. In some implementations, the system requirements include system requirements associated with propulsion systems. In some implementations, the method further includes generating, in the computing device, one or more perturbation scenarios that are defined outside the operating envelope, generating, in the computing device, additional data associated with each perturbation scenario using the simulation model and control algorithm, and determining a stability assessment for each of the perturbation scenarios that are defined outside the operating envelope. In some implementations, determining the stability assessment is accomplished using a time domain stability margin assessment technique. In some implementations, determining the stability assessment is accomplished using a frequency domain stability margin assessment technique. In some implementations, determining the stability assessment is accomplished using Monte Carlo analysis.

[0009] Another innovative aspect of the subject matter described in this disclosure can be implemented in a method of verifying system requirements against a plurality of scenarios. The method includes generating, in a computing device, a plurality of scenarios that are defined within an operating envelope, determining whether system requirements are met for each ofthe plurality of scenarios, and presenting a graphical display that shows a performance of each of the plurality of scenarios against the system requirements in a scenario result matrix.

[0010] In some implementations, each cell of the scenario result matrix shows whether one of the parameters meets the system requirements for one of the corresponding scenarios. In some implementations, the system requirements include system requirements associated with life support system requirements in a spacecraft.

[0011] Another innovative aspect of the subject matter described in this disclosure can be implemented in a method of assessing stability against one or more perturbation scenarios. The method includes generating, in a computing device, a plurality of perturbation scenarios that are defined outside an operating envelope, where each perturbation scenario comprises multiple parameters for monitoring, generating, in the computing device, data associated with each perturbation scenario using a simulation model and control algorithm, where the data tracks one of the parameters over a duration of time, and determining, using the computing device, a stability assessment for each of the perturbation scenarios that are defined outside the operating envelope.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 shows a schematic diagram of various flow paths in an example air revitalization system used for environmental control and life support systems according to some implementations.

[0013] Figure 2 shows a schematic block diagram of individual components in the example air revitalization system of Figure 1 used in a model according to some implementations, where each of the individual components has a thermodynamic process associated with it.

[0014] Figure 3 shows a simplified block diagram of major control features with control algorithms in an example air revitalization system according to some implementations.

[0015] Figure 4A shows a block diagram of an example framework that determines whether system requirements are met for a plurality of scenarios according to some implementations.

[0016] Figure 4B shows a flow diagram of an example method of verifying system requirements against a plurality of scenarios according to some implementations.

[0017] Figure 4C shows a flow diagram of an example method of assessing stability against one or more perturbation scenarios according to some implementations.

[0018] Figure 5 shows an example scenario result matrix that illustrates whether certain system requirements are met for each scenario according to some implementations.

[0019] Figures 6A-6F show data logs for monitored parameters obtained from a simulation model and control algorithm, tracking relative humidity in Figure 6A, tracking a vacuum isolation valve position in Figure 6B, tracking temperature in Figure 6C, tracking heat transfer in Figure 6D, tracking fan speed in Figure 6E, and tracking a position of a three-way proportioning valve and air scrub damper.

[0020] Figures 7A-7C show data logs for temperature obtained from a simulation model and control algorithm where perturbation gains of (1 / 2)X in Figure 7A, IX in Figure 7B, and 2X in Figure 7C were assessed using a time domain stability assessment technique.DETAILED DESCRIPTION

[0021] In a complex system such as a life support system in a space flight program, there will be a number of system requirements that must be met. By way of an example, designing and manufacturing an air revitalization system may impose several high-level requirements. Such requirements may include, for example, (1) providing cabin thermal control, (2) providing cabin humidity control, (3) limiting trace contaminant concentration within the cabin to acceptable levels, (4) limiting CO2 concentration within the cabin to acceptable levels, (5) providing cabin fire detection by ensuring a minimal level of ventilation alongside smokedetecting sensors. In other words, the life support system is designed to operate within the system requirements so that the design complies with a range of temperatures, relative humidity, acceptable CO2 levels, acceptable trace contaminant levels, etc. Designing a life support system that meets these system requirements introduces cross-coupled multi-parameter problems that are challenging to assess. Systems that run into such complex multi-parameter problems are not only limited to life support systems. Other systems may include thermal control systems, nuclear power systems, and dynamic vehicle control systems, telecommunications systems, finance systems, chemical refining systems, propulsion systems, among other systems that need to be designed and optimized to meet a given set of system requirements. Such systems are generally complex technical systems configured to be assessed in a binary or quantitative manner.

[0022] Historically, designing and manufacturing a system to meet specific system requirements have been limited by a lack of computing power. In the past, experimentation and real-world testing conducted one or a handful of cases (e.g., worse-case scenarios) to design systems that operate within a given set of system requirements. However, with increased computing power, it is advantageous to characterize an entire operating enveloperather than one or a handful of cases. This can be accomplished with automation using computational models and algorithms that simulate possible scenarios.

[0023] Returning to an example of a life support system that may include an air revitalization system, system requirements may impose acceptable measurements or levels of temperature, humidity, trace contaminants, CO2, etc. These measurements in an environment may be impacted by adjusting operational controls such as changing vent speeds in a fan, changing an angle on one or more dampers, or controlling some other component in the system. In one example, obtaining colder temperatures in an environment may be achieved by increasing air flow through a heat exchanger. In another example, reducing CO2 concentration may be achieved by increasing air flow through a CO2 control assembly.

[0024] Figure 1 shows a schematic diagram of various flow paths in an example air revitalization system used for environmental control and life support systems according to some implementations. As shown in Figure 1, the air revitalization system may include one or more actuators. These actuators may include a first vacuum valve assembly (VVA1), a second vacuum valve assembly (VVA2), a three-way proportioning valve (TWPV), a fan assembly (FA), and an air scrub damper (ASD). The fan assembly FA may serve as a primary determinant for overall air flow to a heat exchanger. In some cases, multiple fans may be used so that fans may be cycled to distribute wear across the fans. The air scrub damper ASD may serve as a flow damper that controls a proportion of flow diverted to consumables branch. The three-way proportioning valve TWPV may serve as a coolant flow control valve, which can be used to reduce coolant flow to the heat exchanger and reduce the heat exchanger efficiency. The vacuum valve assemblies VVA1, VVA2 may serve as a pair of isolation valves used to gate vacuum access for one or more humidity control assemblies HCA1, HCA2, essentially turning them “on” or “off.” Air flow may be circulated through a ventilation system (VS) of a cabin. Air flow may pass through an ammonia filter, a consumables bypass branch, trace contaminant control assembly, CO2 control assembly, one or more humidity control assemblies, air scrub damper, fan assembly, and heat exchanger. Moisture (water vapor) may flow from one or more humidity control assemblies via vacuum valve assemblies to an external vent. Coolant may flow between a heat exchanger and a coolant supply / return via the three- way proportioning valve.

[0025] A description of system performance for a system such as one shown in Figure 1 may require information from multiple sources. For modeling the air revitalization system in Figure 1, a description of system performance may require information from multiple physics domains including pipe flow networks, air psychometrics, heat transfer, and chemistry. Rather thancreating a unified set of boundary conditions or running longer integrated transient simulations with disparate component models, a computational model may be developed to provide a modeling solution for the air revitalization system or other complex system.

[0026] A computational model may be utilized to solve a complex modeling problem such as presented in the air revitalization system of Figure 1. The computational model may be configured to solve a complex flow network such as presented in the air revitalization system of Figure 1. The computational model may include a physics or physical model that is configured to perform first-principle transient performance assessments of the air revitalization system. The computational model describes the integrated performance of the air revitalization system within the life support system. The computational model may include various submodels, such as sub-models for humidity control and heat exchanger performance. In some embodiments, the computational model may be configured to solve a complex flow network using an iterative flow network solver.

[0027] In some embodiments, the computational model may be integrated with other models. In some embodiments, the computational model may support modular components. In some embodiments, the computational model may support configuration-driven physical and control behavior. In some embodiments, the computational model may support automated requirement checking, which may include time-varying requirements. In some embodiments, the computational model may complete simulations at a relatively fast speed, where a 24-hour simulation can be completed in 1 hour or less. This can be done at a sufficient fidelity without degrading requirement compliance. In some embodiments, the computational model may be scalable to support configurable, multiprocessor or multimachine execution or hundreds or thousands of scenarios simultaneously. In some embodiments, the computational model supports automated testing for components and assemblies of components to enforce similarity to ground-truth data (e.g., CFD modeling results). Some of the advantages of the computational model may include its simplicity of use and low cost.

[0028] The computational model may make one or more high-level assumptions. For example, the computational model for the air revitalization system can make an assumption that the flow through the air revitalization system and other supplementary flow circuits (e.g., a coolant line network) is primarily governed by low-speed compressible 1-D flow relations. In another example, the computational model for the air revitalization system can make an assumption about fluid compressibility to simplify calculations and improve execution time. Components within the air revitalization system may be modeled as individual thermodynamic processes, which modify one or more fluid states. In this case, the computational model can use pressure,temperature, and specific humidity to define the fluid state, as well as the mass flow rate of air to define the scale of the system (e.g., to translate from mass-specific properties to physical masses).

[0029] Figure 2 shows a schematic block diagram of individual components in the example air revitalization system of Figure 1 used in a flow model according to some implementations, where each of the individual components has a thermodynamic process associated with it. Figure 2 may illustrate only major components of the air revitalization system, divided according to type or working fluid. The flow model may use loss characteristics for various components (bends, branches, filters, trace contaminant control assembly, humidity control assembly, etc.) to determine flow rates and pressure drops. Wherever appropriate, computational fluid dynamics results are used to capture both friction and minor losses as a single loss coefficient or characteristics as a function of Reynolds number. Elsewhere, such as in the CO2 control assembly, loss characteristics may be defined by a loss coefficient K and the major frictional losses of the system. Internal, non-compressible frictional losses may be functions of length, relative roughness of the tube / duct, and diameter of the tube / duct. For a given branch of the system with known loss coefficients, geometry, and friction factors, a pressure loss may be calculated according to the following formula: AP = 0.5pV2(EK + f(L / Dh)), where, through a given branch, p is the density of the flow, V is the velocity of the flow, XK is the summation of minor losses in each branch, f is the friction factor of the tube / duct, L is the length of the tube / duct, and D is the hydraulic diameter of the tube / duct.

[0030] In some embodiments, the computational model is configured to tune and test a control algorithm. Complex systems are generally characterized by interconnected components. By way of the example in the air revitalization system, thermal control can require coordinating both the fan assembly and three-way proportioning valve to effect overall heat removal at the heat exchanger. The air scrub damper may be used to control humidity, CO2, and trace contaminants simultaneously, but these loads do not necessarily track each other. Movement of the air scrub damper can impact overall system flow rate, and therefore heat removal at the heat exchanger. Actuation of the vacuum valve assemblies can impact downstream humidity and also impact heat removal at the heat exchanger. In fact, any actuator in the air revitalization system can impact nearly every process variable of interest.

[0031] Other controls design challenges may involve limitations of components. For instance, a humidity control assembly may be limited in terms of its size and capacity. During crew exercise, for example, humidity may increase uncontrolled but may be limited but the duration of exercise and humidity capacity in the cabin volume. The humidity control assembly mayhave to nominally tolerate extended durations of insufficient control authority, but quickly readapt once humidity loads return to normal. Additionally, the air revitalization system may be required to support contingency operations for CO2 removal in the event that other components, modules, or vehicles fail to work properly. The CO2 control assembly may include lithium hydroxide (LiOH), but lithium hydroxide may generate additional heat and humidity loads. Humidity and flow rate through the CO2 control assembly may be optimized to a tight band to ensure optimal CO2 removal efficiency, and the tight band may be sufficiently tight that a discrete control solution may be required for humidity requiring vacuum isolation valve alternation.

[0032] Control algorithms are employed to command and / or control components in a system such as the air revitalization system. Using the input that the control algorithm is commanding, the computational model simulates the effect or impact that is made on parameters such as cabin temperature, cabin pressure, relative humidity, etc. This feeds back into the system so that a prediction can be made about what the cabin environment is like, and a determination can be made regarding whether certain system requirements are met. Selected system requirements may include, for example: (i) keeping relative humidity between 25% and 75%, (ii) keeping cabin dewpoint below 10°C (or below 13 °C during exercise), (iii) prevent or limit condensation in the cabin and within the air revitalization system, which may require humidities well below the 75% relative humidity limit, (iv) maintain a cabin temperature between 20°C and 27 °C when crewed (and down to °C acceptable when uncrewed), (v) maintain an overall system flow rate for smoke detection, (vi) maintain flow rates for ammonia filter, trace contaminant control assembly, and CO2 control assembly within acceptable bounds, (vii) maintain relative humidity above 38% if a CO2 control assembly is installed, (viii) minimize actuator actuations such that estimated lifespan for each actuator exceeds a desired lifespan.

[0033] In some embodiments, the control algorithm may be used to control one or more proportional-integral-derivative (PID) controllers. In some implementations, a first PID controller controls the air scrub damper based on cabin dewpoint. In some implementations, a second PID controller controls one or both of the three-way proportioning valve and the fan assembly based on temperature. The control algorithm may drive the fan speed to a certain setpoint and / or may drive the three-way proportioning valve to a certain setpoint depending on the output of the PID controller.

[0034] In some embodiments, the control algorithm may be used to control one or more vacuum isolation valves. The control algorithm may be employed to open or close vacuumisolation valves to control humidity and maintain temperature controls. The control algorithm may use conditional logic based on multiple factors to decide how many vacuum isolation valves to open or close. For instance, the one or more vacuum isolation valves may be closed to prevent humidity loss. In some implementations, the vacuum isolation valves are automatically controlled based on an automatic control logic. Some constraints can include a number of times that the vacuum isolation valves may open and close to limit excessive wear on hardware components. Other constraints can include opening a single vacuum isolation valve if a cabin dewpoint exceeds a target setpoint, or closing a vacuum isolation valve if the cabin is critically close to exceeding a lower CO2 control assembly humidity requirement. When there are multiple vacuum isolation valves, a load-balancing algorithm may determine which vacuum isolation valve to actuate, which may be based on how many previous cycles each vacuum isolation valve has sustained throughout its lifetime.

[0035] In some embodiments, the control algorithm may be held to one or more flow rate criteria. In some cases, flow rate may be estimated using flow rate sensors or using several delta pressure sensors and polynomial fits. The computational model of the system may monitor parameters such as flow rates and compute errors for each limit. Depending on the monitored parameter, changes may be made to actuator controls in the system.

[0036] Figure 3 shows a simplified block diagram of major control features with control algorithms in an example air revitalization system according to some implementations. The significant level of cross-coupling between components (e.g., actuators) and process variables present challenges for control stability, which can be assessed with testing across a control envelope.

[0037] The present disclosure integrates a physical model and control algorithm into a single framework to verify compliance / non-compliance of system requirements for a plurality of scenarios. The physical model is a computational model that includes simulation logic. The framework performs automated requirement checking for each of the plurality of scenarios. The framework receives the system requirements and generates the plurality of scenarios to run using the computational model and control algorithm, and evaluates each of the different scenarios against the system requirements.

[0038] Figure 4A shows a block diagram of an example framework that determines compliance / non-compliance of system requirements for a plurality of scenarios according to some implementations. At block 401 of the framework 400, a plurality of scenarios are generated based on an operating envelope. Each of the scenarios are different from one another. The scenarios may be driven by the system requirements. The system must workunder a variety of parameters, conditions, and operating modes to define the system requirements. Accordingly, the scenarios test the system for a variety of different parameters, conditions, and operating modes. Each scenario may comprise multiple parameters, conditions, or operating modes. By way of an example, the scenario may include a particular temperature, humidity, heat load, cabin volume, and operating mode (e.g., crewed or uncrewed, CO2 contingency or no CO2 contingency).

[0039] It is not desirable to simulate a single scenario. The worst-case scenario for one parameter may be the best-case scenario for another parameter, which creates a “whack-a- mole” problem for design optimization. The operating envelope may be designed to provide a range of simulation inputs for the framework to simulate. From the inputs, the framework may generate a variety of simulation input sets by combining individual parameters to achieve many different possible combinations. These simulation input sets may constitute “scenarios,” whereby the scenarios comprise different combinations of parameters, conditions, and operating modes from one another. In some embodiments, the framework may specify special scenarios. Such special scenarios may target “what if’ operating modes. In some cases, the special scenarios may include perturbation scenarios that may operate outside the operating envelope and may be simulated for assessing stability rather than compliance / non-compliance with system requirements.

[0040] At block 402 of the framework 400, the integrated physical model and control algorithm are run for each scenario. The framework 400 may run the scenarios quickly. The framework 400 may utilize parallel programming to convert a single-threaded simulation loop into a multithreaded batch process that can be run across multiple processors or multiple machines. Given that each scenario may require a certain duration to run, the framework 400 may utilize parallel processing so that multiple scenarios may be run simultaneously. In one example, hundreds of scenarios may be executed by the framework 400 simultaneously across several cores that can be completed in a short amount of time, allowing for iterations on design decisions.

[0041] At block 403 of the framework 400, each system requirement (or criteria) is checked for each scenario. This takes place during or after the integrated physical model and control algorithm run each scenario. In some embodiments, the system requirements are user-defined. The system requirements may include target ranges for parameters and conditions to be met for compliance / non-compliance. As discussed above with regards to the air revitalization system, system requirements may include maintaining a relative humidity range, maintaining a cabin dewpoint, maintaining a temperature range, maintaining flow rates within acceptable bounds, having a minimum number of actuations, etc. Based on data generated from thephysical model and control algorithm for each scenario, the framework 400 verifies whether the system requirements are met for each scenario.

[0042] At block 404 of the framework 400, plots and / or raw data logs are generated for each scenario. Plots and raw data logs may be generated for each parameter in a multiparameter scenario. The physical model and control algorithm track and monitor changes to each parameter in a system over time. Such parameters may be interdependent and impact one another within the system. By way of an example, parameters that are tracked and monitored in a multiparameter scenario may include one or more of the following: relative humidity, cabin temperature, cabin pressure, cabin dewpoint, CO2 concentration, trace contaminant concentrations, vacuum isolation valve position, fan speed, heat transfer, ammonia flow rate, water generation rate, and water removal rate. Plots and raw data logs for one or more of these parameters may be provided by the framework 400. Examples of such plots and raw data logs are shown in Figures 6A-6F and Figures 7A-7C.

[0043] Blocks 402-404 may be repeated until all the scenarios of the plurality of scenarios are run and complete. The scenarios may be run simultaneously by the framework 400 rather than sequentially. In some embodiments, the framework 400 may process over 20 scenarios, over 50 scenarios, over 100 scenarios, over 200 scenarios, over 500 scenarios, or over 1000 scenarios. In some embodiments, the framework 400 may process the plurality of scenarios in 2 hours or less, in 1 hour or less, in 30 minutes or less, or in 10 minutes or less. The framework 400 is able to run many scenarios and run them quickly in a multi-threaded batch process.

[0044] At block 405 of the framework 400, cross-scenario statistics may be optionally generated. The framework 400 is able to perform analysis of its results and generate statistics across multiple scenarios. In some implementations, the framework 400 can collect and display statistics for each operational mode (e.g., uncrewed, or CO2 contingency). This allows users or operators to determine typical, worst-case, and best-case scenarios for any given parameter(s) for a particular operational mode. In some implementations, the framework 400 is configured to compute actuator lifetime estimates by considering an average performance for each operating mode and expected duration of operation in each operational mode. In one example, a cross-scenario statistic may include metrics / statistics such as average fan speed in a given day for uncrewed scenarios. As selected parameters are outputted into tables, graphs, etc., trend assessments are easily identified.

[0045] Visualization of results may be summarized in a graphical display that shows a performance of each of the plurality of scenarios against the system requirements. In some embodiments, the graphical display may be a matrix such as a scenario results matrix. Thescenario results matrix may summarize all of the completed scenarios using a vector of binary requirement checks. The scenario results matrix displays one or more scenarios along an axis and criteria for compliance / non-compliance along another axis. An example scenario results matrix is illustrated in Figure 5. A “light grey” (or other color, e.g., green) cell represents compliance for a particular criterion in a particular scenario. A ’’dark grey” (or other color, e.g., red) cell represents non-compliance for a particular criterion in a particular scenario.

[0046] At block 406 of the framework 400, run data is published to a shared server.

[0047] At block 407 of the framework 400, the data is analyzed. Referring to analysis of a scenario results matrix, one or more operators / users may assess the overall state of the integrated hardware / software design and prioritize which issues to tackle first.

[0048] At block 408 of the framework 400, the design is iterated by adjusting one or more of the following: physical model, control algorithm, or operating envelope. With design iteration, the goal is to achieve greater compliance with the system requirements for a plurality of scenarios. In other words, the design is iterated until all or substantially all of the scenario results matrix displays “light grey” cells. The framework 400 continues to iterate the design to achieve greater compliance in meeting the system requirements. That way, operators and users can see the “color” change in real-time as the framework iterates the design.

[0049] Figure 4B shows a flow diagram of an example method of verifying system requirements against a plurality of scenarios according to some implementations. The operations of a process flow 450 may be performed in different orders, and / or with different, fewer, or additional operations. In some implementations, the operations of the process flow 450 may be implemented, at least in part, according to software stored in one or more non- transitory computer readable media.

[0050] At block 452 of the process flow 450, a plurality of scenarios that are defined within an operating envelope are generated in a computing device. Each scenario comprises multiple parameters for monitoring in a system. Each scenario is a multiparameter scenario involving multiple process variables, where one process variable can impact one or more other process variables in the system. The system may be a multiple-input multiple-output system. Example systems may include life support systems including air revitalization systems, thermal control systems, nuclear power systems, and control systems for dynamic vehicles. Other example systems may include telecommunications systems, finance systems, chemical refining systems, and propulsion systems.

[0051] By way of an example in a life support system on a spacecraft, parameters for monitoring may include two or more of the following: relative humidity, cabin temperature,cabin pressure, cabin dewpoint, CO2 concentration, trace contaminant concentrations, vacuum isolation valve position, fan speed, heat transfer, ammonia flow rate, water generation rate, and water removal rate. Such parameters may be monitored and tracked during simulation of each scenario.

[0052] The operating envelope establishes the initial conditions or simulation inputs for the plurality of scenarios. In some implementations, the operating envelope provides the limits for different conditions, parameters, and operating modes for the possible scenarios. Otherwise, an infinite number of scenarios are generated, which is not practical for simulation. In some implementations, the operating envelope may define different possible operating modes such as crewed or uncrewed scenarios, CO2 contingency or no CO2 contingency, crew exercise or no crew exercise, etc. In some implementations, the operating envelope may define initial conditions such as an initial cabin temperature, initial cabin pressure, or initial relative humidity. In some implementations, the operating envelope may define situations for certain parameters such as constant fan speed, temperature swings, fan settings, power limits, time limits, heat loads, cabin volume, etc. The plurality of scenarios may be defined based on different combinations of conditions, parameters, and operating modes that are possible within the operating envelope. In some implementations, the plurality of scenarios are automatically generated by the computing device. In some implementations, the plurality of scenarios are generated by user input into the computing device.

[0053] At block 454 of the process flow 450, data associated with each scenario is generated in the computing device using a simulation model and control algorithm. The data associated with each scenario tracks one or more parameters over a duration of time. In some implementations, the data associated with each scenario may be presented as raw data logs, plots, or graphs. Using the simulation model and control algorithm, data is generated for each of the plurality of scenarios until all of the scenarios are complete. The operating envelope may provide the simulation inputs for the simulation model and the control algorithm to generate the data associated with each scenario.

[0054] The simulation model may be a physical or physics-based model that simulates the interactions, behaviors, characteristics, performance, and other criteria in a system such as the multiple-input multiple-output system. The computing device may utilize the simulation model to describe the integrated performance of the system. In some implementations, the simulation model may include one or more sub-models coupled to one another, such as submodels for humidity control and heat exchanger performance. In some implementations, the simulation model may determine how the parameters for monitoring change over time undereach of the scenarios. For instance, the simulation model and control algorithm may determine how temperature, relative humidity, pressure, flow, concentration, heat transfer, and other parameters change over time based on the conditions, parameters, and operating modes established by the scenario.

[0055] The control algorithm may be integrated with the simulation model. The control algorithm may command and / or control components in the system. The system may be characterized by one or more components that can be controlled by the control algorithm. As the parameters are monitored in the system, the control algorithm may regulate components such as controllers (e.g., PID controllers), valves, fans, actuators, dampers, etc. The control algorithm may impact the parameters in the system. Sensor measurements may feed back to the system and determinations can be made by the control algorithm to regulate and / or operate components of the system accordingly. That way, certain limits or requirements can be maintained in the system by the control algorithm.

[0056] Using the simulation model and the control algorithm, the computing device may process the plurality of scenarios and generate data associated with each of the plurality of scenarios. In some implementations, the plurality of scenarios may be processed simultaneously by the computing device. This allows for several scenarios to be processed quickly in a relatively short amount of time. In some implementations, generating the data associated with each scenario using the simulation model and the control algorithm includes running each scenario in parallel using the simulation model and the control algorithm.

[0057] Data associated with each scenario may be represented by raw data logs or plots, examples of which are shown in Figures 6A-6F. Figures 6A-6F show data logs for monitored parameters obtained from a simulation model and control algorithm, tracking relative humidity in Figure 6A, tracking a vacuum isolation valve position in Figure 6B, tracking temperature in Figure 6C, tracking heat transfer in Figure 6D, tracking fan speed in Figure 6E, and tracking a position of a three-way proportioning valve and air scrub damper in Figure 6F.

[0058] Figure 6A shows a raw data log tracking relative humidity as a function of time. The raw data log tracking relative humidity corresponds to a particular scenario involving a crewed exercise situation. Figure 6A shows an upper relative humidity limit of about 75% and a lower relative humidity limit of about 25%. The cabin relative humidity has a set point of about 27%, which is just about lower relative humidity limit. As shown in Figure 6A during crewed exercise, the relative humidity rises and falls directly with crew water generation rates. The lower relative humidity limit is violated on several occasions during crewed exercise, but theduration of violation may not be sufficiently long to be non-compliant with a system requirement.

[0059] Figure 6B shows a raw data log tracking a vacuum isolation valve position as a function of time. The raw data log tracking the vacuum isolation valve position corresponds to a particular scenario involving a worst-case scenario with CO2 contingency. Due to tight allowable flow rate envelopes for the CO2 control assembly, the only method of control in this scenario is rapid actuation of the vacuum isolation valve. Here, in Figure 6B, there are two vacuum isolation valves being monitored. Rapid actuation of the vacuum isolation valves occurs to control the flow rate envelopes for the CO2 control assembly and the relative humidity, but this comes at the cost of diminishing the lifespan of the vacuum isolation valves.

[0060] Figure 6C shows a raw data log tracking temperature as a function of time. The raw data log tracking temperature corresponds to a particular scenario involving an uncrewed flight. Figure 6C shows a lower limit for a crewed flight at around 20°C and an upper limit for a crewed flight at around 27°C. With the uncrewed scenario, the temperature stabilizes relatively quickly, which can occur by driving the fan to its minimum setting (e.g., 7000 RPM) and the three-way proportioning valve to a certain position (e.g., up to 30 degrees). The temperature eventually reaches a steady-state at around the lower limit of about 20°C.

[0061] Figure 6D shows a raw data log tracking heat transfer (W) as a function of time. The raw data log tracking heat transfer corresponds to a particular scenario involving a crewed exercise situation. Figure 6D shows a cabin heat load of about 1980 W and a maximum heat transfer limit of about 3200 W. Inter-module ventilation power consumption generates heat of about 250 W and fan power consumption generates heat of about 450 W. Total heat generated may represent a summation of heat generated from various components such as the cabin heat load, the inter-module ventilation, and the fan. As shown in Figure 6D, the total heat generated may be relatively constant around 3680 W. The components of the system may work to remove heat from the system, and the total heat removed by the system may largely track with the total heat generated.

[0062] Figure 6E shows a raw data log tracking fan speed as a function of time. The raw data log tracking fan speed corresponds to a particular scenario involving a crewed exercise situation. Figure 6E shows a fan speed that moderately fluctuates between 8000 RPM and 8400 RPM. The command limit may be established at around 15800 RPM. A red flag limit may be established at around 12500 RPM. A yellow flag limit may be established at around 11000 RPM. As shown in Figure 6E, the fan speed does not exceed any one of the yellow flag limit, red flag limit, or command limit.

[0063] Figure 6F shows a raw data log tracking a position of a three-way proportioning valve and an air scrub damper as a function of time. The raw data log tracking valve / damper position corresponds to a particular scenario involving a crewed exercise situation. Figure 6F shows the valve position actuating between 0 degrees and 20 degrees, with cycles occurring at least four times. Figure 6F shows the damper position actuating between 20 degrees and 40 degrees, with cycles occurring at least four times.

[0064] Returning to Figure 4B, at block 456 of the process flow 450, whether system requirements are met for each of the parameters for each of the plurality of scenarios is determined by the computing device. The data is analyzed by the computing device and assessed against the system requirements to verify whether the system requirements are met for each scenario. The system requirements may include multiple criteria that represent certain conditions to be met for compliance / non-compliance. The criteria can include acceptable ranges, bounds, limits, thresholds, or conditions for each of the parameters to satisfy in order to reach compliance. If a parameter being tracked in a given scenario satisfies the criterion, then the criterion is deemed compliant for the given scenario. If the parameter being tracked in a given scenario fails to satisfy the criterion, then the criterion is deemed to be non- compliant. In some implementations, the system requirements may be user- or operator- defined.

[0065] One example of a system requirement in a life support system follows: e.g., maintain relative humidity within 25% to 75%; if relative humidity is between 15% and 20%, then the duration of time within that range cannot exceed 4 hours; if relative humidity is between 5% and 10%, then the duration of time within that range cannot exceed 30 minutes. If the relative humidity of the given scenario meets aforementioned criterion, then the system requirement is met.

[0066] Another example of a system requirement in a life support system follows: e.g., maintain the cabin heat so that it does not exceed the maximum heat transfer limit; where the cabin heat cannot exceed the maximum heat transfer limit after an initialization phase (e.g., after 1 hour). If the cabin heat of the given scenario meets the aforementioned criterion, then the system requirement is met.

[0067] In some implementations, the system requirements comprise system requirements associated with life support system requirements in a spacecraft. In some implementations, the system requirements comprise system requirements associated with control systems of dynamic vehicles. In some implementations, the system requirements comprise system requirements associated with nuclear power system requirements. In some implementations,the system requirements comprise system requirements associated with thermal control systems. In some implementations, the system requirements comprise system requirements associated with telecommunications systems. In some implementations, the system requirements comprise system requirements associated with finance systems. In some implementations, the system requirements comprise system requirements associated with chemical refining systems. In some implementations, the system requirements comprise system requirements associated with propulsion systems.

[0068] In some implementations, the process flow 450 further includes generating crossscenario statistics using the data for the plurality of scenarios. Data may be aggregated from one or more scenarios to calculate and generate cross-scenario statistics. The cross-scenario statistics may be used to determine compliance / non-compliance with some system requirements.

[0069] At block 458 of the process flow 450, a graphical display that shows a performance of each of the plurality of scenarios against the system requirements is presented. This step is optional. Visualization of results that summarize the performance of the system for all of its plurality of scenarios in the operating envelope can be presented by the graphical display. The performance of the system can be measured against compliance / non-compliance of the system requirements. In some implementations, the graphical display includes a scenario result matrix, where each cell of the scenario results matrix shows whether one of the parameters meets the system requirement for one of the corresponding scenarios. Each of the scenarios can be mapped along an axis (e.g., x-axis). Each of the criterion associated with a system requirement can be mapped along another axis (e.g., y-axis).

[0070] Figure 5 shows an example scenario result matrix that illustrates whether certain system requirements are met for each scenario according to some implementations. Scenarios are shown along the x-axis, where each scenario is labeled by a numerical reference identifier (e.g., 21111, 21112, 21121, etc.) and each scenario represents different operating conditions and operating modes. Criteria or system requirements are shown along the y-axis. Each system requirement may be labeled according to the parameter being monitored. For example, rhl may represent a first relative humidity limit, rh2 may represent a second relative humidity limit, Qmax may represent a heat transfer limit or tolerance, surface temperature may represent a temperature limit, fan RPM may represent a fan speed limit, NH3 flow max may represent an ammonia flow rate maximum limit, etc. “Light grey” (or other color, e.g., green) in the scenario result matrix indicates compliance with the system requirement. “Dark grey” (or other color, e.g., red) in the scenario result matrix indicates non-compliance with the system requirement.The scenario result matrix provides a simple, visual representation of the performance of the system across multiple scenarios against system requirements. Which scenarios passed? Which scenarios failed or could use improvement? Which criterion passed? Which criterion failed or could use improvement? Such questions can be quickly assessed with a visual representation such as the scenario result matrix as shown in Figure 5. This enables a user or operator to make adjustments to the design to achieve greater compliance or improved performance.

[0071] In some implementations, the scenario result matrix is not limited to color coding, but may assess performance in meeting system requirements using other indicators (e.g., checkmarks, letters, true-false, shading, lines). In some implementations, the scenario result matrix is not limited to binary attributes, but may utilize the graphical display to represent performance across a wider spectrum. For example, the scenario result matrix may indicate performance using other colors such as “green,” “yellow,” “orange,” “red,” or A, B, C, D, F, where performance levels can be assessed across a wider spectrum, or across multiple dimensions or criteria.

[0072] Returning to Figure 4B, in some implementations, the process flow 450 may further include iterating on designs associated with one or more of the simulation model, the control algorithm, and the operating envelope to improve on the performance of each of the plurality of scenarios against the system requirements. Hardware and / or software design adjustments can be made to improve the performance of the system in terms of its compliance to the system requirements. In some implementations, design improvements can be made where scenarios for a given criterion are non-compliant or “red,” and one or more iterations on the design can follow until compliance or “green” is reached.

[0073] In some implementations, the process flow 450 further includes generating one or more perturbation scenarios that are defined outside the operating envelope. In some implementations, perturbation scenarios introduce random noise such as worst-case sensor noise. In some implementations, perturbation scenarios introduce thermal / humidity load variations. In some implementations, perturbation scenarios introduce significant variations in parameters such as temperature, pressure, flow rates, chemistry, water generation rate, etc. The computing device may determine whether stability is met within the system. The process flow 450 further includes generating additional data associated with each perturbation scenario using the simulation model and control algorithm. Such additional data may include raw data logs, plots, and / or graphs for tracking one or more parameters of the system. The process flow 450further includes determining a stability assessment for each of the perturbation scenarios that are defined outside the operating envelope.

[0074] In some implementations, determining the stability assessment is accomplished using a time domain stability margin assessment technique. In some implementations, determining the stability assessment is accomplished using a frequency domain stability margin assessment technique. In some implementations, determining the stability assessment is accomplished using Monte Carlo analysis.

[0075] The framework integrating the simulation model and control algorithm of the present disclosure can cover hundreds or thousands of defined scenarios covering nominal and off- nominal cases. Using automated requirement checking the framework can rapidly verify the system against required environmental conditions (e.g., cabin temperature, coolant temperature, humidity, and pressure setpoints) and operating modes. The framework may include options for accounting for long-term degradation effects like component aging and filter loading.

[0076] Control stability of the system within a stability margin may be another requirement for the framework to verify in “special” scenarios. It is possible in “special” scenarios that system performance may differ from simulation-performance and ground-performance. Such differences could unpredictably drive unstable system performance. Often, a simulation model and control algorithm may assume ideal characteristics for sensor accuracy, sensor noise, and boundary condition stability. In actual operation, however these characteristics will be imperfect with an unpredictable characteristic that can be modeled with random noise. One concern could be whether the control algorithm could tolerate sensor uncertainty while still meeting system requirements. This can drive a concern about actuator usage and impacts to lifetime and power utilization.

[0077] Under such “special” scenarios, a number of control stability verification approaches can be used. One such approach is Monte Carlo analysis. Another such approach is gain / phase margin analysis. Gain / phase margin analysis may be used to perform control stability verification in the simulation model and control algorithm.

[0078] One type of gain / phase margin analysis can be a frequency domain stability margin assessment. To illustrate an example, a multiple-input multiple-output problem can be broken down into three single-input single-output configurations: (1) one single-input single-output controller controlling temperature using fan speed, (2) one single-input single-output controller controlling temperature using the three-way proportioning valve, and (3) one single-input single-output controller controlling humidity using an air scrub damper. For each single-inputsingle-output controller, a relevant actuator was given a set of sinusoidal inputs at a range of frequencies while the other actuators were held constant. A corresponding process variable such as temperature or humidity would respond to the excited input in a sinusoidal fashion. The magnitude and phase offset between the two waves is used to define the frequency response distribution. Gain margin can be calculated as a magnitude of the system response. Phase margin can be calculated as the phase offset. Positive margins can be indicative that the system will experience a self- stabilizing decaying oscillatory response. The foregoing method can also be referred to as a frequency domain stability margin assessment method.

[0079] Another type of gain / phase margin analysis can be a time domain stability margin assessment. To illustrate an example, the required gain margin can be converted into a proportion applied to baseline PID constants and the required phase margin can be converted into a time delay. Provided that the system does not exhibit unstable behavior under such conditions, it can be considered stable. Optionally, the gain margin and the phase margin can be incrementally adjusted to identify exact points of marginal stability.

[0080] By way of an example, dual PID-I controllers are implemented for humidity and thermal control. Cabin volume, absolute pressure, and the presence of CO2 capture assemblies are three factors influencing control stability. For gain margin, 6 dB can equate to an amplitude ratio of 1.995 (-2). Each gain set can be assessed at (1 / 2)X, IX, and 2X of the nominal value. A time delay of about 40 seconds is assumed (effective phase margin of 43.2 degrees). With six perturbation options and eight environmental conditions, 48 additional scenarios are generated. Success can be evaluated based on a qualitative assessment of control stability, verifying that no major oscillations occur in either the process variables or actuator movement.

[0081] Figures 7A-7C show data logs for temperature obtained from a simulation model and control algorithm where perturbation gains of (1 / 2)X in Figure 7A, IX in Figure 7B, and 2X in Figure 7C were assessed using a time domain stability assessment technique. (1 / 2)X can be understood as half-nominal, IX can be understood as nominal, and 2X can be understood as double-nominal. Normal conditions can be demonstrated by IX gain. The results were noneventful, with most scenarios exhibiting similar performance to a baseline unperturbed scenario. The primary disturbance in the plots include the initialization spike, which occurs due to the simulation model and the control algorithm catching up to steady-state reality. The initialization spike is comparable in intensity to those caused by expected cabin heat load changes. Under normal conditions (IX gain), the system recovered from the initialization spike within one hour and with a minor overshoot. In both the (1 / 2)X gain and the 2X gain scenarios, there is a decaying oscillatory response, and because the response is decaying the system canbe judged as stable. Nonetheless, the 2X gain case had the worst-performance with no other cases exhibiting such a strong oscillatory response.

[0082] Control stability verification can also be performed using Monte Carlo analysis. By way of illustration, noise models can be added to sensors and environmental loads. Sensor noise can get added to the simulation of the simulation model and control algorithm. Load noise can additionally or alternatively be added to the simulation of the simulation model and control algorithm. For each noise source, the noise can be sampled via a Gaussian curve centered about the expected value of the parameter and limited to ±3G, where G is the expected standard deviation of the noise distribution. Noise sources may be added one-by-one with intermediate model runs after each addition to identify which noise sources contributed to the most performance degradation. For instance, adding sensor noise to delta pressure sensors impacts the control algorithm for flow rate control, and the flow rate control was observed to be degraded in performance from its baseline performance without the delta pressure sensor noise. However, the control algorithm is able to tolerate the noise and maintain time averaged flow rates within target bounds, though the magnitude of the instantaneous noise made it impossible to keep flow rates within the envelope at every single timepoint. As sensor and load noises get added to a simulation, it can be important to continuously assess actuator setting updates, which can have a direct impact on lifetime for various components (e.g., three-way proportioning valve and air scrub damper) and are a useful indicator for controllability (systems requiring more actuator updates to maintain stability can be considered more difficult to control). The sum total of noise sources can degrade control performance such as temperature control performance, making performance more erratic.

[0083] Figure 4C shows a flow diagram of an example method of assessing stability against one or more perturbation scenarios according to some implementations. The operations of a process flow 460 may be performed in different orders, and / or with different, fewer, or additional operations. In some implementations, the operations of the process flow 450 may be implemented, at least in part, according to software stored in one or more non-transitory computer readable media.

[0084] At block 462 of the process flow 460, a plurality of perturbation scenarios that are defined outside an operating envelope are generated by a computing device. Each of the plurality of perturbation scenarios include multiple parameters for monitoring in a system. The perturbation scenarios may introduce random noise or other parameter deviations that introduce uncertainty to the system. Each perturbation scenario is a multiparameter scenario involving multiple process variables, where one process variable can impact one or more other processvariables in the system. The system may be a multiple-input multiple-output system. Example systems may include life support systems including air revitalization systems, thermal control systems, nuclear power systems, and vehicle dynamics systems. The operating envelope may represent idealized circumstances such as absence of sensor noise, idealized sensor accuracy, and boundary condition stability.

[0085] At block 464 of the process flow 460, data associated with each perturbation scenario is generated using a simulation model and control algorithm. The data tracks one or more parameters for each scenario over a duration of time. In some implementations, the data includes raw data logs, plots, and / or graphs. The simulation model may be a physical or physics-based model that simulates the interactions, behaviors, characteristics, performance, or other criteria in the system. The computing device may utilize the simulation model to describe the integrated performance of the system. The control algorithm may be integrated with the simulation model. The control algorithm may command and / or control components in the system. Using the simulation model and control algorithm, data is generated for each of the plurality of perturbation scenarios until all of the scenarios are complete.

[0086] At block 466 of the process flow 460, a stability assessment is determined for each of the perturbation scenarios that are defined outside the operating envelope. Rather than determining compliance / non-compliance with system requirements, the computing device may determine whether the system is stable or not under each of the perturbation scenarios. In some implementations, the stability assessment can be performed using a gain / phase margin analysis, such as a frequency domain stability margin assessment or a time domain stability margin assessment. In some implementations, the stability assessment can be performed using a Monte Carlo analysis.Conclusion

[0087] Although the foregoing disclosed systems, methods, apparatuses, processes, and compositions have been described in detail within the context of specific implementations for the purpose of promoting clarity and understanding, it will be apparent to one of ordinary skill in the art that there are many alternative ways of implementing foregoing implementations which are within the spirit and scope of this disclosure. Accordingly, the implementations described herein are to be viewed as illustrative of the disclosed inventive concepts rather than restrictively, and are not to be used as an impermissible basis for unduly limiting the scope of any claims eventually directed to the subject matter of this disclosure.

Claims

CLAIMSWhat is claimed is:

1. A method of verifying system requirements against a plurality of scenarios, the method comprising: generating, in a computing device, a plurality of scenarios that are defined within an operating envelope, wherein each scenario comprises multiple parameters for monitoring; generating, in the computing device, data associated with each scenario using a simulation model and control algorithm, wherein the data tracks one of the parameters over a duration of time; and determining, using the computing device, whether system requirements are met for each of the parameters for each of the plurality of scenarios.

2. The method of claim 1, further comprising: presenting a graphical display that shows a performance of each of the plurality of scenarios against the system requirements.

3. The method of claim 2, wherein the graphical display comprises a scenario result matrix, wherein each cell of the scenario result matrix shows whether one of the parameters meets the system requirements for one of the corresponding scenarios.

4. The method of claim 2, further comprising: iterating on designs associated with one or more of the simulation model, the control algorithm, and the operating envelope to improve on the performance of each of the plurality of scenarios against the system requirements.

5. The method of claim 1, further comprising: generating cross-scenario statistics using the data for the plurality of scenarios.

6. The method of claim 1, wherein the operating envelope is used as simulation inputs for the simulation model and control algorithm to generate the data.

7. The method of claim 1, wherein generating the data associated with each scenario using the simulation model and control algorithm comprises running each scenario in parallel using the simulation model and control algorithm.

8. The method of claim 1, wherein the system requirements are associated with complex technical system requirements configured to be assessed in a binary or quantitative manner.

9. The method of claim 8, wherein the system requirements comprise system requirements associated with life support system requirements in a spacecraft.

10. The method of claim 9, wherein the multiple parameters for monitoring comprise two or more of the following: relative humidity, cabin temperature, cabin pressure, cabin dewpoint, CO2 concentration, trace contaminant concentrations, vacuum isolation valve position, fan speed, heat transfer, ammonia flow rate, water generation rate, and water removal rate.

11. The method of claim 8, wherein the system requirements comprise system requirements associated with dynamic vehicle control systems, nuclear power system requirements, or thermal control systems.

12. The method of claim 8, wherein the system requirements comprise system requirements associated with telecommunications systems, finance systems, chemical refining systems, or propulsion systems.

13. The method of claim 1, further comprising: generating, in the computing device, one or more perturbation scenarios that are defined outside the operating envelope; generating, in the computing device, additional data associated with each perturbation scenario using the simulation model and control algorithm; and determining a stability assessment for each of the perturbation scenarios that are defined outside the operating envelope.

14. The method of claim 13, wherein determining the stability assessment is accomplished using a time domain stability margin assessment technique.

15. The method of claim 13, wherein determining the stability assessment is accomplished using a frequency domain stability margin assessment technique.

16. The method of claim 13, wherein determining the stability assessment is accomplished using Monte Carlo analysis.

17. A method of verifying system requirements against a plurality of scenarios, the method comprising: generating, in a computing device, a plurality of scenarios that are defined within an operating envelope; determining whether system requirements are met for each of the plurality of scenarios; and presenting a graphical display that shows a performance of each of the plurality of scenarios against the system requirements in a scenario result matrix.

18. The method of claim 17, wherein each cell of the scenario result matrix shows whether one of the parameters meets the system requirements for one of the corresponding scenarios.

19. The method of claim 17, wherein the system requirements comprise system requirements associated with life support system requirements in a spacecraft.

20. A method of assessing stability against one or more perturbation scenarios, the method comprising: generating, in a computing device, a plurality of perturbation scenarios that are defined outside an operating envelope, wherein each perturbation scenario comprises multiple parameters for monitoring; generating, in the computing device, data associated with each perturbation scenario using a simulation model and control algorithm, wherein the data tracks one of the parameters over a duration of time; and determining, using the computing device, a stability assessment for each of the perturbation scenarios that are defined outside the operating envelope.

Images