Search NASA⌕ Search

SEARCH · Search NASA

Results for “state machine”

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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Actor-based Runtime Verification with MESA

This work presents a runtime verification approach implemented in the tool MESA (MEssage-based System Analysis) which allows for using concurrent monitors to check for properties specified in data parameterized temporal logic and state machines. The tool is implemented as an internal Scala DSL. We employ the actor programming model to implement MESA where monitors are captured by concurrent actors that communicate via messaging. The paper presents a case study in which MESA is used to effectively monitor a large number of flights from live US airspace data streams. We also perform an empirical study by conducting experiments using monitoring systems with different numbers of concurrent monitors and different layers of indexing on the data contained in events. The paper describes the experiments, evaluates the results, and discusses challenges faced during the study. The evaluation shows the value of combining concurrency with indexing to handle data rich events.

runtime verification↗
NASA NTRS2013

Mars Science Laboratory CHIMRA/IC/DRT Flight Software for Sample Acquisition and Processing

The design methodologies of using sequence diagrams, multi-process functional flow diagrams, and hierarchical state machines were successfully applied in designing three MSL (Mars Science Laboratory) flight software modules responsible for handling actuator motions of the CHIMRA (Collection and Handling for In Situ Martian Rock Analysis), IC (Inlet Covers), and DRT (Dust Removal Tool) mechanisms. The methodologies were essential to specify complex interactions with other modules, support concurrent foreground and background motions, and handle various fault protections. Studying task scenarios with multi-process functional flow diagrams yielded great insight to overall design perspectives. Since the three modules require three different levels of background motion support, the methodologies presented in this paper provide an excellent comparison. All three modules are fully operational in flight.

sample processing↗
NASA NTRS2020

GN&C Sequencing for Orion Rendezvous, Proximity Operations, and Docking

As part of the Artemis program to return humans to the lunar surface, the National Aeronautics and Space Administration is planning to use the Orion Multi- Purpose Crew Vehicle to transport crew to a small orbital platform called Gate- way in cislunar space. To facilitate this activity, Orion is required to perform Rendezvous, Proximity Operations, and Docking (RPOD) with both the Gate- way and the launch vehicle upper stage. The Orion spacecraft uses sequencing in the form of Phases, Segments, Activities, and Modes (PSAM) to configure Guidance, Navigation, & Control (GN&C) software during each portion of the mission. Significant updates to Orion PSAM definitions are required for RPOD. This paper describes the process of defining these new sequencing elements, implementing them in prototype flight software, and testing them in an integrated simulation environment. First, requirements are specified to determine the nominal and off-nominal sequencing behavior necessary to complete the mission. These requirements also specify which software functions should be fully autonomous and which functions require manual interactions from crew or ground operators. Next, the RPOD concept of operations is defined with detailed events listed in a mission timeline. Third, a state machine diagram is developed to show all PSAM states, including all possible transitions between them. After this, the PSAM states and transitions are entered into a sequencing software emulator and parameter values and modes are defined for GN&C software elements. Finally, the PSAM architecture is tested within an integrated simulation environment by connecting it with prototypes of relevant GN&C flight software elements and with detailed vehicle models. After the sequencing design has been finalized and tested, it is implemented in flight software.

Schulte, Peter Z.↗
NASA NTRS1983

Verification of Numerical Algorithms

The following strategy is suggested for specification and proof: (1) Defer the construction of a formal program specification with respect to I/O assertions unit the correctness of the program with respect to an abstract mathematical model of program intent is demonstrated. (2) Prove that an abstract machine (using infinite precision arithmetic) would compute that object exactly. (3) Prove that the computational sequences of arithmetic operations that occur in the abstract machine must be precisely the same at every step as those occurring on an actual machine (with finite precision arithmetic), executing the same program. (4) Use a Verification Conditions VC-generator that knows about the semantics of arithmetic operations to annotate the program with assertions that bound (or in some circumstances estimate) the difference between the actual machine state variables and the corresponding ones of the abstract machine. Construct the formal program specification by combining the verification conditions into theorems about computational error that can be proved with mechanical assistance.

Source record↗
NASA NTRS2015

Software Testbed for Developing and Evaluating Integrated Autonomous Subsystems

