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 919 records · Page 51

Moonwalk Series: The Moon on Earth - Program 4

This episode (4th and last in the series) opens with Michael Collins in the Command Module, Columbia. It then shows the flight of the Lunar Excursion Module (LEM) and the rendezvous with Columbia. The reentry into the Earth's atmosphere, the parachutes deployment, followed by the splashdown is shown. Next we see shots of various parades welcoming the three astronauts home. Following these celebrations, we see the Lunar Receiving Lab, where the Lunar rocks are processed, and the various questions that science hopes to begin to answer about the moon, the development of the solar system and the evolution of life on earth, with the close examination of the rocks are asked.

Source record↗

Acceptance test report (MI-74067-009-00). SVWS access arm (Serial number AA-09-03) (drawing 75M08129-13)

Acceptance tests were conducted at Kennedy Space Center of the Saturn Vehicle Workshop Spacecraft Access Arm and related equipment. The tests were conducted to prove complete system capability to operate satisfactorily under conditions required to support spacecraft operations and activities. The SVWS Access Arm, serial number AA-09-03, is a Command Module Service Arm, S/A 9, which was removed from the mobile launcher and modified to support the SVWS operations. The C/M environmental chamber was removed and a completely new chamber was installed. The retract system was redesigned to remove the automatic/remote control capability and replaced with a local manual control. The SVWS Access Arm System was successfully tested and supported spacecraft processing without major problems.

Hagood, J. T.↗

Automated Cryocooler Monitor and Control System

A system was designed to automate cryogenically cooled low-noise amplifier systems used in the NASA Deep Space Network. It automates the entire operation of the system including cool-down, warm-up, and performance monitoring. The system is based on a single-board computer with custom software and hardware to monitor and control the cryogenic operation of the system. The system provides local display and control, and can be operated remotely via a Web interface. The system controller is based on a commercial single-board computer with onboard data acquisition capability. The commercial hardware includes a microprocessor, an LCD (liquid crystal display), seven LED (light emitting diode) displays, a seven-key keypad, an Ethernet interface, 40 digital I/O (input/output) ports, 11 A/D (analog to digital) inputs, four D/A (digital to analog) outputs, and an external relay board to control the high-current devices. The temperature sensors used are commercial silicon diode devices that provide a non-linear voltage output proportional to temperature. The devices are excited with a 10-microamp bias current. The system is capable of monitoring and displaying three temperatures. The vacuum sensors are commercial thermistor devices. The output of the sensors is a non-linear voltage proportional to vacuum pressure in the 1-Torr to 1-millitorr range. Two sensors are used. One measures the vacuum pressure in the cryocooler and the other the pressure at the input to the vacuum pump. The helium pressure sensor is a commercial device that provides a linear voltage output from 1 to 5 volts, corresponding to a gas pressure from 0 to 3.5 MPa (approx. = 500 psig). Control of the vacuum process is accomplished with a commercial electrically operated solenoid valve. A commercial motor starter is used to control the input power of the compressor. The warm-up heaters are commercial power resistors sized to provide the appropriate power for the thermal mass of the particular system, and typically provide 50 watts of heat. There are four basic operating modes. "Cool " mode commands the system to cool to normal operating temperature. "Heat " mode is used to warm the device to a set temperature near room temperature. "Pump " mode is a maintenance function that allows the vacuum system to be operated alone to remove accumulated contaminants from the vacuum area. In "Off " mode, no power is applied to the system.

Britcliffe, Michael J.↗

Evolution of the Scope and Capabilities of Uplink Support Software for Mars Surface Operations

