Search NASA⌕ Search

SEARCH · Search NASA

Results for “configuration management”

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 235 records · Page 13
All sourcesNASA NTRSDOE OSTI
NASA NTRS2010

OLTARIS: On-Line Tool for the Assessment of Radiation in Space

The On-Line Tool for the Assessment of Radiation In Space (OLTARIS) is a World Wide Web based tool that assesses the effects of space radiation on humans and electronics in items such as spacecraft, habitats, rovers, and spacesuits. This document explains the basis behind the interface and framework used to input the data, perform the assessment, and output the results to the user as well as the physics, engineering, and computer science used to develop OLTARIS. The transport and physics is based on the HZETRN and NUCFRG research codes. The OLTARIS website is the successor to the SIREST website from the early 2000's. Modifications have been made to the code to enable easy maintenance, additions, and configuration management along with a more modern web interface. Overall, the code has been verified, tested, and modified to enable faster and more accurate assessments.

Singleterry, Robert C., Jr.↗
NASA NTRS2010

NASA Astronauts on Soyuz: Experience and Lessons for the Future

The U. S., Russia, and, China have each addressed the question of human-rating spacecraft. NASA's operational experience with human-rating primarily resides with Mercury, Gemini, Apollo, Space Shuttle, and International Space Station. NASA s latest developmental experience includes Constellation, X38, X33, and the Orbital Space Plane. If domestic commercial crew vehicles are used to transport astronauts to and from space, Soyuz is another example of methods that could be used to human-rate a spacecraft and to work with commercial spacecraft providers. For Soyuz, NASA's normal assurance practices were adapted. Building on NASA's Soyuz experience, this report contends all past, present, and future vehicles rely on a range of methods and techniques for human-rating assurance, the components of which include: requirements, conceptual development, prototype evaluations, configuration management, formal development reviews (safety, design, operations), component/system ground-testing, integrated flight tests, independent assessments, and launch readiness reviews. When constraints (cost, schedule, international) limit the depth/breadth of one or more preferred assurance means, ways are found to bolster the remaining areas. This report provides information exemplifying the above safety assurance model for consideration with commercial or foreign-government-designed spacecraft. Topics addressed include: U.S./Soviet-Russian government/agency agreements and engineering/safety assessments performed with lessons learned in historic U.S./Russian joint space ventures

Source record↗
NASA NTRS2011

Seven Processes that Enable NASA Software Engineering Technologies

This slide presentation reviews seven processes that NASA uses to ensure that software is developed, acquired and maintained as specified in the NPR 7150.2A requirement. The requirement is to ensure that all software be appraised for the Capability Maturity Model Integration (CMMI). The enumerated processes are: (7) Product Integration, (6) Configuration Management, (5) Verification, (4) Software Assurance, (3) Measurement and Analysis, (2) Requirements Management and (1) Planning & Monitoring. Each of these is described and the group(s) that are responsible is described.

Housch, Helen↗
NASA NTRS2011

Flight Systems Integration and Test

Topics to be Covered in this presentation are: (1) Integration and Test (I&T) Planning (2) Integration and Test Flows (3) Overview of Typical Mission I&T (4) Supporting Elements (5) Lessons-Learned and Helpful Hints (6) I&T Mishaps and Failures (7) The Lighter Side of I&T and (8) Small-Group Activity. This presentation highlights a typical NASA "in-house" I&T program (1) For flight systems that are developed by NASA at a space flight center (like GSFC) (2) Requirements well-defined: qualification/acceptance, documentation, configuration management. (3) Factors: precedents, human flight, risk-aversion ("failure-phobia"), taxpayer dollars, jobs and (4) Some differences among NASA centers, but generally a resource-intensive process

Wright, Michael R.↗
NASA NTRS2012

Engineering a Multimission Approach to Navigation Ground Data System Operations

The Mission Design and Navigation (MDNAV) Section at the Jet Propulsion Laboratory (JPL) supports many deep space and earth orbiting missions from formulation to end of mission operations. The requirements of these missions are met with a multimission approach to MDNAV ground data system (GDS) infrastructure capable of being shared and allocated in a seamless and consistent manner across missions. The MDNAV computing infrastructure consists of compute clusters, network attached storage, mission support area facilities, and desktop hardware. The multimission architecture allows these assets, and even personnel, to be leveraged effectively across the project lifecycle and across multiple missions simultaneously. It provides a more robust and capable infrastructure to each mission than might be possible if each constructed its own. It also enables a consistent interface and environment within which teams can conduct all mission analysis and navigation functions including: trajectory design; ephemeris generation; orbit determination; maneuver design; and entry, descent, and landing analysis. The savings of these efficiencies more than offset the costs of increased complexity and other challenges that had to be addressed: configuration management, scheduling conflicts, and competition for resources. This paper examines the benefits of the multimission MDNAV ground data system infrastructure, focusing on the hardware and software architecture. The result is an efficient, robust, scalable MDNAV ground data system capable of supporting more than a dozen active missions at once.

