Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “JSON”

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.

157 records · Page 9
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

CFS Test Framework

NASA's Core Flight System (cFS) provides a generic flight software framework architecture for developing flight software. As the cFS framework has gained popularity over the years within the flight software community, supporting software tools have been developed to assist in the design, development, testing and verification of flight software. The cFS Test Framework (CTF) is a recently developed cFS tool with capabilities to develop and run automated test and verification scripts against flight software targets. The CTF tool parses and executes JSON-based test scripts containing test instructions, while logging and reporting the results. CTF utilizes a plugin-based architecture to allow developers to extend CTF with new test instructions, external interfaces, and custom functionality. To interface with flight software, CTF parses a set of CCSDS message definition files to create the necessary command and telemetry structures for use during the test run. Additionally, CTF also supports interfacing with multiple cFS instances, allowing a test script to verify requirements that involve multiple flight software targets. Lastly, CTF provides support for executing test scripts against FSW running on remote or embedded hardware. This allows CTF to execute the same test scripts across different target configurations throughout the development process. In this presentation, we will introduce the cFS Test Framework (CTF) architecture, discuss the history of cFS testing frameworks, and present the features and capabilities currently provided by CTF. Lastly, we will show a demo of the CTF tool being used to execute test scripts against flight software.

cfs↗
NASA NTRSDate not supplied

Benefits of using Electronic Data Sheets (EDS) with coreFlight Systems (cFS) - A Project Example

Recently there has been interest in the incorporation of core Flight Systems (cFS) with Spacecraft Onboard Interface Services (SOIS) Electronic Data Sheets (EDS) in the spaceflight software community. The Regenerative Fuel Cell project at the Glenn Research Center is using cFS architecture with EDS support for its monitoring and control software. The presentation will outline the benefits to using cFS with EDS support: First, EDS establishes a single source of truth for the definitions of data structures used throughout an entire mission that may otherwise be programmed in different languages and designed with different processor architectures. Not only does this help with inter-application communication via the software bus, but it also greatly simplifies communication between systems. An EDS Application Programming Interface (API) library allows the conversion of EDS data structures to and from native data structures. Second, bindings for other programming languages (e.g. Lua, Python, JSON) have been written to allow the creation and manipulation of EDS data objects within those languages. The RFC project uses Lua scripts to automatically generate binary configuration files at build time to be loaded into our cFS programs. We also use Python bindings in a graphical user interface (GUI) to allow an operator to send commands and view telemetry messages sent from cFS instances. Finally, using Lua scripts we can set up specific simulation scenarios to perform automatic functional testing. During the development of the RFC software, the software team put together a generic python GUI called “cFS-EDS-GroundStation” that provides a basic interface to an instance of cFS with EDS support. The GUI includes a basic telecommand and telemetry system that reads directly from the generated EDS databases. In the telecommand system, dropdown menus are populated with all user commands that are defined in EDS. In the telemetry system, telemetry messages are automatically decoded, written to the screen, and saved to a binary file. Additional Python scripts have been written to convert the binary data files into a comma separated value (CSV) format for further processing. We will demonstrate the basic use of the cFS-EDS-GroundStation software including adding additional commands and telemetry payload values in EDS and see them appear automatically in the cFS-EDS-Groundstation software. About the RFC project: The Regenerative Fuel Cell project is tasked with developing and demonstrating a power system consisting of a fuel cell and electrolyzer to provide power during a lunar day/night cycle. During the night, the fuel cell takes Hydrogen and Oxygen gasses and converts them into electricity, water, and heat. During the day, the electrolyzer takes input power (e.g. from a photovoltaic array) and converts water back into Hydrogen and Oxygen gasses.

Mathew Mccaskey↗
NASA NTRSDate not supplied

A New Architecture for Parallelization of Complex Spacecraft Trajectory Optimization Scans

This paper describes CopScanner, a new component of the Copernicus ecosystem for spacecraft trajectory design and optimization. CopScanner is a Python library being developed at the NASA JSC which enables easy parallelization of Copernicus scans. CopScanner is currently being developed and implemented for production of Copernicus trajectory scans for upcoming Artemis Missions (Artemis II and beyond). On the backend, CopScanner utilizes Dask, an open-source Python library for parallel computing which enables parallelization over both multi-core local machines and large-scale distributed computing clusters. CopScanner abstracts the trajectory scanning process into a DAG which is constructed using a chain of individual subscans. Each node in the DAG executes a python module, called the callable, for which there are built-in defaults, or users may specify their own. Support for custom callables makes CopScanner a versatile trajectory optimization software. All output files and associated metadata from a CopScanner scan are compressed and stored in a two-file output, collectively called the FileStore, consisting of a SQLite database and a compressed JSON MessagePack file, for which CopScanner provides a Python class for interaction.

Quentin Moore↗
NASA NTRSDate not supplied

The TOLNet 2.0 Website: How an API Can Promote Open Science and FAIR Principles

