SEARCH · Search NASA

Results for “standard user interface”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 451 records · Page 25

All sources NASA NTRS DOE OSTI

DOE OSTI2024

IDAES-PSE Software Tools for Optimizing Energy Systems and Market Interactions

Modern power grids coordinate electricity production and consumption via multi-scale wholesale energy markets. Historically, levelized cost metrics were the de facto standard for techno-eco-nomic analyses of energy systems and comparison of technology options. However, these metrics neglect the complexity of energy infrastructure including the time-varying value of electricity. An emerging alternative is multi-period optimization, which considers the locational marginal price of electricity as input data (parameters). In this work, we present a general interface for multi-period optimization with time-varying energy prices to facilitate rapid analysis and comparison of potential energy systems models. The PriceTakerModel class is written in the IDAES-PSE platform and allows users to generate a multi-period, price-taker model instance, as well as automatically generate common operational constraints for their model, such as start-up and shutdown. We show this interface successfully generates multi-period price-taker models, facilitates model discrimination, and aids in analyzing various technologies for deployment in unique energy markets.

Laky, Daniel↗

NASA NTRS2006

Applying Registry Services to Spaceflight Technologies to Aid in the Assignment of Assigned Numbers to Disparate Systems and Their Technologies to Further Enable Interoperability

To date very little effort has been made to provide interoperability between various space agency projects. To effectively get to the Moon and beyond systems must interoperate. To provide interoperability, standardization and registries of various technologies will be required. These registries will be created as they relate to space flight. With the new NASA Moon/Mars initiative a requirement to standardize and control the naming conventions of very disparate systems and technologies are emerging. The need to provide numbering to the many processes, schemas, vehicles, robots, space suits and technologies (e.g. versions), to name a few, in the highly complex Constellation Initiative is imperative. The number of corporations, developer personnel, system interfaces, people interfaces will require standardization and registries on a scale not currently envisioned. It would only take one exception (stove piped system development) to weaken, if not, destroy interoperability. To start, a standardized registry process must be defined that allows many differing engineers, organizations and operators the ability to easily access disparate registry information across numerous technological and scientific disciplines. Once registries are standardized the need to provide registry support in terms of setup and operations, resolution of conflicts between registries and other issues will need to be addressed. Registries should not be confused with repositories. No end user data is "stored" in a registry nor is it a configuration control system. Once a registry standard is created and approved, the technologies that should be registered must be identified and prioritized. In this paper, we will identify and define a registry process that is compatible with the Constellation Initiative and other non related space activities and organizations. We will then identify and define the various technologies that should use a registry to provide interoperability. The first set of technologies will be those that are currently in need of expansion namely the assignment of satellite designations and the process which controls assignments. Second, we will analyze the technologies currently standardized under the Consultative Committee for Space Data Systems (CCSDS) banner. Third, we will analyze the current CCSDS working group and birds of a feather activities to ascertain registry requirements. Lastly, we will identify technologies that are either currently under the auspices of another

Bradford, Robert N.↗

NASA NTRS2006

Applying Registry Services to Spaceflight Technologies to Aid in the Assignment of Assigned Numbers to Disparate Systems and their Technologies to Further Enable Interoperability

