Search NASA⌕ Search

SEARCH · Search NASA

Results for “safety standards”

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS1997

NASA Software Safety Standard

If software is a critical element in a safety critical system, it is imperative to implement a systematic approach to software safety as an integral part of the overall system safety programs. The NASA-STD-8719.13A, "NASA Software Safety Standard", describes the activities necessary to ensure that safety is designed into software that is acquired or developed by NASA, and that safety is maintained throughout the software life cycle. A PDF version, is available on the WWW from Lewis. A Guidebook that will assist in the implementation of the requirements in the Safety Standard is under development at the Lewis Research Center (LeRC). After completion, it will also be available on the WWW from Lewis.

Rosenberg, Linda↗
NASA NTRS2007

NASA's Software Safety Standard

NASA relies more and more on software to control, monitor, and verify its safety critical systems, facilities and operations. Since the 1960's there has hardly been a spacecraft launched that does not have a computer on board that will provide command and control services. There have been recent incidents where software has played a role in high-profile mission failures and hazardous incidents. For example, the Mars Orbiter, Mars Polar Lander, the DART (Demonstration of Autonomous Rendezvous Technology), and MER (Mars Exploration Rover) Spirit anomalies were all caused or contributed to by software. The Mission Control Centers for the Shuttle, ISS, and unmanned programs are highly dependant on software for data displays, analysis, and mission planning. Despite this growing dependence on software control and monitoring, there has been little to no consistent application of software safety practices and methodology to NASA's projects with safety critical software. Meanwhile, academia and private industry have been stepping forward with procedures and standards for safety critical systems and software, for example Dr. Nancy Leveson's book Safeware: System Safety and Computers. The NASA Software Safety Standard, originally published in 1997, was widely ignored due to its complexity and poor organization. It also focused on concepts rather than definite procedural requirements organized around a software project lifecycle. Led by NASA Headquarters Office of Safety and Mission Assurance, the NASA Software Safety Standard has recently undergone a significant update. This new standard provides the procedures and guidelines for evaluating a project for safety criticality and then lays out the minimum project lifecycle requirements to assure the software is created, operated, and maintained in the safest possible manner. This update of the standard clearly delineates the minimum set of software safety requirements for a project without detailing the implementation for those requirements. This allows the projects leeway to meet these requirements in many forms that best suit a particular project's needs and safety risk. In other words, it tells the project what to do, not how to do it. This update also incorporated advances in the state of the practice of software safety from academia and private industry. It addresses some of the more common issues now facing software developers in the NASA environment such as the use of Commercial-Off-the-Shelf Software (COTS), Modified OTS (MOTS), Government OTS (GOTS), and reused software. A team from across NASA developed the update and it has had both NASA-wide internal reviews by software engineering, quality, safety, and project management. It has also had expert external review. This presentation and paper will discuss the new NASA Software Safety Standard, its organization, and key features. It will start with a brief discussion of some NASA mission failures and incidents that had software as one of their root causes. It will then give a brief overview of the NASA Software Safety Process. This will include an overview of the key personnel responsibilities and functions that must be performed for safety-critical software.

Ramsay, Christopher M.↗
NASA NTRS2005

NASA's Software Safety Standard

NASA (National Aeronautics and Space Administration) relies more and more on software to control, monitor, and verify its safety critical systems, facilities and operations. Since the 1960's there has hardly been a spacecraft (manned or unmanned) launched that did not have a computer on board that provided vital command and control services. Despite this growing dependence on software control and monitoring, there has been no consistent application of software safety practices and methodology to NASA's projects with safety critical software. Led by the NASA Headquarters Office of Safety and Mission Assurance, the NASA Software Safety Standard (STD-18l9.13B) has recently undergone a significant update in an attempt to provide that consistency. This paper will discuss the key features of the new NASA Software Safety Standard. It will start with a brief history of the use and development of software in safety critical applications at NASA. It will then give a brief overview of the NASA Software Working Group and the approach it took to revise the software engineering process across the Agency.

Ramsay, Christopher M.↗
NASA NTRS1997

An overview of revised NASA safety standard 1740.14

Following a broad review of the debris control guidelines outside of NASA and according to additional feedback on the guidelines from within NASA, revisions were made to the NASA safety standard 1740.14. The NASA policy to limit the generation of orbital debris on NASA missions, stated in the NASA management instruction 1700.8 and implemented in the form of the NASA safety standard (NSS) 1740.14 is described together with the revisions implemented. The overall direction of the guidelines is the same, but the details of many of the guidelines were changed, including: changes for tether programs and for the control of operational debris. The NASA will continue to review the guidelines as new measurements and improved models of the environment are obtained.

Reynolds, Robert↗
NASA NTRS1990

NASA safety standard for lifting devices and equipment