To implement fault tolerant autonomy in future space systems, it will be necessary to integrate planning, adaptive control, and state estimation subsystems. However, integrating these subsystems is difficult, time-consuming, and error-prone. This paper describes Intelliface/ADAPT, a software testbed that helps researchers develop and test alternative strategies for integrating planning, execution, and diagnosis subsystems more quickly and easily. The testbed's architecture, graphical data displays, and implementations of the integrated subsystems support easy plug and play of alternate components to support research and development in fault-tolerant control of autonomous vehicles and operations support systems. Intelliface/ADAPT controls NASA's Advanced Diagnostics and Prognostics Testbed (ADAPT), which comprises batteries, electrical loads (fans, pumps, and lights), relays, circuit breakers, invertors, and sensors. During plan execution, an experimentor can inject faults into the ADAPT testbed by tripping circuit breakers, changing fan speed settings, and closing valves to restrict fluid flow. The diagnostic subsystem, based on NASA's Hybrid Diagnosis Engine (HyDE), detects and isolates these faults to determine the new state of the plant, ADAPT. Intelliface/ADAPT then updates its model of the ADAPT system's resources and determines whether the current plan can be executed using the reduced resources. If not, the planning subsystem generates a new plan that reschedules tasks, reconfigures ADAPT, and reassigns the use of ADAPT resources as needed to work around the fault. The resource model, planning domain model, and planning goals are expressed using NASA's Action Notation Modeling Language (ANML). Parts of the ANML model are generated automatically, and other parts are constructed by hand using the Planning Model Integrated Development Environment, a visual Eclipse-based IDE that accelerates ANML model development. Because native ANML planners are currently under development and not yet sufficiently capable, the ANML model is translated into the New Domain Definition Language (NDDL) and sent to NASA's EUROPA planning system for plan generation. The adaptive controller executes the new plan, using augmented, hierarchical finite state machines to select and sequence actions based on the state of the ADAPT system. Real-time sensor data, commands, and plans are displayed in information-dense arrays of timelines and graphs that zoom and scroll in unison. A dynamic schematic display uses color to show the real-time fault state and utilization of the system components and resources. An execution manager coordinates the activities of the other subsystems. The subsystems are integrated using the Internet Communications Engine (ICE). an object-oriented toolkit for building distributed applications.

Testbed↗
NASA NTRS1993

An elementary tutorial on formal specification and verification using PVS

A tutorial on the development of a formal specification and its verification using the Prototype Verification System (PVS) is presented. The tutorial presents the formal specification and verification techniques by way of specific example - an airline reservation system. The airline reservation system is modeled as a simple state machine with two basic operations. These operations are shown to preserve a state invariant using the theorem proving capabilities of PVS. The technique of validating a specification via 'putative theorem proving' is also discussed and illustrated in detail. This paper is intended for the novice and assumes only some of the basic concepts of logic. A complete description of user inputs and the PVS output is provided and thus it can be effectively used while one is sitting at a computer terminal.

Butler, Ricky W.↗
NASA NTRS1998

Use of SX Series Devices and IEEE 1149.1 JTAG Circuitry

This report summarizes the use of SX series devices and their JTAG 1149.1 circuitry. 'JTAG' circuitry was originally designed to standardize testing of boards via a simple control port interface electrically without having to use devices such as a bed of nails tester. JTAG is also used for other functions such as executing built-in-test sequences, identifying devices, or, through custom instructions, other functions designed in by the chip designer. The JTAG circuitry is designed for test only; it has no functional use in the integrated circuit during normal operations. The JTAG circuitry and the mode of the device is controlled by a circuit block known as the 'TAP controller,' which is a sixteen-state state machine along with various registers. The controller is normally in an operational state known as TEST-LOGIC-RESET. In this state, the device is held in a fully functional, operating mode. However, a Single Event Upset (SEU) may remove the TAP controller from this state, causing a loss of control of the integrated circuit, unless certain precautions are taken, such as grounding the optional JTAG TRST signal.

Katz, Richard B.↗
NASA NTRS1998

Use of SX Series Devices and IEEE 1149.1 JTAG Circuitry

