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 307 records · Page 17
All sourcesNASA NTRSDOE OSTI
NASA NTRS2013

Shock Position Control for Mode Transition in a Turbine Based Combined Cycle Engine Inlet Model

A dual flow-path inlet for a turbine based combined cycle (TBCC) propulsion system is to be tested in order to evaluate methodologies for performing a controlled inlet mode transition. Prior to experimental testing, simulation models are used to test, debug, and validate potential control algorithms which are designed to maintain shock position during inlet disturbances. One simulation package being used for testing is the High Mach Transient Engine Cycle Code simulation, known as HiTECC. This paper discusses the development of a mode transition schedule for the HiTECC simulation that is analogous to the development of inlet performance maps. Inlet performance maps, derived through experimental means, describe the performance and operability of the inlet as the splitter closes, switching power production from the turbine engine to the Dual Mode Scram Jet. With knowledge of the operability and performance tradeoffs, a closed loop system can be designed to optimize the performance of the inlet. This paper demonstrates the design of the closed loop control system and benefit with the implementation of a Proportional-Integral controller, an H-Infinity based controller, and a disturbance observer based controller; all of which avoid inlet unstart during a mode transition with a simulated disturbance that would lead to inlet unstart without closed loop control.

Csank, Jeffrey T.↗
NASA NTRS2012

Rapid Diagnostics of Onboard Sequences

Keeping track of sequences onboard a spacecraft is challenging. When reviewing Event Verification Records (EVRs) of sequence executions on the Mars Exploration Rover (MER), operators often found themselves wondering which version of a named sequence the EVR corresponded to. The lack of this information drastically impacts the operators diagnostic capabilities as well as their situational awareness with respect to the commands the spacecraft has executed, since the EVRs do not provide argument values or explanatory comments. Having this information immediately available can be instrumental in diagnosing critical events and can significantly enhance the overall safety of the spacecraft. This software provides auditing capability that can eliminate that uncertainty while diagnosing critical conditions. Furthermore, the Restful interface provides a simple way for sequencing tools to automatically retrieve binary compiled sequence SCMFs (Space Command Message Files) on demand. It also enables developers to change the underlying database, while maintaining the same interface to the existing applications. The logging capabilities are also beneficial to operators when they are trying to recall how they solved a similar problem many days ago: this software enables automatic recovery of SCMF and RML (Robot Markup Language) sequence files directly from the command EVRs, eliminating the need for people to find and validate the corresponding sequences. To address the lack of auditing capability for sequences onboard a spacecraft during earlier missions, extensive logging support was added on the Mars Science Laboratory (MSL) sequencing server. This server is responsible for generating all MSL binary SCMFs from RML input sequences. The sequencing server logs every SCMF it generates into a MySQL database, as well as the high-level RML file and dictionary name inputs used to create the SCMF. The SCMF is then indexed by a hash value that is automatically included in all command EVRs by the onboard flight software. Second, both the binary SCMF result and the RML input file can be retrieved simply by specifying the hash to a Restful web interface. This interface enables command line tools as well as large sophisticated programs to download the SCMF and RMLs on-demand from the database, enabling a vast array of tools to be built on top of it. One such command line tool can retrieve and display RML files, or annotate a list of EVRs by interleaving them with the original sequence commands. This software has been integrated with the MSL sequencing pipeline where it will serve sequences useful in diagnostics, debugging, and situational awareness throughout the mission.

Starbird, Thomas W.↗
NASA NTRS2007

Java Programming Language

The Java seminar covers the fundamentals of Java programming language. No prior programming experience is required for participation in the seminar. The first part of the seminar covers introductory concepts in Java programming including data types (integer, character, ..), operators, functions and constants, casts, input, output, control flow, scope, conditional statements, and arrays. Furthermore, introduction to Object-Oriented programming in Java, relationships between classes, using packages, constructors, private data and methods, final instance fields, static fields and methods, and overloading are explained. The second part of the seminar covers extending classes, inheritance hierarchies, polymorphism, dynamic binding, abstract classes, protected access. The seminar conclude by introducing interfaces, properties of interfaces, interfaces and abstract classes, interfaces and cailbacks, basics of event handling, user interface components with swing, applet basics, converting applications to applets, the applet HTML tags and attributes, exceptions and debugging.