NASA's minimum safety requirements are established for the design, testing, inspection, maintenance, certification, and use of overhead and gantry cranes (including top running monorail, underhung, and jib cranes), mobile cranes, derrick hoists, and special hoist supported personnel lifting devices (these do not include elevators, ground supported personnel lifts, or powered platforms). Minimum requirements are also addressed for the testing, inspection, and use of Hydra-sets, hooks, and slings. Safety standards are thoroughly detailed.

Source record↗
NASA NTRS1997

Safety Standard for Hydrogen and Hydrogen Systems: Guidelines for Hydrogen System Design, Materials Selection, Operations, Storage and Transportation

The NASA Safety Standard, which establishes a uniform process for hydrogen system design, materials selection, operation, storage, and transportation, is presented. The guidelines include suggestions for safely storing, handling, and using hydrogen in gaseous (GH2), liquid (LH2), or slush (SLH2) form whether used as a propellant or non-propellant. The handbook contains 9 chapters detailing properties and hazards, facility design, design of components, materials compatibility, detection, and transportation. Chapter 10 serves as a reference and the appendices contained therein include: assessment examples; scaling laws, explosions, blast effects, and fragmentation; codes, standards, and NASA directives; and relief devices along with a list of tables and figures, abbreviations, a glossary and an index for ease of use. The intent of the handbook is to provide enough information that it can be used alone, but at the same time, reference data sources that can provide much more detail if required.

Source record↗
NASA NTRS1995

NASA Safety Standard: Guidelines and Assessment Procedures for Limiting Orbital Debris

Collision with orbital debris is a hazard of growing concern as historically accepted practices and procedures have allowed man-made objects to accumulate in orbit. To limit future debris generation, NASA Management Instruction (NMI) 1700.8, 'Policy to Limit Orbital Debris Generation,' was issued in April of 1993. The NMI requires each program to conduct a formal assessment of the potential to generate orbital debris. This document serves as a companion to NMI 1700.08 and provides each NASA program with specific guidelines and assessment methods to assure compliance with the NMI. Each main debris assessment issue (e.g., Post Mission Disposal) is developed in a separate chapter.

Source record↗
NASA NTRS2009

NASA Space Safety Standards and Procedures for Human Rating Requirements

The National Aeronautics and Space Administration of the United States of America (NASA) has arguably led this planet in space exploration and certainly has been one of two major leaders in those endeavors. NASA governance is institutionalized and managed in a series documents arranged in a hierarchy and flowing down to the work levels. A document tree of NASA s documentation in its totality would likely overwhelm and not be very informative. Taken in segments related to the various business topics and focusing in those segments, however, provides a logical and understandable relationship and flow of requirements and processes. That is the nature of this chapter, a selection of NASA documentation pertaining to space exploration and a description of how those documents together form the plan by which NASA business for space exploration is conducted. Information presented herein is taken from NASA publications and is available publicly and no information herein is protected by copyright or security regulations. While NASA documents are the source of information presented herein, any and all views expressed herein and any misrepresentations of NASA data that may occur herein are those of the author and should not be considered NASA official positions or statements, nor should NASA endorsement of anything presented in this work be assumed.

Shivers, C. Herbert↗
NASA NTRS2007

Software Safety Risk in Legacy Safety-Critical Computer Systems

Safety Standards contain technical and process-oriented safety requirements. Technical requirements are those such as "must work" and "must not work" functions in the system. Process-Oriented requirements are software engineering and safety management process requirements. Address the system perspective and some cover just software in the system > NASA-STD-8719.13B Software Safety Standard is the current standard of interest. NASA programs/projects will have their own set of safety requirements derived from the standard. Safety Cases: a) Documented demonstration that a system complies with the specified safety requirements. b) Evidence is gathered on the integrity of the system and put forward as an argued case. [Gardener (ed.)] c) Problems occur when trying to meet safety standards, and thus make retrospective safety cases, in legacy safety-critical computer systems.

Hill, Janice L.↗
NASA NTRS2015

Planning the Unplanned Experiment: Assessing the Efficacy of Standards for Safety Critical Software

