Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “User Interface Design”

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 1,603 records · Page 89
All sourcesNASA NTRSDOE OSTI
NASA NTRS2000

A natural basis for efficient brain-actuated control

The prospect of noninvasive brain-actuated control of computerized screen displays or locomotive devices is of interest to many and of crucial importance to a few 'locked-in' subjects who experience near total motor paralysis while retaining sensory and mental faculties. Currently several groups are attempting to achieve brain-actuated control of screen displays using operant conditioning of particular features of the spontaneous scalp electroencephalogram (EEG) including central mu-rhythms (9-12 Hz). A new EEG decomposition technique, independent component analysis (ICA), appears to be a foundation for new research in the design of systems for detection and operant control of endogenous EEG rhythms to achieve flexible EEG-based communication. ICA separates multichannel EEG data into spatially static and temporally independent components including separate components accounting for posterior alpha rhythms and central mu activities. We demonstrate using data from a visual selective attention task that ICA-derived mu-components can show much stronger spectral reactivity to motor events than activity measures for single scalp channels. ICA decompositions of spontaneous EEG would thus appear to form a natural basis for operant conditioning to achieve efficient and multidimensional brain-actuated control in motor-limited and locked-in subjects.

NASA Discipline Space Human Factors↗
NASA NTRS2011

Telemetry and Science Data Software System

The Telemetry and Science Data Software System (TSDSS) was designed to validate the operational health of a spacecraft, ease test verification, assist in debugging system anomalies, and provide trending data and advanced science analysis. In doing so, the system parses, processes, and organizes raw data from the Aquarius instrument both on the ground and while in space. In addition, it provides a user-friendly telemetry viewer, and an instant pushbutton test report generator. Existing ground data systems can parse and provide simple data processing, but have limitations in advanced science analysis and instant report generation. The TSDSS functions as an offline data analysis system during I&T (integration and test) and mission operations phases. After raw data are downloaded from an instrument, TSDSS ingests the data files, parses, converts telemetry to engineering units, and applies advanced algorithms to produce science level 0, 1, and 2 data products. Meanwhile, it automatically schedules upload of the raw data to a remote server and archives all intermediate and final values in a MySQL database in time order. All data saved in the system can be straightforwardly retrieved, exported, and migrated. Using TSDSS s interactive data visualization tool, a user can conveniently choose any combination and mathematical computation of interesting telemetry points from a large range of time periods (life cycle of mission ground data and mission operations testing), and display a graphical and statistical view of the data. With this graphical user interface (GUI), the data queried graphs can be exported and saved in multiple formats. This GUI is especially useful in trending data analysis, debugging anomalies, and advanced data analysis. At the request of the user, mission-specific instrument performance assessment reports can be generated with a simple click of a button on the GUI. From instrument level to observatory level, the TSDSS has been operating supporting functional and performance tests and refining system calibration algorithms and coefficients, in sync with the Aquarius/SAC-D spacecraft. At the time of this reporting, it was prepared and set up to perform anomaly investigation for mission operations preceding the Aquarius/SAC-D spacecraft launch on June 10, 2011.

Bates, Lakesha↗
NASA NTRS2004

Toward Synthesis, Analysis, and Certification of Security Protocols

