Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Syntax”

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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRS2015

A Tool for Model-Based Generation of Scenario-driven Electric Power Load Profiles

Power consumption during all phases of spacecraft flight is of great interest to the aerospace community. As a result, significant analysis effort is exerted to understand the rates of electrical energy generation and consumption under many operational scenarios of the system. Previously, no standard tool existed for creating and maintaining a power equipment list (PEL) of spacecraft components that consume power, and no standard tool existed for generating power load profiles based on this PEL information during mission design phases. This paper presents the Scenario Power Load Analysis Tool (SPLAT) as a model-based systems engineering tool aiming to solve those problems. SPLAT is a plugin for MagicDraw (No Magic, Inc.) that aids in creating and maintaining a PEL, and also generates a power and temporal variable constraint set, in Maple language syntax, based on specified operational scenarios. The constraint set can be solved in Maple to show electric load profiles (i.e. power consumption from loads over time). SPLAT creates these load profiles from three modeled inputs: 1) a list of system components and their respective power modes, 2) a decomposition hierarchy of the system into these components, and 3) the specification of at least one scenario, which consists of temporal constraints on component power modes. In order to demonstrate how this information is represented in a system model, a notional example of a spacecraft planetary flyby is introduced. This example is also used to explain the overall functionality of SPLAT, and how this is used to generate electric power load profiles. Lastly, a cursory review of the usage of SPLAT on the Cold Atom Laboratory project is presented to show how the tool was used in an actual space hardware design application.

power load profile↗
NASA NTRS2017

Launch Control System Software Development System Automation Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administration's (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This system requires high quality testing that will measure and test the capabilities of the system. For the past two years, the Exploration and Operations Division at Kennedy Space Center (KSC) has assigned a group including interns and full-time engineers to develop automated tests to save the project time and money. The team worked on automating the testing process for the SCCS GUI that would use streamed simulated data from the testing servers to produce data, plots, statuses, etc. to the GUI. The software used to develop automated tests included an automated testing framework and an automation library. The automated testing framework has a tabular-style syntax, which means the functionality of a line of code must have the appropriate number of tabs for the line to function as intended. The header section contains either paths to custom resources or the names of libraries being used. The automation library contains functionality to automate anything that appears on a desired screen with the use of image recognition software to detect and control GUI components. The data section contains any data values strictly created for the current testing file. The body section holds the tests that are being run. The function section can include any number of functions that may be used by the current testing file or any other file that resources it. The resources and body section are required for all test files; the data and function sections can be left empty if the data values and functions being used are from a resourced library or another file. To help equip the automation team with better tools, the Project Lead of the Automated Testing Team, Jason Kapusta, assigned the task to install and train an optical character recognition (OCR) tool to Brandon Echols, a fellow intern, and I. The purpose of the OCR tool is to analyze an image and find the coordinates of any group of text. Some issues that arose while installing the OCR tool included the absence of certain libraries needed to train the tool and an outdated software version. We eventually resolved the issues and successfully installed the OCR tool. Training the tool required many images and different fonts and sizes, but in the end the tool learned to accurately decipher the text in the images and their coordinates. The OCR tool produced a file that contained significant metadata for each section of text, but only the text and coordinates of the text was required for our purpose. The team made a script to parse the information we wanted from the OCR file to a different file that would be used by automation functions within the automated framework. Since a majority of development and testing for the automated test cases for the GUI in question has been done using live simulated data on the workstations at the Launch Control Center (LCC), a large amount of progress has been made. As of this writing, about 60% of all of automated testing has been implemented. Additionally, the OCR tool will help make our automated tests more robust due to the tool's text recognition being highly scalable to different text fonts and text sizes. Soon we will have the whole test system automated, allowing for more full-time engineers working on development projects.

Automation↗
NASA NTRS2018

Trajectory Specification Language for Air Traffic Control

Trajectory Specification is a method of specifying aircraft trajectories with tolerances such that the position at any instant in time is constrained to a precisely defined bounding space. The bounding space at any instant in time is defined by tolerances relative to a reference trajectory that specifies position as a function of time. The tolerances are dynamic and are based on the aircraft navigation capabilities and the traffic situation. This paper proposes a standard Trajectory Specification Language (TSL) based on the Extensible Markup Language (XML) to represent these specifications and to communicate them by datalink. The language can be used to downlink trajectory requests from air to ground and to uplink trajectory assignments from ground to air. The XML format can be converted to binary for operational use, if necessary, using Efficient XML Interchange (EXI) or Abstract Syntax Notation (ASN.1).