This report summarizes the use of SX series devices and their JTAG 1149.1 circuitry. 'JTAG' circuitry was originally designed to standardize testing of boards via a simple control port interface electrically without having to use devices such as a bed of nails tester. JTAG is also used for other functions such as executing built-in-test sequences, identifying devices, or, through custom instructions, other functions designed in by the chip designer. The JTAG circuitry is designed for test only; it has no functional use in the integrated circuit during normal operations. The JTAG circuitry and the mode of the device is controlled by a circuit block known as the 'TAP controller,' which is a sixteen-state state machine along with various registers. The controller is normally in an operational state known as TEST-LOGIC-RESET. In this state, the device is held in a fully functional, operational mode. However, a Single Event Upset (SEU) may remove the TAP controller from this state, causing a loss of control of the integrated circuit, unless certain precautions are taken, such as grounding the optional JTAG TRST signal.

Katz, Richard B.↗
NASA NTRS2018

The Behavior, Constraint, and Scenario (BeCoS) Tool: A Web-Based Software Application for Modeling Behaviors and Scenarios

The Behavior, Constraint, and Scenario (BeCoS) tool has been developed to allow engineers to specify system and component behaviors. The tool is a web application that is developed in JavaScript and uses the React framework for the user interface and Redux for maintaining application state. The foundation of the tool is its underlying ontology, which expands upon a previously-defined behavior ontology with a scenario ontology. The behavior ontology includes elements like behaving elements, state variables, parameters, and constraints, while the scenario ontology includes core constructs like activities, temporal constraints, and timepoints. BeCoS allows users to easily create behaving elements and to specify their state variables, parameters, state machines, and constraints. BeCoS also allows users to develop temporal constraint networks that specify constraints on component states over time. BeCoS is a prototype tool that has been deployed and tested by systems engineers on the Europa Clipper project, which generated several use cases and helped steer its current developmental effort. By enabling systems engineers to specify behavior in a semantically-rigorous manner, BeCoS is an enabling technology for analyses that previously could not be performed, and when exporting its model to other tools, allows for consistent behavior models to be used.

Ingham, Michel D.↗
NASA NTRS2018

The Behavior, Constraint, and Scenario (BeCoS) Tool: A Web-Based Software Application for Modeling Behaviors and Scenarios

The Behavior, Constraint, and Scenario (BeCoS) tool has been developed to allow engineers to specify system and component behaviors. The tool is a web application that is developed in JavaScript and uses the React framework for the user interface and Redux for maintaining application state. The foundation of the tool is its underlying ontology, which expands upon a previously-defined behavior ontology with a scenario ontology. The behavior ontology includes elements like behaving elements, state variables, parameters, and constraints, while the scenario ontology includes core constructs like activities, temporal constraints, and timepoints. BeCoS allows users to easily create behaving elements and to specify their state variables, parameters, state machines, and constraints. BeCoS also allows users to develop temporal constraint networks that specify constraints on component states over time. BeCoS is a prototype tool that has been deployed and tested by systems engineers on the Europa Clipper project, which generated several use cases and helped steer its current developmental effort. By enabling systems engineers to specify behavior in a semantically-rigorous manner, BeCoS is an enabling technology for analyses that previously could not be performed, and when exporting its model to other tools, allows for consistent behavior models to be used.

Inghams, Michel D.↗
NASA NTRS2017

Automated Analysis of Stateflow Models

Stateflow is a widely used modeling framework for embedded and cyber physical systems where control software interacts with physical processes. In this work, we present a framework a fully automated safety verification technique for Stateflow models. Our approach is two-folded: (i) we faithfully compile Stateflow models into hierarchical state machines, and (ii) we use automated logic-based verification engine to decide the validity of safety properties. The starting point of our approach is a denotational semantics of State flow. We propose a compilation process using continuation-passing style (CPS) denotational semantics. Our compilation technique preserves the structural and modal behavior of the system. The overall approach is implemented as an open source toolbox that can be integrated into the existing Mathworks Simulink Stateflow modeling framework. We present preliminary experimental evaluations that illustrate the effectiveness of our approach in code generation and safety verification of industrial scale Stateflow models.

Stateflow↗
NASA NTRS1990

Stabilization of discrete-event processes

