SEARCH · Search NASA

Results for “Command and Data Handling”

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

SourceResearch connectionFrom yearThrough year

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

At least 307 records · Page 17

All sources NASA NTRS DOE OSTI

NASA NTRS2005

Inductive Learning Approaches for Improving Pilot Awareness of Aircraft Faults

Neural network flight controllers are able to accommodate a variety of aircraft control surface faults without detectable degradation of aircraft handling qualities. Under some faults, however, the effective flight envelope is reduced; this can lead to unexpected behavior if a pilot performs an action that exceeds the remaining control authority of the damaged aircraft. The goal of our work is to increase the pilot s situational awareness by informing him of the type of damage and resulting reduction in flight envelope. Our methodology integrates two inductive learning systems with novel visualization techniques. One learning system, the Inductive Monitoring System (IMS), learns to detect when a simulation includes faulty controls, while two others, Inductive Classification System (INCLASS) and multiple binary decision tree system (utilizing C4.5), determine the type of fault. In off-line training using only non-failure data, IMS constructs a characterization of nominal flight control performance based on control signals issued by the neural net flight controller. This characterization can be used to determine the degree of control augmentation required in the pitch, roll, and yaw command channels to counteract control surface failures. This derived information is typically sufficient to distinguish between the various control surface failures and is used to train both INCLASS and C4.5. Using data from failed control surface flight simulations, INCLASS and C4.5 independently discover and amplify features in IMS results that can be used to differentiate each distinct control surface failure situation. In real-time flight simulations, distinguishing features learned during training are used to classify control surface failures. Knowledge about the type of failure can be used by an additional automated system to alter its approach for planning tactical and strategic maneuvers. The knowledge can also be used directly to increase the pilot s situational awareness and inform manual maneuver decisions. Our multi-modal display of this information provides speech output to issue control surface failure warnings to a lesser-used communication channel and provides graphical displays with pilot-selectable !eve!s of details to issues additional information about the failure. We also describe a potential presentation for flight envelope reduction that can be viewed separately or integrated with an existing attitude indicator instrument. Preliminary results suggest that the inductive approach is capable of detecting that a control surface has failed and determining the type of fault. Furthermore, preliminary evaluations suggest that the interface discloses a concise summary of this information to the pilot.

Spikovska, Lilly↗

NASA NTRS2013

An Overview of the Microgravity Science Glovebox (MSG) Facility and the Research Performed in the MSG on the International Space Station (ISS)

The Microgravity Science Glovebox (MSG) is a rack facility aboard the International Space Station (ISS) designed for investigation handling. The MSG was built by the European Space Agency (ESA) which also provides sustaining engineering support for the facility. The MSG has been operating on the ISS since July 2002 and is currently located in the US Laboratory Module. The unique design of the facility allows it to accommodate science and technology investigations in a "workbench" type environment. The facility has an enclosed working volume that is held at a negative pressure with respect to the crew living area. This allows the facility to provide two levels of containment for small parts, particulates, fluids, and gases. This containment approach protects the crew from possible hazardous operations that take place inside the MSG work volume. Research investigations operating inside the MSG are provided a large 255 liter enclosed work space, 1000 watts of dc power via a versatile supply interface (120, 28, +/- 12, and 5 Vdc), 1000 watts of cooling capability, video and data recording and real time downlink, ground commanding capabilities, access to ISS Vacuum Exhaust and Vacuum Resource Systems, and gaseous nitrogen supply. These capabilities make the MSG one of the most utilized facilities on ISS. The MSG has been used for over 14500 hours of scientific payload operations. MSG investigations involve research in cryogenic fluid management, fluid physics, spacecraft fire safety, materials science, combustion, plant growth, and life support technology. The MSG facility is operated by the Payloads Operations Integration Center at Marshall Space flight Center. Payloads may also operate remotely from different telescience centers located in the United States and Europe. The investigative Payload Integration Manager (iPIM) is the focal to assist organizations that have payloads operating in the MSG facility. NASA provides an MSG engineering unit for payload developers to verify that their hardware is operating properly before actual operation on the ISS. This paper will provide an overview of the MSG facility, a synopsis of the research that has already been accomplished in the MSG, and an overview of video and biological upgrades.

Jordan, Lee P.↗

NASA NTRS2016

Overview of the Microgravity Science Glovebox (MSG) Facility and the Research Performed in the MSG

