Search NASA⌕ Search

SEARCH · Search NASA

Results for “workarounds,”

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.

69 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Space Shuttle Cargo Integration Coupled Loads Analysis Lessons Learned

When a system experiences a loading environment characterized by rapidly varying forces, such as a rocket launch, a transient analysis is used to analyze the response of the system. The most common transient analysis methodology is the Coupled Loads Analysis (CLA). CLAs are used by the automotive and aerospace industry to analyze cars, trucks, planes, helicopters, spacecraft, etc. The Space Shuttle program used the CLA methodology to assess the compatibility of the payload with the Orbiter and the flight environment. The Space Shuttle Verification Loads Analysis (VLA) was a standardized CLA process that started between ten and thirteen months prior to launch, and included several meetings as well as analysis by both the Space Shuttle Program and the payload developers to verify that the payloads were compatible with the flight loads environment and would not interact negatively with the vehicle. Over the course of the Space Shuttle Program, many improvements were made to the process, which reduced cycle time and improved manifest flexibility. There were several issues which were never fully addressed, but workarounds were developed to keep the process flowing. The lessons learned included automation of some processes and standardization of others, early assessments, improved documentation and better coordination with all stakeholders in the process. Lessons learned also included the limitations in the current process, and what to do to avoid the same issues in the future.

Erica E. Bruno↗
NASA NTRSDate not supplied

Goes-16 On-Station Custom Maneuver Generation with Focussuite

This paper discusses the process of the NOAA GOES Mission Operations Support Team (MOST) in mitigating the effects of inconsistently performing ArcJet Thrusters (AJTs) aboard the GOES-16 spacecraft in geostationary orbit. These AJTs are hot-gas thrusters which augment the gas flow using an electric arc to increase the exit velocity of the gases. Fuel flow problems have led to GOES-16 being unable to safely use its AJTs for maneuvers at times. This primarily affects North/South Station-Keeping (NSSK) maneuvers, which control inclination and use a majority of the station-keeping fuel budget. As a result, GOES-16 has had to occasionally resort to using non-AJT hot-gas thrusters. These thrusters are not placed as close to GOES-16's centerline, have lower thrust, and have lower specific impulse when compared to AJTs. In addition, MOST’s ground systems do not officially support using these non-AJT thrusters for NSSK maneuvers. MOST had to quickly develop workaround solutions using the FocusSuite Autofocus programming environment to compute the maneuvers. This paper outlines the mixture of commercial off-the-shelf (COTS) and MOST-developed products which have allowed GOES-16 to continue station-keeping even with inconsistently-per-forming AJTs, showing that script-based automation systems like Autofocus can simplify complex solutions to a few scripted user inputs.

Henry Heim↗
NASA NTRSDate not supplied

An Approach to Identifying Aspects of Positive Pilot Behavior within the Aviation Safety Reporting System