In January of 2004 both of the Mars Exploration Rover spacecraft landed safely, initiating daily surface operations at the Jet Propulsion Laboratory for what was anticipated to be approximately three months of mobile exploration. The longevity of this mission, still ongoing after ten years, has provided not only a tremendous return of scientific data but also the opportunity to refine and improve the methodology by which robotic Mars surface missions are commanded. Since the landing of the Mars Science Laboratory spacecraft in August of 2012, this methodology has been successfully applied to operate a Martian rover which is both similar to, and quite different from, its predecessors. For MER and MSL, daily uplink operations can be most broadly viewed as converting the combined interests of both the science and engineering teams into a spacecraft-safe set of transmittable command files. In order to accomplish these ends a discrete set of mission-critical software tools were developed which not only allowed for conformation to established JPL standards and practices but also enabled innovative technologies specific to each mission. Although these primary programs provided the requisite capabilities for meeting the high-level goals of each distinct phase of the uplink process, there was little in the way of secondary software to support the smooth flow of data from one phase to the next. In order to address this shortcoming a suite of small software tools was developed to aid in phase transitions, as well as to automate some of the more laborious and error-prone aspects of uplink operations. This paper describes the evolution of this software suite, from its initial attempts to merely shorten the duration of the operator's shift, to its current role as an indispensable tool enforcing workflow of the uplink operations process and agilely responding to the new and unexpected challenges of missions which can, and have, lasted many years longer than originally anticipated.

CoUGAR↗

Transcribing Air Traffic Control System Command Center Planning Telecons Using Cloud-Based Automatic Speech Recognition

This paper addresses the challenge of using Automatic Speech Recognition (ASR) technology to transcribe regular teleconferences that happen between FAA Air Traffic Control System Command Center (ATCSCC) planners, stakeholders and air users. These planning teleconferences (aka telecons or planning webinars) are an integral part of managing air traffic in the U.S. National Airspace System (NAS). In particular, the meetings facilitate the creation and modification of various traffic management initiatives (TMIs), that are used to regulate the flow of air traffic. This is typically a human intensive process, requiring specialists to listen to the entire meeting audio (10-20 minutes duration) and inferring the state of the NAS (e.g., weather phenomenon) that was discussed. It would be advantageous to have digital transcripts of the audio and have useful information (e.g., related to TMIs) automatically extracted from the transcripts. In this regard, we are exploring the adoption of state-of-the-art speech to text and Natural Language Processing (NLP) tools that will achieve our objective of digitizing the webinar audio. Unfortunately, the highly technical phraseology present in the audio and limited data availability for model building make ASR difficult. To overcome this challenge, we have taken the critical first step in creating a human transcription dataset from ~20 hours of speech in the ATCSCC audio with the help of subject matter experts. A novelty of our work is the creation of a ground truth transcription dataset for ATCSCC teleconference webinars, which is particularly important for Aviation domain-specific NLP tasks. Using Microsoft Speech Studio, a cloud-based ASR platform, we have fine-tuned the English pre-trained ASR models (available in speech studio) and achieved an average word error rate (WER) of 6.81%. The baseline ASR also provides a digital version of each planning webinar, making it accessible and text-searchable for future references. Additionally, the transcriptions can serve as a bridge between raw audio data and a range of text-based NLP tasks, such as named entity recognition (NER) and intent classification, potentially enhancing the digital footprint of the webinars and other connected data sources. Our work has several potential applications. Firstly, the transcriptions can be analyzed to understand the complex decision process of creating, implementing and modifying TMIs and may also contribute to TMI prediction services. Secondly, our dataset and model can be used to develop more accurate ASR systems for aviation-specific language, which can bring about digital communication in the aviation industry (and aid current “voice only” communications, which are inherently error-prone). Lastly, the transcriptions themselves can be used as a valuable resource for training other NLP models.

Stephen S. B. Clarke↗

Summary of the key features of seven biomathematical models of human fatigue and performance

BACKGROUND: Biomathematical models that quantify the effects of circadian and sleep/wake processes on the regulation of alertness and performance have been developed in an effort to predict the magnitude and timing of fatigue-related responses in a variety of contexts (e.g., transmeridian travel, sustained operations, shift work). This paper summarizes key features of seven biomathematical models reviewed as part of the Fatigue and Performance Modeling Workshop held in Seattle, WA, on June 13-14, 2002. The Workshop was jointly sponsored by the National Aeronautics and Space Administration, U.S. Department of Defense, U.S. Army Medical Research and Materiel Command, Office of Naval Research, Air Force Office of Scientific Research, and U.S. Department of Transportation. METHODS: An invitation was sent to developers of seven biomathematical models that were commonly cited in scientific literature and/or supported by government funding. On acceptance of the invitation to attend the Workshop, developers were asked to complete a survey of the goals, capabilities, inputs, and outputs of their biomathematical models of alertness and performance. Data from the completed surveys were summarized and juxtaposed to provide a framework for comparing features of the seven models. RESULTS: Survey responses revealed that models varied greatly relative to their reported goals and capabilities. While all modelers reported that circadian factors were key components of their capabilities, they differed markedly with regard to the roles of sleep and work times as input factors for prediction: four of the seven models had work time as their sole input variable(s), while the other three models relied on various aspects of sleep timing for model input. Models also differed relative to outputs: five sought to predict results from laboratory experiments, field, and operational data, while two models were developed without regard to predicting laboratory experimental results. All modelers provided published papers describing their models, with three of the models being proprietary. CONCLUSIONS: Although all models appear to have been fundamentally influenced by the two-process model of sleep regulation by Borbely, there is considerable diversity among them in the number and type of input and output variables, and their stated goals and capabilities.

