SEARCH · Search NASA

Results for “Command Error Detection”

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.

SourceResearch connectionFrom yearThrough year

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

62 records · Page 4

All sources NASA NTRS DOE OSTI

DOE OSTI2017

Development of the Delphi display concept for alternative explanations decision making support - 120

Human operators of advanced technology systems, such as nuclear power, command and control, and deepwater oil drilling, must be able to evaluate and respond to a wide array of operational anomalies. Unfortunately, these circumstances are often complex and ambiguous, complicating decision making tasks. One common decision making error, called confirmation bias, occurs when decision makers prematurely focus on one explanation instead of systematically considering all plausible alternative explanations that could equally well account for an operational anomaly (Nickerson, 1998). The Delphi display is designed to counteract decision makers' tendencies towards confirmation bias and to encourage them to consider all plausible explanations, including high risk explanations, they might otherwise overlook. An initial Delphi display prototype was designed to help identify the underlying cause of operational anomalies in the complex, high-consequence technology of deepwater drilling. This prototype decision aid incorporates major indicators related to operational anomalies and presents corresponding plausible explanations for each indicator, ranging from high-risk system-critical explanations to lower-risk but still significant events. The Delphi display incorporates several innovative features to help decision makers detect and monitor operational anomalies and view the relationships among indicators and their associated plausible explanations. Preliminary evaluations of an early prototype Delphi display for detecting kicks in deepwater oil drilling operations have been promising. Moreover, the methodology used to design and develop the Delphi display can be readily generalized to numerous other operational contexts that require humans to make system-critical decisions. To illustrate, an initial Delphi display design for nuclear power plant control is described. (authors)

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

NASA NTRS2011

Digital Interface Board to Control Phase and Amplitude of Four Channels

An increasing number of parts are designed with digital control interfaces, including phase shifters and variable attenuators. When designing an antenna array in which each antenna has independent amplitude and phase control, the number of digital control lines that must be set simultaneously can grow very large. Use of a parallel interface would require separate line drivers, more parts, and thus additional failure points. A convenient form of control where single-phase shifters or attenuators could be set or the whole set could be programmed with an update rate of 100 Hz is needed to solve this problem. A digital interface board with a field-programmable gate array (FPGA) can simultaneously control an essentially arbitrary number of digital control lines with a serial command interface requiring only three wires. A small set of short, high-level commands provides a simple programming interface for an external controller. Parity bits are used to validate the control commands. Output timing is controlled within the FPGA to allow for rapid update rates of the phase shifters and attenuators. This technology has been used to set and monitor eight 5-bit control signals via a serial UART (universal asynchronous receiver/transmitter) interface. The digital interface board controls the phase and amplitude of the signals for each element in the array. A host computer running Agilent VEE sends commands via serial UART connection to a Xilinx VirtexII FPGA. The commands are decoded, and either outputs are set or telemetry data is sent back to the host computer describing the status and the current phase and amplitude settings. This technology is an integral part of a closed-loop system in which the angle of arrival of an X-band uplink signal is detected and the appropriate phase shifts are applied to the Ka-band downlink signal to electronically steer the array back in the direction of the uplink signal. It will also be used in the non-beam-steering case to compensate for phase shift variations through power amplifiers. The digital interface board can be used to set four 5-bit phase shifters and four 5-bit attenuators and monitor their current settings. Additionally, it is useful outside of the closed-loop system for beamsteering alone. When the VEE program is started, it prompts the user to initialize variables (to zero) or skip initialization. After that, the program enters into a continuous loop waiting for the telemetry period to elapse or a button to be pushed. A telemetry request is sent when the telemetry period is elapsed (every five seconds). Pushing one of the set or reset buttons will send the appropriate command. When a command is sent, the interface status is returned, and the user will be notified by a pop-up window if any error has occurred. The program runs until the End Program button is depressed.

Smith, Amy E.↗

NASA NTRS2008

Automatic Testcase Generation for Flight Software