The National Airspace System (NAS) is constantly evolving as air traffic continues to ramp up to pre-pandemic numbers and projected to grow to unprecedented levels in the coming years. As well as increasing demand to the current system, emerging operations such as Unmanned Autonomous Systems are also expected to add to complexity in the airspace. To address these issues, the industry and government agencies supporting the NAS will need to rely upon additional automation and new technologies to address future operational requirements, while continuing to be a world-leading safe transportation system. As these new technologies are implemented, the system continues to rely on human pilots and controllers in the loop to monitor the system and intervene in situations the automation cannot handle. The goal of proactively addressing safety is of foremost concern to ensure passenger confidence. The industry has implemented various Safety Monitoring Systems to identify safety risks and proactively address them before they result in a serious incident or accident. One such program is the Aviation Safety Reporting System (ASRS). ASRS is a long-established system where pilots and controllers voluntarily and anonymously report safety incidents they experienced and observed during line operations by providing rich text narratives describing the events, the environment, and conditions leading to the safety event of concern. These narratives provide insight and context around events of interest and can be used to identify emerging problems. They can trigger investigations within Flight Operational Quality Assurance or Flight Data Monitoring programs. However, this process typically focuses on the adverse events and the unsafe aspects of the operations surrounding the reported or detected events. This perspective of investigating factors that went wrong around an adverse event is commonly referred to as Safety I. Alternatively, characterizing successful actions that operators perform every day under varying conditions that keep the system within safe operating bounds is a concept referred to as Safety II. The benefit of the Safety II view is that the scope is much larger than that of Safety I since a vast majority of the operations result in successful flights. Many of the successful techniques used to manage operational threats are not documented in standard operating procedures or taught during training. They are typically acquired over time by working with experienced pilots during line operations or in many cases after experiencing a problem for the first time and reacting to it in situ, drawing from years of experience to manage the threat. In an attempt to quantify these positive actions, we are proposing an approach to extracting key behaviors within ASRS reports that can support the Safety II concept. Our analysis assumes that ASRS reports contain some descriptions of corrective actions that operators performed to prevent a situation from leading to an accident. Leveraging recent advances in Natural Language Process modeling, we have developed an approach to extract positive sentiment from reports, embed these positive statements in a vector space where they can be numerically analyzed, and clustering these statements into similar contextual categories. From these contextualized categories we can attempt to summarized and distilled aspects of the positive behavior. The goal is to identify categories of behavior that describe consistent operator techniques that supports the Safety II concept. With this information, airlines may enable learning from these positive actions, or address procedures that need to be changed to avoid having pilots implement a workaround. These insights can provide a lens into what is “going right” in the operations that may otherwise not be known widely within the community. It is envisioned that this approach can be extended to other narrative programs such as Line Operation Safety Audit or Learning Improvement Team reports where similar observed behavior can be analyzed to extract positive actions and inform the overall operations.

NLP↗
NASA NTRS2022

Mars 2020 Entry, Descent, and Landing System Software Implementation

On February 18th, 2021, the Mars 2020 project's Perseverance Rover successfully touched down on the Martian surface after nearly eight years of development. The Mars 2020 Entry, Descent, and Landing (EDL) System largely leveraged heritage from the Mars Science Laboratory (MSL) EDL System while employing targeted technological advancements. The landing process is autonomously directed by a software behavior implemented in the rover's primary flight computer called the EDL Timeline that assumes control of the vehicle six days before atmospheric entry. This paper first walks through the basics of the EDL Timeline mechanics and how the behavior is designed to account for internal system variations and environmental unknowns. It then summarizes the interactions between the EDL timeline and other high-level system behaviors like spacecraft mode transitions and system fault protection, focusing on the complications that arise when passing spacecraft control between executive functions. Although the MSL-inherited EDL System is reliable and capable, targeted updates and a thorough verification and validation program were required for Mars 2020. This paper discusses changes made to close vulnerabilities discovered during both MSL and Mars 2020 development cycles, landing system capability enhancements that were enabling for Mars 2020's mission, and how these updates were integrated with the heritage system. It then describes how both analysis and testing campaigns were utilized to verify and validate all aspects of EDL and system behaviors that run during the six days before landing, as well as the operational workarounds that were needed to address problems found during the development and commissioning process. Finally, this paper imparts lessons learned from Mars 2020 EDL development, implementation, and operations, emphasizing how systems designed to conduct time-critical mission events with low margin of error can be improved in the future.

Stehura, Aaron↗
NASA NTRS2022

Mars 2020 Entry, Descent, and Landing Software Implementation