Implemented security protocols are basically pieces of software which are used to (a) authenticate the other communication partners, (b) establish a secure communication channel between them (using insecure communication media), and (c) transfer data between the communication partners in such a way that these data only available to the desired receiver, but not to anyone else. Such an implementation usually consists of the following components: the protocol-engine, which controls in which sequence the messages of the protocol are sent over the network, and which controls the assembly/disassembly and processing (e.g., decryption) of the data. the cryptographic routines to actually encrypt or decrypt the data (using given keys), and t,he interface to the operating system and to the application. For a correct working of such a security protocol, all of these components must work flawlessly. Many formal-methods based techniques for the analysis of a security protocols have been developed. They range from using specific logics (e.g.: BAN-logic [4], or higher order logics [12] to model checking [2] approaches. In each approach, the analysis tries to prove that no (or at least not a modeled intruder) can get access to secret data. Otherwise, a scenario illustrating the &tack may be produced. Despite the seeming simplicity of security protocols ("only" a few messages are sent between the protocol partners in order to ensure a secure communication), many flaws have been detected. Unfortunately, even a perfect protocol engine does not guarantee flawless working of a security protocol, as incidents show. Many break-ins and security vulnerabilities are caused by exploiting errors in the implementation of the protocol engine or the underlying operating system. Attacks using buffer-overflows are a very common class of such attacks. Errors in the implementation of exception or error handling can open up additional vulnerabilities. For example, on a website with a log-in screen: multiple tries with invalid passwords caused the expected error message (too many retries). but let the user nevertheless pass. Finally, security can be compromised by silly implementation bugs or design decisions. In a commercial VPN software, all calls to the encryption routines were incidentally replaced by stubs, probably during factory testing. The product worked nicely. and the error (an open VPN) would have gone undetected, if a team member had not inspected the low-level traffic out of curiosity. Also, the use secret proprietary encryption routines can backfire, because such algorithms often exhibit weaknesses which can be exploited easily (see e.g., DVD encoding). Summarizing, there is large number of possibilities to make errors which can compromise the security of a protocol. In today s world with short time-to-market and the use of security protocols in open and hostile networks for safety-critical applications (e.g., power or air-traffic control), such slips could lead to catastrophic situations. Thus, formal methods and automatic reasoning techniques should not be used just for the formal proof of absence of an attack, but they ought to be used to provide an end-to-end tool-supported framework for security software. With such an approach all required artifacts (code, documentation, test cases) , formal analyses, and reliable certification will be generated automatically, given a single, high level specification. By a combination of program synthesis, formal protocol analysis, certification; and proof-carrying code, this goal is within practical reach, since all the important technologies for such an approach actually exist and only need to be assembled in the right way.

Schumann, Johann↗
NASA NTRS2010

Gas Flow Detection System

This system provides a portable means to detect gas flow through a thin-walled tube without breaking into the tubing system. The flow detection system was specifically designed to detect flow through two parallel branches of a manifold with only one inlet and outlet, and is a means for verifying a space shuttle program requirement that saves time and reduces the risk of flight hardware damage compared to the current means of requirement verification. The prototype Purge Vent and Drain Window Cavity Conditioning System (PVD WCCS) Flow Detection System consists of a heater and a temperature-sensing thermistor attached to a piece of Velcro to be attached to each branch of a WCCS manifold for the duration of the requirement verification test. The heaters and thermistors are connected to a shielded cable and then to an electronics enclosure, which contains the power supplies, relays, and circuit board to provide power, signal conditioning, and control. The electronics enclosure is then connected to a commercial data acquisition box to provide analog to digital conversion as well as digital control. This data acquisition box is then connected to a commercial laptop running a custom application created using National Instruments LabVIEW. The operation of the PVD WCCS Flow Detection System consists of first attaching a heater/thermistor assembly to each of the two branches of one manifold while there is no flow through the manifold. Next, the software application running on the laptop is used to turn on the heaters and to monitor the manifold branch temperatures. When the system has reached thermal equilibrium, the software application s graphical user interface (GUI) will indicate that the branch temperatures are stable. The operator can then physically open the flow control valve to initiate the test flow of gaseous nitrogen (GN2) through the manifold. Next, the software user interface will be monitored for stable temperature indications when the system is again at thermal equilibrium with the test flow of GN2. The temperature drop of each branch from its "no flow" stable temperature peak to its stable "with flow" temperature will allow the operator to determine whether a minimum level of flow exists. An alternative operation has the operator turning on the software only long enough to record the ambient temperature of the tubing before turning on the heaters and initiating GN2 flow. The stable temperature of the heated tubing with GN2 flow is then compared with the ambient tubing temperature to determine if flow is present in each branch. To help quantify the level of flow in the manifolds, each branch will be bench calibrated to establish its thermal properties using the flow detection system and different flow rates. These calibration values can then be incorporated into the software application to provide more detailed flow rate information.

Moss, Thomas↗
NASA NTRS2013

Human Machine Interface Programming and Testing

Human Machine Interface (HMI) Programming and Testing is about creating graphical displays to mimic mission critical ground control systems in order to provide NASA engineers with the ability to monitor the health management of these systems in real time. The Health Management System (HMS) is an online interactive human machine interface system that monitors all Kennedy Ground Control Subsystem (KGCS) hardware in the field. The Health Management System is essential to NASA engineers because it allows remote control and monitoring of the health management systems of all the Programmable Logic Controllers (PLC) and associated field devices. KGCS will have equipment installed at the launch pad, Vehicle Assembly Building, Mobile Launcher, as well as the Multi-Purpose Processing Facility. I am designing graphical displays to monitor and control new modules that will be integrated into the HMS. The design of the display screen will closely mimic the appearance and functionality of the actual modules. There are many different field devices used to monitor health management and each device has its own unique set of health management related data, therefore each display must also have its own unique way to display this data. Once the displays are created, the RSLogix5000 application is used to write software that maps all the required data read from the hardware to the graphical display. Once this data is mapped to its corresponding display item, the graphical display and hardware device will be connected through the same network in order to test all possible scenarios and types of data the graphical display was designed to receive. Test Procedures will be written to thoroughly test out the displays and ensure that they are working correctly before being deployed to the field. Additionally, the Kennedy Ground Controls Subsystem's user manual will be updated to explain to the NASA engineers how to use the new module displays.

Foster, Thomas Garrison↗
NASA NTRS2015

The Hopper: A Wearable Robotic Device Testbed for Micro-Gravity Bone-Loading Proof-of-Concept

Wearable robotic systems are showing increased potential for addressing crew countermeasures needs. Wearable robots offer a compactness, programmability, and eccentric loading capability not present in more conventional exercise equipment. Correspondingly, advancements in the man to machine interface has progressed, allowing for higher loads to be applied directly to the person in new and novel ways. Recently, the X1 exoskeleton, a lower extremity wearable robot originally designed for mobility assistance and rehabilitation, underwent human subject testing to assess its potential as a knee dynamometer. This was of interest to NASA physiologists because currently strength is not assessed in flight due to hardware limitations, and thus there is a poor understanding of the time course of in-flight changes to muscle strength. The study concluded that the X1 compared well with the Biodex, the "gold standard" in terrestrial dynamometry, with coefficients of variation less than 6.0%. In a following study, the X1 powered ankle was evaluated for its efficacy in exercising calf muscles. Current on-orbit countermeasures equipment does not adequately protect the calf from atrophy. The results of this study were also positive (targeted muscle activity demonstrated via comparing pre- and post-exercise magnetic resonance imaging T2 measurements), again showing the efficacy of wearable robotic devices for addressing the countermeasure needs of our astronauts. Based on these successes and lessons learned, the Grasshopper was co-developed between IHMC (Florida Institute for Human and Machine Cognition) and NASA. The Grasshopper, or the Hopper for short, is a wearable robotic device designed to address muscle and bone density loss for astronauts spending extended periods of time in micro-gravity. The Grasshopper connects to the user's torso like a hiking backpack, over the shoulders and around the waist. At the feet are footplates that strap to the user. There are two actuators, one at each "knee" joint, which are capable of high fidelity torque control. Because the Hopper uses motors instead of gravity to create the load on the user, the device is suited for use on space missions. Exercise in zero-gravity conditions is critical to maintain muscle strength and bone mass. In operation, the actuators try to fold up, or collapse, the device, putting a compressive load between the user's feet and torso. This force is similar to carrying a heavy backpack. The user then bends and extends his or her knees, replicating a weightlifting squat exercise. The applied load is precisely controlled by a computer, and can be programmed to simulate gravitation loads or any desired load prescription, such as free-weight squat exercise. It is even possible to perform eccentric exercises, or negatives, without the need for a spotter. Because the hip joints, as well as the spine and long leg bones, are in the applied load path, there is the potential to stimulate bone growth, countering the typical bone loss when astronauts return from extended duration space travel.

Beck, C. E.↗
NASA NTRS2002

The D3 Middleware Architecture

DARWIN is a NASA developed, Internet-based system for enabling aerospace researchers to securely and remotely access and collaborate on the analysis of aerospace vehicle design data, primarily the results of wind-tunnel testing and numeric (e.g., computational fluid-dynamics) model executions. DARWIN captures, stores and indexes data; manages derived knowledge (such as visualizations across multiple datasets); and provides an environment for designers to collaborate in the analysis of test results. DARWIN is an interesting application because it supports high-volumes of data. integrates multiple modalities of data display (e.g., images and data visualizations), and provides non-trivial access control mechanisms. DARWIN enables collaboration by allowing not only sharing visualizations of data, but also commentary about and views of data. Here we provide an overview of the architecture of D3, the third generation of DARWIN. Earlier versions of DARWIN were characterized by browser-based interfaces and a hodge-podge of server technologies: CGI scripts, applets, PERL, and so forth. But browsers proved difficult to control, and a proliferation of computational mechanisms proved inefficient and difficult to maintain. D3 substitutes a pure-Java approach for that medley: A Java client communicates (though RMI over HTTPS) with a Java-based application server. Code on the server accesses information from JDBC databases, distributed LDAP security services, and a collaborative information system. D3 is a three tier-architecture, but unlike 'E-commerce' applications, the data usage pattern suggests different strategies than traditional Enterprise Java Beans - we need to move volumes of related data together, considerable processing happens on the client, and the 'business logic' on the server-side is primarily data integration and collaboration. With D3, we are extending DARWIN to handle other data domains and to be a distributed system, where a single login allows a user transparent access to test results from multiple servers and authority domains.

Walton, Joan↗
NASA NTRS2011

CCSDS Advanced Orbiting Systems Virtual Channel Access Service for QoS MACHETE Model

To support various communications requirements imposed by different missions, interplanetary communication protocols need to be designed, validated, and evaluated carefully. Multimission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE), described in "Simulator of Space Communication Networks" (NPO-41373), NASA Tech Briefs, Vol. 29, No. 8 (August 2005), p. 44, combines various tools for simulation and performance analysis of space networks. The MACHETE environment supports orbital analysis, link budget analysis, communications network simulations, and hardware-in-the-loop testing. By building abstract behavioral models of network protocols, one can validate performance after identifying the appropriate metrics of interest. The innovators have extended the MACHETE model library to include a generic link-layer Virtual Channel (VC) model supporting quality-of-service (QoS) controls based on IP streams. The main purpose of this generic Virtual Channel model addition was to interface fine-grain flow-based QoS (quality of service) between the network and MAC layers of the QualNet simulator, a commercial component of MACHETE. This software model adds the capability of mapping IP streams, based on header fields, to virtual channel numbers, allowing extended QoS handling at link layer. This feature further refines the QoS v existing at the network layer. QoS at the network layer (e.g. diffserv) supports few QoS classes, so data from one class will be aggregated together; differentiating between flows internal to a class/priority is not supported. By adding QoS classification capability between network and MAC layers through VC, one maps multiple VCs onto the same physical link. Users then specify different VC weights, and different queuing and scheduling policies at the link layer. This VC model supports system performance analysis of various virtual channel link-layer QoS queuing schemes independent of the network-layer QoS systems.

