SEARCH · Search NASA

Results for “Secure Software Development”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

SourceResearch connectionFrom yearThrough year

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

192 records · Page 11

All sources NASA NTRS DOE OSTI

NASA NTRS2005

Transition Report for Dr. Ken Fernandez, NASA Marshall Space Flight Center

The primary objective proposed during my tenure with the NASA Administrator's Fellowship Program (NAFP) was the use of ROBOSIM, a NASA developed robot simulation software package, to introduce the first robotics class to the School of Engineering at Alabama A&M University. The students participating in the spring of 2004 chose as their class project a simulation of the Shuttle, the Shuttle Remote Manipulator System, and the inspection boom which may be used to inspect the Shuttle's tiles on-orbit. In addition to meeting this primary objective and fulfilling other activities that were required by NAFP participants, several other accomplishments are reported. Participation with the faculty of Alabama A&M in the planning and execution of the First and Second Annual Michael P. Anderson Memorial Summer Programs for minority high school students was completed. This program, funded by NASA, provided supervised "hands- on" group activities in various engineering disciplines, including robotics. A third major accomplishment during the NAFP tenure was the granting of a U.S. patent for the NASA 3-D Luggage Scanning System. International patents are also pending on this device. The device uses stereographic imaging similar to that used by NASA on the Mars Rover to enhance the contents of luggage and other items being inspected. It is believed that this device can greatly improve the efficiency and accuracy of security checkpoint screening.

Fernandez, Ken R.↗

NASA NTRS2009

Controlling Infrastructure Costs: Right-Sizing the Mission Control Facility

Johnson Space Center's Mission Control Center is a space vehicle, space program agnostic facility. The current operational design is essentially identical to the original facility architecture that was developed and deployed in the mid-90's. In an effort to streamline the support costs of the mission critical facility, the Mission Operations Division (MOD) of Johnson Space Center (JSC) has sponsored an exploratory project to evaluate and inject current state-of-the-practice Information Technology (IT) tools, processes and technology into legacy operations. The general push in the IT industry has been trending towards a data-centric computer infrastructure for the past several years. Organizations facing challenges with facility operations costs are turning to creative solutions combining hardware consolidation, virtualization and remote access to meet and exceed performance, security, and availability requirements. The Operations Technology Facility (OTF) organization at the Johnson Space Center has been chartered to build and evaluate a parallel Mission Control infrastructure, replacing the existing, thick-client distributed computing model and network architecture with a data center model utilizing virtualization to provide the MCC Infrastructure as a Service. The OTF will design a replacement architecture for the Mission Control Facility, leveraging hardware consolidation through the use of blade servers, increasing utilization rates for compute platforms through virtualization while expanding connectivity options through the deployment of secure remote access. The architecture demonstrates the maturity of the technologies generally available in industry today and the ability to successfully abstract the tightly coupled relationship between thick-client software and legacy hardware into a hardware agnostic "Infrastructure as a Service" capability that can scale to meet future requirements of new space programs and spacecraft. This paper discusses the benefits and difficulties that a migration to cloud-based computing philosophies has uncovered when compared to the legacy Mission Control Center architecture. The team consists of system and software engineers with extensive experience with the MCC infrastructure and software currently used to support the International Space Station (ISS) and Space Shuttle program (SSP).

Martin, Keith↗

NASA NTRS2016

Near Real-Time Flood Monitoring and Impact Assessment Systems

Floods are the costliest natural disaster, causing approximately 6.8 million deaths in the twentieth century alone. Worldwide economic flood damage estimates in 2012 exceed $19 Billion USD. Extended duration floods also pose longer term threats to food security, water, sanitation, hygiene, and community livelihoods, particularly in developing countries. Projections by the Intergovernmental Panel on Climate Change (IPCC) suggest that precipitation extremes, rainfall intensity, storm intensity, and variability are increasing due to climate change. Increasing hydrologic uncertainty will likely lead to unprecedented extreme flood events. As such, there is a vital need to enhance and further develop traditional techniques used to rapidly assess flooding and extend analytical methods to estimate impacted population and infrastructure. Measuring flood extent in situ is generally impractical, time consuming, and can be inaccurate. Remotely sensed imagery acquired from space-borne and airborne sensors provides a viable platform for consistent and rapid wall-to-wall monitoring of large flood events through time. Terabytes of freely available satellite imagery are made available online each day by NASA, ESA, and other international space research institutions. Advances in cloud computing and data storage technologies allow researchers to leverage these satellite data and apply analytical methods at scale. Repeat-survey earth observations help provide insight about how natural phenomena change through time, including the progression and recession of floodwaters. In recent years, cloud-penetrating radar remote sensing techniques (e.g., Synthetic Aperture Radar) and high temporal resolution imagery platforms (e.g., MODIS and its 1-day return period), along with high performance computing infrastructure, have enabled significant advances in software systems that provide flood warning, assessments, and hazard reduction potential. By incorporating social and economic data, researchers can develop systems that automatically quantify the socioeconomic impacts resulting from flood disaster events.

