Results for “verification and validation” — Page 21

The U.S. Department of Energy’s (DOE) Office of Nuclear Energy (DOE-NE) is planning for an integrated waste management approach to transport, store, and dispose of spent nuclear fuel (SNF) and other high-level radioactive waste (HLW) as part of the Integrated Waste Management (IWM) program [1]. In support of this effort, the Stakeholder Tool for Assessing Radioactive Transportation (START) is being developed within the IWM program [2, 3]. This is a web-based decision support tool that can be used to analyze geospatial data related to the transportation of SNF and HLW. START is designed as a web-based application using an ArcGIS server through which the user can select the origin and destination of the route [4]. This is followed by selection of the mode of transportation of choice based on user preference. Some of the modes available to the user include rail, heavy haul truck, and barge. The option of utilizing more than one mode of transportation (intermodal transportation) is also implemented in START. A few examples of intermodal transportation include barge to rail, and heavy haul truck to rail. It must be noted that some routes might not have access to all modes of transportation, depending on the infrastructure availability at the origin and destination sites. Users can also select any stops or barriers they would like to introduce in the routes. This is followed by selection of the routing criteria of interest. Three primary routing options available to the user include minimum population, minimum distance, and minimum time. Apart from that, a few other options include accounting for a weighted average of the three aforementioned routing options. The next step involves the selection of the buffer distance of interest which includes the two choices available of 800 m and 2500 m, respectively. Finally, an option to select any prohibited rail carriers that the user does not wish to use is available. After making these selections, a route is ready to be created.

Gadey, Harish Reddy↗

DOE OSTI2024

Design and Development IER:516 - Zirconium Test Assembly (ZTA) - Critical Experiments for Zr Nuclear Data Verification and Validation

Abstract not provided.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

NASA NTRS1993

An assessment of space shuttle flight software development processes

In early 1991, the National Aeronautics and Space Administration's (NASA's) Office of Space Flight commissioned the Aeronautics and Space Engineering Board (ASEB) of the National Research Council (NRC) to investigate the adequacy of the current process by which NASA develops and verifies changes and updates to the Space Shuttle flight software. The Committee for Review of Oversight Mechanisms for Space Shuttle Flight Software Processes was convened in Jan. 1992 to accomplish the following tasks: (1) review the entire flight software development process from the initial requirements definition phase to final implementation, including object code build and final machine loading; (2) review and critique NASA's independent verification and validation process and mechanisms, including NASA's established software development and testing standards; (3) determine the acceptability and adequacy of the complete flight software development process, including the embedded validation and verification processes through comparison with (1) generally accepted industry practices, and (2) generally accepted Department of Defense and/or other government practices (comparing NASA's program with organizations and projects having similar volumes of software development, software maturity, complexity, criticality, lines of code, and national standards); (4) consider whether independent verification and validation should continue. An overview of the study, independent verification and validation of critical software, and the Space Shuttle flight software development process are addressed. Findings and recommendations are presented.

Source record↗

NASA NTRS2006

Validation (not just verification) of Deep Space Missions

ion & Validation (V&V) is a widely recognized and critical systems engineering function. However, the often used definition 'Verification proves the design is right; validation proves it is the right design' is rather vague. And while Verification is a reasonably well standardized systems engineering process, Validation is a far more abstract concept and the rigor and scope applied to it varies widely between organizations and individuals. This is reflected in the findings in recent Mishap Reports for several NASA missions, in which shortfalls in Validation (not just Verification) were cited as root- or contributing-factors in catastrophic mission loss. Furthermore, although there is strong agreement in the community that Test is the preferred method for V&V, many people equate 'V&V' with 'Test', such that Analysis and Modeling aren't given comparable attention. Another strong motivator is a realization that the rapid growth in complexity of deep-space missions (particularly Planetary Landers and Space Observatories given their inherent unknowns) is placing greater demands on systems engineers to 'get it right' with Validation.

verification↗

NASA NTRS2023

Robotic and Crewed Mars Missions Increasing the Demand for Planetary Protection Technology Needs

Planetary protection (PP) policy seeks to avoid harmful contamination by limiting biological and relevant organic contamination from spacecraft as well as preventing adverse changes to Earth’s biosphere when extraterrestial samples are brought back to Earth. The PP policy at NASA was updated in 2021 (NPR 8715.24) and 2022 (NASA-STD-8719.27) to enable missions by expanding the decades old prescriptive requirements to allow for an option of adopting performance-based requirements that are objectivesdriven, risk-informed and case-assured. In parallel, the final PP knowledge gap workshop was completed representing the international consensus on the key areas to be considered in developing crew PP policy. These knowledge gaps focused on key technology development areas in 1) microbial and human health monitoring, 2) technical and operations needed for contamination control and 3) natural transport of contamination on Mars. As robotic missions start to implement performance-based approaches and research and technology efforts commence to inform crew policy the demand for data quality driven verification and validation in relevant space environments. Examples of the types of testing that is envisioned includes test as you fly validation and verification of decontamination systems in a relevant on-orbit and Mars environment, developing lethality curves of terrestrial organisms to further our understanding of the biocidal impacts of Mars and the space environment, and particle transport model validation and verification. Thus, the PP discipline has identified the need for groundbased space environments to perform preliminary testing as validation and verification of flight systems and to advance the technology readiness level prior to further testing on-orbit or lunar environments to prepare for Mars.

