Search NASA⌕ Search

SEARCH · Search NASA

Results for “Docker”

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.

47 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2021

Power Autonomy Research and Development Environment (PARDE) User’s Guide Version 0.1.2

This document is a user's guide for the Power Autonomy Research and Development Environment (PARDE) software package. PARDE is a version of NASA's Autonomous Power Control (APC) software that can be used to evaluate fault management and automatic power system reconfiguration algorithms in a relevant system without having to fully develop all the supporting software. Software items included are a set of C++ class source files representing simplified fault management and reconfiguration logic, a power system simulation representing a notional architecture for NASA's Gateway vehicle, a web-based graphical user interface for running and testing the simulation and APC, a Docker-based automatic setup script for a development environment, and a user's guide.

autonomous power control↗
NASA NTRSDate not supplied

Building Collaborative Proving Grounds for R2O2R – NASA/CCMC - NOAA/Space Weather Prediction Testbed (SWPT) Partnership

In 2016 and 2019, Executive Orders were signed by the President to prepare the Nation for Space Weather Events. At the forefront of being able to achieve this goal is the necessity to accelerate and enhance R2O2R. To drive this initiative, the Space Weather R2O2R Framework, initially led by NOAA and NASA, was developed. At the very center of the framework is the Space Weather Proving Grounds effort that will allow various institutions to collaborate, share, and advance their space weather modeling and simulation capabilities. The first of these Proving Grounds is the Architecture for Collaborative Evaluation (ACE) environment shared between the Community Coordinated Modeling Center (CCMC) at NASA and the Space Weather Prediction Testbed (SWPT) at NOAA. Since 2019, the ACE environment has been set up on the AWS cloud where it utilizes AWS cloud services and Docker containerization technology.

T. Tsui↗
NASA NTRS2022

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗
NASA NTRS2024

Exploring New Frontiers in Space Communications: Enhancing Delay Tolerant Networking through Cloud and Containerization

The High-rate Delay Tolerant Networking (HDTN) project at NASA Glenn Research Center has developed software that enables more flexible, reliable, and efficient space internetworking by using modern computing techniques such as cloud services, microservices, network function virtualization, software defined networking, and a distributed architecture. HDTN is built upon the Bundle Protocol and related convergence layers which have been developed to mitigate the challenges of the space networking environment including long delays, asymmetric data rates, and intermittent connectivity. The HDTN implementation employs asynchronous message processing tasks which allow for non-blocking operations as well as deployment in both centralized and distributed architectures. This paper investigates deploying HDTN in a containerized approach on the NASA Goddard’s Mission Cloud Platform using Amazon Web Services Elastic Compute Cloud (EC2). Commercial cloud computing will lower operating costs, provide flexible resource allocation, and allow for interconnectivity between multiple NASA centers as well as external partners. Containerization using Docker will enable greater portability and scalability for HDTN to be deployed into a variety of environments. We discuss possible NASA missions and use-cases such as the Laser Communications Relay Demonstration (LCRD) where the services provided by HDTN (reliable transport, high-rate message processing, and store-and-forward capabilities) will be enhanced through cloud computing and containerization. In addition, we describe the HDTN architecture and possible microservice-based networking approaches that can be obtained via HDTN’s configuration capabilities. Finally, we detail the EC2 specifications needed to achieve data rates greater than 1 Gbps to support optical communication missions such as LCRD.

Blake LaFuente↗
NASA NTRS2024

DSS Security Assessment

The Discovery and Synchronization service (DSS) has implemented some reasonable technical controls that help improve security and there are very few technical findings. The use of Docker and Kubernetes helps simplify the deployment process, and the DSS uses mutual TLS (mTLS) to connect. Much of the security risk across the DSS is a factor of its nature, a distributed environment that relies on all members to secure their parts correctly. As such, the DSS team should attempt to emphasize security controls that reduce complexity for securing entities’ Cockroach DB (CRDB) instances properly and improve coordination among DSS members for things like security patching, incident response, detecting, and removing bad actors. The DSS team must recognize that operating a DSS instance securely will require a combination of technical and procedural controls. Each DSS entity must configure their instance properly and follow standard operating procedures to ensure that the DSS service is secure.

