Search NASA⌕ Search

SEARCH · Search NASA

Results for “Event sequence”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 37 records · Page 2

Simulation of Liquid Rocket Engine Failure Propagation Using Self-Evolving Scenarios

Traditional probabilistic risk assessment approaches often require failure scenarios to be explicitly defined through event sequences that are then quantified as part of the integrated analysis. This approach becomes difficult when failure propagation paths change as a function of the system operation. Additionally, if the propagation paths represent interactions among even a modest number of components, the scenario count becomes combinatorially intractable. This paper presents an alternate approach for quantifying the probability of failure propagation in such a case. Rather than explicitly defining scenario sequences, simple physical models are created for each of the components. In this way, only the physical states and rules of component interactions must be defined, rather than event sequences for each individual scenario. Initiating failures are introduced into the system, either randomly or as defined by relative likelihood, and the failures cascade through the system via the interaction rules. This process is repeated using Monte Carlo methods and, as a result, the most probable scenarios “self-evolve” in terms of both sequence path and frequency. This approach was applied to failures occurring in the engine compartment of a space launch vehicle with four liquid rocket engines and four high-pressure helium tanks. Each engine was modeled with key components, such as turbomachinery, combustion chamber, propellant lines, and additional support systems. Three test cases were conducted with different high-energy engine failures. End results of interest included an additional engine-out failure and tank burst, which represent the loss-of-mission (LOM) and loss-of-crew (LOC) failure environments, respectively. Observations show that almost every scenario outcome is unique and that many scenarios involve complex chain reactions that are difficult to predict. This validates the usefulness of the modeling approach in assessing the overall risks to the crew during a launch vehicle abort.

Rocket Engine↗

Capturing the sequence of events during the water oxidation reaction in photosynthesis using XFELs

Ever since the discovery that Mn was required for oxygen evolution in plants by Pirson in 1937 and the period-four oscillation in flash-induced oxygen evolution by Joliot and Kok in the 1970s, understanding of this process has advanced enormously using state-of-the-art methods. The most recent in this series of innovative techniques was the introduction of X-ray free-electron lasers (XFELs) a decade ago, which led to another quantum leap in the understanding in this field, by enabling operando X-ray structural and X-ray spectroscopy studies at room temperature. This review summarizes the current understanding of the structure of Photosystem II (PS II) and its catalytic centre, the Mn 4 CaO 5 complex, in the intermediate S i ( i = 0-4)-states of the Kok cycle, obtained using XFELs.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗

Experimental Validation of Thermal Hydraulic Behavior in Sodium Fast Reactors (SFR) with the Thermal Hydraulic Experimental Test Article (THETA)

Thermal stratification and transition to natural circulation pose two of the largest sources of uncertainty in systems-level modeling of liquid metal-cooled fast reactors. As these phenomena typically develop during transient event sequences, licensing-basis events analyzed using systemslevel models may have considerable uncertainties associated with thermal-hydraulic parameters of the system to account for these phenomena. As a result, the validation basis for these phenomena for systems-level codes is insufficient to fully support the wide range of liquid metal fast reactors being developed in the US. Currently, the most viable path for licensing a design is to take significant conservatisms and maintain sufficiently large safety margins to account for this uncertainty.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

A Search for Meteor Shower Signatures in the LDEF IDE Data

For 346 days after the deployment of the LDEF satellite on April 7, 1984, the tape recorder belonging to the Interplanetary Dust Experiment (DE) stored information on over 15,000 impacts made by submicron and larger-size particles on its metal oxide silicon (MOS) detectors. These detectors were mounted on trays facing in six orthogonal directions - LDEF ram and trailing edge, the poles of the LDEF orbit (north and south), and radially inward (towards the Earth) and outward (towards space). The 13.1 second time resolution provided by the IDE electronics, combined with the high sensitivity of the MOS detectors and large collecting area (approximately 1 sq.m) of the experiment, conclusively showed that the small particle environment at the LDEF altitude of 480 km was highly time-variable, with particle fluxes spanning over four orders of magnitude. A large number of the 15,000 impacts recorded by IDE occurred in groups, which were of two types - the spikes, single, isolated events of high intensity and the multiple orbit event sequences (MOES), which were series of events separated in time by integer multiples of the LDEF orbital period. Even though the spikes were generally more intense, the MOES could be quite long-lived, some lasting for many days. A previous paper by Cooke et al. attributed the MOES to impacts by man-made debris particles in orbits intersecting that of LDEF. The 20 day longevity of one of these events - termed the May Swarm - led to the suggestion that the debris particles must be con- stantly replenished by their source, as the orbits of micron sized particles will rapidly decay under the influence of radiation pressure and other non-gravitational forces, entering Earth's atmosphere after only a few revolutions. However, the date of onset of the May Swarm (May 22) and the long duration of this event may indicate a possible correlation with the annual Arietid meteor shower, which peaks around June 8. As this seemed to hold the promise of a less artificial explanation than a satellite or rocket body continuously dribbling debris, it was decided to take a fresh look at parts of the IDE data set in an attempt to detect meteor showers within the impact record.

