Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Execution”

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 1,279 records · Page 71
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

cFS Test Framework (CTF)

NASA's Core Flight System (cFS) provides a generic flight software framework architecture for developing flight software. As the cFS framework has gained popularity over the years within the flight software community, supporting software tools have been developed to assist in the design, development, testing and verification of flight software. The cFS Test Framework (CTF) is a recently developed cFS tool with capabilities to develop and run automated test and verification scripts against flight software targets. The CTF tool parses and executes JSON-based test scripts containing test instructions, while logging and reporting the results. CTF utilizes a plugin-based architecture to allow developers to extend CTF with new test instructions, external interfaces, and custom functionality. To interface with flight software, CTF parses a set of CCSDS message definition files to create the necessary command and telemetry structures for use during the test run. Additionally, CTF also supports interfacing with multiple cFS instances, allowing a test script to verify requirements that involve multiple flight software targets. Lastly, CTF provides support for executing test scripts against FSW running on remote or embedded hardware. This allows CTF to execute the same test scripts across different target configurations throughout the development process. In this presentation, we will introduce the cFS Test Framework (CTF) architecture, discuss the history of cFS testing frameworks, and present the features and capabilities currently provided by CTF. Lastly, we will show a demo of the CTF tool being used to execute test scripts against flight software.

Aly I Shehata↗
NASA NTRS2013

Towards a decision support system for space flight operations

The Mission Operations Directorate (MOD) at the Johnson Space Center (JSC) has put in place a Model Based Systems Engineering (MBSE) technological framework for the development and execution of the Flight Production Process (FPP). This framework has provided much added value and return on investment to date. This paper describes a vision for a model based Decision Support System (DSS) for the development and execution of the FPP and its design and development process. The envisioned system extends the existing MBSE methodology and technological framework which is currently in use. The MBSE technological framework currently in place enables the systematic collection and integration of data required for building an FPP model for a diverse set of missions. This framework includes the technology, people and processes required for rapid development of architectural artifacts. It is used to build a feasible FPP model for the first flight of spacecraft and for recurrent flights throughout the life of the program. This model greatly enhances our ability to effectively engage with a new customer. It provides a preliminary work breakdown structure, data flow information and a master schedule based on its existing knowledge base. These artifacts are then refined and iterated upon with the customer for the development of a robust end-to-end, high-level integrated master schedule and its associated dependencies. The vision is to enhance this framework to enable its application for uncertainty management, decision support and optimization of the design and execution of the FPP by the program. Furthermore, this enhanced framework will enable the agile response and redesign of the FPP based on observed system behavior. The differences between the anticipated system behavior and the observed behavior may be due to the processing of tasks internally, or due to external factors such as changes in program requirements or conditions associated with other organizations that are outside of MOD. The paper provides a roadmap for the four increments of this vision. These increments include (1) the existing capabilities (2) hardware and software system components and interfaces with the NASA ground system, (3) uncertainty management and (4) re-planning and automated execution. Each of these increments provides value independently; but some may also enable building of a subsequent increment.

Ruszkowski, James↗
NASA NTRS2018

Runtime Verification: From Propositional to First-Order Temporal Logic

Runtime Verification is a branch of formal methods concerned with analysis of execution traces for the purpose of determining the state or general quality of the executing system. The field covers numerous approaches, one of which is specification-based runtime verification, where execution traces are checked against formal specifications. The paper presents syntax, semantics, and monitoring algorithms for respectively propositional and first-order temporal logics. In propositional logics the observed events in the execution trace are represented using atomic propositions, while first-order logic allows universal and existential quantification over data occurring as arguments in events. Monitoring of the first-order case is drastically more challenging than the propositional case, and we present a solution for this problem based on BDDs. We furthermore discuss monitorability of temporal properties by dividing them into different classes representing different degrees of monitorability.

Peled, Doron↗
NASA NTRS2017

CARACaS multi-agent maritime autonomy for unmanned surface vehicles in the Swarm II harbor patrol demonstration

