Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “asset level data”

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 19 records

Security Data Warehouse Application

The Security Data Warehouse (SDW) is used to aggregate and correlate all JSC IT security data. This includes IT asset inventory such as operating systems and patch levels, users, user logins, remote access dial-in and VPN, and vulnerability tracking and reporting. The correlation of this data allows for an integrated understanding of current security issues and systems by providing this data in a format that associates it to an individual host. The cornerstone of the SDW is its unique host-mapping algorithm that has undergone extensive field tests, and provides a high degree of accuracy. The algorithm comprises two parts. The first part employs fuzzy logic to derive a best-guess host assignment using incomplete sensor data. The second part is logic to identify and correct errors in the database, based on subsequent, more complete data. Host records are automatically split or merged, as appropriate. The process had to be refined and thoroughly tested before the SDW deployment was feasible. Complexity was increased by adding the dimension of time. The SDW correlates all data with its relationship to time. This lends support to forensic investigations, audits, and overall situational awareness. Another important feature of the SDW architecture is that all of the underlying complexities of the data model and host-mapping algorithm are encapsulated in an easy-to-use and understandable Perl language Application Programming Interface (API). This allows the SDW to be quickly augmented with additional sensors using minimal coding and testing. It also supports rapid generation of ad hoc reports and integration with other information systems.

Vernon, Lynn R.↗

Centralized Alert-Processing and Asset Planning for Sensorwebs

A software program provides a Sensorweb architecture for alert-processing, event detection, asset allocation and planning, and visualization. It automatically tasks and re-tasks various types of assets such as satellites and robotic vehicles in response to alerts (fire, weather) extracted from various data sources, including low-level Webcam data. JPL has adapted cons iderable Sensorweb infrastructure that had been previously applied to NASA Earth Science applications. This NASA Earth Science Sensorweb has been in operational use since 2003, and has proven reliability of the Sensorweb technologies for robust event detection and autonomous response using space and ground assets. Unique features of the software include flexibility to a range of detection and tasking methods including those that require aggregation of data over spatial and temporal ranges, generality of the response structure to represent and implement a range of response campaigns, and the ability to respond rapidly.

Castano, Rebecca↗

Sensitivity of Mars surface navigation to timing errors

This study will show that the surface asset positioning process is robust and relatively insensitive to these errors. Indeed, the combination of in-situ and MN orbiter to Earth Doppler data is capable of simultaneously resolving surface asset and MN orbiter positions to an accuracy of 10 m, and clock errors to levels better than 3 msec.

Mars Network navigation timing errors↗

Relay Forward-Link File Management Services (MaROS Phase 2)

This software provides the service-level functionality to manage the delivery of files from a lander mission repository to an orbiter mission repository for eventual spacelink relay by the orbiter asset on a specific communications pass. It provides further functions to deliver and track a set of mission-defined messages detailing lander authorization instructions and orbiter data delivery state. All of the information concerning these transactions is persisted in a database providing a high level of accountability of the forward-link relay process.

Allard, Daniel A.↗

Examples of Level Products Possible from Existing Assets

How do patterns of human environmental and infectious diseases respond to leading environmental changes, particularly to urban growth and change and the associated impacts of urbanization? We use HyspIRI high spatial resolution, multispectral, and multitemporal TIR data to track energy balance and energy flux characteristics for changing land covers/land uses through time to provide synoptic views of impacts on surface energy fluxes, emissivity and temperature and HyspIRI data in conjunction with spatial growth models to project land cover/land use changes in the future to assess impacts on natural and human ecosystems. We use multispectral thermal IR land cover maps at a high spatial resolution (60m) on a weekly basis for long-term validation of surface energy responses and changes in emissivity and integration of HyspIRI TIR data with spatial modeling to assess changes in land cover/land use through time and subsequent changes in thermal energy responses

Quattrochi, Dale A.↗

A Systems Model for System-Wide Safety Safety Demonstrator (SD-1): Wildfire Response Operations

