Search NASA⌕ Search

SEARCH · Search NASA

Results for “security software networking”

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.

106 records · Page 6

Making Sense of Remotely Sensed Ultra-Spectral Infrared Data

NASA's Jet Propulsion Laboratory (JPL), Pasadena, California, Earth Observing System (EOS) programs, the Deep Space Network (DSN), and various Department of Defense (DOD) technology demonstration programs, combined their technical expertise to develop SEASCRAPE, a software program that obtains data when thermal infrared radiation passes through the Earth's atmosphere and reaches a sensor. Licensed by the California Institute of Technology (Caltech), SEASCRAPE automatically inverts complex infrared data and makes it possible to obtain estimates of the state of the atmosphere along the ray path. Former JPL staff members created a small entrepreneurial firm, Remote Sensing Analysis Systems, Inc., of Altadena, California, to commercialize the product. The founders believed that a commercial version of the software was needed for future U.S. government missions and the commercial monitoring of pollution. With the inversion capability of this software and remote sensing instrumentation, it is possible to monitor pollution sources from safe and secure distances on a noninterfering, noncooperative basis. The software, now know as SEASCRAPE_Plus, allows the user to determine the presence of pollution products, their location and their abundance along the ray path. The technology has been cleared by the Department of Commerce for export, and is currently used by numerous research and engineering organizations around the world.

Source record↗

The Database Query Support Processor (QSP)

The number and diversity of databases available to users continues to increase dramatically. Currently, the trend is towards decentralized, client server architectures that (on the surface) are less expensive to acquire, operate, and maintain than information architectures based on centralized, monolithic mainframes. The database query support processor (QSP) effort evaluates the performance of a network level, heterogeneous database access capability. Air Force Material Command's Rome Laboratory has developed an approach, based on ANSI standard X3.138 - 1988, 'The Information Resource Dictionary System (IRDS)' to seamless access to heterogeneous databases based on extensions to data dictionary technology. To successfully query a decentralized information system, users must know what data are available from which source, or have the knowledge and system privileges necessary to find out this information. Privacy and security considerations prohibit free and open access to every information system in every network. Even in completely open systems, time required to locate relevant data (in systems of any appreciable size) would be better spent analyzing the data, assuming the original question was not forgotten. Extensions to data dictionary technology have the potential to more fully automate the search and retrieval for relevant data in a decentralized environment. Substantial amounts of time and money could be saved by not having to teach users what data resides in which systems and how to access each of those systems. Information describing data and how to get it could be removed from the application and placed in a dedicated repository where it belongs. The result simplified applications that are less brittle and less expensive to build and maintain. Software technology providing the required functionality is off the shelf. The key difficulty is in defining the metadata required to support the process. The database query support processor effort will provide quantitative data on the amount of effort required to implement an extended data dictionary at the network level, add new systems, adapt to changing user needs, and provide sound estimates on operations and maintenance costs and savings.

Source record↗

A Central Asia Hydrologic Monitoring Dataset for Food and Water Security Applications in Afghanistan

From the Hindu Kush mountains to the Registan Desert, Afghanistan is a diverse landscape where droughts, floods, conflict, and economic market accessibility pose challenges for agricultural livelihoods and food security. The ability to remotely monitor environmental conditions is critical to support decision making for humanitarian assistance. The Famine Early Warning Systems Network (FEWS NET) Land Data Assimilation System (FLDAS) global and Central Asia data streams provide information on hydrologic states for routine integrated food security analysis. While developed for a specific project, these data are publicly available and useful for other applications that require hydrologic estimates of the water and energy balance. These two data streams are unique because of their suitability for routine monitoring, as well as for being a historical record for computing relative indicators of water availability. The global stream is available at ∼ 1-month latency, and monthly average outputs are on a 10 km grid from 1982–present. The second data stream, Central Asia (21–56°N, 30–100°E), at ∼ 1 d latency, provides daily average outputs on a 1 km grid from 2000–present. This paper describes the configuration of the two FLDAS data streams, background on the software modeling framework, selected meteorological inputs and parameters, and results from previous evaluation studies. We also provide additional analysis of precipitation and snow cover over Afghanistan. We conclude with an example of how these data are used in integrated food security analysis. For use in new and innovative studies that will improve understanding of this region, these data are hosted by U.S. Geological Survey data portals and the National Aeronautics and Space Administration (NASA). The Central Asia data described in this paper can be accessed via the NASA repository at https://doi.org/10.5067/VQ4CD3Y9YC0R (Jacob and Slinski, 2021), and the global data described in this paper can be accessed via the NASA repository at https://doi.org/10.5067/5NHC22T9375G (McNally, 2018).

