SEARCH · Engineering Papers

Results for “software integration”

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.

SourceResearch connectionFrom yearThrough year

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

At least 1,333 records · Page 74

All sources NASA NTRS DOE OSTI

NASA NTRS2006

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challange

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), responsible for project management and flight operations; Orbital Sciences Corporation (OSC), spacecraft builder and responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), responsible for science planning and operations. As a cost-capped mission, one of Dawn s implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL s ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL s GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project s commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to an overall systems engineering process and fundamental systems engineering practices: decomposition of the project request into manageable requirements; definition of a structured yet flexible development process; integration of multiple ground disciplines and experts into a focused team effort; in-process risk management; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

systems engineering↗

NASA NTRS2006

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challenge

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), manages the project and is responsible for flight operation; Orbital Sciences Corporation (OSC), is the spacecraft builder and is responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), is responsible for science planning and operations. As a cost-capped mission, one of Dawn's implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL's ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL's GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project's commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to fundamental systems engineering practices: decomposition of the project request into manageable requirements; integration of multiple ground disciplines and experts into a focused team effort; definition of a structured yet flexible development process; definition of an in-process risk reduction plan; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

Ground Data System (GDS)↗

DOE OSTI2021

Improved Nondestructive Isotopic Analysis with Practical Microcalorimeter Gamma Spectrometers

Advances in both instrumentation and data analysis software are now enabling the first ultra-high-resolution microcalorimeter gamma spectrometers designed for implementation in nuclear facilities and analytical laboratories. With approximately ten times better energy resolution than high-purity germanium detectors, these instruments can overcome important uncertainty limits. Microcalorimeter gamma spectroscopy is intended to provide nondestructive isotopic analysis capabilities with sufficient precision and accuracy to reduce the need for sampling, chemical separations, and mass spectrometry to meet safeguards and security goals. Key milestones were the development of the SOFIA instrument (Spectrometer Optimized for Facility Integrated Applications) and the SAPPY software (Spectral Analysis Program in PYthon). SOFIA is a compact instrument that combines advances in large multiplexed transition-edge sensor arrays with optimized cryogenic performance to overcome many practical limitations of previous systems. With a 256-pixel multiplexed detector array capable of 5,000 counts per second, measurement time can be comparable to high-purity germanium detectors. SAPPY was developed to determine isotopic ratios in data from SOFIA and other microcalorimeter instruments with an approach similar to the widely-used FRAM software. SAPPY provides a flexible framework with rigorous uncertainty analysis for both microcalorimeter and high purity germanium (HPGe) data, allowing direct comparison. Here, we present current results from the SOFIA instrument, preliminary isotopic analysis using SAPPY, and describe how the technology is being used to explore uncertainty limits of nondestructive isotopic characterization, inform safeguards models, and extract improved nuclear data including gamma-ray branching ratios.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

DOE OSTI2020

Heterogeneous Reconstruction of Tracks and Primary Vertices With the CMS Pixel Tracker

The High-Luminosity upgrade of the Large Hadron Collider (LHC) will see the accelerator reach an instantaneous luminosity of 7 × 10 34 cm −2 s −1 with an average pileup of 200 proton-proton collisions. These conditions will pose an unprecedented challenge to the online and offline reconstruction software developed by the experiments. The computational complexity will exceed by far the expected increase in processing power for conventional CPUs, demanding an alternative approach. Industry and High-Performance Computing (HPC) centers are successfully using heterogeneous computing platforms to achieve higher throughput and better energy efficiency by matching each job to the most appropriate architecture. In this paper we will describe the results of a heterogeneous implementation of pixel tracks and vertices reconstruction chain on Graphics Processing Units (GPUs). The framework has been designed and developed to be integrated in the CMS reconstruction software, CMSSW. The speed up achieved by leveraging GPUs allows for more complex algorithms to be executed, obtaining better physics output and a higher throughput.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

NASA NTRS2003

Rocket Engine Health Management: Early Definition of Critical Flight Measurements

The NASA led Space Launch Initiative (SLI) program has established key requirements related to safety, reliability, launch availability and operations cost to be met by the next generation of reusable launch vehicles. Key to meeting these requirements will be an integrated vehicle health management ( M) system that includes sensors, harnesses, software, memory, and processors. Such a system must be integrated across all the vehicle subsystems and meet component, subsystem, and system requirements relative to fault detection, fault isolation, and false alarm rate. The purpose of this activity is to evolve techniques for defining critical flight engine system measurements-early within the definition of an engine health management system (EHMS). Two approaches, performance-based and failure mode-based, are integrated to provide a proposed set of measurements to be collected. This integrated approach is applied to MSFC s MC-1 engine. Early identification of measurements supports early identification of candidate sensor systems whose design and impacts to the engine components must be considered in engine design.