Shaykhian, Gholam Ali↗
NASA NTRS2013

Application Program Interface for the Orion Aerodynamics Database

The Application Programming Interface (API) for the Crew Exploration Vehicle (CEV) Aerodynamic Database has been developed to provide the developers of software an easily implemented, fully self-contained method of accessing the CEV Aerodynamic Database for use in their analysis and simulation tools. The API is programmed in C and provides a series of functions to interact with the database, such as initialization, selecting various options, and calculating the aerodynamic data. No special functions (file read/write, table lookup) are required on the host system other than those included with a standard ANSI C installation. It reads one or more files of aero data tables. Previous releases of aerodynamic databases for space vehicles have only included data tables and a document of the algorithm and equations to combine them for the total aerodynamic forces and moments. This process required each software tool to have a unique implementation of the database code. Errors or omissions in the documentation, or errors in the implementation, led to a lengthy and burdensome process of having to debug each instance of the code. Additionally, input file formats differ for each space vehicle simulation tool, requiring the aero database tables to be reformatted to meet the tool s input file structure requirements. Finally, the capabilities for built-in table lookup routines vary for each simulation tool. Implementation of a new database may require an update to and verification of the table lookup routines. This may be required if the number of dimensions of a data table exceeds the capability of the simulation tools built-in lookup routines. A single software solution was created to provide an aerodynamics software model that could be integrated into other simulation and analysis tools. The highly complex Orion aerodynamics model can then be quickly included in a wide variety of tools. The API code is written in ANSI C for ease of portability to a wide variety of systems. The input data files are in standard formatted ASCII, also for improved portability. The API contains its own implementation of multidimensional table reading and lookup routines. The same aerodynamics input file can be used without modification on all implementations. The turnaround time from aerodynamics model release to a working implementation is significantly reduced

Robinson, Philip E.↗
NASA NTRS2013

Advanced Shock Position Control for Mode Transition in a Turbine Based Combined Cycle Engine Inlet Model

A dual flow-path inlet system is being tested to evaluate methodologies for a Turbine Based Combined Cycle (TBCC) propulsion system to perform a controlled inlet mode transition. Prior to experimental testing, simulation models are used to test, debug, and validate potential control algorithms. One simulation package being used for testing is the High Mach Transient Engine Cycle Code simulation, known as HiTECC. This paper discusses the closed loop control system, which utilizes a shock location sensor to improve inlet performance and operability. Even though the shock location feedback has a coarse resolution, the feedback allows for a reduction in steady state error and, in some cases, better performance than with previous proposed pressure ratio based methods. This paper demonstrates the design and benefit with the implementation of a proportional-integral controller, an H-Infinity based controller, and a disturbance observer based controller.

Csank, Jeffrey T.↗
NASA NTRS2013

Creating and Testing Simulation Software

The goal of this project is to learn about the software development process, specifically the process to test and fix components of the software. The paper will cover the techniques of testing code, and the benefits of using one style of testing over another. It will also discuss the overall software design and development lifecycle, and how code testing plays an integral role in it. Coding is notorious for always needing to be debugged due to coding errors or faulty program design. Writing tests either before or during program creation that cover all aspects of the code provide a relatively easy way to locate and fix errors, which will in turn decrease the necessity to fix a program after it is released for common use. The backdrop for this paper is the Spaceport Command and Control System (SCCS) Simulation Computer Software Configuration Item (CSCI), a project whose goal is to simulate a launch using simulated models of the ground systems and the connections between them and the control room. The simulations will be used for training and to ensure that all possible outcomes and complications are prepared for before the actual launch day. The code being tested is the Programmable Logic Controller Interface (PLCIF) code, the component responsible for transferring the information from the models to the model Programmable Logic Controllers (PLCs), basic computers that are used for very simple tasks.