threat modeling↗
DOE OSTI2025

Remote Instrumentation and Data Acquisition: An Internship Research Report

This report outlines the development and implementation of a remote data acquisition system for waveform analysis using a Rohde & Schwarz oscilloscope. The project involved capturing waveform data, and transferring it to a local machine for visualization and analysis. The core logic was developed in C++ with a focus on object oriented programming and the use of polymorphism so the main application can interact with any instrument without knowing its exact type, simplifying the overall logic and making it easier to add or swap out components without changing the rest of the codebase.. The system issues Standard Commands for Programmable Instruments (SCPI) via a socket connection and parses the oscilloscope’s ASCII waveform data. The C++ application was containerized using Docker for ease of portability, and reproducibility. Emphasis was placed on secure networking practices, error handling, and effective data capture. The report describes the technical steps taken, challenges encountered, and lessons learned, providing insight into the practical integration of hardware interfacing with remote computational environments.

Parikh, Jaymil [Fermilab]↗
DOE OSTI2025

DeepLynx Ecosystem 2025

Poor data integration and governance continue to plague complex engineering projects, resulting in missed cost, schedule, and performance targets. Departments operate in isolated systems with manual data exchange, creating fragmented information that compounds errors and leads to significant delays and cost overruns. The DeepLynx ecosystem addresses these challenges through an open-source, modular data management platform that transforms fragmented project data into an integrated digital thread. Built on a federated microservice architecture, the ecosystem comprises seven specialized tools centered around DeepLynx Nexus, a unified data catalog with hierarchical organization and graph-based navigation capabilities. The ecosystem includes: DeepLynx Stream for real-time timeseries data ingestion from industrial sources; DeepLynx Ingest for governed data uploads with formal review workflows; DeepLynx Lattice for ontology-based entity and relationship extraction; DeepLynx Run for workflow orchestration and secure AI/ML compute; DeepLynx Visualize for 3D digital twin visualization; and DeepLynx Insight for AI-assisted document analysis with traceable, grounded responses. Deployable in cloud, on-premise, or hybrid environments using containerized Docker applications and Helm charts, the DeepLynx ecosystem provides flexible infrastructure that adapts to organizational requirements. By consolidating project data into a unified data lake with role-based access controls and OAuth2 authentication, DeepLynx enables digital thread and digital twin capabilities that improve decision-making, reduce risk, and support complex engineering workflows throughout the project lifecycle.

42 - ENGINEERING↗
DOE OSTI2026

Modular Accelerator Robotics Framework Implementation For Accelerator Inspection

Accelerator tunnels, such as the ones at Fermilab, remain highly radioactive after beam shutoff due to induced radiation from the beam. This residual radiation creates a hazardous environment for manual inspection and repair of beamline components. To minimize worker radiation dose and reduce beam downtime, the AD Robotics Initiative previously built a fleet of low-cost custom mobile robots. However, the custom Python sockets server-client architecture lacked standardization, causing development delays and complicating the integration of new sensors and actuators. Here, we developed a modular system using ROS2 and Docker to standardize the teleoperation and control interfaces. This system was validated by implementing a teleoperation controller with real-time, low-latency, and high-definition video feedback. The aim of this framework is for a new feature or even a robot to be integrated into the system simply by documenting the hardware configuration. Current integration of LiDAR, Odometry, and Depth Cameras provides the foundation for Simultaneous Localization and Mapping (SLAM) tasks. Finally, future work involves integration into the accelerator control system and the attachment of a 6 degree-of-freedom robotic arm for telemanipulation.