Discrete-event processes are modeled by state-machines in the Ramadge-Wonham framework with control by a feedback event disablement mechanism. In this paper, concepts of stabilization of discrete-event processes are defined and investigated. The possibility of driving a process (under control) from arbitrary initial states to a prescribed subset of the state set and then keeping it there indefinitely is examined. This stabilization property is studied also with respect to 'open-loop' processes and their asymptotic behavior is characterized. Polynomial time algorithms are presented for verifying various types of attraction and for the synthesis of attractors.

Brave, Y.↗
NASA NTRS1987

Correctness criteria for process migration

Two correctness criteria, the state consistency criterion and the property consistency criterion for process migration are discussed. The state machine approach is used to model the interactions between a user process and its environment. These criteria are defined in terms of the model. The idea of environment view was introduced to distinguish what a user process observes about its environment from what its environment state really is and argue that a consistent view of the environment must be maintained for every migrating process.

Lu, Chin↗
NASA NTRS1995

Formal methods demonstration project for space applications

The Space Shuttle program is cooperating in a pilot project to apply formal methods to live requirements analysis activities. As one of the larger ongoing shuttle Change Requests (CR's), the Global Positioning System (GPS) CR involves a significant upgrade to the Shuttle's navigation capability. Shuttles are to be outfitted with GPS receivers and the primary avionics software will be enhanced to accept GPS-provided positions and integrate them into navigation calculations. Prior to implementing the CR, requirements analysts at Loral Space Information Systems, the Shuttle software contractor, must scrutinize the CR to identify and resolve any requirements issues. We describe an ongoing task of the Formal Methods Demonstration Project for Space Applications whose goal is to find an effective way to use formal methods in the GPS CR requirements analysis phase. This phase is currently under way and a small team from NASA Langley, ViGYAN Inc. and Loral is now engaged in this task. Background on the GPS CR is provided and an overview of the hardware/software architecture is presented. We outline the approach being taken to formalize the requirements, only a subset of which is being attempted. The approach features the use of the PVS specification language to model 'principal functions', which are major units of Shuttle software. Conventional state machine techniques form the basis of our approach. Given this background, we present interim results based on a snapshot of work in progress. Samples of requirements specifications rendered in PVS are offered to illustration. We walk through a specification sketch for the principal function known as GPS Receiver State processing. Results to date are summarized and feedback from Loral requirements analysts is highlighted. Preliminary data is shown comparing issues detected by the formal methods team versus those detected using existing requirements analysis methods. We conclude by discussing our plan to complete the remaining activities of this task.

Divito, Ben L.↗
NASA NTRSDate not supplied

Performance of a Regenerative Fuel Cell System for the Lunar Surface

Regenerative fuel cells (RFCs) are an attractive energy storage solution for lunar missions as a technology capable of providing a higher specific energy (i.e., W∙h/kg) than state-of-the-art packaged Li-ion battery systems. An RFC consists of the (1 & 2) electrochemical stacks (chemical to electrical energy conversion to supply electricity to an external load, i.e. the fuel cell reaction, and electrical to chemical energy conversion of supplied electrical power to dissociate water into hydrogen and oxygen gases, i.e. water electrolysis), (3) fluidic conditioning, (4) reactant storage, (5) avionics, (6) power management and distribution (PMAD), and (7) thermal management. NASA’s Glenn Research Center has designed, assembled, and tested a breadboard RFC sys-tem capable of operating autonomously for multiple simulated lunar day/night cycles in a laboratory environment. The system is comprised of a non-flow through proton exchange membrane (PEM) fuel cell stack and a liquid-anode feed PEM electrolyzer (EZ) stack designed to electrochemically compress the reactants at balanced pressures up to 12.4 MPa (1800 psia). The fluidic conditioning, avionics, PMAD, and thermal management sub-systems are largely comprised of commercial-off-the-shelf components for this system-level development effort. The hardware is controlled by a CubeSat space processor running an operational program based on core flight architecture that can control the RFC hardware autonomously through a state machine with fault monitoring. The testing results highlighted here were completed with the system in an open-loop configuration such that reactants generated through water electrolysis were vented while gas cylinders supplied fuel cell operation. The breadboard operated autonomously, but there were five unplanned transitions to a safe state that required a manual restart after reviewing the data, determining a root cause, and implementing a solution. Four of the transitions were caused by the thermal management subsystem and the fifth was caused by a water management control issue in the EZ sub-system. The RFC system operated for over 550 hours with the final cycle being slightly abbreviated due to reasons unrelated to system performance.

Kerrigan Cain↗
NASA NTRSDate not supplied

Performance of a Regenerative Fuel Cell System for the Lunar Surface

Regenerative fuel cells (RFCs) are an attractive energy storage solution for lunar missions as a technology capable of providing a higher specific energy (i.e., W∙h/kg) than state-of-the-art packaged Li-ion battery systems. An RFC consists of the (1 & 2) electrochemical stacks (chemical to electrical energy conversion to supply electricity to an external load, i.e. the fuel cell reaction, and electrical to chemical energy conversion of supplied electrical power to dissociate water into hydrogen and oxygen gases, i.e. water electrolysis), (3) fluidic conditioning, (4) reactant storage, (5) avionics, (6) power management and distribution (PMAD), and (7) thermal management. NASA’s Glenn Research Center has designed, assembled, and tested a breadboard RFC sys-tem capable of operating autonomously for multiple simulated lunar day/night cycles in a laboratory environment. The system is comprised of a non-flow through proton exchange membrane (PEM) fuel cell stack and a liquid-anode feed PEM electrolyzer (EZ) stack designed to electrochemically compress the reactants at balanced pressures up to 12.4 MPa (1800 psia). The fluidic conditioning, avionics, PMAD, and thermal management sub-systems are largely comprised of commercial-off-the-shelf components for this system-level development effort. The hardware is controlled by a CubeSat space processor running an operational program based on core flight architecture that can control the RFC hardware autonomously through a state machine with fault monitoring. The testing results highlighted here were completed with the system in an open-loop configuration such that reactants generated through water electrolysis were vented while gas cylinders supplied fuel cell operation. The breadboard operated autonomously, but there were five unplanned transitions to a safe state that required a manual restart after reviewing the data, determining a root cause, and implementing a solution. Four of the transitions were caused by the thermal management subsystem and the fifth was caused by a water management control issue in the EZ sub-system. The RFC system operated for over 550 hours with the final cycle being slightly abbreviated due to reasons unrelated to system performance.

Kerrigan Cain↗
NASA NTRS1995

The scheme machine: A case study in progress in design derivation at system levels

The Scheme Machine is one of several design projects of the Digital Design Derivation group at Indiana University. It differs from the other projects in its focus on issues of system design and its connection to surrounding research in programming language semantics, compiler construction, and programming methodology underway at Indiana and elsewhere. The genesis of the project dates to the early 1980's, when digital design derivation research branched from the surrounding research effort in programming languages. Both branches have continued to develop in parallel, with this particular project serving as a bridge. However, by 1990 there remained little real interaction between the branches and recently we have undertaken to reintegrate them. On the software side, researchers have refined a mathematically rigorous (but not mechanized) treatment starting with the fully abstract semantic definition of Scheme and resulting in an efficient implementation consisting of a compiler and virtual machine model, the latter typically realized with a general purpose microprocessor. The derivation includes a number of sophisticated factorizations and representations and is also deep example of the underlying engineering methodology. The hardware research has created a mechanized algebra supporting the tedious and massive transformations often seen at lower levels of design. This work has progressed to the point that large scale devices, such as processors, can be derived from first-order finite state machine specifications. This is roughly where the language oriented research stops; thus, together, the two efforts establish a thread from the highest levels of abstract specification to detailed digital implementation. The Scheme Machine project challenges hardware derivation research in several ways, although the individual components of the system are of a similar scale to those we have worked with before. The machine has a custom dual-ported memory to support garbage collection. It consists of four tightly coupled processes--processor, collector, allocator, memory--with a very non-trivial synchronization relationship. Finally, there are deep issues of representation for the run-time objects of a symbolic processing language. The research centers on verification through integrated formal reasoning systems, but is also involved with modeling and prototyping environments. Since the derivation algebra is basd on an executable modeling language, there is opportunity to incorporate design animation in the design process. We are looking for ways to move smoothly and incrementally from executable specifications into hardware realization. For example, we can run the garbage collector specification, a Scheme program, directly against the physical memory prototype, and similarly, the instruction processor model against the heap implementation.

Johnson, Steven D.↗