The Microgravity Science Glovebox (MSG) is a rack facility aboard the International Space Station (ISS) designed for investigation handling. The MSG was built by the European Space Agency (ESA) which also provides sustaining engineering support for the facility. The MSG has been operating on the ISS since July 2002 and is currently located in the US Laboratory Module. The unique design of the facility allows it to accommodate science and technology investigations in a "workbench" type environment. The facility has an enclosed working volume that is held at a negative pressure with respect to the crew living area. This allows the facility to provide two levels of containment for small parts, particulates, fluids, and gases. This containment approach protects the crew from possible hazardous operations that take place inside the MSG work volume. Research investigations operating inside the MSG are provided a large 255 liter enclosed work space, 1000 watts of direct current power via a versatile supply interface (120, 28, plus or minus 12, and 5 volts direct current), 1000 watts of cooling capability, video and data recording and real time downlink, ground commanding capabilities, access to ISS Vacuum Exhaust and Vacuum Resource Systems, and gaseous nitrogen supply. These capabilities make the MSG one of the most utilized facilities on ISS. The MSG has been used for over 27,000 hours of scientific payload operations. MSG investigations involve research in cryogenic fluid management, fluid physics, spacecraft fire safety, materials science, combustion, plant growth, biological studies and life support technology. The MSG facility is operated by the Payloads Operations Integration Center at Marshall Space Flight Center. Payloads may also operate remotely from different telescience centers located in the United States and Europe. The Investigative Payload Integration Manager (IPIM) is the focal to assist organizations that have payloads operating in the MSG facility. NASA provides an MSG engineering unit for payload developers to verify that their hardware is operating properly before actual operation on the ISS. This poster will provide an overview of the MSG facility, a synopsis of the research that has already been accomplished in the MSG, and an overview of video and biological upgrades. The author would like to acknowledge Teledyne Brown Engineering and the entire MSG Team for their inputs into this poster.

Jordan, Lee↗

NASA NTRS2004

Space Communications Emulation Facility

Establishing space communication between ground facilities and other satellites is a painstaking task that requires many precise calculations dealing with relay time, atmospheric conditions, and satellite positions, to name a few. The Space Communications Emulation Facility (SCEF) team here at NASA is developing a facility that will approximately emulate the conditions in space that impact space communication. The emulation facility is comprised of a 32 node distributed cluster of computers; each node representing a satellite or ground station. The objective of the satellites is to observe the topography of the Earth (water, vegetation, land, and ice) and relay this information back to the ground stations. Software originally designed by the University of Kansas, labeled the Emulation Manager, controls the interaction of the satellites and ground stations, as well as handling the recording of data. The Emulation Manager is installed on a Linux Operating System, employing both Java and C++ programming codes. The emulation scenarios are written in extensible Markup Language, XML. XML documents are designed to store, carry, and exchange data. With XML documents data can be exchanged between incompatible systems, which makes it ideal for this project because Linux, MAC and Windows Operating Systems are all used. Unfortunately, XML documents cannot display data like HTML documents. Therefore, the SCEF team uses XML Schema Definition (XSD) or just schema to describe the structure of an XML document. Schemas are very important because they have the capability to validate the correctness of data, define restrictions on data, define data formats, and convert data between different data types, among other things. At this time, in order for the Emulation Manager to open and run an XML emulation scenario file, the user must first establish a link between the schema file and the directory under which the XML scenario files are saved. This procedure takes place on the command line on the Linux Operating System. Once this link has been established the Emulation manager validates all the XML files in that directory against the schema file, before the actual scenario is run. Using some very sophisticated commercial software called the Satellite Tool Kit (STK) installed on the Linux box, the Emulation Manager is able to display the data and graphics generated by the execution of a XML emulation scenario file. The Emulation Manager software is written in JAVA programming code. Since the SCEF project is in the developmental stage, the source code for this type of software is being modified to better fit the requirements of the SCEF project. Some parameters for the emulation are hard coded, set at fixed values. Members of the SCEF team are altering the code to allow the user to choose the values of these hard coded parameters by inserting a toolbar onto the preexisting GUI.

Hill, Chante A.↗

NASA NTRS2013

Mission Data System Java Edition Version 7