To date very little effort has been made to provide interoperability between various space agency projects. To effectively get to the Moon and beyond systems must interoperate. To provide interoperability, standardization and registries of various technologies will be required. These registries will be created as they relate to space flight. With the new NASA Moon/Mars initiative, a requirement to standardize and control the naming conventions of very disparate systems and technologies is emerging. The need to provide numbering to the many processes, schemas, vehicles, robots, space suits and technologies (e.g. versions), to name a few, in the highly complex Constellation initiative is imperative. The number of corporations, developer personnel, system interfaces, people interfaces will require standardization and registries on a scale not currently envisioned. It would only take one exception (stove piped system development) to weaken, if not, destroy interoperability. To start, a standardized registry process must be defined that allows many differing engineers, organizations and operators the ability to easily access disparate registry information across numerous technological and scientific disciplines. Once registries are standardized the need to provide registry support in terms of setup and operations, resolution of conflicts between registries and other issues will need to be addressed. Registries should not be confused with repositories. No end user data is "stored" in a registry nor is it a configuration control system. Once a registry standard is created and approved, the technologies that should be registered must be identified and prioritized. In this paper, we will identify and define a registry process that is compatible with the Constellation initiative and other non related space activities and organizations. We will then identify and define the various technologies that should use a registry to provide interoperability. The first set of technologies will be those that are currently in need of expansion namely the assignment of satellite designations and the process which controls assignments. Second, we will analyze the technologies currently standardized under the Consultative Committee for Space Data Systems (CCSDS) banner. Third, we will analyze the current CCSDS working group and Birds of a Feather (BoF) activities to ascertain registry requirements. Lastly, we will identify technologies that are either currently under the auspices of another standards body or technologies that are currently not standardized. For activities one through three, we will provide the analysis by either discipline or technology with rationale, identification and brief description of requirements and precedence. For activity four, we will provide a list of current standards bodies e.g. IETF and a list of potential candidates.

Bradford, Robert N.↗

DOE OSTI2024

PUFFIn – A user friendly fast interface for calculating and visualizing the dose distribution in materials

This article describes a new graphical user interface that uses the PENELOPE Monte Carlo code to calculate dose distributions in materials. It is named PUFFIn, for the Penelope User-Friendly Fast Interface and was developed as an educational and scoping analysis tool for non-experts in radiation modeling. PUFFIn enables the user to visualize and compare the dose distributions in objects (e.g., sterilized healthcare products) irradiated with cobalt-60 gamma-rays, electron beam (E-beam) or X-rays. From such comparisons, the user can determine the most efficient product and/or packaging designs for any given radiation field – whether for conceptual or existing products and packaging. PUFFIn is distributed in a complete, self-contained package of software, including the PENELOPE radiation transport code, a standard graphics package, and a set of simple exercises. The package is available to any user at no cost and requires a minimal amount of training compared to other similar software. PUFFIn's capabilities are described, as well as validation measurements performed at Texas A&M University E-beam facility and the Aerial E-beam Facility in France.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS1975

USDI DCS technical support: Mississippi Test Facility

The objective of the technical support effort is to provide hardware and data processing support to DCS users so that application of the system may be simply and effectively implemented. Technical support at Mississippi Test Facility (MTF) is concerned primarily with on-site hardware. The first objective of the DCP hardware support was to assure that standard measuring apparatus and techniques used by the USGS could be adapted to the DCS. The second objective was to try to standardize the miscellaneous variety of parameters into a standard instrument set. The third objective was to provide the necessary accessories to simplify the use and complement the capabilities of the DCP. The standard USGS sites have been interfaced and are presently operating. These sites are stream gauge, ground water level and line operated quality of water. Evapotranspiration, meteorological and battery operated quality of water sites are planned for near future DCP operation. Three accessories which are under test or development are the Chu antenna, solar power supply and add-on memory. The DCP has proven to be relatively easy to interface with many monitors. The large antenna is awkward to install and transport. The DCS has met the original requirements well; it has and is proving that an operation, satellite-based data collection system is feasible.

Preble, D. M.↗

NASA NTRS1999

Plug and Play Integration through Space Object Standardization

Plug and play is an industry standard promoted by Intel and Microsoft, and others that allows users to add and remove various input and output devices without making specific customizations to their systems. The idea behind concept is that using standard products eases integration of components and promotes capabilities of conforming products. The concept works because vendors comply with a standard specification. This paper reports the development of a reference architecture for the mission control domain, which is leveraging off this revolutionary concept. Standards are being developed at the application layer, which enable "plug and play" of mission software products. A Mission Control, reference architecture has been defined. For each sub-domain, the interfaces are modeled in Interface Definition Language (IDL). A subset of the IDL has been developed within both commercial off-the-shelf (COTS) and government (GOTS) products. Selected vendors have agreed to modify their products to be compatible with the defined IDL. The plug and play integration of these different products has been validated in a demonstration testbed.

Boyce, Leslye↗

NASA NTRS2013

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗

DOE OSTI2023