Amy McNally↗

Station Program Note Pull Automation

Upon commencement of my internship, I was in charge of maintaining the CoFR (Certificate of Flight Readiness) Tool. The tool acquires data from existing Excel workbooks on NASA's and Boeing's databases to create a new spreadsheet listing out all the potential safety concerns for upcoming flights and software transitions. Since the application was written in Visual Basic, I had to learn a new programming language and prepare to handle any malfunctions within the program. Shortly afterwards, I was given the assignment to automate the Station Program Note (SPN) Pull process. I developed an application, in Python, that generated a GUI (Graphical User Interface) that will be used by the International Space Station Safety & Mission Assurance team here at Johnson Space Center. The application will allow its users to download online files with the click of a button, import SPN's based on three different pulls, instantly manipulate and filter spreadsheets, and compare the three sources to determine which active SPN's (Station Program Notes) must be reviewed for any upcoming flights, missions, and/or software transitions. Initially, to perform the NASA SPN pull (one of three), I had created the program to allow the user to login to a secure webpage that stores data, input specific parameters, and retrieve the desired SPN's based on their inputs. However, to avoid any conflicts with sustainment, I altered it so that the user may login and download the NASA file independently. After the user has downloaded the file with the click of a button, I defined the program to check for any outdated or pre-existing files, for successful downloads, to acquire the spreadsheet, convert it from a text file to a comma separated file and finally into an Excel spreadsheet to be filtered and later scrutinized for specific SPN numbers. Once this file has been automatically manipulated to provide only the SPN numbers that are desired, they are stored in a global variable, shown on the GUI, and transferred over to a new Excel worksheet for comparison. I managed to get my application to acquire the CSWG (Computer Safety Working Group) and the SPNWG (Space Station Working Group) SPN's with just two mouse clicks for each pull, as opposed to several from the original process. When all three pulls are performed, an Excel sheet containing all three different results will be generated for the user to compare and determine which SPN's will be presented or reviewed the following month. The experience from this internship has been spectacular. As a high school senior who will begin attending college in the fall, this internship has been both educationally and occupationally beneficial. The internship has allowed me the opportunities to learn new programming languages, effectively network with NASA personnel from a variety of departments at JSC, and allowed me to learn new professional skills and etiquette. My internship at NASA's Johnson Space Center has further motivated me to pursue a Master's degree in Software Engineering and strive for a prosperous career with NASA as a civil servant.

Delgado, Ivan↗

Re-Engineering the Multimission Command System at the Jet Propulsion Laboratory

This paper will discuss the design and implementation of the command software, especially trade-offs and lessons learned from practical operational use in JPL's Advanced Multimission Operations System.The command system provides an advanced multimission environment for secure, concurrent commanding of multiple spacecraft. The lessons learned have resulted in a re-engineering of the command system, especially in its user interface and new automation capabilities. This paper will also discuss new development work including a multimission command database toolkit, a universal command translator for sequencing and real-time commands, and incorporation of telecommand capabilities for new missions.

re-engineering↗

Virtualization - A Key Cost Saver in NASA Multi-Mission Ground System Architecture