The Mission Data System framework defines closed-loop control system abstractions from State Analysis including interfaces for state variables, goals, estimators, and controllers that can be adapted to implement a goal-oriented control system. The framework further provides an execution environment that includes a goal scheduler, execution engine, and fault monitor that support the expression of goal network activity plans. Using these frameworks, adapters can build a goal-oriented control system where activity coordination is verified before execution begins (plan time), and continually during execution. Plan failures including violations of safety constraints expressed in the plan can be handled through automatic re-planning. This version optimizes a number of key interfaces and features to minimize dependencies, performance overhead, and improve reliability. Fault diagnosis and real-time projection capabilities are incorporated. This version enhances earlier versions primarily through optimizations and quality improvements that raise the technology readiness level. Goals explicitly constrain system states over explicit time intervals to eliminate ambiguity about intent, as compared to command-oriented control that only implies persistent intent until another command is sent. A goal network scheduling and verification process ensures that all goals in the plan are achievable before starting execution. Goal failures at runtime can be detected (including predicted failures) and handled by adapted response logic. Responses can include plan repairs (try an alternate tactic to achieve the same goal), goal shedding, ignoring the fault, cancelling the plan, or safing the system.

Reinholtz, William K.↗

NASA NTRS2008

Supporting Increased Autonomy for a Mars Rover

This paper presents an architecture and a set of technology for performing autonomous science and commanding for a planetary rover. The MER rovers have outperformed all expectations by lasting over 1100 sols (or Martian days), which is an order of magnitude longer than their original mission goal. The longevity of these vehicles will have significant effects on future mission goals, such as objectives for the Mars Science Laboratory rover mission (scheduled to fly in 2009) and the Astrobiology Field Lab rover mission (scheduled to potentially fly in 2016). Common objectives for future rover missions to Mars include the handling of opportunistic science, long-range or multi-sol driving, and onboard fault diagnosis and recovery. To handle these goals, a number of new technologies have been developed and integrated as part of the CLARAty architecture. CLARAty is a unified and reusable robotic architecture that was designed to simplify the integration, testing and maturation of robotic technologies for future missions. This paper focuses on technology comprising the CLARAty Decision Layer, which was designed to support and validate high-level autonomy technologies, such as automated planning and scheduling and onboard data analysis.

autonomous science↗

NASA NTRS2010

Operational Lessons Learned from the Ares I-X Flight Test

The Ares I-X flight test, launched in 2009, is the first test of the Ares I crew launch vehicle. This development flight test evaluated the flight dynamics, roll control, and separation events, but also provided early insights into logistical, stacking, launch, and recovery operations for Ares I. Operational lessons will be especially important for NASA as the agency makes the transition from the Space Shuttle to the Constellation Program, which is designed to be less labor-intensive. The mission team itself comprised only 700 individuals over the life of the project compared to the thousands involved in Shuttle and Apollo missions; while missions to and beyond low-Earth orbit obviously will require additional personnel, this lean approach will serve as a model for future Constellation missions. To prepare for Ares I-X, vehicle stacking and launch infrastructure had to be modified at Kennedy Space Center's Vehicle Assembly Building (VAB) as well as Launch Complex (LC) 39B. In the VAB, several platforms and other structures designed for the Shuttle s configuration had to be removed to accommodate the in-line, much taller Ares I-X. Vehicle preparation activities resulted in delays, but also in lessons learned for ground operations personnel, including hardware deliveries, cable routing, transferred work and custodial paperwork. Ares I-X also proved to be a resource challenge, as individuals and ground service equipment (GSE) supporting the mission also were required for Shuttle or Atlas V operations at LC 40/41 at Cape Canaveral Air Force Station. At LC 39B, several Shuttle-specific access arms were removed and others were added to accommodate the in-line Ares vehicle. Ground command, control, and communication (GC3) hardware was incorporated into the Mobile Launcher Platform (MLP). The lightning protection system at LC 39B was replaced by a trio of 600-foot-tall towers connected by a catenary wire to account for the much greater height of the vehicle. Like Shuttle, Ares I-X will be stacked on a MLP and rolled out to the pad on a Saturn-era crawler-transporter. While Ares I-X was only held in place by the four hold-down posts on its aft skirt during rollout, a new vehicle stabilization system (VSS) attached to the vertical service structure kept the vehicle from undue swaying prior to launch at the pad, LC 39B. Following the launch, the flight test vehicle first stage was recovered with the aid of new parachutes resized to accommodate the five-segment-long first stage, which had a much greater length and mass than the Shuttle s reusable solid rocket boosters. After splashdown, recovery divers exercised extra care when handling the first stage to ensure that the flight data recorders in the fifth segment simulator were not damaged by exposure to sea water. The data recovered from the Ares I-X flight test will be very valuable in verifying the predicted environments and models used to design the vehicle. Lessons learned from Ares I-X will be shared with the Ares Projects through written and verbal reports and through integration of mission team members into the Project workforce.