J. Nick Benardini↗

NASA NTRSDate not supplied

Robotic and Crewed Mars Missions Increasing the Demand for Planetary Protection Technology Needs

Planetary protection (PP) policy seeks to avoid harmful contamination by limiting biological and relevant organic contamination from spacecraft as well as preventing adverse changes to Earth’s biosphere when extraterrestrial samples are brought back to Earth. The PP policy at NASA was updated in 2021 (NPR 8715.24) and 2022 (NASA-STD-8719.27) to enable missions by expanding the decades old prescriptive requirements to allow for an option of adopting performance-based requirements that are objectives-driven, risk-informed and case-assured. In parallel, the final PP knowledge gap workshop was completed representing the international consensus on the key areas to be considered in developing crew PP policy. These knowledge gaps focused on key technology development areas in 1) microbial and human health monitoring, 2) technical and operations needed for contamination control and 3) natural transport of contamination on Mars. As robotic missions start to implement performance-based approaches and research and technology efforts commence to inform crew policy the demand for data quality driven verification and validation in relevant space environments. Examples of the types of testing that is envisioned includes test as you fly validation and verification of decontamination systems in a relevant on-orbit and Mars environment, developing lethality curves of terrestrial organisms to further our understanding of the biocidal impacts of Mars and the space environment, and particle transport model validation and verification. Thus, the PP discipline has identified the need for ground-based space environments to perform preliminary testing as validation and verification of flight systems and to advance the technology readiness level prior to further testing on-orbit or lunar environments to prepare for Mars.

J Nick Benardini↗

NASA NTRSDate not supplied

Fusion of Test and Analysis: Artemis I Booster to Mobile Launcher Interface Validation

NASA is in the midst of bold and exciting next steps in human exploration and spaceflight. The designs of the new Space Launch System (SLS), the Orion spacecraft and the Exploration Ground Systems (EGS) for vehicle processing and launch are essentially complete and there has been significant progress in manufacturing and assembly of specific hardware for the Artemis I and Artemis II missions. Equally as important, the program level and integrated system level testing and analyses are also well underway to support integrated verification, validation, and Certificate of Flight Readiness (CoFR) for Artemis I. Testing and analysis are key to addressing technical challenges faced by the Artemis missions. Building block approaches are required that provide the right balance between component, element, and/or system level testing that satisfies verification and validation objectives where uncertainties are quantified and minimized. Artemis I is a system of systems that requires a fusion of test and analysis that adeptly characterizes critical interfaces between major program elements. An example of this fusion involves characterizing the interface between the SLS booster and the Mobile Launcher (ML) Vertical Support Post (VSP) interfaces. Proper characterization of this interface represents a number of challenges beginning with the fact that it is a mating of ground support structure in the form of a civil structure to flight hardware. Both sides of the interface are built to different construction standards, but are governed by interface requirements to ensure compatibility when mated. From past program experience, the flexibility at the booster to ML interface is critical in developing accurate prelaunch stacking and cryogenic preloads, squat loads, and pad separation release of preloads and squat loads. This same premise holds for Artemis I. To characterize the asymmetric characteristics at this interface, careful consideration of static forces due to gravity loading with the commensurate effects due to leveling during booster stacking (i.e., spacing and shimming) and nonlinear geometric forces are necessary for inclusion in pre-test assessments. This paper will look at these issues for the upcoming Booster Pull Test in which two boosters will be installed on the ML and one of these boosters will undergo static lateral loading followed afterwards with dynamic excitation into resonance and free-decay. This paper evaluates the booster to ML interface characteristics by characterizing the interface flexibility between the booster aft skirt and the ML VSP interfaces. Furthermore, this paper methodically evaluates the effect of the following on the test outcome: gravitational effects on the booster and ML, the effects of VSP leveling, spacing, and shimming under gravitational loading during booster stacking, the effect of geometric nonlinear follower force due to cg offset as booster is laterally displaced, and the system coupling between the booster under test, ML, and the second booster. Simulated results for a static load pull and dynamic excitation provide insight into the differences in measurement responses when boundary conditions and geometric conditions are included and not included.