Moore Machine Motion Controls Refurbishment Statement of Work and Specification

Diamond Turning Machines known as “Moore” machines are used in the production of Potassium diHydrogen Phosphate (KDP) optics required for the National Ignition Facility (NIF). These machines are owned by the Department of Energy, as provided by Lawrence Livermore National Security LLC (LLNS). Moore Machines 1 and 2 are located at the Gooch & Housego (G&H) facility in Highland Heights, OH. The existing Aerotech motion controllers, motor drivers/amplifiers, input/output (I/O) hardware, control computer, software user interface, human machine interface (HMI), cabling, and encoders are beyond service life and require replacement. This Statement of Work (SoW) defines the motion control system refurbishment requirements for the Moore diamond turning machines designated Moore 1 and Moore 2. The motion controls system design shall include a motion control computer, control software, motor drive amplifiers and controllers, linear scale encoders, rotary encoders, HMI, power distribution, emergency stop (E-Stop) and interlocks, cabling, switches, solenoids, transducers, sensors, actuators, ancillary system interfaces, and related components necessary for a complete machine tool control system. The Subcontractor shall include effort to standardize systems between the two machines if reasonably possible.

42 ENGINEERING↗

DOE OSTI2026

A User-Friendly GUI Tool for Automated Microstructural Analysis of Fiber-Reinforced Composites and Porous Structures

Understanding and quantifying microstructural features such as fiber orientation and porosity is critical for predicting the mechanical behavior and performance of fiber-reinforced polymer composites. Traditional manual analysis is time-consuming, subjective, and unsuitable for high-throughput datasets. We present a graphical user interface (GUI) application that automates the analysis of microscopy images to extract key microstructural metrics, including fiber orientation tensors, fiber orientation distribution, porosity and pore size distribution. The app integrates multiple image segmentation techniques including global and local thresholding, clustering, and region-based approaches, offering flexibility for different types of image qualities and features. Users can load microstructural images, select regions of interest and segmentation techniques tailored to their image dataset. It also addresses a critical challenge in fiber orientation analysis: the ambiguities caused by touching, overlapping, or partially cut fibers. It supports autorun examples for standardized workflows, enabling reproducible analysis and facilitating training and benchmarking. This tool significantly reduces manual intervention, enhances consistency, and accelerates data generation for structure–property modeling, process optimization, and digital materials research. The tool is intended for use by materials scientists, engineers, and researchers engaged in composite characterization, quality control, and machine learning-based microstructural studies.

Chawla, Komal [ORNL] (ORCID:0000000190327565)↗

NASA NTRS2005

Formal Safety Certification of Aerospace Software

In principle, formal methods offer many advantages for aerospace software development: they can help to achieve ultra-high reliability, and they can be used to provide evidence of the reliability claims which can then be subjected to external scrutiny. However, despite years of research and many advances in the underlying formalisms of specification, semantics, and logic, formal methods are not much used in practice. In our opinion this is related to three major shortcomings. First, the application of formal methods is still expensive because they are labor- and knowledge-intensive. Second, they are difficult to scale up to complex systems because they are based on deep mathematical insights about the behavior of the systems (t.e., they rely on the "heroic proof"). Third, the proofs can be difficult to interpret, and typically stand in isolation from the original code. In this paper, we describe a tool for formally demonstrating safety-relevant aspects of aerospace software, which largely circumvents these problems. We focus on safely properties because it has been observed that safety violations such as out-of-bounds memory accesses or use of uninitialized variables constitute the majority of the errors found in the aerospace domain. In our approach, safety means that the program will not violate a set of rules that can range for the simple memory access rules to high-level flight rules. These different safety properties are formalized as different safety policies in Hoare logic, which are then used by a verification condition generator along with the code and logical annotations in order to derive formal safety conditions; these are then proven using an automated theorem prover. Our certification system is currently integrated into a model-based code generation toolset that generates the annotations together with the code. However, this automated formal certification technology is not exclusively constrained to our code generator and could, in principle, also be integrated with other code generators such as RealTime Workshop or even applied to legacy code. Our approach circumvents the historical problems with formal methods by increasing the degree of automation on all levels. The restriction to safety policies (as opposed to arbitrary functional behavior) results in simpler proof problems that can generally be solved by fully automatic theorem proves. An automated linking mechanism between the safety conditions and the code provides some of the traceability mandated by process standards such as DO-178B. An automated explanation mechanism uses semantic markup added by the verification condition generator to produce natural-language explanations of the safety conditions and thus supports their interpretation in relation to the code. It shows an automatically generated certification browser that lets users inspect the (generated) code along with the safety conditions (including textual explanations), and uses hyperlinks to automate tracing between the two levels. Here, the explanations reflect the logical structure of the safety obligation but the mechanism can in principle be customized using different sets of domain concepts. The interface also provides some limited control over the certification process itself. Our long-term goal is a seamless integration of certification, code generation, and manual coding that results in a "certified pipeline" in which specifications are automatically transformed into executable code, together with the supporting artifacts necessary for achieving and demonstrating the high level of assurance needed in the aerospace domain.

