Search NASA⌕ Search

SEARCH · Search NASA

Results for “Hazard analysis”

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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2009

A Reference Model for Software and System Inspections. White Paper

Software Quality Assurance (SQA) is an important component of the software development process. SQA processes provide assurance that the software products and processes in the project life cycle conform to their specified requirements by planning, enacting, and performing a set of activities to provide adequate confidence that quality is being built into the software. Typical techniques include: (1) Testing (2) Simulation (3) Model checking (4) Symbolic execution (5) Management reviews (6) Technical reviews (7) Inspections (8) Walk-throughs (9) Audits (10) Analysis (complexity analysis, control flow analysis, algorithmic analysis) (11) Formal method Our work over the last few years has resulted in substantial knowledge about SQA techniques, especially the areas of technical reviews and inspections. But can we apply the same QA techniques to the system development process? If yes, what kind of tailoring do we need before applying them in the system engineering context? If not, what types of QA techniques are actually used at system level? And, is there any room for improvement.) After a brief examination of the system engineering literature (especially focused on NASA and DoD guidance) we found that: (1) System and software development process interact with each other at different phases through development life cycle (2) Reviews are emphasized in both system and software development. (Figl.3). For some reviews (e.g. SRR, PDR, CDR), there are both system versions and software versions. (3) Analysis techniques are emphasized (e.g. Fault Tree Analysis, Preliminary Hazard Analysis) and some details are given about how to apply them. (4) Reviews are expected to use the outputs of the analysis techniques. In other words, these particular analyses are usually conducted in preparation for (before) reviews. The goal of our work is to explore the interaction between the Quality Assurance (QA) techniques at the system level and the software level.

He, Lulu↗
NASA NTRS2022

Run Time Assurance for Electric Vertical Takeoff and Landing Aircraft

NASA is conducting research to demonstrate and evaluate the application of Run Time Assurance (RTA) as a means to assure safety in Electric Vertical Takeoff and Landing (eVTOL) aircraft with highly automated or autonomous flight capability supervised by a single onboard pilot. The work described in this report demonstrates an application of RTA and examines the implications for design and analysis of aircraft functions and systems; aircraft safety hazards; safety assurance; development assurance; and pilot tasks and performance. This research effort also seeks to assess the efficacy of the combined application of traditional Functional Hazard Analysis (FHA) and the more modern System Theoretic Process Analysis (STPA) techniques to perform hazard analyses on aircraft with complex automated and autonomous systems and an onboard pilot. During the research effort we developed architectural designs of two alternate eVTOL aircraft, generally following the process characterized in the SAE standards ARP4754 and ARP4761. The design has focused on the control architectures of these aircraft, which are identical except that one incorporates RTA techniques to reduce the criticality of some key software components. Artifacts of this process include a taxonomy of aircraft-level functions, aircraft-level architecture diagrams, aircraft-level functional hazard assessments (AFHA), function allocations onto aircraft systems and subsystems, functional block diagrams for a select set of control-related functions, and system-level functional hazard assessments (SFHA) for those functions. This project has highlighted the notion that DAL D is something of a sweet spot for low-confidence controllers in an RTA-based design. Among the many activities described in DO-178C, the activities related to requirement verifiability, algorithmic accuracy, and test coverage can be the most challenging for the kinds of advanced control techniques that may be desirable in novel UAM designs, such as adaptive control, machine-learning, artificial intelligence, numerical search, and Monte Carlo based algorithms. Moreover, the standard requires that development teams demonstrate that errors leading to unacceptable failure conditions have been removed from the software. The RTA architecture, which cordons off the low-confidence function, makes it much easier to show this for these kinds of algorithms. With regard to the use of STPA and FHA as complementary hazard analysis techniques, our research effort led us to the conclusion that STPA should be used to derive requirements for hardware and software systems and/or components. Also, STPA is a natural complement to other processes in ARP4754A involving design studies and iteration.

Run-time assurance↗
NASA NTRS1994

Investigating and implementing enhancements to the simulation of short-term collision hazards

