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

Aerospace Engineering Systems

Continuous improvement of aerospace product development processes is a driving requirement across much of the aerospace community. As up to 90% of the cost of an aerospace product is committed during the first 10% of the development cycle, there is a strong emphasis on capturing, creating, and communicating better information (both requirements and performance) early in the product development process. The community has responded by pursuing the development of computer-based systems designed to enhance the decision-making capabilities of product development individuals and teams. Recently, the historical foci on sharing the geometrical representation and on configuration management are being augmented: Physics-based analysis tools for filling the design space database; Distributed computational resources to reduce response time and cost; Web-based technologies to relieve machine-dependence; and Artificial intelligence technologies to accelerate processes and reduce process variability. Activities such as the Advanced Design Technologies Testbed (ADTT) project at NASA Ames Research Center study the strengths and weaknesses of the technologies supporting each of these trends, as well as the overall impact of the combination of these trends on a product development event. Lessons learned and recommendations for future activities will be reported.

VanDalsem, William R.↗

Software Development and Test Methodology for a Distributed Ground System

The Marshall Space Flight Center's (MSFC) Payload Operations Center (POC) ground system has evolved over a period of about 10 years. During this time the software processes have migrated from more traditional to more contemporary development processes in an effort to minimize unnecessary overhead while maximizing process benefits. The Software processes that have evolved still emphasize requirements capture, software configuration management, design documenting, and making sure the products that have been developed are accountable to initial requirements. This paper will give an overview of how the Software Processes have evolved, highlighting the positives as well as the negatives. In addition, we will mention the COTS tools that have been integrated into the processes and how the COTS have provided value to the project.

Ritter, George↗

Software Design Methodology Migration for a Distributed Ground System

The Marshall Space Flight Center's (MSFC) Payload Operations Center (POC) ground system has been developed and has evolved over a period of about 10 years. During this time the software processes have migrated from more traditional to more contemporary development processes. The new Software processes still emphasize requirements capture, software configuration management, design documenting, and making sure the products that have been developed are accountable to initial requirements. This paper will give an overview of how the Software Process have evolved highlighting the positives as well as the negatives. In addition, we will mention the COTS tools that have been integrated into the processes and how the COTS have provided value to the project .

Ritter, George↗

External Data and Attribute Hyperlink Programs for Promis*e(Registered Trademark)

External Data and Attribute Hyperlink are computer programs that can be added to Promis*e(trademark) which is a commercial software system that automates routine tasks in the design (including drawing schematic diagrams) of electrical control systems. The programs were developed under the Stennis Space Center's (SSC) Dual Use Technology Development Program to provide capabilities for SSC's BMCS configuration management system which uses Promis*e(trademark). The External Data program enables the storage and management of information in an external database linked to a drawing. Changes can be made either in the database or on the drawing. Information that originates outside Promis*e(trademark) can be stored in custom fields that can be added to the database. Although this information is not available in Promis*e(trademark) printed drawings, it can be associated with symbols in the drawings, and can be retrieved through the drawings when the software is running. The Attribute Hyperlink program enables the addition of hyperlink information as attributes of symbols. This program enables the formation of a direct hyperlink between a schematic diagram and an Internet site or a file on a compact disk, on the user's hard drive, or on another computer on a network to which the user's computer is connected. The user can then obtain information directly related to the part (e.g., maintenance, or troubleshooting information) associated with the hyperlink.

Derengowski, Rich↗

NASA Remote Sensing Data in Earth Sciences: Processing, Archiving, Distribution, Applications at the GES DISC

The NASA Goddard Earth Sciences Data and Information Services Center (GES DISC) is one of the major Distributed Active Archive Centers (DAACs) archiving and distributing remote sensing data from the NASA's Earth Observing System. In addition to providing just data, the GES DISC/DAAC has developed various value-adding processing services. A particularly useful service is data processing a t the DISC (i.e., close to the input data) with the users' algorithms. This can take a number of different forms: as a configuration-managed algorithm within the main processing stream; as a stand-alone program next to the on-line data storage; as build-it-yourself code within the Near-Archive Data Mining (NADM) system; or as an on-the-fly analysis with simple algorithms embedded into the web-based tools (to avoid downloading unnecessary all the data). The existing data management infrastructure at the GES DISC supports a wide spectrum of options: from data subsetting data spatially and/or by parameter to sophisticated on-line analysis tools, producing economies of scale and rapid time-to-deploy. Shifting processing and data management burden from users to the GES DISC, allows scientists to concentrate on science, while the GES DISC handles the data management and data processing at a lower cost. Several examples of successful partnerships with scientists in the area of data processing and mining are presented.