The Tropospheric Ozone Lidar Network (TOLNet) has generated over a decade of ozone vertical profile data products over North America. The science value of the TOLNet data has been demonstrated in numerous peer-reviewed publications on air quality and other ozone relevant research. To support the broad spectrum of data use, the TOLNet team launched a major effort to upgrade the web-based data repository aiming to enhance the data discoverability and to enable machine-to-machine data upload and download processes. Specifically, the TOLNet website included an application programming interface (API), which supports machine-to-machine data search and data download. The API also extracts selected variables from the files, which can be retrieved as JSON objects and used to create data displays without having to download or open the underlying files. The TOLNet science team members can also use the API for automated data upload, including a data file scanning feature to ensure data product integrity. To be presented will include a summary of key features of data repositories, an actual use case of machine-to-machine data access/use, as well as our journey to make TOLNet data more FAIR, i.e., more findable, accessible, interoperable, and (re)usable.

Crystal Gummo↗
DOE OSTI2024

AI in Science Communication

Generative AI has brought great innovations across multiple fields, offering great tools for enhanced communication and efficiency. This project focused on developing a custom AI chatbot using OpenAI's Chat GPT (GPT-4o) to support the Fermilab communications team. An analysis identified Chat GPT as the optimal choice, leading to the adoption of its team version and the implementation of a real-time JSON schema for website scanning. Four distinct personas were created to tailor responses to specific audiences, and Fermilab's published content was uploaded to ensure tone consistency. The training involved iterative prompt trials, resulting in a responsive and effective communication assistant. Initial evaluations indicate that the custom GPT shows promise.

Valle, Diego↗
DOE OSTI2024

Zapiary: Creating Visibility in IOT Networks

Zigbee and Z-Wave are the main networking protocols used by low-power Internet of Things (IOT) devices. These protocols use low frequencies. Mesh architecture, and unique address formats that make them not compatible with traditional network traffic tools like IX-Discovery Tools. Zapiary is a software that takes CSV files with Zigbee and Z-Wave traffic and generates Structured Threat Information eXpression (STIX) JSON bundles illustrating the communication within IOT networks. The bundles can then be viewed within Structured Threat Intelligence Graph (STIG) or used with AI/ML models to provide deeper visibility into nodes that make up the network and the ability to trend the mesh network over time.

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2025

CMS Token Transition

Within the LHC community, a momentous transition has been occurring in authorization. For nearly 20 years, services within the Worldwide LHC Computing Grid (WLCG) have authorized based on mapping an identity, derived from an X.509 credential, or a group/role, derived from a VOMS extension issued by the experiment. A fundamental shift is occurring to capabilities: the credential, a bearer token, asserts the authorizations of the bearer, not the identity. By the HL-LHC era, the CMS experiment plans for the transition to tokens, based on the WLCG Common JSON Web Token profile, to be complete. Services in the technology architecture include the INDIGO Identity and Access Management server to issue tokens; a HashiCorp Vault server to store and refresh access tokens for users and jobs; a managed token bastion server to push credentials to the HTCondor CredMon service; and HTCondor to maintain valid tokens in long-running batch jobs. We will describe the transition plans of the experiment, current status, configuration of the central authorization server, lessons learned in commissioning token-based access with sites, and operational experience using tokens for both job submissions and file transfers.

43 PARTICLE ACCELERATORS↗
DOE OSTI2025

Fermilab's Transition to Token Authentication

Fermilab is the first High Energy Physics institution to transition from X.509 user certificates to authentication tokens in production systems. All the experiments that Fermilab hosts are now using JSON Web Token (JWT) access tokens in their grid jobs. Many software components have been either updated or created for this transition, and most of the software is available to others as open source. The tokens are defined using the WLCG Common JWT Profile. Token attributes for all the tokens are stored in the Fermilab FERRY system which generates the configuration for the CILogon token issuer. High security-value refresh tokens are stored in Hashicorp Vault configured by htvault-config, and JWT access tokens are requested by the htgettoken client through its integration with HTCondor. The Fermilab job submission system jobsub was redesigned to be a lightweight wrapper around HTCondor. The grid workload management system GlideinWMS which is also based on HTCondor was updated to use tokens for pilot job submission. For automated job submissions a managed tokens service was created to reduce duplication of effort and knowledge of how to securely keep tokens active. The existing Fermilab file transfer tool ifdh was updated to work seamlessly with tokens, as well as the Fermilab POMS (Production Operations Management System) which is used to manage automatic job submission and the RCDS (Rapid Code Distribution System) which is used to distribute analysis code via the CernVM FileSystem. The dCache storage system was reconfigured to accept tokens for authentication in place of X.509 proxy certificates. As some services and sites have not yet implemented token support, proxy certificates are still sent with jobs for backwards compatibility, but some experiments are beginning to transition to stop using them.

Dykstra, Dave [Fermilab] (ORCID:0000000326539015)↗
DOE OSTI2025

A Managed Tokens Service for Securely Keeping and Distributing Grid Tokens