Jennings, Esther H.↗
NASA NTRS2016

Space Launch System Spacecraft and Payload Elements: Making Progress Toward First Launch

Significant and substantial progress continues to be accomplished in the design, development, and testing of the Space Launch System (SLS), the most powerful human-rated launch vehicle the United States has ever undertaken. Designed to support human missions into deep space, SLS is one of three programs being managed by the National Aeronautics and Space Administration's (NASA's) Exploration Systems Development directorate. The Orion spacecraft program is developing a new crew vehicle that will support human missions beyond low Earth orbit, and the Ground Systems Development and Operations (GSDO) program is transforming Kennedy Space Center (KSC) into next-generation spaceport capable of supporting not only SLS but also multiple commercial users. Together, these systems will support human exploration missions into the proving ground of cislunar space and ultimately to Mars. SLS will deliver a near-term heavy-lift capability for the nation with its 70 metric ton Block 1 configuration, and will then evolve to an ultimate capability of 130 metric tons. The SLS program marked a major milestone with the successful completion of the Critical Design Review in which detailed designs were reviewed and subsequently approved for proceeding with full-scale production. This marks the first time an exploration class vehicle has passed that major milestone since the Saturn V vehicle launched astronauts in the 1960s during the Apollo program. Each element of the vehicle now has flight hardware in production in support of the initial flight of the SLS - Exploration Mission-1 (EM-1), an uncrewed mission to orbit the moon and return, and progress in on track to meet the initial targeted launch date in 2018. In Utah and Mississippi, booster and engine testing are verifying upgrades made to proven shuttle hardware. At Michoud Assembly Facility (MAF) in Louisiana, the world's largest spacecraft welding tool is producing tanks for the SLS core stage. This paper will particularly focus on work taking place at Marshall Space Flight Center (MSFC) and United Launch Alliance (ULA) in Alabama, where upper stage and adapter elements of the vehicle are being constructed and tested. Providing the Orion crew capsule/launch vehicle interface and in-space propulsion via a cryogenic upper stage, the Spacecraft/Payload Integration and Evolution (SPIE) Element serves a key role in achieving SLS goals and objectives. The SPIE element marked a major milestone in 2014 with the first flight of original SLS hardware, the Orion Stage Adapter (OSA) which was used on Exploration Flight Test-1 with a design that will be used again on EM-1. Construction is already underway on the EM-1 Interim Cryogenic Propulsion Stage (ICPS), an in-space stage derived from the Delta Cryogenic Second Stage. Manufacture of the Orion Stage Adapter and the Launch Vehicle Stage Adapter is set to begin at the Friction Stir Facility located at MSFC while structural test articles are either completed (OSA) or nearing completion (Launch Vehicle Stage Adapter). An overview is provided of the launch vehicle capabilities, with a specific focus on SPIE Element qualification/testing progress, as well as efforts to provide access to deep space regions currently not available to the science community through a secondary payload capability utilizing CubeSat-class satellites.