Cooke, William J.↗

A software architecture for automating operations processes

The Operations Engineering Lab (OEL) at JPL has developed a software architecture based on an integrated toolkit approach for simplifying and automating mission operations tasks. The toolkit approach is based on building adaptable, reusable graphical tools that are integrated through a combination of libraries, scripts, and system-level user interface shells. The graphical interface shells are designed to integrate and visually guide a user through the complex steps in an operations process. They provide a user with an integrated system-level picture of an overall process, defining the required inputs and possible output through interactive on-screen graphics. The OEL has developed the software for building these process-oriented graphical user interface (GUI) shells. The OEL Shell development system (OEL Shell) is an extension of JPL's Widget Creation Library (WCL). The OEL Shell system can be used to easily build user interfaces for running complex processes, applications with extensive command-line interfaces, and tool-integration tasks. The interface shells display a logical process flow using arrows and box graphics. They also allow a user to select which output products are desired and which input sources are needed, eliminating the need to know which program and its associated command-line parameters must be executed in each case. The shells have also proved valuable for use as operations training tools because of the OEL Shell hypertext help environment. The OEL toolkit approach is guided by several principles, including the use of ASCII text file interfaces with a multimission format, Perl scripts for mission-specific adaptation code, and programs that include a simple command-line interface for batch mode processing. Projects can adapt the interface shells by simple changes to the resources configuration file. This approach has allowed the development of sophisticated, automated software systems that are easy, cheap, and fast to build. This paper will discuss our toolkit approach and the OEL Shell interface builder in the context of a real operations process example. The paper will discuss the design and implementation of a Ulysses toolkit for generating the mission sequence of events. The Sequence of Events Generation (SEG) system provides an adaptable multimission toolkit for producing a time-ordered listing and timeline display of spacecraft commands, state changes, and required ground activities.

Miller, Kevin J.↗

A mechanistic model of a PWR-based nuclear power plant in response to external hazard-induced station blackout accidents

Natural hazard-induced nuclear accidents, such as the Fukushima Daiichi Accident that occurred in Japan in 2011, have significantly increased reactor safety studies in understanding nuclear power plant (NPP) responses to external hazard events such as earthquakes and floods. Natural hazards could cause the loss of offsite power in nuclear power plants, potentially leading to a Station Blackout (SBO) accident that significantly contributes to the overall risk of nuclear power plant accidents. Despite the fact that extensive research has been conducted on the station blackout accident for nuclear power plant, further understanding of these events is needed, particularly in the context of the dynamic nature of external hazards such as external flooding. This paper estimates the progression of station blackout events for a generic pressurized water reactor (PWR) in response to external flooding events. The original RELAP5-3D model of the Westinghouse four-loop design pressurized water reactor was adopted and modified to simulate the external flood-induced station blackout accident, including the short-term and long-term station blackout scenarios. A sensitivity analysis of long-term station blackout, examining reactor operation times and analyzing key parameters over time, was also conducted in this work. The results of the analyses, especially the critical timing parameters of key event sequences, provide useful insights about the time during the external flooding event, which is important for plant operators to make timely decisions to prevent potential core damage. This paper represents significant progress toward developing an integrated risk assessment framework for further identifying and assessing the effects of the critical sources of uncertainties of nuclear power plant under external hazard-induced events.

Liu, Tao↗

Cyote-attack Chain Estimator