With science team budgets being slashed, and a lack of adequate facilities for science payload teams to operate their instruments, there is a strong need for innovative new ground systems that are able to provide necessary levels of capability processing power, system availability and redundancy while maintaining a small footprint in terms of physical space, power utilization and cooling.The ground system architecture being presented is based off of heritage from several other projects currently in development or operations at Goddard, but was designed and built specifically to meet the needs of the Science and Planetary Operations Control Center (SPOCC) as a low-cost payload command, control, planning and analysis operations center. However, this SPOCC architecture was designed to be generic enough to be re-used partially or in whole by other labs and missions (since its inception that has already happened in several cases!)The SPOCC architecture leverages a highly available VMware-based virtualization cluster with shared SAS Direct-Attached Storage (DAS) to provide an extremely high-performing, low-power-utilization and small-footprint compute environment that provides Virtual Machine resources shared among the various tenant missions in the SPOCC. The storage is also expandable, allowing future missions to chain up to 7 additional 2U chassis of storage at an extremely competitive cost if they require additional archive or virtual machine storage space.The software architecture provides a fully-redundant GMSEC-based message bus architecture based on the ActiveMQ middleware to track all health and safety status within the SPOCC ground system. All virtual machines utilize the GMSEC system agents to report system host health over the GMSEC bus, and spacecraft payload health is monitored using the Hammers Integrated Test and Operations System (ITOS) Galaxy Telemetry and Command (TC) system, which performs near-real-time limit checking and data processing on the downlinked data stream and injects messages into the GMSEC bus that are monitored to automatically page the on-call operator or Systems Administrator (SA) when an off-nominal condition is detected. This architecture, like the LTSP thin clients, are shared across all tenant missions.Other required IT security controls are implemented at the ground system level, including physical access controls, logical system-level authentication authorization management, auditing and reporting, network management and a NIST 800-53 FISMA-Moderate IT Security plan Risk Assessment Contingency Plan, helping multiple missions share the cost of compliance with agency-mandated directives.The SPOCC architecture provides science payload control centers and backup mission operations centers with a cost-effective, standardized approach to virtualizing and monitoring resources that were traditionally multiple racks full of physical machines. The increased agility in deploying new virtual systems and thin client workstations can provide significant savings in personnel costs for maintaining the ground system. The cost savings in procurement, power, rack footprint and cooling as well as the shared multi-mission design greatly reduces upfront cost for missions moving into the facility. Overall, the authors hope that this architecture will become a model for how future NASA operations centers are constructed!

Ground System Architecture↗

NASA IV&V's Cyber Range for Space Systems

A cyber range is a virtual environment that is used for cyberwarfare training and cyber technology development. It provides tools that help strengthen the stability, security and performance of cyber infrastructures and IT systems. NASA IV&V has created an adaptable virtual environment that is representative of a typical NASA mission system of systems environment that serves multiple purposes: Training of network defenders. Ability to perform simulated red vs blue training events. Ability to deploy mission specific technologies in a cyber contested environment. Ability to demonstrate vulnerabilities and their impact to ground and space systemsThe overall system is comprised of more than 70 virtual machines and physical infrastructure to demonstrate real-world cyber attacks against: email users, wireless networks, and physically implanted devices with command and control call-back. The cyber range was built to emulate a NASA precipitation satellite infrastructure.This presentation will give an overview of the virtual cyber range and how it was used to conduct a simulate red vs blue exercise with the goal of compromising the simulated spacecraft that utilizes real NASA flight software.

test and evaluation DT&E↗

Technology Benefit Estimator (T/BEST): User's Manual

The Technology Benefit Estimator (T/BEST) system is a formal method to assess advanced technologies and quantify the benefit contributions for prioritization. T/BEST may be used to provide guidelines to identify and prioritize high payoff research areas, help manage research and limited resources, show the link between advanced concepts and the bottom line, i.e., accrued benefit and value, and to communicate credibly the benefits of research. The T/BEST software computer program is specifically designed to estimating benefits, and benefit sensitivities, of introducing new technologies into existing propulsion systems. Key engine cycle, structural, fluid, mission and cost analysis modules are used to provide a framework for interfacing with advanced technologies. An open-ended, modular approach is used to allow for modification and addition of both key and advanced technology modules. T/BEST has a hierarchical framework that yields varying levels of benefit estimation accuracy that are dependent on the degree of input detail available. This hierarchical feature permits rapid estimation of technology benefits even when the technology is at the conceptual stage. As knowledge of the technology details increases the accuracy of the benefit analysis increases. Included in T/BEST's framework are correlations developed from a statistical data base that is relied upon if there is insufficient information given in a particular area, e.g., fuel capacity or aircraft landing weight. Statistical predictions are not required if these data are specified in the mission requirements. The engine cycle, structural fluid, cost, noise, and emissions analyses interact with the default or user material and component libraries to yield estimates of specific global benefits: range, speed, thrust, capacity, component life, noise, emissions, specific fuel consumption, component and engine weights, pre-certification test, mission performance engine cost, direct operating cost, life cycle cost, manufacturing cost, development cost, risk, and development time. Currently, T/BEST operates on stand-alone or networked workstations, and uses a UNIX shell or script to control the operation of interfaced FORTRAN based analyses. T/BEST's interface structure works equally well with non-FORTRAN or mixed software analysis. This interface structure is designed to maintain the integrity of the expert's analyses by interfacing with expert's existing input and output files. Parameter input and output data (e.g., number of blades, hub diameters, etc.) are passed via T/BEST's neutral file, while copious data (e.g., finite element models, profiles, etc.) are passed via file pointers that point to the expert's analyses output files. In order to make the communications between the T/BEST's neutral file and attached analyses codes simple, only two software commands, PUT and GET, are required. This simplicity permits easy access to all input and output variables contained within the neutral file. Both public domain and proprietary analyses codes may be attached with a minimal amount of effort, while maintaining full data and analysis integrity, and security. T/BESt's sotware framework, status, beginner-to-expert operation, interface architecture, analysis module addition, and key analysis modules are discussed. Representative examples of T/BEST benefit analyses are shown.