Ahamed, Aakash↗

NASA NTRS2012

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↗

NASA NTRS2005

Tools and Data Services from the NASA Earth Satellite Observations for Climate Applications

Climate science and applications require access to vast amounts of archived high quality data, software tools and services for data manipulation and information extraction. These on the other hand require gaining detailed understanding of the data's internal structure and physical implementation to data reduction, combination and data product production. This time-consuming task must be undertaken before the core investigation can begin and is an especially difficult challenge when science objectives require users to deal with large multi-sensor data sets of different formats, structures, and resolutions. In order to address these issues the Goddard Space Flight Center (GSFC) Earth Sciences (GES), Data and Information Service Center (DISC) Distributed Active Archive Center (DAAC) has made great progress in facilitating science and applications research by developing innovative tools and data services applied to the Earth sciences atmospheric and climate data. The GES/DISC/DAAC has successfully implemented and maintained a long-term climate satellite data archive and developed tools and services to a variety of atmospheric science missions including AIRS, AVHRR, MODIS, SeaWiFS, SORCE, TOMS, TOVS, TRMM, and UARS and Aura instruments providing researchers with excellent opportunities to acquire accurate and continuous atmospheric measurements. Since the number of climate science products from these various missions is steadily increasing as a result of more sophisticated sensors and new science algorithms, the main challenge for data centers like the GES/DISC/DAAC is to guide users through the variety of data sets and products, provide tools to visualize and reduce the volume of the data and secure uninterrupted and reliable access to data and related products. This presentation will describe the effort at the GES/DISC/DAAC to build a bridge between multi-sensor data and the effective scientific use of the data, with an emphasis on the heritage satellite observations and science products for climate applications. The intent is to inform users of the existence of this large collection of data and products; suggest starting points for cross-platform science projects and data mining activities and provide data services and tools information. More information about the GES/DISC/DAAC satellite data and products, tools, and services can be found at http://daac.gsfc.nasa.gov.

Vicente, Gilberto A.↗

NASA NTRS2003

Space Act Agreement Maker (SAAM) With Electronic Routing System (ERouter) Developed

Members of the Commercial Technology Office at the NASA Glenn Research Center have developed an exciting new tool that greatly reduces the lead time in creating and routing Space Act Agreements. The Space Act Agreement Maker (SAAM) is an e-government Web-based system that automates the initial drafting of Space Act Agreements by technical and program personnel. SAAM also is used for editing and will be used later for maintaining electronic copies of all Space Act Agreements. During the initial drafting, the software prompts NASA personnel proposing an agreement to answer questions regarding the agreement. On the basis of the answers, the software selects from a matrix of NASA standard clauses to produce a first draft of the agreement. The draft agreement and information submitted by the NASA personnel are electronically routed to Glenn s Commercial Technology Office for review and, where necessary, editing. The final version of the agreement, along with any supporting documentation, is then routed for electronic concurrence/approval to the necessary internal review participants using the electronic routing system (e-router). SAAM was developed cooperatively by Glenn s Commercial Technology Office and Glenn s Office of Chief Counsel. Currently, SAAM is being evaluated by the NASA Headquarters General Counsel Office for use at all NASA centers. This system allows for the effective processing of Space Act Agreements for NASA s internal and external customers. Document control is maintained by a database. With SAAM s electronic routing, review times can be reduced significantly, allowing Glenn to more rapidly establish partnerships with industry. Prior to the creation of SAAM, it took several hours to draft a Space Act Agreement. With SAAM in place, the document can be written in about 30 min. Using the e-router also saves time in determining where the agreement is in the routing process. The document can be tracked easily, and delays can be avoided. Important research with industry partners can commence quickly after preliminary discussions have been held. The development of these products is in line with the expanding e-government initiative that is part of the Presidential Management Agenda. By using this product, NASA researchers can secure greater support from industry and academia partners. The Space Act Agreement Maker has been very well received at NASA Headquarters and at some of the other NASA centers as well. We anticipate that the NASA Ames Research Center will have the system in place very soon, and that some of the other centers will use SAAM in the near future. The General Counsel s office at NASA Headquarters has encouraged the Glenn team to develop a similar system for processing patent licenses. Find out more about Glenn's Technology Transfer & Partnership Office http://technology.grc.nasa.gov/.