Rayyan Khana, M. [Unlisted, US, IL] (ORCID:0009000↗
NASA NTRSDate not supplied

An Integrated Software Architecture for Solar Cruiser Mission Design and Navigation

Solar Cruiser is a solar sailing mission, riding as a secondary payload to the Interstellar Mapping and Acceleration Probe (IMAP) mission, expected to launch in February of 2025. The Solar Cruiser vehicle will generate thrust via a complex, low-thrust solar sail. The extreme low-thrust nature of the solar sail will leave Solar Cruiser highly sensitive to external environmental effects (such as solar radiation pressure and high-order gravitational perturbations) throughout the entirety of flight. Because of this, preliminary & operational optimization routines must be intricately tied to high-order predictive propagation models to ensure the greatest possible confidence in mission success. The Solar Cruiser Mission Design and Navigation (MDNav) team has designed a software tool suite, employing the latest in software containerization technology, to accomplish this task, allowing for seamless development across several users and operating systems. Combining JPL’s Monte toolkit with high-performance optimizers written by researchers at the University of Alabama, the proposed architecture allows for instant verification of optimized trajectories within the same development environment that the optimization takes place, removing the need for mission designers and navigators to switch between tools. The MDNav software suite itself is separated from the development and operational scripts to be used in flight, which allows for maintaining a low-footprint version control profile – thus avoiding unnecessary file bloating. This paper discusses the historical differences between previous iterations of the Solar Cruiser MDNav tool suite and the current iteration, planned operational interfaces of the tool with other software and subsystems, and the planned path forward in maintaining containerization services for the software throughout the lifetime of Solar Cruiser.

Containerization↗
NASA NTRSDate not supplied

An Integrated Software Architecture for Solar Cruiser Mission Design and Navigation

Solar Cruiser is a solar sailing mission, riding as a secondary payload to the Interstellar Mapping and Acceleration Probe (IMAP) mission, expected to launch in February of 2025. The Solar Cruiser vehicle will generate thrust via a complex, low-thrust solar sail. The extreme low-thrust nature of the solar sail will leave Solar Cruiser highly sensitive to external environmental effects (such as solar radiation pressure and high-order gravitational perturbations) throughout the entirety of flight. Because of this, preliminary & operational optimization routines must be intricately tied to high-order predictive propagation models to ensure the greatest possible confidence in mission success. The Solar Cruiser Mission Design and Navigation (MDNav) team has designed a software tool suite, employing the latest in software containerization technology, to accomplish this task, allowing for seamless development across several users and operating systems. Combining JPL’s Monte toolkit with University of Alabama’s high-performance optimizer, ASSET, the proposed architecture allows for instant verification of optimized trajectories within the same development environment that the optimization takes place, removing the need for mission designers and navigators to switch between tools. The MDNav software suite itself is separated from the development and operational scripts to be used in flight, which allows for maintaining a low-footprint version control profile – thus avoiding unnecessary file bloating. This paper discusses the historical differences between previous iterations of the Solar Cruiser MDNav tool suite and the current iteration, planned operational interfaces of the tool with other software and subsystems, and the planned path forward in maintaining containerization services for the software throughout the lifetime of Solar Cruiser.

solar cruiser↗
NASA NTRSDate not supplied

AAM NC ATI TechTalk - Aerograph Architecture v1

Aerograph is NASA’s data management system for Advanced Air Mobility. Its mission is to support AAM research by providing a reliable and secure system that collects, stores, protects, and shares AAM data. Its vision is to provide a system that AAM research scientists, aerospace engineers, data scientists, and analysts trust for obtaining NC data and performing key analyses. The types of data Aerograph manages involves data related to flight test events, including: Aircraft Performance and Characterization (e.g., position reports) Airspace (e.g., operation intent, waypoints, and constraints) Environment (e.g., surface and wind weather) Infrastructure (e.g., surveillance coverage) Derivative Analytical Artifacts (e.g., glide path performance chart, 3D position chart, Integrated Data Product)

Aerograph↗