Fermilab is transitioning authentication and authorization for grid operations to using bearer tokens based on the WLCG Common JWT (JSON Web Token) Profile. One of the functionalities that Fermilab experimenters rely on is the ability to automate batch job submission, which in turn depends on the ability to securely refresh and distribute the necessary credentials to experiment job submit points. Thus, with the transition to using tokens for grid operations, we needed to create a service that would obtain, refresh, and distribute tokens for experimenters' use. This service would avoid the need for experimenters to be experts in obtaining their own tokens and would better protect the most sensitive long-lived credentials. Further, the service needed to be widely scalable, as Fermilab hosts many experiments, each of which would need their own credentials. To address these issues, we created and deployed a Managed Tokens Service. The service is written in Go, taking advantage of that language's native concurrency primitives to easily be able to scale operations as we onboard experiments. The service uses as its first credentials a set of kerberos keytabs, stored on the same secure machine that the Managed Tokens service runs on. These kerberos credentials allow the service to use htgettoken via condor_vault_storer to store vault tokens in the HTCondor credential managers (credds) that run on the batch system scheduler machines (HTCondor schedds); as well as downloading a local, shorter-lived copy of the vault token. The kerberos credentials are then also used to distribute copies of the locally-stored vault tokens to experiment submit points.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
DOE OSTI2026

An Autonomous MCP Bridge to Rucio: Enhancing Data Management Accessibility for High Energy Physics

The Rucio Data Management System [1] is an important tool used by High Energy Physics experiments, including those at Fermi National Accelerator Laboratory, to store and manage exabyte-scale scientific datasets. Despite its central role in coordinating data across globally distributed storage sites, Rucio's command line interface (CLI) presents a steep learning curve, and makes it difficult for scientists to navigate through. To solve this issue, a containerized Model Context Protocol (MCP) [2] server was built that connects Large Language Models directly to Rucio, allowing AI agents to handle data tasks by using simple, natural language rather than memorized terminal commands. The core engineering focus of this project was moving the server away from slow terminal commands that require text parsing and replacing them with a native Python Client API toolset and a planned REST API framework. Moving to the Python API handles data operations directly in memory, which helps clear up formatting errors, provides the AI with clean, structured JSON data and speeds up tool execution. To prove that the system actually works, a benchmarking pipeline was also built with various questions to test the AI across four different model configurations. The questions included finding data scopes, tracking down specific datasets, and checking replication rules. Through benchmarking, early runs showed that with raw terminal text, the model would get confused and stuck, whereas switching to the Python API to feed the AI clean, structured data yielded massive improvement. By creating an intelligent and autonomous bridge to a storage network, this project shows how AI can be implemented in scientific data management, which ultimately helps scientists at Fermilab spend less time sorting through data and more time focusing on their experiments and analysis.

Akella, Kashyap [William Rainey Harper Coll.]↗
DOE OSTI2022

Supply Chain Risk Management: Data Structuring

Supply chain risk management (SCRM) is an area of research that addresses both logistics concepts to maximize efficiency, reliability, and revenue as well as risk features, such as potential weak points, break points, and vulnerabilities within the supply chain. SCRM is used to find risks introduced at each node in a supply chain and how these risks can impact a company’s products, individuals, customers, and reputation. SCRM is a relatively new field, so standardized processes including data structuring are not fully documented. This paper explains the importance of a standard data structuring methodology and how it can enhance current SCRM efforts. Data ingest, structuring, and analysis are predominantly managed by humans. Automating some of the less complex steps can positively impact SCRM by allowing human analysts to focus on more strategic analyses. Types of data to be collected and structured are collected via publicly available information related to hardware, software, and corporate entities. After the data has been collected, the information is formatted in a specific manner, conforming to a schema, to allow for more effective and efficient ingest for further analysis. This paper outlines data structures used by Pacific Northwest National Laboratory for SCRM research and analysis purposes. These structures have been used for hundreds of analyses and have been successful in developing a common baseline. Data structuring is one of the first steps in data standardization, which will further mature and enhance the SCRM research area.

supply chain risk management, data structuring, re↗
DOE OSTI2022

System Modeling Frameworks for Wind Turbines and Plants: Review and Requirements Specifications

System modeling frameworks for wind turbines and plants are used by research groups and industry to design wind energy systems that take into account key trade-offs across performance, cost, and reliability at both the turbine and plant level. The frameworks are exercised using a variety of multi-disciplinary design, analysis and optimization (MDAO) methods. To improve inter-operability and foster collaboration, this report proposes a classification system for the frameworks along dimensions of model fidelity and scope. The classification system is first motivated with reviews the state-of-the-art in the development of software frameworks for integrated wind turbine and plant simulation. Within each major wind turbine and power plant subsystem, a matrix is developed for the disciplines used and the fidelity levels with which each discipline can be modeled. The existing frameworks are then classified according to the matrix. Next, an ontology is proposed that will allow for standardizing how data is transferred between the most common discipline-fidelity combinations used in the frameworks. A common representation of data creates the ability to 1) share system descriptions and analysis results, supporting more transparent benchmarks and comparison, and 2) integrate models together into workflows within and across organizations for improving the efficiency and performance of wind turbine and power plant design processes. Ultimately, this integration leads to better overall wind energy system designs with high performance and low costs.

17 WIND ENERGY↗