Davis, Stephan R.↗

NASA NTRS1993

EOS ground data systems: A description and interface overview

The Earth Observing System (EOS) is planned as a space-based measurement system, earth-science research program, and data and information system (EOSDIS). It will consist of several high data rate spacecraft with multiple earth sensing instruments which provide investigators with a thorough, longterm view of the earth's environment. Up to seven spacecraft may be supported at once, either in operational, checkout, or testing phases; and the average data rate from the EOS satellites in orbit at any one time is expected to be from 18 to 60 Mbps. Providing the data processing and flight operations support for EOS will be the EOSDIS Core System (ECS). The ECS will command and control the spacecraft; process and store the EOS data; provide access to the data for years; and support researchers. The data processing aspects of the ECS consist of a collection of Distributed Active Archive Centers (DAAC's) which perform the product generation, data archive and distribution, and information management services. Flight operations aspects will be provided by the EOS Operations Center, by instrument control centers, and by widely distributed instrument support terminals. The communications and system management aspects will be provided by the EOSDIS Science Network and the System Management Center. In addition to the EOS satellite data, other data sets from earlier earth science missions are also to be added to designated DAAC's. Other ground data systems which will provide support to EOS for acquiring, transporting, processing, and distributing the transformed spacecraft data are currently being defined or are being upgraded for the EOS era. These systems include the Space Network consisting of the Tracking and Data Relay Satellite System (TDRSS), the TDRSS Ground Terminals, and the Network Control Center as well as the night Dynamics Facility, the EOS Data and Operations System, and EOS Communications. This paper briefly describes data handling by the ECS, the support data systems, their interfaces, and their roles.

Smith, Gene↗

NASA NTRS2019

Development Considerations for Implementing a Voice-Controlled Spacecraft System

As computational power and speech recognition algorithms improve, the consumer market will see better-performing speech recognition applications. The cell phone and Internet-related service industry have further enhanced speech recognition applications using artificial intelligence and statistical data-mining techniques. These improvements to speech recognition technology (SRT) may one day help astronauts on future deep space human missions that require control of complex spacecraft systems or spacesuit applications by voice. Though SRT and more advanced speech recognition techniques show promise, use of this technology for a space application such as vehicle/habitat/spacesuit requires careful considerations. This paper provides considerations and guidance for the use of SRT in voice-controlled spacecraft systems (VCSS) applications for space missions, specifically in command-and-control (C2) applications where the commanding is user-initiated. First, current SRT limitations as known at the time of this report are given. Then, highlights of SRT used in the space program provide the reader with a history of some of the human spaceflight applications and research. Next, an overview of the speech production process and the intrinsic variations of speech are provided. Finally, general guidance and considerations are given for the development of a VCSS using a human-centered design approach for space applications that includes vocabulary selection and performance testing, as well as VCSS considerations for C2 dialogue management design, feedback, error handling, and evaluation/usability testing.

Salazar, George↗

NASA NTRS1998

Autonomous Satellite Command and Control Through the World Wide Web

The Automated Space System Experimental Testbed (ASSET) system is a simple yet comprehensive real-world operations network being developed. Phase 3 of the ASSET Project was January-December 1997 and is the subject of this report. This phase permitted SSDL and its project partners to expand the ASSET system in a variety of ways. These added capabilities included the advancement of ground station capabilities, the adaptation of spacecraft on-board software, and the expansion of capabilities of the ASSET management algorithms. Specific goals of Phase 3 were: (1) Extend Web-based goal-level commanding for both the payload PI and the spacecraft engineer. (2) Support prioritized handling of multiple (PIs) Principle Investigators as well as associated payload experimenters. (3) Expand the number and types of experiments supported by the ASSET system and its associated spacecraft. (4) Implement more advanced resource management, modeling and fault management capabilities that integrate the space and ground segments of the space system hardware. (5) Implement a beacon monitoring test. (6) Implement an experimental blackboard controller for space system management. (7) Further define typical ground station developments required for Internet-based remote control and for full system automation of the PI-to-spacecraft link. Each of those goals are examined. Significant sections of this report were also published as a conference paper. Several publications produced in support of this grant are included as attachments. Titles include: 1) Experimental Initiatives in Space System Operations; 2) The ASSET Client Interface: Balancing High Level Specification with Low Level Control; 3) Specifying Spacecraft Operations At The Product/Service Level; 4) The Design of a Highly Configurable, Reusable Operating System for Testbed Satellites; 5) Automated Health Operations For The Sapphire Spacecraft; 6) Engineering Data Summaries for Space Missions; and 7) Experiments In Automated Health Assessment And Notification For The Sapphire Microsatellite.