Mission Design and Navigation (MDNAV)↗
NASA NTRS2013

Estimated Probability of a Cervical Spine Injury During an ISS Mission

Introduction: The Integrated Medical Model (IMM) utilizes historical data, cohort data, and external simulations as input factors to provide estimates of crew health, resource utilization and mission outcomes. The Cervical Spine Injury Module (CSIM) is an external simulation designed to provide the IMM with parameter estimates for 1) a probability distribution function (PDF) of the incidence rate, 2) the mean incidence rate, and 3) the standard deviation associated with the mean resulting from injury/trauma of the neck. Methods: An injury mechanism based on an idealized low-velocity blunt impact to the superior posterior thorax of an ISS crewmember was used as the simulated mission environment. As a result of this impact, the cervical spine is inertially loaded from the mass of the head producing an extension-flexion motion deforming the soft tissues of the neck. A multibody biomechanical model was developed to estimate the kinematic and dynamic response of the head-neck system from a prescribed acceleration profile. Logistic regression was performed on a dataset containing AIS1 soft tissue neck injuries from rear-end automobile collisions with published Neck Injury Criterion values producing an injury transfer function (ITF). An injury event scenario (IES) was constructed such that crew 1 is moving through a primary or standard translation path transferring large volume equipment impacting stationary crew 2. The incidence rate for this IES was estimated from in-flight data and used to calculate the probability of occurrence. The uncertainty in the model input factors were estimated from representative datasets and expressed in terms of probability distributions. A Monte Carlo Method utilizing simple random sampling was employed to propagate both aleatory and epistemic uncertain factors. Scatterplots and partial correlation coefficients (PCC) were generated to determine input factor sensitivity. CSIM was developed in the SimMechanics/Simulink environment with a Monte Carlo wrapper (MATLAB) used to integrate the components of the module. Results: The probability of generating an AIS1 soft tissue neck injury from the extension/flexion motion induced by a low-velocity blunt impact to the superior posterior thorax was fitted with a lognormal PDF with mean 0.26409, standard deviation 0.11353, standard error of mean 0.00114, and 95% confidence interval [0.26186, 0.26631]. Combining the probability of an AIS1 injury with the probability of IES occurrence was fitted with a Johnson SI PDF with mean 0.02772, standard deviation 0.02012, standard error of mean 0.00020, and 95% confidence interval [0.02733, 0.02812]. The input factor sensitivity analysis in descending order was IES incidence rate, ITF regression coefficient 1, impactor initial velocity, ITF regression coefficient 2, and all others (equipment mass, crew 1 body mass, crew 2 body mass) insignificant. Verification and Validation (V&V): The IMM V&V, based upon NASA STD 7009, was implemented which included an assessment of the data sets used to build CSIM. The documentation maintained includes source code comments and a technical report. The software code and documentation is under Subversion configuration management. Kinematic validation was performed by comparing the biomechanical model output to established corridors.

Brooker, John E.↗
NASA NTRS2014

Model-Based GN and C Simulation and Flight Software Development for Orion Missions beyond LEO

For Orion missions beyond low Earth orbit (LEO), the Guidance, Navigation, and Control (GN&C) system is being developed using a model-based approach for simulation and flight software. Lessons learned from the development of GN&C algorithms and flight software for the Orion Exploration Flight Test One (EFT-1) vehicle have been applied to the development of further capabilities for Orion GN&C beyond EFT-1. Continuing the use of a Model-Based Development (MBD) approach with the Matlab®/Simulink® tool suite, the process for GN&C development and analysis has been largely improved. Furthermore, a model-based simulation environment in Simulink, rather than an external C-based simulation, greatly eases the process for development of flight algorithms. The benefits seen by employing lessons learned from EFT-1 are described, as well as the approach for implementing additional MBD techniques. Also detailed are the key enablers for improvements to the MBD process, including enhanced configuration management techniques for model-based software systems, automated code and artifact generation, and automated testing and integration.

Odegard, Ryan↗
NASA NTRS2015

NASA Data Acquisition System Software Development for Rocket Propulsion Test Facilities