Generazio, Edward R.↗

NASA Tech Briefs, September 2006

Topics covered include: Improving Thermomechanical Properties of SiC/SiC Composites; Aerogel/Particle Composites for Thermoelectric Devices; Patches for Repairing Ceramics and Ceramic- Matrix Composites; Lower-Conductivity Ceramic Materials for Thermal-Barrier Coatings; An Alternative for Emergency Preemption of Traffic Lights; Vehicle Transponder for Preemption of Traffic Lights; Automated Announcements of Approaching Emergency Vehicles; Intersection Monitor for Traffic-Light-Preemption System; Full-Duplex Digital Communication on a Single Laser Beam; Stabilizing Microwave Frequency of a Photonic Oscillator; Microwave Oscillators Based on Nonlinear WGM Resonators; Pointing Reference Scheme for Free-Space Optical Communications Systems; High-Level Performance Modeling of SAR Systems; Spectral Analysis Tool 6.2 for Windows; Multi-Platform Avionics Simulator; Silicon-Based Optical Modulator with Ferroelectric Layer; Multiplexing Transducers Based on Tunnel-Diode Oscillators; Scheduling with Automated Resolution of Conflicts; Symbolic Constraint Maintenance Grid; Discerning Trends in Performance Across Multiple Events; Magnetic Field Solver; Computing for Aiming a Spaceborne Bistatic- Radar Transmitter; 4-Vinyl-1,3-Dioxolane-2-One as an Additive for Li-Ion Cells; Probabilistic Prediction of Lifetimes of Ceramic Parts; STRANAL-PMC Version 2.0; Micromechanics and Piezo Enhancements of HyperSizer; Single-Phase Rare-Earth Oxide/Aluminum Oxide Glasses; Tilt/Tip/Piston Manipulator with Base-Mounted Actuators; Measurement of Model Noise in a Hard-Wall Wind Tunnel; Loci-STREAM Version 0.9; The Synergistic Engineering Environment; Reconfigurable Software for Controlling Formation Flying; More About the Tetrahedral Unstructured Software System; Computing Flows Using Chimera and Unstructured Grids; Avoiding Obstructions in Aiming a High-Gain Antenna; Analyzing Aeroelastic Stability of a Tilt-Rotor Aircraft; Tracking Positions and Attitudes of Mars Rovers; Stochastic Evolutionary Algorithms for Planning Robot Paths; Compressible Flow Toolbox; Rapid Aeroelastic Analysis of Blade Flutter in Turbomachines; General Flow-Solver Code for Turbomachinery Applications; Code for Multiblock CFD and Heat-Transfer Computations; Rotating-Pump Design Code; Covering a Crucible with Metal Containing Channels; Repairing Fractured Bones by Use of Bioabsorbable Composites; Kalman Filter for Calibrating a Telescope Focal Plane; Electronic Absolute Cartesian Autocollimator; Fiber-Optic Gratings for Lidar Measurements of Water Vapor; Simulating Responses of Gravitational-Wave Instrumentation; SOFTC: A Software Correlator for VLBI; Progress in Computational Simulation of Earthquakes; Database of Properties of Meteors; Computing Spacecraft Solar-Cell Damage by Charged Particles; Thermal Model of a Current-Carrying Wire in a Vacuum; Program for Analyzing Flows in a Complex Network; Program Predicts Performance of Optical Parametric Oscillators; Processing TES Level-1B Data; Automated Camera Calibration; Tracking the Martian CO2 Polar Ice Caps in Infrared Images; Processing TES Level-2 Data; SmaggIce Version 1.8; Solving the Swath Segment Selection Problem; The Spatial Standard Observer; Less-Complex Method of Classifying MPSK; Improvement in Recursive Hierarchical Segmentation of Data; Using Heaps in Recursive Hierarchical Segmentation of Data; Tool for Statistical Analysis and Display of Landing Sites; Automated Assignment of Proposals to Reviewers; Array-Pattern-Match Compiler for Opportunistic Data Analysis; Pre-Processor for Compression of Multispectral Image Data; Compressing Image Data While Limiting the Effects of Data Losses; Flight Operations Analysis Tool; Improvement in Visual Target Tracking for a Mobile Robot; Software for Simulating Air Traffic; Automated Vectorization of Decision-Based Algorithms; Grayscale Optical Correlator Workbench; "One-Stop Shopping" for Ocean Remote-Sensing and Model Data; State Analysis Database Tool; Generating CAHV and CAHVOmages with Shadows in ROAMS; Improving UDP/IP Transmission Without Increasing Congestion; FORTRAN Versions of Reformulated HFGMC Codes; Program for Editing Spacecraft Command Sequences; Flight-Tested Prototype of BEAM Software; Mission Scenario Development Workbench; Marsviewer; Tool for Analysis and Reduction of Scientific Data; ASPEN Version 3.0; Secure Display of Space-Exploration Images; Digital Front End for Wide-Band VLBI Science Receiver; Multifunctional Tanks for Spacecraft; Lightweight, Segmented, Mostly Silicon Telescope Mirror; Assistant for Analyzing Tropical-Rain-Mapping Radar Data; and Anion-Intercalating Cathodes for High-Energy- Density Cells.

