Search NASA⌕ Search

SEARCH · Search NASA

Results for “Software asset”

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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2010

Model Transformation for a System of Systems Dependability Safety Case

Software plays an increasingly larger role in all aspects of NASA's science missions. This has been extended to the identification, management and control of faults which affect safety-critical functions and by default, the overall success of the mission. Traditionally, the analysis of fault identification, management and control are hardware based. Due to the increasing complexity of system, there has been a corresponding increase in the complexity in fault management software. The NASA Independent Validation & Verification (IV&V) program is creating processes and procedures to identify, and incorporate safety-critical software requirements along with corresponding software faults so that potential hazards may be mitigated. This Specific to Generic ... A Case for Reuse paper describes the phases of a dependability and safety study which identifies a new, process to create a foundation for reusable assets. These assets support the identification and management of specific software faults and, their transformation from specific to generic software faults. This approach also has applications to other systems outside of the NASA environment. This paper addresses how a mission specific dependability and safety case is being transformed to a generic dependability and safety case which can be reused for any type of space mission with an emphasis on software fault conditions.

Murphy, Judy↗
NASA NTRS2015

Fault Management Architectures and the Challenges of Providing Software Assurance

Fault Management (FM) is focused on safety, the preservation of assets, and maintaining the desired functionality of the system. How FM is implemented varies among missions. Common to most missions is system complexity due to a need to establish a multi-dimensional structure across hardware, software and spacecraft operations. FM is necessary to identify and respond to system faults, mitigate technical risks and ensure operational continuity. Generally, FM architecture, implementation, and software assurance efforts increase with mission complexity. Because FM is a systems engineering discipline with a distributed implementation, providing efficient and effective verification and validation (V&V) is challenging. A breakout session at the 2012 NASA Independent Verification & Validation (IV&V) Annual Workshop titled "V&V of Fault Management: Challenges and Successes" exposed this issue in terms of V&V for a representative set of architectures. NASA's Software Assurance Research Program (SARP) has provided funds to NASA IV&V to extend the work performed at the Workshop session in partnership with NASA's Jet Propulsion Laboratory (JPL). NASA IV&V will extract FM architectures across the IV&V portfolio and evaluate the data set, assess visibility for validation and test, and define software assurance methods that could be applied to the various architectures and designs. This SARP initiative focuses efforts on FM architectures from critical and complex projects within NASA. The identification of particular FM architectures and associated V&V/IV&V techniques provides a data set that can enable improved assurance that a system will adequately detect and respond to adverse conditions. Ultimately, results from this activity will be incorporated into the NASA Fault Management Handbook providing dissemination across NASA, other agencies and the space community. This paper discusses the approach taken to perform the evaluations and preliminary findings from the research.

Fault Management↗
DOE OSTI2024

Developing a Supply Chain Security Program

Amid growing concerns over foreign manufacturing for components and devices deployed in critical energy infrastructure, this research from the national labs will highlight best practices for developing and maintaining a supply chain security program. Tools for asset inventory, tips for developing and maintaining software- and hardware-bills-of-materials (SBOMs and HBOMs), recommended contractual language for vendor agreements, and identification of responsibilities will be shared. We discuss the one-time requirements to enable a successful supply chain security program and the best ways to operationalize this program for maximum impact, including development of robust practices for vulnerability tracking, patch management, and workarounds, with understanding of the reliability and uptime requirements for utilities. The recommendations shared are based on a cyber-informed engineering approach to identification of high-consequence impacts and the engineering controls related to supply chain management that can best mitigate these impacts. This approach allows for prioritization of resources. Additionally, we highlight relative up-front and ongoing costs associated with recommended controls. Viewers will leave with an understanding what a supply chain security program is, and what steps, prioritized for resource-constrained organizations, can build a robust program.

14 SOLAR ENERGY↗
NASA NTRS1992

Object linking in repositories