Cantwell, Brian↗

NASA NTRS2017

Airborne Trajectory Management (ABTM): A Blueprint for Greater Autonomy in Air Traffic Management

The aviation users of the National Airspace System (NAS) - the airlines, General Aviation (GA), the military and, most recently, operators of Unmanned Aircraft Systems (UAS) - are constrained in their operations by the design of the current paradigm for air traffic control (ATC). Some of these constraints include ATC preferred routes, departure fix restrictions and airspace ground delay programs. As a result, most flights cannot operate on their most efficient business trajectories and a great many flights are delayed even getting into the air, which imposes a significant challenge to maintaining efficient flight and network operations. Rather than accepting ever more sophisticated scheduling solutions to accommodate the existing constraints in the airspace, a series of increasingly capable airborne technologies, integrated with planned improvements in the ground system through the Federal Aviation Administration (FAA) Next Generation Air Traffic Management System (NextGen) programs, could produce much greater operational flexibility for flight path optimization by the aviation system users. These capabilities, described in research coming out of NASA's Aeronautics Research Mission Directorate, can maintain or improve operational safety while taking advantage of air and ground NextGen technologies in novel ways. The underlying premise is that the nation's physical airspace is still abundant and underused, and that the delays and inefficient flight operations resulting from artificial structure in airspace use and procedural constraints on those operations may not be necessary for safe and efficient flight. This article is not an indictment of today's NAS or the people who run it. Indeed, it is an exceptional achievement that Air Traffic Management (ATM) - the complex human/machine conglomeration of communications, navigation and surveillance equipment and the rules and procedures for controlling traffic in the airspace - has both the capacity and enables the degree of efficiency in air travel that it does. But it is also true that sixty years of the "radar religion" (i.e., reliance on radar-based command and control) has produced several generations of ATM system operators and researchers who believe that introducing automation within the existing functional structure of ATM is the only way to "modernize" the system. Even NextGen, which began as a proposal for "transformational" change in the way ATC is performed, has morphed over the last decade and a half to become just the inclusion of Global Positioning System (GPS) for navigation, Automatic Dependent Surveillance Broadcast (ADS-B) for surveillance, and Data Communications (Data Comm) for communications, while still operating in rigidly structured airspace with human controllers being responsible for separation and traffic flow management (TFM) within defined sectors of airspace, using the same horizontal separation standards that have been in use since raw primary radar was introduced in the 1950s. No system as massive as the current NAS ATM can be replaced with a better system while simultaneously meeting the transportation and other aviation needs of the nation. A new generation of more flexible operations must emerge and yet coexist in harmony with the current operation (i.e., share the same airspace without segregation), thereby enabling a long-term transformation to take place in the way increasing numbers of flights are handled. Market forces will be the ultimate driver of this transformation, and investment realities mandate that real benefits must accrue to the first operators to adopt these new capabilities. In fact, the kinds of missions envisioned in the emerging world of UAS operations, unachievable under conventional ATM, demand that this transformation take place. Airborne Trajectory Management (ABTM) is proposed as a series of transformational steps leading to vastly increased flexibility in flight operations and capacity in the airspace to accommodate many varied airspace uses while improving safety. As will be described, ABTM enables the gradual emergence of a new paradigm for user-based trajectory management in ATM that brings tangible benefits to equipped operators at every step while leveraging the air and ground investments of NextGen. There are five steps in this ABTM transformation.1 NASA has extensively studied the first and last of these steps, and a roadmap of increasing capabilities and benefits is proposed for bridging between these operational concepts.

Cotton, William B.↗

NASA NTRS2004

A modular suite of hardware enabling spaceflight cell culture research