Denney, Ewen↗

NASA NTRS2009

NASA's Earth Observing Data and Information System

NASA's Earth Observing System Data and Information System (EOSDIS) has been a central component of NASA Earth observation program for over 10 years. It is one of the largest civilian science information system in the US, performing ingest, archive and distribution of over 3 terabytes of data per day much of which is from NASA s flagship missions Terra, Aqua and Aura. The system supports a variety of science disciplines including polar processes, land cover change, radiation budget, and most especially global climate change. The EOSDIS data centers, collocated with centers of science discipline expertise, archive and distribute standard data products produced by science investigator-led processing systems. Key to the success of EOSDIS is the concept of core versus community requirements. EOSDIS supports a core set of services to meet specific NASA needs and relies on community-developed services to meet specific user needs. EOSDIS offers a metadata registry, ECHO (Earth Observing System Clearinghouse), through which the scientific community can easily discover and exchange NASA s Earth science data and services. Users can search, manage, and access the contents of ECHO s registries (data and services) through user-developed and community-tailored interfaces or clients. The ECHO framework has become the primary access point for cross-Data Center search-and-order of EOSDIS and other Earth Science data holdings archived at the EOSDIS data centers. ECHO s Warehouse Inventory Search Tool (WIST) is the primary web-based client for discovering and ordering cross-discipline data from the EOSDIS data centers. The architecture of the EOSDIS provides a platform for the publication, discovery, understanding and access to NASA s Earth Observation resources and allows for easy integration of new datasets. The EOSDIS also has developed several methods for incorporating socioeconomic data into its data collection. Over the years, we have developed several methods for determining needs of the user community including use of the American Customer Satisfaction Index and a broad metrics program.

Mitchell, Andrew E.↗

NASA NTRSDate not supplied

The Design of a Flexible, Interoperable Navigation Signal for Future Lunar Missions

The LunaNet Interoperability Specification (LNIS) is a set of standards currently under development by NASA, ESA, and JAXA, which define a common, interoperable set of services and interfaces for lunar communication and navigation. The LNIS includes specifications for the GNSS-like Augmented Forward Signal (AFS). The LANS (Lunar Augmented Navigation Service) will be comprised of Multiple LunaNet Service Provider (LNSP) nodes broadcasting the AFS, such as NASA’s LCRNS (Lunar Communications Relay and Navigation Systems), ESA’s Moonlight LCNS (Lunar Communication and Navigation Services) and the Japan LNSS (Lunar Navigation Satellite System). The LANS will provide a GNSS-like capability enabling orbiting and surface users in lunar space (such as Artemis) to estimate their position, velocity and time as described in Giordano et al., (2023). Initial capabilities will focus on providing service to the lunar South pole region. The specification of AFS defines two orthogonal signal components on a single carrier, with the in-phase component (AFS-I) being a lower-chip-rate data channel tailored for applications where low SWaP is critical (e.g., IoT devices or search and rescue), and the quadrature component (AFS-Q) being a high-chip-rate data-less pilot signal for high-precision, robust lunar navigation and positioning applications. An initial description of AFS was provided in the LNIS, (2023), and initial analysis results were shown in Dafesh, et al., (2024). In this work, we provide rationale for updates to the LNIS that define key aspects of the signal including the primary spreading code designs for the data and pilot channels, and a three-tiered overlay code approach for the pilot channel that provides flexible signal acquisition alternatives, rapid time dissemination and robust frame Sync. The paper also describes a robust data sync word that is designed to enable frame Sync. for low-SWaP receivers that only use the I channel, as well as a low-density parity check code (LDPC) data message encoding design and interleaving definition. The work further describes the impact of the updated AFS design in terms of improved acquisition performance, interference resistance, navigation message capabilities and rapid absolute time dissemination for users able to access clock and ephemeris data over an external network. The cross-correlation and synchronization performance of the AFS design is also compared to potential alternatives, further providing rationale for the final signal design configuration.