Schorr, Andrew A.↗
NASA NTRS2002

Science Planning for Multi-Spacecraft Coordinated Observations

Fulfilling the promise of an era of great observatories, NASA now has more than three space-based astronomical telescopes operating in different wavebands. This situation provides astronomers with a unique opportunity to simultaneously observe with multiple observatories. Yet scheduling multiple observatories simultaneously is highly inefficient when compared to single observatory observations. Thus, programs using multiple observatories are limited not due to scientific restrictions, but due to operational inefficiencies. Each year, a number of proposals are accepted by a space-based observatory for conduction of astronomical observations and gathering of science data for the study of galactic events. Since each space-based observatory uses a set of instruments designed to operate in specific energy regions, most such studies are conducted by submitting observation proposals to multiple observatories, with requests to coordinate among themselves. To assure that the proposed observations can be scheduled, each observatory's staff has to check that the observations are valid and meet all the constraints for their own observatory; in addition, they have to verify that the observations satisfy the constraints of the other observatories. Thus, coordinated observations require painstaking manual collaboration among the observatory staff at each observatory. In order to exploit new paradigms for observatory operation, the Goddard Space Flight Center's Advanced Architectures and Automation Branch has developed a prototype tool called the Visual Observation Layout Tool (VOLT). The main objective of VOLT is to provide a visual tool to automate the science planning of coordinated observations for multiple spacecraft, as well as to increase the scheduling probability of observations. However, VOLT is also useful for single observatory planning to optimize observatory control. Three space-based missions are interested in using VOLT (the Hubble Space Telescope, the Chandra X-Ray Observatory, and the Far Ultraviolet Spectroscopic Explorer). The VOLT team members have collaborated with these missions to gather requirements and obtain feedback on their mission planning processes. VOLT has been developed as a cross-platform Java client application for use by scientists and observatory science planning staff to visualize scheduling options and constraints. It also supports a lightweight graphical user interface for remote viewing via a Web front end. Additionally, it uniquely supports the ability to interact with multiple, diverse scheduling packages in order to determine windows of opportunity for observations and visually portray the constraints of each observation request. VOLT enables science data capture scenarios which are currently either impossible, or which require extensive time and manpower to coordinate amongst multiple observatories. it supports early detection of planning conflicts by generating coordinated solutions based on observatory schedulability and constraints. The project development approach has included frequent prototype demonstrations to our interested missions to obtain feedback after each release of the software. We will present an overview of our lessons learned in infusing the VOLT tool into the operations of the missions we have collaborated with and a brief demonstration of the software.

