Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “communication protocols”

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 127 records · Page 7
All sourcesNASA NTRSDOE OSTI
NASA NTRS1992

Telescience Testbed Program: A study of software for SIRTF instrument control

As a continued element in the Telescience Testbed Program (TTP), the University of Arizona Steward Observatory and the Electrical and Computer Engineering Department (ECE) jointly developed a testbed to evaluate the Operations and Science Instrument System (OASIS) software package for remote control of an instrument for the Space Infrared Telescope Facility (SIRTF). SIRTF is a cryogenically-cooled telescope with three focal plane instruments that will be the infrared element of NASA's Great Observatory series. The anticipated launch date for SIRTF is currently 2001. Because of the complexity of the SIRTF mission, it was not expected that the OASIS package would be suitable for instrument control in the flight situation, however, its possible use as a common interface during the early development and ground test phases of the project was considered. The OASIS package, developed at the University of Colorado for control of the Solar Mesosphere Explorer (SME) satellite, serves as an interface between the operator and the remote instrument which is connected via a network. OASIS provides a rudimentary windowing system as well as support for standard spacecraft communications protocols. The experiment performed all of the functions required of the MIPS simulation program. Remote control of the instrument was demonstrated but found to be inappropriate for SIRTF at this time for the following reasons: (1) programming interface is too difficult; (2) significant computer resources were required to run OASIS; (3) the communications interface is too complicated; (4) response time was slow; and (5) quicklook of image data was not possible.

Young, Erick T.↗
NASA NTRS1989

Coordinating the activities of a planner and an execution agent

A research program was defined that will explore the link between planning and execution systems. A simple scenario was defined in which a very capable off-line planning system interacts with the user and a smaller, less capable, on-line real-time system executing plans and reacting to faults. However, the on-line execution system may have a more flexible representation of the plans it is executing. This imbalance in the capabilities of the two agents involved should clarify some of the research objectives and give an experimental framework for the work. The task is to investigate the knowledge representations and communication protocols needed to link a user stating some requirements for a task to be carried out through a planning system to the (remote) execution agent that can carry out the user's wishes. The notion that a single representation can encapsulate the expression of the user's requirements, the capabilities for action, the communication to the execution agent, the successful or faulty response from the execution agent and the means of keeping the user informed, is examined. Methods of creating plan patches to update the plans separately held by each of the parties involved to keep them in step as they each react to changing circumstances in real-time is investigated. This involves the specification of plan patch attachment points that can be understood by the recipient. Transaction based methods are also investigated for coordinating the activities of the planner with those of the execution agent and user. The trial application area for the research is in the command and control of an advanced Earth Observation Space Platform.

Tate, Austin↗
NASA NTRS1987

Considerations for Multiprocessor Topologies

Choosing a multiprocessor interconnection topology may depend on high-level considerations, such as the intended application domain and the expected number of processors. It certainly depends on low-level implementation details, such as packaging and communications protocols. The authors first use rough measures of cost and performance to characterize several topologies. They then examine how implementation details can affect the realizable performance of a topology.

INTERPROCESSOR COMMUNICATION↗
NASA NTRS2016

Future Standardization of Space Telecommunications Radio System with Core Flight System

NASA Glenn Research Center (GRC) is integrating the NASA Space Telecommunications Radio System (STRS) Standard with the Core Flight System (cFS). The STRS standard provides a common, consistent framework to develop, qualify, operate and maintain complex, reconfigurable and reprogrammable radio systems. The cFS is a flexible, open architecture that features a plug-and-play software executive called the Core Flight Executive (cFE), a reusable library of software components for flight and space missions and an integrated tool suite. Together, STRS and cFS create a development environment that allows for STRS compliant applications to reference the STRS APIs through the cFS infrastructure. These APis are used to standardize the communication protocols on NASAs space SDRs. The cFE-STRS Operating Environment (OE) is a portable cFS library, which adds the ability to run STRS applications on existing cFS platforms. The purpose of this paper is to discuss the cFE-STRS OE prototype, preliminary experimental results performed using the Advanced Space Radio Platform (ASRP), the GRC Sband Ground Station and the SCaN (Space Communication and Navigation) Testbed currently flying onboard the International Space Station. Additionally, this paper presents a demonstration of the Consultative Committee for Space Data Systems (CCSDS) Spacecraft Onboard Interface Services (SOIS) using electronic data sheets inside cFE. This configuration allows for the data sheets to specify binary formats for data exchange between STRS applications. The integration of STRS with cFS leverages mission-proven platform functions and mitigates barriers to integration with future missions. This reduces flight software development time and the costs of software-defined radio (SDR) platforms. Furthermore, the combined benefits of STRS standardization with the flexibility of cFS provide an effective, reliable and modular framework to minimize software development efforts for spaceflight missions.