Fatigue/physiopathology↗

Caltrans Keeps the Spitzer Pipelines Moving

The computer pipelines used to process digital infrared astronomical images from NASA's Spitzer Space Telescope require various input calibration-data files for characterizing the attributes and behaviors of the onboard focal-plane-arrays and their detector pixels, such as operability, dark-current offset, linearity, non- uniformity, muxbleed, droop, and point-response functions. The telescope has three very different science instruments, each with three or four spectral-band-pass channels, depending on the instrument. Moreover, each instrument has various operating modes (e-g., full array or sub-array in one case) and parameters (e.g., integration time). Calibration data that depend on these considerations are needed by pipelines for generating both science products (production pipelines) and higher-level calibration products (calibration pipelines). The calibration files are created in various formats either 'off-line' or by the aforementioned calibration pipelines, depending on the above configuration details. Also, the calibration files are generally applicable to a certain time period and therefore must be selected accordingly for a given raw input image to be correctly processed. All of this complexity in selecting and retrieving calibration files for pipeline processing is handled by a procedural software-program called 'caltrans' . This software, which is implemented in C and interacts with an Informix database, was developed at the Spitzer Science Center (SSC) and is now deployed in SSC daily operations. The software is rule-based, very flexible, and, for efficiency, capable of retrieving multiple calibration files with a single software-execution command.

Spitzer↗

Wavelet-Based Real-Time Diagnosis of Complex Systems

A new method of robust, autonomous real-time diagnosis of a time-varying complex system (e.g., a spacecraft, an advanced aircraft, or a process-control system) is presented here. It is based upon the characterization and comparison of (1) the execution of software, as reported by discrete data, and (2) data from sensors that monitor the physical state of the system, such as performance sensors or similar quantitative time-varying measurements. By taking account of the relationship between execution of, and the responses to, software commands, this method satisfies a key requirement for robust autonomous diagnosis, namely, ensuring that control is maintained and followed. Such monitoring of control software requires that estimates of the state of the system, as represented within the control software itself, are representative of the physical behavior of the system. In this method, data from sensors and discrete command data are analyzed simultaneously and compared to determine their correlation. If the sensed physical state of the system differs from the software estimate (see figure) or if the system fails to perform a transition as commanded by software, or such a transition occurs without the associated command, the system has experienced a control fault. This method provides a means of detecting such divergent behavior and automatically generating an appropriate warning.

Gulati, Sandeep↗

XTCE (XML Telemetric and Command Exchange) Standard Making It Work at NASA. Can It Work For You?

The XML Telemetric and Command Exchange (XTCE) standard is intended as a way to describe telemetry and command databases to be exchanged across centers and space agencies. XTCE usage has the potential to lead to consolidation of the Mission Operations Center (MOC) Monitor and Control displays for mission cross-support, reducing equipment and configuration costs, as well as a decrease in the turnaround time for telemetry and command modifications during all the mission phases. The adoption of XTCE will reduce software maintenance costs by reducing the variation between our existing mission dictionaries. The main objective of this poster is to show how powerful XTCE is in terms of interoperability across centers and missions. We will provide results for a use case where two centers can use their local tools to process and display the same mission telemetry in their MOC independently of one another. In our use case we have first quantified the ability for XTCE to capture the telemetry definitions of the mission by use of our suite of support tools (Conversion, Validation, and Compliance measurement). The next step was to show processing and monitoring of the same telemetry in two mission centers. Once the database was converted to XTCE using our tool, the XTCE file became our primary database and was shared among the various tool chains through their XTCE importers and ultimately configured to ingest the telemetry stream and display or capture the telemetered information in similar ways.Summary results include the ability to take a real mission database and real mission telemetry and display them on various tools from two centers, as well as using commercially free COTS.