This paper describes new autonomy technology that enabled a team of unmanned surface vehicles (USVs) to execute cooperative behaviors in the USV Swarm II harbor patrol demonstration and provides a description of autonomy performance in the event. The new developments extend the NASA Jet Propulsion Laboratory’s CARACaS (Control Architecture for Robotic Agent Command and Sensing) autonomy architecture, which pro- vides foundational software infrastructure, core executive functions, and several default robotic technology mod- ules. In Swarm II, CARACaS demonstrated higher levels of autonomy and more complex cooperation than previous on-water exercises, using full-sized vehicles and real-world sensing and communication. The core au- tonomous behaviors to support the harbor patrol scenario included Patrol, Track, Inspect, and Trail, providing the capability of finding all vessels entering the patrol area, keeping track of them, inspecting them to infer intent, and trailing suspect vessels. Significantly, CARACaS assumed responsibility for not only executing tasks safely and efficiently but also recognizing what tasks needed to be accomplished, given the current state of the world. Since the heterogeneous USV teams shared world model that evolved, such as due to (dis)appearance of vessels in the area or a change in health or availability of a USV, CARACaS replanned to generate and reallocate the new task list. Thus, human intervention was never required in the loop to task USVs during mission execution, though a supervisory role was supported in the autonomy system for mission monitoring and exception handling. Finally, CARACaS also ensured the USVs avoided hazards and obeyed the applicable rules of the road, using its local motion planning modules.

Sandoval, Michael↗
NASA NTRSDate not supplied

CFS Test Framework

NASA's Core Flight System (cFS) provides a generic flight software framework architecture for developing flight software. As the cFS framework has gained popularity over the years within the flight software community, supporting software tools have been developed to assist in the design, development, testing and verification of flight software. The cFS Test Framework (CTF) is a recently developed cFS tool with capabilities to develop and run automated test and verification scripts against flight software targets. The CTF tool parses and executes JSON-based test scripts containing test instructions, while logging and reporting the results. CTF utilizes a plugin-based architecture to allow developers to extend CTF with new test instructions, external interfaces, and custom functionality. To interface with flight software, CTF parses a set of CCSDS message definition files to create the necessary command and telemetry structures for use during the test run. Additionally, CTF also supports interfacing with multiple cFS instances, allowing a test script to verify requirements that involve multiple flight software targets. Lastly, CTF provides support for executing test scripts against FSW running on remote or embedded hardware. This allows CTF to execute the same test scripts across different target configurations throughout the development process. In this presentation, we will introduce the cFS Test Framework (CTF) architecture, discuss the history of cFS testing frameworks, and present the features and capabilities currently provided by CTF. Lastly, we will show a demo of the CTF tool being used to execute test scripts against flight software.

cfs↗
NASA NTRSDate not supplied

Firmware Architecture of the ARMADAS Bolting Robot

The Automated Reconfigurable Mission Adaptive Digital Assembly Systems (ARMADAS) project, under development at NASA Ames Research Center, has demonstrated on-ground autonomous robotic assembly of extensive digital structures, and it is now moving forward towards in-space demonstration. The ARMADAS system comprises of the operation software, the operation user interface (opsUI), and a swarm of robots. The robotic system consists of a multitude of collaborative agents specifically designed to transport, place and bolt the building blocks, called voxels (volumetric pixels). This paper focuses on the bolting robot, referred to as Mobile Metamaterial Internal Co-Integrator (MMIC-I). MMIC-I is a battery-powered crawling robot. It navigates the structure through extension, contraction and gripping. Two distinct controller boards operate the robot's two symmetric modules, referred to as module A and B. Board A is the master board: it coordinates motion planning and motion primitives execution, hosts the WiFi client, performs periodic self-assessment and system idle check and triggers faults if anomalies are detected. Board B periodically sends a heartbeat to board A, through a wired communication channel that uses the Serial protocol. Additionally, board A's WiFi client receives heartbeat packet requests or motion/bolting commands from a dedicated server board, and acknowledges reception sending back a response heartbeat packet containing information about the overall robot status, e. g. electrical current and voltage values, target and actual angles, operating mode, fault status. Whenever a motion command is sent, the motion planning section of the firmware determines the current robot configuration, using Inertial Measurement Unit readings and the motors Pulse Width Modulation values. Afterwards, it calculates the list of primitives needed to reach the target state, and controls their execution in the proper order. MMIC-I can receive and execute motion and bolting commands only when it is in operational mode. MMIC-I has three operating modes: standby, operational and safed. Standby mode is automatically entered upon startup. While in standby mode, all motors are powered off, and the only accepted commands are the ones relative to a change of mode and heartbeat packet request. Fault detection causes the robot to automatically enter safed or standby mode. Whenever the detected fault occurs within a motion and requires immediate intervention, e. g. an over-current situation, the robot enters safed mode. Safed mode powers off all motors except for the locomotion module, thus preventing the robot from collapsing. Conversely, when the detected fault doesn't require immediate intervention (low battery warning, for instance), the robot enters standby mode after completing the ongoing motion. This paper provides a detailed discussion of MMIC-I's firmware architecture. It accurately describes the implementation approach for each module: sensor data reading, motor control and actuation, WiFi server-client communication, intra-boards Serial communication, operating modes and autonomous fault detection, motion planning, coordination and execution, etc. Moreover, in support of the software description, this paper includes a thorough characterization of MMIC-I's hardware and avionics.