The TacSat3 project is applying Integrated Systems Health Management (ISHM) technologies to an Air Force spacecraft for operational evaluation in space. The experiment will demonstrate the effectiveness and cost of ISHM and vehicle systems management (VSM) technologies through onboard operation for extended periods. We present two approaches to automatic testcase generation for ISHM: 1) A blackbox approach that views the system as a blackbox, and uses a grammar-based specification of the system's inputs to automatically generate *all* inputs that satisfy the specifications (up to prespecified limits); these inputs are then used to exercise the system. 2) A whitebox approach that performs analysis and testcase generation directly on a representation of the internal behaviour of the system under test. The enabling technologies for both these approaches are model checking and symbolic execution, as implemented in the Ames' Java PathFinder (JPF) tool suite. Model checking is an automated technique for software verification. Unlike simulation and testing which check only some of the system executions and therefore may miss errors, model checking exhaustively explores all possible executions. Symbolic execution evaluates programs with symbolic rather than concrete values and represents variable values as symbolic expressions. We are applying the blackbox approach to generating input scripts for the Spacecraft Command Language (SCL) from Interface and Control Systems. SCL is an embedded interpreter for controlling spacecraft systems. TacSat3 will be using SCL as the controller for its ISHM systems. We translated the SCL grammar into a program that outputs scripts conforming to the grammars. Running JPF on this program generates all legal input scripts up to a prespecified size. Script generation can also be targeted to specific parts of the grammar of interest to the developers. These scripts are then fed to the SCL Executive. ICS's in-house coverage tools will be run to measure code coverage. Because the scripts exercise all parts of the grammar, we expect them to provide high code coverage. This blackbox approach is suitable for systems for which we do not have access to the source code. We are applying whitebox test generation to the Spacecraft Health INference Engine (SHINE) that is part of the ISHM system. In TacSat3, SHINE will execute an on-board knowledge base for fault detection and diagnosis. SHINE converts its knowledge base into optimized C code which runs onboard TacSat3. SHINE can translate its rules into an intermediate representation (Java) suitable for analysis with JPF. JPF will analyze SHINE's Java output using symbolic execution, producing testcases that can provide either complete or directed coverage of the code. Automatically generated test suites can provide full code coverage and be quickly regenerated when code changes. Because our tools analyze executable code, they fully cover the delivered code, not just models of the code. This approach also provides a way to generate tests that exercise specific sections of code under specific preconditions. This capability gives us more focused testing of specific sections of code.

Bushnell, David Henry↗

NASA NTRS2006

Anomaly Recovery and the Mars Exploration Rovers

The premise of the design of operations for the Mars Exploration Rovers (MER) is that the vehicles will drive each day. As a result, they will encounter some aspect of the terrain environment that cannot be anticipated or otherwise accommodated by the sequences linked onboard that day. The operations team then must correct the problem by planning then commanding the execution of a different drive the next day. Often other aspects of the operation on the surface of Mars: environmental changes, component degradation, errors in sequence design or execution, etc., lead to anomalies which must be addressed before normal operations can resume. The operational design that makes it possible to recover from a driving error each day also reduces the time needed to recover from anomalies. As an example of the efficiency achieved, less than 5% (about 30 sols out of 700 sols of operations) of the time on the surface has been devoted to recovery from anomalies for each vehicle. In this paper the major anomalies experienced by the MER rovers will be recounted and the streamlined approaches to addressing these problems described. The operational flexibility developed for these missions is also a function of the system design that anticipated a number of likely faults and conditions arising from uncertainty in sequence execution and environmental change. This design will be described as well as the considerations in operation that motivated this design. These considerations will likely be present in any future surface mission.

rovers↗

NASA NTRS2011

NASA Tech Briefs, May 2011

