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
All sourcesNASA NTRSDOE OSTI
NASA NTRS2010

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.↗
NASA NTRS2014

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↗
NASA NTRS2001

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↗
NASA NTRS2020

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↗
NASA NTRS2020

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↗
NASA NTRS1995

The orbital characteristics of debris particle rings as derived from IDE observations of multiple orbit intersections with LDEF

During the first 346 days of the LDEF's almost 6 year stay in space, the metal oxide silicon detectors of the Interplanetary Dust Experiment (IDE) recorded over 15,000 impacts, most of which were separated in time by integer multiples of the LDEF orbital period (called multiple orbit event sequences, or MOES). Simple celestial mechanics provides ample reason to expect that a good deal of information about the orbits of the impacting debris particles can be extracted from these MOES, and so a procedure, based on the work of Greenberg, has been developed and applied to one of these events, the so-called 'May swarm'. This technique, the 'Method of Differential Precession,' allows for the determination of the geometrical elements of a particle orbit from the change in the position of the impact point with time. The application of this approach to the May swarm gave the following orbital elements for the orbit of the particles striking LDEF during this MOES: a = 6746.5 km; 0.0165 less than e less than 0.025; i = 66.55 deg; Omega(sub 0) = 179.0 deg plus or minus 0.2 deg; omega = 178.1 deg plus or minus 0.2 deg.

Cooke, William J.↗
NASA NTRS2013

Development of the Orion Crew-Service Module Umbilical Retention and Release Mechanism

The Orion CSM umbilical retention and release mechanism supports and protects all of the cross-module commodities between the spacecrafts crew and service modules. These commodities include explosive transfer lines, wiring for power and data, and flexible hoses for ground purge and life support systems. The mechanism employs a single separation interface which is retained with pyrotechnically actuated separation bolts and supports roughly two dozen electrical and fluid connectors. When module separation is commanded, either for nominal on-orbit CONOPS or in the event of an abort, the mechanism must release the separation interface and sever all commodity connections within milliseconds of command receipt. There are a number of unique and novel aspects of the design solution developed by the Orion mechanisms team. The design is highly modular and can easily be adapted to other vehiclesmodules and alternate commodity sets. It will be flight tested during Orions Exploration Flight Test 1 (EFT-1) in 2014, and the Orion team anticipates reuse of the design for all future missions. The design packages fluid, electrical, and ordnance disconnects in a single separation interface. It supports abort separations even in cases where aerodynamic loading prevents the deployment of the umbilical arm. Unlike the Apollo CSM umbilical which was a destructive separation device, the Orion design is resettable and flight units can be tested for separation performance prior to flight.Initial development testing of the mechanisms separation interface resulted in binding failures due to connector misalignments. The separation interface was redesigned with a robust linear guide system, and the connector separation and boom deployment were separated into two discretely sequenced events. These changes addressed the root cause of the binding failure by providing better control of connector alignment. The new design was tuned and validated analytically via Monte Carlo simulation. The analytical validation was followed by a repeat of the initial test suite plus test cases at thermal extremes and test cases with imposed mechanical failures demonstrating fault tolerance. The mechanism was then exposed to the qualification vibration environment. Finally, separation testing was performed at full speed with live ordnance.All tests of the redesigned mechanism resulted in successful separation of the umbilical interface with adequate force margins and timing. The test data showed good agreement with the predictions of the Monte Carlo simulation. The simulation proved invaluable due to the number of variables affecting the separation and the uncertainty associated with each. The simulation allowed for rapid assessment of numerous trades and contingency scenarios, and can be easily reconfigured for varying commodity sets and connector layouts.

Separation↗
NASA NTRS2015

Reliability and Probabilistic Risk Assessment - How They Play Together

Since the Space Shuttle Challenger accident in 1986, NASA has extensively used probabilistic analysis methods to assess, understand, and communicate the risk of space launch vehicles. Probabilistic Risk Assessment (PRA), used in the nuclear industry, is one of the probabilistic analysis methods NASA utilizes to assess Loss of Mission (LOM) and Loss of Crew (LOC) risk for launch vehicles. PRA is a system scenario based risk assessment that uses a combination of fault trees, event trees, event sequence diagrams, and probability distributions to analyze the risk of a system, a process, or an activity. It is a process designed to answer three basic questions: 1) what can go wrong that would lead to loss or degraded performance (i.e., scenarios involving undesired consequences of interest), 2) how likely is it (probabilities), and 3) what is the severity of the degradation (consequences). Since the Challenger accident, PRA has been used in supporting decisions regarding safety upgrades for launch vehicles. Another area that was given a lot of emphasis at NASA after the Challenger accident is reliability engineering. Reliability engineering has been a critical design function at NASA since the early Apollo days. However, after the Challenger accident, quantitative reliability analysis and reliability predictions were given more scrutiny because of their importance in understanding failure mechanism and quantifying the probability of failure, which are key elements in resolving technical issues, performing design trades, and implementing design improvements. Although PRA and reliability are both probabilistic in nature and, in some cases, use the same tools, they are two different activities. Specifically, reliability engineering is a broad design discipline that deals with loss of function and helps understand failure mechanism and improve component and system design. PRA is a system scenario based risk assessment process intended to assess the risk scenarios that could lead to a major/top undesirable system event, and to identify those scenarios that are high-risk drivers. PRA output is critical to support risk informed decisions concerning system design. This paper describes the PRA process and the reliability engineering discipline in detail. It discusses their differences and similarities and how they work together as complementary analyses to support the design and risk assessment processes. Lessons learned, applications, and case studies in both areas are also discussed in the paper to demonstrate and explain these differences and similarities.

