Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “quality 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 307 records · Page 17

Teams and teamwork at NASA Langley Research Center

The recent reorganization and shift to managing total quality at the NASA Langley Research Center (LaRC) has placed an increasing emphasis on teams and teamwork in accomplishing day-to-day work activities and long-term projects. The purpose of this research was to review the nature of teams and teamwork at LaRC. Models of team performance and teamwork guided the gathering of information. Current and former team members served as participants; their collective experience reflected membership in over 200 teams at LaRC. The participants responded to a survey of open-ended questions which assessed various aspects of teams and teamwork. The participants also met in a workshop to clarify and elaborate on their responses. The work accomplished by the teams ranged from high-level managerial decision making (e.g., developing plans for LaRC reorganization) to creating scientific proposals (e.g., describing spaceflight projects to be designed, sold, and built). Teams typically had nine members who remained together for six months. Member turnover was around 20 percent; this turnover was attributed to heavy loads of other work assignments and little formal recognition and reward for team membership. Team members usually shared a common and valued goal, but there was not a clear standard (except delivery of a document) for knowing when the goal was achieved. However, members viewed their teams as successful. A major factor in team success was the setting of explicit a priori rules for communication. Task interdependencies between members were not complex (e.g., sharing of meeting notes and ideas about issues), except between members of scientific teams (i.e., reliance on the expertise of others). Thus, coordination of activities usually involved scheduling and attendance of team meetings. The team leader was designated by the team's sponsor. This leader usually shared power and responsibilities with other members, such that team members established their own operating procedures for decision making. Sponsors followed a hands-off policy during team operations, but they approved and reviewed team products. Most teams, particularly high-level decision-making teams, had little or no authority to carry out their decisions. Team members had few interpersonal conflicts. They monitored each other respectfully about meeting deadlines. Feedback and backup behaviors were seen as desirable aspects of teamwork, wanted by the members, and done appropriately.

Dickinson, Terry L.↗

Performing Verification and Validation in Reuse-Based Software Engineering

The implementation of reuse-based software engineering not only introduces new activities to the software development process, such as domain analysis and domain modeling, it also impacts other aspects of software engineering. Other areas of software engineering that are affected include Configuration Management, Testing, Quality Control, and Verification and Validation (V&V). Activities in each of these areas must be adapted to address the entire domain or product line rather than a specific application system. This paper discusses changes and enhancements to the V&V process, in order to adapt V&V to reuse-based software engineering.

Addy, Edward A.↗

Flight Test Safety Considerations for Airborne Science Aircraft

Most of the scientific community that require scientific data or scientific measurements from aircraft do not understand the full implications of putting certain equipment on board high performance aircraft. It is the duty of the NASA Flight Operations personnel to ensure that all Principal Investigators who are given space on NASA flight research aircraft, comply with stringent safety requirements. The attitude of the experienced Flight operations personnel given this duty has been and remains one of insuring that the PI's experiment is allowed to be placed on the aircraft (facility) and can be operated in a manner that will obtain the expected data. This is sometimes a challenge. The success that NASA has in this regard is due to the fact that it is its own authority under public law, to certify its aircraft as airworthy. Airworthiness, fitness for flight, is a complex issue which pulls together all aspects of configuration management, engineering, quality, and flight safety. It is often the case at each NASA Center that is conducting airborne research, that unique solutions to some challenging safety issues are required. These solutions permit NASA to do things that would not be permitted by the Department of Transportation. This paper will use examples of various flight research configurations to show the necessity of a disciplined process leading up to flight test and mission implementation. All new configurations required engineering flight test but many, as noted in this paper, require that the modifications be flight tested to insure that they do not negatively impact on any part of the aircraft operational profiles. The success of these processes has been demonstrated over many years and NASA has accommodated experimental packages that cannot be flown on any other aircraft.

Reynolds, Randolph S.↗

Evaluation of NASA Data Products for RPO Applications

This presentation summarizes preliminary investigations at SSC by NASA's ASD in Air Quality including decision support tools, partner plans, working groups, and committees. An overview of follow-on short-term and long-term objectives is also provided. A table of potential NASA sensors for use with air quality applications is included, along with specifications for MODIS 04 and 06 products. This presentation was originally given by Rich Piorot of the Vermont Department of Environmental Conservation - Air Quality as part of a round-table discussion during "Exploring Collaborative Opportunities in Air Quality Monitoring, Modelling and Communication Workshop" in Boulder, CO, on March 21-22, 2005; verbal consent for this presentation to be provided to Mr. Piorot was given by the NASA SSC ASD Air Quality Program Manager on March 14, 2005.

Frisbie, Troy↗

Modeling defect trends for iterative development