This topic is covered in three sections. The first section explores some of the architectural ramifications of extending the Eichmann/Atkins lattice-based classification scheme to encompass the assets of the full life cycle of software development. A model is considered that provides explicit links between objects in addition to the edges connecting classification vertices in the standard lattice. The second section gives a description of the efforts to implement the repository architecture using a commercially available object-oriented database management system. Some of the features of this implementation are described, and some of the next steps to be taken to produce a working prototype of the repository are pointed out. In the final section, it is argued that design and instantiation of reusable components have competing criteria (design-for-reuse strives for generality, design-with-reuse strives for specificity) and that providing mechanisms for each can be complementary rather than antagonistic. In particular, it is demonstrated how program slicing techniques can be applied to customization of reusable components.

Eichmann, David↗
NASA NTRS2011

MaROS: Information Management Service

This software is provided by the Mars Relay Operations Service (MaROS) task to a variety of Mars projects for the purpose of coordinating communications sessions between landed spacecraft assets and orbiting spacecraft assets at Mars. The Information Management Service centralizes a set of functions previously distributed across multiple spacecraft operations teams, and as such, greatly improves visibility into the end-to-end strategic coordination process. Most of the process revolves around the scheduling of communications sessions between the spacecraft during periods of time when a landed asset on Mars is geometrically visible by an orbiting spacecraft. These relay sessions are used to transfer data both to and from the landed asset via the orbiting asset on behalf of Earth-based spacecraft operators. This software component is an application process running as a Java virtual machine. The component provides all service interfaces via a Representational State Transfer (REST) protocol over https to external clients. There are two general interaction modes with the service: upload and download of data. For data upload, the service must execute logic specific to the upload data type and trigger any applicable calculations including pass delivery latencies and overflight conflicts. For data download, the software must retrieve and correlate requested information and deliver to the requesting client. The provision of this service enables several key advancements over legacy processes and systems. For one, this service represents the first time that end-to-end relay information is correlated into a single shared repository. The software also provides the first multimission latency calculator; previous latency calculations had been performed on a mission-by-mission basis.

Allard, Daniel A.↗
NASA NTRS2008

Mars Interoperability 2008-2015: Options for Relay Orbiter Support to Mars Bound Assets

The current relay orbiter infrastructure at Mars, in support of the user assets presently at Mars and those scheduled for the 2008 to 2015 time frame, only have a need to store-and-forward the returned data collected by an asset to Earth as a single non-prioritized data file. In the forward direction, the relay orbiters are only required to relay the forward link data, i.e., command sequences, software and configuration information assembled on the ground, to the Asset. There are currently no requirements for status/control messages or files to be sent in the return direction from an Asset to an application located on the Relay, nor are there requirements in the forward direction to send status/control messages or files originating on a Relay to an Asset. In addition there are currently no networking requirements at Mars where data originally sent by an Asset is to be delivered to another user asset. However, we foresee the day when standard services for 1) on-board file prioritization of user asset data by a Relay, 2) control/status message transfer between assets and a Relay, and 3) networking between assets i.e., Asset to Asset message/file transfer via a Relay will be required. Each of these services will require the Relay to be capable of understanding the data type and routing needs of the user asset data and be capable of processing it for these purposes. This paper will focus on the innovative enhancements required to the existing communications infrastructure at Mars to enable these future services.

File Transfer↗
NASA NTRS2006

Transforming Our SMEX Organization by Way of Innovation, Standardization, and Automation