Safie, Fayssal↗
NASA NTRS1998

Space Shuttle Main Engine Quantitative Risk Assessment: Illustrating Modeling of a Complex System with a New QRA Software Package

During 1997, a team from Hernandez Engineering, MSFC, Rocketdyne, Thiokol, Pratt & Whitney, and USBI completed the first phase of a two year Quantitative Risk Assessment (QRA) of the Space Shuttle. The models for the Shuttle systems were entered and analyzed by a new QRA software package. This system, termed the Quantitative Risk Assessment System(QRAS), was designed by NASA and programmed by the University of Maryland. The software is a groundbreaking PC-based risk assessment package that allows the user to model complex systems in a hierarchical fashion. Features of the software include the ability to easily select quantifications of failure modes, draw Event Sequence Diagrams(ESDs) interactively, perform uncertainty and sensitivity analysis, and document the modeling. This paper illustrates both the approach used in modeling and the particular features of the software package. The software is general and can be used in a QRA of any complex engineered system. The author is the project lead for the modeling of the Space Shuttle Main Engines (SSMEs), and this paper focuses on the modeling completed for the SSMEs during 1997. In particular, the groundrules for the study, the databases used, the way in which ESDs were used to model catastrophic failure of the SSMES, the methods used to quantify the failure rates, and how QRAS was used in the modeling effort are discussed. Groundrules were necessary to limit the scope of such a complex study, especially with regard to a liquid rocket engine such as the SSME, which can be shut down after ignition either on the pad or in flight. The SSME was divided into its constituent components and subsystems. These were ranked on the basis of the possibility of being upgraded and risk of catastrophic failure. Once this was done the Shuttle program Hazard Analysis and Failure Modes and Effects Analysis (FMEA) were used to create a list of potential failure modes to be modeled. The groundrules and other criteria were used to screen out the many failure modes that did not contribute significantly to the catastrophic risk. The Hazard Analysis and FMEA for the SSME were also used to build ESDs that show the chain of events leading from the failure mode occurence to one of the following end states: catastrophic failure, engine shutdown, or siccessful operation( successful with respect to the failure mode under consideration).

Smart, Christian↗
NASA NTRS1972

Delta-90 Interplanetary Monitoring Platform-H (IMP-H) flash flight report

The Delta-90 launch vehicle and the IMP-H spacecraft were successfully launched from Pad B, Complex 17, Cape Kennedy Air Force Station, Florida, at 2120:00.559 EDT on September 22, 1972. The countdown proceeded smoothly to liftoff with no major difficulties or unscheduled holds. The Delta-90/IMP-H were launched on a pad azimuth of 115 degrees, the vehicle ten rolled to 95 degrees from the north placing the spacecraft in a highly elliptical transfer orbit. Firing the spacecraft kickmotor at 1136 EDT, September 25, 1972, injected the spacecraft into its final desirable near-circular orbit approximately half way between the planet earth and its moon. Vehicle performance of all stages appeared nominal with all sequenced events occurring at the expected times. Data acquisition from all range stations was very good. Damage to the launch pad caused by liftoff was nominal.

Source record↗
NASA NTRS1975

Apollo experience report: Guidance and control systems. Mission control programmer for unmanned missions AS-202, Apollo 4, and Apollo 6

An unmanned test flight program required to evaluate the command module heat shield and the structural integrity of the command and service module/Saturn launch vehicle is described. The mission control programer was developed to provide the unmanned interface between the guidance and navigation computer and the other spacecraft systems for mission event sequencing and real-time ground control during missions AS-202, Apollo 4, and Apollo 6. The development of this unmanned programer is traced from the initial concept through the flight test phase. Detailed discussions of hardware development problems are given with the resulting solutions. The mission control programer functioned correctly without any flight anomalies for all missions. The Apollo 4 mission control programer was reused for the Apollo 6 flight, thus being one of the first subsystems to be reflown on an Apollo space flight.

Holloway, G. F.↗
NASA NTRS1987

The human role in space (THURIS) applications study. Final briefing