Stauber, Laurel J.↗

NASA NTRSDate not supplied

In-Depth Modeling and Simulation Analysis of Artemis Missions Using the Impact Probabilistic Risk Assessment Tool

BACKGROUND The Artemis campaign is a Moon exploration program with a series of six planned missions, five of which will be crewed. These five crewed missions will contain a single mission segment (space flight), or multiple mission segments involving space flight (Orion), lunar landing (LTV) and/or space habitat (Gateway). Each crewed segment faces the risk of unique medical conditions, necessitating medical sets/kits tailored to those specificities. To support and enable a data-driven and evidence-based decision-making process through out a mission’s life cycle, a software tool called IMPACT was developed. Using probabilistic risk assessment (PRA) methodologies, IMPACT (Informing Mission Planning via Analysis of Complex Tradespaces) is a novel tool built for analyzing the possibility of encountering complex medical risks during space flight, and for identifying the medical resources and capabilities needed to treat those potential at-risk medical conditions. IMPACT achieves this by performing hundreds of thousands of Monte Carlo simulations of missions to build aggregate pictures of medical risk. During an extended simulation modeling phase, IMPACT generated analytical results for medical risks, and the medical resources and capabilities to address those risks, for every segment of every crewed Artemis mission. This presentation will highlight the reliability, consistency and validity of IMPACT’s computational modeling techniques and will showcase the library of analytical outcomes generated for the Artemis missions. OVERVIEW During the early stages of IMPACT’s design, architecture and technical requirements collection, “scenarios” (use cases) - achievement goals required for acceptance testing, were identified by stakeholders. IMPACT successfully completed the scenario testing requirements and undertook an extensive operational run phase utilizing a wide range of input combinations with a goal of delivering a cohesive, trustworthy, reliable, vast, and diverse body of evidence. The intent of these modeling runs was to validate consistency in output, ensure solidity of executable operations and to streamline processes by identifying areas requiring efficiency improvements. Using the many missions of Artemis, IMPACT ran variations of operational runs to assess the output for acceptable, as well as unusual characteristics. This rigorous long-term “shakedown” analysis was implemented to help build a collective body of evidence to aid in securing a high level of confidence, reliability, and validity in the output, whether from the applicational components of IMPACT, or the entirety of the operational process. ANTICIPATED ANALYSIS AND CONCLUSION This presentation will discuss the various categories of input criteria; the comparisons in the application of these input criteria to various Artemis missions; the preparation and collection of the body of evidence, and reliability of the computational modeling techniques. This paper serves as an initial analytical overview of IMPACT’s probabilistic risk assessment (PRA) medical risk outputs covering Artemis missions and is not intended to be deemed the official medical response for the Artemis campaign.

Crew Composition↗

NASA NTRS2011

Deep Space Networking Experiments on the EPOXI Spacecraft