Source record↗

Secure Peer-to-Peer Networks for Scientific Information Sharing

The most common means of remote scientific collaboration today includes the trio of e-mail for electronic communication, FTP for file sharing, and personalized Web sites for dissemination of papers and research results. With the growth of broadband Internet, there has been a desire to share large files (movies, files, scientific data files) over the Internet. Email has limits on the size of files that can be attached and transmitted. FTP is often used to share large files, but this requires the user to set up an FTP site for which it is hard to set group privileges, it is not straightforward for everyone, and the content is not searchable. Peer-to-peer technology (P2P), which has been overwhelmingly successful in popular content distribution, is the basis for development of a scientific collaboratory called Scientific Peer Network (SciPerNet). This technology combines social networking with P2P file sharing. SciPerNet will be a standalone application, written in Java and Swing, thus insuring portability to a number of different platforms. Some of the features include user authentication, search capability, seamless integration with a data center, the ability to create groups and social networks, and on-line chat. In contrast to P2P networks such as Gnutella, Bit Torrent, and others, SciPerNet incorporates three design elements that are critical to application of P2P for scientific purposes: User authentication, Data integrity validation, Reliable searching SciPerNet also provides a complementary solution to virtual observatories by enabling distributed collaboration and sharing of downloaded and/or processed data among scientists. This will, in turn, increase scientific returns from NASA missions. As such, SciPerNet can serve a two-fold purpose for NASA: a cost-savings software as well as a productivity tool for scientists working with data from NASA missions.

Karimabadi, Homa↗

Issues and Methods for Assessing COTS Reliability, Maintainability, and Availability

Many vendors produce products that are not domain specific (e.g., network server) and have limited functionality (e.g., mobile phone). In contrast, many customers of COTS develop systems that am domain specific (e.g., target tracking system) and have great variability in functionality (e.g., corporate information system). This discussion takes the viewpoint of how the customer can ensure the quality of COTS components. In evaluating the benefits and costs of using COTS, we must consider the environment in which COTS will operate. Thus we must distinguish between using a non-mission critical application like a spreadsheet program to produce a budget and a mission critical application like military strategic and tactical operations. Whereas customers will tolerate an occasional bug in the former, zero tolerance is the rule in the latter. We emphasize the latter because this is the arena where there are major unresolved problems in the application of COTS. Furthermore, COTS components may be embedded in the larger customer system. We refer to these as embedded systems. These components must be reliable, maintainable, and available, and must be with the larger system in order for the customer to benefit from the advertised advantages of lower development and maintenance costs. Interestingly, when the claims of COTS advantages are closely examined, one finds that to a great extent these COTS components consist of hardware and office products, not mission critical software [1]. Obviously, COTS components are different from custom components with respect to one or more of the following attributes: source, development paradigm, safety, reliability, maintainability, availability, security, and other attributes. However, the important question is whether they should be treated differently when deciding to deploy them for operational use; we suggest the answer is no. We use reliability as an example to justify our answer. In order to demonstrate its reliability, a COTS component must pass the same reliability evaluations as the custom components, otherwise the COTS components will be the weakest link in the chain of components and will be the determinant of software system reliability. The challenge is that there will be less information available for evaluating COTS components than for custom components but this does not mean we should despair and do nothing. Actually, there is a lot we can do even in the absence of documentation on COTS components because the customer will have information about how COTS components are to be used in the larger system. To illustrate our approach, we will consider the reliability, maintainability, and availability (RMA) of COTS components as used in larger systems. Finally, COTS suppliers might consider increasing visibility into their products to assist customers in determining the components' fitness for use in a particular application. We offer ideas of information that would be useful to customers, and what vendors might do to provide it.

