Assessing safety requirements for hydrogen fuel cell use in maritime applications using computational fluid dynamics.
Abstract not provided.
SEARCH · Search NASA
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.
Abstract not provided.
Topics dealing with nuclear safety are addressed which include the following: general safety requirements; safety design requirements; terrestrial safety; SP-100 Flight System key safety requirements; potential mission accidents and hazards; key safety features; ground operations; launch operations; flight operations; disposal; safety concerns; licensing; the nuclear engine for rocket vehicle application (NERVA) design philosophy; the NERVA flight safety program; and the NERVA safety plan.
A study was conducted to develop space tug operational concepts and baseline operations plan, and to provide cost estimates for space tug operations. Background data and study results are presented along with a transition phase analysis (the transition from interim upper state to tug operations). A summary is given of the tug operational and interface requirements with emphasis on the on-orbit checkout requirements, external interface operational requirements, safety requirements, and system operational interface requirements. Other topics discussed include reference missions baselined for the tug and details for the mission functional flows and timelines derived for the tug mission, tug subsystems, tug on-orbit operations prior to the tug first burn, spacecraft deployment and retrieval by the tug, operations centers, mission planning, potential problem areas, and cost data.
It is the goal of Moon to Mars (M2M) to establish a single consolidated set of safety requirements and a safety review process for utilization payloads that will cross program vehicle hatches or operate externally on multiple program vehicles during transport or operation that satisfies Exploration Ground Systems (EGS), Orion, EVA, and Human Surface Mobility Program (EHP), Gateway (GW), and Human Landing System (HLS) programs. This document defines the Cross Program Utilization Payload (xPUP) safety review process for mission effectivity of Artemis III and beyond. This review process will help ensure protection of the overall Moon to Mars integrated system from potential hazards created by cross program payloads that either cross a program vehicle hatch or can interface with more than one M2M lunar exploration program vehicle. The process will identify payload hazards and controls that will protect ground personnel, flight crew, the integrated vehicle, ground equipment, or facilities. This process is also applicable to samples that cross hatches between vehicles including for return to Earth. The xPUP safety review process will be led by one of the M2M programs' integration safety panels, chosen on a per-payload basis. After the lead integration safety panel is determined, the common safety process is established, based on pre-determined criteria, which includes ad-hoc members from other stakeholder programs. Stakeholder programs are those that interface with the utilization payload in any way (e.g., operating on a lunar exploration vehicle or crossing program vehicle hatches). The xPUP will execute this safety review process for flight and ground utilization payload hardware design, its ground support equipment, and landing and recovery in accordance with the applicable safety requirements as specified in M2M-30043: Moon to Mars Cross Program Utilization Payload Safety Requirements. The xPUP safety process will follow the lead integration safety panel’s safety process requirements. Formal agreements will be communicated with the payload developer using the payload integration processes documented in M2M-30037, Artemis Payload Integration Implementation Plan.
Safety requirements for photovoltaic module and panel designs and configurations for residential, intermediate, and large scale applications are investigated. Concepts for safety systems, where each system is a collection of subsystems which together address the total anticipated hazard situation, are described. Descriptions of hardware, and system usefulness and viability are included. A comparison of these systems, as against the provisions of the 1984 National Electrical Code covering photovoltaic systems is made. A discussion of the Underwriters Laboratory UL investigation of the photovoltaic module evaluated to the provisions of the proposed UL standard for plat plate photovoltaic modules and panels is included. Grounding systems, their basis and nature, and the advantages and disadvantages of each are described. The meaning of frame grounding, circuit groundings, and the type of circuit ground are covered.
Safety-critical computer systems must be engineered to meet system and software safety requirements. For legacy safety-critical computer systems, software safety requirements may not have been formally specified during development. When process-oriented software safety requirements are levied on a legacy system after the fact, where software development artifacts don't exist or are incomplete, the question becomes 'how can this be done?' The risks associated with only meeting certain software safety requirements in a legacy safety-critical computer system must be addressed should such systems be selected as candidates for reuse. This paper proposes a method for ascertaining formally, a software safety risk assessment, that provides measurements for software safety for legacy systems which may or may not have a suite of software engineering documentation that is now normally required. It relies upon the NASA Software Safety Standard, risk assessment methods based upon the Taxonomy-Based Questionnaire, and the application of reverse engineering CASE tools to produce original design documents for legacy systems.
Pairwise Trajectory Management (PTM) is an Interval Management (IM) concept that utilizes airborne and ground-based capabilities to enable the implementation of airborne pairwise spacing capabilities in oceanic regions. The goal of PTM is to use airborne surveillance and tools to manage an "at or greater than" inter-aircraft spacing. Due to the accuracy of Automatic Dependent Surveillance-Broadcast (ADS-B) information and the use of airborne spacing guidance, the minimum PTM spacing distance will be less than distances a controller can support with current automation systems that support oceanic operations. Ground tools assist the controller in evaluating the traffic picture and determining appropriate PTM clearances to be issued. Avionics systems provide guidance information that allows the flight crew to conform to the PTM clearance issued by the controller. The combination of a reduced minimum distance and airborne spacing management will increase the capacity and efficiency of aircraft operations at a given altitude or volume of airspace. This document provides an overview of the proposed application, a description of several key scenarios, a high level discussion of expected air and ground equipment and procedure changes, a description of a NASA human-machine interface (HMI) prototype for the flight crew that would support PTM operations, and initial benefits analysis results. Additionally, included as appendices, are the following documents: the PTM Operational Services and Environment Definition (OSED) document and a companion "Future Considerations for the Pairwise Trajectory Management (PTM) Concept: Potential Future Updates for the PTM OSED" paper, a detailed description of the PTM algorithm and PTM Limit Mach rules, initial PTM safety requirements and safety assessment documents, a detailed description of the design, development, and initial evaluations of the proposed flight crew HMI, an overview of the methodology and results of PTM pilot training requirements focus group and human-in-the-loop testing activities, and the PTM Pilot Guide.
An overview of the development test flight (DTF-1) mission is presented, and the system design, safety requirements, and safety features are described. The lessons that were learned during the design and early development stages are also presented. The DTF-1 mission objectives are to evaluate: the overall man-machine performance in zero G, Flight Telerobotic Service manipulator design, and workstation design, including handcontrollers and displays. The payload bay and aft flight deck elements, and computer control of the DTF-1 are described. Recommendations for developing and implementing a safety system are presented, and some design alternatives for the next space-qualified telerobotic system are suggested.
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.
Assuring personnel and equipment are fully protected during the Space Shuttle launch and landing operations has been a primary concern of NASA and its associated contractors since the inception of the program. A key factor in support of this policy has been the area access safety training requirements for badging of employees assigned to work on Space Shuttle Launch and Facilities. This requirement was targeted for possible cost savings and the transition of physical on-site walkdowns to the use of television tapes has realized program cost savings while continuing to fully satisfy the area access safety training requirements.
This paper reports the results of a small study of requirements changes to the onboard software of three spacecraft subsequent to launch. Only those requirement changes that resulted from post-launch anomalies (i.e., durring operations) were of interest here, since the goal was to better understand the relationship between critical anomolies during operations and how safety-critical requirements evolve.
A paramount objective of all human-rated launch and reentry vehicle developers is to ensure that the risks to both the crew onboard and the public are minimized within reasonable cost, schedule, and technical constraints. Past experience has shown that proper attention to range safety requirements necessary to ensure public safety must be given early in the design phase to avoid additional operational complexities or threats to the safety of people onboard, and the design engineers must give these requirements the same consideration as crew safety requirements. For human spaceflight, the primary purpose and operational concept for any flight safety system is to protect the public while maximizing the likelihood of crew survival. This paper will outline the policy considerations, technical issues, and operational impacts regarding launch and reentry vehicle failure scenarios where crew and public safety are intertwined and thus addressed optimally in an integrated manner. An overview of existing range and crew safety policy requirements will be presented. Application of these requirements and lessons learned from both the Space Shuttle and Constellation Programs will also be discussed. Using these past programs as examples, the paper will detail operational, design, and analysis approaches to mitigate and balance the risks to people onboard and in the public. Manned vehicle perspectives from the Federal Aviation Administration (FAA) and Air Force organizations that oversee public safety will be summarized as well. Finally, the paper will emphasize the need to factor policy, operational, and analysis considerations into the early design trades of new vehicles to help ensure that both crew and public safety are maximized to the greatest extent possible.
This paper reports the results of a small study of requirements changes to the onboard software of three spacecraft subsequent to launch. Only those requirement changes that resulted from post-launch anoma-lies (i.e., during operations) were of interest here, since the goal was to better understand the relation-ship between critical anomalies during operations and how safety-critical requirements evolve. The results of the study were surprising in that anomaly-driven, post-launch requirements changes were rarely due to previous requirements having been incorrect. Instead, changes involved new requirements (1) for the software to handle rare events or (2) for the software to compensate for hardware failures or limitations. The prevalence of new requirements as a result of post-launch anomalies suggests a need for increased requirements-engineering support of maintenance activities in these systems. The results also confirm both the difficulty and the benefits of pursuing requirements completeness, especially in terms of fault tolerance, during development of critical systems.
Communications support for the X-33 requires addressing several interesting challenges to meet program and range safety requirements. In addition, the heavily cost driven program has provided concessions to the communications support to reduce the cost of networking the extended range. Cost trade-offs showed that by lowering the telemetry data rate from 2 Megabits per second to 1440 Megabits per second that significant cost avoidance could be realized. Also, by adopting standard telecommunications data rate for the uplink data stream, an efficient and integrated solution for the extended range communications could be supported. Meeting the program requirements as well as range safety requirements for this effort are critical to the success of the program. This paper describes some of the important requirements driving the design of the extended range communications support and the design of the system to meet those requirements.
The Nuclear Power and Propulsion Technical Discipline Team has directed an effort to consider possible improvements to the launch approval process as it relates to fission reactors. To that end, Reference 1 described possible general design criteria and risk criteria for fission reactors. At the time that Reference 1 was completed, it was felt that additional examination of reentry issues was warranted. This paper presents the next step in that examination, which is to accurately describe and frame the problem and suggest safety criteria that might apply to inadvertent reentry. The report includes a discussion of the issues associated with different types of inadvertent reentry, the possible consequences of those events, a review of previous work in the area, security and nonproliferation issues, and options for safety requirements that might be considered. Note that safety requirements can have significant mission implications, e.g., no operation below a certain orbit.
Good requirements are the first step for good communications, and good communications are central to insure an understanding between the customer and contractor. Failure to generate good requirements is unfortunately commonplace and repeated. Waivers to requirements are discussed from a risk based point of view. The assumption that every requirement will eventually be waived is used to establish a critical review of a draft safety requirement. Validation methods of requirements are addressed. Value added that safety requirements contribute to the Project is estimated to further our critical review of draft requirements.
This study examines potential improvements that could be made to the nuclear safety and launch approval process for fission reactors to reduce the associated uncertainties in cost and schedule while continuing to ensure public safety and environmental protection. It concentrates on the launch approval and mission safety of fission power and propulsion applications of nuclear energy. Improvements to the launch approval process for radioisotope power systems (RPSs) are being considered elsewhere but are acknowledged throughout the report. The study considered technical, process, and organizational improvements to the launch approval processes. The study exclusively evaluated reactors that would not be started up prior to achieving a “sufficiently high orbit,” per United Nations (UN) Resolution 47/68.Potential criticality accidents were considered that could occur during a launch failure or abort or during reentry. Numerous scenarios were examined that might involve one or more Earth flybys as well as potential transportation missions that could intentionally return an active, or previously active fission reactor to Earth orbit. The Study Group was guided in its deliberations according to a number of fundamental principles. These included the paramount importance of adequate and appropriate levels of public safety and environmental protection as well as the importance of the inclusion of independent scientific, engineering, and safety reviews of the applications and proposals as a critical part of the process. Also considered was the need for the development of launch approval processes that might be different, depending upon the source of the application for launch approval, whether it be derived as a governmental launch, a commercial launch, or a hybrid/combination of the two. It is clear that all launches of nuclear reactors into space should have similar safety requirements; however, the safety review effort and the details of the analysis that are required should be commensurate with the potential hazards and the actual risk, which may differ based on the reactor design and its intended purpose. Finally, the study aimed at ensuring that whatever processes and procedures are developed should maximize the sufficiency, simplicity, and transparency of the processes. The Study Group reached five Conclusions and makes thirteen Recommendations. The Conclusions and Recommendations presented here are extensions of those presented previously in other studies. This report attempts to add specificity to the actions that need to be taken in order to move forward with successful space fission reactor programs. Without action to address the perceived and real problems in the launch approval process, designers and mission managers will be reluctant to commit the resources necessary to make space fission reactors a reality.
Aerospace systems are developed similarly to other large-scale systems through a series of reviews, where designs are modified as system requirements are refined. For space-based systems few are built and placed into service. These research vehicles have limited historical experience to draw from and formidable reliability and safety requirements, due to the remote and severe environment of space. Aeronautical systems have similar reliability and safety requirements, and while these systems may have historical information to access, commercial and military systems require longevity under a range of operational conditions and applied loads. Historically, the design of aerospace systems, particularly the selection of sensors, is based on the requirements for control and performance rather than on health assessment needs. Furthermore, the safety and reliability requirements are met through sensor suite augmentation in an ad hoc, heuristic manner, rather than any systematic approach. A review of the current sensor selection practice within and outside of the aerospace community was conducted and a sensor selection architecture is proposed that will provide a justifiable, dependable sensor suite to address system health assessment requirements.