Joel W Sills Jr.↗

NASA NTRSDate not supplied

Multidisciplinary Dynamic Testing Challenges in Validating the NASA Artemis Architecture

NASA is in the midst of bold and exciting next steps in human exploration and spaceflight. The designs of the new Space Launch System (SLS), the Orion spacecraft and the Exploration Ground Systems (EGS) for vehicle processing and launch are essentially complete and there has been significant progress in manufacturing and assembly of specific hardware for the Artemis I and Artemis II missions. Equally as important, the program level and integrated system level testing and analyses are also well underway to support integrated verification, validation, and certificate of flight readiness (CoFR) for the first Artemis mission. Testing and analysis are key to addressing technical challenges that the Artemis missions offer. Building block approaches are required that provide the right balance between component, system, and/or element level testing that satisfies verification and validation objectives and where, uncertainties are quantified and minimized. Artemis I is a system of systems that requires a fusion of test and analysis that adeptly characterizes critical interfaces between major program elements. NASA is implementing new in-situ testing that fuse traditional aerospace structures with civil structures, such as the Integrated Modal Test for the Artemis I vehicle where the Mobile Launcher and Crawler Transporter serve as a support structure whose dynamics couple with that of the Artemis I vehicle. This new paradigm requires a closer inspection of structural behavior of the Crawler Transporter and the Mobile Launcher as they now serve multiple purposes. This requires a paradigm shift to look beyond experimental modal techniques and incorporates operational modal analysis techniques to validate dynamic models from data collected during rollout to the launch pad. A further complicating factor is the Crawler Transporter generated ground forces have numerous harmonics making extracting dynamic responses of the Artemis I, Mobile Launcher, and Crawler Transporter coupled system challenging. This discussion explores all these challenges with and attempts to understand how we best build confidence in systems and system-of-systems performance capabilities and margins and understand uncertainties.

Joel W Sills↗

NASA NTRS2006

Autonomy Software: V&V Challenges and Characteristics

The successful operation of unmanned air vehicles requires software with a high degree of autonomy. Only if high level functions can be carried out without human control and intervention, complex missions in a changing and potentially unknown environment can be carried out successfully. Autonomy software is highly mission and safety critical: failures, caused by flaws in the software cannot only jeopardize the mission, but could also endanger human life (e.g., a crash of an UAV in a densely populated area). Due to its large size, high complexity, and use of specialized algorithms (planner, constraint-solver, etc.), autonomy software poses specific challenges for its verification, validation, and certification. -- - we have carried out a survey among researchers aid scientists at NASA to study these issues. In this paper, we will present major results of this study, discussing the broad spectrum. of notions and characteristics of autonomy software and its challenges for design and development. A main focus of this survey was to evaluate verification and validation (V&V) issues and challenges, compared to the development of "traditional" safety-critical software. We will discuss important issues in V&V of autonomous software and advanced V&V tools which can help to mitigate software risks. Results of this survey will help to identify and understand safety concerns in autonomy software and will lead to improved strategies for mitigation of these risks.

Schumann, Johann↗