Search NASA⌕ Search

SEARCH · Search NASA

Results for “checklists”

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 199 records · Page 11
All sourcesNASA NTRSDOE OSTI
NASA NTRS2007

Filling the Assurance Gap on Complex Electronics

Many of the methods used to develop software bare a close resemblance to Complex Electronics (CE) development. CE are now programmed to perform tasks that were previously handled by software, such as communication protocols. For example, the James Webb Space Telescope will use Field Programmable Gate Arrays (FPGAs), which can have over a million logic gates, to send telemetry. System-on-chip (SoC) devices, another type of complex electronics, can combine a microprocessor, input and output channels, and sometimes an FPGA for programmability. With this increased intricacy, the possibility of software-like bugs such as incorrect design, logic, and unexpected interactions within the logic is great. Since CE devices are obscuring the hardware/software boundary, mature software methodologies have been proposed, with slight modifications, to develop these devices. By using standardized S/W Engineering methods such as checklists, missing requirements and bugs can be detected earlier in the development cycle, thus creating a development process for CE that can be easily maintained and configurable based on the device used.

Plastow, Richard A.↗
NASA NTRS2007

Software Process Assurance for Complex Electronics (SPACE)

Complex Electronics (CE) are now programmed to perform tasks that were previously handled in software, such as communication protocols. Many of the methods used to develop software bare a close resemblance to CE development. For instance, Field Programmable Gate Arrays (FPGAs) can have over a million logic gates while system-on-chip (SOC) devices can combine a microprocessor, input and output channels, and sometimes an FPGA for programmability. With this increased intricacy, the possibility of software-like bugs such as incorrect design, logic, and unexpected interactions within the logic is great. Since CE devices are obscuring the hardware/software boundary, we propose that mature software methodologies may be utilized with slight modifications in the development of these devices. Software Process Assurance for Complex Electronics (SPACE) is a research project that looks at using standardized S/W Assurance/Engineering practices to provide an assurance framework for development activities. Tools such as checklists, best practices and techniques can be used to detect missing requirements and bugs earlier in the development cycle creating a development process for CE that will be more easily maintained, consistent and configurable based on the device used.

Plastow, Richard A.↗
NASA NTRS2008

Staying Motivated During Tough Times

This paper describes the problem of team motivation on a project. Our team was working with the Department of Homeland Security (DHS). The task consisted of figuring out how to safely control and land an airliner using just the thrust from the engines. This is called Throttles-Only Control (TOC). We weren't allowed to modify the airliner in any way, given the time and cost involved, and we had to use a stock airliner with line pilots. The idea was to give the pilots an emergency checklist which would provide them with the most useful information in the shortest time to learn how to fly TOC. The DHS Program office that was supporting us had its funding redirected, due to new priorities. The process of staying motivated for finishing as much of the project as possible is described.

Cole, Jennifer H.↗
NASA NTRS2008

Operator Performance Evaluation of Fault Management Interfaces for Next-Generation Spacecraft

In the cockpit of the NASA's next generation of spacecraft, most of vehicle commanding will be carried out via electronic interfaces instead of hard cockpit switches. Checklists will be also displayed and completed on electronic procedure viewers rather than from paper. Transitioning to electronic cockpit interfaces opens up opportunities for more automated assistance, including automated root-cause diagnosis capability. The paper reports an empirical study evaluating two potential concepts for fault management interfaces incorporating two different levels of automation. The operator performance benefits produced by automation were assessed. Also, some design recommendations for spacecraft fault management interfaces are discussed.

Hayashi, Miwa↗
NASA NTRS2007

Full Life-Cycle Defect Management Assessment: Initial Inspection Data Collection Results and Research Questions for Further Study