In-space assembly↗
NASA NTRS2023

Adaptive Independent Verification and Validation (IV&V) Reduces Risk of Software Impacting Safety in Artemis Missions

The National Aeronautics and Space Administration (NASA) is asking more of its human spaceflight programs than ever before through the collective Artemis Missions. The NASA Independent Verification and Validation (IV&V) Program contributes to NASA’s human spaceflight goals by providing IV&V services for NASA’s critical spacecraft and ground software. The IV&V Program is tasked with providing assurance from both individual and integrated mission software perspectives. The Artemis IV&V organization is actively supporting six distinct development efforts: Orion, the Space Launch System (SLS), Exploration Ground Systems (EGS), Mission Control Center (MCC), the Lunar Gateway, and the Human Landing System (HLS), representing a wide diversity of developer organizations, management structures, and development approaches. With much of this extremely complex flight and ground software being essential to human safety both on the ground and in space, Artemis IV&V is likewise challenged to provide more value-added assurance to future Artemis missions within a constrained budget. To meet this challenge, Artemis IV&V employs a variety of novel and evolving “Adaptive IV&V” approaches for planning and executing IV&V analysis to increase both the efficiency and effectiveness of the IV&V Program’s assurance activities, and to address the difficulties imposed by assuring software for a large, highly integrated, multi-mission enterprise managed and executed by physically and organizationally distinct programs. Instilling agile principles like iterative planning cycles, self-organizing teams, and regular retrospectives, into IV&V planning and execution has led to a more rapid turnaround of a minimum viable assurance product and allowed for increased alignment of assurance activities with development progress. Adopting an assurance case methodology has led to greater consistency and clearer communication of assurance design and provided a foundation for long-term maintenance of assurance plans, products, and results across missions. The IV&V-developed Assurance / Safety Case Analytical Network (A-SCAN) framework and tool has enabled the quantification and tracking of system/software risk and confidence. These confidence measures provide a means to repeatedly express the impact of planned and completed assurance work and the remaining residual risk. Applied as part of a “Follow-the-Risk” organizational ethos, this allows consistent rightsizing of analysis rigor and intensity commensurate with the perceived risk of defects, as well as appropriate targeting of the highest risk areas of the software to find safety issues before they can manifest. Finally, the development of the IV&V Advanced Risk Reduction Integrated Software Test and Operations Tri-program Lightweight Environment (ARRISTOTLE), an integrated software-only simulation of Orion, SLS, and EGS systems, has made it possible to independently test integrated pad and flight scenarios and inject faults to observe how the Artemis multi-program, mission software behaves in degraded modes and in response to hazards. These adaptive IV&V investments have enabled Artemis IV&V to become more efficient and effective in IV&V planning and execution and respond more readily to changes in the risk landscape, increasing the breadth and depth of risk reduction possible within the available resources. Residual risk tracking allows IV&V to communicate more effectively with stakeholders, both internal and external at all levels, and inform key decision-making personnel. This evolving assurance design approach provides IV&V surety that work is performed in the highest risk, most value-added areas of the software, to keep our astronauts and ground crews safe and ensure mission success.

Gerek A Whitman↗
NASA NTRS2022

A Model-Based Approach for Europa Lander Mission Concept Exploration