Leptoukh, Gregory G.↗

Lessons Learned Implementing DOORS in a Citrix Environment

NASA's James Web Space Telescope (JWST) Project is a large multi-national project with geographically dispersed contractors that all need access to the Projects requirement database. Initially, the project utilized multiple DOORS databases with the built-in partitions feature to exchange modules amongst the various contractor sites. As the requirements databases matured the use of partitions became extremely difficult. There have been many issues such as incompatible versions of DOORS, inefficient mechanism for sharing modules, security concerns, performance issues, and inconsistent document import and export formats. Deployment of the client software with limited IT resources available was also an issue. The solution chosen by JWST was to integrate the use of a Citrix environment with the DOORS database to address most of the project concerns. The use of the Citrix solution allowed a single Requirements database in a secure environment via a web interface. The Citrix environment allows JWST to upgrade to the most current version of DOORS without having to coordinate multiple sites and user upgrades. The single requirements database eliminates a multitude of Configuration Management concerns and facilitated the standardization of documentation formats. This paper discusses the obstacles and the lessons learned throughout the installation, implementation, usage and deployment process of a centralized DOORS database solution.

Bussman, Marie↗

UID.. .Now That's Gonna Leave A Mark

Since 1975 bar codes on products at the retail counter have been accepted as the standard for entering product identity for price determination. Since the beginning of the 21st century, the Data Matrix symbol has become accepted as the bar code format that is marked directly on a part, assembly or product that is durable enough to identify that item for its lifetime. NASA began the studies for direct part marking Data Matrix symbols on parts during the Return to Flight activities after the Challenger Accident. Over the 20 year period that has elapsed since Challenger, a mountain of studies, analyses and focused problem solutions developed by and for NASA have brought about world changing results. NASA Technical Standard 6002 and NASA Handbook 6003 for Direct Part Marking Data Matrix Symbols on Aerospace Parts have formed the basis for most other standards on part marking internationally. NASA and its commercial partners have developed numerous products and methods that addressed the difficulties of collecting part identification in aerospace operations. These products enabled the marking of Data Matrix symbols in virtually every situation and the reading of symbols at great distances, severe angles, under paint and in the dark without a light. Even unmarkable delicate parts now have a process to apply a chemical mixture, recently trademarked as Nanocodes, that can be converted to Data Matrix information through software. The accompanying intellectual property is protected by ten patents, several of which are licensed. Direct marking Data Matrix on NASA parts dramatically decreases data entry errors and the number of parts that go through their life cycle marked, two major threats to sound configuration management and flight safety. NASA is said to only have people and stuff with information connecting them. Data Matrix is one of the most significant improvements since Challenger to the safety and reliability of that connection.

Schramm, Fred↗

NASA Technologies for Product Identification

Since 1975 bar codes on products at the retail counter have been accepted as the standard for entering product identity for price determination. Since the beginning of the 21st century, the Data Matrix symbol has become accepted as the bar code format that is marked directly on a part, assembly or product that is durable enough to identify that item for its lifetime. NASA began the studies for direct part marking Data Matrix symbols on parts during the Return to Flight activities after the Challenger Accident. Over the 20 year period that has elapsed since Challenger, a mountain of studies, analyses and focused problem solutions developed by and for NASA have brought about world changing results. NASA Technical Standard 6002 and NASA Handbook 6003 for Direct Part Marking Data Matrix Symbols on Aerospace Parts have formed the basis for most other standards on part marking internationally. NASA and its commercial partners have developed numerous products and methods that addressed the difficulties of collecting part identification in aerospace operations. These products enabled the marking of Data Matrix symbols in virtually every situation and the reading of symbols at great distances, severe angles, under paint and in the dark without a light. Even unmarkable delicate parts now have a process to apply a chemical mixture called NanocodesTM that can be converted to a Data Matrix. The accompanying intellectual property is protected by 10 patents, several of which are licensed. Direct marking Data Matrix on NASA parts virtually eliminates data entry errors and the number of parts that go through their life cycle unmarked, two major threats to sound configuration management and flight safety. NASA is said to only have people and stuff with information connecting them. Data Matrix is one of the most significant improvements since Challenger to the safety and reliability of that connection. This presentation highlights the accomplishments of NASA in its efforts to develop technologies for automatic identification, its efforts to implement them and its vision on their role in space.