Maks, Lori↗
NASA NTRS2000

Modeling and Design of an Electro-Rheological Fluid Based Haptic System for Tele-Operation of Space Robots

For many years, the robotic community sought to develop robots that can eventually operate autonomously and eliminate the need for human operators. However, there is an increasing realization that there are some tasks that human can perform significantly better but, due to associated hazards, distance, physical limitations and other causes, only robot can be employed to perform these tasks. Remotely performing these types of tasks requires operating robots as human surrogates. While current "hand master" haptic systems are able to reproduce the feeling of rigid objects, they present great difficulties in emulating the feeling of remote/virtual stiffness. In addition, they tend to be heavy, cumbersome and usually they only allow limited operator workspace. In this paper a novel haptic interface is presented to enable human-operators to "feel" and intuitively mirror the stiffness/forces at remote/virtual sites enabling control of robots as human-surrogates. This haptic interface is intended to provide human operators intuitive feeling of the stiffness and forces at remote or virtual sites in support of space robots performing dexterous manipulation tasks (such as operating a wrench or a drill). Remote applications are referred to the control of actual robots whereas virtual applications are referred to simulated operations. The developed haptic interface will be applicable to IVA operated robotic EVA tasks to enhance human performance, extend crew capability and assure crew safety. The electrically controlled stiffness is obtained using constrained ElectroRheological Fluids (ERF), which changes its viscosity under electrical stimulation. Forces applied at the robot end-effector due to a compliant environment will be reflected to the user using this ERF device where a change in the system viscosity will occur proportionally to the force to be transmitted. In this paper, we will present the results of our modeling, simulation, and initial testing of such an electrorheological fluid (ERF) based haptic device.

Mavroidis, Constantinos↗
NASA NTRS2015

Simulation Apps Bring Us Closer to Mars

My work with mathematical modeling and computer simulations began in earnest in 1987 when I signed on with the National Aeronautics and Space Administration, better known as NASA. At the time I was developing computer simulations to support the design of carbon dioxide (CO2) removal systems for the International Space Station (ISS) life support system. CO2 is a human metabolic waste, produced at a rate of a kilogram per day per crewmember. CO2 must be removed from the crew cabin, as it will quickly become detrimental to crew health. The systems used to remove CO2 are typically based on sorption processes, which include complex interactions of heat transfer, mass transfer, and gas flow through porous media. At this time, there were no commercial options for solving a set of coupled mathematical models such as partial differential equations (PDEs); you either force-fit the physics into a thermal analysis package or wrote your own code, complete with discretization, meshing, and solution algorithms. Unfortunately, coding CO2 removal processes from scratch did not allow an appropriate focus on the challenging yet crucial task of understanding and capturing the underlying physics via appropriate mathematical models. Configuration control was often simply ignored due to tight schedules, resulting in a code that would be quicker for a second party to rewrite than modify. In the early 2000s, I decided to move CO2 removal simulations to a platform with built-in meshing, solvers, and postprocessing capabilities, and that could solve user-defined multiphysics PDEs. The program chosen to meet these needs was COMSOL Multiphysics®. Along with freeing the engineer to focus on the underlying physics, a degree of configuration control was automatically achieved via a consistent user interface, thus allowing COMSOL users to share computer models. My team has developed simulations that are already providing a valuable debugging capability for the ISS CO2 removal system, and will provide guidance in upgrades to that system.

