Search NASA⌕ Search

SEARCH · Search NASA

Results for “command process”

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 793 records · Page 44
All sourcesNASA NTRSDOE OSTI
NASA NTRS1993

The SAMPEX Data Processing Unit

The paper discusses salient features of the SAMPEX Data Processing Unit (DPU), the primary function of which is to collect sensor data to create telemetry packets for transmission to the solid-state recorder located within the Small Explorer Data System. Particular attention is given to the sensor interface electronics, the space command interface, the spacecraft telemetry interface, and the memory mapper of the DPU system; the task scheduling concept; and system reconfiguring. A block diagram of the DPU system is included.

Mabry, D. J.↗
NASA NTRS2005

Control Method for Video Guidance Sensor System

A method is provided for controlling operations in a video guidance sensor system wherein images of laser output signals transmitted by the system and returned from a target are captured and processed by the system to produce data used in tracking of the target. Six modes of operation are provided as follows: (i) a reset mode; (ii) a diagnostic mode; (iii) a standby mode; (iv) an acquisition mode; (v) a tracking mode; and (vi) a spot mode wherein captured images of returned laser signals are processed to produce data for all spots found in the image. The method provides for automatic transition to the standby mode from the reset mode after integrity checks are performed and from the diagnostic mode to the reset mode after diagnostic operations are commands is permitted only when the system is in the carried out. Further, acceptance of reset and diagnostic standby mode. The method also provides for automatic transition from the acquisition mode to the tracking mode when an acceptable target is found.

Richard T Howard↗
NASA NTRS1983

The Galileo spacecraft system design

The Galileo Orbiter differs markedly from its Mariner, Viking and Voyager predecessors in many aspects of its design, as dictated by its unique mission characteristics. Novel design features include a dual spin configuration, long life bipropellant propulsion, radioisotope thermoelectric generators, and a star scanner. Other major changes are related to Space Shuttle Orbiter compatibility. The selection of a distributed data system employing a high speed data bus represents a major advance over Voyager systems. The command, control and data handling functions for the Orbiter are merged into a single software-controlled subsystem. The paramount importance of software development in the design of Galileo subsystems is noted, in view of the requirement for total engineering and science data acquisition process reprogrammability.

Jones, C. P.↗
NASA NTRS1987

The Mission Operations Planning Assistant

The Mission Operations Planning Assistant (MOPA) is a knowledge-based system developed to support the planning and scheduling of instrument activities on the Upper Atmospheric Research Satellite (UARS). The MOPA system represents and maintains instrument plans at two levels of abstraction in order to keep plans comprehensible to both UARS Principal Investigators and Command Management personnel. The hierarchical representation of plans also allows MOPA to automatically create detailed instrument activity plans from which spacecraft command loads may be generated. The MOPA system was developed on a Symbolics 3640 computer using the ZetaLisp and ART languages. MOPA's features include a textual and graphical interface for plan inspection and modification, recognition of instrument operational constraint violations during the planning process, and consistency maintenance between the different planning levels. This paper describes the current MOPA system.

Schuetzle, James G.↗
NASA NTRS1987

The mission operations planning assistant

The Mission Operations Planning Assistant (MOPA) is a knowledge-based system developed to support the planning and scheduling of instrument activities on the Upper Atmospheric Research Satellite (UARS). The MOPA system represents and maintains instrument plans at two levels of abstraction in order to keep plans comprehensible to both UARS Prinicpal Investigators and Command Management personnel. The hierarchical representation of plans also allows MOPA to automatically create detailed instrument activity plans from which spacecraft command loads may be generated. The MOPA system was developed on a Symbolics 3640 computer using the ZETALISP and ART languages. MOPA's features include a textual and graphical interface for plan inspection and modification, recognition of instrument operational constraint violations during the planning process, and consistency maintenance between the different planning levels. This paper describes the current MOPA system.

Schuetzle, James G.↗
NASA NTRS1994

Low encounter speed comet COMA sample return missions