On February 18th, 2021, the Mars 2020 project's Perseverance Rover successfully touched down on the Martian surface after nearly eight years of development. The Mars 2020 Entry, Descent, and Landing (EDL) System largely leveraged heritage from the Mars Science Laboratory (MSL) EDL System while employing targeted technological advancements. The landing process is autonomously directed by a software behavior implemented in the rover's primary flight computer called the EDL Timeline that assumes control of the vehicle six days before atmospheric entry. In addition to performing the critical function of landing the rover on the Martian surface, the EDL timeline behavior must co-exist in a non-partitioned software and system environment with other high-level functions that accomplish the goals for the rest of the mission. Due to the criticality of EDL, the potential for loss of mission, and a need for complete system autonomy, the standard for how the EDL Timeline interacts with other functions in the system is highly constrained. This paper first walks through the basics of the EDL Timeline mechanics and how the behavior is designed to account for internal system variations and environmental unknowns. It then summarizes the interactions between the EDL timeline and other high-level system behaviors like spacecraft mode transitions and system fault protection, focusing on the complications that arise when passing spacecraft control between executive functions. Although the MSL-inherited EDL System is reliable and capable, targeted updates and a thorough verification and validation program were required for Mars 2020. This paper discusses changes made to close vulnerabilities discovered during both MSL and Mars 2020 development cycles, landing system capability enhancements that were enabling for Mars 2020's mission, and how these updates were integrated with the heritage system. It then describes how both analysis and testing campaigns were utilized to verify and validate all aspects of EDL and system behaviors that run during the six days before landing, as well as the operational workarounds that were needed to address problems found during the development and commissioning process. Finally, this paper imparts lessons learned from Mars 2020 EDL development, implementation, and operations, emphasizing how systems designed to conduct time-critical mission events with low margin of error can be improved in the future.

Stehura, Aaron↗
NASA NTRSDate not supplied

An Approach to Identifying Aspects of Positive Pilot Behavior within the Aviation Safety Reporting System

The National Airspace System (NAS) is constantly evolving as air traffic continues to ramp up to pre-pandemic numbers and projected to grow to unprecedented levels in the coming years. As well as increasing demand to the current system, emerging operations such as Unmanned Autonomous Systems are also expected to add to complexity in the airspace. To address these issues, the industry and government agencies supporting the NAS will need to rely upon additional automation and new technologies to address future operational requirements, while continuing to be a world-leading safe transportation system. As these new technologies are implemented, the system continues to rely on human pilots and controllers in the loop to monitor the system and intervene in situations the automation cannot handle. The goal of proactively addressing safety is of foremost concern to ensure passenger confidence. The industry has implemented various Safety Monitoring Systems to identify safety risks and proactively address them before they result in a serious incident or accident. One such program is the Aviation Safety Reporting System (ASRS). ASRS is a long-established system where pilots and controllers voluntarily and anonymously report safety incidents they experienced and observed during line operations by providing rich text narratives describing the events, the environment, and conditions leading to the safety event of concern. These narratives provide insight and context around events of interest and can be used to identify emerging problems. They can trigger investigations within Flight Operational Quality Assurance or Flight Data Monitoring programs. However, this process typically focuses on the adverse events and the unsafe aspects of the operations surrounding the reported or detected events. This perspective of investigating factors that went wrong around an adverse event is commonly referred to as Safety I. Alternatively, characterizing successful actions that operators perform every day under varying conditions that keep the system within safe operating bounds is a concept referred to as Safety II. The benefit of the Safety II view is that the scope is much larger than that of Safety I since a vast majority of the operations result in successful flights. Many of the successful techniques used to manage operational threats are not documented in standard operating procedures or taught during training. They are typically acquired over time by working with experienced pilots during line operations or in many cases after experiencing a problem for the first time and reacting to it in situ, drawing from years of experience to manage the threat. In an attempt to quantify these positive actions, we are proposing an approach to extracting key behaviors within ASRS reports that can support the Safety II concept. Our analysis assumes that ASRS reports contain some descriptions of corrective actions that operators performed to prevent a situation from leading to an accident. Leveraging recent advances in Natural Language Process modeling, we have developed an approach to extract positive sentiment from reports, embed these positive statements in a vector space where they can be numerically analyzed, and clustering these statements into similar contextual categories. From these contextualized categories we can attempt to summarized and distilled aspects of the positive behavior. The goal is to identify categories of behavior that describe consistent operator techniques that supports the Safety II concept. With this information, airlines may enable learning from these positive actions, or address procedures that need to be changed to avoid having pilots implement a workaround. These insights can provide a lens into what is “going right” in the operations that may otherwise not be known widely within the community. It is envisioned that this approach can be extended to other narrative programs such as Line Operation Safety Audit or Learning Improvement Team reports where similar observed behavior can be analyzed to extract positive actions and inform the overall operations.