XM↗
NASA NTRS2018

The Simple Assurance Argument Interchange Format (SAAIF) Manual

This document describes the Simple Assurance Argument Interchange Format, a proposed meta-model for describing structured assurance arguments. We describe the syntax and semantics of the model elements, compare the meta-model to existing argument formats, and give an example to illustrate its use.

Graydon, Patrick J.↗
NASA NTRS2020

Pattern Identification - A Foundation for Research in the Emphasis of Design Patterns in Systems Engineering and Knowledge Capture

Pattern Language describes the morphology and functionality of a system in the absence of design particulars. Harnessing this capability will provide the Systems Engineering discipline a means of managing the development of increasingly complex systems with increasingly distributed design teams while capturing and retaining knowledge for future generations. Pattern Language is a syntax for describing, and structurally relating, design patterns. Design patterns contextually describe the application of domain knowledge in the engineered solution to the force balance problem. The parallels between pattern recognition and application, as a fundamental stage of human learning, and pattern observation within a complex system, suggests pattern language may be a valuable tool in the capture and dissemination of knowledge. Pattern application has enjoyed considerable study over the last several decades, however much of this work has focused on the replication of design particulars. This work returns to the roots of Pattern Language and explores the utility of patterns as an architectural description and guide, and knowledge capture method, for complex system development beginning with the identification of a time proven design pattern.

Russell, Samuel P.↗
NASA NTRS2018

Runtime Verification: From Propositional to First-Order Temporal Logic

Runtime Verification is a branch of formal methods concerned with analysis of execution traces for the purpose of determining the state or general quality of the executing system. The field covers numerous approaches, one of which is specification-based runtime verification, where execution traces are checked against formal specifications. The paper presents syntax, semantics, and monitoring algorithms for respectively propositional and first-order temporal logics. In propositional logics the observed events in the execution trace are represented using atomic propositions, while first-order logic allows universal and existential quantification over data occurring as arguments in events. Monitoring of the first-order case is drastically more challenging than the propositional case, and we present a solution for this problem based on BDDs. We furthermore discuss monitorability of temporal properties by dividing them into different classes representing different degrees of monitorability.

Peled, Doron↗
NASA NTRS2019

Constraint-Based Off-Nominal Behavior Modeling for Europa Clipper

The risk analysis for the Europa Clipper mission evaluates the probability of mission failure based on the failure rates of individual components and dependencies among them. The probabilities are calculated by integrating over the intervals of time within which a fault occurs, accounting for an infinite number of cases. The response of the spacecraft to different faults can result in different schedules of activities, changing the intervals of integration. Europa currently uses models of spacecraft systems and components to simulate individual flight scenarios. The goal is to develop a framework for integrating, automating, and improving this modeling process. We describe an approach to generating the schedules for the different fault cases and determining the intervals for faults. It is not enough to just simulate individual cases because we are working with continuous variables that generate an infinite number of possible futures. Instead, we determine time windows within which certain faults can occur and use these time windows as bounds for integration. We found that determining these time windows is a constraint optimization problem. In order to represent these problems, we employ a language based on ontologies of behavior and scenarios. The language enables us to specify constraints in a simple, declarative syntax. A constraint-based analysis engine uses the declarative specification to identify bounds on system parameters and fill in details of behavior. For example, we created a detailed model of power generation, power use, and the corresponding effects on the battery in order to determine when an undervoltage fault can occur. An undervoltage during a trajectory correction maneuver requires that thrusting be interrupted for just enough time to recharge the battery such that the maneuver can be completed within battery limits. This behavior is generated based on the model to minimize the interruption time. For certain scenarios the constraint optimization problems were simple enough to be solved by hand, but the framework made the process substantially faster. It also produced solutions to other problems that we could not solve by hand or with existing tools and allowed us to generate and run many scenarios at once. The scenario language and engine greatly simplified the process of identifying time bounds and separating cases.

Everline, Chester J.↗
NASA NTRS2018

Definition of Modeling vs. Programming Languages