Current NASA propulsion test facilities include Stennis Space Center in Mississippi, Marshall Space Flight Center in Alabama, Plum Brook Station in Ohio, and White Sands Test Facility in New Mexico. Within and across these centers, a diverse set of data acquisition systems exist with different hardware and software platforms. The NASA Data Acquisition System (NDAS) is a software suite designed to operate and control many critical aspects of rocket engine testing. The software suite combines real-time data visualization, data recording to a variety formats, short-term and long-term acquisition system calibration capabilities, test stand configuration control, and a variety of data post-processing capabilities. Additionally, data stream conversion functions exist to translate test facility data streams to and from downstream systems, including engine customer systems. The primary design goals for NDAS are flexibility, extensibility, and modularity. Providing a common user interface for a variety of hardware platforms helps drive consistency and error reduction during testing. In addition, with an understanding that test facilities have different requirements and setups, the software is designed to be modular. One engine program may require real-time displays and data recording; others may require more complex data stream conversion, measurement filtering, or test stand configuration management. The NDAS suite allows test facilities to choose which components to use based on their specific needs. The NDAS code is primarily written in LabVIEW, a graphical, data-flow driven language. Although LabVIEW is a general-purpose programming language; large-scale software development in the language is relatively rare compared to more commonly used languages. The NDAS software suite also makes extensive use of a new, advanced development framework called the Actor Framework. The Actor Framework provides a level of code reuse and extensibility that has previously been difficult to achieve using LabVIEW. The

Herbert, Phillip W., Sr.↗
NASA NTRS2016

NASA Human System Risk Assessment Process

NASA utilizes an evidence based system to perform risk assessments for the human system for spaceflight missions. The center of this process is the multi-disciplinary Human System Risk Board (HSRB). The HSRB is chartered from the Chief Health and Medical Officer (OCHMO) at NASA Headquarters. The HSRB reviews all human system risks via an established comprehensive risk and configuration management plan based on a project management approach. The HSRB facilitates the integration of human research (terrestrial and spaceflight), medical operations, occupational surveillance, systems engineering and many other disciplines in a comprehensive review of human system risks. The HSRB considers all factors that influence human risk. These factors include pre-mission considerations such as screening criteria, training, age, sex, and physiological condition. In mission factors such as available countermeasures, mission duration and location and post mission factors such as time to return to baseline (reconditioning), post mission health screening, and available treatments. All of the factors influence the total risk assessment for each human risk. The HSRB performed a comprehensive review of all potential inflight medical conditions and events and over the course of several reviews consolidated the number of human system risks to 30, where the greatest emphasis is placed for investing program dollars for risk mitigation. The HSRB considers all available evidence from human research and, medical operations and occupational surveillance in assessing the risks for appropriate mitigation and future work. All applicable DRMs (low earth orbit for 6 and 12 months, deep space for 30 days and 1 year, a lunar mission for 1 year, and a planetary mission for 3 years) are considered as human system risks are modified by the hazards associated with space flight such as microgravity, exposure to radiation, distance from the earth, isolation and a closed environment. Each risk has a summary two-page assessment representing the state of knowledge/evidence of that risk, available risk mitigations, traceability to the Space Flight Human System Standards (SFHSS) and program requirements, and future work required. These data then can drive coordinated budgets across the Human Research Program, the International Space Station, Crew Health and Safety and Advanced Exploration System budgets to provide the most economical and timely mitigations. The risk assessments were completed for the 6 DRMs and serve as the baseline for which subsequent research and technology development and crew health care portfolios can be assessed. The HSRB reviews each risk at least annually or when new evidence/information is available that adds to the body of evidence. The current status of each risk can be reported to program management for operations, budget reviews and general oversight of the human system risk management program.

Francisco, D.↗
NASA NTRS2016

Marshall Space Flight Center Telescience Resource Kit