BioServe Space Technologies, a NASA Research Partnership Center (RPC), has developed and operated various middeck payloads launched on 23 shuttle missions since 1991 in support of commercial space biotechnology projects. Modular cell culture systems are contained within the Commercial Generic Bioprocessing Apparatus (CGBA) suite of flight-qualified hardware, compatible with Space Shuttle, SPACEHAB, Spacelab and International Space Station (ISS) EXPRESS Rack interfaces. As part of the CGBA family, the Isothermal Containment Module (ICM) incubator provides thermal control, data acquisition and experiment manipulation capabilities, including accelerometer launch detection for automated activation and thermal profiling for culture incubation and sample preservation. The ICM can accommodate up to 8 individually controlled temperature zones. Command and telemetry capabilities allow real-time downlink of data and video permitting remote payload operation and ground control synchronization. Individual cell culture experiments can be accommodated in a variety of devices ranging from 'microgravity test tubes' or standard 100 mm Petri dishes, to complex, fed-batch bioreactors with automated culture feeding, waste removal and multiple sample draws. Up to 3 levels of containment can be achieved for chemical fixative addition, and passive gas exchange can be provided through hydrophobic membranes. Many additional options exist for designing customized hardware depending on specific science requirements.

manned↗

NASA NTRSDate not supplied

Splashdown Visualization of Spent Stages

The state of the art for many Earth-to-orbit trajectory analysis toolsets used at NASA is somewhat dated in terms of the languages they are written in and their user interfaces. Many of these programs are written in languages like Fortran or C that are no longer considered modern in the technology industry, and are command-line based without any means of interpreting the data outputs. This presentation is meant to demonstrate a specific use case for a newly developed web app that visualizes the output data for one of these tools. Specifically, one key usage is to investigate and validate launches for notional multi-stage vehicle concepts to various non-standard high-inclination orbits. Some NASA requirements dictate that trajectories be designed such that no surviving debris lands closer than 200 nautical miles (nm) from foreign landmasses or 27 nm from the continental United States, therefore validating re-entry locations of spent stages is an integral part of the launch planning process. In addition, at programmatic levels it can prove insightful and clarifying for the decision-making process to enhance the technical results of numerical simulations with visualizations. The intent with this tool is to provide the mission analyst and program level management with an intuitive and clear grasp of key information on possible mission scenarios either departing from or arriving at Earth, and in the future, the moon or Mars as well. The software tool was developed with an agile development approach and utilizes the latest frameworks and technologies. The front end uses the React JavaScript library for making a state of the art frontend and a backend based on the Django Python framework for handling data using Python’s powerful and free scientific libraries. In addition, the CesiumJS open-source library is key for visualizing these end-to-end trajectories on a high-resolution Earth model. The presentation will demonstrate the current capability and tested use cases.

Jack Agolli↗

NASA NTRS2023

Easy, Scalable Subsetting of GEDI Point Clouds

The GEDI Subsetter, a Python tool developed for NASA’s Multi-mission Algorithm and Analysis Platform (MAAP), optimizes the accessibility and visualization of GEDI point clouds by enabling users to efficiently subset data in a convenient, scalable manner. Complex science data often requires users to learn new software skills and handle many large files. Handling and cleaning large data sets is tedious and error-prone. These challenges significantly impede analysis. One of the goals of NASA's MAAP is to provide a platform that lowers the barrier to conducting research and analysis at scale. When a group of MAAP users wanted to conduct above-ground biomass estimation using GEDI data, we found that their existing workflow for leveraging GEDI data suffered from the barriers mentioned above. Furthermore, their workflow did not scale easily beyond a small number of granules. We found that existing tools related to GEDI data retrieval and subsetting were too limiting, so the GEDI Subsetter was written to support MAAP users’ needs. Being able to run many subsetting jobs simultaneously in the MAAP, and parallelizing the code itself, has led to significant speed improvements in obtaining relevant data, reducing subsetting time from hours to minutes. MAAP users can now more quickly and easily obtain only the data relevant to their research, by choosing which GEDI collection they want to work with (L1A, L2A, L2B, or L4A), and how they want to subset it, by specifying an area of interest, a temporal range, and relevant attributes. This has significantly reduced the feedback loop for users, allowing them to much more quickly subset GEDI data and begin their analysis. Although the GEDI Subsetter originally targeted users of the MAAP, it is generalized such that it can also be used outside of the MAAP and includes a command-line interface for convenience. Furthermore, with minor modifications, it should be possible to use it with non-GEDI data as the general pattern should be applicable to other sparse/track-based sensors.