This study investigates the usage of a system model as a means to capture concept formulation for a potentialmission. Efforts are underway at JPL to explore thearchitectural and system concepts for a lander on Europa.Executing a mission on the surface of Europa poses uniquechallenges that will require the lander to operate with onboardautonomy that is more sophisticated than systems previouslyoperated by JPL. Current tasks to explore surface missionconcepts intend to identify concepts that enable a high degree ofonboard autonomy as well as identify the issues and technicallimitations that restrict autonomy. The Europa lander missionconcept team is developing a system model to support thisexploration.The results of this study highlight how executable systemmodeling and the associated engineering environment may beapplied to pre-project conceptual exploration. The applicationof system modeling has resulted in a central system model thatprecisely describes the concepts formulated by the EuropaLander Mission Concept Team. Documentation in the form ofdiagrams and narrative has been directly generated from thesystem model and accessible by team members in a webapplication. The executability of the system model enablesvarious analyses such as simulation of interactions betweencomponents and evaluating system behavior againstrequirements. Execution of the system model has produced statetimelines, plots of system variables, and simulation traces basedon input scenarios. The executable system model enables therapid and repeatable production of these artifacts.

Reeves, Glenn↗
NASA NTRS2022

Perseverance Rover’s Robotic Arm and Turret Mounted Instruments’ Surface Commissioning

The Robotic Arm (RA) on the Perseverance rover is an integral component of the Sampling and Caching System necessary for completing the science goals of the Mars 2020 mission. While the Perseverance rover was based on the Curiosity rover which landed in 2012, the Robotic Arm was redesigned to carry a much larger turret with a new suite of payloads. Shortly after Perseverance landed in Jezero Crater, a series of checkouts was completed with the RA during the first 100 sols of the mission in order to ensure proper functionality of the RA and the instruments mounted on the turret. This period of time in the mission was called Surface Operations Transition (SOX). The objective of SOX was to systematically execute checkout activities for all the basic functionality so that the RA and instruments, as well as other rover components, could be released for scientific exploration.RA activities during SOX can be divided into a few different categories: Mechanism Checkouts, Rover Visual Inspections, Performance Characterization, and Instrument Functional Checkouts. Many of these checkouts built off of each other such that each subsequent activity would verify incrementally complex functionality. Many of the defined activities were executed several times throughout the development of the rover and served as a check that the RA’s performance is consistent with testing on Earth. Other activities were developed uniquely for SOX to respond to challenges discovered during development. They were designed to be verifiable without the help of ground support equipment or previous executions on the flight hardware to compare against.This paper discusses the formulation and conception of the various RA SOX checkout activities, verification and testing required to certify them for flight, execution of the activities on Mars, issues encountered, and finally results and findings as the mission transitioned to nominal science operations. We will be presenting the results and analysis using downlinked imaging and data from the flight vehicle to show how we verified the performance of the Robotic Arm and the turret mounted instruments in order to transition to science operations with a clean bill of health.

Edgett, Kenneth↗
NASA NTRS2022

Validation of the Mars 2020 Fault Protection Design: Navigating the Infinity of the Off-Nominal

On July 30th 2020, the Mars 2020 mission successfully launched out of Cape Canaveral, Florida, passed through the Earth’s shadow, and began its short cruise to Mars. Less than seven months later, the Perseverance rover touched down safely in Jezero Crater to begin its ambitious mission that includes looking for signs of ancient life and collecting samples for future return to Earth. Getting to the successful landing, or “Tango Delta Nominal,” could not have been achieved without also considering the off-nominal. One of the teams supporting this ambitious mission is the fault protection (FP) team. This team is tasked with assessing the various failures, or faults, that could prevent mission success and with ensuring that the autonomous behaviors built into the software and hardware can detect faults and recover the vehicle to a safe state. As part of its charter, the FP team designed a test campaign to provide confidence in the system’s robustness to off-nominal scenarios across all of Mars 2020’s mission phases. The greatest challenge associated with designing such a validation campaign was reducing the infinite number of anomalous scenarios into a finite test suite. In addition, the tests needed to be executed efficiently in order to utilize the team’s limited test venue access, but still needed to maintain a level of rigor that guaranteed confidence in the test outcomes. Given that each test scenario generated massive amounts of data, the team also developed methods for quickly ascertaining whether the autonomous fault protection behaviors maintained vehicle safety in the presence of an anomaly. This paper summarizes the processes that the Mars 2020 fault protection team employed to execute its off-nominal validation campaign. It captures both the methods of generating a suite of off-nominal tests, as well as reducing it to a subset that can be realistically executed within schedule and resource constraints. It also describes the various processes and philosophies that the team utilized to execute the tests efficiently, including creating a standardized procedure template, keeping the test cases modular so that they could be easily interchanged, and capturing common fault injections in a change-controlled database. Finally, it will describe the tools and processes for assessing the test data, focusing in particular on a tool that evaluated vehicle state using “secondary” sources of data to validate that the software had truly configured the spacecraft to the expected safe state.