space communications↗
NASA NTRS2016

Future Standardization of Space Telecommunications Radio System with Core Flight System

NASA Glenn Research Center (GRC) is integrating the NASA Space Telecommunications Radio System (STRS) Standard with the Core Flight System (cFS), an avionics software operating environment. The STRS standard provides a common, consistent framework to develop, qualify, operate and maintain complex, reconfigurable and reprogrammable radio systems. The cFS is a flexible, open architecture that features a plugand- play software executive called the Core Flight Executive (cFE), a reusable library of software components for flight and space missions and an integrated tool suite. Together, STRS and cFS create a development environment that allows for STRS compliant applications to reference the STRS application programmer interfaces (APIs) that use the cFS infrastructure. These APIs are used to standardize the communication protocols on NASAs space SDRs. The cFS-STRS Operating Environment (OE) is a portable cFS library, which adds the ability to run STRS applications on existing cFS platforms. The purpose of this paper is to discuss the cFS-STRS OE prototype, preliminary experimental results performed using the Advanced Space Radio Platform (ASRP), the GRC S‑ band Ground Station and the SCaN (Space Communication and Navigation) Testbed currently flying onboard the International Space Station (ISS). Additionally, this paper presents a demonstration of the Consultative Committee for Space Data Systems (CCSDS) Spacecraft Onboard Interface Services (SOIS) using electronic data sheets (EDS) inside cFE. This configuration allows for the data sheets to specify binary formats for data exchange between STRS applications. The integration of STRS with cFS leverages mission-proven platform functions and mitigates barriers to integration with future missions. This reduces flight software development time and the costs of software-defined radio (SDR) platforms. Furthermore, the combined benefits of STRS standardization with the flexibility of cFS provide an effective, reliable and modular framework to minimize software development efforts for spaceflight missions.

space communications↗
NASA NTRSDate not supplied

Evaluation of Initial and Mid-Term Air Traffic Procedures for Urban Air Mobility Operations

Urban air mobility (UAM) operations are expected to expand in scale over the next several years as novel aircraft types, including electric vertical takeoff and landing aircraft, are certified and begin operations. These new aircraft may increase safety, decrease noise, and lower operating costs compared with helicopters, allowing them to operate in ways existing aircraft do not. It is vital that these expanded operations are compatible with and do not disrupt existing operations or the air traffic management system. To study the ways in which scaled UAM operations can best integrate in the national airspace system, NASA and Joby Aviation partnered to conduct a high-fidelity air traffic controller-in-the-loop study. Building on air traffic procedures used to manage high tempo operations in other parts of the airspace, new procedures, routes, and communications protocols were developed and tested by retired controllers in NASA’s Future Flight Central tower simulation facility. In addition, new cooperative airspace constructs in the form of corridors were developed to understand their potential contributions to even greater scales of operation. The controllers managed traffic scenarios in the Dallas-Fort Worth and Dallas Love Field airports consisting of fleets of up to 100 UAM aircraft operating alongside traditional traffic . Metrics for air traffic controller workload, duration of communications, departure delays, and other measures of allowable aircraft throughput were collected. The analysis indicates that using today’s procedures for initial UAM operations under nominal conditions could enable up to 40 operations per hour to an airport’s central terminal area if that involved crossing a runway and up to 55operations per hour if reaching the central terminal did not involve crossing a runway. Operations at these tempos did not delay or otherwise interfere with simulated runway traffic and were rated acceptable by the air traffic controllers. The new corridor constructs dramatically lowered controller workload in certain circumstances, suggesting they may be effective in further increasing the allowable scale of operations.

Urban Air Mobility↗
NASA NTRSDate not supplied

Evaluation of Initial and Mid-Term Air Traffic Procedures for Urban Air Mobility