NLP↗
NASA NTRSDate not supplied

An Approach to Identifying Aspects of Positive Pilot Behavior within the Aviation Safety Reporting System

The National Airspace System (NAS) is constantly evolving as air traffic continues to ramp up to pre-pandemic numbers and projected to grow to unprecedented levels in the coming years. As well as increasing demand to the current system, emerging operations such as Unmanned Autonomous Systems are also expected to add to complexity in the airspace. To address these issues, the industry and government agencies supporting the NAS will need to rely upon additional automation and new technologies to address future operational requirements, while continuing to be a world-leading safe transportation system. As these new technologies are implemented, the system continues to rely on human pilots and controllers in the loop to monitor the system and intervene in situations the automation cannot handle. The goal of proactively addressing safety is of foremost concern to ensure passenger confidence. The industry has implemented various Safety Monitoring Systems to identify safety risks and proactively address them before they result in a serious incident or accident. One such program is the Aviation Safety Reporting System (ASRS). ASRS is a long-established system where pilots and controllers voluntarily and anonymously report safety incidents they experienced and observed during line operations by providing rich text narratives describing the events, the environment, and conditions leading to the safety event of concern. These narratives provide insight and context around events of interest and can be used to identify emerging problems. They can trigger investigations within Flight Operational Quality Assurance or Flight Data Monitoring programs. However, this process typically focuses on the adverse events and the unsafe aspects of the operations surrounding the reported or detected events. This perspective of investigating factors that went wrong around an adverse event is commonly referred to as Safety I. Alternatively, characterizing successful actions that operators perform every day under varying conditions that keep the system within safe operating bounds is a concept referred to as Safety II. The benefit of the Safety II view is that the scope is much larger than that of Safety I since a vast majority of the operations result in successful flights. Many of the successful techniques used to manage operational threats are not documented in standard operating procedures or taught during training. They are typically acquired over time by working with experienced pilots during line operations or in many cases after experiencing a problem for the first time and reacting to it in situ, drawing from years of experience to manage the threat. In an attempt to quantify these positive actions, we are proposing an approach to extracting key behaviors within ASRS reports that can support the Safety II concept. Our analysis assumes that ASRS reports contain some descriptions of corrective actions that operators performed to prevent a situation from leading to an accident. Leveraging recent advances in Natural Language Process modeling, we have developed an approach to extract positive sentiment from reports, embed these positive statements in a vector space where they can be numerically analyzed, and clustering these statements into similar contextual categories. From these contextualized categories we can attempt to summarized and distilled aspects of the positive behavior. The goal is to identify categories of behavior that describe consistent operator techniques that supports the Safety II concept. With this information, airlines may enable learning from these positive actions, or address procedures that need to be changed to avoid having pilots implement a workaround. These insights can provide a lens into what is “going right” in the operations that may otherwise not be known widely within the community. It is envisioned that this approach can be extended to other narrative programs such as Line Operation Safety Audit or Learning Improvement Team reports where similar observed behavior can be analyzed to extract positive actions and inform the overall operations.

NLP↗
NASA NTRSDate not supplied

Quantum Hardware-Enabled Molecular Dynamics via Transfer Learning