We need well-founded means of determining whether software is t for use in safety-critical applications. While software in industries such as aviation has an excellent safety record, the fact that software aws have contributed to deaths illustrates the need for justi ably high con dence in software. It is often argued that software is t for safety-critical use because it conforms to a standard for software in safety-critical systems. But little is known about whether such standards `work.' Reliance upon a standard without knowing whether it works is an experiment; without collecting data to assess the standard, this experiment is unplanned. This paper reports on a workshop intended to explore how standards could practicably be assessed. Planning the Unplanned Experiment: Assessing the Ecacy of Standards for Safety Critical Software (AESSCS) was held on 13 May 2014 in conjunction with the European Dependable Computing Conference (EDCC). We summarize and elaborate on the workshop's discussion of the topic, including both the presented positions and the dialogue that ensued.

Graydon, Patrick J.↗
NASA NTRS1989

Safety and cryogenic wind tunnels

The Langley 0.3-Meter Transonic Cryogenic Tunnel (0.3-m TCT) was placed in operation at NASA's Langley Research Center in 1973 as the world's first cryogenic pressure tunnel. The 0.3-m TCT can operate from ambient to cryogenic temperatures over an absolute pressure range from about 1 to 6 atmospheres. Three major test section concepts were developed and refined in this unique facility. The 0.3-m TCT is a leader in the development of various cryogenic pressure wind tunnel experimental techniques, instrumentation, control, model technology and safety standards. The safety experience gained is examined. During this period of advanced research, new operating techniques, training policies, and procedures had to be established. The paper deals with the Do's and Don'ts of cryogenic wind tunnel testing. Hazards and safety requirements which are unique to cryogenic testing are discussed. Highlights of experience and lessons learned with the 0.3-m TCT are reviewed.

Ray, Edward J.↗
NASA NTRS2007

Traceability of Software Safety Requirements in Legacy Safety Critical Systems

How can traceability of software safety requirements be created for legacy safety critical systems? Requirements in safety standards are imposed most times during contract negotiations. On the other hand, there are instances where safety standards are levied on legacy safety critical systems, some of which may be considered for reuse for new applications. Safety standards often specify that software development documentation include process-oriented and technical safety requirements, and also require that system and software safety analyses are performed supporting technical safety requirements implementation. So what can be done if the requisite documents for establishing and maintaining safety requirements traceability are not available?

Hill, Janice L.↗
NASA NTRS2001

Resources Available for Hazards Analysis of Aerospace Fluids

In recent years, the legislative and executive branches of the federal government have pushed to make government more efficient and responsive to the needs of the marketplace. One of these initiatives, Public Law 104-113, also known as the National Technology Transfer and Advancement Act of 1995 (NTTAA), is designed to accelerate technology transfer to industry and promote government-industry partnership. Summarized, NTTAA states that '... all Federal agencies and departments shall use technical standards that are developed or adopted by voluntary consensus standards bodies, using such technical standards as a means to carry out policy objectives or activities determined by the agencies and departments. Government agencies must now determine if their in-house requirement-setting activities are sufficiently unique that no public interest is served by having them adopted by a voluntary consensus organization (VCO), or if not, to use or develop voluntary consensus standards. The Office of Management and Budget (OMB) is chartered by the law to monitor federal agency progress and report the results to Congress. In response to NTTAA, agency-wide oxygen and hydrogen safety standards sponsored by the NASA Headquarters (HQ) Office of Safety and Mission Assurance (OSMA) were obvious choices for early adoption by VCOs. In 1996, HQ sought assistance from the Johnson Space Center (JSC) White Sands Test Facility (WSTF), the technical lead for development of these safety standards, to evaluate their adoption by VCOs. At that time, WSTF-developed propellant hazards manuals were likewise identified for possible VCO adoption. Subsequently, WSTF was asked to represent NASA for development of an international ISO safety standard for hydrogen use. Concurrent with these WSTF standards activities are related efforts to develop and publish propellant hazards analysis protocols and safety courses for the industrial, propellant use of oxygen, hydrogen, and hypergols. This paper reports on these efforts and describes WSTF's overall voluntary consensus standards program to coordinate the interchange of NASA's propellant hazards and safety information with industry.

Woods, S. S.↗
NASA NTRS2001

Space Debris Modeling at NASA

Since the Second European Conference on Space Debris in 1997, the Orbital Debris Program Office at the NASA Johnson Space Center has undertaken a major effort to update and improve the principal software tools employed to model the space debris environment and to evaluate mission risks. NASA's orbital debris engineering model, ORDEM, represents the current and near-term Earth orbital debris population from the largest spacecraft to the smallest debris in a manner which permits spacecraft engineers and experimenters to estimate the frequency and velocity with which a satellite may be struck by debris of different sizes. Using expanded databases and a new program design, ORDEM2000 provides a more accurate environment definition combined with a much broader array of output products in comparison with its predecessor, ORDEM96. Studies of the potential long-term space debris environment are now conducted with EVOLVE 4.0, which incorporates significant advances in debris characterization and breakup modeling. An adjunct to EVOLVE 4.0, GEO EVOLVE has been created to examine debris issues near the geosynchronous orbital regime. In support of NASA Safety Standard 1740.14, which establishes debris mitigation guidelines for all NASA space programs, a set of evaluation tools called the Debris Assessment Software (DAS) is specifically designed for program offices to determine whether they are in compliance with NASA debris mitigation guidelines. DAS 1.5 has recently been released with improved WINDOWS compatibility and graphics functions. DAS 2.0 will incorporate guideline changes in a forthcoming revision to NASA Safety Standard 1740.14. Whereas DAS contains a simplified model to calculate possible risks associated with satellite reentries, NASA's higher fidelity Object Reentry Survival Analysis Tool (ORSAT) has been upgraded to Version 5.0. With the growing awareness of the potential risks posed by uncontrolled satellite reentries to people and property on Earth, the application of both DAS and ORSAT has increased markedly in the past two years.

Johnson, Nicholas L.↗