Schramm, Fred, Jr.↗

Failure Assessment

Three questions to which software developers want accurate, precise answers are "How can the software system fail?", "mat bad things will happen if the software fails?t', and "How many failures will the software experience?". Numerous techniques have been devised to answer these questions; three of the best known are: 1) Software Fault Tree Analysis (SFTA) 2) Software Failure Modes, Effects, and Criticality Analysis (SFMECA 3) Software Fault/Failure Modeling. SFTA and SFMECA have been successfully used to analyze the flight software for a number of robotic planetary exploration missions, including Galileo, Cassini, and Deep Space 1. Given the increasing interest in reusing software components from mission to mission, one of us has developed techniques for reusing the corresponding portions of the SFTA and SFMECA, reducing the effort required to conduct these analyses. SFTA has also been shown to be effective in analyzing the security aspects of software systems; intrusion mechanisms and effects can easily be modeled using these techniques. The Bi- Directional Safety Analysis (BDSA) method combines a forward search (similar to SFMECA) from potential failure modes to their effects, with a backward search (similar to SFTA) from feasible hazards to the contributing causes of each hazard. BDSA offers an efficient way to identify latent failures. Recent work has extended BDSA to product-line applications such as flight-instrumentation displays and developed tool support for the reuse of the failure-analysis artifacts within a product line. BDSA has also been streamlined to support those projects having tight cost and/or schedule constraints for their failure analysis efforts. We discuss lessons learned from practice, describe available tools, and identi@ some future directions for the topic. A substantial amount of research has been devoted to estimating the number of failures that a software system will experience during test and operations, as well as the number of faults that have been inserted into that system during its development. One of us has found that the amount of structural change to a system during its development is strongly related to the number of faults inserted into it. Using techniques requiring no additional effort on the part of the development organization, the required measurements of structural evolution can be easily obtained from a development effort's configuration management system and readily transformed into an estimate of fault content. So far, structure-fault relationships have been identified for source code; current work seeks to examine artifacts available earlier in the lifecycle to determine if similar relationships between structure and fault content can be found. In particular, relationships between requirements change requests and the number of faults inserted into the implemented system would provide a significant improvement in our ability to control software quality during the early development phases.

fault tree↗

UID...Now That's Gonna Leave A Mark

Since 1975 bar codes on products at the retail counter have been accepted as the standard for entering product identity for price determination. Since the beginning of the 21st century, the Data Matrix symbol has become accepted as the bar code format that is marked directly on a part, assembly or product that is durable enough to identify that item for its lifetime. NASA began the studies for direct part marking Data Matrix symbols on parts during the Return to Flight activities after the Challenger Accident. Over the 20 year period that has elapsed since Challenger, a mountain of studies, analyses and focused problem solutions developed by and for NASA have brought about world changing results. NASA Technical Standard 6002 and NASA Handbook 6003 for Direct Part Marking Data Matrix Symbols on Aerospace Parts have formed the basis for most other standards on part marking internationally. NASA and its commercial partners have developed numerous products and methods that addressed the difficulties of collecting part identification in aerospace operations. These products enabled the marking of Data Matrix symbols in virtually every situation and the reading of symbols at great distances, severe angles, under paint and in the dark without a light. Even unmarkable delicate parts now have a process to apply a chemical mixture, recently trademarked as Nanocodes, that can be converted to Data Matrix information through software. The accompanying intellectual property is protected by ten patents, several of which are licensed. Direct marking Data Matrix on NASA parts dramatically decreases data entry errors and the number ofparts that go through their life cycle unmarked, two major threats to sound configuration management and flight safety. NASA is said to only have people and stuff with information connecting them. Data Matrix is one of the most significant improvements since Challenger to the safety and reliability of that connection.

Schramm, Harry F., Jr.↗

UID...Now That's Gonna Leave a Mark