Attack Chain Estimator (ACE) Application Overview The Attack Chain Estimator (ACE) Application is a sophisticated tool designed for the ingestion, classification, sequencing, and enrichment of cybersecurity threat reports. This application leverages advanced machine learning models and extensive historical data to provide comprehensive insights into cyber threats, specifically targeting Industrial Control Systems (ICS). Purpose The primary functions of the ACE Application include: Ingestion of Cybersecurity Threat Reporting: Capable of ingesting text-based threat reports in markdown or text file format. Supports ingestion of structured data from other sources in STIX/JSON format. Classification of Report’s Text-Based Events: Utilizes a DeBERTa classifier, specifically trained on cybersecurity data, to map the events to MITRE ATT&CK for ICS Tactics and Techniques. Classification is performed using multiple Jupyter notebooks and machine learning workflows hosted as FastAPI microservices: regex_data deberta_base_35_train_hft_classifier_mlflow.ipynb hft_regex_classifier_mlflow.ipynb param_train_hft_classifier_mlflow.ipynb regex_tactic_tech.ipynb Ordering of Tactics, Techniques, and Observable Events: Sequences the identified tactics, techniques, and events to form a coherent attack chain. Enrichment with Historical Attack Chain Details: Enhances the attack chain with details from historical attacks using a Markov model developed from CyOTE Precursor Analysis Report data. The Markov model is available as a FastAPI endpoint for seamless integration. Enrichment with Adversary Emulation Capabilities Data: Integrates adversary emulation capabilities data using MITRE Caldera for OT adversary abilities UUIDs. Export of Output Files: Provides options to export the enriched attack chain in JSON or CSV formats. Routing of Output to Other Applications: Facilitates routing of output to various platforms and applications, including: Threat Intelligence Platforms COREII Scout for Threat Intelligence Analysis COREII Modeling and Simulation for Adversary Emulation Technical Description The ACE Application is an advanced cybersecurity tool designed to provide detailed threat analysis and sequence generation. It is built on a robust architecture that integrates natural language processing, machine learning, and historical data modeling. Key Components: Data Ingestion Module: Handles the input of threat reports and data from various formats, ensuring flexibility in data sources. Classification Engine: Employs DeBERTa-based classifiers hosted as FastAPI microservices to analyze and classify threat report events in accordance with the MITRE ATT&CK framework for ICS. Sequence Generator: Orders the classified events into a logical attack chain, providing clear insight into the sequence of tactics and techniques used in the threat. Enrichment Engine: Integrates historical data and adversary emulation capabilities to enhance the attack chain with valuable context and additional details. The historical data enrichment is powered by a Markov model, which is available as a FastAPI endpoint. Export and Routing Module: Facilitates the export of the enriched attack chain in multiple formats and routes the output to designated applications for further analysis or emulation.

Paul, Tony [Idaho National Laboratory (INL), Idaho↗

Virtual Machine Language 2.1

VML (Virtual Machine Language) is an advanced computing environment that allows spacecraft to operate using mechanisms ranging from simple, time-oriented sequencing to advanced, multicomponent reactive systems. VML has developed in four evolutionary stages. VML 0 is a core execution capability providing multi-threaded command execution, integer data types, and rudimentary branching. VML 1 added named parameterized procedures, extensive polymorphism, data typing, branching, looping issuance of commands using run-time parameters, and named global variables. VML 2 added for loops, data verification, telemetry reaction, and an open flight adaptation architecture. VML 2.1 contains major advances in control flow capabilities for executable state machines. On the resource requirements front, VML 2.1 features a reduced memory footprint in order to fit more capability into modestly sized flight processors, and endian-neutral data access for compatibility with Intel little-endian processors. Sequence packaging has been improved with object-oriented programming constructs and the use of implicit (rather than explicit) time tags on statements. Sequence event detection has been significantly enhanced with multi-variable waiting, which allows a sequence to detect and react to conditions defined by complex expressions with multiple global variables. This multi-variable waiting serves as the basis for implementing parallel rule checking, which in turn, makes possible executable state machines. The new state machine feature in VML 2.1 allows the creation of sophisticated autonomous reactive systems without the need to develop expensive flight software. Users specify named states and transitions, along with the truth conditions required, before taking transitions. Transitions with the same signal name allow separate state machines to coordinate actions: the conditions distributed across all state machines necessary to arm a particular signal are evaluated, and once found true, that signal is raised. The selected signal then causes all identically named transitions in all present state machines to be taken simultaneously. VML 2.1 has relevance to all potential space missions, both manned and unmanned. It was under consideration for use on Orion.

Riedel, Joseph E.↗

FITEVT: A FORTRAN program for arrival-time analysis of nuclear-decay events

FITEVT is a FORTRAN program designed to analyze recorded arrival times of nuclear-decay events affected by dead-time. Here, the primary goal of the program is precise and accurate determination of half-lives. Its method involves imposition of a known sufficiently long extending dead-time to the recorded event sequence, so that the original dead-time effects are completely obliterated and the remaining live-times of the survived events are known exactly. Upon completion of the analysis, the arrival-time spectrum and the live-time spectrum are predicted and compared to those constructed from the survived events.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

Apollo experience report: Guidance and control systems: Automated control system for unmanned mission AS-201

The Apollo command module heat shield and Apollo command and service module/Saturn launch vehicle structural integrity were evaluated in an unmanned test flight. An automated control system was developed to provide the mission event sequencing, the real-time ground control interface, and the backup attitude reference system for the unmanned flight. The required mission events, the design logic, the redundancy concept, and the ground-support-equipment concept are described and some development problem areas are discussed. The mission event time line and the real-time ground command list are included to provide an outline of the control system capabilities and requirements. The mission was accomplished with the automated control system, which functioned without flight anomalies.

Holloway, G. F.↗

LDEF Interplanetary Dust Experiment (IDE) results

The Interplanetary Dust Experiment (IDE) provided high time resolution detection of microparticle impacts on the Long Duration Exposure Facility satellite. Particles, in the diameter range from 0.2 microns to several hundred microns, were detected impacting on six orthogonal surfaces of the gravity-gradient stabilized LDEF spacecraft. The total sensitive surface area was about one square meter, distributed between LDEF rows 3 (Wake or West), 6 (South), 9 (Ram or East), 12 (North), as well as the Space and Earth ends of LDEF. The time of each impact is known to an accuracy that corresponds to better than one degree in orbital longitude. Because LDEF was gravity-gradient stabilized and magnetically damped, the direction of the normal to each detector panel is precisely known for each impact. The 11 1/2 month tape-recorded data set represents the most extensive record gathered of the number, orbital location, and incidence direction for microparticle impacts in low Earth orbit. Perhaps the most striking result from IDE was the discovery that microparticle impacts, especially on the Ram, South, and North surfaces, were highly episodic. Most such impacts occurred in localized regions of the orbit for dozens or even hundreds of orbits in what we have termed Multiple Orbit Event Sequences (MOES). In addition, more than a dozen intense and short-lived 'spikes' were seen in which impact fluxes exceeded the background by several orders of magnitude. These events were distributed in a highly non-uniform fashion in time and terrestrial longitude and latitude.

Oliver, John P.↗

Modeling Payload Stowage Impacts on Fire Risks On-Board the International Space Station

The purpose of this presentation is to determine the risks of fire on-board the ISS due to non-standard stowage. ISS stowage is constantly being reexamined for optimality. Non-standard stowage involves stowing items outside of rack drawers, and fire risk is a key concern and is heavily mitigated. A Methodology is needed to account for fire risk due to non-standard stowage to capture the risk. The contents include: 1) Fire Risk Background; 2) General Assumptions; 3) Modeling Techniques; 4) Event Sequence Diagram (ESD); 5) Qualitative Fire Analysis; 6) Sample Qualitative Results for Fire Risk; 7) Qualitative Stowage Analysis; 8) Sample Qualitative Results for Non-Standard Stowage; and 9) Quantitative Analysis Basic Event Data.