The Employment of Defects (EoD) approach to measuring and analyzing defects seeks to identify and capture trends and phenomena that are critical to managing software quality in the iterative software development lifecycle at JPL.

modeling defects metrics↗

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.↗

The Role and Quality of Software Safety in the NASA Constellation Program

In this study, we examine software safety risk in the early design phase of the NASA Constellation spaceflight program. Obtaining an accurate, program-wide picture of software safety risk is difficult across multiple, independently-developing systems. We leverage one source of safety information, hazard analysis, to provide NASA quality assurance managers with information regarding the ongoing state of software safety across the program. The goal of this research is two-fold: 1) to quantify the relative importance of software with respect to system safety; and 2) to quantify the level of risk presented by software in the hazard analysis. We examined 154 hazard reports created during the preliminary design phase of three major flight hardware systems within the Constellation program. To quantify the importance of software, we collected metrics based on the number of software-related causes and controls of hazardous conditions. To quantify the level of risk presented by software, we created a metric scheme to measure the specificity of these software causes. We found that from 49-70% of hazardous conditions in the three systems could be caused by software or software was involved in the prevention of the hazardous condition. We also found that 12-17% of the 2013 hazard causes involved software, and that 23-29% of all causes had a software control. Furthermore, 10-12% of all controls were software-based. There is potential for inaccuracy in these counts, however, as software causes are not consistently scoped, and the presence of software in a cause or control is not always clear. The application of our software specificity metrics also identified risks in the hazard reporting process. In particular, we found a number of traceability risks in the hazard reports may impede verification of software and system safety.

Layman, Lucas↗

Obtaining Valid Safety Data for Software Safety Measurement and Process Improvement

We report on a preliminary case study to examine software safety risk in the early design phase of the NASA Constellation spaceflight program. Our goal is to provide NASA quality assurance managers with information regarding the ongoing state of software safety across the program. We examined 154 hazard reports created during the preliminary design phase of three major flight hardware systems within the Constellation program. Our purpose was two-fold: 1) to quantify the relative importance of software with respect to system safety; and 2) to identify potential risks due to incorrect application of the safety process, deficiencies in the safety process, or the lack of a defined process. One early outcome of this work was to show that there are structural deficiencies in collecting valid safety data that make software safety different from hardware safety. In our conclusions we present some of these deficiencies.

Basili, Victor r.↗

Thermal Components Boost Performance of HVAC Systems

As the International Space Station (ISS) travels 17,500 miles per hour, normal is having a constant sensation of free-falling. Normal is no rain, but an extreme amount of shine.with temperatures reaching 250 F when facing the Sun. Thanks to a number of advanced control systems onboard the ISS, however, the interior of the station remains a cool, comfortable, normal environment where astronauts can live and work for extended periods of time. There are two main control systems on the ISS that make it possible for humans to survive in space: the Thermal Control System (TCS) and the Environmental Control and Life Support system. These intricate assemblies work together to supply water and oxygen, regulate temperature and pressure, maintain air quality, and manage waste. Through artificial means, these systems create a habitable environment for the space station s crew. The TCS constantly works to regulate the temperature not only for astronauts, but for the critical instruments and machines inside the spacecraft as well. To do its job, the TCS encompasses several components and systems both inside and outside of the ISS. Inside the spacecraft, a liquid heat-exchange process mechanically pumps fluids in closed-loop circuits to collect, transport, and reject heat. Outside the ISS, an external system circulates anhydrous ammonia to transport heat and cool equipment, and radiators release the heat into space. Over the years, NASA has worked with a variety of partners.public and private, national and international. to develop and refine the most complex thermal control systems ever built for spacecraft, including the one on the ISS.

Source record↗

NASA Extreme Environment Mission Operations: Science Operations Development for Human Exploration

The purpose of NASA Extreme Environment Mission Operations (NEEMO) mission 16 in 2012 was to evaluate and compare the performance of a defined series of representative near-Earth asteroid (NEA) extravehicular activity (EVA) tasks under different conditions and combinations of work systems, constraints, and assumptions considered for future human NEA exploration missions. NEEMO 16 followed NASA's 2011 Desert Research and Technology Studies (D-RATS), the primary focus of which was understanding the implications of communication latency, crew size, and work system combinations with respect to scientific data quality, data management, crew workload, and crew/mission control interactions. The 1-g environment precluded meaningful evaluation of NEA EVA translation, worksite stabilization, sampling, or instrument deployment techniques. Thus, NEEMO missions were designed to provide an opportunity to perform a preliminary evaluation of these important factors for each of the conditions being considered. NEEMO 15 also took place in 2011 and provided a first look at many of the factors, but the mission was cut short due to a hurricane threat before all objectives were completed. ARES Directorate (KX) personnel consulted with JSC engineers to ensure that high-fidelity planetary science protocols were incorporated into NEEMO mission architectures. ARES has been collaborating with NEEMO mission planners since NEEMO 9 in 2006, successively building upon previous developments to refine science operations concepts within engineering constraints; it is expected to continue the collaboration as NASA's human exploration mission plans evolve.