Heinich, Christina M.↗
NASA NTRS2013

Maintaining the Health of Software Monitors

Software health management (SWHM) techniques complement the rigorous verification and validation processes that are applied to safety-critical systems prior to their deployment. These techniques are used to monitor deployed software in its execution environment, serving as the last line of defense against the effects of a critical fault. SWHM monitors use information from the specification and implementation of the monitored software to detect violations, predict possible failures, and help the system recover from faults. Changes to the monitored software, such as adding new functionality or fixing defects, therefore, have the potential to impact the correctness of both the monitored software and the SWHM monitor. In this work, we describe how the results of a software change impact analysis technique, Directed Incremental Symbolic Execution (DiSE), can be applied to monitored software to identify the potential impact of the changes on the SWHM monitor software. The results of DiSE can then be used by other analysis techniques, e.g., testing, debugging, to help preserve and improve the integrity of the SWHM monitor as the monitored software evolves.

Runtime Monitor↗
NASA NTRS2015

Simulation Apps Bring Us Closer to Mars

My work with mathematical modeling and computer simulations began in earnest in 1987 when I signed on with the National Aeronautics and Space Administration, better known as NASA. At the time I was developing computer simulations to support the design of carbon dioxide (CO2) removal systems for the International Space Station (ISS) life support system. CO2 is a human metabolic waste, produced at a rate of a kilogram per day per crewmember. CO2 must be removed from the crew cabin, as it will quickly become detrimental to crew health. The systems used to remove CO2 are typically based on sorption processes, which include complex interactions of heat transfer, mass transfer, and gas flow through porous media. At this time, there were no commercial options for solving a set of coupled mathematical models such as partial differential equations (PDEs); you either force-fit the physics into a thermal analysis package or wrote your own code, complete with discretization, meshing, and solution algorithms. Unfortunately, coding CO2 removal processes from scratch did not allow an appropriate focus on the challenging yet crucial task of understanding and capturing the underlying physics via appropriate mathematical models. Configuration control was often simply ignored due to tight schedules, resulting in a code that would be quicker for a second party to rewrite than modify. In the early 2000s, I decided to move CO2 removal simulations to a platform with built-in meshing, solvers, and postprocessing capabilities, and that could solve user-defined multiphysics PDEs. The program chosen to meet these needs was COMSOL Multiphysics®. Along with freeing the engineer to focus on the underlying physics, a degree of configuration control was automatically achieved via a consistent user interface, thus allowing COMSOL users to share computer models. My team has developed simulations that are already providing a valuable debugging capability for the ISS CO2 removal system, and will provide guidance in upgrades to that system.

Knox, Jim↗
NASA NTRS2008

FPGA Verification Accelerator (FVAX)

Is Verification Acceleration Possible? - Increasing the visibility of the internal nodes of the FPGA results in much faster debug time - Forcing internal signals directly allows a problem condition to be setup very quickly center dot Is this all? - No, this is part of a comprehensive effort to improve the JPL FPGA design and V&V process.

Oh, Jane↗
NASA NTRS2015

Towards an Open, Distributed Software Architecture for UxS Operations