Morantz, Chaz↗
NASA NTRS2023

Adaptive Independent Verification and Validation (IV&V) Reduces Risk of Software Impacting Safety in Artemis Missions

The National Aeronautics and Space Administration (NASA) is asking more of its human spaceflight programs than ever before through the collective Artemis Missions. The NASA Independent Verification and Validation (IV&V) Program contributes to NASA’s human spaceflight goals by providing IV&V services for NASA’s critical spacecraft and ground software. The IV&V Program is tasked with providing assurance from both individual and integrated mission software perspectives. The Artemis IV&V organization is actively supporting six distinct development efforts: Orion, the Space Launch System (SLS), Exploration Ground Systems (EGS), Mission Control Center (MCC), the Lunar Gateway, and the Human Landing System (HLS), representing a wide diversity of developer organizations, management structures, and development approaches. With much of this extremely complex flight and ground software being essential to human safety both on the ground and in space, Artemis IV&V is likewise challenged to provide more value-added assurance to future Artemis missions within a constrained budget. To meet this challenge, Artemis IV&V employs a variety of novel and evolving “Adaptive IV&V” approaches for planning and executing IV&V analysis to increase both the efficiency and effectiveness of the IV&V Program’s assurance activities, and to address the difficulties imposed by assuring software for a large, highly integrated, multi-mission enterprise managed and executed by physically and organizationally distinct programs. Instilling agile principles like iterative planning cycles, self-organizing teams, and regular retrospectives, into IV&V planning and execution has led to a more rapid turnaround of a minimum viable assurance product and allowed for increased alignment of assurance activities with development progress. Adopting an assurance case methodology has led to greater consistency and clearer communication of assurance design and provided a foundation for long-term maintenance of assurance plans, products, and results across missions. The IV&V-developed Assurance / Safety Case Analytical Network (A-SCAN) framework and tool has enabled the quantification and tracking of system/software risk and confidence. These confidence measures provide a means to repeatedly express the impact of planned and completed assurance work and the remaining residual risk. Applied as part of a “Follow-the-Risk” organizational ethos, this allows consistent rightsizing of analysis rigor and intensity commensurate with the perceived risk of defects, as well as appropriate targeting of the highest risk areas of the software to find safety issues before they can manifest. Finally, the development of the IV&V Advanced Risk Reduction Integrated Software Test and Operations Tri-program Lightweight Environment (ARRISTOTLE), an integrated software-only simulation of Orion, SLS, and EGS systems, has made it possible to independently test integrated pad and flight scenarios and inject faults to observe how the Artemis multi-program, mission software behaves in degraded modes and in response to hazards. These adaptive IV&V investments have enabled Artemis IV&V to become more efficient and effective in IV&V planning and execution and respond more readily to changes in the risk landscape, increasing the breadth and depth of risk reduction possible within the available resources. Residual risk tracking allows IV&V to communicate more effectively with stakeholders, both internal and external at all levels, and inform key decision-making personnel. This evolving assurance design approach provides IV&V surety that work is performed in the highest risk, most value-added areas of the software, to keep our astronauts and ground crews safe and ensure mission success.

Gerek Whitman↗
NASA NTRSDate not supplied

Earth Science Data Processing With Nextflow