Comets, being considered the most primitive bodies in the solar system, command the highest priority among solar-system objects for studying solar nebula evolution and the evolution of life through biogenic elements and compounds. The study of comets, and more especially, of material from them, provides an understanding of the physical, chemical, and mineralogical processes operative in the formation and earliest development of the solar systems. These return samples will provide valuable information on comets and serve as a rosetta stone for the analytical studies conducted on interplanetary dust particles over the past two decades, and will provide much needed extraterrestrial samples for the planetary materials community since the Apollo program. Lander sample return missions require rather complex spacecraft, intricate operations, and costly propulsion systems. By contrast, it is possible to take a highly simplified approach for sample capture and return in the case of a comet. In the past, we have considered Earth free-return trajectory to the comet, in which passive collectors intercept dust and volatiles from the cometary coma. However, standard short period cometary free-return trajectories results in the comet to the spacecraft encounter speeds in the range of 10 km/s. At these speeds the kinetic energy of the capture process can render significant modification of dust structure, change of solid phase as well as the lost of volatiles components. This paper presents a class of new missions with trajectories with significant reduction of encounter speeds by incorporating gravity assists and deep space maneuvering. Low encounter speed cometary flyby sample return will enable a marked increase in the value of the return science. Acquiring thousands of samples from a known comet and thousands of images of a comet nucleus would be space firsts. Applying new approach in flight mechanics to generate a new class of low encounter speed cometary sample return trajectories opens new possibilities in science. A systematic search of trajectories for the first decade of the twenty-first century will be made. The target encounter speed is for less than 7 km/s to short period comets.

Tsou, P.↗
NASA NTRS2006

Implementing Distributed Operations: A Comparison of Two Deep Space Missions

Two very different deep space exploration missions--Mars Exploration Rover and Cassini--have made use of distributed operations for their science teams. In the case of MER, the distributed operations capability was implemented only after the prime mission was completed, as the rovers continued to operate well in excess of their expected mission lifetimes; Cassini, designed for a mission of more than ten years, had planned for distributed operations from its inception. The rapid command turnaround timeline of MER, as well as many of the operations features implemented to support it, have proven to be conducive to distributed operations. These features include: a single science team leader during the tactical operations timeline, highly integrated science and engineering teams, processes and file structures designed to permit multiple team members to work in parallel to deliver sequencing products, web-based spacecraft status and planning reports for team-wide access, and near-elimination of paper products from the operations process. Additionally, MER has benefited from the initial co-location of its entire operations team, and from having a single Principal Investigator, while Cassini operations have had to reconcile multiple science teams distributed from before launch. Cassini has faced greater challenges in implementing effective distributed operations. Because extensive early planning is required to capture science opportunities on its tour and because sequence development takes significantly longer than sequence execution, multiple teams are contributing to multiple sequences concurrently. The complexity of integrating inputs from multiple teams is exacerbated by spacecraft operability issues and resource contention among the teams, each of which has their own Principal Investigator. Finally, much of the technology that MER has exploited to facilitate distributed operations was not available when the Cassini ground system was designed, although later adoption of web-based and telecommunication tools has been critical to the success of Cassini operations.

Cassini Mission↗
NASA NTRS2009

On DESTINY Science Instrument Electrical and Electronics Subsystem Framework