The ability to perform ab initio molecular dynamics simulations using potential energy surfaces provided by quantum computers would open the door to virtually exact dynamics for a variety of chemical and biochemical systems, with impacts on catalysis and biophysics. Nonetheless, performing molecular dynamics on surfaces produced by quantum hardware has been hampered by the noisy energies typically produced by quantum computers and challenges associated with computing gradients and scaling to large systems interest. A recent set of advances in machine learning, known as transfer learning, provides a new path forward for molecular dynamics simulations on quantum hardware. Transfer learning offers a workaround, where one first trains models on larger, less accurate classical datasets and then refines them on smaller, more accurate quantum datasets. We explore this approach by training machine learning models to predict a molecule's potential energy based on its geometric structure using Behler-Parrinello neural networks. When successfully trained, the model enables energy gradient predictions necessary for dynamic simulations. To reduce the quantum resources needed, the model is initially trained with data derived from classical density functional theory and subsequently refined with a smaller dataset obtained from a variational quantum eigensolver optimization of the unitary coupled cluster ansatz. We show that this approach significantly reduces the size of the needed quantum training dataset while capturing the high accuracies needed within quantum chemistry simulations. The success of this two-step training method opens more opportunities to apply machine learning models on quantum data, a significant stride towards efficient quantum-classical hybrid computational models.

quantum computing↗
NASA NTRSDate not supplied

Zemax Modeling of a Self-aligned Focusing Schlieren System with Simulated Compressible Flow

A self-aligned focusing schlieren system is simulated in the ANSYS Zemax OpticStudio software environment. The model uses a custom scatter-defining dynamic link library on the retroreflective background in order to scatter rays in the direction of the incident ray rather than the specular ray. Simulated compressible flow refractive index fields are imported into Zemax by use of the grid gradient object and a workaround to the maximum point limit is introduced. The Ronchi ruling is built as a high resolution bitmap image in MATLAB and set in Zemax as a slide object allowing the bitmap image to either transmit or terminate rays at each line pair. The Zemax simulations are compared to computational numerical schlieren and experimental conventional, path-integrated schlieren results from a hypersonic stagnation point injection flow configuration and an experimental image of a shock wave from a laser-induced breakdown. In the stagnation point injection simulations, the Zemax schlieren images capture complex flow features such as the Mach disk, shear layers, contact surface, and bow shock well, but contains long, curved features (striations) between the model and the bow shock that are not present in the synthetic schlieren image from the CFD or the experimental image. The image from Zemax of the spark-induced shock wave captures the shape and curvature of the shock but appears blurry due to grid discretization in the computational data.

Nicholas A Mejia↗
NASA NTRSDate not supplied

Swift Mission Gyro Patch and Re-Calibration Without A Calibration Campaign

The Swift spacecraft has three Two-Axis-Rate-Assemblies (TARAs) (designated as TARA 1, TARA 2, and TARA 3, and generically referred to as gyros) which until March of 2024 were all used in rate estimation as an operational workaround (dubbed “corrector-gyro”) of a software defect discovered in 2007. TARA 1 performance degraded throughout 2023 and 2024, making it an unreliable rate source. It was determined that shifting TARA 1 to be the corrector-gyro and using mainly TARAs 2 and 3, with the existing flight software (FSW) defect, would not meet performance requirements for science operations. Rather the FSW was patched to remove the defect found in 2007. This patch was delivered by the vendor in 2009, but was not fully tested or installed at that time. A decision was made in 2024 to install the patch despite limited simulation and testing capabilities. The problem facing the team was to come up with a set of alignment parameters that would work with the new patch, using data from the spacecraft operating normally in the old configuration. Calibration activities would have been possible in either the old or new FSW configuration, but were ultimately deemed unnecessary, saving staff time and pre-serving time on the spacecraft for science data collection. This paper describes the old and new FSW configurations related to gyro processing and alignment, and how the raw gyro and star tracker data from normal operation were used with a multidimensional unconstrained nonlinear minimization in MATLAB (Nelder-Mead1) to produce a fully calibrated set of gyro alignment parameters compatible with the patched FSW. Flight data is presented showing that not only did the process work, it improved performance significantly, rivaling the best slew performance of the mission to date.

MATLAB↗
NASA NTRSDate not supplied

Content and Representation of Information Needed to Support Time-Constrained Problem Solving