It is often the case in software projects that when schedule and budget resources are limited, the Verification and Validation (V&V) activities suffer. Fewer V&V activities can be afforded and moreover, short-term challenges can result in V&V activities being scaled back or dropped altogether. As a result, too often the default solution is to save activities for improving software quality until too late in the life-cycle, relying on late-term code inspections followed by thorough testing activities to reduce defect counts to acceptable levels. As many project managers realize, however, this is a resource-intensive way of achieving the required quality for software. The Full Life-cycle Defect Management Assessment Initiative, funded by NASA s Office of Safety and Mission Assurance under the Software Assurance Research Program, aims to address these problems by: Improving the effectiveness of early life-cycle V&V activities to make their benefits more attractive to team leads. Specifically, we focus on software inspection, a proven method that can be applied to any software work product, long before executable code has been developed; Better communicating this effectiveness to software development teams, along with suggestions for parameters to improve in the future to increase effectiveness; Analyzing the impact of early life-cycle V&V on the effectiveness and cost required for late life-cycle V&V activities, such as testing, in order to make the tradeoffs more apparent. This white paper reports on an initial milestone in this work, the development of a preliminary model of inspection effectiveness across multiple NASA Centers. This model contributes toward reaching our project goals by: Allowing an examination of inspection parameters, across different types of projects and different work products, for an analysis of factors that impact defect detection effectiveness. Allowing a comparison of this NASA-specific model to existing recommendations in the literature regarding how to plan effective inspections. Forming a baseline model which can be extended to incorporate factors describing: the numbers and types of defects that are missed by inspections; how such defects flow downstream through software development phases; how effectively they can be caught by testing activities in the late stages of development. The model has been implemented in a prototype web-enabled decision-support tool which allows developers to enter their inspection data and receive feedback based on a comparison against the model. The tool also allows users to access reusable materials (such as checklists) from projects included in the baseline. Both the tool itself and the model underlying it will continue to be extended throughout the remainder of this initiative. As results of analyzing inspection effectiveness for defect containment are determined, they can be shared via the tool and also via updates to existing training courses on metrics and software inspections. Moreover, the tool will help satisfy key CMMI requirements for the NASA Centers, as it will enable NASA to take a global view across peer review results for various types of projects to identify systemic problems. This analysis can result in continuous improvements to the approach to verification.

Shull, Forrest↗
NASA NTRS2008

Exhaustive Thresholds and Resistance Checkpoints

Once deployed, all intricate systems that operate for a long time (such as an airplane or chemical processing plant) experience degraded performance during operational lifetime. These can result from losses of integrity in subsystems and parts that generally do not materially impact the operation of the vehicle (e.g., the light behind the button that opens the sliding door of the minivan). Or it can result from loss of more critical parts or subsystems. Such losses need to be handled quickly in order to avoid loss of personnel, mission, or part of the system itself. In order to manage degraded systems, knowledge of its potential problem areas and the means by which these problems are detected should be developed during the initial development of the system. Once determined, a web of sensors is employed and their outputs are monitored with other system parameters while the system is in preparation or operation. Just gathering the data is only part of the story. The interpretation of the data itself and the response of the system must be carefully developed as well to avoid a mishap. Typically, systems use a test-threshold-response paradigm to process potential system faults. However, such processing sub-systems can suffer from errors and oversights of a consistent type, causing system aberrant behavior instead of expected system and recovery operations. In our study, we developed a complete checklist for determining the completeness of a fault system and its robustness to common processing and response difficulties.

Easton, Charles↗
NASA NTRS2004

Security Risks: Management and Mitigation in the Software Life Cycle

A formal approach to managing and mitigating security risks in the software life cycle is requisite to developing software that has a higher degree of assurance that it is free of security defects which pose risk to the computing environment and the organization. Due to its criticality, security should be integrated as a formal approach in the software life cycle. Both a software security checklist and assessment tools should be incorporated into this life cycle process and integrated with a security risk assessment and mitigation tool. The current research at JPL addresses these areas through the development of a Sotfware Security Assessment Instrument (SSAI) and integrating it with a Defect Detection and Prevention (DDP) risk management tool.

securiy↗
NASA NTRS2001

Configural Scoring of Simulator Sickness, Cybersickness and Space Adaptation Syndrome: Similarities and Differences?

From a survey of ten U.S. Navy flight simulators a large number (N > 1,600 exposures) of self-reports of motion sickness symptomatology were obtained. Using these data, scoring algorithms were derived, which permit examination of groups of individuals that can be scored either for 1) their total sickness experience in a particular device; or, 2) according to three separable symptom clusters which emerged from a Factor Analysis. Scores from this total score are found to be proportional to other global motion sickness symptom checklist scores with which they correlate (r = 0.82). The factors that surfaced from the analysis include clusters of symptoms referable as nausea, oculomotor disturbances, and disorientation (N, 0, and D). The factor scores may have utility in differentiating the source of symptoms in different devices. The present chapter describes our experience with the use of both of these types of scores and illustrates their use with examples from flight simulators, space sickness and virtual environments.