Future space missions are going to require large focal planes with many sensing arrays and hundreds of millions of pixels all read out at high data rates'' . This will place unique demands on the electrical and electronics (EE) subsystem design and it will be critically important to have high technology readiness level (TRL) EE concepts ready to support such missions. One such omission is the Joint Dark Energy Mission (JDEM) charged with making precise measurements of the expansion rate of the universe to reveal vital clues about the nature of dark energy - a hypothetical form of energy that permeates all of space and tends to increase the rate of the expansion. One of three JDEM concept studies - the Dark Energy Space Telescope (DESTINY) was conducted in 2008 at the NASA's Goddard Space Flight Center (GSFC) in Greenbelt, Maryland. This paper presents the EE subsystem framework, which evolved from the DESTINY science instrument study. It describes the main challenges and implementation concepts related to the design of an EE subsystem featuring multiple focal planes populated with dozens of large arrays and millions of pixels. The focal planes are passively cooled to cryogenic temperatures (below 140 K). The sensor mosaic is controlled by a large number of Readout Integrated Circuits and Application Specific Integrated Circuits - the ROICs/ASICs in near proximity to their sensor focal planes. The ASICs, in turn, are serviced by a set of "warm" EE subsystem boxes performing Field Programmable Gate Array (FPGA) based digital signal processing (DSP) computations of complex algorithms, such as sampling-up-the-ramp algorithm (SUTR), over large volumes of fast data streams. The SUTR boxes are supported by the Instrument Control/Command and Data Handling box (ICDH Primary and Backup boxes) for lossless data compression, command and low volume telemetry handling, power conversion and for communications with the spacecraft. The paper outlines how the JDEM DESTINY concept instrument EE subsystem can be built now, a design; which is generally U.S. Government work not protected by U.S. copyright IEEEAC paper # 1429. Version 4. Updated October 19, 2009 applicable to a wide variety of missions using large focal planes with lar ge mosaics of sensors.

Kizhner, Semion↗
NASA NTRS2006

Implementing distributed operations : a comparison of two Deep Space Missions

Two very different deep space exploration missions—Mars Exploration Rover and Cassini—have made use of distributed operations for their science teams. In the case of MER, the distributed operations capability was implemented only after the prime mission was completed, as the rovers continued to operate well in excess of their expected mission lifetimes; Cassini, designed for a prime mission of four years, had planned for distributed operations from its inception. The rapid command turnaround timeline of MER, as well as many of the operations features implemented to support it, have proven to be conducive to distributed operations. These features include: a single science team leader during the tactical operations timeline, highly integrated science and engineering teams, processes and file structures designed to permit multiple team members to work in parallel to deliver sequencing products, web-based spacecraft status and planning reports for team-wide access, and near-elimination of paper products from the operations process.

Larsen, Barbara↗
NASA NTRS2016

Command and Data Handling Branch Internship

Modular Integrated Stackable Layers (MISL) is a computer system designed for simple, fast, and cost effective flexible reconfiguration in space environments such as the ISS and Orion projects for various uses. Existing applications include wireless and wired communications, data acquisition and instrumentation, and camera systems, and potential applications include bus protocol converters and subsystem control. MISL is based on Texas Instruments (TI)' MSP430 16-bit ultra-low-power microcontroller device. The purpose of my project was to integrate the MISL system with a liquid crystal display (LCD) touchscreen. The LCD, manufactured by Crystalfontz and part number CFAF320240F-035T-TS, is a 320 by 240 RGB resistive color screen including an optional carrier board. The vast majority of the project was done with Altium Designer, a tool for printed circuit board (PCB) schematic capture, 3D design, and FPGA (Field Programmable Gate Array) development. The new PCB was to allow the LCD to directly stack to the rest of MISL. Research was done with datasheets for the TI microcontroller and touchscreen display in order to meet desired hardware specifications. Documentation on prior MISL projects was also utilized. The initial step was to create a schematic for the LCD, power bus, and data bus connections between components. A layout was then designed with the required physical dimensions, routed traces and vias, power and ground planes, layer stacks, and other specified design rules such as plane clearance and hole size. Multiple consultation sessions were held with Hester Yim, the technical discipline lead for the Command and Data Handling Branch, and Christy Herring, the lead PCB layout designer in the Electronic Design and Manufacturing Branch in order to ensure proper configuration. At the moment, the PCB is awaiting revision by the latter-mentioned branch. Afterwards, the board will begin to undergo the manufacturing and testing process. Throughout the internship at Johnson Space Center, I gained several technical and professional skills. I gained proficiency in Altium Designer and experience using subversion clients, as well as knowledge in PSpice with OrCAD and battery design for spaceflight from on-site. I also gained networking, organization, and communication skills throughout meetings with coworkers and other interns. This internship at Johnson Space Center has impacted my future aspirations by further inspiring me to follow a career path into space rated engineering technology and human spaceflight applications. After graduation, I plan to attend graduate Modular Integrated Stackable Layers (MISL) is a computer system designed for simple, fast, and cost effective flexible reconfiguration in space environments such as the ISS and Orion projects for various uses. Existing applications include wireless and wired communications, data acquisition and instrumentation, and camera systems, and potential applications include bus protocol converters and subsystem control. MISL is based on Texas Instruments’ MSP430 16 bit ultra-low power microcontroller device. The purpose of my project was to integrate the MISL system with a liquid crystal display touchscreen. The LCD, manufactured by Crystalfontz and part number CFAF320240F-035T-TS, is a 320x240 RGB resistive color screen including an optional carrier board.The vast majority of the project was done with Altium Designer, a tool for printed circuit board (PCB) schematic capture, 3D design, and FPGA development. The new PCB was to allow the LCD to directly stack to the rest of MISL. Research was done with datasheets for the TI microcontroller and touchscreen display in order to meet desired hardware specifications. Documentation on prior MISL projects was also utilized. The initial step was to create a schematic for the LCD, power bus, and data bus connections between components. A layout was then designed with the required physical dimensions, routed traces and vias, power and ground planes, layer stacks, and other specified design rules such as plane clearance and hole size. Multiple consultation sessions were held with Hester Yim, the technical discipline lead for the Command and Data Handling Branch, and Christy Herring, the lead PCB layout designer in the Electronic Design and Manufacturing Branch in order to ensure proper configuration. At themoment, the PCB is awaiting revision by the latter-mentioned branch. Afterwards, the board will begin to undergo the manufacturing and testing process.Throughout the internship at Johnson Space Center, I gained several technical and professional skills. I gained proficiency in Altium Designer and experience using subversion clients, as well as knowledge in PSpice with OrCAD and battery design for spaceflight from on-site. I also gained networking, organization, and communication skills throughout meetings with coworkers and other interns. This internship at Johnson Space Center has impacted my future aspirations by further inspiring me to follow a career path into space rated engineering technology and human spaceflight applications. After graduation, I plan to attend graduate school for a master's or doctorate degree in electrical or computer engineering.