Charles Daniels↗

NASA NTRS1992

ROSAT data analysis with EXSAS

For the x-ray observatory ROSAT, data from survey and pointed mission phases taken with different focal plane instruments and according to a complex mission timeline have to be handled. Data analysis therefore puts high demands on appropriate software tools. With EXSAS - the Extended Scientific Analysis System developed with an effort of 20 man years by the German ROSAT Scientific Data Center - a comfortable system for the reduction of data from the ROSAT x-ray and XUV instruments has been made available. EXSAS comprises a large collection of application modules as typically required in analyzing data of this wavelength regime and runs as a specific context in the wide-spread ESO-MIDAS environment. EXSAS, completely written in FORTRAN 77, takes full advantage of all the standards used in MIDAS and therefore, reflects the same portability (different UNIX installations and VMS). If required, the FORTRAN code also enables users to adapt the software in an easy way to their specific needs. To maintain independence from the specifics of different operating systems also on the data input side, all ROSAT data redistributed in the widely accepted FITS format. Although EXSAS has been developed specifically for data analysis of the ROSAT instruments, its structural design is sufficiently general to serve equally well also data from other X-ray and XUV instruments. EXSAS analysis modules are grouped into 4 application packages dealing with Data Preparation and Instrument Correction, Spatial Analysis, Spectral Analysis and Timing Analysis. A special EXSAS header, read and updated by each application, maintains the general information transfer on the origin, the history and the parameter space of the data stored in tables and images. About 100 genuine commands (most of which offer several additional options) allow to interactively explore the functionality of the system. Up to now 40 institutes all over the world have requested the EXSAS software. Maintenance and regular updates of the software and the comprehensive documentation are provided by the ROSAT Scientific Data Center at Garching.

Zimmermann, H. U.↗

NASA NTRSDate not supplied

Objective Structured Clinical Evaluation (OSCE) of an Artificial Intelligence (AI) Clinical Decision Support System (CDSS) Tool

BACKGROUND Objective Structured Clinical Evaluations (OSCEs) have long been established as a robust methodology for summative assessment of clinical skills and decision-making during medical education. The recent integration of Artificial Intelligence (AI) into clinical decision-making processes has prompted the need for novel evaluation frameworks to assess the efficacy and reliability of AI clinical decision support system (CDSS) tools. This abstract outlines the process of quantitatively evaluating a novel CDSS (“Doc in a Box” Google 2024) trained on curated medical spaceflight data in the psychomotor domain as it interfaces with a human volunteer acting as the crew medical officer (CMO). PURPOSE The AI CDSS under review was developed as part of the Lunar Command and Control Interoperability (LuCCI) project, which is intended to address a gap in how Lunar Surface Systems (LSS) would interoperate across multiple programs, commercial partners, and international partners. The project objective is to define, prototype, integrate, and evaluate an interoperable lunar command, control, data, and software reference architecture to enable autonomy and informatics capability through common standards across LSS. A multi-modal AI-based CDSS compatible with Federated LSS will assist clinicians in diagnosing and managing complex medical conditions by providing evidence-based recommendations through predictive analytics. Given the critical role of decision-support as NASA continues to evolve its Earth-independent medical operations (EIMO), it is imperative to ensure that such AI tools perform reliably and align with clinical standards during progressive lunar and Martian exploration class missions. METHODS The OSCE framework, traditionally used for evaluating human clinicians, was adapted to assess the AI tool's decision-making capabilities in simulated clinical scenarios. In this adapted OSCE, the AI CDSS was tested across a series of structured clinical scenarios designed to mimic real-life spaceflight patient cases. These scenarios included a range of conditions and complexities, allowing for comprehensive assessment of the tool's performance. Key evaluation metrics included accuracy of diagnosis, timeliness of decision-making, and appropriate recommendations for therapies. The OSCE was scored by human physician evaluators who assessed the AI's recommendations in comparison with expert clinicians' medical decision making to ensure alignment with best practices and the standard of care. RESULTS Preliminary results indicate that the AI CDSS demonstrated high accuracy in diagnostic recommendations and decision support across various scenarios. However, certain limitations were noted, such as occasional discrepancies in handling complex or nuanced cases that required a more contextual understanding. Additionally, the tool scored higher on the diagnostic portion of the rubric, with lower scores in the therapeutic recommendations. These findings highlight the importance of continuous refinement and validation of AI tools through rigorous evaluation frameworks like the OSCE. The adaptation of OSCEs for AI tools presents several advantages, including a structured and reproducible approach to evaluation, the ability to test AI systems in diverse clinical scenarios, and the opportunity to benchmark AI performance against established clinical standards to permit charting of future progress as aerospace medicine evolves as a discipline. Remaining challenges include ensuring that these evaluations capture the full spectrum of clinical decision-making scenarios that will be confronted by CMOs during missions and adequately reflecting real-world variability of the austere spaceflight environment. CONCLUSION Employing OSCEs to evaluate AI clinical decision support tools offers a promising approach to validating their clinical utility and efficacy. This methodology not only provides insights into the tool's performance but also fosters ongoing improvement and alignment with standard of care practices. Future research should focus on refining these evaluation processes and addressing limitations to enhance the integration of AI tools in clinical spaceflight settings. REFERENCES Scott S, Hearns V, Barker MA. Testing Clinical Skills: A Look at the OSCE and USMLE Clinical Skills Exams. S D Med. 2019 Oct;72(10):451-453. Majumder MAA, Kumar A, Krishnamurthy K, Ojeh N, Adams OP, Sa B. An evaluative study of objective structured clinical examination (OSCE): students and examiners perspectives. Adv Med Educ Pract. 2019 Jun 5;10:387-397. Karam VY, Park YS, Tekian A, Youssef N. Evaluating the validity evidence of an OSCE: results from a new medical school. BMC Med Educ. 2018 Dec 20;18(1):313.