Christenson, Rick L.↗

DOE OSTI2023

Normality of I-V Measurements Using ML

There is an increased interest in instrument-computing ecosystems (ICEs) that support science workflows empowered by AI-automated experiments and computations in diverse areas. In particular, electrochemistry ICEs are promising for accelerating the design and discovery of electrochemical systems for energy storage and conversion, by automating significant parts of workflows that combine synthesis and characterization experiments with computations. They require the integration of flow controllers, solvent containers, pumps, fraction collectors, and potentiostats, all connected to an electrochemical cell, as illustrated in Fig. 1. These are specialized instruments with custom software that is not originally designed for network integration. We developed network and software solutions for electrochemical workflows that adapt system and instrument settings in real-time for multiple rounds of experiments. In particular, we developed Python wrappers for Application Programming Interfaces (APIs) of instrument commands and Pyro client-server modules that enable them to be executed from remote computers. The entire workflow is orchestrated by a Jupyter notebook running on a remote computer.

Al Najjar, Anees↗

DOE OSTI2011

Designing the Cloud-based DOE Systems Biology Knowledgebase

Systems Biology research, even more than many other scientific domains, is becoming increasingly data-intensive. Not only have advances in experimental and computational technologies lead to an exponential increase in scientific data volumes and their complexity, but increasingly such databases themselves are providing the basis for new scientific discoveries. To engage effectively with these community resources, integrated analyses, synthesis and simulation software is needed, regularly supported by scientific workflows. In order to provide a more collaborative, community driven research environment for this heterogeneous setting, the Department of Energy (DOE) has decided to develop a federated, cloud based cyber infrastructure - the Systems Biology Knowledgebase (Kbase). Pacific Northwest National Laboratory (PNNL) with its long tradition in data intensive science lead two of the five initial pilot projects, these two focusing on defining and testing the basic federated cloud-based system architecture and develop a prototype implementation. Hereby the community wide accessibility of biological data and the capability to integrate and analyze this data within its changing research context were seen as key technical functionalities the Kbase needed to enable. In this paper we describe the results of our investigations into the design of a cloud based federated infrastructure for: (1) Semantics driven data discovery, access and integration; (2) Data annotation, publication and sharing; (3) Workflow enabled data analysis; and (4) Project based collaborative working. We describe our approach, exemplary use cases and our prototype implementation that demonstrates the feasibility of this approach.

99 GENERAL AND MISCELLANEOUS↗

NASA NTRSDate not supplied

Developing A Dependable Multi-Agent Rover Swarm Using cFS

The future of space exploration lies in cooperative autonomous systems. Ensuring their high integrity remains a challenge. The Robust Software Engineering group at NASA Ames Research Center has been developing the Troupe project to explore the challenges with developing and assuring high integrity of cooperative autonomous robotic systems. In particular, Troupe aims to develop a swarm of autonomous rovers capable of mapping unknown terrain and assure their high integrity using the advanced V&V tools developed in the group. In this paper, we present the evolution of the design of Troupe. We focus on the lessons learned in developing and assuring the rover swarm using core Flight System (cFS). In particular, we discuss the benefits and challenges in applying model-based development to develop the rover swarm.

space systems↗

NASA NTRSDate not supplied

Developing A Dependable Multi-Agent Rover Swarm Using cFS

space systems↗

NASA NTRS1994

Coordinating complex decision support activities across distributed applications