CCSDS↗

Pioneer Odyssey: Encounter with a Giant

Ancient peoples, perhaps thousands of years ago, undoubtedly conceived the idea of "reaching out" to Jupiter, the largest and most brilliant of the "wandering stars." But for mankind to stretch across the half billion miles to the giant planet of the Solar System many advances in technical and organizational fields of human endeavor had to be made. Outreach to Jupiter did not become a serious possibility until the Pioneer F and G Project was formed by NASA early in 1968. And then man began to design an extension of his senses that would probe the environs of the giant of the Solar System, a truly pioneer odyssey into the virtually unknown regions beyond the orbit of Mars. In the ensuing year. a dedicated and cooperative effort of several thousand people in Govern­ment, university, and private industrial organiza­tions converted the idea into a reality. Less than twelve generations after Galileo first saw the banded disc of Jupiter and the flickering dots of its large satellites in the newly invented telescope, mankind sent a machine to make observations within that Jovian system. The two Pioneer spacecraft for the mission to Jupiter each weighed only about 570 pounds, yet carried eleven highly sophisticated instruments capable of operating unattended for many year in space. The spacecraft consumes less electrical power than a standard 100 watt lamp yet is able to accept instructions from Earth to control numerous operating modes of its scientific payload, process observations from these scientific instruments and format the observations into information usable on Earth. Even more remarkable. the space­craft transmits a radio signal of only 8 watts power - equal to a nightlight - yet the information carried by the radio signal is received back on Earth from a distance of several billion miles. The Pioneer mission could not have been a success without the special engineering, scientific and management organization created for its accomplishment. This organization was rather unique in that it first had to meet a launch date target relatively quickly and then had to function for an extremely long mission operational time, far longer than any previous mission to planets. The first task was thus to organize so that the mission could be planned and the spacecraft designed and fabricated to be ready for launch within a few weeks of a 30-month target for completion. The program also produced an organization that planned mission operations to such detail that more than 16,000 commands were transmitted flawlessly to the distant spacecraft during Jupiter encounter. And each command reached the spacecraft within one second of the planned time despite the more than 90 minutes required for the radio message to travel from Earth to the space­craft and for the spacecraft to return a confirma­tion to controllers back on Earth. The organization for Pioneer also determined the required flight path from Earth to Jupiter with such precision, and controlled the launch vehicle with such accuracy, that 21 months after launch the spacecraft was able to fly behind Jupiter's satellite lo, thereby providing the first measurement that indicated the possibility of a tenuous atmosphere about this large satellite. Finally, the Pioneer organization processed and analyzed each year sufficient information from the spacecraft to fill a book having about 3 million pages and reduced this avalanche of data from space into summaries of manageable size. And all this organization depended on people, consisted of people: the people who really made this whole mission possible. Pioneer has always depended on the dedication of many individuals from many organizations throughout the world to achieve its scientific objectives, and, as evidenced by the success of the Pioneer series, this dependence is completely justified. Relatively few individuals have an opportunity during their lives to participate in such a challenging, historic, pioneering effort; and still fewer are able to enjoy the rewards of such an activity. We who have worked on Pioneer 10 and its sister spacecraft, Pioneer 11, consider ourselves fortunate to be in both classes. For the opportunity we thank the people of the United States of America, who have supported our country's space effort and its spreading of human awareness of a vast and intriguing universe in which our own unique planet Earth is only one of myriads of worlds. This volume describing the mission to Jupiter and its results is one of the many rewards for our effort which we share with you, the reader.

Fimmel, Richard O.↗

Simulation of Mariner Mars 1971 spacecraft