NASA's Small Explorer (SMEX) Flight Operations Team (FOT) is currently tackling the challenge of supporting ground operations for several satellites that have surpassed their designed lifetime and have a dwindling budget. At Goddard Space Flight Center (GSFC), these missions are presently being reengineered into a fleet-oriented ground system. When complete, this ground system will provide command and control of four SMEX missions, and will demonstrate fleet automation and control concepts as a pathfinder for additional mission integrations. A goal of this reengineering effort is to demonstrate new ground-system technologies that show promise of supporting longer mission lifecycles and simplifying component integration. In pursuit of this goal, the SMEX organization has had to examine standardization, innovation, and automation. A core technology being demonstrated in this effort is the GSFC Mission Services Evolution Center (GMSEC) architecture. The GMSEC architecture focuses on providing standard interfaces for ground system applications to promote application interoperability. Building around commercial Message Oriented Middleware and providing a common messaging standard allows GMSEC to provide the capabilities necessary to support integration of new software components into existing missions and increase the level of interaction within the system. For SMS, GMSEC has become the technology platform to transform flight operations with the innovation and automation necessary to reduce operational costs. The automation technologies supported in SMEX are built upon capabilities provided by the GMSEC architecture that allows the FOT to further reduce the involvement of the console, operator. Initially, SMEX is automating only routine operations, such as safety and health monitoring, basic commanding, and system recovery. The operational concepts being developed here will reduce the need for staffed passes and are a necessity for future fleet management. As this project continues to evolve, additional innovations beyond GMSEC and automation have, and will continue to be developed. The team developed techniques for migrating ground systems of existing on-orbit assets. The tools necessary to monitor and control software failures were integrated and tailored for operational environments. All this was done with a focus of extending fleet operations to mission beyond SMU. The result of this work is the foundation for a broader fleet-capable ground system that will include several missions supported by the Space Science Mission Operations Project.

Madden, Maureen↗
NASA NTRS1991

Object links in the repository

Some of the architectural ramifications of extending the Eichmann/Atkins lattice-based classification scheme to encompass the assets of the full life-cycle of software development are explored. In particular, we wish to consider a model which provides explicit links between objects in addition to the edges connecting classification vertices in the standard lattice. The model we consider uses object-oriented terminology. Thus, the lattice is viewed as a data structure which contains class objects which exhibit inheritance. A description of the types of objects in the repository is presented, followed by a discussion of how they interrelate. We discuss features of the object-oriented model which support these objects and their links, and consider behavior which an implementation of the model should exhibit. Finally, we indicate some thoughts on implementing a prototype of this repository architecture.

Beck, Jon↗
NASA NTRS1997

The Generalized Support Software (GSS) Domain Engineering Process: An Object-Oriented Implementation and Reuse Success at Goddard Space Flight Center

The Flight Dynamics Division (FDD) of NASA's Goddard Space Flight Center (GSFC) recently embarked on a far-reaching revision of its process for developing and maintaining satellite support software. The new process relies on an object-oriented software development method supported by a domain specific library of generalized components. This Generalized Support Software (GSS) Domain Engineering Process is currently in use at the NASA GSFC Software Engineering Laboratory (SEL). The key facets of the GSS process are (1) an architecture for rapid deployment of FDD applications, (2) a reuse asset library for FDD classes, and (3) a paradigm shift from developing software to configuring software for mission support. This paper describes the GSS architecture and process, results of fielding the first applications, lessons learned, and future directions

Condon, Steven↗
NASA NTRS2015

Fault Management Architectures and the Challenges of Providing Software Assurance

The satellite systems Fault Management (FM) is focused on safety, the preservation of assets, and maintaining the desired functionality of the system. How FM is implemented varies among missions. Common to most is system complexity due to a need to establish a multi-dimensional structure across hardware, software and operations. This structure is necessary to identify and respond to system faults, mitigate technical risks and ensure operational continuity. These architecture, implementation and software assurance efforts increase with mission complexity. Because FM is a systems engineering discipline with a distributed implementation, providing efficient and effective verification and validation (VV) is challenging. A breakout session at the 2012 NASA Independent Verification Validation (IVV) Annual Workshop titled VV of Fault Management: Challenges and Successes exposed these issues in terms of VV for a representative set of architectures. NASA's IVV is funded by NASA's Software Assurance Research Program (SARP) in partnership with NASA's Jet Propulsion Laboratory (JPL) to extend the work performed at the Workshop session. NASA IVV will extract FM architectures across the IVV portfolio and evaluate the data set for robustness, assess visibility for validation and test, and define software assurance methods that could be applied to the various architectures and designs. This work focuses efforts on FM architectures from critical and complex projects within NASA. The identification of particular FM architectures, visibility, and associated VVIVV techniques provides a data set that can enable higher assurance that a satellite system will adequately detect and respond to adverse conditions. Ultimately, results from this activity will be incorporated into the NASA Fault Management Handbook providing dissemination across NASA, other agencies and the satellite community. This paper discusses the approach taken to perform the evaluations and preliminary findings from the research including identification of FM architectures, visibility observations, and methods utilized for VVIVV.