Earth science data processing tasks present many challenges. These tasks often process large input datasets and require scores of CPU-hours to generate results. All but the simplest tasks will be decomposed into a series of computational or data manipulation steps, also known as a scientific workflow. In order to reduce the burden of orchestrating and running the dependent processing steps, a workflow execution engine is required. This poster describes the lessons learned by the CLARREO Pathfinder (CPF) team while developing multiple scientific workflows and utilizing the open-source Nextflow engine to execute them in a cloud computing environment. The Nextflow engine is designed with the following stated goals: first, the engine does not dictate how individual steps in the task are implemented (i.e. it is language and interface agnostic); second, the engine supports easy configuration and modularity at the workflow level so that others can easily execute our workflows to reproduce results; lastly, the engine eases development by transparently scaling execution from local to remote environments. Nextflow was developed for the bioinformatics domain but is a good fit for other scientific workflows where the overall task is well-described by a dataflow diagram. The CPF team has developed Nextflow pipelines (i.e. scientific workflows) to simulate CLARREO radiance, generate large look-up tables for inter-calibration algorithms, and generate L4 intercalibration data products. These pipelines consume from single-digits to hundreds of thousands of CPU-hours. In the development and evolution of these pipelines we have discovered many design patterns, pitfalls, and solutions to common problems. Our goal is to demonstrate important aspects of how to design, implement, run, and ultimately share Nextflow pipelines in the domain of Earth science.

Aron D Bartle↗
DOE OSTI2020

Methods and apparatus to modify a binary file for scalable dependency loading on distributed computing systems

Methods and apparatus to modify a binary file for scalable loading on distributed computing systems are disclosed. An example method to modify a binary file for scalable loading on a distributed computing system includes identifying, by executing an instruction with a processor, in the binary file a file name for a shared file, determining, by executing an instruction with the processor, whether the shared file can be loaded based on a path name specified in the binary file, and, responsive to a determination that the shared file can be loaded, generating, by executing an instruction with the processor, an identifier that can be used to access a local file scalably copied from a global file system, and modifying, by executing an instruction with the processor, the binary file by replacing, in the binary file, the file name with the generated identifier.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

Science Federation Emulation Testbed: Demonstration of VFSIE Functionalities

The Virtual Federated Science Instrument Environment (VFSIE) is a digital twin of a federated infrastructure of multiple sites with science instruments and computing systems that are geographically dispersed. It emulates the federation using containers and virtual hosts (vhosts) connected over local and wide-area networks for the main purpose of supporting the development and testing of science workflows and software stacks, which will subsequently transition to the physical infrastructure. In this demo, we present VFSIE of a four sites scenario and illustrate the following use cases: (i) execution of federation stack components that expose resources to enable a science user to execute workflows, (ii) execution of remote control commands of beam-line instruments to collect measurements and position the sensor, and (iii) remote execution and access of Jupyter Notebook for tomographic image computations

Al Najjar, Anees↗
DOE OSTI2023

Per-instruction energy debugging using instruction sampling hardware

A processor utilizes instruction based sampling to generate sampling data sampled on a per instruction basis during execution of an instruction. The sampling data indicates what processor hardware was used due to the execution of the instruction. Software receives the sampling data and generates an estimate of energy used by the instruction based on the sampling data. The sampling data may include microarchitectural events and the energy estimate utilizes a base energy amount corresponding to the instruction executed along with energy amounts corresponding to the microarchitectural events in the sampling data. The sampling data may include switching events associated with hardware blocks that switched due to execution of the instruction and the energy estimate for the instruction is based on the switching events and capacitance estimates associated with the hardware blocks.

Wei, Shijia↗
DOE OSTI2020

Waste Management Project Success - Regulatory Assurance Systems - 20118

