Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software Architecture”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 829 records · Page 46
All sourcesNASA NTRSDOE OSTI
NASA NTRS2016

MarCO: Interplanetary Mission Development on a CubeSat Scale

Mars Cube One (MarCO) is a twin CubeSat mission developed by the NASA Jet Propulsion Laboratory (JPL) to accompany the InSight (Interior Exploration using Seismic Investigations, Geodesy and Heat Transport) Mars mission lander. MarCO's primary mission objective is to launch with InSight and independently fly to Mars to serve as a communications relay during InSight's entry, descent, and landing (EDL) phase. MarCO represents a new type of deep space mission: CubeSats at Mars. Building on the development of JPL's first interplanetary CubeSat project, the Interplanetary Nano-Spacecraft Pathfinder in Relevant Environment (INSPIRE), MarCO further refined the approach to hardware, software, and ground architecture development to solve the challenges of quickly building low-budget spacecraft to fly to Mars. The greatest constraint, beyond others typical of CubeSat missions, was time. The duration between MarCO's conception to completion of spacecraft assembly was less than two years - an unprecedented schedule for any planetary mission to date. Through necessity, MarCO has built on previous experience, procedures, systems, and development methodologies, defining a new niche for supporting larger primary missions. The MarCO spacecraft are poised to write a new chapter in deep space exploration.

Schoolcraft, Josh↗
NASA NTRS2016

MarCO: Interplanetary Mission Development on a CubeSat Scale

Shortly after JPL’s Interior Exploration using Seismic Investigations, Geodesy and Heat Transport (InSight) mission launches, separates, and commences its cruise phase, two CubeSats will deploy from the launch vehicle’s upper stage and begin independent flight to Mars (Fig. 1). During InSight’s entry, descent, and landing (EDL) sequence, these twin Mars Cube One (MarCO) spacecraft will fly 3,500 km above the Martian surface, recording and relaying InSight UHF radio data to the Deep Space Network (DSN) on Earth1. MarCO is a twin CubeSat mission developed by the NASA Jet Propulsion Laboratory (JPL) to accompany the InSight (Interior Exploration using Seismic Investigations, Geodesy and Heat Transport) Mars mission lander. MarCO's primary mission objective is to launch with InSight and independently fly to Mars to serve as a communications relay during InSight's entry, descent, and landing (EDL) phase. MarCO represents a new type of deep space mission: CubeSats at Mars. Building on the development of JPL's first interplanetary CubeSat project, the Interplanetary Nano-Spacecraft Pathfinder in Relevant Environment (INSPIRE), MarCO further refined the approach to hardware, software, and ground architecture development to solve the challenges of quickly building low-budget spacecraft to fly to Mars. The greatest constraint, beyond others typical of CubeSat missions, was time. The duration between MarCO's conception to completion of spacecraft assembly was less than two years - an unprecedented schedule for any planetary mission to date. Through necessity, MarCO has built on previous experience, procedures, systems, and development methodologies, defining a new niche for supporting larger primary missions. The MarCO spacecraft are poised to write a new chapter in deep space exploration. Originally slated to launch and reach Mars in 2016, the InSight mission schedule subsequently slipped to 2018. During the original landing of InSight, Earth would not be in view, and no orbiter around Mars would have been in position to both receive UHF EDL data and simultaneously relay it back to Earth. It was from this obstacle that MarCO was conceived. Regardless of any changes to InSight’s 2018 EDL configuration geometry, MarCO is still expected to fly and serve in the same capacity as originally designed: the first CubeSat mission to Mars. CubeSats have historically been firmly in the domain of universities and small companies. As first conceived, they served as a platform upon which to teach all aspects of the space mission lifecycle. JPL took on this mission type with Interplanetary Nano-Spacecraft Pathfinder in Relevant Environment2 (INSPIRE), moving the concept into a new domain: deep space. Building from the INSPIRE platform and lessons learned, MarCO addressed new challenges in the domain of planetary missions: independent interplanetary flight and navigation, integration with a large-scale mission, long-distance and long-delay communication, short development time, and a small development team. Of these, the greatest constraint was schedule: only 18 months passed from conception of mission concept until delivery of fully assembled and tested flight hardware. Careful selection of mission team, along with extensive use of off-the-shelf equipment, and streamlining automated processes, was essential. This achievement represents the next step in the evolution of CubeSats beyond low-Earth orbit.

Werne, Thomas↗
NASA NTRSDate not supplied

Test Results for Autonomous Assembly of Modular Space Structures

