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,585 records · Page 88
All sourcesNASA NTRSDOE OSTI
NASA NTRS2013

Orbital Debris Engineering Model (ORDEM) v.3

A model of the manmade orbital debris environment is required by spacecraft designers, mission planners, and others in order to understand and mitigate the effects of the environment on their spacecraft or systems. A manmade environment is dynamic, and can be altered significantly by intent (e.g., the Chinese anti-satellite weapon test of January 2007) or accident (e.g., the collision of Iridium 33 and Cosmos 2251 spacecraft in February 2009). Engineering models are used to portray the manmade debris environment in Earth orbit. The availability of new sensor and in situ data, the re-analysis of older data, and the development of new analytical and statistical techniques has enabled the construction of this more comprehensive and sophisticated model. The primary output of this model is the flux [#debris/area/time] as a function of debris size and year. ORDEM may be operated in spacecraft mode or telescope mode. In the former case, an analyst defines an orbit for a spacecraft and "flies" the spacecraft through the orbital debris environment. In the latter case, an analyst defines a ground-based sensor (telescope or radar) in terms of latitude, azimuth, and elevation, and the model provides the number of orbital debris traversing the sensor's field of view. An upgraded graphical user interface (GUI) is integrated with the software. This upgraded GUI uses project-oriented organization and provides the user with graphical representations of numerous output data products. These range from the conventional flux as a function of debris size for chosen analysis orbits (or views), for example, to the more complex color-contoured two-dimensional (2D) directional flux diagrams in local spacecraft elevation and azimuth.

Matney, Mark↗
NASA NTRSDate not supplied

Radiation-Hard Parallel Readout Circuit for Low-Frequency Voltage Signal Measurements

NASA Goddard Space Flight Center (GSFC) has successfully developed and tested a custom-designed low-noise multi-channel digitizer (MCD) application specific integrated circuit (ASIC) for operation in harsh radiation environments. The MCD-ASIC is optimized for low-frequency and low-voltage signal measurements from sensors and transducers. It has 20 input channels where each channel is comprised of auto-zeroed chopper variable-gain amplifier, post amplifier, and a second order ∑∆ modulator. ∑∆ analog-to-digital converter (ADC) relies on oversampling and noise shaping to achieve high-resolution conversion. However, the MCD-ASIC requires digital filtering and decimation to convert the output single bit streams from the ADC to useful data words. A parallel digital platform such as a field-programmable-gate-array (FPGA) is highly suitable to fully leverage the capabilities of the MCD-ASIC. The FPGA controls the MCD-ASIC via serial peripheral interface (SPI) protocol and acquires data from it. A Python-script communicates with the FPGA board through a USB interface on a cross operating platform. Using this architecture, the system is capable of monitoring up to 20 voltage readout channels simultaneously in a real-time manner. Each channel’s parameters can be programmed independently allowing maximum user versatility. In this paper, we present analysis of the analog front-end, the implementation of the digital processing unit on the FPGA, and provide noise performance results from the MCD-ASIC readout.

ASIC↗
NASA NTRSDate not supplied

The Doppler Wind and Temperature Sounder (DWTS) Flight Evaluation and Experiments (TES-16,17)

The Doppler Wind and Temperature Sounder instrument (DWTS) developed by Global Atmospheric Technologies and Sciences (GATS) is a simple yet powerful tool with the potential to become a new window through which the study of upper atmosphere dynamics can occur. Based around a defense-grade infrared camera peering through a static gas cell used as a scanning spectral filter, a DWTS instrument can infer wind velocities and kinetic temperatures throughout the stratosphere and lower thermosphere. The DWTS achieves this scanning by measuring the induced Doppler shift and Doppler broadening of emissions as they pass through the DWTS field of view (Gordley, Marshall, 2011). The DWTS holds promise in improving accuracy in weather determination among other terrestrial benefits, and the core technology can be easily adapted to study the dynamics of other planetary atmospheres. In partnership with GATS, NOAA, and other collaborators, NASA Ames and the Nano-Orbital Workshop (NOW) group have been working to evaluate the DWTS instrument on orbit and optimize it as a flexible payload for nanosatellites. The first mission selected for DWTS technical evaluation is preparing for flight in early 2024, which will be followed by a more capable science mission in 2025, with both missions being part of the TES-n/NOW heritage flight series. The first rapid technology demonstration flight, TES-16/DWTS-A, will demonstrate a single DWTS instrument in an approximately 2U payload volume. With an estimated power consumption of 50 watts, the instrument will maintain the imaging sensor plane at 80K during instrument performance evaluation periods using an integrated Stirling cryocooler. Data from DWTS will be captured and processed via a NOW-designed custom data interface unit before being transmitted via S-band radio back to select ground stations, with instrument command and control maintained via L-band global-coverage radio. The subsequent TES-17/DWTS-B mission will be a dedicated science mission tasked with validating the instrument’s full altitude coverage capabilities, currently estimated from 20 to 200 km during both day and night. This new atmospheric observational capability will come from a single small satellite equipped with three DWTS imagers, each hosting a different gas cell chemistry, to form a complete instrument. The intention of this flight series, and one of NASA’s interests in this instrument, is not only to advance Earth atmospheric dynamics, but to advance a Martian atmospheric study instrument as well (Colaprete, Gordley, et al) which, if successful, would greatly further understanding of Martian atmospheric dynamics. This document describes the flight series in detail, including challenges facing the TES-16 flight tests and the projected challenges and application of Mars study. Additional detail regarding the possible applications of a Cognitive Communication technique in current flight development by NOW collaborators at the NASA Glenn Research Center is also discussed, including the implications of using an automated User Initiated Service (UIS) protocol to maximize the data collected per orbit.

DWTS Nano-satellite TES-n↗
NASA NTRS2005

NASA Interactive Forms Type Interface - NIFTI

A flexible database query, update, modify, and delete tool was developed that provides an easy interface to Oracle forms. This tool - the NASA interactive forms type interface, or NIFTI - features on-the- fly forms creation, forms sharing among users, the capability to query the database from user-entered criteria on forms, traversal of query results, an ability to generate tab-delimited reports, viewing and downloading of reports to the user s workstation, and a hypertext-based help system. NIFTI is a very powerful ad hoc query tool that was developed using C++, X-Windows by a Motif application framework. A unique tool, NIFTI s capabilities appear in no other known commercial-off-the- shelf (COTS) tool, because NIFTI, which can be launched from the user s desktop, is a simple yet very powerful tool with a highly intuitive, easy-to-use graphical user interface (GUI) that will expedite the creation of database query/update forms. NIFTI, therefore, can be used in NASA s International Space Station (ISS) as well as within government and industry - indeed by all users of the widely disseminated Oracle base. And it will provide significant cost savings in the areas of user training and scalability while advancing the art over current COTS browsers. No COTS browser performs all the functions NIFTI does, and NIFTI is easier to use. NIFTI s cost savings are very significant considering the very large database with which it is used and the large user community with varying data requirements it will support. Its ease of use means that personnel unfamiliar with databases (e.g., managers, supervisors, clerks, and others) can develop their own personal reports. For NASA, a tool such as NIFTI was needed to query, update, modify, and make deletions within the ISS vehicle master database (VMDB), a repository of engineering data that includes an indentured parts list and associated resource data (power, thermal, volume, weight, and the like). Since the VMDB is used both as a collection point for data and as a common repository for engineering, integration, and operations teams, a tool such as NIFTI had to be designed that could expedite the creation of database query/update forms which could then be shared among users.

Jain, Bobby↗
NASA NTRS1997

Cooperative Data Sharing: Simple Support for Clusters of SMP Nodes

Libraries like PVM and MPI send typed messages to allow for heterogeneous cluster computing. Lower-level libraries, such as GAM, provide more efficient access to communication by removing the need to copy messages between the interface and user space in some cases. still lower-level interfaces, such as UNET, get right down to the hardware level to provide maximum performance. However, these are all still interfaces for passing messages from one process to another, and have limited utility in a shared-memory environment, due primarily to the fact that message passing is just another term for copying. This drawback is made more pertinent by today's hybrid architectures (e.g. clusters of SMPs), where it is difficult to know beforehand whether two communicating processes will share memory. As a result, even portable language tools (like HPF compilers) must either map all interprocess communication, into message passing with the accompanying performance degradation in shared memory environments, or they must check each communication at run-time and implement the shared-memory case separately for efficiency. Cooperative Data Sharing (CDS) is a single user-level API which abstracts all communication between processes into the sharing and access coordination of memory regions, in a model which might be described as "distributed shared messages" or "large-grain distributed shared memory". As a result, the user programs to a simple latency-tolerant abstract communication specification which can be mapped efficiently to either a shared-memory or message-passing based run-time system, depending upon the available architecture. Unlike some distributed shared memory interfaces, the user still has complete control over the assignment of data to processors, the forwarding of data to its next likely destination, and the queuing of data until it is needed, so even the relatively high latency present in clusters can be accomodated. CDS does not require special use of an MMU, which can add overhead to some DSM systems, and does not require an SPMD programming model. unlike some message-passing interfaces, CDS allows the user to implement efficient demand-driven applications where processes must "fight" over data, and does not perform copying if processes share memory and do not attempt concurrent writes. CDS also supports heterogeneous computing, dynamic process creation, handlers, and a very simple thread-arbitration mechanism. Additional support for array subsections is currently being considered. The CDS1 API, which forms the kernel of CDS, is built primarily upon only 2 communication primitives, one process initiation primitive, and some data translation (and marshalling) routines, memory allocation routines, and priority control routines. The entire current collection of 28 routines provides enough functionality to implement most (or all) of MPI 1 and 2, which has a much larger interface consisting of hundreds of routines. still, the API is small enough to consider integrating into standard os interfaces for handling inter-process communication in a network-independent way. This approach would also help to solve many of the problems plaguing other higher-level standards such as MPI and PVM which must, in some cases, "play OS" to adequately address progress and process control issues. The CDS2 API, a higher level of interface roughly equivalent in functionality to MPI and to be built entirely upon CDS1, is still being designed. It is intended to add support for the equivalent of communicators, reduction and other collective operations, process topologies, additional support for process creation, and some automatic memory management. CDS2 will not exactly match MPI, because the copy-free semantics of communication from CDS1 will be supported. CDS2 application programs will be free to carefully also use CDS1. CDS1 has been implemented on networks of workstations running unmodified Unix-based operating systems, using UDP/IP and vendor-supplied high- performance locks. Although its inter-node performance is currently unimpressive due to rudimentary implementation technique, it even now outperforms highly-optimized MPI implementation on intra-node communication due to its support for non-copy communication. The similarity of the CDS1 architecture to that of other projects such as UNET and TRAP suggests that the inter-node performance can be increased significantly to surpass MPI or PVM, and it may be possible to migrate some of its functionality to communication controllers.

DiNucci, David C.↗
NASA NTRS2013

Space Operations Learning Center (SOLC) iPhone/iPad Application

This iPhone application, Space Junk Sammy, is intended to be an educational application designed for Apple iPhones and iPads. This new concept educates kids in an innovative way about how orbital debris affects space missions. Orbital debris is becoming a very significant concern for NASA and all Earthorbiting space missions. Spacecraft in low-Earth orbit are in constant danger of being potentially damaged or destroyed by debris. High-profile spacecraft such as the International Space Station (ISS) and Hubble Space Telescope are dealing with orbital debris on a regular basis. Other basic educational concepts that are portrayed are low-Earth orbits, satellites, ISS, attitude control, and other facts that can be presented in betweenlevel popup screens. The Orbital Debris Cleanup game is relatively simple from the user s technical standpoint. It is a 2D game where the user s avatar is a satellite buddy, named Sammy, in orbit around Earth. Sammy is controlled by the user with the device s gyroscope as well as touchscreen controls. It has equipment used for taking care of the space debris objects on the screen. Sammy also has a claw, a laser deflector, and hydrazine rockets to grab or push the debris objects into a higher orbit or into a lower orbit to burn up in the Earth s atmosphere. The user interface shows Sammy and space debris objects constantly moving from left to right, where Sammy is trying to catch the debris objects before they move off the right side of the screen. Everything will be in constant motion to increase fun and add to the realism of orbiting the Earth. The satellite buddy is used to clean up the space debris and protect other satellites. Later levels will include a laser deflector and hydrazine rockets instead of a robotic claw to push the orbital debris into a higher orbit and out of the path of other satellites

Binebrink, Daniel↗
NASA NTRS1993

INMARSAT's personal communicator system

Inmarsat has been providing near global mobile satellite communications since 1982 and Inmarsat terminals are currently being used in more than 130 countries. The terminals have been reduced in size and cost over the years and new technology has enabled the recent introduction of briefcase sized personal telephony terminals (Inmarsat-M). This trend continues and we are likely to see Inmarsat handheld terminals by the end of the decade. These terminals are called Inmarsat-P and this paper focuses on the various elements required to support a high quality service to handheld terminals. The main system elements are: the handheld terminals; the space segment with the associated orbits; and the gateways to terrestrial networks. It is both likely and desirable that personal handheld satellite communications will be offered by more than one system provider and this competition will ensure strong emphasis on service quality and cost of ownership. The handheld terminals also have to be attractive to a large number of potential users, and this means that the terminals must be small enough to fit in a pocket. Battery lifetime is another important consideration, and this coupled with radiation safety requirements limits the maximum radiated EIRP. The terminal G/T is mainly constrained by the gain of the omnidirectional antenna and the noise figure of the RF front end (including input losses). Inmarsat has examined, with the support of industry, a number of Geosynchronous (GSO), Medium Earth Orbit (MEO) and Low Earth Orbit (LEO) satellite options for the provision of a handheld mobile satellite service. This paper describes the key satellite and orbit parameters and tradeoffs which affect the overall quality of service and the space segment costing. The paper also stresses not only the importance of using and sharing the available mobile frequency band allocations efficiently, but also the key considerations affecting the choice of feeder link bands. The design of the gateways and the terrestrial network is critical to the overall viability of the service, and this paper also examines the key technical parameters associated with the Land Earth Stations (LES), which act as gateways into the Public Switched Telephone Network (PSTN). These not only include the design tradeoffs associated with the LES, but also the different terrestrial network interface options. The paper concludes with a brief description of the satellite propagation conditions associated with the use of handheld terminals. It describes how the handheld results in a number of propagation impairments which are not common to the previous measurements associated with vehicle mounted antennas. These measurements indicate that there is a complex tradeoff between link margin and the elevation angle to the satellite which has a significant impact on the space segment requirements and costing.

Hart, Nick↗
NASA NTRS2001

Simple, Scalable, Script-Based Science Processor (S4P)

The development and deployment of data processing systems to process Earth Observing System (EOS) data has proven to be costly and prone to technical and schedule risk. Integration of science algorithms into a robust operational system has been difficult. The core processing system, based on commercial tools, has demonstrated limitations at the rates needed to produce the several terabytes per day for EOS, primarily due to job management overhead. This has motivated an evolution in the EOS Data Information System toward a more distributed one incorporating Science Investigator-led Processing Systems (SIPS). As part of this evolution, the Goddard Earth Sciences Distributed Active Archive Center (GES DAAC) has developed a simplified processing system to accommodate the increased load expected with the advent of reprocessing and launch of a second satellite. This system, the Simple, Scalable, Script-based Science Processor (S42) may also serve as a resource for future SIPS. The current EOSDIS Core System was designed to be general, resulting in a large, complex mix of commercial and custom software. In contrast, many simpler systems, such as the EROS Data Center AVHRR IKM system, rely on a simple directory structure to drive processing, with directories representing different stages of production. The system passes input data to a directory, and the output data is placed in a "downstream" directory. The GES DAAC's Simple Scalable Script-based Science Processing System is based on the latter concept, but with modifications to allow varied science algorithms and improve portability. It uses a factory assembly-line paradigm: when work orders arrive at a station, an executable is run, and output work orders are sent to downstream stations. The stations are implemented as UNIX directories, while work orders are simple ASCII files. The core S4P infrastructure consists of a Perl program called stationmaster, which detects newly arrived work orders and forks a job to run the appropriate executable (registered in a configuration file for that station). Although S4P is written in Perl, the executables associated with a station can be any program that can be run from the command line, i.e., non-interactively. An S4P instance is typically monitored using a simple Graphical User Interface. However, the reliance of S4P on UNIX files and directories also allows visibility into the state of stations and jobs using standard operating system commands, permitting remote monitor/control over low-bandwidth connections. S4P is being used as the foundation for several small- to medium-size systems for data mining, on-demand subsetting, processing of direct broadcast Moderate Resolution Imaging Spectroradiometer (MODIS) data, and Quick-Response MODIS processing. It has also been used to implement a large-scale system to process MODIS Level 1 and Level 2 Standard Products, which will ultimately process close to 2 TB/day.

Lynnes, Christopher↗
NASA NTRS2002

LWS/SET Technology Experiment Carrier

This paper examines the approach taken to building a low-cost, modular spacecraft bus that can be used to support a variety of technology experiments in different space environments. It describes the techniques used and design drivers considered to ensure experiment independence from as yet selected host spacecraft. It describes the technology experiment carriers that will support NASA's Living With a Star Space Environment Testbed space missions. NASA has initiated the Living With a Star (LWS) Program to develop a better scientific understanding to address the aspects of the connected Sun-Earth system that affect life and society. A principal goal of the program is to bridge the gap between science, engineering, and user application communities. The Space Environment Testbed (SET) Project is one element of LWS. The Project will enable future science, operational, and commercial objectives in space and atmospheric environments by improving engineering approaches to the accommodation and/or mitigation of the effects of solar variability on technological systems. The SET Project is highly budget constrained and must seek to take advantage of as yet undetermined partnering opportunities for access to space. SET will conduct technology validation experiments hosted on available flight opportunities. The SET Testbeds will be developed in a manner that minimizes the requirements for accommodation, and will be flown as flight opportunities become available. To access the widest range of flight opportunities, two key development requirements are to maintain flexibility with respect to accommodation constraints and to have the capability to respond quickly to flight opportunities. Experiments, already developed to the technology readiness level of needing flight validation in the variable Sun-Earth environment, will be selected on the basis of the need for the subject technology, readiness for flight, need for flight resources and particular orbit. Experiments will be accumulated by the Project and manifested for specific flight opportunities as they become available. The SET Carrier is designed to present a standard set of interfaces to SET technology experiments and to be modular and flexible enough to interface to a variety of possible host spacecraft. The Carrier will have core components and mission unique components. Once the core carrier elements have been developed, only the mission unique components need to be defined and developed for any particular mission. This approach will minimize the mission specific cost and development schedule for a given flight opportunity. The standard set of interfaces provided by SET to experiments allows them to be developed independent of the particulars of a host spacecraft. The Carrier will provide the power, communication, and the necessary monitoring features to operate experiments. The Carrier will also provide all of the mechanical assemblies and harnesses required to adapt experiments to a particular host. Experiments may be hosted locally with the Carrier or remotely on the host spacecraft. The Carrier design will allow a single Carrier to support a variable number of experiments and will include features that support the ability to incrementally add experiments without disturbing the core architecture.

Sherman, Barry↗
NASA NTRS2008

Evolution of the Earth Observing System (EOS) Data and Information System (EOSDIS)

One of the strategic goals of the U.S. National Aeronautics and Space Administration (NASA) is to "Develop a balanced overall program of science, exploration, and aeronautics consistent with the redirection of the human spaceflight program to focus on exploration". An important sub-goal of this goal is to "Study Earth from space to advance scientific understanding and meet societal needs." NASA meets this subgoal in partnership with other U.S. agencies and international organizations through its Earth science program. A major component of NASA s Earth science program is the Earth Observing System (EOS). The EOS program was started in 1990 with the primary purpose of modeling global climate change. This program consists of a set of space-borne instruments, science teams, and a data system. The instruments are designed to obtain highly accurate, frequent and global measurements of geophysical properties of land, oceans and atmosphere. The science teams are responsible for designing the instruments as well as scientific algorithms to derive information from the instrument measurements. The data system, called the EOS Data and Information System (EOSDIS), produces data products using those algorithms as well as archives and distributes such products. The first of the EOS instruments were launched in November 1997 on the Japanese satellite called the Tropical Rainfall Measuring Mission (TRMM) and the last, on the U.S. satellite Aura, were launched in July 2004. The instrument science teams have been active since the inception of the program in 1990 and have participation from Brazil, Canada, France, Japan, Netherlands, United Kingdom and U.S. The development of EOSDIS was initiated in 1990, and this data system has been serving the user community since 1994. The purpose of this chapter is to discuss the history and evolution of EOSDIS since its beginnings to the present and indicate how it continues to evolve into the future. this chapter is organized as follows. Sect. 7.2 provides a discussion of EOSDIS, its elements and their functions. Sect. 7.3 provides details regarding the move towards more distributed systems for supporting both the core and community needs to be served by NASA Earth science data systems. Sect. 7.4 discusses the use of standards and interfaces and their importance in EOSDIS. Sect. 7.5 provides details about the EOSDIS Evolution Study. Sect. 7.6 presents the implementation of the EOSDIS Evolution plan. Sect. 7.7 briefly outlines the progress that the implementation has made towards the 2015 Vision, followed by a summary in Sect. 7.8.

Ramapriyan, Hampapuram K.↗
NASA NTRS1990

Two Axis Pointing System (TAPS) attitude acquisition, determination, and control

The Two Axis Pointing System (TAPS) is a 2 axis gimbal system designed to provide fine pointing of Space Transportation System (STS) borne instruments. It features center-of-mass instrument mounting and will accommodate instruments of up to 1134 kg (2500 pounds) which fit within a 1.0 by 1.0 by 4.2 meter (40 by 40 by 166 inch) envelope. The TAPS system is controlled by a microcomputer based Control Electronics Assembly (CEA), a Power Distribution Unit (PDU), and a Servo Control Unit (SCU). A DRIRU-II inertial reference unit is used to provide incremental angles for attitude propagation. A Ball Brothers STRAP star tracker is used for attitude acquisition and update. The theory of the TAPS attitude determination and error computation for the Broad Band X-ray Telescope (BBXRT) are described. The attitude acquisition is based upon a 2 star geometric solution. The acquisition theory and quaternion algebra are presented. The attitude control combines classical position, integral and derivative (PID) control with techniques to compensate for coulomb friction (bias torque) and the cable harness crossing the gimbals (spring torque). Also presented is a technique for an adaptive bias torque compensation which adjusts to an ever changing frictional torque environment. The control stability margins are detailed, with the predicted pointing performance, based upon simulation studies. The TAPS user interface, which provides high level operations commands to facilitate science observations, is outlined.

Azzolini, John D.↗
NASA NTRS1994

Customizing the JPL Multimission Ground Data System: Lessons learned

The Multimission Ground Data System (MGDS) at NASA's Jet Propulsion Laboratory has brought improvements and new technologies to mission operations. It was designed as a generic data system to meet the needs of multiple missions and avoid re-inventing capabilities for each new mission and thus reduce costs. It is based on adaptable tools that can be customized to support different missions and operations scenarios. The MGDS is based on a distributed client/server architecture, with powerful Unix workstations, incorporating standards and open system architectures. The distributed architecture allows remote operations and user science data exchange, while also providing capabilities for centralized ground system monitor and control. The MGDS has proved its capabilities in supporting multiple large-class missions simultaneously, including the Voyager, Galileo, Magellan, Ulysses, and Mars Observer missions. The Operations Engineering Lab (OEL) at JPL has been leading Customer Adaptation Training (CAT) teams for adapting and customizing MGDS for the various operations and engineering teams. These CAT teams have typically consisted of only a few engineers who are familiar with operations and with the MGDS software and architecture. Our experience has provided a unique opportunity to work directly with the spacecraft and instrument operations teams and understand their requirements and how the MGDS can be adapted and customized to minimize their operations costs. As part of this work, we have developed workstation configurations, automation tools, and integrated user interfaces at minimal cost that have significantly improved productivity. We have also proved that these customized data systems are most successful if they are focused on the people and the tasks they perform and if they are based upon user confidence in the development team resulting from daily interactions. This paper will describe lessons learned in adapting JPL's MGDS to fly the Voyager, Galileo, and Mars Observer missions. We will explain how powerful, existing ground data systems can be adapted and packaged in a cost effective way for operations of small and large planetary missions. We will also describe how the MGDS was adapted to support operations within the Galileo Spacecraft Testbed. The Galileo testbed provided a unique opportunity to adapt MGDS to support command and control operations for a small autonomous operations team of a handful of engineers flying the Galileo Spacecraft flight system model.

Murphy, Susan C.↗
NASA NTRS2013

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗
NASA NTRS2013

JWST Integrated Science Instrument Module Alignment Optimization Tool

During cryogenic vacuum testing of the James Webb Space Telescope (JWST) Integrated Science Instrument Module (ISIM), the global alignment of the ISIM with respect to the designed interface of the JWST optical telescope element (OTE) will be measured through a series of optical characterization tests. These tests will determine the locations and orientations of the JWST science instrument projected focal surfaces and entrance pupils with respect to their corresponding OTE optical interfaces. If any optical performance non-compliances are identified, the ISIM will be adjusted to improve its performance. In order to understand how to manipulate the ISIM's degrees of freedom properly and to prepare for the ISIM flight model testing, a series of optical-mechanical analyses have been completed to develop and identify the best approaches for bringing a non-compliant ISIM element into compliance. In order for JWST to meet its observatory-level optical requirements and ambitious science goals, the ISIM element has to meet approximately 150 separate optical requirements. Successfully achieving many of those optical requirements depends on the proper alignment of the ISIM element with respect to the OTE. To verify that the ISIM element will meet its optical requirements, a series of cryogenic vacuum tests will be conducted with an OTE Simulator (OSIM). An optical Ray Trace and Geometry Model tool was developed to help solve the multi-dimensional alignment problem. The tool allows the user to determine how best to adjust the alignment of the JWST ISIM with respect to the ideal telescope interfaces so that the approximately 150 ISIM optical performance requirements can be satisfied. This capability has not existed previously.

Bos, Brent↗
NASA NTRS2002

A Systems Model for Power Technology Assessment

A computer model is under continuing development at NASA Glenn Research Center that enables first-order assessments of space power technology. The model, an evolution of NASA Glenn's Array Design Assessment Model (ADAM), is an Excel workbook that consists of numerous spreadsheets containing power technology performance data and sizing algorithms. Underlying the model is a number of databases that contain default values for various power generation, energy storage and power management and distribution component parameters. These databases are actively maintained by a team of systems analysts so that they contain state-of-art data as well as the most recent technology performance projections. Sizing of the power subsystems can be accomplished either by using an assumed mass specific power (W/kg) or energy (Wh/kg) or by a bottoms-up calculation that accounts for individual component performance and masses. The power generation, energy storage and power management and distribution subsystems are sized for given mission requirements for a baseline case and up to three alternatives. This allows four different power systems to be sized and compared using consistent assumptions and sizing algorithms. The component sizing models contained in the workbook are modular so that they can be easily maintained and updated. All significant input values have default values loaded from the databases that can be over-written by the user. The default data and sizing algorithms for each of the power subsystems are described in some detail. The user interface and workbook navigational features are also discussed. Finally, an example study case that illustrates the model's capability is presented.

Hoffman, David J.↗
NASA NTRSDate not supplied

Supervisory Control with Dual Tasking in Post G-Transition Vehicle Landings

BACKGROUND Landing during exploration spaceflight may consist of both planned automated supervisory control and unplanned crew override. Supervisory control, particularly when performed under cognitive load with additional monitoring tasks, is essential for ensuring overall mission success during landing contingencies. Evaluating performance in a relevant Human Landing System (HLS) supervisory landing task after long-duration microgravity exposure can help identify potential risks from human error and sensorimotor alterations. Adaptive changes in the sensorimotor system can manifest during g-transitions as spatial disorientation. Although training and landing aids facilitate successful landings despite disorientation, these adaptive changes may heighten cognitive demand, which must be considered in the landing strategy. It is important to characterize these effects as soon as possible following the G-transition while the sensorimotor system remains in a state of adaptive flux to inform appropriate countermeasures. METHODS A Multi-attribute Lunar Table Battery (MALTB) task was developed for an iOS tablet device to provide flexible crew testing and training capabilities in-flight and on the ground. Elements of the tablet task were derived from the Multi-Attribute Task Battery (MATB, Cegarra et al. 2020). The task requires crew members to study a map of a planned landing site and memorizing the terrain and surface landmarks to inform potential divert maneuvers during landing. The user will oversee a series of approaches through touchdown simulations on the tablet with an external camera view of the Lunar surface. The primary responsibility of the crew member will be to execute a divert if the guidance recommended site is erroneous (e.g., the guidance projected landing target is not within 10m of the planned landing site center), or the projected landing site is no longer suitable due to surface obstacles. Considering vehicle maneuverability and fuel reserves, the divert capabilities will diminish as the task progresses. In cases where a divert is initiated, a new landing target will need to be designated by the user and will be evaluated for the proximity to the original pre-planned site. A secondary operational monitoring task will challenge the user's cognitive reserve by requiring the user to maintain several gauges within acceptable limits and respond to a visual indicator while completing the landing approach. Outcome measures include distance from the planned landing site to the user-initiate divert landing location, ground slope at the new landing site, time to divert, the ability to accomplish the secondary monitoring tasks, and perceived workload. The tablet task is being evaluated in a ground-based study to determine the learning effect of first-time users. The tablet task will be utilized in a flight study to test performance multiple times postflight. Future potential testing in-flight have been identified for capsules with iOS tablet devices. Multi-attribute Lunar Table Battery Task MALTB comprises video footage of thirty distinct landing conditions. The landing scenarios feature various landing sites (n = 3), hazardous object sizes (n = 6), sun azimuth degrees (n = 4), camera modes (i.e., fixed or gimbaled), and navigation bias (i.e., true or false). Each seventy second trial uses a sixty-degree constant glideslope trajectory. The application architecture and layout include user identification setup and data storing, a guided walkthrough of the task and interface components, practice mode for task familiarization, and a modified Bedford workload scale administered following task completion. The time-based dependent measures are saved locally to the iOS Files application and post-processing scripts have been developed to evaluate the remaining measures of performance. RELEVANCE This project will deliver an operational demonstration of crew monitoring capability following spaceflight and identify potential deficits that may require remediation. Comparison of individual vestibular and cognitive changes with crew performance will help better characterize the landing risks associated with sensorimotor alterations. ACKNOWLEDGEMENTS: This project is funded by NASA’s Human Research Program Human Health Countermeasures Element. REFERENCES Cegarra J, Valery B, Avril E, Calmettes C, Navarro J (2020) OpenMATB: A Multi-Attribute Task Battery promoting task customization, software extensibility and experiment replicability. Behav Res Methods 52:1980-1990 doi: 10.3758/s13428-020-01364-w

Matthew McDonnell↗
NASA NTRS2012

Integrating Engineering Data Systems for NASA Spaceflight Projects

NASA has a large range of custom-built and commercial data systems to support spaceflight programs. Some of the systems are re-used by many programs and projects over time. Management and systems engineering processes require integration of data across many of these systems, a difficult problem given the widely diverse nature of system interfaces and data models. This paper describes an ongoing project to use a central data model with a web services architecture to support the integration and access of linked data across engineering functions for multiple NASA programs. The work involves the implementation of a web service-based middleware system called Data Aggregator to bring together data from a variety of systems to support space exploration. Data Aggregator includes a central data model registry for storing and managing links between the data in disparate systems. Initially developed for NASA's Constellation Program needs, Data Aggregator is currently being repurposed to support the International Space Station Program and new NASA projects with processes that involve significant aggregating and linking of data. This change in user needs led to development of a more streamlined data model registry for Data Aggregator in order to simplify adding new project application data as well as standardization of the Data Aggregator query syntax to facilitate cross-application querying by client applications. This paper documents the approach from a set of stand-alone engineering systems from which data are manually retrieved and integrated, to a web of engineering data systems from which the latest data are automatically retrieved and more quickly and accurately integrated. This paper includes the lessons learned through these efforts, including the design and development of a service-oriented architecture and the evolution of the data model registry approaches as the effort continues to evolve and adapt to support multiple NASA programs and priorities.

Carvalho, Robert E.↗
NASA NTRSDate not supplied

A Notional Artemis Lunar Surface Exploration Package (ArLSEP) based on the Gandalf Staff Platform

Introduction: The Artemis program is planning to deliver crew and cargo to the lunar surface, but there is no current package for supporting lunar in-struments and experiments similar to the Apollo Lunar Surface Exploration Package (ALSEP). This abstract provides a possible concept for such a package using the Gandalf Staff Platform as a common core. Gandalf Staff: The Gandalf Staff is an early prototype system developed over FY’21/FY’22 using NASA Science Technology Mission Directorate (STMD) Center Information Fund (CIF) grants to de-sign, build and test “proof-of-concept” components. These components include a 24v battery powered monopole that powers a suite of subsystems, including a Graphical User Interface (GUI) for crew, surface voice and data communications, Lunar Search and Rescue (LunaSAR) navigation and communications, LiDAR, field site external lighting, 360-degree camera, and a geothermal instrument for measuring sub-surface temperature gradient. The staff can be carried independently by an Extra-Vehicular Activity (EVA) astronaut, or can be mounted into a tripod for “hands free” support at a surface site being investigated. The staff can be attached to an external solar array and power storage system for long-duration operations. [1,2] ALSEP: An ASLEP flew on each mission Apollo 12 to Apollo 17. For Apollo 11, a simplified packaged called the Early Apollo Scientific Experiments Pack-age (EASEP) was flown. Each package included a “Central Station” that provided the power and communications connected to a variety of instruments and sensors. The power was provided by a Radioisotope Thermoelectric Generator (RTG) fueled by Plutoni-um-238 generating 70 watts of power (initially, decayed over time) [3]. The communications system provide for direct to Earth data transfer from the lunar surface. Each pack-age was stowed externally in the Lunar Module (LM) Scientific Equipment (SEQ) bay with a mass up to 163 kg (Apollo 17). The crew unloaded the ALSEP from the LM and deployed the instruments on the lunar surface. Although designed to operate for only 1 year, many sites operated for up to 8 years successfully [4]. The Active Seismic Experiment (ASE) included 3 geophones for detecting seismic waves created by mortars and thumpers deployed by the crew. Other active experiments measured the lunar atmosphere, the heat flow in the subsurface, the lunar gravity and potential gravity waves, the lunar magnetic field, the solar wind and plasma interactions in cislunar space. Passive experiments included collectors for dust and cosmic rays, and retroreflectors for precise measurements of distance using a laser from Earth. The ALSEP program continues to generate insights into lunar formation and evolution. ArLSEP Concepts: The lunar surface science package for the Artemis program will hopefully exceed the capability of the ALSEP. There are multiple issues for discussion leading to the design of a new ArLSEP, needing requirements definition from the science community, NASA mission architecture, and NASA budget planners. 1. Delivery Mechanism Two possible projects currently provide capability to deliver scientific cargo to the lunar surface: 1) the Commercial Lunar Payload Services (CLPS) [5] and the Human Landing System (HLS) [6, 7]. Each project is controlled by a different organization within NASA and budgeted with different criteria although both support lunar exploration. The HLS system delivers crew (and potentially cargo) to human landing sites. If an ArLSEP is “predeployed” to such a site, the design must include power (either from the vehicle or independently) to keep the electronics functioning until deployed by the crew. If an ArLSEP is delivered on a vehicle after the crew is present on the lunar surface, safety protocols require adequate distance from the humans for impact from descent propelled sur-face regolith ejecta. This distance can not exceed the capability of the crew to walk (if no rover) to the vehicle for ArLSEP deployment. 2. Overall Guidelines The general design of ArLSEP will likely follow the ALSEP with a common system for communications and power; however, significant architecture differences between Apollo and Artemis exist. Power: The RTG will not be available for early Artemis missions nor likely follow-on Lunar Exploration Transportation Services (LETS) missions [8]. Thus, ArLSEP power must be supplied by solar arrays with sufficient battery capability to “keep alive” necessary electronics during any lunar surface eclipse period. Communication: The Artemis program is developing a series of communications satellites for lunar orbit to provide surface transmission of data and voice to Earth. Called “LunaNET”, this network is component useful for ArLSEP since south polar locations may not always have direct “line-of-sight” to Earth [9]. 3. Concept of Operations (ConOps) The general ConOps for ArLSEP is to deliver the package to lunar surface before the crew arrives, and then have the crew deploy the package after some period of time. This requires coordinated design (for power systems) and launch window (for schedule) on both the cargo and crew missions. Once the ArLSEP is deployed, it will operate autonomously for a number of years. It should be designed to be EVA compatible for crew maintenance and upgrade. 4. Notional Design (for discussion purpose only) The landing site near the South Pole is expected to have no eclipse cycle exceeding 5 days, so the “keep alive” power is 144 hours (6 days to include margin). A 12v ArLSEP will use rechargeable LiFePO4 cells, which are common in the Electric Vehicle (EV) industry. With a current of 5 amps and a 125 watt system, the mass is about 90kg. The comm. system and structure adds another 10kg, thus the “Central Station” is approximately 100kg. The solar power is collected on four arrays (each 2m above the surface), and the entire ArLSEP is designed to stow in a 2m x 1m x 1m volume. The experiment and instrument design will vary for each installation and add mass to the total (although they are expected to fit within the 2m3 volume). Seismic wave generation will likely not be provided with mortars, thus an electric “thumper” will be required. Active instruments such as imaging systems and sensing instruments will benefit from the additional power and communication capability provided by ArLSEP. Passive systems such as retroreflectors, witness plates, and cosmic dust collectors can be added to either the landing vehicle and/or the ArLSEP. With repeated HLS missions to the same human site, the ArLSEP can be expanded and easily maintained for long duration science collection on the lunar surface.

ALSEP↗