Search NASA⌕ Search

SEARCH · Search NASA

Results for “debugging”

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 451 records · Page 25
All sourcesNASA NTRSDOE OSTI
NASA NTRS2018

Validation & Verification of Electrical Components B2 Test Facility

The research focus of this project is to assist in the closure of Measurement, Monitoring and Control System (MMCS) and other electrical requirements in support of the B2 Space Launch System (SLS) Core Stage Green Run Test Project. Alongside this goal I am to understand project management tools to analyze and control activities/tasks associated with those items. The project I am working on will assist electrical engineers in developing and or identifying closure rationale for the MMCS and electrical requirements. Also as serving the role of a training project manager, I am to develop and maintain a method for tracking progress with estimate completion dates specifically identifying those items during this performance window. The methods I used in order to perform the research consisted of worddocuments, excel sheets, and pdf documents needed for review. For example, documents consisted of: a SLS Core Stage Green Run Facility Requirement Document (FRD) identifying the SSC MMCS and electrical requirements, a Stage Controller to SSC Interface Control Document (ICD) identifying the SSC requirements, and the B2 SLS Core Stage Green Run Test project System Requirements Document (SRD) which identifies the MMCS and electrical requirements. The files were sent to me by both mentors, Mr. Barry Robinson and Ms. Dawn Davis. Overall, the review process for the word documents and excel spreadsheets proved to be successful. The data for the electrical components were accurate and were consistent with the original recorded data. However, the consistency with the pdf documents did not follow up all the way. Attention to this mistake was made and further revisions were done in order for the data to agree with each other. Furthermore, an itinerary was designed using Microsoft Outlook in order to track progress with estimated completion dates. This project contributes to NASA/Center Missions and Goals through the Waterfall Model. The Waterfall Model is a linear system used for engineering design. In the Waterfall Model, the fourth step is Verification and Validation. This involves installation, testing, and debugging of the B2 SLS Core Stage electrical components. For the SLS Core Stage Green Run Test Project, each requirement contained in this approved requirements set will have at least one Verification Item (VI) assigned to it. During the design phase, VIs will mostly consist of Analysis or Inspection types. Design phase VIs and closure information will be documented in Dynamics Data Management System (DDMS) in the form of analysis reports and design documentation.

Bastian, Tyler↗
NASA NTRS2018

LADEE Simulation for Mission Operations

The Lunar Atmosphere Dust Environment Explorer (LADEE) model-based spacecraft simulator has been discussed previously at the Workshop on Spacecraft Flight Software including the verification and validation of the flight software, hardware integration of payloads, and multi-domain simulation. In addition to flight software development and testing the LADEE simulator was used by Mission Operations to develop and test spacecraft command scripts, train operators during mission simulations, verification of all tactical command sequence files uploaded to spacecraft during flight.This presentation will discuss the experience of the LADEE operations team using the spacecraft simulator including implementation, processes and lessons learned. We will also discuss a specific instance where the simulator was used in operations to debug and design a software fix for a spacecraft anomaly experienced with the star tracker.

Operations↗
NASA NTRS2017

Generating Real-Time Robotics Control Software from SysML

In this paper, we outline an approach for autogenerating real-time robotics control code from hierarchical state machines and hardware configurations encoded in Systems Modeling Language (SysML). We propose a software architecture that provides an abstract SysML layer with access to device state information and a set of primitive device commands, such as move actuator and release brake, allowing a user to build up a complete functional state machine directly in SysML. The SysML diagram is then exported to a standard SCXML file format and subsequently used to auto-generate hardware control code. Once this architecture is in place, the only explicit code elements that need to be written are the primitive device commands, which can be easily unit tested and reused across different systems. The motivation for this work was the need for a test bed that enables the rapid prototyping of mechanisms and control algorithms for a spacecraft that could ultimately be used for preparing Martian rock samples for their return to Earth. To this end, our software system was also designed to allow for the run-time specification of the hardware layout in SysML, with the hardware-level control functions kept agnostic to the specific parameters or communication bus of any particular device. Further, we outline a system for specifying both the state machine and hardware configuration in the MagicDraw IDE in such a way that the system can be simulated before any code is generated. The resultant software system is easy to debug, understand, and allows users to choose how much information is encoded as a visual or text-based representation.

Godart, Peter↗
NASA NTRS2019

Testbed Requirements to Enable New Observing Strategies