Telescience Resource Kit (TReK) is a suite of software applications that can be used to monitor and control assets in space or on the ground. The Telescience Resource Kit was originally developed for the International Space Station program. Since then it has been used to support a variety of NASA programs and projects including the WB-57 Ascent Vehicle Experiment (WAVE) project, the Fast Affordable Science and Technology Satellite (FASTSAT) project, and the Constellation Program. The Payloads Operations Center (POC), also known as the Payload Operations Integration Center (POIC), provides the capability for payload users to operate their payloads at their home sites. In this environment, TReK provides local ground support system services and an interface to utilize remote services provided by the POC. TReK provides ground system services for local and remote payload user sites including International Partner sites, Telescience Support Centers, and U.S. Investigator sites in over 40 locations worldwide. General Capabilities: Support for various data interfaces such as User Datagram Protocol, Transmission Control Protocol, and Serial interfaces. Data Services - retrieve, process, record, playback, forward, and display data (ground based data or telemetry data). Command - create, modify, send, and track commands. Command Management - Configure one TReK system to serve as a command server/filter for other TReK systems. Database - databases are used to store telemetry and command definition information. Application Programming Interface (API) - ANSI C interface compatible with commercial products such as Visual C++, Visual Basic, LabVIEW, Borland C++, etc. The TReK API provides a bridge for users to develop software to access and extend TReK services. Environments - development, test, simulations, training, and flight. Includes standalone training simulators.

Wade, Gina↗
NASA NTRS2017

Ground System Architectures Workshop GMSEC SERVICES SUITE (GSS): an Agile Development Story

The GMSEC (Goddard Mission Services Evolution Center) Services Suite (GSS) is a collection of tools and software services along with a robust customizable web-based portal that enables the user to capture, monitor, report, and analyze system-wide GMSEC data. Given our plug-and-play architecture and the needs for rapid system development, we opted to follow the Scrum Agile Methodology for software development. Being one of the first few projects to implement the Agile methodology at NASA GSFC, in this presentation we will present our approaches, tools, successes, and challenges in implementing this methodology. The GMSEC architecture provides a scalable, extensible ground and flight system for existing and future missions. GMSEC comes with a robust Application Programming Interface (GMSEC API) and a core set of Java-based GMSEC components that facilitate the development of a GMSEC-based ground system. Over the past few years, we have seen an upbeat in the number of customers who are moving from a native desktop application environment to a web based environment particularly for data monitoring and analysis. We also see a need to provide separation of the business logic from the GUI display for our Java-based components and also to consolidate all the GUI displays into one interface. This combination of separation and consolidation brings immediate value to a GMSEC-based ground system through increased ease of data access via a uniform interface, built-in security measures, centralized configuration management, and ease of feature extensibility.

Software Development/Agile↗
NASA NTRS2017

Smashing the Stovepipe: Leveraging the GMSEC Open Architecture and Advanced IT Automation to Rapidly Prototype, Develop and Deploy Next-Generation Multi-Mission Ground Systems

Satellite/Payload Ground Systems - Typically highly-customized to a specific mission's use cases - Utilize hundreds (or thousands!) of specialized point-to-point interfaces for data flows / file transfers Documentation and tracking of these complex interfaces requires extensive time to develop and extremely high staffing costs Implementation and testing of these interfaces are even more cost-prohibitive, and documentation often lags behind implementation resulting in inconsistencies down the road With expanding threat vectors, IT Security, Information Assurance and Operational Security have become key Ground System architecture drivers New Federal security-related directives are generated on a daily basis, imposing new requirements on current / existing ground systems - These mandated activities and data calls typically carry little or no additional funding for implementation As a result, Ground System Sustaining Engineering groups and Information Technology staff continually struggle to keep up with the rolling tide of security Advancing security concerns and shrinking budgets are pushing these large stove-piped ground systems to begin sharing resources - I.e. Operational / SysAdmin staff, IT security baselines, architecture decisions or even networks / hosting infrastructure Refactoring these existing ground systems into multi-mission assets proves extremely challenging due to what is typically very tight coupling between legacy components As a result, many "Multi-Mission" ops. environments end up simply sharing compute resources and networks due to the difficulty of refactoring into true multi-mission systems Utilizing continuous integration / rapid system deployment technologies in conjunction with an open architecture messaging approach allows System Engineers and Architects to worry less about the low-level details of interfaces between components and configuration of systems GMSEC messaging is inherently designed to support multi-mission requirements, and allows components to aggregate data across multiple homogeneous or heterogeneous satellites or payloads - The highly-successful Goddard Science and Planetary Operations Control Center (SPOCC) utilizes GMSEC as the hub for it's automation and situational awareness capability Shifts focus towards getting GS to a final configuration-managed baseline, as well as multi-mission / big-picture capabilities that help increase situational awareness, promote cross-mission sharing and establish enhanced fleet management capabilities across all levels of the enterprise.

GMSEC↗
NASA NTRS2018

Exploration Medical System Trade Study Tools Overview