Fault Management↗
NASA NTRS2017

Key Differences in Operating a Rover on the Moon vs. Mars

The command and control model for spacecraft operations, as well as the distribution of tasks between ground assets and in space assets, whether with a crew or solely robotic, is fundamentally constrained by the round trip light time between the space asset and the control facility (presumably on Earth, though not required). For an asset on Mars, the round trip light time varies, from roughly fourteen minutes to up to forty minutes. For a Lunar asset the round-trip light time is measured in only a few seconds, but current communications systems may more than double the latency with system overhead. For a Lunar Asset the total command latency may range from six seconds to more than forty, depending on communications overhead and data rates. Further, these variables are not always predictable, thus complicating operations. There are several differentiating factors for Lunar vs. Mars operations, Round trip light time/Atmosphere/Lighting and ShadowsTerrain type and knowledge/Round trip light time has implications for the distribution of tasks between ground and in space assets. Even at Lunar Distances, the combination of round trip light time plus communications systems overhead does not enable joy stick driving of a rover. The best that can be done, if driving from Earth, is near real time command and control. By 2030, driving from in space may be possible. Productivity on Mars requires either long operational sequences of commands, as is done for current rovers such as Curiosity, significant autonomous capability or, as may be possible by 2030, command and control support from space. Another implication of the long round trip light time from Earth to Mars, is that flight software functions must be resident on the in space asset. On the Moon, there is considerably more flexibility, enabling processing functions, to be resident on Earth or in space. This provides the opportunity to take advantage of the considerable processing power available on the ground, but may be constrained by data rates. On the Moon, for practical operational purposes, there is no atmosphere. Hence there is no scattering of light in the shadows. This has implications for image interpretation and driving near the poles. The Moon has permanently shadowed regions (PSR), unique terrain with unknown surface properties. With no scattering of light in shadows, driving on the Moon, particularly at the poles, where we have strong evidence of water, may prove to be hazardous and complex, requiring non-optical sensors, such as LIDAR.

Trimble, Jay↗
NASA NTRS1996

The Application of V&V within Reuse-Based Software Engineering

Verification and Validation (V&V) is performed during application development for many systems, especially safety-critical and mission-critical systems. The V&V process is intended to discover errors as early as possible during the development process. Early discovery is important in order to minimize the cost and other impacts of correcting these errors. In reuse-based software engineering, decisions on the requirements, design and even implementation of domain assets can can be made prior to beginning development of a specific system. in order to bring the effectiveness of V&V to bear within reuse-based software engineering. V&V must be incorporated within the domain engineering process.

Addy, Edward↗
NASA NTRS2004

NASA Langley Research Center's Simulation-To-Flight Concept Accomplished through the Integration Laboratories of the Transport Research Facility

The Flight Simulation and Software Branch (FSSB) at NASA Langley Research Center (LaRC) maintains the unique national asset identified as the Transport Research Facility (TRF). The TRF is a group of facilities and integration laboratories utilized to support the LaRC's simulation-to-flight concept. This concept incorporates common software, hardware, and processes for both groundbased flight simulators and LaRC s B-757-200 flying laboratory identified as the Airborne Research Integrated Experiments System (ARIES). These assets provide Government, industry, and academia with an efficient way to develop and test new technology concepts to enhance the capacity, safety, and operational needs of the ever-changing national airspace system. The integration of the TRF enables a smooth continuous flow of the research from simulation to actual flight test.

Martinez, Debbie↗
DOE OSTI2025

SLIA Reference Architecture Models

