SEARCH · Search NASA

Results for “modular 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 487 records · Page 27

All sources NASA NTRS DOE OSTI

DOE OSTI2023

Modular, Multifunction, Multiport and Medium Voltage Utility Scale SiC PV Inverter (Final Report)

This project is to develop and demonstrate a Modular, Multi-function, Multiport and Medium Voltage utility scale SiC solar inverter (M4 Inverter). The M4 Inverter is a next generation utility scale PV + storage inverter that can substantially reduce the levelized cost of energy (LCOE) while providing grid friendly ancillary services. Conventional utility scale solar inverters includes three parts, a megawatt rated solar inverter, a low frequency transformer (LFT) and a medium voltage switch gear. The proposed M4 Inverter directly converts the DC output of solar panels to medium voltage AC, eliminating the bulky and costly LFT. The M4 Inverter also has a DC port to interface with an additional energy storage device. This plus its bidirectional power flow capability, allows multiple functions in addition to PV maximum power tracking be achieved. These additional functionalities include but not limited to reactive power support, peak shaving, fast frequency regulation and synthetic inertia. Predicted LCOE reductions with these added functionalities, improved efficiency and longer lifetime time are more than 30% compared with the 2017 utility scale solar LCOE. A 1MVA SiC M4 Inverter was developed and tested at high power level. The project has also advanced the state of the art in controller hardware in the loop simulation capability. Power electronic innovations introduced in the M4 Inverter includes 1700V SiC MOSFET application in 1500V PV system, soft switching three-port power converters and modular converter architecture.

24 POWER TRANSMISSION AND DISTRIBUTION↗

NASA NTRS1992

Data storage and retrieval system abstract

The STX mass storage system design is intended for environments requiring high speed access to large volumes of data (terabyte and greater). Prior to commitment to a product design plan, STX conducted an exhaustive study of the commercially available off-the-shelf hardware and software. STX also conducted research into the area of emerging technologies in networks and storage media so that the design could easily accommodate new interfaces and peripherals as they came on the market. All the selected system elements were brought together in a demo suite sponsored jointly by STX and ALLIANT where the system elements were evaluated based on actual operation using a client-server mirror image configuration. Testing was conducted to assess the various component overheads and results were compared against vendor data claims. The resultant system, while adequate to meet our capacity requirements, fell short of transfer speed expectations. A product team lead by STX was assembled and chartered with solving the bottleneck issues. Optimization efforts yielded a 60 percent improvement in throughput performance. The ALLIANT computer platform provided the I/O flexibility needed to accommodate a multitude of peripheral interfaces including the following: up to twelve 25MB/s VME I/O channels; up to five HiPPI I/O full duplex channels; IPI-s, SCSI, SMD, and RAID disk array support; standard networking software support for TCP/IP, NFS, and FTP; open architecture based on standard RISC processors; and V.4/POSIX-based operating system (Concentrix). All components including the software are modular in design and can be reconfigured as needs and system uses change. Users can begin with a small system and add modules as needed in the field. Most add-ons can be accomplished seamlessly without revision, recompilation or re-linking of software.

Matheson, Barbara↗

NASA NTRS1998

A Geometry Based Infra-Structure for Computational Analysis and Design