LANS↗

NASA NTRS2025

The Design of a Flexible, Interoperable Navigation Signal for Future Lunar Missions

LunaNet↗

DOE OSTI2021

Accurate simulation of surfaces and interfaces of ten FCC metals and steel using Lennard–Jones potentials

Abstract The earlier integration of validated Lennard–Jones (LJ) potentials for 8 fcc metals into materials and biomolecular force fields has advanced multiple research fields, for example, metal–electrolyte interfaces, recognition of biomolecules, colloidal assembly of metal nanostructures, alloys, and catalysis. Here we introduce 12-6 and 9-6 LJ parameters for classical all-atom simulations of 10 further fcc metals (Ac, Ca (α), Ce (γ), Es (β), Fe (γ), Ir, Rh, Sr (α), Th (α), Yb (β)) and stainless steel. The parameters reproduce lattice constants, surface energies, water interfacial energies, and interactions with (bio)organic molecules in 0.1 to 5% agreement with experiment, as well as qualitative mechanical properties under standard conditions. Deviations are reduced up to a factor of one hundred in comparison to earlier Lennard–Jones parameters, embedded atom models, and density functional theory. We also explain a quantitative correlation between atomization energies from experiments and surface energies that supports parameter development. The models are computationally very efficient and applicable to an exponential space of alloys. Compatibility with a wide range of force fields such as the Interface force field (IFF), AMBER, CHARMM, COMPASS, CVFF, DREIDING, OPLS-AA, and PCFF enables reliable simulations of nanostructures up to millions of atoms and microsecond time scales. User-friendly model building and input generation are available in the CHARMM-GUI Nanomaterial Modeler. As a limitation, deviations in mechanical properties vary and are comparable to DFT methods. We discuss the incorporation of reactivity and features of the electronic structure to expand the range of applications and further increase the accuracy.

Kanhaiya, Krishan (ORCID:0000000236222655)↗

NASA NTRS1991

Toward a North American Standard for Mobile Data Services

The rapid introduction of digital mobile communications systems is an important part of the emerging digital communications scene. These developments pose both a potential problem and a challenge. On one hand, these separate market driven developments can result in an uncontrolled mixture of analog and digital links which inhibit data modem services across the mobile/Public Switched network (PSTN). On the other hand, the near coincidence of schedules for development of some of these systems, i.e., Digital Cellular, Mobile Satellite, Land Mobile Radio, and ISDN, provides an opportunity to address interoperability problems by defining interfaces, control, and service standards that are compatible among these new services. In this paper we address the problem of providing data services interoperation between mobile terminals and data devices on the PSTN. The expected data services include G3 Fax, asynchronous data, and the government's STU-3 secure voice system, and future data services such as ISDN. We address a common architecture and a limited set of issues that are key to interoperable mobile data services. We believe that common mobile data standards will both improve the quality of data service and simplify the systems for manufacturers, data users, and service providers.

Dean, Richard A.↗

DOE OSTI2023

MATBOX, an Open-Source Microstructure Analysis Toolbox for Meshing, Generation, Segmentation, and Characterization of 3D Heterogenous Volumes