Urban air mobility (UAM) operations are expected to expand in scale over the next several years as novel aircraft types, including electric vertical takeoff and landing aircraft, are certified and begin operations. These new aircraft may increase safety, decrease noise, and lower operating costs compared with helicopters, allowing them to operate in ways existing aircraft do not. It is vital that these expanded operations are compatible with and do not disrupt existing operations or the air traffic management system. To study the ways in which scaled UAM operations can best integrate in the national airspace system, NASA and Joby Aviation partnered to conduct a high-fidelity air traffic controller-in-the-loop study. Building on air traffic procedures used to manage high tempo operations in other parts of the airspace, new procedures, routes, and communications protocols were developed and tested by retired controllers in NASA’s Future Flight Central tower simulation facility. In addition, new cooperative airspace constructs in the form of corridors were developed to understand their potential contributions to even greater scales of operation. The controllers managed traffic scenarios in the Dallas-Fort Worth and Dallas Love Field airports consisting of fleets of up to 100 UAM aircraft operating alongside traditional traffic. Metrics for air traffic controller workload, duration of communications, departure delays, and other measures of allowable aircraft throughput were collected. The analysis indicates that using today’s procedures for initial UAM operations under nominal conditions could enable up to 40 operations per hour to an airport’s central terminal area if that involved crossing a runway and up to 55 operations per hour if reaching the central terminal did not involve crossing a runway. Operations at these tempos did not delay or otherwise interfere with simulated runway traffic and were rated acceptable by the air traffic controllers. The new corridor constructs dramatically lowered controller workload in certain circumstances, suggesting they may be effective in further increasing the allowable scale of operations.

Advanced Air Mobility↗
NASA NTRS1981

The role of pilots

The need for detailed specifications is addressed. Candidates for standardization include hardware interfaces, communication protocols, and data exchange services. Atmosphere, Ocean, and Resource pilot programs, utilization of current techniques and technologies in the use and exchange of data and to facilitate access to data are discussed. Pilot objectives aim to: (1) demonstrate the use of advanced technologies, (2) provide a test bed environment for data handling technique evaluation, (3) evolve requirements and capabilities, and (4) document validated methodologies as standards and guidelines for data systems planning use. A user oriented catalog system, data set management, a network communication system, and a user interface are also discussed.

Gary, J. P.↗
NASA NTRS1998

High End Computer Network Testbedding at NASA Goddard Space Flight Center

The Earth & Space Data Computing (ESDC) Division, at the Goddard Space Flight Center, is involved in development and demonstrating various high end computer networking capabilities. The ESDC has several high end super computers. These are used to run: (1) computer simulation of the climate systems; (2) to support the Earth and Space Sciences (ESS) project; (3) to support the Grand Challenge (GC) Science, which is aimed at understanding the turbulent convection and dynamos in stars. GC research occurs in many sites throughout the country, and this research is enabled by, in part, the multiple high performance network interconnections. The application drivers for High End Computer Networking use distributed supercomputing to support virtual reality applications, such as TerraVision, (i.e., three dimensional browser of remotely accessed data), and Cave Automatic Virtual Environments (CAVE). Workstations can access and display data from multiple CAVE's with video servers, which allows for group/project collaborations using a combination of video, data, voice and shared white boarding. The ESDC is also developing and demonstrating the high degree of interoperability between satellite and terrestrial-based networks. To this end, the ESDC is conducting research and evaluations of new computer networking protocols and related technologies which improve the interoperability of satellite and terrestrial networks. The ESDC is also involved in the Security Proof of Concept Keystone (SPOCK) program sponsored by National Security Agency (NSA). The SPOCK activity provides a forum for government users and security technology providers to share information on security requirements, emerging technologies and new product developments. Also, the ESDC is involved in the Trans-Pacific Digital Library Experiment, which aims to demonstrate and evaluate the use of high performance satellite communications and advanced data communications protocols to enable interactive digital library data access between the U. S. Library of Congress, the National Library of Japan and other digital library sites at 155 MegaBytes Per Second. The ESDC participation in this program is the Trans-Pacific access to GLOBE visualizations in real time. ESDC is participating in the Department of Defense's ATDNet with Multiwavelength Optical Network (MONET) a fully switched Wavelength Division Networking testbed. This presentation is in viewgraph format.

Gary, James Patrick↗
NASA NTRS2006

X-Windows Information Sharing Protocol Widget Class

The X-Windows Information Sharing Protocol (ISP) Widget Class ("Class") is used here in the object-oriented-programming sense of the word) was devised to simplify the task of implementing ISP graphical-user-interface (GUI) computer programs. ISP programming tasks require many method calls to identify, query, and interpret the connections and messages exchanged between a client and an ISP server. Most X-Windows GUI programs use widget sets or toolkits to facilitate management of complex objects. The widget standards facilitate construction of toolkits and application programs. The X-Windows Information Sharing Protocol (ISP) Widget Class encapsulates the client side of the ISP programming libraries within the framework of an X-Windows widget. Using the widget framework, X-Windows GUI programs can interact with ISP services in an abstract way and in the same manner as that of other graphical widgets, making it easier to write ISP GUI client programs. Wrapping ISP client services inside a widget framework enables a programmer to treat an ISP server interface as though it were a GUI. Moreover, an alternate subclass could implement another communication protocol in the same sort of widget.