A software tool, the Relative Collision Matrix (RCM), has been developed to provide a quick-look representation of the shortterm collision hazard to space systems from a fragmentation event in Earth orbit. The software performs multiple fragmentation simulations of space objects to quantify the probability of collision for a satellite or a constellation of satellites nearby. Previously, the results were displayed in a color matrix format which showed the relative hazard of each constellation. The RCM can be used for scientific research and operational assessments even though it was designed for test and evaluation applications. Because of its successful use as an analytical tool, the capabilities of RCM are being extended by enhancing the orbital hazard analysis routines, developing ballistic trajectory hazard analysis routines, and expanding the breakup modeling. Improvements are also being made to the RCM's usability and presentation quality by developing a graphical user interface and by providing graphical animated and nonanimated output.

Huth, Jeffrey S.↗
NASA NTRS1996

Guide for Oxygen Hazards Analyses on Components and Systems

Because most materials, including metals, will burn in an oxygen-enriched environment, hazards are always present when using oxygen. Most materials will ignite at lower temperatures in an oxygen-enriched environment than in air, and once ignited, combustion rates are greater in the oxygen-enriched environment. Many metals burn violently in an oxygen-enriched environment when ignited. Lubricants, tapes, gaskets, fuels, and solvents can increase the possibility of ignition in oxygen systems. However, these hazards do not preclude the use of oxygen. Oxygen may be safely used if all the materials in a system are not flammable in the end-use environment or if ignition sources are identified and controlled. These ignition and combustion hazards necessitate a proper oxygen hazards analysis before introducing a material or component into oxygen service. The objective of this test plan is to describe the White Sands Test Facility oxygen hazards analysis to be performed on components and systems before oxygen is introduced and is recommended before implementing the oxygen component qualification procedure. The plan describes the NASA Johnson Space Center White Sands Test Facility method consistent with the ASTM documents for analyzing the hazards of components and systems exposed to an oxygen-enriched environment. The oxygen hazards analysis is a useful tool for oxygen-system designers, system engineers, and facility managers. Problem areas can be pinpointed before oxygen is introduced into the system, preventing damage to hardware and possible injury or loss of life.

Stoltzfus, Joel M.↗
NASA NTRS1979

Engineering risk reduction in satellite programs

Methods developed in planning and executing system safety engineering programs for Lockheed satellite integration contracts are presented. These procedures establish the applicable safety design criteria, document design compliance and assess the residual risks where non-compliant design is proposed, and provide for hazard analysis of system level test, handling and launch preparations. Operations hazard analysis identifies product protection and product liability hazards prior to the preparation of operational procedures and provides safety requirements for inclusion in them. The method developed for documenting all residual hazards for the attention of program management assures an acceptable minimum level of risk prior to program deployment. The results are significant for persons responsible for managing or engineering the deployment and production of complex high cost equipment under current product liability law and cost/time constraints, have a responsibility to minimize the possibility of an accident, and should have documentation to provide a defense in a product liability suit.

Dean, E. S., Jr.↗
NASA NTRSDate not supplied

NASA’s Moon Trek Portal: New Capabilities Supporting Mission Planning and Engagement