Billings, Rachel Mae↗
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 NTRS2008

Aquarius's Instrument Science Data System (ISDS) Automated to Acquire, Process, Trend Data and Produce Radiometric System Assessment Reports

The Aquarius Radiometer, a subsystem of the Aquarius Instrument required a data acquisition ground system to support calibration and radiometer performance assessment. To support calibration and compose performance assessments, we developed an automated system which uploaded raw data to a ftp server and saved raw and processed data to a database. This paper details the overall functionalities of the Aquarius Instrument Science Data System (ISDS) and the individual electrical ground support equipment (EGSE) which produced data files that were infused into the ISDS. Real time EGSEs include an ICDS Simulator, Calibration GSE, Labview controlled power supply, and a chamber data acquisition system. ICDS Simulator serves as a test conductor primary workstation, collecting radiometer housekeeping (HK) and science data and passing commands and HK telemetry collection request to the radiometer. Calibration GSE (Radiometer Active Test Source) provides source choice from multiple targets for the radiometer external calibration. Power Supply GSE, controlled by labview, provides real time voltage and current monitoring of the radiometer. And finally the chamber data acquisition system produces data reflecting chamber vacuum pressure, thermistor temperatures, AVG and watts. Each GSE system produce text based data files every two to six minutes and automatically copies the data files to the Central Archiver PC. The Archiver PC stores the data files, schedules automated uploads of these files to an external FTP server, and accepts request to copy all data files to the ISDS for offline data processing and analysis. Aquarius Radiometer ISDS contains PHP and MATLab programs to parse, process and save all data to a MySQL database. Analysis tools (MATLab programs) in the ISDS system are capable of displaying radiometer science, telemetry and auxiliary data in near real time as well as performing data analysis and producing automated performance assessment reports of the Aquarius Radiometer.

Source record↗
NASA NTRS1991

Knowledge-based processing for aircraft flight control

