Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “dataflow”

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.

43 records · Page 3

Transitioning the NASA SLR Network to Event Timing Mode for Reduced Systematics, Improved Stability and Data Precision

NASA's legacy Satellite Laser Ranging (SLR) network produces about one-third of the global SLR data to support spacegeodesy. This network of globally distributed stations has been using Time Interval Units (TIU) for range measurements for thelast 25 + years. To improve the reliability of the SLR network and satisfy the need for stable millimeter precision data, a phasedreplacement of the TIUs in the network with picosecond-precise Event Timer Modules was initiated in 2015. This schemeallowed the time of flight and laser transmit epoch measurement to one picosecond resolution. For a network with globalscientific impact, transitioning to a new data generation metrological scheme requires significant data scrutiny and long-termscience data validation. Any long-term testing/measurement has the potential to interrupt the station's daily operational dataflow to the International Laser Ranging Service (ILRS) as the station under test will have to put its test data into quarantine.We have demonstrated a very effective way to test and implement the new device without removing the old hardware andwithout the need for the orbit analysis. This operationally noninvasive scheme performed concurrent test measurements enablinguninterrupted operational data flow to the users, while allowing simultaneous test data capture for short- and long-termsystematics and stability analysis. Extensive analysis of the test data was performed by the NASA SLR engineering team andthe ILRS Analysis Standing Committee, to uncover biases and any dependencies on the satellite ranges (for nonlinear scaleissues). Multi-ETM comparison was also performed at two of the SLR stations through the interchange of hardware to establishthe inter-device range biases and stability. Such benchmarked hardware was subsequently sent to the remaining stationsto allow traceability and normalize the network performance. The range bias intercomparison performed using the multiyearSLR data analysis agreed well with the engineering changes, thus validating the approach to flush out station-specific rangingsystematics affecting precise orbit determination. Such an improvement and rebalancing of the current network will allowan orderly transition of the current NASA SLR network operating at a maximum rate of 10 Hz to the NASA next generationSpace Geodesy Satellite Laser Ranging (SGSLR) network operating at 2 kHz (McGarry et al. in J Geod, 2018. https ://doi.org/10.1007/s0019 0-018-1191-6; Merkowitz et al. in J Geod, 2018. https ://doi.org/10.1007/s0019 0-018-1204-5).

Varghese, Thomas↗

CoCoSim, a Code Generation Framework for Control/command Applications: An Overview of CoCoSim for Multi-Periodic Discrete Simulink Models

We present CoCoSim, a framework to support the design, code generation and analysis of discrete dataflow model expressed in Simulink. In this work, we specifically focus on the analysis and code generation of multi-periodic systems. For that CoCoSim provides two complementary approaches: the first amounts to encode the multiperiodic semantics in a pure-synchronous one – à la Lustre–, enabling the use of model checker for verifying properties. The second provides a faithful code generation into multiple communicating (mono)synchronous components – à la Prelude– that can be then simulated or embedded in the final platform with any real-time scheduler. These approaches have been experimented in various settings.

Bourbouh, Hamza↗

Bridging the Gap Between Requirements and Model Analysis : Evaluation on Ten Cyber-Physical Challenge Problems

Formal verfication and simulation are powerful tools to validate requirements against complex systems. [Problem] Requirements are developed in early stages of the software lifecycle and are typically written in ambiguous natural language. There is a gap between such requirements and formal notations that can be used by verification tools, and lack of support for proper association of requirements with software artifacts for verification. [Principal idea] We propose to write requirements in an intuitive, structured natural language with formal semantics, and to support formalization and model/code verification as a smooth, well-integrated process. [Contribution] We have developed an end-to-end, open source requirements analysis framework that checks Simulink models against requirements written in structured natural language. Our framework is built in the Formal Requirements Elicitation Tool (fret); we use fret's requirements language named fretish, and formalization of fretish requirements in temporal logics. Our proposed framework contributes the following features: 1) automatic extraction of Simulink model information and association of fretish requirements with target model signals and components; 2) translation of temporal logic formulas into synchronous dataflow cocospec specifications as well as Simulink monitors, to be used by verification tools; we establish correctness of our translation through extensive automated testing; 3) interpretation of counterexamples produced by verification tools back at requirements level. These features support a tight integration and feedback loop between high level requirements and their analysis. We demonstrate our approach on a major case study: the Ten Lockheed Martin Cyber-Physical, aerospace-inspired challenge problems.

Mavridou, Anastasia↗

A Web Based Collaborative Design Environment for Spacecraft

In this era of shrinking federal budgets in the USA we need to dramatically improve our efficiency in the spacecraft engineering design process. We have come up with a method which captures much of the experts's expertise in a dataflow design graph.

collaborative↗

Gateway Command and Data Handling Network Implementation and Validation

As initial Lunar Gateway modules approach design maturity, the Artemis Network Validation and Integration Lab (ANVIL) has begun demonstrations to validate avionics network dataflows. The flight architecture design includes utilizing Time-Triggered Ethernet (TTE) and layer-3 switching capabilities to enable greater automation and flexibility of critical and best effort traffic. Critical traffic is considered as Time-Triggered (TT), Rate Constrained (RC) and prioritized Best Effort (BE) traffic classes. End systems, such as mission computers, power control, and robotics, use three planes and all traffic classes while other devices interface via Best Effort. Typical best effort devices include video, laptops, wireless access points, and payloads. Other devices have a various hybrid approach of interfaces including alarms, telemetry/logging, and communication units. In the paper, we will present an update of the Gateway network architecture and how the system will operate nominally and during a stack topology reconfiguration. We will also discuss the network risks, and trade-offs of performance, flexibility, and redundancy. Finally, we will show the process for validation, demonstration, and verification approaches to the vehicle network.

Gateway↗

Earth Science Data Processing With Nextflow

Earth science data processing tasks present many challenges. These tasks often process large input datasets and require scores of CPU-hours to generate results. All but the simplest tasks will be decomposed into a series of computational or data manipulation steps, also known as a scientific workflow. In order to reduce the burden of orchestrating and running the dependent processing steps, a workflow execution engine is required. This poster describes the lessons learned by the CLARREO Pathfinder (CPF) team while developing multiple scientific workflows and utilizing the open-source Nextflow engine to execute them in a cloud computing environment. The Nextflow engine is designed with the following stated goals: first, the engine does not dictate how individual steps in the task are implemented (i.e. it is language and interface agnostic); second, the engine supports easy configuration and modularity at the workflow level so that others can easily execute our workflows to reproduce results; lastly, the engine eases development by transparently scaling execution from local to remote environments. Nextflow was developed for the bioinformatics domain but is a good fit for other scientific workflows where the overall task is well-described by a dataflow diagram. The CPF team has developed Nextflow pipelines (i.e. scientific workflows) to simulate CLARREO radiance, generate large look-up tables for inter-calibration algorithms, and generate L4 intercalibration data products. These pipelines consume from single-digits to hundreds of thousands of CPU-hours. In the development and evolution of these pipelines we have discovered many design patterns, pitfalls, and solutions to common problems. Our goal is to demonstrate important aspects of how to design, implement, run, and ultimately share Nextflow pipelines in the domain of Earth science.

Aron D Bartle↗

The Essence of Reactivity

Reactive programming, functional reactive programming, event-based programming, stream programming, and temporal logic all share an underlying commonality: values can vary over time. These languages differ in multiple ways, including the nature of time itself (e.g., continuous or discrete, dense or sparse, implicit or explicit), on how much of the past and future can be referenced, on the kinds of values that can be represented, as well as the mechanisms used to evaluate expressions or formulas. This paper presents a series of abstractions that capture the essence of different forms of time variance. By separating the aspects that differentiate each family of formalisms, we can better express the commonalities and differences between them. We demonstrate our work with a prototype in Haskell that allows us to write programs in terms of a generic interface that can be later instantiated to different abstractions depending on the desired target.

reactive programming↗