Dshell++: A Component Based, Reusable Space System Simulation Framework

Lim, Christopher S.; Jain, Abhinandan

Home/Archive/NASA NTRS

NASA NTRS · 20150009168

Dshell++: A Component Based, Reusable Space System Simulation Framework

Lim, Christopher S.·Jain, Abhinandan

View original source ↗Export metadata ↓

Abstract

This paper describes the multi-mission Dshell++ simulation framework for high fidelity, physics-based simulation of spacecraft, robotic manipulation and mobility systems. Dshell++ is a C++/Python library which uses modern script driven object-oriented techniques to allow component reuse and a dynamic run-time interface for complex, high-fidelity simulation of spacecraft and robotic systems. The goal of the Dshell++ architecture is to manage the inherent complexity of physicsbased simulations while supporting component model reuse across missions. The framework provides several features that support a large degree of simulation configurability and usability.

Explore related subjects

Software aerospace simulation

Keep this discovery

Explore connections, maps & timelines

BibTeX RIS

Lim, Christopher S., Jain, Abhinandan. 2009-07-19. Dshell++: A Component Based, Reusable Space System Simulation Framework. https://ntrs.nasa.gov/citations/20150009168

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↗