Preparation for the Mariner Mars 1971 mission is reported, including an extensive training program for operations personnel during which the primary source of spacecraft data was a computer program simulating the spacecraft. The objectives of a simulation model for training purposes differed from objectives appropriate to a design or analysis model. Model subsystems were designed to provide realistic telemetry data reflecting changes due both to commands and environmental parameters affecting the spacecraft at various times during the mission. The spacecraft is modeled along two separate functional lines. Boolean operations are concentrated in the spacecraft logic model, which determines the spacecraft state or mode, while mathematical operations or algorithms are executed in computational subsystem models. Although logic parameters are interrogated as a part of each computational pass, actual logic model processing occurs only when a change-of-state input is generated by the operations organization. The program design, some of the special characteristics of each of the modeled subsystems, and how the model was used in support of mission operations training are presented.

Ausman, N. E., Jr.↗

A spacecraft computer repairable via command.

The MULTIPAC is a central data system developed for deep-space probes with the distinctive feature that it may be repaired during flight via command and telemetry links by reprogramming around the failed unit. The computer organization uses pools of identical modules which the program organizes into one or more computers called processors. The interaction of these modules is dynamically controlled by the program rather than hardware. In the event of a failure, new programs are entered which reorganize the central data system with a somewhat reduced total processing capability aboard the spacecraft. Emphasis is placed on the evolution of the system architecture and the final overall system design rather than the specific logic design.

Fimmel, R. O.↗

Planning the Voyager spacecraft's mission to Uranus

The application of the systems engineering process to the planning of the Voyager spacecraft mission is described. The Mission Planning Office prepared guidelines that controlled the use of the project and multimission resources and spacecraft consumables in order to obtain valuable scientific data at an acceptable risk level. Examples of mission planning which are concerned with the design of the Deep Space Network antenna, the uplink window for transmitting computer command subsystem loads, and the contingency and risk assessment functions are presented.

Plagemann, Stephen H.↗

Range and mission scheduling automation using combined AI and operations research techniques

Ground-based systems for Satellite Command, Control, and Communications (C3) operations require a method for planning, scheduling and assigning the range resources such as: antenna systems scattered around the world, communications systems, and personnel. The method must accommodate user priorities, last minute changes, maintenance requirements, and exceptions from nominal requirements. Described are computer programs which solve 24 hour scheduling problems, using heuristic algorithms and a real time interactive scheduling process.

Arbabi, Mansur↗

A new systems engineering approach to streamlined science and mission operations for the Far Ultraviolet Spectroscopic Explorer (FUSE)

The Mission Operations and Data Systems Directorate (MO&DSD, Code 500), the Space Sciences Directorate (Code 600), and the Flight Projects Directorate (Code 400) have developed a new approach to combine the science and mission operations for the FUSE mission. FUSE, the last of the Delta-class Explorer missions, will obtain high resolution far ultraviolet spectra (910 - 1220 A) of stellar and extragalactic sources to study the evolution of galaxies and conditions in the early universe. FUSE will be launched in 2000 into a 24-hour highly eccentric orbit. Science operations will be conducted in real time for 16-18 hours per day, in a manner similar to the operations performed today for the International Ultraviolet Explorer. In a radical departure from previous missions, the operations concept combines spacecraft and science operations and data processing functions in a single facility to be housed in the Laboratory for Astronomy and Solar Physics (Code 680). A small missions operations team will provide the spacecraft control, telescope operations and data handling functions in a facility designated as the Science and Mission Operations Center (SMOC). This approach will utilize the Transportable Payload Operations Control Center (TPOCC) architecture for both spacecraft and instrument commanding. Other concepts of integrated operations being developed by the Code 500 Renaissance Project will also be employed for the FUSE SMOC. The primary objective of this approach is to reduce development and mission operations costs. The operations concept, integration of mission and science operations, and extensive use of existing hardware and software tools will decrease both development and operations costs extensively. This paper describes the FUSE operations concept, discusses the systems engineering approach used for its development, and the software, hardware and management tools that will make its implementation feasible.

Butler, Madeline J.↗

Control method for prosthetic devices