Emerging capabilities to integrate instruments on smallsats, airborne platforms and in situ devices into an intelligent, distributed observing strategy show great promise for measuring Earth science natural phenomena and physical processes that have not previously been characterized. To reduce the threshold for success in deploying such an intelligent, integrated observing strategy, a ground-based testbed system is proposed. Virtually all of the technologies needed for using such a tool have matured to the point of being used, individually. Virtually none of the technologies have been deployed, working together. The technologies to be deployed should be integrated into a working "breadboard" where the components can be debugged and performance and behavior characterized and tuned-up. A system of this complexity should not be expected to work without full integration and experimental characterization. Further, and perhaps more importantly, in order to successfully propose a space-based element to this strategy, teams must convince the relevant science community that the risk is low enough to warrant the investment. The main benefit of the testbed is to retire the risk of integrating these new technologies and increase the Technology Readiness Level (TRL) of each component as well as the System Readiness Level (SRL) of the integrated system.

Little, Mike↗
NASA NTRS2017

YADA: Yet Another Distributed Architecture for Real-Time Robotic Control Systems

This paper presents YADA, a new software architecture for real-time robotic control systems that is minimal, modular, and fully transparent. YADA divides control software into decoupled behavior, user-interface, and hardware-level bus modules. This decoupling at the module level is accomplished by auto-generating human-readable message types that are tailored to the hardware topology oft he current system. These message types provide modules with a common framework for exchanging state information and relaying commands to devices while being agnostic to the communication protocol itself. We also detail how to structure behavior and bus modules to facilitate modularity and flexibility with third party software. YADA has been used with success on several technology development testbeds at JPL, an example of which is given in this paper, and has proven to provide developers a light-weight and highly reconfigurable system for efficient debugging and practical code sharing

Godart, Peter↗
NASA NTRS2020

LaRC SmartLab Apps For Instrument Control and Data Processing: Laboratory Environment Monitor

The LaRC SmartLab applications are a series of software tools to greatly enhance researcher efficiency by streamlining and automating workflows. Python scripts and applications are increasingly being used in scientific workflows, including for instrument control and data processing. Interactive Python scripting environments such as JupyterLab provide powerful tools for using Python. In some use cases, the development of standalone applications with dedicated graphical user interfaces can enhance the utility of the code and open it up to more users, including non-programmers. Here, we describe a Python based application for communicating with, and displaying data from, iTHX Temperature, Humidity, and Dew Point probes. We discuss the set up and use of the application as well as its implementation. We also highlight the use of Simulated probes to enable users and developers to familiarize with or debug the application, even when they do not have access to the physical hardware in the laboratory.

LaRC SmartLab↗
NASA NTRS2003

UCLA parallel PIC framework

The UCLA Parallel PIC Framework (UPIC) has been developed to provide trusted components for the rapid construction of new, parallel Particle-in-Cell (PIC) codes. The Framework uses object-based ideas in Fortran95, and is designed to provide support for various kinds of PIC codes on various kinds of hardware. The focus is on student programmers. The Framework supports multiple numerical methods, different physics approximations, different numerical optimizations and implementations for different hardware. It is designed with "defensive" programming in mind, meaning that it contains many error checks and debugging helps. Above all, it is designed to hide the complexity of parallel processing. It is currently being used in a number of new Parallel PIC codes.

Norton, Charles D.↗
NASA NTRS2018

SpaceWire as a Cube-Sat Instrument Interface

SpaceWire is used in the control and data interface for an instrument on a pair of small satellites, one of which was launched in summer 2017. The instrument SpaceWire interface is implemented in a Field Programmable Gate Array as an instantiated core controlled by a LEON3FT CPU, which is also implemented as an instantiated core. The UT699 processor in the flight computer provides the spacecraft side’s SpaceWire interface. A simple message based protocol consisting of four message types was defined, based on existing SpaceWire standards. One was for passing commands to and responses from the instrument in the form of text strings similar to those from a system console where each line of text is passed in a SpaceWire message. Another was for passing spacecraft time to the instrument. The third was for transferring files using a subset of the Remote Memory Access Protocol (RMAP). The fourth was for retrieving science data from the instrument. A set of user application programming interface (API) routines provided an abstracted interface to both the serial console (used during debug) and the SpaceWire device interface. Early instrument development and testing was done with a set of utilities that controlled a Star-Dundee USB-SpaceWire brick providing a user interface similar to a serial console terminal emulator with the addition of file and data transfers. Later in the integration and test process, these utilities were integrated with the COSMOS ground systems software used for spacecraft control, providing a seamless transition from standalone instrument tests to benchtop flat-sat test and full spacecraft level tests.