Knox, Jim↗
NASA NTRS2000

Internet Technologies for Space-based Communications: State of the Art and Challenges

The Internet is rapidly changing the ways we communicate information around the globe today. The desire to provide Internet-based services to anyone, anywhere, anytime has brought satellite communications to the forefront to become an integral part of the Internet. In spite of the distances involved, satellite links are proving to be capable of providing Internet services based on Internet protocol (TCP/IP) stack. This development has led to the question particularly at NASA; can satellites and other space platforms become an Internet-node in space? This will allow the direct transfer of information directly from space to the users on Earth and even be able to control the spacecraft and its instruments. NASA even wants to extend the near earth space Internet to deep space applications where scientists and the public here on Earth may view space exploration in real time via the Internet. NASA's future solar system exploration will involve intensive in situ investigations of planets, moons, asteroids, and comets. While past missions typically involved a single fly-by or orbiting science spacecraft, future missions will begin to use fleets of small, highly intelligent robotic vehicles to carry out collaborative investigations. The resulting multi-spacecraft topologies will effectively create a wide area network spanning the solar system. However, this will require significant development in Internet technologies for space use. This paper provides the status'of the Internet for near earth applications and the potential extension of the Internet for use in deep space planetary exploration. The paper will discuss the overall challenges of implementing the space Internet and how the space Internet will integrate into the complex terrestrial systems those forms the Internet of today in a hybrid set of networks. Internet. We envision extending to the deep space environment such Internet concepts as a well-designed layered architecture. This effort will require an ability to develop and infuse new physical layer technology to increase network bandwidth at very low-bit error rates. In addition, we identify network technologies such as routers and switches needed to maintain standard application layer interfaces, while providing low-cost, efficient, modular networking solutions. We will describe the overall architectural approach to extending the concept of the Internet to space and highlight the important technological challenges and initiatives that will make it a reality.

Bhasin, K.↗
NASA NTRS2004

Bolt Analysis Program

In designing and testing bolted joints there are multiple parameters to be considered and calculations that must be performed to predict the joint behavior. Each different set of parameters may call for a different set of equations. Determining every parameter in each bolted joint is impractical and in many cases impossible. On the other hand, it is much easier to reduce these calculations to a universal set that can be used for all bolted joints. This is the purpose of the Bolt Analysis Program. My project under the Mechanical and Rotating Systems branch of the Engineering Development and Analysis Division was to take the Bolt Analysis Program Version 2.0 and update the program to a modem and user-friendly format. Version 2.0 of the Bolt Analysis Program is a useful program, but lacks the dynamic capabilities that are needed for current applications. Version 2.0 of the Bolt Analysis Program was written in 1993 using the Pascal programming language in a DOS format. This program allows you to input data in a step-by-step format, calculates the data, and then on a final screen displays the input and the output fiom the calculations. Version 2.0 is still applicable for all bolted joint anaiysis, but has updates that are desired. First, the program runs in DOS format. With the applications available today, my mentor decided it would be best to update the program into Excel using Visual Basic for Applications (VBA). This would allow the program to have multiple Graphical User Interfaces (GUI s) while retaining all functions of the previous program. Version 2.0 only allows you to input data in a step-by-step process. If you make a mistake and need to go back, you must run through the entire program before you can return to fix your error. This becomes tedious when needing to change one parameter or test multiple sets of data. In Version 3.0, the program allows you to enter and change data at any time while displaying real-time output data. If you realize an error, it is as simple as scrolling back to your mistake and changing the data. Additional information is included in the original extended abstract.

Travis, Brandon E.↗
NASA NTRS2006

Remote Sensing Time Series Product Tool