The SLIA Reference Architecture Models project, sponsored by the DOE CESER Energy CyberSense Program (Oct 2024–Sep 2025), advanced LLNL’s PySCES simulation tool to better support CyTRICS Prioritization and Initial Risk Assessment (PIRA) reference architectures. Key achievements include enhancements to the PySCES transmission substation facility model, expanded asset coverage, and enhancements to the PySCES code base. Software improvements reduced code complexity, migrated PySCES to Python version 3.11, introduced an object-oriented design, and added a schema database for easier updates and validation. New features support device criticality assessments and a more precise parametric simulation mode. Remaining gaps include model validation, workflow limitations, Monte Carlo convergence issues, full device criticality metric implementation, model fidelity, and general software improvements. Continued development is recommended to address these gaps and fully align PySCES with CyTRICS PIRA requirements.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2013

Kennedy Space Center: Swamp Works

When I began my internship with the Granular Mechanics and Regolith Operations laboratory (GMRO), also known as Swamp Works, I was given the unique opportunity to shadow many teams working on various projects, and decide what projects I wanted to take part in. Before I go into details of my experiences at Swamp Works, I would like to take a moment to explain what I discovered Swamp Works to be. Swamp Works is a family of hardworking, dedicated, and driven people from various backgrounds and skill sets. These people all work to advance technologies and make science fiction science fact through means of rapid prototyping. They support and encourage failure as an option when learning new things, as long as lesson learned from said failure. In fact, their motto states "Fail, Fast, Forward." What this means is, not if but when one fails he or she must do so quickly and spring forward from the failure so that his or her progress is not delayed. With this acceptance, it provided me the confidence to dive into a multitude of projects working in various fields and with a wide range of skill sets. The first project I joined was Badger. My motivation for taking on this project was the opportunity I would have to obtain valuable experience working with 3D modeling and 3D printing technologies. Badger was a digging apparatus to be used in a highly dusty environment in a material known as Regolith. Regolith is a scientific term for the dirt or top soil found on planetary bodies. Regolith contains a large quantity of sediments less than lOppm and as a result poses a challenge of keeping it out of any cracks and crevices. Furthermore, regolith can create high levels of electrostatic energy, which can prove damaging to sensitive electrical hardware. With these characteristics in mind, I decided to take on the task of designing and manufacturing a dust proof cover for the sensitive electrical hardware. When I began this project, I did not have the slightest idea as to how to use 3D modeling software or a means of manufacturing a viable product. As I went along with variants of the design, I became very proficient with a 3D modeling program known as CREO 2.0. Upon completion of my 3D design, I then had the task of manufacturing and having, in my hands, a usable model. To do this I had to work with additive printing technologies also known as 3D printing. Through my experiences working with Badger, I realized that 3D modeling is the focal point in much of engineering. With this in mind, I have embraced this fact and decided to further my experience with this software so that I may become a more valuable asset to any firm later in my career. Mid-way through work with Badger, I picked up another project in which I found much interest. I ha~ the opportunity to work side by side with a materials and composites guru in manufacturing carbon composite coupons (test strips) for performing stress, strain, and sheer analysis on. Being from a surfing, kiteboarding, and other water sport background I have always been interested in board design. With this in mind, it is no wonder why I found interest in such a project. I had the opportunity to refine Mold preparatory, composite layup, and composite curing techniques. Following manufacturing of these composite strips, I then performed various stress tests and logged my results. With these results, future teams could create lighter, stronger, and more cost effective composite structures for use in varieties of applications. After my experiences with materials and composites testing, I have obtained crucial appreciation for detailed documentation and analysis that material sciences involve. However, as interesting as composite materials testing has been, I do not feel this is where my future career lies. Another, more on the side, project I have been involved in is building a 626 cubic foot regolith containment chamber for doing full scale testing of robotic systems. This chamber is built of high strength aluminum scaffold materials, 80/20, and massive panels of Lexan. Once the chamber is completed, it is be filled with 120 tons of regolith and dubbed the largest regolith test chamber in the world. Through my experiences with building "Big Bin" as we called it, I discovered my demand for engaging and hands on activities. Through all of my incredible experiences working with the Swamp Works at Kennedy Space Center; I have obtained crucial knowledge, insights, and experiences that have fuelled, shaped, and will continue to drive me toward my ultimate goal of obtaining not only a degree in Engineering, but obtaining a job that I can call a career. I want to give much thanks to all of those who mentored me along my journey, and to all who made this opportunity a reality.