Kennedy, Robert S.↗
NASA NTRS2010

The ICARE Method

The ICARE method is a flexible, widely applicable method for systems engineers to solve problems and resolve issues in a complete and comprehensive manner. The method can be tailored by diverse users for direct application to their function (e.g. system integrators, design engineers, technical discipline leads, analysts, etc.). The clever acronym, ICARE, instills the attitude of accountability, safety, technical rigor and engagement in the problem resolution: Identify, Communicate, Assess, Report, Execute (ICARE). This method was developed through observation of Space Shuttle Propulsion Systems Engineering and Integration (PSE&I) office personnel approach in an attempt to succinctly describe the actions of an effective systems engineer. Additionally it evolved from an effort to make a broadly-defined checklist for a PSE&I worker to perform their responsibilities in an iterative and recursive manner. The National Aeronautics and Space Administration (NASA) Systems Engineering Handbook states, engineering of NASA systems requires a systematic and disciplined set of processes that are applied recursively and iteratively for the design, development, operation, maintenance, and closeout of systems throughout the life cycle of the programs and projects. ICARE is a method that can be applied within the boundaries and requirements of NASA s systems engineering set of processes to provide an elevated sense of duty and responsibility to crew and vehicle safety. The importance of a disciplined set of processes and a safety-conscious mindset increases with the complexity of the system. Moreover, the larger the system and the larger the workforce, the more important it is to encourage the usage of the ICARE method as widely as possible. According to the NASA Systems Engineering Handbook, elements of a system can include people, hardware, software, facilities, policies and documents; all things required to produce system-level results, qualities, properties, characteristics, functions, behavior and performance. The ICARE method can be used to improve all elements of a system and, consequently, the system-level functional, physical and operational performance. Even though ICARE was specifically designed for a systems engineer, any person whose job is to examine another person, product, or process can use the ICARE method to improve effectiveness, implementation, usefulness, value, capability, efficiency, integration, design, and/or marketability. This paper provides the details of the ICARE method, emphasizing the method s application to systems engineering. In addition, a sample of other, non-systems engineering applications are briefly discussed to demonstrate how ICARE can be tailored to a variety of diverse jobs (from project management to parenting).

Henke, Luke↗
NASA NTRS2011

Multi-Center Implementation of NPR 7123.1A: A Collaborative Effort

Collaboration efforts between MSFC and GRC Engineering Directorates to implement the NASA Systems Engineering (SE) Engine have expanded over the past year to include other NASA Centers. Sharing information on designing, developing, and deploying SE processes has sparked further interest based on the realization that there is relative consistency in implementing SE processes at the institutional level. This presentation will provide a status on the ongoing multi-center collaboration and provide insight into how these NPR 7123.1A SE-aligned directives are being implemented and managed to better support the needs of NASA programs and projects. NPR 7123.1A, NASA Systems Engineering Processes and Requirements, was released on March 26, 2007 to clearly articulate and establish the requirements on the implementing organization for performing, supporting, and evaluating SE activities. In early 2009, MSFC and GRC Engineering Directorates undertook a collaborative opportunity to share their research and work associated with developing, updating and revising their SE process policy to comply and align with NPR 7123.1A. The goal is to develop instructions, checklists, templates, and procedures for each of the 17 SE process requirements so that systems engineers will be a position to define work that is process-driven. Greater efficiency and more effective technical management will be achieved due to consistency and repeatability of SE process implementation across and throughout each of the NASA centers. An added benefit will be to encourage NASA centers to pursue and collaborate on joint projects as a result of using common or similar processes, methods, tools, and techniques.

Hall, Phillip B.↗
NASA NTRS2005

Designing Flight Deck Procedures