Introduction: NASA’s Moon Trek (https://trek.nasa.gov/moon/) is one of a growing number of interactive, browser-based, online portals for planetary data visualization and analysis produced by NASA’s Solar System Treks Project (SSTP). Moon Trek continues to be enhanced with new data and new capabilities enabling it to facilitate the planning and conducting of upcoming lunar missions by NASA, its commercial partners, and its international partners, as well as advancing its role as a valuable outreach tool. A Comprehensive Online Web Portal: Developed at NASA’s Jet Propulsion Laboratory (JPL) and managed as a project of NASA’s Solar System Exploration Research Virtual Institute (SSERVI) at NASA Ames Research Center, Moon Trek is a browser-based web portal. The portal provides easy-to-use tools for browsing, data layering, data product blending, and feature search among thousands of data products covering topography, mineralogy, elemental abundance, geology, and much more. Visualizations are provided in var-ious map projections, interactive 3D viewing, and in virtual reality. Using an in-house stereo workflow, SSTP is able to produce new NAC-based high-resolution mosaics and DEMs. Diverse Applications for Lunar Exploration: Baseline analytic tools available to all users include dis-tance measurement, elevation profiling, sun angle calculation, and 3D print file generation. More advanced account-level tools allow users to perform more computationally intensive analyses. These include ray-traced lighting analysis for user-specified areas over user-specified time/date ranges and time intervals, electro-static surface potential analysis, subsetting of large data products, slope analysis, and Lunar Laser Ranging geometry calculation. Artificial intelligence (AI) and ma-chine learning (ML) based tools have been implemented for crater detection and hazard analysis, boulder detection and hazard analysis, and rockfall detection. New Tools Facilitating Exploration: Additional, new tools have recently been added and others are in development, offering even greater functionality in con-ducting analyses of potential landing sites and areas of surface operations. The new Line-of-Sight tool facilitates communications planning between locations on the lunar surface, between any given site on the lunar surface and a specified ground station on the Earth, and between a site on the lunar surface and a relay asset in lunar orbit, all taking into account local lunar topography. The new Data Plotter tool provides both tabular and graphical representations of pixel values along a user specified path for a growing number of data products. The new NAC Finder tool will identify and pro-vide access to NAC images that intersect a user-defined path or bounded area. The SSTP development team is looking to leverage the capabilities of its existing AI and ML crater, boulder, and rockfall detection and analysis tools, and extend that technology to a generalized feature detector that can be trained on instances of specific types of landforms and then search the lunar surface for more examples of such features. New traverse planning tools are being developed with use cases in generalized concept studies and specific mission planning in mind. These will facilitate finding optimal traverse paths based on constraints such as slope, lighting, hazard avoidance, and communications. These will be complemented by new traverse visualization capabilities. Users will be able to interactively ride along with a rover, examining 3D views of the terrain while adjusting camera height and viewing angle along with selecting different data layer overlays to drape across the terrain. Engaging the Public: The capabilities being developed for mission planning are being leveraged to further enhance Moon Trek’s proven utility as a valuable public outreach resource. This includes providing multiple lev-els of engagement with different points of entry. At its simplest level, promoting understanding through visualization, media and the public will be able to easily visualize and conduct their own exploration of lunar sites targeted by NASA and its partners. For a more in-depth experience, we are working with our stakeholders to promote understanding through interaction by extend-ing our current landing site and traverse analysis capabilities, making simplified access to these tools available to those who want to explore more deeply key factors in planning a mission through interactive and possibly even gamified experiences. The highest degree of public outreach, focusing on engagement through scientific participation, could be achieved through our work with missions and the NASA Office of the Chief Scientist on Moon Trek’s extension as a tool with specialized capabilities for facilitating citizen science. In such scenarios, participants become members of extended mis-sion science teams, using dedicated and integrated interfaces to analyze mission data to help answer questions key to lunar science and exploration. We are work-ing with NASA’s Office of Communications, museums, planetariums, and the media to help them easily integrate accurate, detailed visualizations of NASA’s lunar destinations and exploration into their content/productions and to engage diverse audiences in diverse venues.

Moon Trek↗
NASA NTRS1977

Preliminary design review package on air flat plate collector for solar heating and cooling system

Guidelines to be used in the development and fabrication of a prototype air flat plate collector subsystem containing 320 square feet (10-4 ft x 8 ft panels) of collector area are presented. Topics discussed include: (1) verification plan; (2) thermal analysis; (3) safety hazard analysis; (4) drawing list; (5) special handling, installation and maintenance tools; (6) structural analysis; and (7) selected drawings.

Source record↗
NASA NTRS2010

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↗
NASA NTRS2023

Machine Learning Framework for Hazard Extraction and Analysis of Trends (HEAT) in Wildfire Response

This research proposes a natural language processing enabled risk analysis framework, named Hazard Extraction andAnalysis of Trends (HEAT), and applies the framework to the ICS-209-PLUS data set of wildfire incident responseforms. The HEAT framework produces safety- and risk- relevant analyses, consisting of: (1) a set of hazards extractedfrom text data, (2) a primary analysis using hazard-relevant metrics, such as rate and severity, to form an FMEA-styletable and risk matrix, (3) a time series analysis of metric trends, and (4) a secondary analysis examining potentialpredictors for hazards. Results from HEAT provide quantitative risk-relevant information for high-level hazards doc-umented in existing-state operations. Because of the generalizability of the steps and limited data requirements, HEATcan be applied to any dataset containing narrative text, thus providing a framework for data-driven machine learning-enabled quantitative risk analysis across a variety of domains. To demonstrate HEAT in a case study, we apply theframework to the ICS-209-PLUS dataset of wildland fire incident response forms. Hazards identified in wildfire re-sponse arise from environmental conditions, the mission, and the wildland urban interface. The resulting risk matrixidentifies evacuations as high-risk hazards, while all other identified hazards are medium or serious risk.

natural language processing↗
NASA NTRS1994

Implementing Software Safety in the NASA Environment

Until recently, NASA did not consider allowing computers total control of flight systems. Human operators, via hardware, have constituted the ultimate safety control. In an attempt to reduce costs, NASA has come to rely more and more heavily on computers and software to control space missions. (For example. software is now planned to control most of the operational functions of the International Space Station.) Thus the need for systematic software safety programs has become crucial for mission success. Concurrent engineering principles dictate that safety should be designed into software up front, not tested into the software after the fact. 'Cost of Quality' studies have statistics and metrics to prove the value of building quality and safety into the development cycle. Unfortunately, most software engineers are not familiar with designing for safety, and most safety engineers are not software experts. Software written to specifications which have not been safety analyzed is a major source of computer related accidents. Safer software is achieved step by step throughout the system and software life cycle. It is a process that includes requirements definition, hazard analyses, formal software inspections, safety analyses, testing, and maintenance. The greatest emphasis is placed on clearly and completely defining system and software requirements, including safety and reliability requirements. Unfortunately, development and review of requirements are the weakest link in the process. While some of the more academic methods, e.g. mathematical models, may help bring about safer software, this paper proposes the use of currently approved software methodologies, and sound software and assurance practices to show how, to a large degree, safety can be designed into software from the start. NASA's approach today is to first conduct a preliminary system hazard analysis (PHA) during the concept and planning phase of a project. This determines the overall hazard potential of the system to be built. Shortly thereafter, as the system requirements are being defined, the second iteration of hazard analyses takes place, the systems hazard analysis (SHA). During the systems requirements phase, decisions are made as to what functions of the system will be the responsibility of software. This is the most critical time to affect the safety of the software. From this point, software safety analyses as well as software engineering practices are the main focus for assuring safe software. While many of the steps proposed in this paper seem like just sound engineering practices, they are the best technical and most cost effective means to assure safe software within a safe system.

Wetherholt, Martha S.↗
NASA NTRS2012

Spaceflight Ground Support Equipment Reliability & System Safety Data

Presented were Reliability Analysis, consisting primarily of Failure Modes and Effects Analysis (FMEA), and System Safety Analysis, consisting of Preliminary Hazards Analysis (PHA), performed to ensure that the CoNNeCT (Communications, Navigation, and Networking re- Configurable Testbed) Flight System was safely and reliably operated during its Assembly, Integration and Test (AI&T) phase. A tailored approach to the NASA Ground Support Equipment (GSE) standard, NASA-STD-5005C, involving the application of the appropriate Requirements, S&MA discipline expertise, and a Configuration Management system (to retain a record of the analysis and documentation) were presented. Presented were System Block Diagrams of selected GSE and the corresponding FMEA, as well as the PHAs. Also discussed are the specific examples of the FMEAs and PHAs being used during the AI&T phase to drive modifications to the GSE (via "redlining" of test procedures, and the placement of warning stickers to protect the flight hardware) before being interfaced to the Flight System. These modifications were necessary because failure modes and hazards were identified during the analysis that had not been properly mitigated. Strict Configuration Management was applied to changes (whether due to upgrades or expired calibrations) in the GSE by revisiting the FMEAs and PHAs to reflect the latest System Block Diagrams and Bill Of Material. The CoNNeCT flight system has been successfully assembled, integrated, tested, and shipped to the launch site without incident. This demonstrates that the steps taken to safeguard the flight system when it was interfaced to the various GSE were successful.

Fernandez, Rene↗
NASA NTRS2010

Hazard Detection Analysis for a Forward-Looking Interferometer

The Forward-Looking Interferometer (FLI) is a new instrument concept for obtaining the measurements required to alert flight crews to potential weather hazards to safe flight. To meet the needs of the commercial fleet, such a sensor should address multiple hazards to warrant the costs of development, certification, installation, training, and maintenance. The FLI concept is based on high-resolution Infrared Fourier Transform Spectrometry (FTS) technologies that have been developed for satellite remote sensing. These technologies have also been applied to the detection of aerosols and gases for other purposes. The FLI concept is being evaluated for its potential to address multiple hazards including clear air turbulence (CAT), volcanic ash, wake vortices, low slant range visibility, dry wind shear, and icing during all phases of flight (takeoff, cruise, and landing). The research accomplished in this second phase of the FLI project was in three major areas: further sensitivity studies to better understand the potential capabilities and requirements for an airborne FLI instrument, field measurements that were conducted in an effort to provide empirical demonstrations of radiometric hazard detection, and theoretical work to support the development of algorithms to determine the severity of detected hazards

West, Leanne↗
NASA NTRS2011

A Case Study of Measuring Process Risk for Early Insights into Software Safety

In this case study, we examine software safety risk in three flight hardware systems in NASA's Constellation spaceflight program. We applied our Technical and Process Risk Measurement (TPRM) methodology to the Constellation hazard analysis process to quantify the technical and process risks involving software safety in the early design phase of these projects. We analyzed 154 hazard reports and collected metrics to measure the prevalence of software in hazards and the specificity of descriptions of software causes of hazardous conditions. We found that 49-70% of 154 hazardous conditions 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. The application of the TPRM methodology identified process risks in the application of the hazard analysis process itself that may lead to software safety risk.

Layman, Lucas↗
NASA NTRS1992

Making the Hubble Space Telescope servicing mission safe

The implementation of the HST system safety program is detailed. Numerous safety analyses are conducted through various phases of design, test, and fabrication, and results are presented to NASA management for discussion during dedicated safety reviews. Attention is given to the system safety assessment and risk analysis methodologies used, i.e., hazard analysis, fault tree analysis, and failure modes and effects analysis, and to how they are coupled with engineering and test analysis for a 'synergistic picture' of the system. Some preliminary safety analysis results, showing the relationship between hazard identification, control or abatement, and finally control verification, are presented as examples of this safety process.

Bahr, N. J.↗
NASA NTRS1992

Making the Hubble Space Telescope servicing mission safe

This paper will detail how the Hubble Space Telescope (HST) system safety program is conducted. Numerous safety analyses are conducted through the various phases of design, test, and fabrication, and results are presented to NASA management for discussion during dedicated safety reviews. This paper will then address the system safety assessment and risk analysis methodologies used (i.e. hazard analysis, fault tree analysis, and failure modes and effects analysis), and how they are coupled with enginering and test analyses for a 'synergistic picture' of the system. Some preliminary safety analysis results, showing the relationship between hazard identification, control or abatement, and finally control verification, will be presented as examples of this safety process.

Bahr, N. J.↗
NASA NTRS2005

Potential of Organic Matrix Composites for Liquid Oxygen Tank

Composite materials are being considered for the tankage of cryogenic propellants in access to space because of potentially lower structural weights. A major hurdle for composites is an inherent concern about the safety of using flammable structural materials in contact with liquid and gaseous oxygen. A hazards analysis approach addresses a series of specific concerns that must be addressed based upon test data. Under the 2nd Generation Reusable Launch Vehicle contracts, testing was begun for a variety of organic matrix composite materials both to aid in the selection of materials and to provide needed test data to support hazards analyses. The work has continued at NASA MSFC and the NASA WSTF to provide information on the potential for using composite materials in oxygen systems. Appropriate methods for oxygen compatibility testing of structural materials and data for a range of composite materials from impact, friction, flammability and electrostatic discharge testing are presented. Remaining concerns and conclusions about composite tank structures, and recommendations for additional testing are discussed. Requirements for system specific hazards analysis are identified.

Davis, Samuel E.↗
NASA NTRSDate not supplied

System-Theoretic Analysis of Unsafe Collaborative Control in Teaming Systems

The interactions that occur in human-teaming are inspiring novel aerospace designs aimed at improving how humans and machines, or multiple machines, work together. Unfortunately, current Systems Engineering processes are ill-equipped to handle these complex relationships and are unable to design and assure the safety for these systems. To close part of this gap, this paper introduces a novel system-theoretic analytical process to identify unsafe collaborative control actions. It is part of a broader set of techniques that extend the state-of-the-art in hazard analysis, System Theoretic Process Analysis (STPA), to systematically address collaboration. The method rigorously expresses the different ways multiple commands may be unsafe together. Using Systems Theory, it employs abstraction to manage the combinatorial complexity in enumerating control contributions from multiple collaborating components. An algorithm integrates these concepts into an end-to-end process and is supported by automation to enumerate, refine, prune, and prioritize unsafe combinations of control actions. The output of the method feeds the specification of system requirements to implement safety-guided design starting early in concept development. The process is demonstrated on a manned-unmanned aircraft teaming case study and finds new causal factors that were not previously found in a past hazard analysis of the same system.

System Safety↗
NASA NTRS1998

Space Shuttle Main Engine Quantitative Risk Assessment: Illustrating Modeling of a Complex System with a New QRA Software Package

During 1997, a team from Hernandez Engineering, MSFC, Rocketdyne, Thiokol, Pratt & Whitney, and USBI completed the first phase of a two year Quantitative Risk Assessment (QRA) of the Space Shuttle. The models for the Shuttle systems were entered and analyzed by a new QRA software package. This system, termed the Quantitative Risk Assessment System(QRAS), was designed by NASA and programmed by the University of Maryland. The software is a groundbreaking PC-based risk assessment package that allows the user to model complex systems in a hierarchical fashion. Features of the software include the ability to easily select quantifications of failure modes, draw Event Sequence Diagrams(ESDs) interactively, perform uncertainty and sensitivity analysis, and document the modeling. This paper illustrates both the approach used in modeling and the particular features of the software package. The software is general and can be used in a QRA of any complex engineered system. The author is the project lead for the modeling of the Space Shuttle Main Engines (SSMEs), and this paper focuses on the modeling completed for the SSMEs during 1997. In particular, the groundrules for the study, the databases used, the way in which ESDs were used to model catastrophic failure of the SSMES, the methods used to quantify the failure rates, and how QRAS was used in the modeling effort are discussed. Groundrules were necessary to limit the scope of such a complex study, especially with regard to a liquid rocket engine such as the SSME, which can be shut down after ignition either on the pad or in flight. The SSME was divided into its constituent components and subsystems. These were ranked on the basis of the possibility of being upgraded and risk of catastrophic failure. Once this was done the Shuttle program Hazard Analysis and Failure Modes and Effects Analysis (FMEA) were used to create a list of potential failure modes to be modeled. The groundrules and other criteria were used to screen out the many failure modes that did not contribute significantly to the catastrophic risk. The Hazard Analysis and FMEA for the SSME were also used to build ESDs that show the chain of events leading from the failure mode occurence to one of the following end states: catastrophic failure, engine shutdown, or siccessful operation( successful with respect to the failure mode under consideration).

Smart, Christian↗