Schneidewind, Norman F.↗

Encryption for Remote Control via Internet or Intranet

A data-communication protocol has been devised to enable secure, reliable remote control of processes and equipment via a collision-based network, while using minimal bandwidth and computation. The network could be the Internet or an intranet. Control is made secure by use of both a password and a dynamic key, which is sent transparently to a remote user by the controlled computer (that is, the computer, located at the site of the equipment or process to be controlled, that exerts direct control over the process). The protocol functions in the presence of network latency, overcomes errors caused by missed dynamic keys, and defeats attempts by unauthorized remote users to gain control. The protocol is not suitable for real-time control, but is well suited for applications in which control latencies up to about 0.5 second are acceptable. The encryption scheme involves the use of both a dynamic and a private key, without any additional overhead that would degrade performance. The dynamic key is embedded in the equipment- or process-monitor data packets sent out by the controlled computer: in other words, the dynamic key is a subset of the data in each such data packet. The controlled computer maintains a history of the last 3 to 5 data packets for use in decrypting incoming control commands. In addition, the controlled computer records a private key (password) that is given to the remote computer. The encrypted incoming command is permuted by both the dynamic and private key. A person who records the command data in a given packet for hostile purposes cannot use that packet after the public key expires (typically within 3 seconds). Even a person in possession of an unauthorized copy of the command/remote-display software cannot use that software in the absence of the password. The use of a dynamic key embedded in the outgoing data makes the central-processing unit overhead very small. The use of a National Instruments DataSocket(TradeMark) (or equivalent) protocol or the User Datagram Protocol makes it possible to obtain reasonably short response times: Typical response times in event-driven control, using packets sized .300 bytes, are <0.2 second for commands issued from locations anywhere on Earth. The protocol requires that control commands represent absolute values of controlled parameters (e.g., a specified temperature), as distinguished from changes in values of controlled parameters (e.g., a specified increment of temperature). Each command is issued three or more times to ensure delivery in crowded networks. The use of absolute-value commands prevents additional (redundant) commands from causing trouble. Because a remote controlling computer receives "talkback" in the form of data packets from the controlled computer, typically within a time interval < or =1 s, the controlling computer can re-issue a command if network failure has occurred. The controlled computer, the process or equipment that it controls, and any human operator(s) at the site of the controlled equipment or process should be equipped with safety measures to prevent damage to equipment or injury to humans. These features could be a combination of software, external hardware, and intervention by the human operator(s). The protocol is not fail-safe, but by adopting these safety measures as part of the protocol, one makes the protocol a robust means of controlling remote processes and equipment by use of typical office computers via intranets and/or the Internet.

Lineberger, Lewis↗

The International Space Station, Optical Communications, and Delay Tolerant Networking: Towards A Solar System Internet Architecture