Three reports address the design of flight-deck procedures and various aspects of human interaction with cockpit systems that have direct impact on flight safety. One report, On the Typography of Flight- Deck Documentation, discusses basic research about typography and the kind of information needed by designers of flight deck documentation. Flight crews reading poorly designed documentation may easily overlook a crucial item on the checklist. The report surveys and summarizes the available literature regarding the design and typographical aspects of printed material. It focuses on typographical factors such as proper typefaces, character height, use of lower- and upper-case characters, line length, and spacing. Graphical aspects such as layout, color coding, fonts, and character contrast are discussed; and several cockpit conditions such as lighting levels and glare are addressed, as well as usage factors such as angular alignment, paper quality, and colors. Most of the insights and recommendations discussed in this report are transferable to paperless cockpit systems of the future and computer-based procedure displays (e.g., "electronic flight bag") in aerospace systems and similar systems that are used in other industries such as medical, nuclear systems, maritime operations, and military systems.

Degani, Asaf↗
NASA NTRS2011

The First Flight Decision for New Human Spacecraft Vehicles - A General Approach

Determining when it is safe to fly a crew on a launch vehicle/spacecraft for the first time, especially when the test flight is a part of the overall system certification process, has long been a challenge for program decision makers. The decision on first flight is ultimately the judgment of the program and agency management in conjunction with the design and operations team. To aid in this decision process, a NASA team undertook the task to develop a generic framework for evaluating whether any given program or commercial provider has sufficiently complete and balanced plans in place to allow crewmembers to safely fly on human spaceflight systems for the first time. It was the team s goal to establish a generic framework that could easily be applied to any new system, although the system design and intended mission would require specific assessment. Historical data shows that there are multiple approaches that have been successful in first flight with crew. These approaches have always been tailored to the specific system design, mission objectives, and launch environment. Because specific approaches may vary significantly between different system designs and situations, prescriptive instructions or thorough checklists cannot be provided ahead of time. There are, however, certain general approaches that should be applied in thinking through the decision for first flight. This paper addresses some of the most important factors to consider when developing a new system or evaluating an existing system for whether or not it is safe to fly humans to/from space. In the simplest terms, it is time to fly crew for the first time when it is safe to do so and the benefit of the crewed flight is greater than the residual risk. This is rarely a straight-forward decision. The paper describes the need for experience, sound judgment, close involvement of the technical and management teams, and established decision processes. In addition, the underlying level of confidence the manager has in making the decision will also be discussed. By applying the outlined thought processes and approaches to a specific design, test program and mission objectives, a project team will be better able to focus the debate and discussion on critical areas for consideration and added scrutiny -- allowing decision makers to adequately address the first crewed flight decision.

Schaible, Dawn M.↗
NASA NTRS2012

Using Agent Based Modeling (ABM) to Develop Cultural Interaction Simulations

Today, most cultural training is based on or built around "cultural engagements" or discrete interactions between the individual learner and one or more cultural "others". Often, success in the engagement is the end or the objective. In reality, these interactions usually involve secondary and tertiary effects with potentially wide ranging consequences. The concern is that learning culture within a strict engagement context might lead to "checklist" cultural thinking that will not empower learners to understand the full consequence of their actions. We propose the use of agent based modeling (ABM) to collect, store, and, simulating the effects of social networks, promulgate engagement effects over time, distance, and consequence. The ABM development allows for rapid modification to re-create any number of population types, extending the applicability of the model to any requirement for social modeling.

Drucker, Nick↗
NASA NTRS2013

Project Profile: Hydrogen Fuel Cell Mobile Lighting Tower (HFCML)

NASA is committed to finding innovative solutions that improve the operational performance of ground support equipment while providing environment and cost benefits, as well. Through the Hydrogen Fuel Cell Mobile Lighting Tower (HFCML) project, NASA gained operational exposure to a novel application of high efficiency technologies. Traditionally, outdoor lighting and auxiliary power at security gates, launch viewing sites, fallback areas, outage support, and special events is provided by diesel generators with metal halide lights. Diesel generators inherently contribute to C02, NOx, particulate emissions, and are very noisy. In 2010, engineers from NASA's Technology Evaluation for Environmental Risk Mitigation Principal Center (TEERM) introduced KSC operations to a novel technology for outdoor lighting needs. Developed by a team led by Sandia National Laboratory (SNL), the technology pairs a 5kW hydrogen fuel cell with robust high efficiency plasma lights in a towable trailer. Increased efficiency, in both the fuel cell power source and lighting load, yields longer run times between fueling operations while providing greater auxiliary power. Because of the unit's quiet operation and no exhaust fumes, it is capable of being used indoors and in emergency situations, and meets the needs of all other operational roles for metal halide/diesel generators. The only discharge is some water and warm air. Environmental benefits include elimination of diesel particulate emissions and estimated 73% greenhouse gas emissions savings when the hydrogen source is natural gas (per GREET model). As the technology matures the costs could become competitive for the fuel cell units which are approximately 5 times diesel units. Initial operational . concerns included the hydrogen storage tanks and valves, lightning safety/grounding, and required operating and refueling procedures. TEERM facilitated technical information exchange (design drawings, technical standards, and operations manuals) necessary for KSC hydrogen system experts to approve use of the HFCML unit, including initiating the environmental checklist (i.e. exterior lighting waiver due to sea turtles), and development of operations and maintenance instructions. TEERM worked with SNL to establish a bailment agreement for KSC to utilize a Beta unit as part of normal Center Operations for a period of twelve months.