Modeling languages (like UML and SysML) are those used in modelbased specification of software-intensive systems. Like programming languages, they are defined using their syntax and semantics. However, both kinds of languages are defined by different communities, and in response to different requirements, which makes their methodologies and tools different. In this paper, we highlight the main differences between the definition methodologies of modeling and programming languages. We also discuss the impact of these differences on language tool support. We illustrate our ideas using examples from known programming and modeling languages. We also present a case study, where we analyze the definition of a new modeling language called the Ontology Modeling Language (OML). We highlight the requirements that have driven OML definition and explain how they are different from those driving typical programming languages. Finally, we discuss how these differences are being abstracted away using new language definition tools.

Elaasar, Maged↗
NASA NTRSDate not supplied

Venous Gas Embolism: Review to Quantify a Safe Volume of Air in Intravenous Fluids Bags for Spaceflight Applications

INTRODUCTION: The ability to create intravenous fluids (IVF) in-situ from the potable water supply of a spaceflight vehicle or habitat is a desired capability for an exploration medical system. In order to define an acceptable volume of air in IVF bags, an understanding of the volume of venous gas embolism as it relates to negative outcomes is needed. The purpose of this study is to review the literature to determine if there is a known volume of gas that contributes to mortality and/or morbidity that could be used to define requirements for rapid IVF infusion in microgravity. METHODS: A literature review was conducted of the PubMed database using the syntax: (Venous) AND (Gas OR Air) AND (Embolism) AND (Morbidity) AND (Mortality) AND (Volume) as well as manual review of references from relevant articles. 151 articles were screened excluding partial text and pediatric articles. Studies were reviewed for identification of volume of venous gas embolism associated with morbidity and/or mortality, which identified 27 articles. RESULTS: Reviewed literature included animal studies, case reports, and review articles. A high variation of proposed volumes contributing to mortality was reported. The limited human data values ranged from 20 ml to 200 ml of infused air with mortality estimated to be 48 – 80%. No studies evaluated human morbidity in any capacity. DISCUSSION: The lack of consensus on the safe volume of infused air has potential ramifications for IVF use in spaceflight as current technologies to create IVF from potable water may introduce air in IVF bags. While current microgravity infusion protocols call for the use of inline air removal filters, commercially available options have flow rate limitations that preclude rapid infusion in a resuscitation scenario. Such filters may be used in parallel to increase flow rate, but the time required to set up such a system may exclude its use during a medical emergency. Additionally, these consumable filters drive up the overall mass and volume of the medical system. Identification of a safe volume of air in IVF would allow for guidelines for the in-situ production of IVF in future spaceflight vehicles/habitats.

Christopher R Woodard↗
NASA NTRS2022

pyCRTM: A Python Interface for the Community Radiative Transfer Model

The Community Radiative Transfer Model (CRTM) is a powerful and versatile scalar radiative transfer model for satellite data assimilation and remote sensing applications. It is implemented as an object-oriented Fortran library, enabling flexible code development and optimal runtime performance on clusters. The downsides of the Fortran interface are a steep learning curve for students and the reduced productivity of users that is typical for static compiled languages, in contrast to dynamic interpreted languages like Python. pyCRTM is a new software framework that directly interfaces the CRTM Fortran data structures and procedures in Python, leveraging both the simplicity and ease of use of Python syntax as well as the flexibility arising from the vast contemporary Python ecosystem. The goal of pyCRTM is to lower the barrier of entry for university students to learn and use the CRTM and to boost the productivity of researchers seeking to create new methods in radiative transfer and data assimilation, or seeking to apply the CRTM to study atmospheric phenomena without having to go through the pre-existing complexity of the CRTM Fortran interface.

Python↗
NASA NTRS2022

Towards an Implementation of Differential Dynamic Logic in PVS

This paper describes an ongoing effort to embed and verify differential dynamic logic (dL) in the Prototype Verification System (PVS). dL is a logic for specifying and formally reasoning about hybrid systems, which employ both continuous and discrete dynamics. There are several benefits of this effort. First, the embedding of dL in PVS offers an independent formal verification of the semantics and rules of dL. Second, the embedding is fully operational within PVS, giving PVS practitioners the ability to use dL in the formal specification and verification process. Third, the rich specification language, type system, and powerful interactive prover of PVS can be used on dL objects. In addition to the embedding and verification of dL, a custom extension for Visual Studio Code has been developed, so that a stylized dL syntax can be used to specify hybrid programs and their properties.

Differential Dynamic Logic↗
NASA NTRS2022