DeFilippo, Anthony Robert↗
NASA NTRS2005

Let's Roll! Rolling Out or Deploying SEPG Assets

The topics covered in this slide presentation are: the general approach to software quality improvement (SQI) at Jet Propulsion Institute, the SQI deployment process, and lessons learned in regard to SQI. The Software Engineering Process Group (SEPG) is the group charged with SQI. The initial focus of the Software Quality Improvement (SQI) Project is on mission-critical software for flight projects, their spacecraft and instrument systems, and their ground systems.

process improvements↗
NASA NTRS2015

Multi-Spacecraft Autonomous Positioning System

As the number of spacecraft in simultaneous operation continues to grow, there is an increased dependency on ground-based navigation support. The current baseline system for deep space navigation utilizes Earth-based radiometric tracking, requiring long-duration observations to perform orbit determination and generate a state update. The age, complexity, and high utilization of the ground assets pose a risk to spacecraft navigation performance. In order to perform complex operations at large distances from Earth, such as extraterrestrial landing and proximity operations, autonomous systems are required. With increasingly complex mission operations, the need for frequent and Earth-independent navigation capabilities is further reinforced. The Multi-spacecraft Autonomous Positioning System (MAPS) takes advantage of the growing interspacecraft communication network and infrastructure to allow for Earth-autonomous state measurements to enable network-based space navigation. A notional concept of operations is given in figure 1. This network is already being implemented and routinely used in Martian communications through the use of the Mars Reconnaissance Orbiter and Mars Odyssey spacecraft as relays for surface assets. The growth of this communications architecture is continued through MAVEN, and future potential commercial Mars telecom orbiters. This growing network provides an initial Marslocal capability for inter-spacecraft communication and navigation. These navigation updates are enabled by cross-communication between assets in the network, coupled with onboard navigation estimation routines to integrate packet travel time to generate ranging measurements. Inter-spacecraft communication allows for frequent state broadcasts and time updates from trusted references. The architecture is a software-based solution, enabling its implementation on a wide variety of current assets, with the operational constraints and measurement accuracy determined by onboard systems.

Anzalone, Evan↗
NASA NTRS2016

Marshall Space Flight Center Telescience Resource Kit

Telescience Resource Kit (TReK) is a suite of software applications that can be used to monitor and control assets in space or on the ground. The Telescience Resource Kit was originally developed for the International Space Station program. Since then it has been used to support a variety of NASA programs and projects including the WB-57 Ascent Vehicle Experiment (WAVE) project, the Fast Affordable Science and Technology Satellite (FASTSAT) project, and the Constellation Program. The Payloads Operations Center (POC), also known as the Payload Operations Integration Center (POIC), provides the capability for payload users to operate their payloads at their home sites. In this environment, TReK provides local ground support system services and an interface to utilize remote services provided by the POC. TReK provides ground system services for local and remote payload user sites including International Partner sites, Telescience Support Centers, and U.S. Investigator sites in over 40 locations worldwide. General Capabilities: Support for various data interfaces such as User Datagram Protocol, Transmission Control Protocol, and Serial interfaces. Data Services - retrieve, process, record, playback, forward, and display data (ground based data or telemetry data). Command - create, modify, send, and track commands. Command Management - Configure one TReK system to serve as a command server/filter for other TReK systems. Database - databases are used to store telemetry and command definition information. Application Programming Interface (API) - ANSI C interface compatible with commercial products such as Visual C++, Visual Basic, LabVIEW, Borland C++, etc. The TReK API provides a bridge for users to develop software to access and extend TReK services. Environments - development, test, simulations, training, and flight. Includes standalone training simulators.

Wade, Gina↗