Barry, Matthew R.↗
NASA NTRS1990

The ISIS project: Fault-tolerance in large distributed systems

The semi-annual status report covers activities of the ISIS project during the second half of 1989. The project had several independent objectives: (1) At the level of the ISIS Toolkit, ISIS release V2.0 was completed, containing bypass communication protocols. Performance of the system is greatly enhanced by this change, but the initial software release is limited in some respects. (2) The Meta project focused on the definition of the Lomita programming language for specifying rules that monitor sensors for conditions of interest and triggering appropriate reactions. This design was completed, and implementation of Lomita is underway on the Meta 2.0 platform. (3) The Deceit file system effort completed a prototype. It is planned to make Deceit available for use in two hospital information systems. (4) A long-haul communication subsystem project was completed and can be used as part of ISIS. This effort resulted in tools for linking ISIS systems on different LANs together over long-haul communications lines. (5) Magic Lantern, a graphical tool for building application monitoring and control interfaces, is included as part of the general ISIS releases.

Birman, Kenneth P.↗
NASA NTRSDate not supplied

Desert Research and Technology Studies (D-RATS) 2022 Quicklook Report

This report summarizes the Desert Research and Technology Studies (D-RATS) 2022 analog tests. BACKGROUND - Artemis Challenges – NASA’s concept of operations (ConOps) for the Artemis mission architecture brings new challenges for human exploration of the lunar surface, including: (1) Low-angle, natural lighting at lunar poles; and (2) Exploration sites that challenge communication with Earth. - International Partner Involvement – NASA is working with the Japan Aerospace Exploration Agency (JAXA) to scope mission & functional requirements for an Artemis Pressurized Rover (PR), which JAXA may provide. - Charter – HQ Exploration Systems Development Mission Directorate (ESDMD) Moon to Mars Architecture Development Office (M2MADO) Strategy and Architectures (SA) chartered the Human-in-the-Loop (HITL) test team to investigate Artemis architectural questions related to pressurized rover ConOps. - Rationale – to inform the NASA/JAXA pressurized rover study-agreement. PLAN - Objectives – Analog tests conducted in October 2022 by the D-RATS team addressed three high-level objectives: 1. Investigate pressurized rover (PR) ConOps and capabilities for Artemis exploration 2. Integrate with JAXA engineers & astronauts and incorporate JAXA PR design elements into testing. 3. Re-establish analog field-testing skills & capabilities with rovers to investigate Artemis architecture ConOps. - Secondary Objectives – Work with other groups to leverage D-RATS field test for additional objectives. 4. Work with the Public Affairs Office (PAO) to perform D-RATS public outreach activities. 5. Coordinate with the Human Physiology Performance Protection & Operations (H-3PO) team to facilitate in-field evaluation of human health and performance (HHP) objectives. 6. Share D-RATS field-site and assets with Lunar LTE Studies (Lunar LiTES) team, to aid their study of the use of 4G/LTE communication protocols and devices for astronauts and robotic nodes on the lunar surface. - Team – Fully integrated test team comprised of members from 5 NASA centers, JAXA, and the United States Geological Survey (USGS) - Location – Black Point Lava Flow, ~40 miles north of Flagstaff, AZ HIGH-LEVEL OBJECTIVES ACCOMPLISHED - Investigated Pressurized Rover ConOps & Capabilities for Artemis Exploration (Objective 1) - Completed testing with 4 crew pairs, each spending 3 days and 2 nights in the rover conducting Artemis PR dayin-the-life activities (2 JAXA astronauts, 2 JAXA engineers, 1 NASA astronaut, 3 NASA engineers). - Collected detailed objective & subjective data supporting 10 strategic questions related to Artemis PR operations. - Field geologists present in field observed rover operations & EVAs. - Science team in Houston MCC communicated directly with crew. - Demonstrated crew-led and MCC-led PR teleoperation use cases during EVAs. - Integrated with JAXA Engineers & Astronauts and Incorporated JAXA PR Design Elements into Testing (Objective 2) - NASA & JAXA engineers, flight controllers, scientists, roboticists, and astronauts directly participated in and/or observed testing both in field and in MCC-Houston. - Incorporated JAXA PR design elements into both integrated and standalone testing at JSC and in the field. - Re-established Analog Field-Testing Skills & Capabilities with Rovers to Investigate Artemis Architecture ConOps (Objective 3) - Multiple teams successfully worked to establish and manage field-test base camp, monitor and maintain the rover, and plan and execute 2 weeks of consecutive field-testing with little to no breaks between crews. TEST OUTCOMES - Results will inform Artemis architecture ConOps & capabilities related to pressurized rover operations (see sections 2 for more details) - Summary and team detailed reports will be posted on the D-RATS 2022 wiki