Revisiting the Solar Research Cyberinfrastructure Needs: A White Paper of Findings and Recommendations

Solar and Heliosphere physics are areas of remarkable data-driven discoveries. Recent advances in high cadence, high-resolution multiwavelength observations, growing amounts of data from realistic modeling, and operational needs for uninterrupted science-quality data coverage generate the demand for a solar metadata standardization and overall healthy data infrastructure. This white paper is prepared as an effort of the working group “Uniform Semantics and Syntax of Solar Observations and Events” created within the “Towards Integration of Heliophysics Data, Modeling, and Analysis Tools” EarthCube Research Coordination Network (@HDMIEC RCN), with primary objectives to discuss current advances and identify future needs for the solar research cyberinfrastructure. The white paper summarizes presentations and discussions held during the special working group session at the EarthCube Annual Meeting on June 19th, 2020, as well as community contribution gathered during a series of preceding workshops and subsequent RCN working group sessions. The authors provide examples of the current standing of the solar research cyberinfrastructure, and describe the problems related to current data handling approaches. The list of the top-level recommendations agreed by the authors of the current white paper is presented at the beginning of the paper.

SMD↗
NASA NTRSDate not supplied

Generic Programming in Fortran 202Y

Back in 2018, the Fortran committee began planning new features for what is now expected to be Fortran 2023, "generic programming" was at the top of the list of requests from the user community. Here, generic programming refers to the ability to specify algorithms that are parameterized in terms of deferred _types_ (as opposed to values). Concrete algorithms are subsequently generated when the generic algorithms are "instantiated" with specific types. After significant consideration the language committee decided that the necessary changes to Fortran to support generic programming would be too large and complex to complete within a single release cycle of the standard. Instead, a new "generics" subgroup was formed with myself as the lead, and we were charged with developing generic programming features for the subsequent release _after_ the F2023, internally referred to as Fortran 202Y. I.e, the new subgroup was provided the luxury of developing the new capabilities across two full release cycles of the standard. This talk will describe the current approach to generics being pursued by the subgroup as well as the current status halfway through the development cycle. I will conclude with some motivating examples implemented with notional syntax.

Fortran↗
NASA NTRS2022

FPP: A Modeling Language for F Prime

We present F Prime Prime (FPP), a new open-source modeling language for F Prime. F Prime is an open-source flight software framework developed at JPL and deployed, among other places, on the Mars helicopter Ingenuity. FPP provides a convenient way to model the architectural elements of an F Prime application, e.g., components, ports, and their connections. It has a succinct and readable syntax, a well- defined semantics, and robust error checking and reporting. The FPP tool suite, written in Scala, analyzes FPP models, reports errors, and translates correct FPP models to a combination of XML and C++. Existing F Prime tools translate the XML to a partial implementation in C++, to be completed by the developers. The model elements have clean interfaces and are highly reusable. An accompanying visualization tool constructs diagrams of components and connections that FSW developers can use to understand and communicate their designs, for ex- ample at reviews. We discuss the design and implementation of FPP and the integration of FPP into F Prime. We also discuss our experience using FPP to construct F Prime models. Finally, we discuss our plans for future work, including improved code generation, improved visualization, and more advanced analysis capabilities.

Starch, Michael D.↗
NASA NTRSDate not supplied

Using Kamodo for CCMC ITM Output and Beyond

Kamodo is an official NASA open source python software package that functionalizes diverse datasets from models and observations in a consistent way, enabling advanced scientific analysis and visualization with simplistic syntax. Here we demonstrate this ability using several ITM models available through the Community Coordinated Modeling Center (CCMC). Users can now interact directly with model outputs, and satellites can be virtually flown through model output to allow many types of model/model and data/model comparisons. We will also provide information about significant updates and improvements to Kamodo and future plans.

Open Source Software↗
NASA NTRS2022

Kamodo’s Model-Agnostic Satellite Flythrough: Lowering the Utilization Barrier for Heliophysics Model Outputs