ExMC is creating an ecosystem of tools to enable well-informed medical system trade studies. The suite of tools address important system implementation aspects of the space medical capabilities trade space and are being built using knowledge from the medical community regarding the unique aspects of space flight. Two integrating models, a systems engineering model and a medical risk analysis model, tie the tools together to produce an integrated assessment of the medical system and its ability to achieve medical system target requirements. This presentation will provide an overview of the various tools that are a part of the tool ecosystem. Initially, the presentation's focus will address the tools that supply the foundational information to the ecosystem. Specifically, the talk will describe how information that describes how medicine will be practiced is captured and categorized for efficient utilization in the tool suite. For example, the talk will include capturing what conditions will be planned for in-mission treatment, planned medical activities (e.g., periodic physical exam), required medical capabilities (e.g., provide imaging), and options to implement the capabilities (e.g., an ultrasound device). Database storage and configuration management will also be discussed. The presentation will include an overview of how these information tools will be tied to parameters in a Systems Modeling Language (SysML) model, allowing traceability to system behavioral, structural, and requirements content. The discussion will also describe an HRP-led enhanced risk assessment model developed to provide quantitative insight into each capability's contribution to mission success. Key outputs from these various tools, to be shared with the space medical and exploration mission development communities, will be assessments of medical system implementation option satisfaction of requirements and per-capability contributions toward achieving requirements.

Mindock, J.↗
NASA NTRS2018

Flight Systems Integration & Test: Lessons Learned for Future Success

This paper offers a comprehensive view of flight system integration and test (I&T) lessons learned related to mishaps and close calls, focusing on what can be done to improve the I&T process to avoid recurrence. Specific areas within the realm of I&T that are covered in this paper include: I&T team communication and training; design of flight and ground systems for I&T; planning and scheduling; configuration management and process documentation; ground support equipment and tools; cleanrooms and contamination; mechanical integration, handling, and deployments; electrical integration and electrostatic discharge; functional testing and troubleshooting; environmental testing and facilities; and launch site operations. To illustrate "real-world" lessons learned for I&T, examples from throughout the history of the U.S. space program are presented. Also presented are some best practices for I&T that can help mitigate mishaps and close calls on the ground or during flight.

Integration & Test↗
NASA NTRS2018

NC Space Grant Report

During the summer of 2018 I supported the Safety & Mission Assurance Directorate (SMA) and Operations Support Division (QA-20) at Stennis Space Center. The mission of the SMA team is to prove safety, risk, reliability, independent assessments, configuration management and quality assurance guidance, and services for all NASA Stennis Space Center (SSC) programs, facilities, and supporting infrastructure. The office actively participates and contributes to the Agency-level Safety & Mission Assurance (S&MA) effort. Over the course of the Summer I participated in three projects. Two of them were focused around Fault Tree Analysis (FTA) and the third focused on relief valves for their E-1 engine test stand.

Torres, David↗
NASA NTRS2004

Modeling the TPF interferometer

The Terrestrial Planet Finder interferometer design concepts are large and complex systems that must operate in environments that are impractical to reproduce in preflight testing. The structurally-connected design is 36 meters long - longer than all but one thermal vacuum chamber in existence. The formation flying design will be comprised of up to five separate spacecraft, each with a sunshield over 15 meters on a side, and is designed to operate with formation sizes spanning over 100 meters to very close formations. System-level verification of the performance of the designs will need to rely on analytical modeling. The effort to model the many physical aspects of the designs under study is under way*. This paper describes the program of modeling for the TPF-I concepts. The program includes a number of types of models, such as the standard stand-alone optics, thermal, and structural models, as well as an end-to-end performance model of the project system called the Observatory Simulation. Aspects of each model are discussed including the purpose, methods of implementation (software applications), and approaches to validation. Program-level considerations (such as model-to-model integration and configuration management) are also discussed. Given that there are at least seven different organizations contributing to model developments and more than twenty separate models, these are special challenges.

Henry, Curt↗
NASA NTRSDate not supplied

The Core Flight System (cFS): NASA Quality Flight Software to Power Science and Exploration Available to the World

The presentation is planned to be a continuation of two previous discussions completed at the FSW Workshop regarding the cFS Test Framework (CTF) and Engineering Data Sheets (EDS). The presentation will also cover the latest advancements in cFS, including: 1. Quick into to cFS 2. An overview of our software release process + Git repo 3. Release of EDS files for the cFE + open-source apps 4. Overview of how to independently verify EDS files using CTF + what they can be used for. 5. Future plans for cFS. This presentation complements the talk on configuration management of distributed cFS repos, to be presented by Tam Ngo from Johnson Space Center.

Dan Knutsen↗