NASA’s current mission-operations paradigm originated with Project Mercury and endured with minimum evolution through the Apollo Program, Space Shuttle Program, and ISS missions. At its foundation is a near-complete real-time dependence on a ground team to manage the combined state of the mission, vehicle, and crew. Utilizing many engineers and operators with broad and deep expertise; large, distributed datasets including extensive telemetry; and expansive analytical and computing power, this ground team has served as the safety net for crewed spaceflight missions over the past 60 years. This approach must change to address challenges associated with missions beyond low Earth orbit (BLEO), including infrequent resupply, reduced ability to evacuate, and delayed communications that prohibit real-time operational support. We anticipate that a necessary part of this change will be increased independence for the crew, as roles and responsibilities traditionally performed by ground teams move on board the vehicle. While many risks are associated with Earth-independent operations, one particular concern is ensuring that the crew will have adequate onboard support to perform urgent problem solving when communication with the ground is delayed or intermittent. A key resource that enables the ground team to respond to anomalies quickly and effectively is the extraordinary expertise and experience it possesses. It is comprised of 80+ experts on at any given time, with a combined 600+ years of system-specific experience across 22 unique console disciplines. A small crew will face the unprecedented challenge of independently responding to anomalies that have historically been handled by a team 20 times their size. Another important resource upon which the ground heavily relies to support procedure execution and anomaly response is data. The amount of telemetry data that each flight controller monitors is extensive. In addition, as the ground team works to further assess impacts, trouble shoot, identify workarounds, and oversee procedure execution, it accesses and synthesizes engineering and procedure information, as well as system build, test, and configuration documentation. It is not feasible nor useful to put all these data onboard as crews become more Earth independent. Each member of a small Mars mission small crew will have multiple roles beyond monitoring telemetry and data gathering, and multiple roles within anomaly resolution processes, thereby limiting their capacity for copious amounts of information. Moreover, while access is necessary, it alone is insufficient. Information will need to be compiled, refined, and represented appropriately to support the crew’s reduced attention and expertise. This work seeks to understand the content and representation of information needed to support time-constrained problem solving and decision making by the crew without real-time ground support. To build this understanding, we first surveyed the literature, focusing on how expert problem solvers construct and manipulate their mental models. Next, we interviewed expert problem solvers in spaceflight and analogous domains and surveyed industry solutions for data presentation. Finally, we analyzed current spaceflight operations by investigating flight controller anomaly resolution processes during ISS training simulations and real operational events. These methods led to creating a problem-solving framework that details common themes and features of attending to, assessing, analyzing, and acting on problems in complex, time-constrained domains. Using this framework and the results of our analysis, we identified conceptual data representations needed for crew-led problem-solving. Preliminary onboard user interface concepts to meet identified needs will be presented.

anomaly response↗
DOE OSTI2024

Developing a Supply Chain Security Program

Amid growing concerns over foreign manufacturing for components and devices deployed in critical energy infrastructure, this research from the national labs will highlight best practices for developing and maintaining a supply chain security program. Tools for asset inventory, tips for developing and maintaining software- and hardware-bills-of-materials (SBOMs and HBOMs), recommended contractual language for vendor agreements, and identification of responsibilities will be shared. We discuss the one-time requirements to enable a successful supply chain security program and the best ways to operationalize this program for maximum impact, including development of robust practices for vulnerability tracking, patch management, and workarounds, with understanding of the reliability and uptime requirements for utilities. The recommendations shared are based on a cyber-informed engineering approach to identification of high-consequence impacts and the engineering controls related to supply chain management that can best mitigate these impacts. This approach allows for prioritization of resources. Additionally, we highlight relative up-front and ongoing costs associated with recommended controls. Viewers will leave with an understanding what a supply chain security program is, and what steps, prioritized for resource-constrained organizations, can build a robust program.

14 SOLAR ENERGY↗
DOE OSTI2024

MFANS 2024 - Formally Proving Characteristics of Cyber-Physical Systems