NASA's Space Communications & Navigation Program within the Space Operations Directorate is operating a program to develop and deploy Disruption Tolerant Networking [DTN] technology for a wide variety of mission types by the end of 2011. DTN is an enabling element of the Interplanetary Internet where terrestrial networking protocols are generally unsuitable because they rely on timely and continuous end-to-end delivery of data and acknowledgments. In fall of 2008 and 2009 and 2011 the Jet Propulsion Laboratory installed and tested essential elements of DTN technology on the Deep Impact spacecraft. These experiments, called Deep Impact Network Experiment (DINET 1) were performed in close cooperation with the EPOXI project which has responsibility for the spacecraft. The DINET 1 software was installed on the backup software partition on the backup flight computer for DINET 1. For DINET 1, the spacecraft was at a distance of about 15 million miles (24 million kilometers) from Earth. During DINET 1 300 images were transmitted from the JPL nodes to the spacecraft. Then, they were automatically forwarded from the spacecraft back to the JPL nodes, exercising DTN's bundle origination, transmission, acquisition, dynamic route computation, congestion control, prioritization, custody transfer, and automatic retransmission procedures, both on the spacecraft and on the ground, over a period of 27 days. The first DINET 1 experiment successfully validated many of the essential elements of the DTN protocols. DINET 2 demonstrated: 1) additional DTN functionality, 2) automated certain tasks which were manually implemented in DINET 1 and 3) installed the ION SW on nodes outside of JPL. DINET 3 plans to: 1) upgrade the LTP convergence-layer adapter to conform to the international LTP CL specification, 2) add convergence-layer "stewardship" procedures and 3) add the BSP security elements [PIB & PCB]. This paper describes the planning and execution of the flight experiment and the validation results.

automated data communication↗

NASA NTRS2014

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 NTRS2017

Lessons Learned from OSIRIS-Rex Autonomous Navigation Using Natural Feature Tracking

The Origins, Spectral Interpretation, Resource Identification, Security-Regolith Explorer (Osiris-REx) spacecraft is scheduled to launch in September, 2016 to embark on an asteroid sample return mission. It is expected to rendezvous with the asteroid, Bennu, navigate to the surface, collect a sample (July 20), and return the sample to Earth (September 23). The original mission design called for using one of two Flash Lidar units to provide autonomous navigation to the surface. Following Preliminary design and initial development of the Lidars, reliability issues with the hardware and test program prompted the project to begin development of an alternative navigation technique to be used as a backup to the Lidar. At the critical design review, Natural Feature Tracking (NFT) was added to the mission. NFT is an onboard optical navigation system that compares observed images to a set of asteroid terrain models which are rendered in real-time from a catalog stored in memory on the flight computer. Onboard knowledge of the spacecraft state is then updated by a Kalman filter using the measured residuals between the rendered reference images and the actual observed images. The asteroid terrain models used by NFT are built from a shape model generated from observations collected during earlier phases of the mission and include both terrain shape and albedo information about the asteroid surface. As a result, the success of NFT is highly dependent on selecting a set of topographic features that can be both identified during descent as well as reliably rendered using the shape model data available. During development, the OSIRIS-REx team faced significant challenges in developing a process conducive to robust operation. This was especially true for terrain models to be used as the spacecraft gets close to the asteroid and higher fidelity models are required for reliable image correlation. This paper will present some of the challenges and lessons learned from the development of the NFT system which includes not just the flight hardware and software but the development of the terrain models used to generate the onboard rendered images.

Navigation↗

NASA NTRS1997

Operation of the Planetary Plasma Interactions Node of the Planetary Data System

Five years ago NASA selected the Planetary Plasma Interactions (PPI) Node at UCLA to help the scientific community locate, access and preserve particles and fields data from planetary missions. We propose to continue to serve for 5 more years. During the first five years we have served the scientific community by providing them with high quality data products. We worked with missions and individual scientists to secure the highest quality data possible and to thoroughly document it. We validated the data, placed it on long lasting media and made sure it was properly archived for future use. So far we have prepared and archived over 10(exp 11) bytes of data from 26 instruments on 4 spacecraft. We have produced 106 CD-ROMs with peer reviewed data. In so doing, we have developed an efficient system to prepare and archive the data and thereby have been able to steadily increase the rate at which the data are produced. Although we produced a substantial archive during the initial five years, we have an even larger amount of work in progress. This includes preparing CD-ROM data sets with all of the Voyager, Pioneer and Ulysses data at Jupiter and Saturn. We will have the Jupiter data ready for the Galileo encounter in December, 1995. We are also completing the Pioneer Venus data restoration. The Galileo Venus archive and radio science data from Magellan will be prepared early in the next period. We are assisting the Small Bodies Node of PDS in the preparation of comet data and will be archiving the asteroid data from Galileo. We will be moving in several new directions as well. We will archive the PPI Node's first Earth based data with data from the International Jupiter Watch and Hubble data taken in support of Ulysses particles and field observations. We will work with the Cassini mission in archive planning efforts. For the inner planets we will begin an archive of Mars data starting with Phobos data and will support the US and Russian Mars missions in the late 1990's. We will restore the Mercury data from Mariner 10 and prepare the lunar data from Clementine in time for the lunar data analysis program in 1995. We will work with the Discovery mission teams to plan their archive and have already started with one, NEAR. Finally we will begin archiving our first heliospheric data from Voyager, Galileo, and Mars observers. We will continue to serve the science community by providing access to the data products. During the past 19 months we have filled nearly 6000 requests for on-line and CD-ROM data. The data delivered directly by the PPI Node has been - 5 x 10(exp 11) bytes. In addition to providing the data, we have provided users with software tools to manage and read the data which are computer, operating system and format independent. We have developed scalable systems so that the same software we use to manage and access the data for the entire PPI Node can be used by individual investigators to manage the data on a single CD-ROM, thereby greatly reducing the software development effort for both the PPI Node and users. We deliver this software with the disks. Recent technical advances have made it possible for us to serve a broader community than before. In the next five year period we plan to extend our outreach to the general public and in particular to increase our support for education. Since planetary plasma data are varied and require expertise in many areas the PPI Node will continue to be distributed. In addition to the primary node at UCLA, the PPI Node has three subnodes with an Outer Planets Subnode at the University of Iowa, an Inner Planets Subnode at UCLA, and a Radio Science Subnode at Stanford University. During the first two years of the renewal period there will be a Radio Astronomy Data Node at GSFC. These organizations will provide scientific expertise on the data, participate in node data selection activities and help with data restoration and mission activities.