McLaughlin, Russell↗
NASA NTRS2013

MPST Software: grl_pef_check

This innovation is a tool used to verify and validate spacecraft sequences at the predicted events file (PEF) level for the GRAIL (Gravity Recovery and Interior Laboratory, see http://www.nasa. gov/mission_pages/grail/main/index. html) mission as part of the Multi-Mission Planning and Sequencing Team (MPST) operations process to reduce the possibility for errors. This tool is used to catch any sequence related errors or issues immediately after the seqgen modeling to streamline downstream processes. This script verifies and validates the seqgen modeling for the GRAIL MPST process. A PEF is provided as input, and dozens of checks are performed on it to verify and validate the command products including command content, command ordering, flight-rule violations, modeling boundary consistency, resource limits, and ground commanding consistency. By performing as many checks as early in the process as possible, grl_pef_check streamlines the MPST task of generating GRAIL command and modeled products on an aggressive schedule. By enumerating each check being performed, and clearly stating the criteria and assumptions made at each step, grl_pef_check can be used as a manual checklist as well as an automated tool. This helper script was written with a focus on enabling the user with the information they need in order to evaluate a sequence quickly and efficiently, while still keeping them informed and active in the overall sequencing process. grl_pef_check verifies and validates the modeling and sequence content prior to investing any more effort into the build. There are dozens of various items in the modeling run that need to be checked, which is a time-consuming and errorprone task. Currently, no software exists that provides this functionality. Compared to a manual process, this script reduces human error and saves considerable man-hours by automating and streamlining the mission planning and sequencing task for the GRAIL mission.

Call, Jared A.↗
NASA NTRS2013

Prospective Safety Analysis and the Complex Aviation System

Fatal accident rates in commercial passenger aviation are at historic lows yet have plateaued and are not showing evidence of further safety advances. Modern aircraft accidents reflect both historic causal factors and new unexpected "Black Swan" events. The ever-increasing complexity of the aviation system, along with its associated technology and organizational relationships, provides fertile ground for fresh problems. It is important to take a proactive approach to aviation safety by working to identify novel causation mechanisms for future aviation accidents before they happen. Progress has been made in using of historic data to identify the telltale signals preceding aviation accidents and incidents, using the large repositories of discrete and continuous data on aircraft and air traffic control performance and information reported by front-line personnel. Nevertheless, the aviation community is increasingly embracing predictive approaches to aviation safety. The "prospective workshop" early assessment tool described in this paper represents an approach toward this prospective mindset-one that attempts to identify the future vectors of aviation and asks the question: "What haven't we considered in our current safety assessments?" New causation mechanisms threatening aviation safety will arise in the future because new (or revised) systems and procedures will have to be used under future contextual conditions that have not been properly anticipated. Many simulation models exist for demonstrating the safety cases of new operational concepts and technologies. However the results from such models can only be as valid as the accuracy and completeness of assumptions made about the future context in which the new operational concepts and/or technologies will be immersed. Of course that future has not happened yet. What is needed is a reasonably high-confidence description of the future operational context, capturing critical contextual characteristics that modulate both the likelihood of occurrence of hazards, and the likelihood that those hazards will lead to negative safety events. Heuristics extracted from scenarios, questionnaires, and observed trends from scanning the aviation horizon may be helpful in capturing those future changes in a way conducive to safety assessment. What is also needed is a checklist of potential sources of emerging risk that arise from organizational features that are frequently overlooked. The ultimate goal is to develop a pragmatic, workable method for using descriptions of the future aviation context, to generate valid predictions of safety risks.

prospection↗
NASA NTRS2014

Mobilization Protocols for Hybrid Sensors for Environmental AOP Sampling (HySEAS) Observations

The protocols presented here enable the proper mobilization of the latest-generation instruments for measuring the apparent optical properties (AOPs) of aquatic ecosystems. The protocols are designed for the Hybrid Sensors for Environmental AOP Sampling (HySEAS) class of instruments, but are applicable to the community of practice for AOP measurements. The protocols are organized into eleven sections beyond an introductory overview: a) cables and connectors, b) HySEAS instruments, c) platform preparation, d) instrument installation, e) cable installation, f) test deployment, g) test recovery, h) maintenance, i) shipping, j) storage, and k) smallboat operations. Each section concentrates on documenting how to prevent the most likely faults, remedy them should they occur, and accomplishing both with the proper application of a modest set of useful tools. Within the twelve sections, there are Socratic exercises to stimulate thought, and the answers to these exercises appear in Appendix A. Frequently asked questions (FAQs) are summarized in a separate section after the answers to the exercises in Appendix B. For practitioners unfamiliar with the nautical terms used throughout this document plus others likely encountered at sea, an abbreviated dictionary of nautical terms appears in Appendix C. An abbreviated dictionary of radiotelephone terms is presented in Appendix D. To ensure familiarity with many of the tools that are presented, Appendix E provides a description of the tools alongside a thumbnail picture. Abbreviated deployment checklists and cable diagrams are provided in Appendix F. The document concludes with an acknowledgments section, a glossary of acronyms, a definition of symbols, and a list of references.