The TSPT (Time Series Product Tool) software was custom-designed for NASA to rapidly create and display single-band and band-combination time series, such as NDVI (Normalized Difference Vegetation Index) images, for wide-area crop surveillance and for other time-critical applications. The TSPT, developed in MATLAB, allows users to create and display various MODIS (Moderate Resolution Imaging Spectroradiometer) or simulated VIIRS (Visible/Infrared Imager Radiometer Suite) products as single images, as time series plots at a selected location, or as temporally processed image videos. Manually creating these types of products is extremely labor intensive; however, the TSPT development tool makes the process simplified and efficient. MODIS is ideal for monitoring large crop areas because of its wide swath (2330 km), its relatively small ground sample distance (250 m), and its high temporal revisit time (twice daily). Furthermore, because MODIS imagery is acquired daily, rapid changes in vegetative health can potentially be detected. The new TSPT technology provides users with the ability to temporally process high-revisit-rate satellite imagery, such as that acquired from MODIS and from its successor, the VIIRS. The TSPT features the important capability of fusing data from both MODIS instruments onboard the Terra and Aqua satellites, which drastically improves cloud statistics. With the TSPT, MODIS metadata is used to find and optionally remove bad and suspect data. Noise removal and temporal processing techniques allow users to create low-noise time series plots and image videos and to select settings and thresholds that tailor particular output products. The TSPT GUI (graphical user interface) provides an interactive environment for crafting what-if scenarios by enabling a user to repeat product generation using different settings and thresholds. The TSPT Application Programming Interface provides more fine-tuned control of product generation, allowing experienced programmers to bypass the GUI and to create more user-specific output products, such as comparison time plots or images. This type of time series analysis tool for remotely sensed imagery could be the basis of a large-area vegetation surveillance system. The TSPT has been used to generate NDVI time series over growing seasons in California and Argentina and for hurricane events, such as Hurricane Katrina.

Predos, Don↗
NASA NTRS2004

Practical Pocket PC Application w/Biometric Security

I work in the Flight Software Engineering Branch, where we provide design and development of embedded real-time software applications for flight and supporting ground systems to support the NASA Aeronautics and Space Programs. In addition, this branch evaluates, develops and implements new technologies for embedded real-time systems, and maintains a laboratory for applications of embedded technology. The majority of microchips that are used in modern society have been programmed using embedded technology. These small chips can be found in microwaves, calculators, home security systems, cell phones and more. My assignment this summer entails working with an iPAQ HP 5500 Pocket PC. This top-of-the-line hand-held device is one of the first mobile PC's to introduce biometric security capabilities. Biometric security, in this case a fingerprint authentication system, is on the edge of technology as far as securing information. The benefits of fingerprint authentication are enormous. The most significant of them are that it is extremely difficult to reproduce someone else's fingerprint, and it is equally difficult to lose or forget your own fingerprint as opposed to a password or pin number. One of my goals for this summer is to integrate this technology with another Pocket PC application. The second task for the summer is to develop a simple application that provides an Astronaut EVA (Extravehicular Activity) Log Book capability. The Astronaut EVA Log Book is what an astronaut would use to report the status of field missions, crew physical health, successes, future plans, etc. My goal is to develop a user interface into which these data fields can be entered and stored. The applications that I am developing are created using eMbedded Visual C++ 4.0 with the Pocket PC 2003 Software Development Kit provided by Microsoft.

Logan, Julian↗
NASA NTRS2012

Wireless Self-Acquistion of 12-Lead ECG via Android Smart Phone

Researchers at NASA s Johnson Space Center and at Orbital Research, Inc. (a NASA SBIR grant recipient) have recently developed a dry-electrode harness that allows for self-acquisition of resting 12-lead ECGs by minimally trained laypersons. When used in conjunction with commercial wireless (e.g., Bluetooth(TM) or 802.11-enabled) 12-lead ECG devices and custom smart phone-based software, the collected 12-lead ECG data can also immediately be forwarded from any geographic location within cellular range to the user s physician(s) of choice. The system can also be used to immediately forward to central receiving stations 12-lead ECG data collected during space flight or during activities in any remote terrestrial location supported by an internet or cellular phone infrastructure. The main novel aspects of the system are first, the dry-electrode 12-lead ECG harness itself, and second, an accompanying Android(TM) smart phone-based wireless 12-lead ECG capability. The ECG harness nominally employs dry electrodes manufactured by Orbital Research, Inc, recently cleared through the Food and Drug Administration (FDA). However, other dry electrodes that are not yet FDA cleared, for example those recently developed by Nanosonic, Inc as part of another NASA SBIR grant, can also be used. The various advantageous features of the harness include: 1) laypersons can be quickly instructed on its correct use, remotely if necessary; 2) all tangled "leadwire spaghetti" is eliminated, as is the common clinical problem of "leadwire reversal"; 3) all adhesives and disposables are also eliminated, the harness being fully reusable; if multiple individuals intend to use use the same harness, then standard antimicrobial wipes can be employed to sterilize the dry electrodes (and harness surface if needed) between users; 5) padded cushions at the lateral sides of the torso function to press the left arm (LA) and right arm (RA) dry electrodes mounted on the cushions against sideward or downward-rested arms of the subject; 6) sufficient distal placement of the arm electrodes achieves good electrode abutment to the arms without the need for adhesives, straps, bands, bracelets, or gloves; 7) padding over the sternum avoids "tenting" in the V1 through V3 (and, when present, the V3R) electrode positions; 8) easy-to-don, one-piece design with an adjustable, front-side single point of connection and an adjustable shoulder strap; and 9) Lund or "modified Lund" placement of the dry electrodes, the results of which more effectively reproduce results from "standard" 12-lead ECG placements than do results from Mason-Likar placements. The main limitation of the harness is that "one size does not fit all", meaning that an appropriately sized harness (small, medium, large, etc) must be chosen on the basis of an individual's size. To facilitate the use of the harness with inexpensive, commodity-grade cell phones and tablet devices, 12-lead ECG software is also being developed to accompany the harness for wireless use with Android. For this part of the project, NASA has teamed with TopCoder, Inc and the Harvard-affiliated NASA Tournament Lab in sponsoring java-based software programming contests through TopCoder. While ECG signals from the harness can already be wirelessly received and thoroughly processed (locally or remotely) by commercial-grade conventional (as well as advanced) 12-lead ECG software running on Microsoft Windows(TM), the Android-based software, once completed, will "cast a wider net" by allowing for a greater percentage of cell phone owners to participate in inexpensive, store-and-forward recordings of 12-lead ECGs worldwide, including for example Android cell phone users in many remote, third-world locations. At the time of writing, the Android 12-lead ECG software platform consists of a basic but expanding graphical user interface and accompanying software that: 1) wirelessly receives the 12-lead ECG data stream from a Bluetooth-based, FDA-cleared 12-leaCG device attached to the harness; 2) locally stores the same data in binary format to the SD card on the Android cell phone; and 3) makes the data stream in available in real time, for now to TopCoder's java programming contestants.