Walker, Raymond J.↗

NASA NTRSDate not supplied

NASA's Moon to Mars Autonomous Habitat Status

NASA is developing a strategy for sending humans to the Mars vicinity, known broadly as the Moon to Mars (M2M) Campaign. A critical part of this campaign is the development of in-space and surface habitation systems capable of substantially extending human presence beyond Low Earth Orbit (LEO). Mars missions feature an in-space transit habitat capable of supporting crews of four on ~850-1200-day missions, including transit to and from Mars and time in Mars orbit. Surface and transit habitats are complex elements which must keep crewmembers healthy and productive in deep-space environments with limited resources, long rescue times in contingency situations, and communication delays; all within constrained mass, volume, and power budgets. These habitats provide crew both living and workspace as well as most of the resources needed to support crew life. For deep space habitats, automation needs to be employed due to latency and for significant amounts of time when the habitats are uncrewed. Automation of systems is possible in space applications, but there are limitations. Outside of the Earth’s (or any) magnetosphere, radiation environments are harsh to both the physical hardware and the software components. Radiation (charged particles and ionizing electromagnetic waves) degrades and damages the hardware and causes single event upsets (SEUs) in software. If the hardware is damaged, data can be lost, or control actions not made. For software, SEUs cause algorithms to result in different solutions, or incorrect commands to be sent out. This means that algorithms and hardware used for deep space systems are different than what is used on Earth. Radiation-tolerant hardware is generations behind the current state-of-the-art hardware. Recent NASA missions, such as James Webb Space Telescope, continue to rely on older technologies such as the RAD750 processor, and the most advanced processors are still single core and less than 1.5 GHz. There have been attempts to use higher performance processors, but these often take multiple mitigation steps to handle the radiation environments, which limits the processing power and/or throughput. Current techniques for radiation mitigation have been redundancies, voting, physical separation of hardware, encasing materials, under-clocking hardware, and more. Some radiation mitigation techniques do provide benefits such as having a redundant system to improve the probability that a system will be available when needed. Autonomous software systems will have fewer interactions with humans on deep space missions and therefore need to be able to handle more off-nominal conditions. Microgravity also complicates the autonomous aspects of the mission because autonomous systems are usually built from known deterministic states, but microgravity causes physical objects to shift and move changing the location an autonomous system placed the object. Not only does the software need to be reliable and deterministic, losing resources due to a software error is not only costly but detrimental to reputation. The combination of having lower performance hardware and having to be able to verify and deterministically run software and an ever-changing environment makes deep space autonomous systems more complicated. Multiple gaps have been identified including verification of autonomous software algorithms (including artificial intelligence and machine learning), higher performance processors (graphics and general purpose), high speed networks (onboard and transmissions), memory, power distribution, data security, and variations from these. These gaps need to be closed for more advanced systems to be deployed and reduce the size, weight, and power impacts on the habitats.

Scott B. Tashakkor↗