Analog↗
NASA NTRS2004

Using software security analysis to verify the secure socket layer (SSL) protocol

nal Aeronautics and Space Administration (NASA) have tens of thousands of networked computer systems and applications. Software Security vulnerabilities present risks such as lost or corrupted data, information the3, and unavailability of critical systems. These risks represent potentially enormous costs to NASA. The NASA Code Q research initiative 'Reducing Software Security Risk (RSSR) Trough an Integrated Approach '' offers, among its capabilities, formal verification of software security properties, through the use of model based verification (MBV) to address software security risks. [1,2,3,4,5,6] MBV is a formal approach to software assurance that combines analysis of software, via abstract models, with technology, such as model checkers, that provide automation of the mechanical portions of the analysis process. This paper will discuss: The need for formal analysis to assure software systems with respect to software and why testing alone cannot provide it. The means by which MBV with a Flexible Modeling Framework (FMF) accomplishes the necessary analysis task. An example of FMF style MBV in the verification of properties over the Secure Socket Layer (SSL) communication protocol as a demonstration.

software↗
NASA NTRS2010

Atrial Fibrillation During an Exploration Class Mission

Background: A long-duration exploration class mission is fraught with numerous medical contingency plans. Herein, we explore the challenges of symptomatic atrial fibrillation (AF) occurring during an exploration class mission. The actions and resources required to ameliorate the situation, including the availability of appropriate pharmaceuticals, monitoring devices, treatment modalities, and communication protocols will be investigated. Challenges of Atrial Fibrillation during an Exploration Mission: Numerous etiologies are responsible for the initiation of AF. On Earth, we have the time and medical resources to evaluate and determine the causative situation for most cases of AF and initiate therapy accordingly. During a long-duration exploration class mission resources will be severely restricted. How is one to determine if new onset AF is due to recent myocardial infarction, pulmonary embolism, fluid overload, thyrotoxicosis, cardiac structural abnormalities, or CO poisoning? Which pharmaceutical therapy should be initiated and what potential side effects can be expected? Should anti-coagulation therapy be initiated? How would one monitor the therapeutic treatment of AF in microgravity? What training would medical officers require, and which communication strategies should be developed to enable the best, safest therapeutic options for treatment of AF during a long-duration exploration class mission? Summary: These questions will be investigated with expert opinion on disease elucidation, efficient pharmacology, therapeutic monitoring, telecommunication strategies, and mission cost parameters with emphasis on atrial fibrillation being just one illustration of the tremendous challenges that face a long-duration exploration mission. The limited crew training time, medical hardware, and drugs manifested to deal with such an event predicate that aggressive primary and secondary prevention strategies be developed to protect a multibillion-dollar asset like the International Space Station or a mission to the Moon or Mars. Learning Objectives: The audience will become familiar with the risks and challenges inherent to developing a therapeutic strategy for the treatment of atrial fibrillation during a long-term exploration class mission.

Lipset, Mark A.↗
NASA NTRS1994

SCL: An off-the-shelf system for spacecraft control