Topics covered include: 1) Method to Estimate the Dissolved Air Content in Hydraulic Fluid; 2) Method for Measuring Collimator-Pointing Sensitivity to Temperature Changes; 3) High-Temperature Thermometer Using Cr-Doped GdAlO3 Broadband Luminescence; 4)Metrology Arrangement for Measuring the Positions of Mirrors of a Submillimeter Telescope; 5) On-Wafer S-Parameter Measurements in the 325-508-GHz Band; 6) Reconfigurable Microwave Phase Delay Element for Frequency Reference and Phase-Shifter Applications; 7) High-Speed Isolation Board for Flight Hardware Testing; 8) High-Throughput, Adaptive FFT Architecture for FPGA-Based Spaceborne Data Processors; 9) 3D Orbit Visualization for Earth-Observing Missions; 10) MaROS: Web Visualization of Mars Orbiting and Landed Assets; 11) RAPID: Collaborative Commanding and Monitoring of Lunar Assets; 12) Image Segmentation, Registration, Compression, and Matching; 13) Image Calibration; 14) Rapid ISS Power Availability Simulator; 15) A Method of Strengthening Composite/Metal Joints; 16) Pre-Finishing of SiC for Optical Applications; 17) Optimization of Indium Bump Morphology for Improved Flip Chip Devices; 18) Measuring Moisture Levels in Graphite Epoxy Composite Sandwich Structures; 19) Marshall Convergent Spray Formulation Improvement for High Temperatures; 20) Real-Time Deposition Monitor for Ultrathin Conductive Films; 21) Optimized Li-Ion Electrolytes Containing Triphenyl Phosphate as a Flame-Retardant Additive; 22) Radiation-Resistant Hybrid Lotus Effect for Achieving Photoelectrocatalytic Self-Cleaning Anticontamination Coatings; 23) Improved, Low-Stress Economical Submerged Pipeline; 24) Optical Fiber Array Assemblies for Space Flight on the Lunar Reconnaissance Orbiter; 25) Local Leak Detection and Health Monitoring of Pressurized Tanks; 26) Dielectric Covered Planar Antennas at Submillimeter Wavelengths for Terahertz Imaging; 27) Automated Cryocooler Monitor and Control System; 28) Broadband Achromatic Phase Shifter for a Nulling Interferometer; 29) Super Dwarf Wheat for Growth in Confined Spaces; 30) Fine Guidance Sensing for Coronagraphic Observatories; 31) Single-Antenna Temperature- and Humidity-Sounding Microwave Receiver; 32) Multi-Wavelength, Multi-Beam, and Polarization-Sensitive Laser Transmitter for Surface Mapping; 33) Optical Communications Link to Airborne Transceiver; 34) Ascent Heating Thermal Analysis on Spacecraft Adaptor Fairings; 35) Entanglement in Self-Supervised Dynamics; 36) Prioritized LT Codes; 37) Fast Image Texture Classification Using Decision Trees; 38) Constraint Embedding Technique for Multibody System Dynamics; 39) Improved Systematic Pointing Error Model for the DSN Antennas; 40) Observability and Estimation of Distributed Space Systems via Local Information-Exchange Networks; 41) More-Accurate Model of Flows in Rocket Injectors; 42) In-Orbit Instrument-Pointing Calibration Using the Moon as a Target; 43) Reliability of Ceramic Column Grid Array Interconnect Packages Under Extreme Temperatures; 44) Six Degrees-of-Freedom Ascent Control for Small-Body Touch and Go; and 45) Optical-Path-Difference Linear Mechanism for the Panchromatic Fourier Transform Spectrometer.

Source record↗

NASA NTRS2014

The CCSDS Next Generation Space Data Link Protocol (NGSLP)

