SEARCH · Search NASA
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.
Electrical, mechanical, and software subsystem needs in the Post 1990 space operations environment are considered as well as the effect of radiation environment on spacecraft configuration. Criteria are given for selecting a specific design or technology concept from among the alternatives available.
The concept of distributed execution of recovery blocks is examined as an approach for uniform treatment of hardware and software faults. A useful characteristic of the approach is the relatively small time cost it requires. The approach is thus suitable for incorporation into real-time computer systems. A specific formulation of the approach that is aimed at minimizing the recovery time is presented, called the distributed recovery block (DRB) scheme. The DRB scheme is capable of effecting forward recovery while handling both hardware and software faults in a uniform manner. An approach to incorporating the capability for multiprocessing scheme is also discussed. Two experiments aimed at testing the execution efficiency of the scheme in real-time applications have been conducted on two different multimicrocomputer networks. The results clearly indicate the feasibility of achieving tolerance of hardware and software faults in a broad range of real-time computer systems by use of the schemes for distributed execution of recovery blocks.
NASA's successful development of next generation space vehicles, habitats, and robotic systems will require reliable hardware and software systems. The aim of this initiative is to develop modeling methodology and tools to support Model-Based Systems Engineering (MBSE) for software assurance and reliability analysis. This effort expands the Unified Modeling Language (UML) software design models to include fault data for the extraction of Failure Modes and Effects Criticality Analysis (FMECA) and Fault Tree Analysis (FTA) for software. We explored different modeling approaches to integrate the UML software design models with the Systems Modeling Language (SysML) system models to generate an integrated model and reliability tools that take into account software and hardware interfaces.The benefits of this concept directly affect the safety community with quick turnarounds to produce software assurance and reliability analysis artifacts and the ability to visualize failure effects, both hardware and software. The result is enhanced system design integrity and early identification of system risks. This initiative will enable software assurance activities early in the system design lifecycle, facilitating the discovery of design weaknesses and enhancing the capability to produce safe, hazard-free systems
The Station Explorer for X-ray Timing and Navigation Technology (SEXTANT) is a technology demonstration enhancement to the Neutron-star Interior Composition Explorer (NICER) mission, which is scheduled to launch in late 2016 and will be hosted as an externally attached payload on the International Space Station (ISS) via the ExPRESS Logistics Carrier (ELC). During NICER's 18-month baseline science mission to understand ultra-dense matter though observations of neutron stars in the soft X-ray band, SEXTANT will, for the first-time, demonstrate real-time, on-board X-ray pulsar navigation, which is a significant milestone in the quest to establish a GPS-like navigation capability that will be available throughout our Solar System and beyond. Along with NICER, SEXTANT has proceeded through Phase B, Mission Definition, and received numerous refinements in concept of operation, algorithms, flight software, ground system, and ground test capability. NICER/SEXTANT's Phase B work culminated in NASA's confirmation of NICER to Phase C, Design and Development, in March 2014. Recently, NICER/SEXTANT successfully passed its Critical Design Review and SEXTANT received continuation approval in September 2014. In this paper, we describe the X-ray pulsar navigation concept and provide a brief history of previous work, and then summarize the SEXTANT technology demonstration objective, hardware and software components, and development to date.
This report validates and documents the detailed features and practical application of the framework for software intensive digital systems risk assessment and risk-informed safety assurance presented in the NASA PRA Procedures Guide for Managers and Practitioner. This framework, called herein the "Context-based Software Risk Model" (CSRM), enables the assessment of the contribution of software and software-intensive digital systems to overall system risk, in a manner which is entirely compatible and integrated with the format of a "standard" Probabilistic Risk Assessment (PRA), as currently documented and applied for NASA missions and applications. The CSRM also provides a risk-informed path and criteria for conducting organized and systematic digital system and software testing so that, within this risk-informed paradigm, the achievement of a quantitatively defined level of safety and mission success assurance may be targeted and demonstrated. The framework is based on the concept of context-dependent software risk scenarios and on the modeling of such scenarios via the use of traditional PRA techniques - i.e., event trees and fault trees - in combination with more advanced modeling devices such as the Dynamic Flowgraph Methodology (DFM) or other dynamic logic-modeling representations. The scenarios can be synthesized and quantified in a conditional logic and probabilistic formulation. The application of the CSRM method documented in this report refers to the MiniAERCam system designed and developed by the NASA Johnson Space Center.
Long-duration, deep-space exploration missions present significant challenges to crew health and performance. These challenges include the individual and combined effects of microgravity, radiation exposure, isolation, limited resources (mass, volume, power, data and crew time), limited options for evacuation and those associated with delayed or constrained communications, all of which demand greater crew autonomy. Specifically, as the communication delays intensify the further we explore space, the unqualified need for Earth-independent medical operations focused on autonomous diagnosis, treatment and prevention will be key to mission continuation and success. To augment the requisite knowledge, skills and abilities (KSAs) of a time-constrained crew operating under stressful conditions, combatting fatigue, and facing a potential medical crisis, a robust clinical decision support system (CDSS) is a probable solution that would facilitate, guide and inform Earth-independent medical operations, while assisting crewmembers through various clinical presentations. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) is expanding the boundaries of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit. ExMC is actively identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addresses gap Medical-701 within the Inflight Medical Conditions risk: “Enhance medical capabilities within an exploration medical system.” Though mass, volume, and power will face increasing constraints, the projected computational capabilities of spacecraft systems will increase exponentially as information technology continues to advance this decade and beyond. Hence, data, software and computational resources will play an essential and synergistic role in maintaining crew health, wellness and performance in deep space missions. The focus of the CDS project is to develop recommended requirements for an in-vehicle CDSS that acts as a ‘virtual assistant’ for delivering optimal health, performance and medical care during exploration missions. The CDSS is envisioned as an integrated, software-based tool deployed on a laptop computer or handheld device. The CDSS will assist the crew and ground support when interacting with knowledge/databases (e.g. records, pharmacy, schedule), instrumentation (e.g. imaging, physiological monitoring devices), and habitat (e.g. wellness system, task performance system) and vehicle systems (e.g. environmental system, communication system). In addition, the human interface will employ a context-based approach that accounts for the crew’s situation. Thus, extraneous and clinically/operationally non-relevant information are reduced to avoid an increase in cognitive load. The framework of an ideal spaceflight CDSS is to include core and advanced analytical features that incorporate work from collaborators yet maintain a flexible platform for integrating new technology in the future. In fiscal year 2021 (FY21), the CDS project identified requirements through two primary mechanisms: (i) the development of software implementation prototypes and (ii) the application of systems engineering processes. The CDS project developed and tested a series of increasingly complex system prototypes that were based on use cases derived from the CDSS concept of operations (ConOps). These software implementations yielded insights on CDSS functionality as well as lessons learned that provided the initial requirements for CDSS capability. By applying a systems engineering (SE) approach, medical scenarios provided in the ConOps and the use cases for software implementation underwent functional decomposition to identify CDSS functionality. Also, systems-based modeling language (SysML) tools such as activity diagrams were developed from the same ConOps and use cases to identify CDSS functionality. The lessons learned from software implementation defined both specific requirements and broad areas of requirements. Within these defined broad requirement areas, further analysis of the SE products identified specific capability that resulted in the final functional requirements. In summary, the software prototypes, functional decomposition of the ConOps and use cases, and SysML diagrams provided the basis for the CDSS requirements developed in FY21. In the upcoming year, these requirements will be refined for their final ExMC baseline review in latter FY22.
Long-duration, deep-space exploration missions present significant challenges to crew health and performance. These challenges include the individual and combined effects of microgravity, radiation exposure, isolation, limited resources (mass, volume, power, data and crew time), limited options for evacuation and those associated with delayed or constrained communications, all of which demand greater crew autonomy. Specifically, as the communication delays intensify the further we explore space, the unqualified need for Earth-independent medical operations focused on autonomous diagnosis, treatment and prevention will be key to mission continuation and success. To augment the requisite knowledge, skills and abilities (KSAs) of a time-constrained crew operating under stressful conditions, combatting fatigue, and facing a potential medical crisis, a robust clinical decision support system (CDSS) is a probable solution that would facilitate, guide and inform Earth-independent medical operations, while assisting crewmembers through various clinical presentations. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) is expanding the boundaries of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit. ExMC is actively identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addresses gap Medical-701 within the Inflight Medical Conditions risk: “Enhance medical capabilities within an exploration medical system.” Though mass, volume, and power will face increasing constraints, the projected computational capabilities of spacecraft systems will increase exponentially as information technology continues to advance this decade and beyond. Hence, data, software and computational resources will play an essential and synergistic role in maintaining crew health, wellness and performance in deep space missions. The focus of the CDS project is to develop recommended requirements for an in-vehicle CDSS that acts as a ‘virtual assistant’ for delivering optimal health, performance and medical care during exploration missions. The CDSS is envisioned as an integrated, software-based tool deployed on a laptop computer or handheld device. The CDSS will assist the crew and ground support when interacting with knowledge/databases (e.g. records, pharmacy, schedule), instrumentation (e.g. imaging, physiological monitoring devices), and habitat (e.g. wellness system, task performance system) and vehicle systems (e.g. environmental system, communication system). In addition, the human interface will employ a context-based approach that accounts for the crew’s situation. Thus, extraneous and clinically/operationally non-relevant information are reduced to avoid an increase in cognitive load. The framework of an ideal spaceflight CDSS is to include core and advanced analytical features that incorporate work from collaborators yet maintain a flexible platform for integrating new technology in the future. In fiscal year 2021 (FY21), the CDS project identified requirements through two primary mechanisms: (i) the development of software implementation prototypes and (ii) the application of systems engineering processes. The CDS project developed and tested a series of increasingly complex system prototypes that were based on use cases derived from the CDSS concept of operations (ConOps). These software implementations yielded insights on CDSS functionality as well as lessons learned that provided the initial requirements for CDSS capability. By applying a systems engineering (SE) approach, medical scenarios provided in the ConOps and the use cases for software implementation underwent functional decomposition to identify CDSS functionality. Also, systems-based modeling language (SysML) tools such as activity diagrams were developed from the same ConOps and use cases to identify CDSS functionality. The lessons learned from software implementation defined both specific requirements and broad areas of requirements. Within these defined broad requirement areas, further analysis of the SE products identified specific capability that resulted in the final functional requirements. In summary, the software prototypes, functional decomposition of the ConOps and use cases, and SysML diagrams provided the basis for the CDSS requirements developed in FY21. In the upcoming year, these requirements will be refined for their final ExMC baseline review in latter FY22.
The results of a combined management and technical initiative aimed at reducing the size and complexity associated with developing operations planning, scheduling, and resource management software systems are presented. The initiative has produced operations concepts, functional requirements, system architectures, a comprehensive lexicon, and software tools to revolutionize the traditional software technology and development practices for planning, scheduling, and resource management systems used in space operations control centers. Examples of technology and practices to reduce complexity include a method for projecting design consequences from an operations concept, a universal architecture for heuristic algorithms, an object-oriented framework for describing large classes of problems that parametrically adapt to all domain peculiarities, the identification of general approaches which respond to changes with minimum impact on systems implementations, and a management structure for prototyping to minimize the risks of ill-conceived designs.
Problems related to the design and control of an autonomous rover for the purpose of unmanned exploration of the planets were considered. Building on the basis of prior studies, a four wheeled rover of unusual mobility and maneuverability was further refined and tested under both laboratory and field conditions. A second major effort was made to develop autonomous guidance. Path selection systems capable of dealing with relatively formidable hazard and terrains involving various short range (1.0-3.0 meters), hazard detection systems using a triangulation detection concept were simulated and evaluated. The mechanical/electronic systems required to implement such a scheme were constructed and tested. These systems include: laser transmitter, photodetectors, the necessary data handling/controlling systems and a scanning mast. In addition, a telemetry system to interface the vehicle, the off-board computer and a remote control module for operator intervention were developed. Software for the autonomous control concept was written. All of the systems required for complete autonomous control were shown to be satisfactory except for that portion of the software relating to the handling of interrupt commands.
The results of a study of the systems concept of the Pinhole/Occulter Facility (PDF) to fly on the Shuttle as a Spacelab payload are reported. In particular, attention is given to the POF configuration and structural/mechanical concepts; POF payload structural concept development; POF payload new baseline configuration; POF pointing requirements and the Spacelab Instrument Pointing System capabilities and limitations; and pointing control implementation approach. The discussion also covers POF command and data management system configuration; POF processor software assessment; and thermal design concept.
Traffic Aware Strategic Aircrew Requests (TASAR) is an onboard automation concept intended to identify trajectory optimizations, in terms of fuel and time saving objectives, clear of known traffic, weather, and airspace restrictions prior to the aircrew initiating a route-change request to Air Traffic Control (ATC). The software implementation of the TASAR concept is the Traffic Aware Planner (TAP). TASAR analysis and development is being executed by the NASA Langley Research Center's Crew Systems and Aviation Operations Branch (CSAOB) under the sponsorship of the Airspace Technology Demonstration (ATD) Project of the NASA Airspace Operations and Safety Program (AOSP). The TASAR Flight Trial-2 (FT-2) was conducted in June, 2015 out of the Newport News/Williamsburg International Airport. This flight trial was conducted using a Piaggio Avanti flight test aircraft and consisted of 12 Evaluation Flights with airline commercial pilots participating as the Evaluation Pilots, three destination airports in Atlanta and Jacksonville Air Route Traffic Control Centers, and one pair of flight plans associated with each destination airport. The primary goal of FT-2 was to reduce risk for upcoming operational trials with NASA partner airlines, Alaska Airlines and Virgin America. To accomplish this primary goal, six independent objectives were conducted during FT-2, however, this paper will report only the findings of Objective 5; the assessment of system usability, pilot perceived workload, and the degree of pilot acceptability of the TAP Human Machine Interface (HMI) during flight operations, via the administration of several subjective measures.
A brief introduction to software engineering is presented. The talk is divided into four sections beginning with the question 'What is software engineering', followed by a brief history of the progression of software engineering at the Langley Research Center in the context of an expanding computing environment. Several basic concepts and terms are introduced, including software development life cycles and maturity levels. Finally, comments are offered on what software engineering means for the Langley Research Center and where to find more information on the subject.
The Chorus software is designed to investigate near-term, tactical conflict and loss of separation detection and resolution concepts for air traffic management. This software is currently being used in two different problem domains: en-route self- separation and sense and avoid for unmanned aircraft systems. This paper describes the core resolution algorithms that are part of Chorus. The combination of several features of the Chorus program distinguish this software from other approaches to conflict and loss of separation resolution. First, the program stores a history of state information over time which enables it to handle communication dropouts and take advantage of previous input data. Second, the underlying conflict algorithms find resolutions that solve the most urgent conflict, but also seek to prevent secondary conflicts with the other aircraft. Third, if the program is run on multiple aircraft, and the two aircraft maneuver at the same time, the result will be implicitly co-ordinated. This implicit coordination property is established by ensuring that a resolution produced by Chorus will comply with a mathematically-defined criteria whose correctness has been formally verified. Fourth, the program produces both instantaneous solutions and kinematic solutions, which are based on simple accel- eration models. Finally, the program provides resolutions for recovery from loss of separation. Different versions of this software are implemented as Java and C++ software programs, respectively.
Abstract-Next Generation Air Transportation System (NextGen) applications reliant upon aircraft data links such as Automatic Dependent Surveillance-Broadcast (ADS-B) offer a sweeping modernization of the National Airspace System (NAS), but the aviation stakeholder community has not yet established a positive business case for equipage and message content standards remain in flux. It is necessary to transition promising Air Traffic Management (ATM) Concepts of Operations (ConOps) from simulation environments to full-scale flight tests in order to validate user benefits and solidify message standards. However, flight tests are prohibitively expensive and message standards for Commercial-off-the-Shelf (COTS) systems cannot support many advanced ConOps. It is therefore proposed to simulate future aircraft surveillance and communications equipage and employ an existing commercial data link to exchange data during dedicated flight tests. This capability, referred to as the Networked Air Traffic Infrastructure Validation Environment (NATIVE), would emulate aircraft data links such as ADS-B using in-flight Internet and easily-installed test equipment. By utilizing low-cost equipment that is easy to install and certify for testing, advanced ATM ConOps can be validated, message content standards can be solidified, and new standards can be established through full-scale flight trials without necessary or expensive equipage or extensive flight test preparation. This paper presents results of a feasibility study of the NATIVE concept. To determine requirements, six NATIVE design configurations were developed for two NASA ConOps that rely on ADS-B. The performance characteristics of three existing in-flight Internet services were investigated to determine whether performance is adequate to support the concept. Next, a study of requisite hardware and software was conducted to examine whether and how the NATIVE concept might be realized. Finally, to determine a business case, economic factors were evaluated and a preliminary cost-benefit analysis was performed.
This paper proposes an initial architecture for a Space Traffic Management (STM) system, based on openApplication Programming Interfaces (APIs) and drawing on previous work by the NASA Ames Research Center (ARC) to develop an architecture for low-altitude Unmanned Aerial System Traffic Management (UTM). The authors explore how autonomy could be used to enhance an STM system, and how constraints inherent in STM complicate and challenge certain applications of autonomy. We conceptually explore how autonomy could be used within an STM architecture, with multiple non-authoritative catalogs of resident space objects, and to determine which oftwo conjuncting spacecraft moves. NASA ARC is developing a software research environment for STM, along with a physical laboratory and visualization space. We invite STM stakeholders to collaborate in our infrastructure, to help inform the design of the proposed STM architecture, and to participate in the refinement and validation of its concept of operations using the software research platform.
pyam is a software development framework with tools for facilitating the rapid development of software in a concurrent software development environment. pyam provides solutions for development challenges associated with software reuse, managing multiple software configurations, developing software product lines, and multiple platform development and build management. pyam uses release-early, release-often development cycles to allow developers to integrate their changes incrementally into the system on a continual basis. It facilitates the creation and merging of branches to support the isolated development of immature software to avoid impacting the stability of the development effort. It uses modules and packages to organize and share software across multiple software products, and uses the concepts of link and work modules to reduce sandbox setup times even when the code-base is large. One sidebenefit is the enforcement of a strong module-level encapsulation of a module s functionality and interface. This increases design transparency, system stability, and software reuse. pyam is written in Python and is organized as a set of utilities on top of the open source SVN software version control package. All development software is organized into a collection of modules. pyam packages are defined as sub-collections of the available modules. Developers can set up private sandboxes for module/package development. All module/package development takes place on private SVN branches. High-level pyam commands support the setup, update, and release of modules and packages. Released and pre-built versions of modules are available to developers. Developers can tailor the source/link module mix for their sandboxes so that new sandboxes (even large ones) can be built up easily and quickly by pointing to pre-existing module releases. All inter-module interfaces are publicly exported via links. A minimal, but uniform, convention is used for building modules.
YAM is a software development framework with tools for facilitating the rapid development and integration of software in a concurrent software development environment. YAM provides solutions for thorny development challenges associated with software reuse, managing multiple software configurations, the development of software product-lines, multiple platform development and build management. YAM uses release-early, release-often development cycles to allow developers to incrementally integrate their changes into the system on a continual basis. YAM facilitates the creation and merging of branches to support the isolated development of immature software to avoid impacting the stability of the development effort. YAM uses modules and packages to organize and share software across multiple software products. It uses the concepts of link and work modules to reduce sandbox setup times even when the code-base is large. One side-benefit is the enforcement of a strong module-level encapsulation of a module s functionality and interface. This increases design transparency, system stability as well as software reuse. YAM is in use by several mid-size software development teams including ones developing mission-critical software.
This paper describes CMEX Mars, an effort in the creation of a comprehensive set of concept maps to describe all aspects of Mars exploration. These concept maps, created using the CmapTools software developed by the Institute for Human and Machine Cognition, are available on the Internet at http:/cmex.arc.nasa.gov/CMEX and are linked among themselves as well as to resources on the Internet. The work described took place mainly between 1998 and 2001 and combined the goals of: 1) developing a library of concept maps for educational outreach while also 2) refining the capabilities of the software used to create the interactive maps and 3) making them available on the Internet. Here we focus on the library of Mars exploration concept maps that has been created.