To address the growing need to evaluate, test, and certify an ever expanding ecosystem of UxS platforms in preparation of cultural integration, NASA Langley Research Center's Autonomy Incubator (AI) has taken on the challenge of developing a software framework in which UxS platforms developed by third parties can be integrated into a single system which provides evaluation and testing, mission planning and operation, and out-of-the-box autonomy and data fusion capabilities. This software framework, named AEON (Autonomous Entity Operations Network), has two main goals. The first goal is the development of a cross-platform, extensible, onboard software system that provides autonomy at the mission execution and course-planning level, a highly configurable data fusion framework sensitive to the platform's available sensor hardware, and plug-and-play compatibility with a wide array of computer systems, sensors, software, and controls hardware. The second goal is the development of a ground control system that acts as a test-bed for integration of the proposed heterogeneous fleet, and allows for complex mission planning, tracking, and debugging capabilities. The ground control system should also be highly extensible and allow plug-and-play interoperability with third party software systems. In order to achieve these goals, this paper proposes an open, distributed software architecture which utilizes at its core the Data Distribution Service (DDS) standards, established by the Object Management Group (OMG), for inter-process communication and data flow. The design decisions proposed herein leverage the advantages of existing robotics software architectures and the DDS standards to develop software that is scalable, high-performance, fault tolerant, modular, and readily interoperable with external platforms and software.

Cross, Charles D.↗
NASA NTRS2016

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗
NASA NTRS2016

Modeling in the State Flow Environment to Support Launch Vehicle Verification Testing for Mission and Fault Management Algorithms in the NASA Space Launch System

Analysis methods and testing processes are essential activities in the engineering development and verification of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS). Central to mission success is reliable verification of the Mission and Fault Management (M&FM) algorithms for the SLS launch vehicle (LV) flight software. This is particularly difficult because M&FM algorithms integrate and operate LV subsystems, which consist of diverse forms of hardware and software themselves, with equally diverse integration from the engineering disciplines of LV subsystems. M&FM operation of SLS requires a changing mix of LV automation. During pre-launch the LV is primarily operated by the Kennedy Space Center (KSC) Ground Systems Development and Operations (GSDO) organization with some LV automation of time-critical functions, and much more autonomous LV operations during ascent that have crucial interactions with the Orion crew capsule, its astronauts, and with mission controllers at the Johnson Space Center. M&FM algorithms must perform all nominal mission commanding via the flight computer to control LV states from pre-launch through disposal and also address failure conditions by initiating autonomous or commanded aborts (crew capsule escape from the failing LV), redundancy management of failing subsystems and components, and safing actions to reduce or prevent threats to ground systems and crew. To address the criticality of the verification testing of these algorithms, the NASA M&FM team has utilized the State Flow environment6 (SFE) with its existing Vehicle Management End-to-End Testbed (VMET) platform which also hosts vendor-supplied physics-based LV subsystem models. The human-derived M&FM algorithms are designed and vetted in Integrated Development Teams composed of design and development disciplines such as Systems Engineering, Flight Software (FSW), Safety and Mission Assurance (S&MA) and major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GN&C), Thrust Vector Control (TVC), liquid engines, and the astronaut crew office. Since the algorithms are realized using model-based engineering (MBE) methods from a hybrid of the Unified Modeling Language (UML) and Systems Modeling Language (SysML), SFE methods are a natural fit to provide an in depth analysis of the interactive behavior of these algorithms with the SLS LV subsystem models. For this, the M&FM algorithms and the SLS LV subsystem models are modeled using constructs provided by Matlab which also enables modeling of the accompanying interfaces providing greater flexibility for integrated testing and analysis, which helps forecast expected behavior in forward VMET integrated testing activities. In VMET, the M&FM algorithms are prototyped and implemented using the same C++ programming language and similar state machine architectural concepts used by the FSW group. Due to the interactive complexity of the algorithms, VMET testing thus far has verified all the individual M&FM subsystem algorithms with select subsystem vendor models but is steadily progressing to assessing the interactive behavior of these algorithms with LV subsystems, as represented by subsystem models. The novel SFE applications has proven to be useful for quick look analysis into early integrated system behavior and assessment of the M&FM algorithms with the modeled LV subsystems. This early MBE analysis generates vital insight into the integrated system behaviors, algorithm sensitivities, design issues, and has aided in the debugging of the M&FM algorithms well before full testing can begin in more expensive, higher fidelity but more arduous environments such as VMET, FSW testing, and the Systems Integration Lab7 (SIL). SFE has exhibited both expected and unexpected behaviors in nominal and off nominal test cases prior to full VMET testing. In many findings, these behavioral characteristics were used to correct the M&FM algorithms, enable better test coverage, and develop more effective test cases for each of the LV subsystems. This has improved the fidelity of testing and planning for the next generation of M&FM algorithms as the SLS program evolves from non-crewed to crewed flight, impacting subsystem configurations and the M&FM algorithms that control them. SFE analysis has improved robustness and reliability of the M&FM algorithms by revealing implementation errors and documentation inconsistencies. It is also improving planning efficiency for future VMET testing of the M&FM algorithms hosted in the LV flight computers, further reducing risk for the SLS launch infrastructure, the SLS LV, and most importantly the crew.