The CCSDS space link protocols i.e., Telemetry (TM), Telecommand (TC), Advanced Orbiting Systems (AOS) were developed in the early growth period of the space program. They were designed to meet the needs of the early missions, be compatible with the available technology and focused on the specific link environments. Digital technology was in its infancy and spacecraft power and mass issues enforced severe constraints on flight implementations. Therefore the Telecommand protocol was designed around a simple Bose, Hocquenghem, Chaudhuri (BCH) code that provided little coding gain and limited error detection but was relatively simple to decode on board. The infusion of the concatenated Convolutional and Reed-Solomon codes5 for telemetry was a major milestone and transformed telemetry applications by providing them the ability to more efficiently utilize the telemetry link and its ability to deliver user data. The ability to significantly lower the error rates on the telemetry links enabled the use of packet telemetry and data compression. The infusion of the high performance codes for telemetry was enabled by the advent of digital processing, but it was limited to earth based systems supporting telemetry. The latest CCSDS space link protocol, Proximity-1 was developed in early 2000 to meet the needs of short-range, bi-directional, fixed or mobile radio links characterized by short time delays, moderate but not weak signals, and short independent sessions. Proximity-1 has been successfully deployed on both NASA and ESA missions at Mars and is planned to be utilized by all Mars missions in development. A new age has arisen, one that now provides the means to perform advanced digital processing in spacecraft systems enabling the use of improved transponders, digital correlators, and high performance forward error correcting codes for all communications links. Flight transponders utilizing digital technology have emerged and can efficiently provide the means to make the next leap in performance for space link communications. Field Programmable Gate Arrays (FPGAs) provide the capability to incorporate high performance forward error correcting codes implemented within software transponders providing improved performance in data transfer, ranging, link security, and time correlation. Given these synergistic technological breakthroughs, the time has come to take advantage of them in applying them to both on going (e.g., command, telemetry) and emerging (e.g., space link security, optical communication) space link applications. However one of the constraining factors within the Data Link Layer in realizing these performance gains is the lack of a generic transfer frame format and common supporting services amongst the existing CCSDS link layer protocols. Currently each of the four CCSDS link layer protocols (TM, TC, AOS, and Proximity-1) have unique formats and services which prohibits their reuse across the totality of all space link applications of CCSDS member space agencies. For example, Mars missions. These missions implement their proximity data link layer using the Proximity-1 frame format and the services it supports but is still required to support the direct from Earth (TC) protocols and the Direct To Earth (AOS/TM) protocols. The prime purpose of this paper, is to describe a new general purpose CCSDS Data Link layer protocol, the NGSLP that will provide the required services along with a common transfer frame format for all the CCSDS space links (ground to/from space and space to space links) targeted for emerging missions after a CCSDS agency-wide coordinated date. This paper will also describe related options that can be included for the Coding and Synchronization sub-layer of the Data Link layer to extend the capacities of the link and additionally provide an independence of the transfer frame sub-layer from the coding sublayer. This feature will provide missions the option of running either the currently performed synchronous coding and transfer frame data link or an asynchronous coding/frame data link, in which the transfer frame length is independent of the block size of the code. The benefits from the elimination of this constraint (frame synchronized to the code block) will simplify the interface between the transponder and the data handling equipment and reduce implementation costs and complexities. The benefits include: inclusion of encoders/decoders into transmitters and receivers without regard to data link protocols, providing the ability to insert latency sensitive messages into the link to support launch, landing/docking, telerobotics. and Variable Coded Modulation (VCM). In addition the ability to transfer different sized frames can provide a backup for delivering stored anomaly engineering data simultaneously with real time data, or relaying of frames from various sources onto a trunk line for delivery to Earth.

Kazz, Greg J.↗

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 NTRS2018

The Utilization Profiles of the CCSDS Unified Space Link Protocol (USLP)