Bell, Mary S.↗

Assessment Environment for Complex Systems Software Guide

This Software Guide (SG) describes the software developed to test the Assessment Environment for Complex Systems (AECS) by the West Virginia High Technology Consortium (WVHTC) Foundation's Mission Systems Group (MSG) for the National Aeronautics and Space Administration (NASA) Aeronautics Research Mission Directorate (ARMD). This software is referred to as the AECS Test Project throughout the remainder of this document. AECS provides a framework for developing, simulating, testing, and analyzing modern avionics systems within an Integrated Modular Avionics (IMA) architecture. The purpose of the AECS Test Project is twofold. First, it provides a means to test the AECS hardware and system developed by MSG. Second, it provides an example project upon which future AECS research may be based. This Software Guide fully describes building, installing, and executing the AECS Test Project as well as its architecture and design. The design of the AECS hardware is described in the AECS Hardware Guide. Instructions on how to configure, build and use the AECS are described in the User's Guide. Sample AECS software, developed by the WVHTC Foundation, is presented in the AECS Software Guide. The AECS Hardware Guide, AECS User's Guide, and AECS Software Guide are authored by MSG. The requirements set forth for AECS are presented in the Statement of Work for the Assessment Environment for Complex Systems authored by NASA Dryden Flight Research Center (DFRC). The intended audience for this document includes software engineers, hardware engineers, project managers, and quality assurance personnel from WVHTC Foundation (the suppliers of the software), NASA (the customer), and future researchers (users of the software). Readers are assumed to have general knowledge in the field of real-time, embedded computer software development.

tests↗

Addressing Scalability While Feature Requests Persist. A Look at NASA Worldview's New Features and Their Implementation

Worldview is a high-traffic web mapping application created using the JavaScript mapping library, OpenLayers. This presentation will primarily focus on three new features: A wrapping component that seamlessly shows satellite imagery over the dateline where most maps either stop or wrap the imagery of the same date. An animation feature that allows users to select date ranges over which they can animate. An A/B comparison feature that gives users the power to compare imagery between dates and layers. In response to an increasingly large codebase caused by ongoing feature requests, Worldview is transitioning to a smaller core codebase comprised of external reusable modules. When creating a module with the intention of having someone else reuse it for a different task, one inherently starts generating code that is easier to read and easier to maintain. This presentation will show demos of these features and cover development techniques used to create them. Worldview is a web mapping tool used for education, research, and disaster response. We consume 600+ Imagery products and support time-critical application areas such as wildfire management, air quality measurements, and flood monitoring.

Reusability↗

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↗

Prioritizing Aquatic Science and Applications Needs in the Chesapeake Bay for a Space-Borne Hyperspectral Mission

The Chesapeake Bay is the largest estuary in North America, benefiting a growing population through its ecosystem services, fishing, recreations, and transportation routes. Studies indicate the health of the Bay as seen some improvement in recent years, yet threats to its health persist (e.g. warming, pollution nutrient run-off). Increasing human activities in coastal regions requires constant vigilance by agencies managing water quality, to ensure the safety of the population. Since April 2018, an interagency working group has been meeting monthly and a daylong workshop was convened with science and applications stakeholders around the overall theme of monitoring water quality from space. Current ocean color images indicate bloom locations used to guide in situ sampling efforts, despite limited spatial, spectral and temporal resolution. High resolution hyperspectral remote sensing provides a potential opportunity to measure additional indicators of ecological health and water quality. Assessing the needs of the aquatic user community around the Chesapeake Bay will inform science and applications recommendations during the current architecture study for a Surface Biology and Geology (SBG) Mission, as well as future scoping studies of other coastal and inland water bodies.

Schollaert Uz, Stephanie↗

Systems and methods for quality of service (QoS) based management of bottlenecks and flows in networks

Techniques based on the Theory of Bottleneck Ordering can reveal the bottleneck structure of a network, and the Theory of Flow ordering can take advantage of the revealed bottleneck structure to manage and configure network flows so as to improve the overall network performance. These two techniques provide insights into the inherent topological properties of a network at least in three areas: (1) identification of the regions of influence of each bottleneck; (2) the order in which bottlenecks (and flows traversing them) may converge to their steady state transmission rates in distributed congestion control algorithms; and (3) the design of optimized traffic engineering policies.

97 MATHEMATICS AND COMPUTING↗