The purpose is to develop algorithms and architectures for embedding artificial intelligence in aircraft guidance and control systems. With the approach adopted, AI-computing is used to create an outer guidance loop for driving the usual aircraft autopilot. That is, a symbolic processor monitors the operation and performance of the aircraft. Then, based on rules and other stored knowledge, commands are automatically formulated for driving the autopilot so as to accomplish desired flight operations. The focus is on developing a software system which can respond to linguistic instructions, input in a standard format, so as to formulate a sequence of simple commands to the autopilot. The instructions might be a fairly complex flight clearance, input either manually or by data-link. Emphasis is on a software system which responds much like a pilot would, employing not only precise computations, but, also, knowledge which is less precise, but more like common-sense. The approach is based on prior work to develop a generic 'shell' architecture for an AI-processor, which may be tailored to many applications by describing the application in appropriate processor data bases (libraries). Such descriptions include numerical models of the aircraft and flight control system, as well as symbolic (linguistic) descriptions of flight operations, rules, and tactics.

Painter, John H.↗
NASA NTRS2005

Multi-Mission System Architecture Platform: Design and Verification of the Remote Engineering Unit

The Multi-Mission System Architecture Platform (MSAP) represents an effort to bolster efficiency in the spacecraft design process. By incorporating essential spacecraft functionality into a modular, expandable system, the MSAP provides a foundation on which future spacecraft missions can be developed. Once completed, the MSAP will provide support for missions with varying objectives, while maintaining a level of standardization that will minimize redesign of general system components. One subsystem of the MSAP, the Remote Engineering Unit (REU), functions by gathering engineering telemetry from strategic points on the spacecraft and providing these measurements to the spacecraft's Command and Data Handling (C&DH) subsystem. Before the MSAP Project reaches completion, all hardware, including the REU, must be verified. However, the speed and complexity of the REU circuitry rules out the possibility of physical prototyping. Instead, the MSAP hardware is designed and verified using the Verilog Hardware Definition Language (HDL). An increasingly popular means of digital design, HDL programming provides a level of abstraction, which allows the designer to focus on functionality while logic synthesis tools take care of gate-level design and optimization. As verification of the REU proceeds, errors are quickly remedied, preventing costly changes during hardware validation. After undergoing the careful, iterative processes of verification and validation, the REU and MSAP will prove their readiness for use in a multitude of spacecraft missions.

Sartori, John↗
NASA NTRS1987

Real-time hierarchically distributed processing network interaction simulation

The Telerobot Testbed is a hierarchically distributed processing system which is linked together through a standard, commercial Ethernet. Standard Ethernet systems are primarily designed to manage non-real-time information transfer. Therefore, collisions on the net (i.e., two or more sources attempting to send data at the same time) are managed by randomly rescheduling one of the sources to retransmit at a later time interval. Although acceptable for transmitting noncritical data such as mail, this particular feature is unacceptable for real-time hierarchical command and control systems such as the Telerobot. Data transfer and scheduling simulations, such as token ring, offer solutions to collision management, but do not appropriately characterize real-time data transfer/interactions for robotic systems. Therefore, models like these do not provide a viable simulation environment for understanding real-time network loading. A real-time network loading model is being developed which allows processor-to-processor interactions to be simulated, collisions (and respective probabilities) to be logged, collision-prone areas to be identified, and network control variable adjustments to be reentered as a means of examining and reducing collision-prone regimes that occur in the process of simulating a complete task sequence.

Zimmerman, W. F.↗
NASA NTRS2012

SRMS Assisted Docking and Undocking for the Orbiter Repair Maneuver