The aim of this internship-based project was to contribute to the ongoing development of a systems model for System-Wide Safety’s first Technical Challenge 5 (TC5) series Safety Demonstrator (SD-1), which will be a demonstration of an In-Time Aviation Safety Management System (IASMS) in emerging wildfire response operations. Using Models-Based Systems Engineering (MBSE) principles to develop the model, I organized and traced previously collected stakeholder needs from the Spring 2022 NASA System-Wide Safety Wildland Firefighting Operations Virtual Workshop (https://nari.arc.nasa.gov/sws-wildfire) to system elements, creating connections which can be used in the future by the project engineers to identify and address requirements gaps throughout the system design process. I also identified and modeled preliminary use case scenarios for aerial assets in the demonstrator and, building on previously produced preliminary high-level models of the 8 SD-1 Services, Functions, and Capabilities (SFCs) and their IASMS data flows, worked to model the Real-Time Risk Assessment (RTRA) tool as an implementation of Risk Assessment and Management that can take in multiple sets of data monitored by SFCs. Project deliverables include stakeholder requirements tables and matrices and systems model diagrams produced with MagicDraw software in the SysML Systems Modeling Language, with eventual plans to connect model diagrams to a Department of Defense Operational Viewpoint (OV-1) graphic, a high-level operational concept graphic that will be used to visualize the SD-1 scenarioin a future phase. The system model serves to provide a common understanding of the scope of and activities necessary for the completion of SD-1,and traces how stakeholder needs are to be addressed.

model-based systems engineering↗

Evolving the Reuse Process at the Flight Dynamics Division (FDD) Goddard Space Flight Center

This paper presents the interim results from the Software Engineering Laboratory's (SEL) Reuse Study. The team conducting this study has, over the past few months, been studying the Generalized Support Software (GSS) domain asset library and architecture, and the various processes associated with it. In particular, we have characterized the process used to configure GSS-based attitude ground support systems (AGSS) to support satellite missions at NASA's Goddard Space Flight Center. To do this, we built detailed models of the tasks involved, the people who perform these tasks, and the interdependencies and information flows among these people. These models were based on information gleaned from numerous interviews with people involved in this process at various levels. We also analyzed effort data in order to determine the cost savings in moving from actual development of AGSSs to support each mission (which was necessary before GSS was available) to configuring AGSS software from the domain asset library. While characterizing the GSS process, we became aware of several interesting factors which affect the successful continued use of GSS. Many of these issues fall under the subject of evolving technologies, which were not available at the inception of GSS, but are now. Some of these technologies could be incorporated into the GSS process, thus making the whole asset library more usable. Other technologies are being considered as an alternative to the GSS process altogether. In this paper, we outline some of issues we will be considering in our continued study of GSS and the impact of evolving technologies.

Condon, S.↗

Integrating High-Resolution Taskable Imagery into a Sensorweb for Automatic Space-Based Monitoring of Flooding in Thailand

Several space-based assets (Terra, Aqua, Earth Observing One) have been integrated into a sensorweb to monitor flooding in Thailand. In this approach, the Moderate Imaging Spectrometer (MODIS) data from Terra and Aqua is used to perform broad-scale monitoring to track flooding at the regional level (250m/pixel) and EO-1 is autonomously tasked in response to alerts to acquire higher resolution (30m/pixel) Advanced Land Imager (ALI) data. This data is then automatically processed to derive products such as surface water extent and volumetric water estimates. These products are then automatically pushed to organizations in Thailand for use in damage estimation, relief efforts, and damage mitigation. More recently, this sensorweb structure has been used to request imagery, access imagery, and process high-resolution (several m to 30m), targetable asset imagery from commercial assets including Worldview-2, Ikonos, Radarsat-2, Landsat-7, and Geo-Eye-1. We describe the overall sensorweb framework as well as new workflows and products made possible via these extensions.

sensorweb operations↗

Utilization of Unsupervised Anomalies Detector as a Tool for Managing the TDRS Constellation at GSFC

NASA’s Goddard Space Flight Center (GSFC) operates a constellation of ten geosynchronous Tracking and Data Relay Satellites (TDRS). The mission of the TDRS constellation is to provide relay communications from low-earth orbiting spacecraft to the primary ground station at the White Sands Complex in Las Cruces, New Mexico. Major customers include the International Space Station and Hubble Space Telescope. The NASA Space Network project office at GSFC manages the constellation of spacecraft. The constellation is over 30 years old, and a wide range of technologies and manufacturing techniques are represented on-orbit. Since 1983, the TDRS constellation has recorded thousands of gigabytes of telemetry data. Spacecraft telemetry data has changed throughout the three generations of TDRS spacecraft, however each spacecraft has the same basic functions with some generational enhancements. The constellation includes several spacecraft that have significantly outlived the manufacturer's projected lifetime. This has provided NASA with a significant benefit in terms of return on investment, however it places a burden on efficient management of the assets for maximum life without permitting a TDRS spacecraft to become stranded in its geosynchronous orbital slot. Consequently, the highest level of attention is paid to systems whose failure could strand a TDRS spacecraft in orbit. In this paper, we proposed two stages of analyzing spacecraft anomalies using data mining (DM) to enhance on-going predictions of spacecraft life, subsystem performance, and analysis of subsystem anomalies. The first stage conducts the unsupervised anomaly detector to detect potential anomalies in real-time telemetry data. The second stage introduced telemetry weight (TW) to each telemetry parameter to determine which parameter caused the strongest anomaly. We will present case studies of some of these analyses and how the data can impact decisions on the management of the constellation.

Ma, Kenneth Y.↗

An Optimum Space-to-Ground Communication Concept for CubeSat Platform Utilizing NASA Space Network and Near Earth Network

National Aeronautics and Space Administration (NASA) CubeSat missions are expected to grow rapidly in the next decade. Higher data rate CubeSats are transitioning away from Amateur Radio bands to higher frequency bands. A high-level communication architecture for future space-to-ground CubeSat communication was proposed within NASA Goddard Space Flight Center. This architecture addresses CubeSat direct-to-ground communication, CubeSat to Tracking Data Relay Satellite System (TDRSS) communication, CubeSat constellation with Mothership direct-to-ground communication, and CubeSat Constellation with Mothership communication through K-Band Single Access (KSA).A Study has been performed to explore this communication architecture, through simulations, analyses, and identifying technologies, to develop the optimum communication concepts for CubeSat communications. This paper will present details of the simulation and analysis that include CubeSat swarm, daughter shipmother ship constellation, Near Earth Network (NEN) S and X-band direct to ground link, TDRS Multiple Access (MA) array vs Single Access mode, notional transceiverantenna configurations, ground asset configurations and Code Division Multiple Access (CDMA) signal trades for daughter mother CubeSat constellation inter-satellite crosslink. Results of Space Science X-band 10 MHz maximum achievable data rate study will be summarized. Assessment of Technology Readiness Level (TRL) of current CubeSat communication technologies capabilities will be presented. Compatibility test of the CubeSat transceiver through NEN and Space Network (SN) will be discussed. Based on the analyses, signal trade studies and technology assessments, the functional design and performance requirements as well as operation concepts for future CubeSat end-to-end communications will be derived.

CubeSat RF Communication↗

A Case for Bundle Protocol in Space

NASA, through the Advanced Exploration Systems (AES) project, is investing in the development and infusion of delay tolerant networking (DTN) protocols for use on future space flight missions. The cornerstone of the DTN suite is the Bundle Protocol which provides network layer addressing and routing of data blocks. In 2017, the Plankton, Aerosol, Cloud, and Ocean Ecosystem (PACE) mission was selected as the first in-house robotic science mission to implement the Bundle Protocol for downlink of housekeeping telemetry. One year into the design and incorporation of the Bundle Protocol on PACE, this presentation makes a case for using the Bundle Protocol for communication with future space assets. Specifically, the use of the Bundle Protocol (1) simplifies relaying data through store and forward routing and custody transfer; (2) simplifies downlink management through delivery guarantees; and (3) simplifies storage services through block level interactions with memory devices.

Swinski, J. P.↗

Recovery of the Space Shuttle Columbia Avionics

Lessons Learned: a) Avionics data can playa critical role in the investigation of a "close call" or accident. b) Avionics designers should think about the role their systems might play in an investigation. c) Know your data, down to the bit level. d) Know your spacecraft - follow the data. e) Internal placement of circuit cards can affect their survivability. f) Think about how to reconstruct nonvolatile memory (e.g. serialize IC's, etc.) g) Use of external assets can aid in extracting data from avionics.

Hames, Kevin L.↗

Climate Change Adaptation Activities at the NASA John F. Kennedy Space Center, FL., USA

In 2010, the Office of Strategic Infrastructure and Earth Sciences established the Climate Adaptation Science Investigators (CASI) program to integrate climate change forecasts and knowledge into sustainable management of infrastructure and operations needed for the NASA mission. NASA operates 10 field centers valued at $32 billion dollars, occupies 191,000 acres and employs 58,000 people. CASI climate change and sea-level rise forecasts focus on the 2050 and 2080 time periods. At the 140,000 acre Kennedy Space Center (KSC) data are used to simulate impacts on infrastructure, operations, and unique natural resources. KSC launch and processing facilities represent a valued national asset located in an area with high biodiversity including 33 species of special management concern. Numerical and advanced Bayesian and Monte Carlo statistical modeling is being conducted using LiDAR digital elevation models coupled with relevant GIS layers to assess potential future conditions. Results are provided to the Environmental Management Branch, Master Planning, Construction of Facilities, Engineering Construction Innovation Committee and our regional partners to support Spaceport development, management, and adaptation planning and design. Potential impacts to natural resources include conversion of 50% of the Center to open water, elevation of the surficial aquifer, alterations of rainfall and evapotranspiration patterns, conversion of salt marsh to mangrove forest, reductions in distribution and extent of upland habitats, overwash of the barrier island dune system, increases in heat stress days, and releases of chemicals from legacy contamination sites. CASI has proven successful in bringing climate change planning to KSC including recognition of the need to increase resiliency and development of a green managed shoreline retreat approach to maintain coastal ecosystem services while maximizing life expectancy of Center launch and payload processing resources.

plant communities↗

Initial Demonstration of the Real-Time Safety Monitoring Framework for the National Airspace System Using Flight Data

As new operational paradigms and additional aircraft are being introduced into the National Airspace System (NAS), maintaining safety in such a rapidly growing environment becomes more challenging. It is therefore desirable to have an automated framework to provide an overview of the current safety of the airspace at different levels of granularity, as well an understanding of how the state of the safety will evolve into the future given the anticipated flight plans, weather forecast, predicted health of assets in the airspace, and so on. Towards this end, as part of our earlier work, we formulated the Real-Time Safety Monitoring (RTSM) framework for monitoring and predicting the state of safety and to predict unsafe events. In our previous work, the RTSM framework was demonstrated in simulation on three different constructed scenarios. In this paper, we further develop the framework and demonstrate it on real flight data from multiple data sources. Specifically, the flight data is obtained through the Shadow Mode Assessment using Realistic Technologies for the National Airspace System (SMART-NAS) Testbed that serves as a central point of collection, integration, and access of information from these different data sources. By testing and evaluating using real-world scenarios, we may accelerate the acceptance of the RTSM framework towards deployment. In this paper we demonstrate the framework's capability to not only estimate the state of safety in the NAS, but predict the time and location of unsafe events such as a loss of separation between two aircraft, or an aircraft encountering convective weather. The experimental results highlight the capability of the approach, and the kind of information that can be provided to operators to improve their situational awareness in the context of safety.

Real-time Safety Monitoring↗

Autonomous Satellite Command and Control Through the World Wide Web

The Automated Space System Experimental Testbed (ASSET) system is a simple yet comprehensive real-world operations network being developed. Phase 3 of the ASSET Project was January-December 1997 and is the subject of this report. This phase permitted SSDL and its project partners to expand the ASSET system in a variety of ways. These added capabilities included the advancement of ground station capabilities, the adaptation of spacecraft on-board software, and the expansion of capabilities of the ASSET management algorithms. Specific goals of Phase 3 were: (1) Extend Web-based goal-level commanding for both the payload PI and the spacecraft engineer. (2) Support prioritized handling of multiple (PIs) Principle Investigators as well as associated payload experimenters. (3) Expand the number and types of experiments supported by the ASSET system and its associated spacecraft. (4) Implement more advanced resource management, modeling and fault management capabilities that integrate the space and ground segments of the space system hardware. (5) Implement a beacon monitoring test. (6) Implement an experimental blackboard controller for space system management. (7) Further define typical ground station developments required for Internet-based remote control and for full system automation of the PI-to-spacecraft link. Each of those goals are examined. Significant sections of this report were also published as a conference paper. Several publications produced in support of this grant are included as attachments. Titles include: 1) Experimental Initiatives in Space System Operations; 2) The ASSET Client Interface: Balancing High Level Specification with Low Level Control; 3) Specifying Spacecraft Operations At The Product/Service Level; 4) The Design of a Highly Configurable, Reusable Operating System for Testbed Satellites; 5) Automated Health Operations For The Sapphire Spacecraft; 6) Engineering Data Summaries for Space Missions; and 7) Experiments In Automated Health Assessment And Notification For The Sapphire Microsatellite.