Heliophysics model outputs are increasingly accessible, but typically are not usable by the majority of the community unless directly collaborating with the relevant model developers. Prohibitive factors include complex file output formats, cryptic metadata, unspecified and often customized coordinate systems, and non-linear coordinate grids. Some pockets of progress exist, giving interfaces to various simulation outputs, but only for a small set of outputs and typically not with open-source, freely available packages. Additionally, the increasing array of tools built upon these sporadic interfaces are typically model-specific. We present Kamodo’s model-agnostic satellite flythrough capabilities as the solution to the utilization barrier for heliophysics model outputs. Developed at the Community Coordinated Modeling Center, these flythrough capabilities are built in Python upon a network of model-agnostic interfaces developed in collaboration with model developers, providing interpolation results the community can trust. Kamodo’s flythrough capabilities present the user with a growing variety of flythrough tools based upon a rapidly expanding library of heliophysics model outputs in several domains, currently including a variety of Ionosphere-Thermosphere-Mesosphere and global magnetosphere model outputs. Each capability is designed to be easily accessible via simplistic model-agnostic syntax, with the entire package freely available in the cloud on Github. Here, we describe the tools developed, include several sample applications for common science questions, demonstrate interoperability with selected packages, and summarize ongoing developments.

Software↗
NASA NTRSDate not supplied

RadLab and the Environmental Data Application Dashboard: Graphical and Programming Interfaces for Interrogation of Space Telemetry Data

Sensors on the International Space Station (ISS) and multiple spacecraft elsewhere in Earth orbit and in deep space continuously monitor and collect environmental data, transmitting this information back to Earth. These data include ionizing radiation and, on the ISS, CO2, relative humidity levels, and temperature, and are of great importance to space biology research. Ionizing radiation in particular has been established in ground-based experiments as being correlated with increased risk of carcinogenesis and cardiovascular and neurological effects. Looking ahead to future long duration crewed missions beyond low Earth orbit, the ability to study how factors including CO2 levels, light cycle, temperature modulate the response to ionizing radiation and microgravity is essential. To date, access to these data has been fragmented across space agencies, spacecraft, and databases. To address this issue, NASA’s Open Science Data Repository (osdr.nasa.gov) has developed two Web applications: the Environmental Data Application (EDA) and a radiation-specific RadLab. Each consists of an API (application programming interface) and an associated GUI (graphical user interface) that provide single points of access to the data. To date, OSDR has focused on the sensors from payloads and radiation detectors located on the ISS. The Web applications process telemetry information and associated data, such as spacecraft location and orientation, from multiple international databases. The applications’ request syntax enables users to interrogate these data by craft, sensor type, time range, radiation type (galactic cosmic rays, solar particle events, the contribution of the South Atlantic Anomaly), facilitating arbitrary comparisons of original source data at varying time resolutions. The applications provide programmatic access for use in computational pipelines and GUIs for data visualization and exploration, making these data FAIR (Findable, Accessible, Interoperable, and Reusable), complementing the biological data contained in OSDR, and providing the space science community with a valuable resource for scientific analyses.

radiation↗
NASA NTRSDate not supplied

RadLab: Graphical and Programming Interfaces for Interrogation of Space Telemetry Data

Sensors on multiple spacecraft in and beyond low Earth orbit continuously monitor and collect space radiation data and transmit it back to Earth. These data are of vast importance to space biology research, as ionizing radiation affects living organisms—astronauts and non-human experiment subjects alike—placing them at higher risk of carcinogenesis, degenerative diseases, and radiation sickness. Therefore, knowledge of the biological effects of space radiation is essential for planning future crewed missions beyond low Earth orbit. The RadLab project, initiated by GeneLab and ALSDA (the Open Science Data Repository; OSDR) and sponsored by the NASA Human Research Program, is a new effort aimed at connecting dosimetry data from radiation detectors located on the International Space Station (ISS), as well as other spacecraft. To date, access to these data has been fragmented across space agencies and databases; to address this issue, we have developed an application programming interface (API) and an associated graphical user interface (GUI) designed to provide a single point of access to the data. As of now, OSDR has focused on the detectors located on the ISS, with the long-term goal to establish a self-sustained portal receiving continuous updates through APIs connecting to multiple radiation databases of varying scope, as well as individual investigator contributions. The RadLab API implements a request syntax enabling users to query data by craft, sensor type, timespan, etc, allowing for arbitrary combinations of original source data, thus providing programmatic access for use in computational pipelines, while the GUI facilitates data visualization and exploration, making these data FAIR (Findable, Accessible, Interoperable, and Reusable), complementing the biological data contained in OSDR, and providing the space science community with a valuable resource for scientific analyses.

radiation↗