In this age of shrinking military, civil, and commercial space budgets, an off-the-shelf solution is needed to provide a multimission approach to spacecraft control. A standard operational interface which can be applied to multiple spacecraft allows a common approach to ground and space operations. A trend for many space programs has been to reduce operational staff by applying autonomy to the spacecraft and to the ground stations. The Spacecraft Command Language (SCL) system developed by Interface and Control Systems, Inc. (ICS) provides an off-the-shelf solution for spacecraft operations. The SCL system is designed to provide a hyper-scripting interface which remains standard from program to program. The spacecraft and ground station hardware specifics are isolated to provide the maximum amount of portability from system to system. Uplink and downlink interfaces are also isolated to allow the system to perform independent of the communications protocols chosen. The SCL system can be used for both the ground stations and the spacecraft, or as a value added package for existing ground station environments. The SCL system provides an expanded stored commanding capability as well as a rule-based expert system on-board. The expert system allows reactive control on-board the spacecraft for functions such as electrical power systems (EPS), thermal control, etc. which have traditionally been performed on the ground. The SCL rule and scripting capability share a common syntax allowing control of scripts from rules and rules from scripts. Rather than telemeter over sampled data to the ground, the SCL system maintains a database on-board which is available for interrogation by the scripts and rules. The SCL knowledge base is constructed on the ground and uploaded to the spacecraft. The SCL system follows an open-systems approach allowing other tasks to communicate with SCL on the ground and in space. The SCL system was used on the Clementine program (launched January 25, 1994) and is required to have bidirectional communications with the guidance, navigation, and control (GNC) algorithms which were written as another task. Sequencing of the spacecraft maneuvers are handled by SCL, but the low-level thruster pulse commands are handled by the GNC software. Attitude information is reported back as telemetry, allowing the SCL expert system to inference on the changing data. The Clementine SCL flight software was largely reused from another Naval Center for Space Technology (NCST) satellite program. This paper details the SCL architecture and how an off-the-shelf solution makes sense for multimission spacecraft programs. The Clementine mission will be used as a case study in the application of the SCL to a 'fast track' program. The benefits of such a system in a 'better, cheaper, faster' climate will be discussed.

Buckley, Brian↗
NASA NTRS2005

The Development of Real-Time Physiological Monitoring and Training Software for Remote Applications

Autogenic Feedback Training Exercise (AFTE) is an protocol and technology developed by Dr. Patricia Cowings and her associates at NASA Ames Research Center as a means to facilitate astronaut adaptation to space and exposure to the microgravity. AFTE is a training method which involves teaching subjects to voluntarily control several of their own physiological responses to environmental stressors. As the procedures matured, the training program was expanded to determine if technology developed to facilitate astronaut adaptation to space would be valuable in treating patients suffering from autonomic and vestibular pathologies and symptomatic relief from nausea and/or blood pressure control anomalies such as hypo- or hypertension. The present study, performed in conjunction with Morehouse School of Medicine, Biomedical Engineering at The University of Akron and NASA Ames Research Center has demonstrated that this technology can be successfully applied over vast distances. The specific purpose of this research was to develop a PC based system which could handle processing of twenty channels of acquired physiological data in addition to the necessary duplex communication protocols that would, for example, permit a patient in Atlanta, GA to be trained by a clinician stationed in San Jose, CA. Sixteen channels of physiological data and 20 channels of processed data are included.

Source record↗
NASA NTRS2014

Using Social Media and Mobile Devices to Discover and Share Disaster Data Products Derived From Satellites

Data products derived from Earth observing satellites are difficult to find and share without specialized software and often times a highly paid and specialized staff. For our research effort, we endeavored to prototype a distributed architecture that depends on a standardized communication protocol and applications program interface (API) that makes it easy for anyone to discover and access disaster related data. Providers can easily supply the public with their disaster related products by building an adapter for our API. Users can use the API to browse and find products that relate to the disaster at hand, without a centralized catalogue, for example floods, and then are able to share that data via social media. Furthermore, a longerterm goal for this architecture is to enable other users who see the shared disaster product to be able to generate the same product for other areas of interest via simple point and click actions on the API on their mobile device. Furthermore, the user will be able to edit the data with on the ground local observations and return the updated information to the original repository of this information if configured for this function. This architecture leverages SensorWeb functionality [1] presented at previous IGARSS conferences. The architecture is divided into two pieces, the frontend, which is the GeoSocial API, and the backend, which is a standardized disaster node that knows how to talk to other disaster nodes, and also can communicate with the GeoSocial API. The GeoSocial API, along with the disaster node basic functionality enables crowdsourcing and thus can leverage insitu observations by people external to a group to perform tasks such as improving water reference maps, which are maps of existing water before floods. This can lower the cost of generating precision water maps. Keywords-Data Discovery, Disaster Decision Support, Disaster Management, Interoperability, CEOS WGISS Disaster Architecture

0↗
NASA NTRS1980

Binary synchronous simulator

Flexible simulator for trouble-shooting data transmission system uses binary synchronous communications protocol to produce error-free transmission of data between two points. Protocol may be used to replace display generator or be directly fed to display generator.

Rogers, J. R., III↗