As Delay Tolerant Networking (DTN) matures as a software product its use cases have extended to infrastructural and architectural studies, bringing DTN closer to a widespread, operational technology. While it is known that a DTN can be configured, given complete information about a system of nodes, to provision a system with a complete network capability, what remains is to tackle practical considerations such as scalability, networking best practices, and how to establish service providers. In this paper, we document progress towards a scalable DTN architecture that was tested across multiple organizational and project boundaries; our approach was tested across nodes flying on the International Space Station (ISS) connected to a ground network. The network consists of four main network areas: the ISS, the White Sands Complex (WSC), the Mission Cloud Platform (MCP), and NASA’s Huntsville Operations Support Center (HOSC). The connections on the ground (WSC, MCP, and HOSC) are straightforward technically, but represent administrative and non-technical challenges that had to be overcome. The connection from the ISS to WSC was realized through a hybrid optical/RF means. In particular, NASA’s Integrated Laser Communications Relay Demonstration (LCRD) can form a relay from lowEarth-orbit (LEO) to the Earth, and was used in conjunction with the LCRD LEO User Modem and Amplifier Terminal (ILLUMA-T) on the ISS to form a link to one of three geographically diverse ground stations. A major goal was to achieve communications while keeping the ISS nodes unaware of ground station choices and scheduling. These disparate links were networked using High-rate DTN (HDTN), which enabled the desired architecture. The network architecture, tests, HDTN performance metrics, and general observations made are all discussed in detail, including a discussion on the successful utilization of the DTN security standard known as DTN Bundle Protocol Security (BPSec). We conclude with suggestions for next steps, and in particular focus on extending this architecture to the Near Space Network (NSN) and the upcoming LunaNet.

Alan Hylton↗

An Automated Flying-Insect Detection System

An automated flying-insect detection system (AFIDS) was developed as a proof-of-concept instrument for real-time detection and identification of flying insects. This type of system has use in public health and homeland-security decision support, agriculture and military pest management, and/or entomological research. Insects are first lured into the AFIDS integrated sphere by insect attractants. Once inside the sphere, the insect s wing beats cause alterations in light intensity that is detected by a photoelectric sensor. Following detection, the insects are encouraged (with the use of a small fan) to move out of the sphere and into a designated insect trap where they are held for taxonomic identification or serological testing. The acquired electronic wing-beat signatures are preprocessed (Fourier transformed) in real time to display a periodic signal. These signals are sent to the end user where they are graphically. All AFIDS data are preprocessed in the field with the use of a laptop computer equipped with LabVIEW. The AFIDS software can be programmed to run continuously or at specific time intervals when insects are prevalent. A special DC-restored transimpedance amplifier reduces the contributions of low-frequency background light signals, and affords approximately two orders of magnitude greater AC gain than conventional amplifiers. This greatly increases the signal-to-noise ratio and enables the detection of small changes in light intensity. The AFIDS light source consists of high-intensity Al-GaInP light-emitting diodes (LEDs). The AFIDS circuitry minimizes brightness fluctuations in the LEDs and when integrated with an integrating sphere, creates a diffuse uniform light field. The insect wing beats isotropically scatter the diffuse light in the sphere and create wing-beat signatures that are detected by the sensor. This configuration minimizes variations in signal associated with insect flight orientation. Preliminary data indicate that AFIDS has sufficient sensitivity and frequency measuring capability to differentiate between male and female mosquitoes (Figure 1, bottom panel) and fruit flies (data not shown). Similar studies show that AFIDS can be utilized to detect discrete differences between two mosquito species, Aedes aegypti and Aedes albopictus. When fully deployable, a wireless network of AFIDS monitors could be used in combination with other remotely sensed data and visually displayed in a geographic information system (GIS) to provide real-time surveillance (see Figure 2). More accurate and sensitive insect population forecasts and effective rapid response and mitigation of insect issues would then be possible.

Vann, Timi↗

The NASA Integrated Information Technology Architecture