This paper presents test results for autonomous assembly of a modular space structure. A Universal Robots UR10e manipulator with a custom end-effector, known as the Grapple Tool, was used to join TriTruss structural modules. The TriTrusses and their assembly configuration were developed for an in-space assembled telescope conceptual design. The tests presented here were performed with a 1:2.8 dimensionally scaled version of the Tri-Trusses. Robot trajectories were generated autonomously using a sample-based motion planner and an a-priori worksite model. The test results verify the assembly concept of operations as well as the software requirements for the Grapple Tool. While the Grapple Tool used in the tests was designed for the 1:2.8 scale Tri-Trusses, it has the same actuators, software, and computation architecture as the version designed for the full scale structure. The test operations consist of picking up two TriTrusses from their stowed locations and joining them to a third TriTruss mounted on a test stand and joining them to each other. This constitutes the first three modules of the in-space assembled telescope conceptual design. The paper presents the robot behavioral architecture, the generated trajectories commanded, the actual trajectories of the robot, and actuator performance of the Grapple Tool.

test↗
NASA NTRSDate not supplied

Test Results for Autonomous Assembly of Modular Space Structures

This paper presents test results for autonomous assembly of a modular space structure. A Universal Robots UR10e manipulator with a custom end-effector, known as the Grapple Tool, was used to join TriTruss structural modules. The TriTrusses and their assembly configuration were developed for an in-space assembled telescope conceptual design. The tests presented here were performed with a 1:2.8 dimensionally scaled version of the Tri-Trusses. Robot trajectories were generated autonomously using a sample-based motion planner and an a-priori worksite model. The test results verify the assembly concept of operations as well as the software requirements for the Grapple Tool. While the Grapple Tool used in the tests was designed for the 1:2.8 scale Tri-Trusses, it has the same actuators, software, and computation architecture as the version designed for the full scale structure. The test operations consist of picking up two TriTrusses from their stowed locations and joining them to a third TriTruss mounted on a test stand and joining them to each other. This constitutes the first three modules of the in-space assembled telescope conceptual design. The paper presents the robot behavioral architecture, the generated trajectories commanded, the actual trajectories of the robot, and actuator performance of the Grapple Tool.

test↗
NASA NTRSDate not supplied

Biomass Harmonization and SAR Analysis with the Multi-mission Algorithm and Analysis Platform (MAAP)