As part of the Orbiter Repair Maneuver (ORM) planned for Return to Flight (RTF) operations, the Shuttle Remote Manipulator System (SRMS) must undock the Orbiter, maneuver it through a complex trajectory at extremely low rates, present it to an EVA crewman at the end of the Space Station Remote Manipulator System to perform the Thermal Protection System (TPS) repair, and then retrace back through the trajectory to dock the Orbiter with the Orbiter Docking System (ODS). The initial and final segments of this operation involve the interaction between the SRMS, ISS, Orbiter and ODS. Previously, a technique entitled "SRMS assisted docking" for installation of a payload to the ODS had been developed and was utilized for the Russian provided Docking Module on STS-74 during Shuttle-Mir missions and both the Node 1 and FGB elements on STS-88/Flight 2A. This procedure consisted of the SRMS grappling the respective payload, maneuvering it to a pre-install position inches above the ODS Androgynous Peripheral Attachment System (APAS) ring, commanding the SRMS into Test mode (which allows brakes-off motion of the joints), and then down-firing Primary Reaction Control System (PRCS) jets in order to effect a capture of the APAS latches. Once a successful capture had been achieved, then the AP AS was operated through its nominal retraction sequence to complete the mating sequence. While this technique can once again be used for the tail end docking portion of the ORM, the initial undocking of the orbiter and ISS vehicles with the assistance of the SRMS has yet to be attempted on orbit. The objective here is to determine the most efficient means to separate or extract the vehicles. Two techniques were analyzed in support of RTF: (1) the 'nominal' demating from the mated interface, and (2) the SRMS performing the operation (either in an active or passive fashion). In the first operation, the demating process would replicate standard undocking operations, with the exception that the SRMS is allowed to arrest the resulting motion. The second operation would be to extend the APAS ring to a ready to dock position, open the capture latches, and then detach the vehicles using the SRMS either actively or passively. In the active case, the APAS ring is extended and latched, and the SRMS is commanded to pull the two interfaces apart (assuming that the effective pull force of the SRMS can overcome the spec values of the combined latch resistance). In the passive case, the SRMS brakes are engaged and the AP AS mechanism is commanded to retract, pulling the two interfaces apart. Since the emphasis of both STS-74 and STS-88 had solely been on the installation operation, as opposed to the separation operation, two new models required development and incorporation within simulation tools designed to analyze those scenarios. These enhancements included: (1) a detailed demating dynamics model to characterize the pusher spring characteristics during undocking, and (2) contact and mechanical system modeling of the back side of the latches to represent unlatching dynamics. This paper first provides an overview of the Monte-Carlo screening analysis for the installation (both nominal and contingency), including the variation of separation distance, misalignment conditions, SRMS joint/brake parameter characteristics, and PRCS jet combinations and corresponding thrust durations. The resulting 'optimum' solution is presented based on trade studies between predicted capture success and integrated system loads. This paper then discusses the upgrades to the APAS math model associated with the new SRMS assisted undocking technique and reviews simulation results for various options investigated for either the active and passive separation of the ISS from the Orbiter.

Space Station Remote Manipulator System↗
NASA NTRS1998

STS-95 CEIT in the OPF-2 and the MPPF

Live footage shows the crewmembers of STS-95, Commander Curtis L. Brown, Pilot Steven W. Lindsey, Mission Specialists Scott E. Parazynski, Stephen K. Robinson, Pedro Duque, Payload Specialists Chiaki Mukai and John H. Glenn in a training room talking. Scenes also show the crew in the simulation spacecraft. Crewmembers are seen in the Orbiter Processing Facility Bay 2 ((OPF-2) and the Multi-Payload Processing Facility (MPPF) looking over equipment during the Crew Equipment Interface Test (CEIT) for their mission. The CEIT gives astronauts an opportunity for a hands-on look at the payloads and equipment with which they will be working on orbit.

Source record↗
NASA NTRS2005

Situation Awareness of Onboard System Autonomy

We have developed intelligent agent software for onboard system autonomy. Our approach is to provide control agents that automate crew and vehicle systems, and operations assistants that aid humans in working with these autonomous systems. We use the 3 Tier control architecture to develop the control agent software that automates system reconfiguration and routine fault management. We use the Distributed Collaboration and Interaction (DCI) System to develop the operations assistants that provide human services, including situation summarization, event notification, activity management, and support for manual commanding of autonomous system. In this paper we describe how the operations assistants aid situation awareness of the autonomous control agents. We also describe our evaluation of the DCI System to support control engineers during a ground test at Johnson Space Center (JSC) of the Post Processing System (PPS) for regenerative water recovery.

Schreckenghost, Debra↗