Lux, James P.↗
NASA NTRS2020

Blackbird: Object-Oriented Planning, Simulation, and Sequencing Framework Used by Multiple Missions

Every JPL flight mission relies on activity planningand sequence generation software to perform operations. Mostsuch tools in use at JPL and elsewhere use attribute-basedschemas or domain-specific languages (DSLs) to defineactivities. This reliance poses user training, softwaremaintenance, performance, and other challenges. To solve thisproblem for future missions, a new software called Blackbirdwas developed which allows engineers to specify behavior instandard Java. The new code base has over an order ofmagnitude fewer lines of code than other JPL planningsoftware, since no DSL or schema interpreter is needed. Theuse of Java for defining activities also allows mission adaptersto debug their code in an integrated development environment,seamlessly call external libraries, and set up truly multimissionmodels. These efficiency gains have significantlyreduced the amount of development effort required to supportthe software. This paper discusses Blackbird’s design,principles, and use cases.

Rothstein-Dowden, Ansel↗
NASA NTRSDate not supplied

Formal Specification and Parametric Verification of the ICAROUS Distributed Merging Protocol for Autonomous Aircraft Systems

ICAROUS is a software architecture that provides highly assured core software modules for building safety-centric autonomous unmanned aircraft applications. One of its core components is the ICAROUS distributed merging (IDM) protocol, which allows for decentralized merging of autonomous aircrafts through a designated intersection. This report presents initial results on formal specification and parametric verification of the IDM protocol. We present the development of a formal, discrete-time specification of the ICAROUS distributed merging protocol in TLA+. The developed TLA+ specification includes an abstracted model of the physical aircraft dynamics, the consensus machinery for leader election and coordination, and the computation of merging schedules. In addition, we present details on a command line tool we developed verimerge, that utilizes the TLC model checker for doing bounded, parametric verification and allows for plotting of these results in 2D parameter spaces. The tool also provides functionality for visualization of concrete protocol behaviors, to aid debugging and understanding. We present preliminary, bounded time verification results for a finite number of aircraft. Limitations of the current techniques and possible future extensions of this work are also discussed.

ICAROUS↗
NASA NTRS2020

Blackbird: Object-Oriented Planning, Simulation, and Sequencing Framework Used by Multiple Missions

Every JPL flight mission relies on activity planning and sequence generation software to perform operations. Most such tools in use at JPL and elsewhere use attribute-based schemas or domain-specific languages (DSLs) to define activities. This reliance poses user training, software maintenance, performance, and other challenges. To solve this problem for future missions, a new software called Blackbird was developed which allows engineers to specify behavior in standard Java. The new code base has over an order of magnitude fewer lines of code than other JPL planning software, since no DSL or schema interpreter is needed. The use of Java for defining activities also allows mission adapters to debug their code in an integrated development environment, seamlessly call external libraries, and set up truly multimission models. These efficiency gains have significantly reduced the amount of development effort required to support the software. This paper discusses Blackbird’s design, principles, and use cases.

Lawler, Christopher↗
NASA NTRSDate not supplied

Feature-Guided Analysis of Neural Networks

Applying standard software engineering practices to neural networks is challenging due to the lack of high-level abstractions describing a neural network’s behavior. To address this challenge, we propose to extract high-level task-specific features from the neural network internal representation, based on monitoring the neural network activations.The extracted feature representations can serve as a link to high-level requirements and can be leveraged to enable fundamental software engineering activities, such as automated testing, debugging, requirements analysis, and formal verification, leading to better engineering of neural networks. Using two case studies, we present initial empirical evidence demonstrating the feasibility of our ideas.

Features↗
NASA NTRSDate not supplied

X-57 Cockpit Display System Development and Features

The X-57 Maxwell airplane [1,2] cockpit display system includes multiple, pilot-selectable pages in a multifunction display with detailed statuses of critical parameters from each of the cruise motors (CMs), cruise motor controllers (CMCs), and battery control modules (BCMs), as well as air temperature measurements at reference locations in the passive ram-air cooling ducts for the motors, controllers, and auxiliary equipment. The user (pilot or ground-test crew) can select overview pages that are part of the standard instrument panel scan pattern or switch to a series of detail or debug pages as the system is operating using a rotary position switch in the cockpit. This paper presents and describes each of these displays, and gives an overview of the development and verification process. The critical data condensed for cockpit handling from each of the major electric propulsion and traction power systems are discussed.

Adam Curry↗
NASA NTRS2022

Neurosymbolic Hybrid Approach to Driver Collision Warning