Waste management (WM) and remediation projects are essential within a restorative environmental culture. Despite years of experience, challenges and obstacles associated with efficient and effective WM project execution remain. Although some obstacles are project specific, a common challenge is navigating the regulatory landscape from planning through execution, particularly with first of a kind (FOAK) and first in a while (FIAW) projects. The absence of a comprehensive regulatory assurance strategy places significant hurdles in the path of project success. To clear a path for the successful execution of increasingly complex WM projects, this paper focuses on development of a comprehensive regulatory assurance strategy and implementation plan that effectively engages stakeholders, agencies, and performers to produce project plans that fully and cost effectively integrate applicable regulatory requirements. The most reliable way to align regulatory processes and decisions needed for mission success is through a regulatory assurance system. This system establishes a healthy interface with regulatory decision makers, to work in a collaborative manner, to create a common vision for regulatory decisions on an agreed upon schedule. A regulatory assurance system consists of several elements. Although the mission may vary from cleanup to site closure to nuclear component production, the elements of a regulatory assurance system remain essentially constant and must include: 1) identifying a common vision or end state, 2) developing a long-term, integrated strategy and schedule, 3) establishing a regulatory partnering team consisting of key decision-makers, 4) regular and frequent communication with decision-makers, 5) ensuring consistent surveillance for early identification of issues and changes that may impact the project, 6) quick resolution of emerging issues to prevent schedule impact, 7) identifying core compliance functions, 8) periodically assessing progress of the project as it relates to regulatory assurance and, 9) providing constructive feedback to improve the process. A regulatory assurance system provides a living, multi-faceted approach to planning, visioning, communicating and tracking to avoid surprises and ensure smooth and timely progress to the project. The overall success measures will be whether the system produces common sense regulatory decisions supporting the vision on time without appeal. Effective regulatory frameworks rarely happen on their own. Balanced, common-sense regulatory decisions stem from teams that are trained to work together to achieve shared goals. In this paper, particular attention is placed on the importance of starting with a shared vision for a regulatory assurance and execution strategy that leverages experience to establish optimal approaches. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
DOE OSTI2020

Data Federation Challenges in Remote Near-Real-Time Fusion Experiment Data Processing

Fusion energy experiments and simulations provide critical information needed to plan future fusion reactors. As next-generation devices like ITER move toward long-pulse experiments, analyses, including AI and ML, should be performed in a wide range of time and computing constraints, from near-real-time constraints, between-shot analysis, and to campaign-wide long-term analysis. However, the data volume, velocity, and variety make it extremely challenging for analyses using only local computational resources. Researchers need the ability to compose and execute workflows spanning edge resources to large-scale high-performance computing facilities.We present Delta, a system to address data analysis challenges, including AI/ML, in fusion science, by leveraging the ADIOS I/O library and middleware, to support executing science workflows over the wide area network for near-real-time streaming. We discuss the data federation challenges in performing remote workflows, focusing on on-going research work in (1) managing, reducing, and streaming data to minimize I/O and data movement overheads, (2) decompressing and reorganizing data for analysis, and (3) executing workflows for automated data analysis. We introduce examples for deep-learning based data analysis for the fusion domain and demonstrate how we use Delta to construct end-to-end workflows for a fusion device in Korea, connecting a remote DOE facility in the USA. The capability demonstrated by this project is the basis for improving the state of the art for near-real-time data federation amongst remote facilities.

Choi, Jong Youl↗
DOE OSTI2025

The Dynamic Networks Experiments: Virtual Experiments to Quantify Gains in Nuclear Explosion Monitoring

We describe an ongoing series of virtual experiments conducted collaboratively by four United States National Laboratories: Sandia National Laboratories, Los Alamos National Laboratory, Lawrence Livermore National Laboratory, and Pacific Northwest National Laboratory. These Dynamic Network Experiments (DNEs) provide an experimental framework to evaluate the potential impact of new research tools on nuclear explosion monitoring. The second DNE (DNE2), completed in 2024, exploited waveform data (seismic, infrasound, and electromagnetic) that was recorded by multi-modal sensors within and near the Nevada National Security Site and synthetic radionuclide signatures over multiple time periods. During the execution of DNE2, we processed and analyzed data through a multi-stage event processing pipeline that ingested raw data, performed quality control, detected signals, built events from these signals, located these events, and characterized the events’ source types and sizes. For each stage and over the entire event processing pipeline, we evaluated performance changes by comparing the performance of new data processing methods, models, and algorithms against a baseline. We also performed an additional execution phase to assess event processing pipeline function, speed, and efficiency against that of an expert analyst, including computational and manual efforts. Finally, we assessed the impact and effort of modern computing infrastructure on the monitoring pipeline. This paper describes key elements of the DNEs, from formulation through execution, as demonstrated in DNE2. The DNEs introduce several novel concepts to quantitatively measure the potential impact of new methods on explosion monitoring, including the collaborative design of multi-modal datasets, performance and logistical metrics, and integrated analyses.

42 ENGINEERING↗