The computational steps traditionally taken for most engineering analysis suites (computational fluid dynamics (CFD), structural analysis, heat transfer and etc.) are: (1) Surface Generation -- usually by employing a Computer Assisted Design (CAD) system; (2) Grid Generation -- preparing the volume for the simulation; (3) Flow Solver -- producing the results at the specified operational point; (4) Post-processing Visualization -- interactively attempting to understand the results. For structural analysis, integrated systems can be obtained from a number of commercial vendors. These vendors couple directly to a number of CAD systems and are executed from within the CAD Graphical User Interface (GUI). It should be noted that the structural analysis problem is more tractable than CFD; there are fewer mesh topologies used and the grids are not as fine (this problem space does not have the length scaling issues of fluids). For CFD, these steps have worked well in the past for simple steady-state simulations at the expense of much user interaction. The data was transmitted between phases via files. In most cases, the output from a CAD system could go to Initial Graphics Exchange Specification (IGES) or Standard Exchange Program (STEP) files. The output from Grid Generators and Solvers do not really have standards though there are a couple of file formats that can be used for a subset of the gridding (i.e. PLOT3D data formats). The user would have to patch up the data or translate from one format to another to move to the next step. Sometimes this could take days. Specifically the problems with this procedure are:(1) File based -- Information flows from one step to the next via data files with formats specified for that procedure. File standards, when they exist, are wholly inadequate. For example, geometry from CAD systems (transmitted via IGES files) is defined as disjoint surfaces and curves (as well as masses of other information of no interest for the Grid Generator). This is particularly onerous for modern CAD systems based on solid modeling. The part was a proper solid and in the translation to IGES has lost this important characteristic. STEP is another standard for CAD data that exists and supports the concept of a solid. The problem with STEP is that a solid modeling geometry kernel is required to query and manipulate the data within this type of file. (2) 'Good' Geometry. A bottleneck in getting results from a solver is the construction of proper geometry to be fed to the grid generator. With 'good' geometry a grid can be constructed in tens of minutes (even with a complex configuration) using unstructured techniques. Adroit multi-block methods are not far behind. This means that a million node steady-state solution can be computed on the order of hours (using current high performance computers) starting from this 'good' geometry. Unfortunately, the geometry usually transmitted from the CAD system is not 'good' in the grid generator sense. The grid generator needs smooth closed solid geometry. It can take a week (or more) of interaction with the CAD output (sometimes by hand) before the process can begin. One way Communication. (3) One-way Communication -- All information travels on from one phase to the next. This makes procedures like node adaptation difficult when attempting to add or move nodes that sit on bounding surfaces (when the actual surface data has been lost after the grid generation phase). Until this process can be automated, more complex problems such as multi-disciplinary analysis or using the above procedure for design becomes prohibitive. There is also no way to easily deal with this system in a modular manner. One can only replace the grid generator, for example, if the software reads and writes the same files. Instead of the serial approach to analysis as described above, CAPRI takes a geometry centric approach. This makes the actual geometry (not a discretized version) accessible to all phases of the analysis. The connection to the geometry is made through an Application Programming Interface (API) and NOT a file system. This API isolates the top-level applications (grid generators, solvers and visualization components) from the geometry engine. Also this allows the replacement of one geometry kernel with another, without effecting these top-level applications. For example, if UniGraphics is used as the CAD package then Parasolid (UG's own geometry engine) can be used for all geometric queries so that no solid geometry information is lost in a translation. This is much better than STEP because when the data is queried, the same software is executed as used in the CAD system. Therefore, one analyzes the exact part that is in the CAD system. CAPRI uses the same idea as the commercial structural analysis codes but does not specify control. Software components of the CAD system are used, but the analysis suite, not the CAD operator, specifies the control of the software session. This also means that the license issues (may be) minimized and individuals need not have to know how to operate a CAD system in order to run the suite.

Haimes, Robert↗

DOE OSTI2022

Olympus System Backplane Definition

The purpose of this document is to define the backplane of the Olympus firing system, a modular system based on SpaceWire communication between modules. The backplane provides the connection between the modules, controller (embedded in the front module), the SpaceWire router, and an alternative switch. Those connections include SpaceWire links, interlocks, a key, a dead-man switch (DMS)/charge, timing lines, power distribution, geographical addresses, and communication to the human-machine interface (HMI). This backplane is based on the VMEBus International Trade Association (VITA) 46 Specification (VPX) and OpenVPX standards for a 3U backplane. Unless otherwise specified, those standards apply for signal definitions and mechanical specifications.

42 ENGINEERING↗

NASA NTRS1976

Implementation of an experimental fault-tolerant memory system

The experimental fault-tolerant memory system described in this paper has been designed to enable the modular addition of spares, to validate the theoretical fault-secure and self-testing properties of the translator/corrector, to provide a basis for experiments using the new testing and correction processes for recovery, and to determine the practicality of such systems. The hardware design and implementation are described, together with methods of fault insertion. The hardware/software interface, including a restricted single error correction/double error detection (SEC/DED) code, is specified. Procedures are carefully described which, (1) test for specified physical faults, (2) ensure that single error corrections are not miscorrections due to triple faults, and (3) enable recovery from double errors.

Carter, W. C.↗

DOE OSTI2022

New modelling capabilities in IDT

This work concerns the enhanced modelling capabilities of the discrete ordinates transport solver IDT. The novelties introduced allow for modelling unstructured geometries composed by a collection of X/Y segments and circles, and the use of reciprocity and conservation relations reduce the memory imprint as well as the computational cost of the method. IDT decomposes geometries in modular Cartesian patterns, which are the so-called Heterogeneous Cartesian Cells (HCCs), containing a chunk of the original unstructured geometries. Each HCC can be then discretized by superimposing a XY grid to refine locally the HCC. Unlike the most popular MOC, IDT performs the spatial sweeping by directional collision probabilities instead of trajectories. The sources and interface angular fluxes are expanded up to linear order. The accuracy of ray-tracing, the memory imprints together with the novel mesh refinement capabilities have been verified. A first set of preliminary results on PWR lattice problems will be presented in this paper.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

NASA NTRS1996

A Note on Interfacing Object Warehouses and Mass Storage Systems for Data Mining Applications

Data mining is the automatic discovery of patterns, associations, and anomalies in data sets. Data mining requires numerically and statistically intensive queries. Our assumption is that data mining requires a specialized data management infrastructure to support the aforementioned intensive queries, but because of the sizes of data involved, this infrastructure is layered over a hierarchical storage system. In this paper, we discuss the architecture of a system which is layered for modularity, but exploits specialized lightweight services to maintain efficiency. Rather than use a full functioned database for example, we use light weight object services specialized for data mining. We propose using information repositories between layers so that components on either side of the layer can access information in the repositories to assist in making decisions about data layout, the caching and migration of data, the scheduling of queries, and related matters.

Grossman, Robert L.↗

NASA NTRS1986

Investigation of an advanced fault tolerant integrated avionics system

Presented is an advanced, fault-tolerant multiprocessor avionics architecture as could be employed in an advanced rotorcraft such as LHX. The processor structure is designed to interface with existing digital avionics systems and concepts including the Army Digital Avionics System (ADAS) cockpit/display system, navaid and communications suites, integrated sensing suite, and the Advanced Digital Optical Control System (ADOCS). The report defines mission, maintenance and safety-of-flight reliability goals as might be expected for an operational LHX aircraft. Based on use of a modular, compact (16-bit) microprocessor card family, results of a preliminary study examining simplex, dual and standby-sparing architectures is presented. Given the stated constraints, it is shown that the dual architecture is best suited to meet reliability goals with minimum hardware and software overhead. The report presents hardware and software design considerations for realizing the architecture including redundancy management requirements and techniques as well as verification and validation needs and methods.

Dunn, W. R.↗

NASA NTRS1987

Space station experiment definition: Long-term cryogenic fluid storage

The conceptual design of a space station Technology Development Mission (TDM) experiment to demonstrate and evaluate cryogenic fluid storage and transfer technologies is presented. The experiment will be deployed on the initial operational capability (IOC) space station for a four-year duration. It is modular in design, consisting of three phases to test the following technologies: passive thermal technologies (phase 1), fluid transfer (phase 2), and active refrigeration (phase 3). Use of existing hardware was a primary consideration throughout the design effort. A conceptual design of the experiment was completed, including configuration sketches, system schematics, equipment specifications, and space station resources and interface requirements. These requirements were entered into the NASA Space Station Mission Data Base. A program plan was developed defining a twelve-year development and flight plan. Program cost estimates are given.

Jetley, R. L.↗

NASA NTRS2019

Medical Data Architecture (MDA) Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.In fiscal year 2018, the MDA project developed Test Bed 2, the second iteration in a series of prototypes with functionality focused on data security through role-based access control and encryption, integration with One Portal exercise software and ingestion of an ultrasound Digital Imaging and Communications in Medicine (DICOM) file and image display. Test Bed 2 advances the medical data system architecture framework by providing these functionalities in a scalable system that maintained a layered, modular design. The architecture framework uses a data services approach with role-based access to data in a customized medical record system suitable for space exploration. These functionalities were demonstrated as part of the Next Space Technologies for Exploration Partnerships (NextSTEP) ground test demonstrated at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Interfacing to a Core Flight Software (CFS) system, the MDA system, using Consultative Committee for Space Data Systems (CCSDS) protocol, transferred an exercise file from the simulated flight MDA system to a mirrored MDA system on the ground through the CFS system. The selection of data sources and demonstrations enabled the team to address stakeholder concerns throughout the development process. In the next iteration, the MDA team will work with stakeholders to identify additional relevant functionalities to further advance system data models, standards and principles that will inform the medical system requirements development.

medical data architecture↗

DOE OSTI2022

SODA Synthesizer: an Open-source, Multi-level, Modular, Extensible Compiler from High-level Frameworks to Silicon

The SODA Synthesizer is an open-source modular, end-to-end hardware compiler framework. The SODA frontend, developed in MLIR, performs system-level design, code partitioning, and high-level optimizations to prepare the specifications for the hardware synthesis. The backend is based on a state-of-the-art high-level synthesis tool, and generates the final hardware design. The backend can interface with logic synthesis tools for field programmable gate arrays or with commercial and open-source logic synthesis tools for application-specific integrated circuits. We discuss the opportunities and challenges in integrating with commercial and open-source tools both at the frontend and backend, and the unique opportunities that an open-source hardware design ecosystem provides.

Bohm Agostini, Nicolas↗

NASA NTRS2012

Modular System to Enable Extravehicular Activity

The ability to perform extravehicular activity (EVA), both human and robotic, has been identified as a key component to space missions to support such operations as assembly and maintenance of space systems (e.g. construction and maintenance of the International Space Station), and unscheduled activities to repair an element of the transportation and habitation systems that can only be accessed externally and via unpressurized areas. In order to make human transportation beyond lower Earth orbit (LEO) practical, efficiencies must be incorporated into the integrated transportation systems to reduce system mass and operational complexity. Affordability is also a key aspect to be considered in space system development; this could be achieved through commonality, modularity and component reuse. Another key aspect identified for the EVA system was the ability to produce flight worthy hardware quickly to support early missions and near Earth technology demonstrations. This paper details a conceptual architecture for a modular EVA system that would meet these stated needs for EVA capability that is affordable, and that could be produced relatively quickly. Operational concepts were developed to elaborate on the defined needs, and to define the key capabilities, operational and design constraints, and general timelines. The operational concept lead to a high level design concept for a module that interfaces with various space transportation elements and contains the hardware and systems required to support human and telerobotic EVA; the module would not be self-propelled and would rely on an interfacing element for consumable resources. The conceptual architecture was then compared to EVA Systems used in the Space Shuttle Orbiter, on the International Space Station to develop high level design concepts that incorporate opportunities for cost savings through hardware reuse, and quick production through the use of existing technologies and hardware designs. An upgrade option was included to make use of the developing suit port technologies.

Sargusingh, Miriam J.↗

NASA NTRS2019

Persistent Assets in Zero-G and on Planetary Surfaces: Enabled by Modular Technology and Robotic Operations

Space operations are on the cusp of a revolutionary new operational paradigm that leverages modular systems and recurring robotic visits to “Persistent Assets” enabling asset maintenance, repair, and enhancement. A “Persistent Asset” is defined here as any zero-g or planetary surface system that benefits from in-space assembly (ISA) or multiple visits for servicing, repairs, and upgrades. This term is an extension of the term “Persistent Platform” used by Ms. Pam Melroy at the Defense Advanced Research Projects Agency to describe the vision of the Agency for a geosynchronous Earth orbiting platform. In this paper, the term “Persistent Asset” is introduced to encompass not only zero-g systems; such as telecommunication platforms, Earth observing science platform, Department of Defense platforms, and scientific telescope systems, but also planetary surface systems that support missions such as human outposts, science stations, and in-situ resource utilization systems. In contrast to the current state of the art, where space systems are typically launched as a single unit and operated without any further physical intervention after launch; future systems will be maintained, enhanced and reconfigured in-situ as new technology becomes available or mission needs change. Visits to the persistent asset can be regularly scheduled or dictated by funding constraints enabling a pay-as-you-go approach, which is largely independent of time-constraints and able to exploit launches of opportunity. In this paper, historical in-space assembly activities which relied heavily on astronaut extra-vehicular activity will be reviewed as well as early robotic assembly activities. These approaches will be contrasted with emerging modular approaches supporting realization of a new Persistent Asset operational paradigm. The paper will define attributes of the Persistent Asset paradigm and illustrate advantages by applying the paradigm to two relevant applications: 1) a large space telescope backing structure and 2) the backbone structure for a solar electric transport vehicle. Finally, recently developed unique Persistent Asset elements (modules, and interface approaches) will be described.