Knowledge-based technologies have been applied successfully to automate planning and scheduling in many problem domains. Automation of decision support can be increased further by integrating task-specific applications with supporting database systems, and by coordinating interactions between such tools to facilitate collaborative activities. Unfortunately, the technical obstacles that must be overcome to achieve this vision of transparent, cooperative problem-solving are daunting. Intelligent decision support tools are typically developed for standalone use, rely on incompatible, task-specific representational models and application programming interfaces (API's), and run on heterogeneous computing platforms. Getting such applications to interact freely calls for platform independent capabilities for distributed communication, as well as tools for mapping information across disparate representations. Symbiotics is developing a layered set of software tools (called NetWorks! for integrating and coordinating heterogeneous distributed applications. he top layer of tools consists of an extensible set of generic, programmable coordination services. Developers access these services via high-level API's to implement the desired interactions between distributed applications.

Adler, Richard M.↗

DOE OSTI2022

Ambassador Project (Final Report)

SEL, in collaboration with its partners, performed research, development and demonstration of a trust, data, and resource management software layer enabling multiple software applications from different suppliers to operate in a Software Defined Infrastructure. The Energy sector has successfully deployed Software Defined Networking (SDN) technology and is rapidly scaling deployments. One major benefit of SDN is the abstracted centralized nature of the orchestration and management of the network. This architecture enables end users to deploy new technology and capabilities as quickly as they perform firmware upgrades to field devices. When an end user needs to roll trucks to install new equipment, they simply deploy new software to run on top of this SD-Infrastructure. This has attracted many software companies to develop value added features and introduce new capabilities, which is all good for the industry but has also introduced new challenges, including how to manage trust between these software applications, how to manage the data integrity and access, and how to manage access to the network resources each of these software applications are demanding. Completion of this project developed and demonstrated a safe and reliable resource scheduler and cybersecurity trust management communication platform allowing multiple software applications to operate in a SD-Infrastructure resulting in the commercialization of a software eco-system and architecture that maintains interoperability, cybersecurity, and reliability where the end user can safely scale out their software to leverage the powerful benefits of SDN.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS2017

Medical Data Architecture Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current International Space Station (ISS) medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable an increasingly autonomous crew than the current ISS paradigm. The MDA will develop capabilities that support automated data collection, and the necessary functionality and challenges in executing a self-contained medical system that approaches crew health care delivery without assistance from ground support.To attain this goal, the first year of the MDA project focused on reducing technical risk, developing documentation and instituting iterative development processes that established the basis for the first version of MDA software (or Test Bed 1). Test Bed 1 is based on a nominal operations scenario authored by the ExMC Element Scientist. This narrative was decomposed into a Concept of Operations that formed the basis for Test Bed 1 requirements. These requirements were successfully vetted through the MDA Test Bed 1 System Requirements Review, which permitted the MDA project to begin software code development and component integration. This paper highlights the MDA objectives, development processes, and accomplishments, and identifies the fiscal year 2017 milestones and deliverables in the upcoming year.

Exploration medical system↗

NASA NTRS2017

Medical Data Architecture Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current International Space Station (ISS) medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable an increasingly autonomous crew than the current ISS paradigm. The MDA will develop capabilities that support automated data collection, and the necessary functionality and challenges in executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. To attain this goal, the first year of the MDA project focused on reducing technical risk, developing documentation and instituting iterative development processes that established the basis for the first version of MDA software (or Test Bed 1). Test Bed 1 is based on a nominal operations scenario authored by the ExMC Element Scientist. This narrative was decomposed into a Concept of Operations that formed the basis for Test Bed 1 requirements. These requirements were successfully vetted through the MDA Test Bed 1 System Requirements Review, which permitted the MDA project to begin software code development and component integration. This paper highlights the MDA objectives, development processes, and accomplishments, and identifies the fiscal year 2017 milestones and deliverables in the upcoming year.

Data management↗

NASA NTRS1984

The pilot climate data system

The Pilot Climate Data System (PCDS) is an interactive scientific information management system for locating, obtaining, manipulating, and displaying climate-research data. The PCDS was developed to manage a large collection of data of interest to the National Aeronautics and Space Administration's (NASA) research community and currently provides such support for approximately twenty data sets. In order to provide the PCDS capabilities, NASA's Goddard Space Flight Center (NASA/GSFC) has integrated the capabilities of several general-purpose software packages with specialized software for reading and reformatting the supported data sets. These capabilities were integrated in a manner which allows the PCDS to be easily expanded, either to provide support for additional data sets or to provide additional functional capabilities. This also allows the PCDS to take advantage of new technology as it becomes available, since parts of the system can be replaced with more powerful components without significantly affecting the user interface.

Reph, M. G.↗

NASA NTRS2005

Investigation of Integrated Vehicle Health Management Approaches

This report is to present the work that was performed during the summer in the Advance Computing Application office. The NFFP (NASA Faculty Fellow Program) had ten summer faculty members working on IVHM (Integrated Vehicle Health Management) technologies. The objective of this project was two-fold: 1) to become familiar with IVHM concepts and key demonstrated IVHM technologies; and 2) to integrate the research that has been performed by IVHM faculty members into the MASTLAB (Marshall Avionic Software Test Lab). IVHM is a NASA-wide effort to coordinate, integrate and apply advanced software, sensors and design technologies to increase the level of intelligence, autonomy, and health state of future vehicles. IVHM is an important concept because it is consistent with the current plan for NASA to go to the moon, mars, and beyond. In order for NASA to become more involved in deep exploration, avionic systems will need to be highly adaptable and autonomous.

Paris, Deidre↗

NASA NTRS2006

Software Reuse Within the Earth Science Community