Schlegel, Todd T.↗
NASA NTRS2016

Space Launch System Spacecraft and Payload Elements: Making Progress Toward First Launch

Significant and substantial progress continues to be accomplished in the design, development, and testing of the Space Launch System (SLS), the most powerful human-rated launch vehicle the United States has ever undertaken. Designed to support human missions into deep space, SLS is one of three programs being managed by the National Aeronautics and Space Administration's (NASA's) Exploration Systems Development directorate. The Orion spacecraft program is developing a new crew vehicle that will support human missions beyond low Earth orbit, and the Ground Systems Development and Operations program is transforming Kennedy Space Center into next-generation spaceport capable of supporting not only SLS but also multiple commercial users. Together, these systems will support human exploration missions into the proving ground of cislunar space and ultimately to Mars. SLS will deliver a near-term heavy-lift capability for the nation with its 70 metric ton (t) Block 1 configuration, and will then evolve to an ultimate capability of 130 t. The SLS program marked a major milestone with the successful completion of the Critical Design Review in which detailed designs were reviewed and subsequently approved for proceeding with full-scale production. This marks the first time an exploration class vehicle has passed that major milestone since the Saturn V vehicle launched astronauts in the 1960s during the Apollo program. Each element of the vehicle now has flight hardware in production in support of the initial flight of the SLS -- Exploration Mission-1 (EM-1), an un-crewed mission to orbit the moon and return. Encompassing hardware qualification, structural testing to validate hardware compliance and analytical modeling, progress in on track to meet the initial targeted launch date in 2018. In Utah and Mississippi, booster and engine testing are verifying upgrades made to proven shuttle hardware. At Michoud Assembly Facility in Louisiana, the world's largest spacecraft welding tool is producing tanks for the SLS core stage. This paper will particularly focus on work taking place at Marshall Space Flight Center (MSFC) and United Launch Alliance in Alabama, where upper stage and adapter elements of the vehicle are being constructed and tested. Providing the Orion crew capsule/launch vehicle interface and in-space propulsion via a cryogenic upper stage, the Spacecraft/Payload Integration and Evolution (SPIE) Element serves a key role in achieving SLS goals and objectives. The SPIE element marked a major milestone in 2014 with the first flight of original SLS hardware, the Orion Stage Adapter (OSA) which was used on Exploration Flight Test-1 with a design that will be used again on EM-1. Construction is already underway on the EM-1 Interim Cryogenic Propulsion Stage (ICPS), an in-space stage derived from the Delta Cryogenic Second Stage. Manufacture of the Orion Stage Adapter and the Launch Vehicle Stage Adapter is set to begin at the Friction Stir Facility located at MSFC while structural test articles are either completed (OSA) or nearing completion (Launch Vehicle Stage Adapter). An overview is provided of the launch vehicle capabilities, with a specific focus on SPIE Element qualification/testing progress, as well as efforts to provide access to deep space regions currently not available to the science community through a secondary payload capability utilizing CubeSat-class satellites.

Schorr, Andrew A.↗