Doggett, William R.↗

NASA NTRS2018

Persistent Assets in Zero-G and on Planetary Surfaces: Enabled by Modular Technology and Robotic Operations

William R Doggett↗

NASA NTRS2023

The Design of the Low-Earth Orbit Flight Test of an Inflatable Decelerator (LOFTID) Reentry Vehicle (RV)

This discussion will involve the design and architecture of the Low-Earth Orbit Flight Test of an Inflatable Decelerator (LOFTID) Reentry Vehicle (RV). It will describe the structure and modular design of the RV, expounding on its various subsystems, including power and commanding, data handling and recovery, instrumentation, the inflation system, and the aeroshell. The unique launch vehicle architecture for the LOFTID mission, as a massive rideshare payload, required the development of supporting flight systems, including the Payload Adapter Separation System (PASS) and the Reentry Vehicle Payload Adapter Interface Ring (RVPAIR). To do no harm to the primary mission, the LOFTID team also designed and delivered a flightworthy Mass Simulator as risk reduction in the event the RV was not ready in time for the primary mission launch date. Various challenges and design trades will be discussed, along with a brief description of the RV performance in flight.

R J Bodkin↗

NASA NTRSDate not supplied

The Design of the Low-Earth Orbit Flight Test of an Inflatable Decelerator (LOFTID) Reentry Vehicle (RV)