Cantwell, Brian↗

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗

A Coordinated Effort to Address Space Weather and Environment Needs

The growing need for coordination of the many aspects of space environments is directly related to our increasing dependence on space assets. An obvious result is that there is a need for a coordinated effort to organize and make accessible the increasing number of space environment products that include space environment models and observations, material testing, and forecasting tools. This paper outlines a concept to establish a NASA-level Applied Spaceflight Environments (ASE) office that will provide coordination and funding for sustained multi-program support in three technical areas; (1) natural environments characterization and modeling, (2) environmental effects on materials and systems, (3) and operational and forecasting space environments modeling. Additionally the ASE office will serve as an entry point of contact for external users who wish to take advantage of data and assets associated with space environments, including space weather.

Minow, Joe↗

Challenges and Lessons Learned in the Application of Autonomy to Space Operations

NASA's Space Operations Management Office (SOMO) is working toward a goal of providing an integrated infrastructure of mission and data services for space missions undertaken by NASA enterprises. A significant portion of this effort is focused on reducing the cost of these services. We are interested in the potential of autonomy to reduce operations costs. SOMO services support space missions, but are not part of the mission objectives; therefore the level of acceptable risk is very low. In fact, SOMO could be effective ly prevented from applying autonomy if customers merely perceive it as adding risk to their mission(s). We are interested in this workshop from the standpoint of understanding what can be done to realize the potential cost savings due to autonomy while maintaining acceptable risk and serving the needs of our customers. We would like to present our lessons learned so far in adopting autonomy and automation, which we think will contribute to clarifying the challenges facing the use of such technology. SOMO provides services to a diverse and ambitious set of mission customers. Many of these missions are groundbreaking missions for which communications, data, and other operations requirements sometimes cannot be clearly articulated early in the program. This motivates a need for systems that are robust in the face of unanticipated situations so that customer missions are not unreasonably constrained or impacted by "shortcomings" in SOMO services. One of SOMO's primary goals is to realize a paradigm in which SOMO acts as a service provider to organizations that fly space missions for NASA, other government agencies, and even the commercial sector. These organizations purchase SOMO services "by the pound" as customers. We have to provide systems that are not experiments themselves, but rather stable bases from which to do bold experiments. To this end, SOMO also seeks to work closely with industry to see that robust autonomy technology gets infused into products and services for the space industry and beyond. The potential for application of these technologies spans space-based communications networks (e.g. TDRSS) and ground-based assets including communication and tracking antenna systems, data networks, and control centers. There are several problems that are candidates for the application of autonomy, if it can be made reliable enough, including: antenna control, antenna scheduling, communication link scheduling and operation, navigation, attitude determination, fault detection, isolation, and reconfiguration (for spacecraft or ground assets), and mission-level planning and scheduling. Some attempts have been made to apply autonomy and automation in these areas in the past with varying degrees of success. We will present relevant case histories and the lessons inferred from them. Combining this past experience with anticipated future needs, we can clarify the challenges that must be met in order to realize the benefits of autonomy.

Forrest, David J.↗