Anton, Kellie e.↗

Data Automata in Scala

The field of runtime verification has during the last decade seen a multitude of systems for monitoring event sequences (traces) emitted by a running system. The objective is to ensure correctness of a system by checking its execution traces against formal specifications representing requirements. A special challenge is data parameterized events, where monitors have to keep track of the combination of control states as well as data constraints, relating events and the data they carry across time points. This poses a challenge wrt. efficiency of monitors, as well as expressiveness of logics. Data automata is a form of automata where states are parameterized with data, supporting monitoring of data parameterized events. We describe the full details of a very simple API in the Scala programming language, an internal DSL (Domain-Specific Language), implementing data automata. The small implementation suggests a design pattern. Data automata allow transition conditions to refer to other states than the source state, and allow target states of transitions to be inlined, offering a temporal logic flavored notation. An embedding of a logic in a high-level language like Scala in addition allows monitors to be programmed using all of Scala's language constructs, offering the full flexibility of a programming language. The framework is demonstrated on an XML processing scenario previously addressed in related work.

runtime verification↗

Quantitative risk assessment system (QRAS)

A quantitative risk assessment system (QRAS) builds a risk model of a system for which risk of failure is being assessed, then analyzes the risk of the system corresponding to the risk model. The QRAS performs sensitivity analysis of the risk model by altering fundamental components and quantifications built into the risk model, then re-analyzes the risk of the system using the modifications. More particularly, the risk model is built by building a hierarchy, creating a mission timeline, quantifying failure modes, and building/editing event sequence diagrams. Multiplicities, dependencies, and redundancies of the system are included in the risk model. For analysis runs, a fixed baseline is first constructed and stored. This baseline contains the lowest level scenarios, preserved in event tree structure. The analysis runs, at any level of the hierarchy and below, access this baseline for risk quantitative computation as well as ranking of particular risks. A standalone Tool Box capability exists, allowing the user to store application programs within QRAS.

Weinstock, Robert M↗

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con- trol its next near term behavior. We present a high-level view of the automated flight rule checker Frc for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there- fore be verified with a trace analysis tool. Frc is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con- text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

Kurklu, Elif↗

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con-trol its next near term behavior. We present a high-level view of the automated flight rule checker FRC for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there-fore be verified with a trace analysis tool. FRC is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con-text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

LADEE↗