A control system and method for prosthetic devices is provided. The control system comprises a transducer for receiving movement from a body part for generating a sensing signal associated with that movement. The sensing signal is processed by a linearizer for linearizing the sensing signal to be a linear function of the magnitude of the distance moved by the body part. The linearized sensing signal is normalized to be a function of the entire range of body part movement from the no-shrug position of the moveable body part. The normalized signal is divided into a plurality of discrete command signals. The discrete command signals are used by typical converter devices which are in operational association with the prosthetic device. The converter device uses the discrete command signals for driving the moveable portions of the prosthetic device and its sub-prosthesis. The method for controlling a prosthetic device associated with the present invention comprises the steps of receiving the movement from the body part, generating a sensing signal in association with the movement of the body part, linearizing the sensing signal to be a linear function of the magnitude of the distance moved by the body part, normalizing the linear signal to be a function of the entire range of the body part movement, dividing the normalized signal into a plurality of discrete command signals, and implementing the plurality of discrete command signals for driving the respective moveable prosthesis device and its sub-prosthesis.

Bozeman, Richard J., Jr.↗

A Photo Album of Earth Scheduling Landsat 7 Mission Daily Activities

Landsat7 is a member of a new generation of Earth observation satellites. Landsat7 will carry on the mission of the aging Landsat 5 spacecraft by acquiring high resolution, multi-spectral images of the Earth surface for strategic, environmental, commercial, agricultural and civil analysis and research. One of the primary mission goals of Landsat7 is to accumulate and seasonally refresh an archive of global images with full coverage of Earth's landmass, less the central portion of Antarctica. This archive will enable further research into seasonal, annual and long-range trending analysis in such diverse research areas as crop yields, deforestation, population growth, and pollution control, to name just a few. A secondary goal of Landsat7 is to fulfill imaging requests from our international partners in the mission. Landsat7 will transmit raw image data from the spacecraft to 25 ground stations in 20 subscribing countries. Whereas earlier Landsat missions were scheduled manually (as are the majority of current low-orbit satellite missions), the task of manually planning and scheduling Landsat7 mission activities would be overwhelmingly complex when considering the large volume of image requests, the limited resources available, spacecraft instrument limitations, and the limited ground image processing capacity, not to mention avoidance of foul weather systems. The Landsat7 Mission Operation Center (MOC) includes an image scheduler subsystem that is designed to automate the majority of mission planning and scheduling, including selection of the images to be acquired, managing the recording and playback of the images by the spacecraft, scheduling ground station contacts for downlink of images, and generating the spacecraft commands for controlling the imager, recorder, transmitters and antennas. The image scheduler subsystem autonomously generates 90% of the spacecraft commanding with minimal manual intervention. The image scheduler produces a conflict-free schedule for acquiring images of the "best" 250 scenes daily for refreshing the global archive. It then equitably distributes the remaining resources for acquiring up to 430 scenes to satisfy requests by international subscribers. The image scheduler selects candidate scenes based on priority and age of the requests, and predicted cloud cover and sun angle at each scene. It also selects these scenes to avoid instrument constraint violations and maximizes efficiency of resource usage by encouraging acquisition of scenes in clusters. Of particular interest to the mission planners, it produces the resulting schedule in a reasonable time, typically within 15 minutes.

Potter, William↗

cFS Test Framework (CTF)

NASA's Core Flight System (cFS) provides a generic flight software framework architecture for developing flight software. As the cFS framework has gained popularity over the years within the flight software community, supporting software tools have been developed to assist in the design, development, testing and verification of flight software. The cFS Test Framework (CTF) is a recently developed cFS tool with capabilities to develop and run automated test and verification scripts against flight software targets. The CTF tool parses and executes JSON-based test scripts containing test instructions, while logging and reporting the results. CTF utilizes a plugin-based architecture to allow developers to extend CTF with new test instructions, external interfaces, and custom functionality. To interface with flight software, CTF parses a set of CCSDS message definition files to create the necessary command and telemetry structures for use during the test run. Additionally, CTF also supports interfacing with multiple cFS instances, allowing a test script to verify requirements that involve multiple flight software targets. Lastly, CTF provides support for executing test scripts against FSW running on remote or embedded hardware. This allows CTF to execute the same test scripts across different target configurations throughout the development process. In this presentation, we will introduce the cFS Test Framework (CTF) architecture, discuss the history of cFS testing frameworks, and present the features and capabilities currently provided by CTF. Lastly, we will show a demo of the CTF tool being used to execute test scripts against flight software.

Aly I Shehata↗