This document defines an Information Technology Architecture for the National Aeronautics and Space Administration (NASA), where Information Technology (IT) refers to the hardware, software, standards, protocols and processes that enable the creation, manipulation, storage, organization and sharing of information. An architecture provides an itemization and definition of these IT structures, a view of the relationship of the structures to each other and, most importantly, an accessible view of the whole. It is a fundamental assumption of this document that a useful, interoperable and affordable IT environment is key to the execution of the core NASA scientific and project competencies and business practices. This Architecture represents the highest level system design and guideline for NASA IT related activities and has been created on the authority of the NASA Chief Information Officer (CIO) and will be maintained under the auspices of that office. It addresses all aspects of general purpose, research, administrative and scientific computing and networking throughout the NASA Agency and is applicable to all NASA administrative offices, projects, field centers and remote sites. Through the establishment of five Objectives and six Principles this Architecture provides a blueprint for all NASA IT service providers: civil service, contractor and outsourcer. The most significant of the Objectives and Principles are the commitment to customer-driven IT implementations and the commitment to a simpler, cost-efficient, standards-based, modular IT infrastructure. In order to ensure that the Architecture is presented and defined in the context of the mission, project and business goals of NASA, this Architecture consists of four layers in which each subsequent layer builds on the previous layer. They are: 1) the Business Architecture: the operational functions of the business, or Enterprise, 2) the Systems Architecture: the specific Enterprise activities within the context of IT systems, 3) the Technical Architecture: a common, vendor-independent framework for design, integration and implementation of IT systems and 4) the Product Architecture: vendor=specific IT solutions. The Systems Architecture is effectively a description of the end-user "requirements". Generalized end-user requirements are discussed and subsequently organized into specific mission and project functions. The Technical Architecture depicts the framework, and relationship, of the specific IT components that enable the end-user functionality as described in the Systems Architecture. The primary components as described in the Technical Architecture are: 1) Applications: Basic Client Component, Object Creation Applications, Collaborative Applications, Object Analysis Applications, 2) Services: Messaging, Information Broker, Collaboration, Distributed Processing, and 3) Infrastructure: Network, Security, Directory, Certificate Management, Enterprise Management and File System. This Architecture also provides specific Implementation Recommendations, the most significant of which is the recognition of IT as core to NASA activities and defines a plan, which is aligned with the NASA strategic planning processes, for keeping the Architecture alive and useful.

Baldridge, Tim↗

Some Aeronautical Communications Experiments

Classically there has existed an asymmetry between the computing and communicating sides of aerospace systems. Over the past few decades, this asymmetry has shifted to favoring communication link technologies, meaning that advancements in available central processing units (CPUs), storage devices, and internal data buses have stagnated. Indeed, the increased emphasis placed on refining subsystem performance such as with antenna bandwidth in phased arrays, amplifier power efficiency, software defined radio (SDR) flexibility and encoding for data compression and error correction has given rise to successful debuts of multi-gigabit-per-second data return from long space-link distances. These accomplishments are easily quantifiable through link budgets and illustrate what is possible, but also reveal the deficiencies in overall communications capabilities. In particular, the ever-accelerating presence of aerospace vehicles gives rise to newer and larger classes of challenges to address the needs of 21st century systems. Furthermore remote sensing and imaging capabilities have far outpaced our ability to transmit their products to the ground, so we are increasingly dependent on pre-processing and downselection to contend with the communications bottleneck. No longer may we depend upon the constrained logistics in delivering end-to-end data delivery through manual reconfigurations, static event scheduling and execution on a per-vehicle basis, for these methods do not scale and therefore must give way to dynamic, networked approaches with an overall systems view in mind. Emerging mission requirements exhibit a trend toward multiple smaller-scale vehicles working together to perform dissimilar observations. Such operations necessitate sensor fusion across a constellation, and where data processing may be distributed throughout a fairly disconnected network whose topology changes over time in non-deterministic manners. Individual communications link performance is still very relevant to deploying an effective communications system, but now must be embedded within a greater architecture of capability to optimally utilize the bandwidth available from each link to generate an ultimate end-to-end quality of service. The deleterious effects of timing uncertainty across the arrangement presents a challenge to measurement synchronization and delivery, so a successful deployed system needs to be tolerant to the delays inherent in time-of-light between elements and digital processing latencies existing at each node. In this presentation we share the flight test results from a high performance Gbps laser communications terminal evaluated with a suite of store and forward capabilities called High-rate Delay Tolerant Networking (HDTN). The communications payload is operated over Lake Erie across a range of configurations including several convergence layers, and is evaluated to determine recovery time after link disruptions, information loss, efficiency and speed. The effectiveness of utilizing a flying laboratory to increase the Technology Readiness Level (TRL) of an integrated system in relevant environments is discussed, as well as the value of conducting aeronautics experiments to retire risk for technology infusion into space missions. Upcoming flight campaigns will be presented, including opportunities to demonstrate secure command and control, data intensive hyperspectral imaging, quantum link characterization, 4k High Definition (HD) video streaming and internetworked space-ground-aero relay operations. These experiments will pave the way for future missions which will depend upon interoperability across disparate government and privately owned networks, involve contention with uncertain and dynamic timing, and require agility to autonomously configure optimal parameters across networks of ever-increasing size and complexity to ensure data delivery. https://www1.grc.nasa.gov/space/scan/acs/tech-studies/dtn/

Daniel Raible↗