The purpose of this paper is to identify the utilization profiles for interfacing the Data Protocol Sublayer using the Unified Space Link Protocols (USLP) (reference 1) with the space link coding procedures as specified in the CCSDS Coding & Synchronization Blue Books (references 2 through 5), used in both telecommand and telemetry applications. This paper describes how the USLP Protocol utilizes the coding and synchronization sublayer to support: a. Direct to Earth (DTE) telemetry links for engineering and science data b. Direct to Earth (DTE) telemetry links for very high rate science data c. Direct from Earth (DFE) command, sequencing and flight software loads d. Space to Space Links (Proximity) utilized by orbiters for data exchange to/from surface bound assets. The CCSDS has divided the functions of the Data Link Layer into two sublayers: the Data Link Protocol Sublayer (DLP-SL) and the Coding and Synchronization Sublayer (CS-SL). The Data Link Protocol Sublayer (DLP-SL) interfaces to the users, accepting the data that is to be transported, on the sending side of the link, and delivering that data on the receiving end. The Transfer Frame is the data unit that is transferred across the Data Link Protocol Sublayer and the Coding and Synchronization Sublayer boundary. The Coding and Synchronization Sublayer (CS-SL) provides the encoding, randomization, and frame synchronization functions that prepares the USLP Transfer Frame for transport across the space link. The CS-SL is divided into 2 processes: 1) The Frame Interface Processes (FIP) performs the interface functions required to prepare the data for delivery to the Coding/Decoding Process (CDP). This process includes prepending a Frame Start Marker to the provided frame, when management has designated that the frame is not to be aligned to the codeblock or when there is no block code used. 2) The Coding/Decoding Process (CDP) performs the forward error correction processes that are used to optimize the performance of the link and minimize the error rate. The CDP creates the symbol stream that is delivered to the Physical Layer. The transfer of the USLP transfer frames across different types of space links is the focus of this paper. The Protocol Data Unit (PDU) that is passed in both directions between the Data Link Protocol Sublayer (DLP-SL) and Coding and Synchronization Sublayer (CS-SL) is the transfer frame. The USLP frame structure provides flexibility that can be constrained by the functions utilized within the CS-SL that prepare the transfer frame for transit. For example, the USLP transfer frame contains a length field that enables the frame to be of variable length but CS-SL under certain conditions may constrain the frame to be fixed in length. This paper describes 5 operational modes available for use by the Data Link Layer to provide data exchange across the USLP space link. These modes are different because different operational requirements apply to vastly different types of space links and thus the communications implementation requirements differ. The environmental issues include the power or energy available, the distance between the end points of the link, the complexity of the equipment available at those end points, the atmospheric conditions and radiometric frequency selection. The CS-SL utilizes different forward error correcting codes supported by specific operational modes to configure the data for transit. This paper describes all of the operational modes in a series of data models which decompose the functionality between the Data Link Protocol Sublayer and the Coding and Synchronization sublayer. The operational modes described are: 1. Uncoded Mode: has been used for short links that contain significant available power to provide an acceptable frame error rate. The frames in this mode can be variable in length and typically use an error detection algorithm (i.e., CRC) to determine if there are errors in the received frame. 2. Convolutional Only Mode: is currently the prime forward error correction coding used for the proximity links. The frames in this mode can be variable in length and typically use an error detection algorithm (i.e., CRC) to determine if there are errors in the received frame. 3. Variable Length Frame Aligned to Variable Length Codeblock (TC): is used for Direct from Earth links were power levels are high and the simple, least complex code i.e., the BCH code is used. This mode has been in use since the early 1970s. The BCH code is a short code and the decoder is easy to implement. 4. Fixed Length Frame Aligned to Fixed Length Codeblock (AOS/TM): was introduced when the concatenated Convolutional and Reed-Solomon Code was formulated to provide significant reduction in link data error rate and the ability to determine if there was an error in the decoded codeblock. The frame is aligned to the codeblock so that there is a one to one relationship of frame errors to codeblock errors without additional error detection coding being added. This mode requires the protocol frames to be the exact size of the message portion of the codeblock. 5. Frames Unaligned to Fixed Length Codeblocks (Currently used for very high rates and space to space links): This mode is currently used for missions that have a very high data rate that can be controlled adaptively as the environment changes and as the next generation operating mode for the proximity link. This mode from a coded data stream point of view is exactly like that described in 4. above, except that the frame need not be aligned to the codeblock. There is no requirement on frame length when using this mode. Thus when using USLP it can be used to support links that require short or long frames. There is also no mandatory requirement that frames cannot be separated by idle data reducing the tight data rate connection requirements between the data link protocol sublayer and the coding & synchronization sublayer. In conclusion, how these operational modes can be put to use in mission operational scenarios is described for Direct from Earth links (DFE), Direct to Earth links (DTE), and Proximity links.

Greenberg, E.↗