Battery performance is strongly correlated with electrode microstructural properties. To account for its impact, lithium-ion battery (LIB) models either abstract the microstructural heterogeneity of composite electrodes using effective macroscopic properties (macro- or meso- scale models) or directly solve the system of equations on the microstructure geometry or mesh (microstructure-scale models). Therefore, to be adequate, both families of models require information from the microstructure geometry, which can be provided by the numerical tool presented in this work. MATBOX is a MATLAB open-source application [1] developed by NREL for performing various microstructure-related tasks including microstructure numerical generation, image filtering and microstructure segmentation, microstructure characterization and correlation, visualization, and microstructure meshing. MATBOX was originally developed for the analysis of LIB electrode microstructures; however, the algorithms provided by the toolbox are widely applicable to other heterogeneous materials. The toolbox provides a user-friendly experience thanks to a Graphical-User Interface, requires no coding by the user, and is well documented. This presentation will illustrate various MATBOX features for the characterization of a LIB electrode, including a fully automated Representative Volume Element (RVE) analysis, the numerical generation of complex 'virtual' microstructure, including dual-layer electrodes and carbon-binder additive phase, and the meshing of a complex NMC/graphite full cell microstructure suitable for 3D finite-element modeling. Other modules (segmentation, visualization, and correlation) will be briefly presented. Thanks to its modular, open-source approach, MATBOX can easily incorporate third-party algorithms to eventually build a standard in the field that will benefit the whole scientific community. Effective diffusion coefficient [2], additive phase numerical generation [3], and meshing [4] third-party algorithms have been already integrated in the toolbox with more to come.

DIRECT ENERGY CONVERSION,MATHEMATICS AND COMPUTING↗

NASA NTRS2005

Increasing the Automation and Autonomy for Spacecraft Operations with Criteria Action Table

The Criteria Action Table (CAT) is an automation tool developed for monitoring real time system messages for specific events and processes in order to take user defined actions based on a set of user-defined rules. CAT was developed by Lockheed Martin Space Operations as a part of a larger NASA effort at the Goddard Space Flight Center (GSFC) to create a component-based, middleware-based, and standard-based general purpose ground system architecture referred as GMSEC - the GSFC Mission Services Evolution Center. CAT has been integrated into the upgraded ground systems for Tropical Rainfall Measuring Mission (TRMM) and Small Explorer (SMEX) satellites and it plays the central role in their automation effort to reduce the cost and increase the reliability for spacecraft operations. The GMSEC architecture provides a standard communication interface and protocol for components to publish/describe messages to an information bus. It also provides a standard message definition so components can send and receive messages to the bus interface rather than each other, thus reducing the component-to-component coupling, interface, protocols, and link (socket) management. With the GMSEC architecture, components can publish standard event messages to the bus for all nominal, significant, and surprising events in regard to satellite, celestial, ground system, or any other activity. In addition to sending standard event messages, each GMSEC compliant component is required to accept and process GMSEC directive request messages.

Li, Zhen-Ping↗

DOE OSTI2025

FY 2025 Multidimensional Data Correlation Platform: Unified Software Architecture for Advanced Materials and Manufacturing Technologies Data Management and Processing

The Advanced Materials and Manufacturing Technologies (AMMT) program continues to advance a data-driven approach to demonstrate the utility of additive manufacturing for fabricating components for nuclear applications. A key scientific goal is to leverage data to better understand manufacturing outcomes and thereby improve the performance, reliability, and lifespan of nuclear components. Ultimately, this effort supports the development of standards for certification and qualification of additively manufactured components, enabling broader industry adoption. In support of this objective, the AMMT program is building and deploying a data management platform to record, index, analyze, and make available the manufacturing data generated across the AMMT program. In FY 2023, the team conceptualized the architecture of the platform and, in FY 2024, deployed the first functional version at the Oak Ridge National Laboratory (ORNL) Manufacturing Demonstration Facility (MDF). In FY 2025, the platform was officially opened to all AMMT members. To enable this expansion, core modifications and enhancements were developed, including improvements to the user interface and workflows for data entry and retrieval. Most notably, robust security and access control mechanisms were implemented to protect data and manage information sharing. This effort featured a logging system, protected views, and controlled access mechanisms. This report documents these enhancements and the transition of the platform into program-wide use.

36 MATERIALS SCIENCE↗