Mobilizarion↗
NASA NTRS2016

Intern Abstract for Spring 2016

The Human Interface Branch - EV3 - is evaluating Organic lighting-emitting diodes (OLEDs) as an upgrade for current displays on future spacecraft. OLEDs have many advantages over current displays. Conventional displays require constant backlighting which draws a lot of power, but with OLEDs they generate light themselves. OLEDs are lighter, and weight is always a concern with space launches. OLEDs also grant greater viewing angles. OLEDs have been in the commercial market for almost ten years now. What is not known is how they will perform in a space-like environment; specifically deep space far away from the Earth's magnetosphere. In this environment, the OLEDs can be expected to experience vacuum and galactic radiation. The intern's responsibility has been to prepare the OLED for a battery of tests. Unfortunately, it will not be ready for testing at the end of the internship. That being said much progress has been made: a) Developed procedures to safely disassemble the tablet. b) Inventoried and identified critical electronic components. c) 3D printed a testing apparatus. d) Wrote software in Python that will test the OLED screen while being radiated. e) Built circuits to restart the tablet and the test pattern, and ensure it doesn't fall asleep during radiation testing. f) Built enclosure that will house all of the electronics Also, the intern has been working on a way to take messages from a simulated Caution and Warnings system, process said messages into packets, send audio packets to a multicast address that audio boxes are listening to, and output spoken audio. Currently, Cautions and Warnings use a tone to alert crew members of a situation, and then crew members have to read through their checklists to determine what the tone means. In urgent situations, EV3 wants to deliver concise and specific alerts to the crew to facilitate any mitigation efforts on their part. Significant progress was made on this project: a) Open channel with the simulated Caution and Warning system to acquire messages. b) Configure audio boxes. c) Grab pre-recorded audio files. d) Packetize the audio stream. A third project that was assigned to implement LED indicator modules for an Omnibus project. The Omnibus project is investigating better ways designing lighting for the interior of spacecraft-both spacecraft lighting and avionics box status lighting indication. The current scheme contains too much of the blue light spectrum that disrupts the sleep cycle. The LED indicator modules are to simulate the indicators running on a spacecraft. Lighting data will be gathered by human factors personal and use in a model underdevelopment to model spacecraft lighting. Significant progress was made on this project: Designed circuit layout a) Tested LEDs at LETF. b) Created GUI for the indicators. c) Created code for the Arduino to run that will illuminate the indicator modules.

Gibson, William↗