Scientific missions in the Earth sciences frequently require cost-effective, highly reliable, and easy-to-use software, which can be a challenge for software developers to provide. The NASA Earth Science Enterprise (ESE) spends a significant amount of resources developing software components and other software development artifacts that may also be of value if reused in other projects requiring similar functionality. In general, software reuse is often defined as utilizing existing software artifacts. Software reuse can improve productivity and quality while decreasing the cost of software development, as documented by case studies in the literature. Since large software systems are often the results of the integration of many smaller and sometimes reusable components, ensuring reusability of such software components becomes a necessity. Indeed, designing software components with reusability as a requirement can increase the software reuse potential within a community such as the NASA ESE community. The NASA Earth Science Data Systems (ESDS) Software Reuse Working Group is chartered to oversee the development of a process that will maximize the reuse potential of existing software components while recommending strategies for maximizing the reusability potential of yet-to-be-designed components. As part of this work, two surveys of the Earth science community were conducted. The first was performed in 2004 and distributed among government employees and contractors. A follow-up survey was performed in 2005 and distributed among a wider community, to include members of industry and academia. The surveys were designed to collect information on subjects such as the current software reuse practices of Earth science software developers, why they choose to reuse software, and what perceived barriers prevent them from reusing software. In this paper, we compare the results of these surveys, summarize the observed trends, and discuss the findings. The results are very similar, with the second, larger survey confirming the basic results of the first, smaller survey. The results suggest that reuse of ESE software can drive down the cost and time of system development, increase flexibility and responsiveness of these systems to new technologies and requirements, and increase effective and accountable community participation.

Marshall, James J.↗

NASA NTRS2012

Design and Fabrication of DebriSat - A Representative LEO Satellite for Improvements to Standard Satellite Breakup Models

This paper discusses the design and fabrication of DebriSat, a 50 kg satellite developed to be representative of a modern low Earth orbit satellite in terms of its components, materials used, and fabrication procedures. DebriSat will be the target of a future hypervelocity impact experiment to determine the physical characteristics of debris generated after an on-orbit collision of a modern LEO satellite. The major ground-based satellite impact experiment used by DoD and NASA in their development of satellite breakup models was SOCIT, conducted in 1992. The target used for that experiment was a Navy transit satellite (~40 cm, 35 kg) fabricated in the 1960's. Modern satellites are very different in materials and construction techniques than those built 40 years ago. Therefore, there is a need to conduct a similar experiment using a modern target satellite to improve the fidelity of the satellite breakup models. To ensure that DebriSat is truly representative of typical LEO missions, a comprehensive study of historical LEO satellite designs and missions within the past 15 years for satellites ranging from 1 kg to 5000 kg was conducted. This study identified modern trends in hardware, material, and construction practices utilized in recent LEO missions. Although DebriSat is an engineering model, specific attention is placed on the quality, type, and quantity of the materials used in its fabrication to ensure the integrity of the outcome. With the exception of software, all other aspects of the satellite s design, fabrication, and assembly integration and testing will be as rigorous as that of an actual flight vehicle. For example, to simulate survivability of launch loads, DebriSat will be subjected to a vibration test. As well, the satellite will undergo thermal vacuum tests to verify that the components and overall systems meet typical environmental standards. Proper assembly and integration techniques will involve comprehensive joint analysis, including the precise torqueing of fasteners and thread locking. Finally, the implementation of process documentation and verification procedures is discussed to provide a comprehensive overview of the design and fabrication of this representative LEO satellite.

Clark, S.↗

NASA NTRS2021

An Innovative Approach to Modeling VIPER Rover Software Life Cycle Cost

NASA’s “Volatiles Investigating Polar Exploration Rover” (VIPER) will be the first robotic mission to prospect for water ice near the south pole of the Moon in late 2023 on a 100-Earth-day mission. The information that the VIPER rover provides will help improve understanding of the composition, distribution, and accessibility of Lunar polar volatiles and will help determine how the Moon’s resources can support future human space exploration. VIPER, however, represents a radical departure from the way that NASA has traditionally developed planetary robotic missions. A key consequence of these differences is that estimating the cost of VIPER’s rover software is challenging and complex.For example, VIPER is being developed using management procedures typically applied to NASA research and technology projects, rather than space flight programs. In addition, key portions of the rover’s software are being designed as ground software to run on mission control computers (rather than on-board the rover as flight software as with prior planetary missions) taking advantage of continuous, interactive data communications between the Moon and Earth and higher performance computing available on the ground. Moreover, the rover’s software is being engineered using Agile software development practices and incorporates a significant amount of open-source, rather than following traditional (spiral, waterfall, etc.) development methods and in-house code. In this paper, we present an innovative process to estimate the life cycle cost of VIPER’s rover software. We first describe how we modeled the architecture and code counts for three software elements: Rover Flight Software (RFSW), Rover Ground Software (RGSW), and Rover Simulation Software (RSIM). We then discuss key challenges and unique aspects of our approach, such as the lack of Lunar rover analogies, the need to integrate and test large open source software, and the strategies developed to account for use of non-space flight management practices and the impact of the COVID-19 pandemic. We conclude with a summary of our results, including cumulative distribution, nearest neighbors and cluster analysis, as well as heuristics used to confirm the reasonableness of the cost estimate.

Utz, Hans↗