Command and Control System Automated Testing

Eric Leiva-Ochoa

Home/Archive/NASA NTRS

NASA NTRS · 20205009018

Command and Control System Automated Testing

Eric Leiva-Ochoa

View original source ↗Export metadata ↓

Abstract

To support the National Aeronautics and Space Administration’s (NASA) Space Launch System (SLS) rocket, Kennedy Space Center (KSC) has developed the Spaceport Command and Control System (SCCS) to monitor and control the pre-launch and launch operations. Within SCCS, the Launch Control System (LCS) is designed to allow console engineers to control and monitor the status of the launch and flight hardware, as well as issue commands to ground control systems and launch vehicles. The display software of the LCS is responsible for visualizing the various data that can be received from the hardware and software components of the LCS. Since this system is providing critical information to engineers in the firing room, the visualization of data across the system must be easy to understand, but also reliable and accurate.

Explore related subjects

Software

Keep this discovery

Explore connections, maps & timelines

BibTeX RIS

Eric Leiva-Ochoa. 2020-11-24. Command and Control System Automated Testing. https://ntrs.nasa.gov/citations/20205009018

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related reports

DOE OSTI2026

BRCore: An R Package Implementing Flexible Selection of Core Taxa Using Contribution to Bray-Curtis Dissimilarity and Neutral Model Fitting

BRCore provides a unified framework for identification and ecological interpretation of core microbiomes across time and space, enhancing robustness and reproducibility in microbiome data analysis. Is supplement to Software: https://github.com/germs-lab/BRCore/tree/v2.0.7 (URL)

Software↗

DOE OSTI2026

Data for The Stem Cell-Type Transcriptome of Bioenergy Sorghum Reveals the Spatial Regulation of Secondary Cell Wall Networks

Bioenergy sorghum is a low-input, drought-resilient, deep-rooting annual crop that has high biomass yield potential enabling the sustainable production of biofuels, biopower, and bioproducts. Bioenergy sorghum’s 4-5 m stems account for ~80% of the harvested biomass. Stems accumulate high levels of sucrose that could be used to synthesize bioethanol and useful biopolymers if information about stem cell-type gene expression and regulation was available to enable engineering. To obtain this information, Laser Capture Microdissection (LCM) was used to isolate and collect transcriptome profiles from five major cell types that are present in stems of the sweet sorghum Wray. Transcriptome analysis identified genes with cell-type specific and cell-preferred expression patterns that reflect the distinct metabolic, transport, and regulatory functions of each cell type. Analysis of cell-type specific gene regulatory networks (GRNs) revealed that unique TF families contribute to distinct regulatory landscapes, where regulation is organized through various modes and identifiable network motifs. Cell-specific transcriptome data was combined with a stem developmental transcriptome dataset to identify the GRN that differentially activates the secondary cell wall (SCW) formation in stem xylem sclerenchyma and epidermal cells. The cell-type transcriptomic dataset provides a valuable source of information about the function of sorghum stem cell types and GRNs that will enable the engineering of bioenergy sorghum stems.

Software↗

NASA NTRS2023

Software Error Incident Categorizations in Aerospace

Since the first use of computers in space and aircraft, software errors have occurred. These errors can manifest as loss-of-life or less catastrophically. As the demand for automation increases, software in safety-critical systems should be designed to be tolerant to the most likely software faults. This paper categorizes historic aerospace software errors to determine trends of how and where automation is most likely to fail. A distinction between software producing wrong (erroneous) output versus no output (fail-silent) is introduced. Of the historical incidents analyzed, 87% were from software acting unexpectedly rather than simply stopping. Rebooting was found to be ineffective to clear erroneous behavior, and only partially effective for silent software. Errors were traced back to the software logic itself in 62% of cases, 13% within configurable data, and 25% introduced through input. Thirty percent (30%) of unexpected software behavior was caused by the absence of software and 20% was due to “unknown-unknowns”. These findings indicate that to achieve fault tolerance in safety-critical systems, backup strategies must be employed to detect and respond to erroneous software behavior beyond only fail-silent cases, and robust off-nominal testing should be performed to uncover unanticipated situations.

Software↗