There are two main algorithmic approaches to autonomous driving systems: (1) An end-to-end system in which a single deep neural network learns to map sensory input directly into appropriate warning and driving responses. (2) A mediated hybrid recognition system in which a system is created by combining independent modules that detect each semantic feature. While some researchers believe that deep learning can solve any problem, others believe that a more engineered and symbolic approach is needed to cope with complex environments with less data. Deep learning alone has achieved state-of-the-art results in many areas, from complex gameplay to predicting protein structures. In particular, in image classification and recognition, deep learning models have achieved accuracies as high as humans. But sometimes it can be very difficult to debug if the deep learning model doesn't work. Deep learning models can be vulnerable and are very sensitive to changes in data distribution. Generalization can be problematic. It's usually hard to prove why it works or doesn't. Deep learning models can also be vulnerable to adversarial attacks. Here, we combine deep learning-based object recognition and tracking with an adaptive neurosymbolic network agent, called the Non-Axiomatic Reasoning System (NARS), that can adapt to its environment by building concepts based on perceptual sequences. We achieved an improved intersection-over-union (IOU) object recognition performance of 0.65 in the adaptive retraining model compared to IOU 0.31 in the COCO data pre-trained model. We improved the object detection limits using RADAR sensors in a simulated environment, and demonstrated the weaving car detection capability by combining deep learning-based object detection and tracking with a neurosymbolic model.

Wang, Pei↗
NASA NTRSDate not supplied

Fostering Better Collaboration in Software Development Cycles Between Scientists and Programmers to Ensure the Integrity of and Promote the Development of New Scientific Data Products.

Misaligned incentives lead to reduced interaction between scientists and programmers on modern NASA science data-product development teams. Typically, situations arise where the scientist is not incentivized to learn modern coding practices and the programmer does not understand the science algorithms in the code. A programmer is responsible for the deliverable code thus setting a tradeoff between the desire for code improvement versus fear of compromising the integrity of data-product while the scientist continues to rely on their legacy codebases owing to the complexity of using the delivered code outside the processing environment and lack of validation modules. The NASA/CERES-TISA project has adopted a collaborative approach, with scientists and programmers both utilizing the same software repository with multiple branches, some optimized for delivery to a processing datacenter and others for scientific product development and validation. A team of scientists and programmers jointly review any new science code updates for integration into the codebase and strive to improve practices through promoting algorithm understanding, better institutional knowledge exchange and documentation, modularization, and developing data processing flow-dictated validation and debugging methods. This leads to a reduction in the personnel single point failures and reduced development time for creation of new science data-products.

CERES↗
NASA NTRS2024

Logic Programming with Extensible Types

Logic programming allows structuring code in terms of predicates or relations, rather than functions. Although logic programming languages present advantages in terms of declarativeness and conciseness, the introduction of static types has not become part of most popular logic programming languages, increasing the difficulty of testing and debugging of logic programming code. This paper demonstrates how to implement logic programming in Haskell, thus empowering logic programs with types, and functional programs with relations or predicates. We do so by combining three ideas. First, we use extensible types to generalize a type by a parameter type function. Second, we use a sum type as an argument to introduce optional variables in extensible types. Third, we implement a unification algorithm capable of working with any data structure, provided that certain operations are implemented for the given type. We demonstrate our proposal via a series of increasingly complex examples inspired by educational texts in logic programming, and leverage the host language's features to make new notation convenient for users, showing that the proposed approach is not just technically possible but also practical.

logic programming↗
DOE OSTI2014

Handling debugger breakpoints in a shared instruction system

A debugger debugs processes that execute shared instructions so that a breakpoint set for one process will not cause a breakpoint to occur in the other processes. A breakpoint is set by recording the original instruction at the desired location and writing a trap instruction to the shared instructions at that location. When a process encounters the breakpoint, the process passes control to the debugger for breakpoint processing if the breakpoint was set at that location for that process. If the trap was not set at that location for that process, the cacheline containing the trap is copied to a small scratchpad memory, and the virtual memory mappings are changed to translate the virtual address of the cacheline to the scratchpad. The original instruction is then written to replace the trap instruction in the scratchpad, so that process can execute the instructions in the scatchpad thereby avoiding the trap instruction.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2016

DebuggingDemo v. 1.0

Intentionally simple buggy code created for use in a debugging demonstration as part of recruiting tech talks. Code exemplifies a buffer overflow, leading to return address corruption. Code also demonstrates unused return value.

Gaines, Sherry↗