Cyber-physical systems (CPS) are engineered systems that rely on the smooth integration of computational algorithms and physical elements. This integration presents new challenges for verifying that systems will behave as expected. The goal of this presentation is to present current challenges and potential solutions for the formal verification of cyber-physical systems. For cyber systems, formal methods refer to systematically rigorous mathematical techniques employed in the specification, development, analysis, and verification of both software and hardware systems. Recent advancements in computer science have yielded sophisticated tools specifically designed to address challenges associated with formal methods in complex systems. These tools leverage various foundational concepts such as logic, formal languages, program semantics, type systems, type theory, and automata theory. A notable achievement in the application of formal methods is the seL4 microkernel, claimed to be the first general-purpose operating-system kernel to be verified. Its proof implies the absence of bugs and guarantees that the kernel meets specifications. For physical systems, dynamic and control theory has a history of using rigorous analytic techniques to prove functional correctness. Lyapunov, optimal, classical, modern, and robust control theories all provide rigorous mathematical methods both to analyze system performance and to design controller that can be guaranteed to meet certain objectives. Recent computational techniques like level set theory and reachability analysis provide assertions that a system's state will avoid unsafe regions. Even though success has been independently achieved for cyber systems and physical systems, the integration of such systems creates new challenges. In particular, there is an obvious discrepancy between finite-state machines and infinite-state systems, resulting in different approaches for modeling and analyzing these system. While it is possible to simulate hybrid systems, this provides only a demonstration of a performance and not proof. For hybrid systems, current formal methods and system analysis approaches typically require a workarounds to work on hybrid systems like CPS. This paper will outline the state of the art and limits of current practice for formally verifying CPS and will identify possible research directions that require attention.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Automated Direct Perturbation Calculations with SCALE TSUNAMI [Abstract]

In nuclear criticality safety analysis, the sensitivity of the eigenvalue keff to uncertainties in nuclear data and its evaluation are crucial. The TSUNAMI sequences within the SCALE code system offer users various options with both multigroup (MG) and continuous-energy (CE) 3D Monte Carlo (MC) transport capabilities for calculating keff sensitivity coefficients and storing them in a sensitivity data file (SDF). Each methodology available in TSUNAMI offers distinct advantages and limitations, and its effectiveness can vary based on the specific problem being solved. As a best practice, practitioners typically use the direct perturbation (DP) method as a confirmatory step alongside their sensitivity calculations to verify the accuracy of the sensitivity data generated. In this process, DP calculations are usually performed on select nuclides, those considered most important for validating their total sensitivities. However, because of code limitations, analysts use a workaround method when conducting DP calculations for a single nuclide: rather than perturbing the nuclide's microscopic cross section, an equivalent number density for this nuclide is calculated to reflect the effect of a change in the macroscopic cross section due to a perturbation in the microscopic cross section. The current approach requires rerunning the CSAS criticality calculation several times with model changes. Although this method can yield results with acceptable accuracy, it is labor-intensive and prone to errors.

AZURE: SAMMY↗
NASA NTRS2011

NASA's Advanced Multimission Operations System: A Case Study in Formalizing Software Architecture Evolution

All software systems of significant size and longevity eventually undergo changes to their basic architectural structure. Such changes may be prompted by evolving requirements, changing technology, or other reasons. Whatever the cause, software architecture evolution is commonplace in real world software projects. Recently, software architecture researchers have begun to study this phenomenon in depth. However, this work has suffered from problems of validation; research in this area has tended to make heavy use of toy examples and hypothetical scenarios and has not been well supported by real world examples. To help address this problem, I describe an ongoing effort at the Jet Propulsion Laboratory to re-architect the Advanced Multimission Operations System (AMMOS), which is used to operate NASA's deep-space and astrophysics missions. Based on examination of project documents and interviews with project personnel, I describe the goals and approach of this evolution effort and then present models that capture some of the key architectural changes. Finally, I demonstrate how approaches and formal methods from my previous research in architecture evolution may be applied to this evolution, while using languages and tools already in place at the Jet Propulsion Laboratory.

software architecture evolution↗