The THURIS (The Human Role in Space) application is an iterative process involving successive assessments of man/machine mixes in terms of performance, cost and technology to arrive at an optimum man/machine mode for the mission application. The process begins with user inputs which define the mission in terms of an event sequence and performance time requirements. The desired initial operational capability date is also an input requirement. THURIS terms and definitions (e.g., generic activities) are applied to the input data converting it into a form which can be analyzed using the THURIS cost model outputs. The cost model produces tabular and graphical outputs for determining the relative cost-effectiveness of a given man/machine mode and generic activity. A technology database is provided to enable assessment of support equipment availability for selected man/machine modes. If technology gaps exist for an application, the database contains information supportive of further investigation into the relevant technologies. The present study concentrated on testing and enhancing the THURIS cost model and subordinate data files and developing a technology database which interfaces directly with the user via technology readiness displays. This effort has resulted in a more powerful, easy-to-use applications system for optimization of man/machine roles. Volume 1 is an executive summary.

Maybee, George W.↗
NASA NTRS1991

Reasoning about real-time systems with temporal interval logic constraints on multi-state automata

Models of real-time systems using a single paradigm often turn out to be inadequate, whether the paradigm is based on states, rules, event sequences, or logic. A model-based approach to reasoning about real-time systems is presented in which a temporal interval logic called TIL is employed to define constraints on a new type of high level automata. The combination, called hierarchical multi-state (HMS) machines, can be used to model formally a real-time system, a dynamic set of requirements, the environment, heuristic knowledge about planning-related problem solving, and the computational states of the reasoning mechanism. In this framework, mathematical techniques were developed for: (1) proving the correctness of a representation; (2) planning of concurrent tasks to achieve goals; and (3) scheduling of plans to satisfy complex temporal constraints. HMS machines allow reasoning about a real-time system from a model of how truth arises instead of merely depending of what is true in a system.

Gabrielian, Armen↗
NASA NTRS1992

Time management displays for shuttle countdown

The Intelligent Launch Decision Support System project is developing a Time Management System (TMS) for the NASA Test Director (NTD) to use for time management during Shuttle terminal countdown. TMS is being developed in three phases: an information phase; a tool phase; and an advisor phase. The information phase is an integrated display (TMID) of firing room clocks, of graphic timelines with Ground Launch Sequencer events, and of constraints. The tool phase is a what-if spreadsheet (TMWI) for devising plans for resuming from unplanned hold situations. It is tied to information in TMID, propagates constraints forward and backward to complete unspecified values, and checks the plan against constraints. The advisor phase is a situation advisor (TMSA), which proactively suggests tactics. A concept prototype for TMSA is under development. The TMID is currently undergoing field testing. Displays for TMID and TMWI are described. Descriptions include organization, rationale for organization, implementation choices and constraints, and use by NTD.

Beller, Arthur E.↗
NASA NTRS1991

LDEF Interplanetary Dust Experiment - Techniques for identification and study of long-lived orbital debris clouds

The Long Duration Exposure Facility (LDEF) is a 12-sided, 4.3-m-diameter, 9.1-m-long cylinder designed and built by NASA Langley to carry experiments for extended periods in space. The LDEF was first placed in orbit by the Shuttle Challenger on 7 April 1984 and recovered by the Shuttle Columbia in January 1990, only days before it was expected to burn up in the earth's atmosphere. The Interplanetary Dust Experiment (IDE) was designed to detect impacts of extra-terrestrial particles and orbital debris. The IDE detectors (which covered about 1 sq m of the surface of LDEF) were sensitive to particles ranging in size from about 0.2 to 100 microns. Data were recorded for 11.5 months before the supply of magnetic tape was exhausted. Examination of the LDEF IDE dataset shows that impacts often occurred in 'bursts', during which numerous impacts occurred in a short time (typically 3-5 min) at a rate much greater than the average impact rate. In several cases, such events reoccurred each time the LDEF returned to the same point in its orbit. Such multi-orbit event sequences were found to extend for as many as 25 or more orbits.

Singer, S. F.↗
NASA NTRS1993

Lunar rover navigation concepts

With regard to the navigation of mobile lunar vehicles on the surface, candidate techniques are reviewed and progress of simulations and experiments made up to now are described. Progress that can be made through precursor investigations on Earth is considered. In the early seventies the problem was examined in a series of relevant tests made in the California desert. Meanwhile, Apollo rovers made short exploratory sorties and robotic Lunokhods traveled over modest distances on the Moon. In these early missions some of the required methods were demonstrated. The navigation problem for a lunar traverse can be viewed in three parts: to determine the starting point with enough accuracy to enable the desired mission; to determine the event sequence required to reach the site of each traverse objective; and to redetermine actual positions enroute. The navigator's first tool is a map made from overhead imagery. The Moon was almost completely photographed at moderate resolution by spacecraft launched in the sixties, but that data set provides imprecise topographic and selenodetic information. Therefore, more advanced orbital missions are now proposed as part of a resumed lunar exploration program. With the mapping coverage expected from such orbiters, it will be possible to use a combination of visual landmark navigation and external radio and optical references (Earth and Sun) to achieve accurate surface navigation almost everywhere on the near side of the Moon. On the far side and in permanently dark polar areas, there are interesting exploration targets where additional techniques will have to be used.

Burke, James D.↗