Trevino, Luis↗
NASA NTRS2017

Verification Testing: Meet User Needs Figure of Merit

Verification is the process through which Modeling and Simulation(M&S) software goes to ensure that it has been rigorously tested and debugged for its intended use. Validation confirms that said software accurately models and represents the real world system. Credibility gives an assessment of the development and testing effort that the software has gone through as well as how accurate and reliable test results are. Together, these three components form Verification, Validation, and Credibility(VV&C), the process by which all NASA modeling software is to be tested to ensure that it is ready for implementation. NASA created this process following the CAIB (Columbia Accident Investigation Board) report seeking to understand the reasons the Columbia space shuttle failed during reentry. The reports conclusion was that the accident was fully avoidable, however, among other issues, the necessary data to make an informed decision was not there and the result was complete loss of the shuttle and crew. In an effort to mitigate this problem, NASA put out their Standard for Models and Simulations, currently in version NASA-STD-7009A, in which they detailed their recommendations, requirements and rationale for the different components of VV&C. They did this with the intention that it would allow for people receiving MS software to clearly understand and have data from the past development effort. This in turn would allow the people who had not worked with the MS software before to move forward with greater confidence and efficiency in their work. This particular project looks to perform Verification on several MATLAB (Registered Trademark)(The MathWorks, Inc.) scripts that will be later implemented in a website interface. It seeks to take note and define the limits of operation, the units and significance, and the expected datatype and format of the inputs and outputs of each of the scripts. This is intended to prevent the code from attempting to make incorrect or impossible calculations. Additionally, this project will look at the coding generally and note inconsistencies, redundancies, and other aspects that may become problematic or slow down the codes run time. Certain scripts lacking in documentation also will be commented and cataloged.

validation↗
NASA NTRS2015

Model Generation to Support Model-Based Testing Applied on NASA DAT - An Experience Report

Model-based Testing (MBT), where a model of the system under tests (SUT) behavior is used to automatically generate executable test cases, is a promising and versatile testing technology. Nevertheless, adoption of MBT technologies in industry is slow and many testing tasks are performed via manually created executable test cases (i.e. test programs such as JUnit). In order to adopt MBT, testers must learn how to construct models and use these models to generate test cases, which might be a hurdle. An interesting observation in our previous work is that the existing manually created test cases often provided invaluable insights for the manual creation of the testing models of the system. In this paper we present an approach that allows the tester to first create and debug a set of test cases. When the tester is happy with the test cases, the next step is to automatically generate a model from the test cases. The generated model is derived from the test cases, which are actions that the system can perform (e.g. a button clicks) and their expected outputs in form of assert statements (e.g. assert data entered). The model is a Finite State Machine (FSM) model that can be employed with little or no manual changes to generate additional test cases for the SUT. We successfully applied the approach in a feasibility study to the NASA Data Access Toolkit (DAT), which is a web-based GUI. One compelling finding is that the test cases that were generated from the automatically generated models were able to detect issues that were not detected by the original set of manually created test cases. We present the findings from the case study and discuss best practices for incorporating model generation techniques into an existing testing process.

State Machines↗
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↗