Since 1975 bar codes on products at the retail counter have been accepted as the standard for entering product identity for price determination. Since the beginning of the 21st century, the Data Matrix symbol has become accepted as the bar code format that is marked directly on a part, assembly or product that is durable enough to identify that item for its lifetime. NASA began the studies for direct part marking Data Matrix symbols on parts during the Return to Flight activities after the Challenger Accident. Over the 20 year period that has elapsed since Challenger, a mountain of studies, analyses and focused problem solutions developed by and for NASA have brought about world changing results. NASA Technical Standard 6002 and NASA Handbook 6003 for Direct Part Marking Data Matrix Symbols on Aerospace Parts have formed the basis for most other standards on part marking internationally. NASA and its commercial partners have developed numerous products and methods that addressed the difficulties of collecting part identification in aerospace operations. These products enabled the marking of Data Matrix symbols in virtually every situation and the reading of symbols at great distances, severe angles, under paint and in the dark without a light. Even unmarkable delicate parts now have a process to apply a chemical mixture, recently trademarked as Nanocodes, that can be converted to Data Matrix information through software. The accompanying intellectual property is protected by ten patents, several of which are licensed. Direct marking Data Matrix on NASA parts dramatically decreases data entry errors and the number of parts that go through their life cycle unmarked, two major threats to sound configuration management and flight safety. NASA is said to only have people and stuff with information connecting them. Data Matrix is one of the most significant improvements since Challenger to the safety and reliability of that connection.

Schramm, Harry F.↗

UID....Now That's Gonna Leave A Mark

Since 1975 bar codes on products at the retail counter have been accepted as the standard for entering product identity for price determination. Since the beginning of the 21 st century, the Data Matrix symbol has become accepted as the bar code format that is marked directly on a part, assembly or product that is durable enough to identify that item for its lifetime. NASA began the studies for direct part marking Data Matrix symbols on parts during the Return to Flight activities after the Challenger Accident. Over the 20 year period that has elapsed since Challenger, a mountain of studies, analyses and focused problem solutions developed by and for NASA have brought about world changing results. NASA Technical Standard 6002 and NASA Handbook 6003 for Direct Part Marking Data Matrix Symbols on Aerospace Parts have formed the basis for most other standards on part marking internationally. NASA and its commercial partners have developed numerous products and methods that addressed the difficulties of collecting part identification in aerospace operations. These products enabled the marking of Data Matrix symbols in virtually every situation and the reading of symbols at great distances, severe angles, under paint and in the dark without a light. Even unmarkable delicate parts now have a process to apply a chemical mixture, recently trademarked as Nanocodes, that can be converted to Data Matrix information through software. The accompanying intellectual property is protected by ten patents, several of which are licensed. Direct marking Data Matrix on NASA parts dramatically decreases data entry errors and the number of parts that go through their life cycle unmarked, two major threats to sound configuration management and flight safety. NASA is said to only have people and stuff with information connecting them. Data Matrix is one of the most significant improvements since Challenger to the safety and reliability of that connection.

Schramm, Harry F., Jr.↗

UID...Leaving Its Mark on the Universe

Since 1975 bar codes on products at the retail counter have been accepted as the standard for entering product identity for price determination. Since the beginning of the 21 st century, the Data Matrix symbol has become accepted as the bar code format that is marked directly on a part, assembly or product that is durable enough to identify that item for its lifetime. NASA began the studies for direct part marking Data Matrix symbols on parts during the Return to Flight activities after the Challenger Accident. Over the 20 year period that has elapsed since Challenger, a mountain of studies, analyses and focused problem solutions developed by and for NASA have brought about world changing results. NASA Technical Standard 6002 and NASA Handbook 6003 for Direct Part Marking Data Matrix Symbols on Aerospace Parts have formed the basis for most other standards on part marking internationally. NASA and its commercial partners have developed numerous products and methods that addressed the difficulties of collecting part identification in aerospace operations. These products enabled the marking of Data Matrix symbols in virtually every situation and the reading of symbols at great distances, severe angles, under paint and in the dark without a light. Even unmarkable delicate parts now have a process to apply a chemical mixture, recently trademarked as Nanocodes, that can be converted to Data Matrix information through software. The accompanying intellectual property is protected by ten patents, several of which are licensed. Direct marking Data Matrix on NASA parts dramatically decreases data entry errors and the number of parts that go through their life cycle unmarked, two major threats to sound configuration management and flight safety. NASA is said to only have people and stuff with information connecting them. Data Matrix is one of the most significant improvements since Challenger to the safety and reliability of that connection.

Schramm, Harry F., Jr.↗

A Holistic Approach to Systems Development