Ariana M Nelson↗

NASA NTRS2018

Considerations for Implementing Voice-Controlled Spacecraft Systems Through a Human-Centered Design Approach

As computational power and speech recognition algorithms improve, the consumer market will see better-performing speech recognition applications. The cell phone and Internet-related service industry have further enhanced speech recognition applications using artificial intelligence and statistical data-mining techniques. These improvements to speech recognition technology (SRT) may one day help astronauts on future deep space human missions that require control of complex spacecraft systems or spacesuit applications by voice. Though SRT and more advanced speech recognition techniques show promise, use of this technology for a space application such as vehicle/habitat/spacesuit requires careful considerations. There are still recognition challenges to overcome such as background noise, human speech variability, and task loading. However, implemented correctly, a voice-controlled spacecraft system (VCSS) can provide a useful, natural and efficient form of human-machine communications during complex tasks such as when the hands and eyes are busy or as an aid for vehicle situational awareness inquiries or collaborative human-robot tasks. This document provides considerations and guidance for the use of SRT in VCSS applications for space missions, specifically in command-and-control (C2) applications where the commanding is user-initiated. First, current SRT limitations as known at the time of this report are given. Then, highlights of SRT used in the space program provide the reader with a history of some of the human spaceflight applications and research. Next, an overview of the speech production process and the intrinsic variations of speech are provided. Finally, general guidance and considerations are given for development of a VCSS using a human-centered design approach for space applications that includes vocabulary selection and performance testing, as well as VCSS considerations for C2 dialogue management design, feedback, error handling, and evaluation/usability testing. Available from

Salazar, George A.↗

NASA NTRS1988

A graphical, rule based robotic interface system

The ability of a human to take control of a robotic system is essential in any use of robots in space in order to handle unforeseen changes in the robot's work environment or scheduled tasks. But in cases in which the work environment is known, a human controlling a robot's every move by remote control is both time consuming and frustrating. A system is needed in which the user can give the robotic system commands to perform tasks but need not tell the system how. To be useful, this system should be able to plan and perform the tasks faster than a telerobotic system. The interface between the user and the robot system must be natural and meaningful to the user. A high level user interface program under development at the University of Alabama, Huntsville, is described. A graphical interface is proposed in which the user selects objects to be manipulated by selecting representations of the object on projections of a 3-D model of the work environment. The user may move in the work environment by changing the viewpoint of the projections. The interface uses a rule based program to transform user selection of items on a graphics display of the robot's work environment into commands for the robot. The program first determines if the desired task is possible given the abilities of the robot and any constraints on the object. If the task is possible, the program determines what movements the robot needs to make to perform the task. The movements are transformed into commands for the robot. The information defining the robot, the work environment, and how objects may be moved is stored in a set of data bases accessible to the program and displayable to the user.

Mckee, James W.↗