SEARCH · Engineering Papers
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.
The Goddard Mission Services Evolution Center (GMSEC) Message Bus is a robust, lightweight, fault-tolerant middleware implementation that supports all messaging capabilities of the GMSEC API. This architecture is a distributed software system that routes messages based on message subject names and knowledge of the locations in the network of the interested software components.
The Mission Control Center (MCC) at Johnson Space Center (JSC) has a rich legacy of supporting Human Space Flight operations throughout the Apollo, Shuttle and International Space Station eras. Through the evolution of ground operations and the Mission Control Center facility, NASA has gained a wealth of experience of what it takes to manage the risk in Safety Critical Operations, especially when human life is at risk. The focus of the presentation will be on the processes (training, operational rigor, team dynamics) that enable the JSC/MCC team to be so successful. The presentation will also share the evolution of the Mission Control Center architecture and how the evolution was introduced while managing the risk to the programs supported by the team. The details of the MCC architecture (e.g., the specific software, hardware or tools used in the facility) will not be shared at the conference since it would not give any additional insight as to how risk is managed in Space Operations.
Highly reliable, high-speed, unidirectional serial data-communication subsystems have been proposed to be installed in an upgrade of the computing systems aboard the space shuttles. The basic design concept of these serial data links is also adaptable to terrestrial use in applications in which there are requirements for highly reliable serial data communications. The hardware and software aspects of the architecture of the data links are dictated largely by a requirement, in the original space-shuttle application, for one computer to monitor the memory transactions and memory contents of other computers in real time with high reliability and without reliance on requests for retransmission. To minimize weight while affording a capability to transfer data at a required rate of 2.56 x 10(exp 8) bits per second, it was decided that the links would be serial ones of the fiber-channel type. [Fiber channel denotes a type of serial computer bus that is used to connect a computer (usually a supercomputer) with a high-speed data storage device. Depending on the specific application, the physical connection between the transmitter and receiver could be made via an optical fiber or a twisted pair of wires.] Heretofore, fiber-channel links have ordinarily been bidirectional and have operated under protocols that provide for receiving stations to detect errors and request retransmission when necessary. In the present case, the time taken by processing to request retransmission would conflict with the requirement for real-time transfer of data. To ensure reliability without retransmission, a link according to the proposal would utilize a modified version of the normal fiberchannel character set in conjunction with forward error correction by means of a Reed-Solomon code (see figure). The Reed-Solomon encoding and decoding and the translations between the normal and modified character sets would be effected by logic circuitry external to the fiber-channel transmitter and receiver, which would be commercial off-the-shelf units. The receiving end of the link could detect and correct errors at a rate as high as 4 million times per second, if necessary. The receiver detects uncorrectable double-byte errors. It has been estimated that uncorrectable-error rate would amount to one failure in about 10(exp 19) characters.
The Mars Relay Operations Service (MaROS) is designed to provide planning and analysis tools in support of ongoing Mars Network relay operations. Strategic relay planning requires coordination between lander and orbiter mission ground data system (GDS) teams to schedule and execute relay communications passes. MaROS centralizes this process, correlating all data relevant to relay coordination to provide a cohesive picture of the relay state. Service users interact with the system through thin-layer command line and web user interface client applications. Users provide and utilize data such as lander view periods of orbiters, Deep Space Network (DSN) antenna tracks, and reports of relay pass performance. Users upload and download relevant relay data via formally defined and documented file structures including some described in Extensible Markup Language (XML). Clients interface with the system via an http-based Representational State Transfer (ReST) pattern using Javascript Object Notation (JSON) formats. This paper will provide a general overview of the service architecture and detail the software interfaces and considerations for interface design.
CommLargo, Inc., has developed a scintillation-hardened Global Positioning System (GPS) receiver that improves reliability for low-orbit missions and complies with NASA's Space Telecommunications Radio System (STRS) architecture standards. A software-defined radio (SDR) implementation allows a single hardware element to function as either a conventional radio or as a GPS receiver, providing backup and redundancy for platforms such as the International Space Station (ISS) and high-value remote sensing platforms. The innovation's flexible SDR implementation reduces cost, weight, and power requirements. Scintillation hardening improves mission reliability and variability. In Phase I, CommLargo refactored an open-source GPS software package with Kalman filter-based tracking loops to improve performance during scintillation and also demonstrated improved navigation during a geomagnetic storm. In Phase II, the company generated a new field-programmable gate array (FPGA)-based GPS waveform to demonstrate on NASA's Space Communication and Navigation (SCaN) test bed.
As the number of spacecraft in simultaneous operation continues to grow, there is an increased dependency on ground-based navigation support. The current baseline system for deep space navigation utilizes Earth-based radiometric tracking, requiring long-duration observations to perform orbit determination and generate a state update. The age, complexity, and high utilization of the ground assets pose a risk to spacecraft navigation performance. In order to perform complex operations at large distances from Earth, such as extraterrestrial landing and proximity operations, autonomous systems are required. With increasingly complex mission operations, the need for frequent and Earth-independent navigation capabilities is further reinforced. The Multi-spacecraft Autonomous Positioning System (MAPS) takes advantage of the growing interspacecraft communication network and infrastructure to allow for Earth-autonomous state measurements to enable network-based space navigation. A notional concept of operations is given in figure 1. This network is already being implemented and routinely used in Martian communications through the use of the Mars Reconnaissance Orbiter and Mars Odyssey spacecraft as relays for surface assets. The growth of this communications architecture is continued through MAVEN, and future potential commercial Mars telecom orbiters. This growing network provides an initial Marslocal capability for inter-spacecraft communication and navigation. These navigation updates are enabled by cross-communication between assets in the network, coupled with onboard navigation estimation routines to integrate packet travel time to generate ranging measurements. Inter-spacecraft communication allows for frequent state broadcasts and time updates from trusted references. The architecture is a software-based solution, enabling its implementation on a wide variety of current assets, with the operational constraints and measurement accuracy determined by onboard systems.
UTM is an 'air traffic management' ecosystem for uncontrolled operations. UTM utilizes industry's ability to supply services under FAA's regulatory authority where these services do not exist. UTM development will ultimately enable the management of large scale, low-altitude UAS operations. Operational concept will address beyond visual line of sight UAS operations under 400 ft. AGL. Information architecture, data exchange protocols, software functions. Roles/responsibilities of FAA and operators. Performance requirements.
Explore the source record for details and available documents.
The yourSky custom astronomical image mosaicking software has a web portal architecture that allows access via ordinary desktop computers with low bandwidth network connections to high performance and highly customizable mosaicking software deployed in a high performance computing and communications environment.
This paper summarizes work in progress in three different areas: 1) a framework for the design of higly reliable and higly available space avionics systems; 2) distributed reliable computing architecture; and 3) Guarded Software Upgrading (GSU) techniques for software upgrading during long-term missions such as the Pluto/Kuiper missions.
This presentation details early research towards applying data plane programming and software defined networking (SDN) to delay tolerant networking (DTN). This involved using the Programming Protocol-Independent Packet Processors (P4) language to program the data plane to handle DTN bundles natively in hardware. The results presented include a proof of concept DTN Bundle Protocol (BP) translator network middlebox, the challenges of programming a data plane to process BP, a software-defined DTN (SDDTN) architecture, and potential future applications of SDDTN. It is demonstrated that SDN and the P4 language has high potential for improving the scalability of DTN networks, although further research must be done to enable this.
A new release of the CRISTAL French criticality calculation package, named CRISTAL V2, has been developed and intensively validated by IRSN and CEA, in collaboration with AREVA. This package was designed to cover the needs of criticality practitioners in the fields of nuclear fuel cycle facilities and transportation of fissile materials. Based on an optimized modular architecture in an updated software development environment, the design of CRISTAL package V2 integrates new generation of cross-section libraries, new calculation schemes consistent with new applications, and up-to-date calculation codes capabilities. Four calculation routes are currently available allowing multi-group and continuous energy calculations. The validation database is composed of more than 3000 critical experiments, in order to cover a wide range of configurations. The CRISTAL V2 package also includes customer services covering a large scope of activities like documentations, hotline, maintenance and training courses. A significant promotion and an increased recognition referred both nationally and internationally are foreseen, including the provision of the CRISTAL V2 package to the OECD / NEA Data Bank. (authors)
A new release of the CRISTAL French criticality calculation package, named CRISTAL V2.0, has been developed and intensively validated by IRSN and CEA, in collaboration with AREVA. This package was designed to cover the needs of criticality practitioners in the fields of nuclear fuel cycle facilities and transportation of fissile materials. Based on an optimized modular architecture in an updated software development environment, the design of CRISTAL package V2.0 integrates new generation of cross section libraries, new calculation schemes consistent with new applications, and up-to-date calculation codes capabilities. Four calculation routes are currently available allowing multi-group and continuous energy calculations. The validation database is composed of more than 3000 critical experiments, in order to cover a wide range of configurations. The CRISTAL V2.0 package also comprises customer services covering a range of areas of activity like documentation, hotline, maintenance and training courses. A wide promotion and an increased recognition referred both nationally and internationally are foreseen, including the provision of the CRISTAL V2.0 package to the OECD / NEA Data Bank. (authors)
The U.S. Department of Energy (DOE)'s Home Energy Score provides homeowners, buyers, and renters directly comparable and credible information about a home's estimated energy use and costs. Certified Qualified Assessors conduct low-cost assessments to provide each home a 1-10 score alongside a set of cost-effective upgrades to improve the score. As of February 2022, hundreds of assessors have delivered over 175,000 scores to homes across the country. Originally released in 2012 using DOE2.1e as the modeling backend, after years of effort, a new version of Home Energy Score was released in 2021 utilizing DOE's flagship energy modeling software, EnergyPlus. The updated architecture leverages modeling advancements and enables new building technologies to be added to the Scoring Tool. The new release represents a leap forward in harmonizing modeling assumptions across DOE and industry programs. In this paper we discuss the rigorous approach to model comparison with DOE2 undertaken prior to the update, utilizing test homes and real homes from the Home Energy Score database to strike a balance between consistency and more accurate energy predictions. We also discuss additional new capabilities, including improvements made to the upgrade recommendations methodology, the inclusion of an energy cost estimate metric based on ResStock analysis for use in home appraisals, and improved data analysis for quality assurance. Finally, we look at the impact Home Energy Score has had over the last decade and its future potential as its uptake in state energy plans, local ordinances, utility programs, and real estate data continues to grow.
Proposing a Center of Excellence under the CORAL-2 NRE is a mandatory requirement. The current Sierra COE (CORAL-1) is largely focused on helping LLNL applications make the disruptive transition to a heterogeneous GPU-based system by 2018. We expect a continuation of COE activities around optimizing our broad and diverse application base (of so-called “traditional” simulation codes) optimized for the El Capitan architecture, as well as supporting the underlying software stack (compilers, tools, programming models, etc.) – but do not expect this to require as much effort in the El Capitan COE (assuming a heterogeneous node architecture). What follows are some thoughts on 3 potential topics of interest for an El Capitan COE at LLNL – largely focused around AI and machine learning and the concept of advancing our goal of intelligent simulation or cognitive computing in the timeframe of deployment and production use of El Capitan (2023-2038). We believe vendor engagement through a COE in this area will provide a natural point-of-interest between LLNL and our vendor partner for common advancement of machine learning capabilities focused on scientific data – potentially greatly broadening the ecosystem around HPC architectures and the supporting software stack for scientific simulation-based AI.
With an increased dataset obtained during the Run 3 of the LHC at CERN and the even larger expected increase of the dataset by more than one order of magnitude for the HL-LHC, the ATLAS experiment is reaching the limits of the current data processing model in terms of traditional CPU resources based on x86_64 architectures and an extensive program for software upgrades towards the HL-LHC has been set up. The ARM architecture is becoming a competitive and energy efficient alternative. Some surveys indicate its increased presence in HPCs and commercial clouds, and some WLCG sites have expressed their interest. Chip makers are also developing their next generation solutions on ARM architectures, sometimes combining ARM and GPU processors in the same chip. Consequently it is important that the ATLAS software embraces the change and is able to successfully exploit this architecture. We report on the successful porting to ARM of the Athena software framework, which is used by ATLAS for both online and offline computing operations. Furthermore we report on the successful validation of simulation workflows running on ARM resources. For this we have set up an ATLAS Grid site using ARM compatible middleware and containers on Amazon Web Services (AWS) ARM resources. The ARM version of Athena is fully integrated in the regular software build system and distributed in the same way as other software releases. In addition, the workflows have been integrated into the HEPscore benchmark suite which is the planned WLCG wide replacement of the HepSpec06 benchmark used for Grid site pledges. In the overall porting process we have used resources on AWS, Google Cloud Platform (GCP) and CERN. A performance comparison of different architectures and resources will be discussed.
The development of the Sampling and Caching Subsystem (SCS) of the Mars 2020 Rover Mission is highly dependent on testing of prototype hardware and software operating in explicit conditions as part of integrated testbeds. To achieve relevant integration of hardware and software while maintaining rapid algorithm development capabilities and high testing throughput, the Controls and Autonomy for Sample Acquisition and Handling (CASAH) software system was developed. CASAH is an implementation of the Intelligent Robotics System Architecture (IRSA),which mimics JPL Flight Software (FSW) in that it is divided into hierarchical modules that run separate processes that communicate via message passing, each module is assigned an owner that is a single developer, and the operator initiates requests via a text-based interface that interprets sequences of commands.IRSA enables a modular breakdown of CASAH that follows that of 2020 Flight Software,so developers can take an algorithm from a module in CASAH and re-code it into the same module in FSW. As deployment of CASAH has grown to ten testbeds - each with different hardware and objectives - bottom-up design decisions have been intentionally made to keep the system lightweight and maintainable by a very small team. To date, CASAH has been used to run 1393 different tests. This work describes CASAH, the testbeds and functionality it supports, the tools used to manage the development and sharing of code, and the features of the software. Lessons learned over the past three years of development and deployment are provided.
The design and development of the Space Telescope Science Operations Ground System (ST SOGS) was evaluated to compile a history of lessons learned that would benefit NASA's Space Infrared Telescope Facility (SIRTF). Forty-nine specific recommendations resulted and were categorized as follows: (1) requirements: a discussion of the content, timeliness and proper allocation of the system and segment requirements and the resulting impact on SOGS development; (2) science instruments: a consideration of the impact of the Science Instrument design and data streams on SOGS software; and (3) contract phasing: an analysis of the impact of beginning the various ST program segments at different times. Approximately half of the software design and source code might be useable for SIRTF. Transportability of this software requires, at minimum, a compatible DEC VAX-based architecture and VMS operating system, system support software similar to that developed for SOGS, and continued evolution of the SIRTF operations concept and requirements such that they remain compatible with ST SOGS operation.