R J Bodkin↗

DOE OSTI2022

Modular Control Architecture for Scalable, Resilient, and Cybersecure Microgrids Test Results [Mojave firmware 1.09 FW valuation]

This quick note outlines what we found after our conversion with you and your team. As suggested, we loaded 1547-2003 source requirements document (SRD) and then went back and loaded 1547-2018 SRD. This did result in implementing the new 1547-2018 settings. This short report focuses on the frequency-watt function and shows a couple of screen shots of the parameter settings via the Mojave HMI interface and plots of the results of the inverter with FW function enabled in both default and most aggressive settings response to frequency events. The first screen shot shows the 1547-2018 selected after selecting 1547-2003.

42 ENGINEERING↗

DOE OSTI2023

Improving the secretion of designed protein assemblies through negative design of cryptic transmembrane domains

Computationally designed protein nanoparticles have recently emerged as a promising platform for the development of new vaccines and biologics. For many applications, secretion of designed nanoparticles from eukaryotic cells would be advantageous, but in practice, they often secrete poorly. Here we show that designed hydrophobic interfaces that drive nanoparticle assembly are often predicted to form cryptic transmembrane domains, suggesting that interaction with the membrane insertion machinery could limit efficient secretion. We develop a general computational protocol, the Degreaser, to design away cryptic transmembrane domains without sacrificing protein stability. The retroactive application of the Degreaser to previously designed nanoparticle components and nanoparticles considerably improves secretion, and modular integration of the Degreaser into design pipelines results in new nanoparticles that secrete as robustly as naturally occurring protein assemblies. Both the Degreaser protocol and the nanoparticles we describe may be broadly useful in biotechnological applications.

77 NANOSCIENCE AND NANOTECHNOLOGY↗