Introduces a Holistic and Iterative Design Process. Continuous process but can be loosely divided into four stages. More effort spent early on in the design. Human-centered and Multidisciplinary. Emphasis on Life-Cycle Cost. Extensive use of modeling, simulation, mockups, human subjects, and proven technologies. Human-centered design doesn t mean the human factors discipline is the most important Disciplines should be involved in the design: Subsystem vendors, configuration management, operations research, manufacturing engineering, simulation/modeling, cost engineering, hardware engineering, software engineering, test and evaluation, human factors, electromagnetic compatibility, integrated logistics support, reliability/maintainability/availability, safety engineering, test equipment, training systems, design-to-cost, life cycle cost, application engineering etc. 9

Wong, Douglas T.↗

Guidance and Control Software Project Data - Volume 2: Development Documents

The Guidance and Control Software (GCS) project was the last in a series of software reliability studies conducted at Langley Research Center between 1977 and 1994. The technical results of the GCS project were recorded after the experiment was completed. Some of the support documentation produced as part of the experiment, however, is serving an unexpected role far beyond its original project context. Some of the software used as part of the GCS project was developed to conform to the RTCA/DO-178B software standard, "Software Considerations in Airborne Systems and Equipment Certification," used in the civil aviation industry. That standard requires extensive documentation throughout the software development life cycle, including plans, software requirements, design and source code, verification cases and results, and configuration management and quality control data. The project documentation that includes this information is open for public scrutiny without the legal or safety implications associated with comparable data from an avionics manufacturer. This public availability has afforded an opportunity to use the GCS project documents for DO-178B training. This report provides a brief overview of the GCS project, describes the 4-volume set of documents and the role they are playing in training, and includes the development documents from the GCS project. Volume 2 contains three appendices: A. Guidance and Control Software Development Specification; B. Design Description for the Pluto Implementation of the Guidance and Control Software; and C. Source Code for the Pluto Implementation of the Guidance and Control Software

Hayhurst, Kelly J.↗

Guidance and Control Software Project Data - Volume 3: Verification Documents

The Guidance and Control Software (GCS) project was the last in a series of software reliability studies conducted at Langley Research Center between 1977 and 1994. The technical results of the GCS project were recorded after the experiment was completed. Some of the support documentation produced as part of the experiment, however, is serving an unexpected role far beyond its original project context. Some of the software used as part of the GCS project was developed to conform to the RTCA/DO-178B software standard, "Software Considerations in Airborne Systems and Equipment Certification," used in the civil aviation industry. That standard requires extensive documentation throughout the software development life cycle, including plans, software requirements, design and source code, verification cases and results, and configuration management and quality control data. The project documentation that includes this information is open for public scrutiny without the legal or safety implications associated with comparable data from an avionics manufacturer. This public availability has afforded an opportunity to use the GCS project documents for DO-178B training. This report provides a brief overview of the GCS project, describes the 4-volume set of documents and the role they are playing in training, and includes the verification documents from the GCS project. Volume 3 contains four appendices: A. Software Verification Cases and Procedures for the Guidance and Control Software Project; B. Software Verification Results for the Pluto Implementation of the Guidance and Control Software; C. Review Records for the Pluto Implementation of the Guidance and Control Software; and D. Test Results Logs for the Pluto Implementation of the Guidance and Control Software.

Hayhurst, Kelly J.↗

Human Research Program Integrated Research Plan

The Integrated Research Plan (IRP) describes the portfolio of Human Research Program (HRP) research and technology tasks. The IRP is the HRP strategic and tactical plan for research necessary to meet HRP requirements. The need to produce an IRP is established in HRP-47052, Human Research Program - Program Plan, and is under configuration management control of the Human Research Program Control Board (HRPCB). Crew health and performance is critical to successful human exploration beyond low Earth orbit. The Human Research Program (HRP) is essential to enabling extended periods of space exploration because it provides knowledge and tools to mitigate risks to human health and performance. Risks include physiological and behavioral effects from radiation and hypogravity environments, as well as unique challenges in medical support, human factors, and behavioral or psychological factors. The Human Research Program (HRP) delivers human health and performance countermeasures, knowledge, technologies and tools to enable safe, reliable, and productive human space exploration. Without HRP results, NASA will face unknown and unacceptable risks for mission success and post-mission crew health. This Integrated Research Plan (IRP) describes HRP s approach and research activities that are intended to address the needs of human space exploration and serve HRP customers and how they are integrated to provide a risk mitigation tool. The scope of the IRP is limited to the activities that can be conducted with the resources available to the HRP; it does not contain activities that would be performed if additional resources were available. The timescale of human space exploration is envisioned to take many decades. The IRP illustrates the program s research plan through the timescale of early lunar missions of extended duration.

Source record↗