The Multi‐mission Algorithm and Analysis Platform (MAAP) is a collaborative effort between NASA and the European Space Agency (ESA) to support above ground biomass (AGB) research in an open science framework. MAAP brings together relevant data, algorithms, and computing capabilities in a common cloud environment to address the challenges of sharing and processing data from field, airborne and satellite measurements. MAAP was publicly released in October 2021, providing computing capabilities co-located with the data, a collaborative coding and analysis environment, and a set of interoperable tools and algorithms developed to support the estimation and visualization of data. MAAP has allowed scientists from both North America and Europe to collaborate on the generation and analysis/visualization of data derived from multiple, discipline-adjacent missions in an open, collaborative environment that has reached beyond traditional scientific investigation. MAAP has been used to support multiple scientific activities. To date, existing LiDAR data from multiple platforms has been calibrated with field measurements and combined for more comprehensive and accurate estimates of above ground biomass AGB; these LiDAR platforms include airborne (e.g. LVIS), the International Space Station (NASA’s Global Ecosystem Dynamics Investigation (GEDI), and satellites (e.g. ICESat-2). The current challenge is to effectively and seamlessly combine the aforementioned LiDAR-based data with new data sources such as P-band RADAR from ESA’s upcoming BIOMASS mission, existing ESA Sentinel-1 C-band SAR, and the 30 PB/yr of high cadence global coverage L-band SAR data from the upcoming NASA-ISRO SAR (NISAR) mission. Recent analysis using MAAP merged ICESat-2 and optical data (Harmonized Landsat Sentinel) produced the most comprehensively precise estimate of boreal-wide AGB to date. Another effort using MAAP is the production and open distribution of global comparisons of AGB map estimates, including from ICESat-2 and GEDI, to bolster stakeholder uptake for policy applications. These map estimates will feed into the Intergovernmental Panel on Climate Change (IPCC) database, likely aiding the next Global Carbon Stocktake of the UNFCCC. Furthermore, the biomass retrieval intercomparison exercise BRIX-2 could benefit from the MAAP providing standardized test cases (based on airborne campaign and spaceborne data) allowing the community to develop and apply retrieval algorithms based on these test cases, while forthcoming SAR data training curricula could also use the MAAP as a teaching and learning platform. The MAAP is meeting the challenges inherent in international, open science collaboration and large scale computing with a platform that is entirely open source and cloud native, using open standards for data access, manipulation, protocols, and formats. The MAAP data system consists of a dedicated data store whose data is indexed in an online catalog conforming to established metadata, application programmatic interfaces (APIs), and service interface standards, using an implementation of the open sourced NASA Common Metadata Repository. Federation of user identities allows users from either NASA or ESA to access and consume services from the other using a unified metadata catalog for the data utilized across the ESA and NASA MAAP platforms. Similarly, we are exploring how to increase interoperability to achieve a common approach to packaging, orchestrating and executing algorithms, with interoperable access to data for subsetting, fast browse, and cloud-optimized access, all using interoperable standards such as those from the Open Geospatial Consortium (OGC). Designed for interoperability, ESA and NASA utilize a common architecture for the software platform. It provides a cloud-based algorithm development environment (ADE) that enables scientists to develop algorithms collaboratively with access to the MAAP data catalog as well as other data archives. MAAP provides an Eclipse Che-based ADE supporting both Python and R languages, popular in this biomass community. Algorithms developed and containerized within the ADE can be deployed to run to thousands of computational nodes in the MAAP’s data processing system (DPS), dramatically speeding up processing and giving scientists a rapid, iterative turnaround of results. NASA’s implementation of the DPS is based on the Hybrid Science Data System (HySDS) framework, used by NASA flight projects to produce Earth science standard products.

cloud computing↗
DOE OSTI2013

Multiphysics Simulations: Challenges and Opportunities

We consider multiphysics applications from algorithmic and architectural perspectives, where "algorithmic" includes both mathematical analysis and computational complexity, and "architectural" includes both software and hardware environments. Many diverse multiphysics applications can be reduced, en route to their computational simulation, to a common algebraic coupling paradigm. Mathematical analysis of multiphysics coupling in this form is not always practical for realistic applications, but model problems representative of applications discussed herein can provide insight. A variety of software frameworks for multiphysics applications have been constructed and refined within disciplinary communities and executed on leading-edge computer systems. We examine several of these, expose some commonalities among them, and attempt to extrapolate best practices to future systems. From our study, we summarize challenges and forecast opportunities.

99 GENERAL AND MISCELLANEOUS↗
DOE OSTI2017

Build and Execute Environment

At exascale, the challenge becomes to develop applications that run at scale and use exascale platforms reliably, efficiently, and flexibly. Workflows become much more complex because they must seamlessly integrate simulation and data analytics. They must include down-sampling, post-processing, feature extraction, and visualization. Power and data transfer limitations require these analysis tasks to be run in-situ or in-transit. We expect successful workflows will comprise multiple linked simulations along with tens of analysis routines. Users will have limited development time at scale and, therefore, must have rich tools to develop, debug, test, and deploy applications. At this scale, successful workflows will compose linked computations from an assortment of reliable, well-defined computation elements, ones that can come and go as required, based on the needs of the workflow over time. We propose a novel framework that utilizes both virtual machines (VMs) and software containers to create a workflow system that establishes a uniform build and execution environment (BEE) beyond the capabilities of current systems. In this environment, applications will run reliably and repeatably across heterogeneous hardware and software. Containers, both commercial (Docker and Rocket) and open-source (LXC and LXD), define a runtime that isolates all software dependencies from the machine operating system. Workflows may contain multiple containers that run different operating systems, different software, and even different versions of the same software. We will run containers in open-source virtual machines (KVM) and emulators (QEMU) so that workflows run on any machine entirely in user-space. On this platform of containers and virtual machines, we will deliver workflow software that provides services, including repeatable execution, provenance, checkpointing, and future proofing. We will capture provenance about how containers were launched and how they interact to annotate workflows for repeatable and partial re-execution. We will coordinate the physical snapshots of virtual machines with parallel programming constructs, such as barriers, to automate checkpoint and restart. We will also integrate with HPC-specific container runtimes to gain access to accelerators and other specialized hardware to preserve native performance. Containers will link development to continuous integration. When application developers check code in, it will automatically be tested on a suite of different software and hardware architectures.

Guan, Qiang↗
DOE OSTI2019

Scaling the Summit: Deploying the World's Fastest Supercomputer

Summit, the latest flagship supercomputer deployed at Oak Ridge Leadership Computing Facility (OLCF), became the number one system in the Top500 list in June 2018 and remains in the top spot in the most recent edition of the list. An extensive acceptance test plan was developed to evaluate the unique features introduced in the Summit architecture and system software stack. The acceptance test also includes tests to ensure that the system is reliable, stable, and performant.

Melesse Vergara, Veronica↗
DOE OSTI2021

Geographic Mapping Tool for Power Systems

Power systems models are continuously updated to reflect changing infrastructure and modeling techniques. Open source geographic locations of power systems infrastructure do not include attributes that directly tie to electrical models. Moreover, relationships established between electric models and geospatial data sets do not apply to a future model because of nomenclature changes and architecture changes. The software titled “Geographic Mapping Tool for Power Systems” starts with a known set of locations, then runs multiple iterations to identify missing locations with a triangulation algorithm based on the branch connections and distances to the known locations.”

Snyder, Isabelle B↗
NASA NTRS2002

Multi-mission sequencing software

This paper describes the architecture of the JPL multi-mission sequencing system and demonstrates many of the benefits of the core/adaptation format of the sequencing software.

sequencing multi-mission↗
NASA NTRSDate not supplied

A Novel RF Architecture for Simultaneous Communication, Navigation, and Remote Sensing with Software-Defined Radio

The rapid growth of SmallSat and CubeSat missions at NASA has necessitated a re-evaluation of communication and remote-sensing architectures. Novel designs for CubeSat-sized single-board computers can now include larger Field-Programmable Gate Arrays (FPGAs) and faster System-on-Chip (SoCs) devices. These components substantially improve onboard processing capabilities so that varying subsystems no longer require an independent processor. By replacing individual Radio Frequency (RF) systems with a single software-defined radio (SDR) and processor, mission designers have greater control over reliability, performance, and efficiency. The presented architecture combines individual processing systems into a single design and establishes a modular SDR architecture capable of both remote-sensing and communication applications. This new approach based on a multi-input multi-output (MIMO) SDR features a scalable architecture optimized for Size, Weight, Power, and Cost (SWaP-C), with sufficient noise performance and phase-coherence to enable both remote-sensing and navigation applications, while providing a communication solution for simultaneous S-band and X-band transmission. This SDR design is developed around the NASA CubeSat Card Standard (CS2) that provides the required modularity through simplified backplane and interchangeable options for multiple radiation-hardened/tolerant processors. This architecture provides missions with a single platform for high-rate communication and a future platform to develop cognitive radio systems.

Advanced Avionics, Hybrid Processing, Data Process↗
DOE OSTI2015

IDC Reengineering Phase 2 Project Scope

The Comprehensive Nuclear-Test-Ban Treaty Organization (CTBTO) operates the International Data Centre (IDC) to support treaty verification activities by Member States. The IDC collects, stores, processes, and distributes data from seismic, hydroacoustic, infrasound, and radionuclide stations. A significant component of the IDC is the seismic, hydroacoustic, and infrasound (SHI) processing system. The IDC has recognized the need to reengineer the SHI processing system and has defined a three-phase reengineering effort. IDC Reengineering Phase 1 (RP1) started in 2011 with the goal to significantly modernize SHI automatic and interactive data processing software, focusing on enhancements to individual components of the system. Reengineering Phase 2 (RP2), started in 2014, addresses the task of specifying a unified architecture for all SHI software, across processing stages, to pave the way for further software development and sustainment in the future. A key objective of RP2 is an architecture sufficient to provide a basis for a cost estimate for the development or enhancement of the software components and subsystems. This report provides a brief description of the scope of the IDC Reengineering Phase 2 project. It describes the goals and objectives of reengineering, the system definition, and the technical scope of the system.This report expands upon the “Scope for IDC Reengineering Phase 2”, July 2014, ECS-DIS-WGB-43-PTS-MATERIAL-12-ADD-1, produced by the IDC.

58 GEOSCIENCES↗
NASA NTRS2004

Separating essentials from incidentals: an execution architecture for real-time control systems

This paper describes an execution architecture that makes such systems far more analyzable and verifiable by aggressive separation of concerns. The architecture separates two key software concerns: transformations of global state, as defined in pure functions; and sequencing/timing of transformations, as performed by an engine that enforces four prime invariants. The important advantage of this architecture, besides facilitating verification, is that it encourages formal specification of systems in a vocabulary that brings systems engineering closer to software engineering.

execution architecture↗
DOE OSTI2019

XScan: An Integrated Tool for Understanding Open Source Community-Based Scientific Code

Many scientific communities have adopted community-based models that integrate multiple components to simulate whole system dynamics. The community software projects’ complexity, stems from the integration of multiple individual software components that were developed under different application requirements and various machine architectures, has become a challenge for effective software system understanding and continuous software development. The paper presents an integrated software toolkit called X-ray Software Scanner (in abbreviation, XScan) for a better understanding of large-scale community-based scientific codes. Our software tool provides support to quickly summarize the overall information of scientific codes, including the number of lines of code, programming languages, external library dependencies, as well as architecture-dependent parallel software features. The XScan toolkit also realizes a static software analysis component to collect detailed structural information and provides an interactive visualization and analysis of the functions. We use a large-scale community-based Earth System Model to demonstrate the workflow, functions and visualization of the toolkit. We also discuss the application of advanced graph analytics techniques to assist software modular design and component refactoring.

Zheng, Weijian↗
DOE OSTI2020

Low cost, flexible, and distribution level universal grid analyser platform: designs and implementations

This study presents the designs and implementations of a distribution level open-universal grid analyser (Open-UGA) platform. The proposed Open-UGA platform consists of distribution-level phasor measurement units (PMUs), a standard signal generator, a router, and a server. Firstly, an overall introduction for the software, hardware, and server architectures of the Open-UGA platform is given. To give a detailed design, the software, hardware, server block diagrams, flowcharts, and printed circuit board photo of the Open-UGA platform are presented in detail. Then, four different types of distribution level PMU algorithms are introduced and implemented in the Open-UGA platform to verify the flexibility and reconfigurability. The flowcharts and functionalities of these four UGAs with different PMU algorithms are given as example implementations. Lastly, a performance comparison is conducted with both quantitative and illustrative results.

24 POWER TRANSMISSION AND DISTRIBUTION↗
NASA NTRS2007

NASA CEV Reference GN&C Architecture

The Orion Crew Exploration Vehicle (CEV) will be the first human spacecraft built by NASA in almost 3 decades and will be the first vehicle to perform both Low Earth Orbit (LEO) missions and lunar missions since Apollo. The awesome challenge of designing a Guidance, Navigation, and Control (GN&C) system for this vehicle that satisfies all of its various mission requirements is countered by the opportunity to take advantage of the improvements in algorithms, software, sensors, and other related GN&C technology over this period. This paper describes the CEV GN&C reference architecture developed to support the overall NASA reference configuration and validate the driving requirements of the Constellation (Cx) Architecture Requirements Document (CARD, Reference 1) and the CEV System Requirements Document (SRD, Reference 2). The Orion GN&C team designed the reference architecture based on the functional allocation of GN&C roles and responsibilities of CEV with respect to the other Cx vehicles, such as the Crew Launch Vehicle (CLV), Earth Departure Stage (EDS), and Lunar Surface Area Module (LSAM), across all flight phases. The specific challenges and responsibilities of the CEV GN&C system from launch pad to touchdown will be introduced along with an overview of the navigation sensor suite, its redundancy management, and flight software (FSW) architecture. Sensors will be discussed in terms of range of operation, data utility within the navigation system, and rationale for selection. The software architecture is illustrated via block diagrams, commensurate with the design aspects.

Tamblyn, Scott↗
NASA NTRS2005

Diagnosis and Prognosis of Weapon Systems

The Prognostics Framework is a set of software tools with an open architecture that affords a capability to integrate various prognostic software mechanisms and to provide information for operational and battlefield decision-making and logistical planning pertaining to weapon systems. The Prognostics NASA Tech Briefs, February 2005 17 Framework is also a system-level health -management software system that (1) receives data from performance- monitoring and built-in-test sensors and from other prognostic software and (2) processes the received data to derive a diagnosis and a prognosis for a weapon system. This software relates the diagnostic and prognostic information to the overall health of the system, to the ability of the system to perform specific missions, and to needed maintenance actions and maintenance resources. In the development of the Prognostics Framework, effort was focused primarily on extending previously developed model-based diagnostic-reasoning software to add prognostic reasoning capabilities, including capabilities to perform statistical analyses and to utilize information pertaining to deterioration of parts, failure modes, time sensitivity of measured values, mission criticality, historical data, and trends in measurement data. As thus extended, the software offers an overall health-monitoring capability.

Nolan, Mary↗
NASA NTRS2014

Ruby on Rails Issue Tracker

The purpose of this report is to detail the tasks accomplished as a NASA NIFS intern for the summer 2014 session. This internship opportunity is to develop an issue tracker Ruby on Rails web application to improve the communication of developmental anomalies between the Support Software Computer Software Configuration Item (CSCI) teams, System Build and Information Architecture. As many may know software development is an arduous, time consuming, collaborative effort. It involves nearly as much work designing, planning, collaborating, discussing, and resolving issues as effort expended in actual development. This internship opportunity was put in place to help alleviate the amount of time spent discussing issues such as bugs, missing tests, new requirements, and usability concerns that arise during development and throughout the life cycle of software applications once in production.

Ruby on Rails↗