Search NASA⌕ Search

SEARCH · Search NASA

Results for “automated command”

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 145 records · Page 8

Man's role in a remote orbital servicing system

The Remote Orbital Servicing System (ROSS), a focal point for NASA research in automation and robotics, is discussed in terms of the role of man in such a system. In the supervisory control mode, the ROSS operator inputs high-level goals to a strategic (nonreal-time) planner which then passes the plan or series of actions to a tactical (real-time) planner which executes the plan. Using directed control, man makes more specific commands to perform strategic planning with or without the use of the automated strategic planner. Shared computer/manual control will require a multifunction interactive display. At the teleoperator control level, a hand controller is used to command the ROSS manipulator and end effectors.

Pennington, J. E.↗

Have we overlooked the pilot's role in an automated flight deck

Having adopted a philosophy of presenting situation information rather than command type as evidenced in flight directors and of keeping the pilot in a decision-making role, a series of simulation and flight experiments has occurred over a number of years as part of the Langley Terminal Configured Vehicle program. This paper traces the development, refinement, and integration of electronic pictorial displays, and a computer augmented velocity vector control mode. Some benefits and performances derived within the basic philosophy and information usage are brought forth in the discussion as results from the various simulator and flight evaluations are presented.

Steinmetz, G. G.↗

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

Automated Software for Manned Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C. Dempsey↗

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies. One goal of advanced spacecraft automation is the ability to reduce both the crew workload and the ground control footprint while at the same time increasing spacecraft and mission flexibility. Historically, crewed spacecraft required a large number of operators on the ground to use a plethora of tools to compute nominal and contingency mission trajectories. Moving those sophisticated software tools to being onboard the vehicle can reduce the need for such complex ground support. Given that today’s spacecraft software is not yet as capable or as flexible in all circumstances as the computers depicted in movies, there is usually a trade-off between software automation cost and the flexibility of that software resulting in a trade-off between what is performed on the spacecraft and what is left to onboard crew or ground control. For missions that go beyond the Moon, software that autonomously controls nearly every aspect of a crewed mission will become a necessity given the long time delays between the spacecraft and Earth’s ground control teams. The lessons learned by Boeing and its Mission Operations team, through the design and implementation of Starliner’s hardware and software automation, will be able to inform future public and private spacecraft design. As the technologies and capabilities evolve, incorporating lessons learned in successful low Earth orbit commercial crew vehicle missions, spacecraft designs will continue to improve and be able to better enable safe execution of human missions to the Moon and beyond.

Robert C Dempsey↗

Automated Software for Crewed Spacecraft - Bridging the Gap from Sci Fi to Reality

With a voice command or a few taps on the console, the spacecraft pivots on a dime at high velocity and gently docks to an orbiting space platform. This is the image most people have of the complex software computations and integrated hardware performance necessary for a spacecraft to successfully perform an automated launch, rendezvous, and docking. Today’s reality is that while computer operations are advancing rapidly, science fiction over-simplifies and over-sells current capabilities. This paper discusses the integration of spacecraft computer automation into the operation of one of the United States’ new Commercial Crew vehicles - the Boeing CST-100 Starliner. Lessons learned by the Boeing Mission Operations team, a unique private-public partnership with NASA, from conceptual design through real-time operation of the first test flight will be discussed along with evolution of the system in preparation for the second uncrewed test flight. Focus will center on how operations has learned to use the automated software to their advantage while also knowing how to adjust the automation in response to spacecraft or mission anomalies.

Robert C. Dempsey↗

Short Haul Civil Tiltrotor Study in MIDAS: Auto versus Manual Nacelle Procedures for Commanded Go-Around

Tiltrotor aircraft combine the speed and range of a turboprop performance with the ability to take off and land in a vertical mode like a helicopter. These aircraft will transport passengers from city center to city center and from satellite airports to major hub airports to make connections to long range travel. The Short Haul Civil Tiltrotor (SH(CT)) being studied by NASA is a concept 40 passenger civil tiltrotor (CTR) transport. The Man-machine Integration Design and Analysis System (MIDAS) was used to evaluate human performance in terms of crew procedures and pilot workload for a simulated 40 passenger Civil Tiltrotor Transport on a steep approach to a vertiport. The scenario for the simulation was a normal approach to the vertiport that is interrupted by a commanded go-around at the landing decision point. The simulation contrasted an automated discrete nacelle mode control with a fully manual nacelle control mode for the go-around. The MIDAS simulation showed that the pilot task loading during approach and for the commanded go-around is high and that pilot workload is near capacity throughout. The go-around in manual nacelle mode was most demanding, resulting in additional time requirements to complete necessary tasks.

Atencio, Adolph, Jr.↗

Proven and Robust Ground Support Systems - GSFC Success and Lessons Learned

Over the past fifteen years, Goddard Space Flight Center has developed several successful science missions in-house: the Wilkinson Microwave Anisotropy Probe (WMAP), the Imager for Magnetopause-to-Aurora Global Exploration (IMAGE), the Earth Observing 1 (EO-1) [1], and the Space Technology 5 (ST-5)[2] missions, several Small Explorers, and several balloon missions. Currently in development are the Solar Dynamics Observatory (SDO) [3] and the Lunar Reconnaissance Orbiter (LRO)[4]. What is not well known is that these missions have been supported during spacecraft and/or instrument integration and test, flight software development, and mission operations by two in house satellite Telemetry and Command (T & C) Systems, the Integrated Test and Operations System (ITOS) and the Advanced Spacecraft Integration and System Test (ASIST). The advantages of an in-house satellite Telemetry and Command system are primarily in the flexibility of management and maintenance - the developers are considered a part of the mission team, get involved early in the development process of the spacecraft and mission operations-control center, and provide on-site, on-call support that goes beyond Help Desk and simple software fixes. On the other hand, care must be taken to ensure that the system remains generic enough for cost effective re-use from one mission to the next. The software is designed such that many features are user-configurable. Where user-configurable options were impractical, features were designed so as to be easy for the development team to modify. Adding support for a new ground message header, for example, is a one-day effort because of the software framework on which that code rests. This paper will discuss the many features of the Goddard satellite Telemetry and Command systems that have contributed to the success of the missions listed above. These features include flexible user interfaces, distributed parallel commanding and telemetry decommutation, a procedure language, the interfaces and tools needed for a high degree of automation, and instantly accessible archives of spacecraft telemetry. It will discuss some of the problems overcome during development, including secure commanding over networks or the Internet, constellation support for the three satellites that comprise the ST-5 mission, and geographically distributed telemetry end users.

Pfarr, Barbara↗

Time-Tag Generation Script

Time-Tag Generation Script (TTaGS) is an application program, written in the AWK scripting language, for generating commands for aiming one Ku-band antenna and two S-band antennas for communicating with spacecraft. TTaGS saves between 2 and 4 person-hours per every 24 hours by automating the repetitious process of building between 150 and 180 antenna-control commands. TTaGS reads a text database of communication satellite schedules and a text database of satellite rise and set times and cross-references items in the two databases. It then compares the scheduled start and stop with the geometric rise and set to compute the times to execute antenna control commands. While so doing, TTaGS determines whether to generate commands for guidance, navigation, and control computers to tell them which satellites to track. To help prevent Ku-band irradiation of the Earth, TTaGS accepts input from the user about horizon tolerance and accordingly restricts activation and effects deactivation of the transmitter. TTaGS can be modified easily to enable tracking of additional satellites and for such other tasks as reading Sun-rise/set tables to generate commands to point the solar photovoltaic arrays of the International Space Station at the Sun.

Jackson, Dan E.↗

Automation study for space station subsystems and mission ground support

An automation concept for the autonomous operation of space station subsystems, i.e., electric power, thermal control, and communications and tracking are discussed. To assure that functions essential for autonomous operations are not neglected, an operations function (systems monitoring and control) is included in the discussion. It is recommended that automated speech recognition and synthesis be considered a basic mode of man/machine interaction for space station command and control, and that the data management system (DMS) and other systems on the space station be designed to accommodate fully automated fault detection, isolation, and recovery within the system monitoring function of the DMS.

Source record↗

Automating the Generation of the Cassini Tour Atlas Database

The Tour Atlas is a large database of geometrical tables, plots, and graphics used by Cassini science planning engineers and scientists primarily for science observation planning. Over time, as the contents of the Tour Atlas grew, the amount of time it took to recreate the Tour Atlas similarly grew--to the point that it took one person a week of effort. When Cassini tour designers estimated that they were going to create approximately 30 candidate Extended Mission trajectories--which needed to be analyzed for science return in a short amount of time--it became a necessity to automate. We report on the automation methodology that reduced the amount of time it took one person to (re)generate a Tour Atlas from a week to, literally, one UNIX command.

Cassini↗

Development Status: Automation Advanced Development Space Station Freedom Electric Power System

Electric power system automation for Space Station Freedom is intended to operate in a loop. Data from the power system is used for diagnosis and security analysis to generate Operations Management System (OMS) requests, which are sent to an arbiter, which sends a plan to a commander generator connected to the electric power system. This viewgraph presentation profiles automation software for diagnosis, scheduling, and constraint interfaces, and simulation to support automation development. The automation development process is diagrammed, and the process of creating Ada and ART versions of the automation software is described.

Dolce, James L.↗

Managing the Implementation of Mission Operations Automation

Reducing the cost of mission operations has necessitated a high level of automation both on spacecraft and ground systems. While automation on spacecraft is implemented during the design phase, ground system automation tends to be implemented during the prime mission operations phase. Experience has shown that this tendency for late automation development can be hindered by several factors: additional hardware and software resources may need to be procured; software must be developed and tested on a non-interference basis with primary operations with limited manpower; and established procedures may not be suited for automation requiring substantial rework. In this paper we will review the experience of successfully automating mission operations for seven on-orbit missions: the Compton Gamma Ray Observatory (CGRO), the Rossi X-Ray Timing Explorer (RXTE), the Advanced Composition Explorer (ACE), the Far Ultraviolet Spectroscopic Explorer (FUSE), Interplanetary Physics Laboratory (WIND), Polar Plasma Laboratory (POLAR), and the Imager for Magnetopause-to-Aurora Global Exploration (IMAGE). We will provide lessons learned in areas such as: spacecraft recorder management, procedure development, lights out commanding from the ground system vs. stored command loads, spacecraft contingency response time, and ground station interfaces. Implementing automation strategies during the mission concept and spacecraft integration and test phase as the most efficient method will be discussed.

Sodano, R.↗

2006 NASA Range Safety Annual Report

Throughout 2006, Range Safety was involved in a number of exciting and challenging activities and events, from developing, implementing, and supporting Range Safety policies and procedures-such as the Space Shuttle Launch and Landing Plans, the Range Safety Variance Process, and the Expendable Launch Vehicle Safety Program procedures-to evaluating new technologies. Range Safety training development is almost complete with the last course scheduled to go on line in mid-2007. Range Safety representatives took part in a number of panels and councils, including the newly formed Launch Constellation Range Safety Panel, the Range Commanders Council and its subgroups, the Space Shuttle Range Safety Panel, and the unmanned aircraft systems working group. Space based range safety demonstration and certification (formerly STARS) and the autonomous flight safety system were successfully tested. The enhanced flight termination system will be tested in early 2007 and the joint advanced range safety system mission analysis software tool is nearing operational status. New technologies being evaluated included a processor for real-time compensation in long range imaging, automated range surveillance using radio interferometry, and a space based range command and telemetry processor. Next year holds great promise as we continue ensuring safety while pursuing our quest beyond the Moon to Mars.

TenHaken, Ron↗

Mode Transitions in Glass Cockpit Aircraft: Results of a Field Study

One consequence of increased levels of automation in complex control systems is the presence of modes. A mode is a particular configuration of a control system that defines how human command inputs are interpreted. In complex systems, modes also often determine a specific allocation of control authority between the human and automated systems. Even in simple static devices (e.g., electronic watches, word processors), the presence of modes has been found to cause problems in either-the acquisition or production of skilled performance. Many of these problems arise due to the fact that the selection of a mode causes device behavior to be mediated by hidden internal state information. For these simple systems, many of these interaction problems can be solved by the design of appropriate feedback to communicate internal state information to the human operator. In complex dynamic systems, however, the design issues associated with modes seem to trancend the problem of merely communicating internal state information via displayed feedback. In complex supervisory control systems (e.g., aircraft, spacecraft, military command and control), a key function of modes is the selection of a particular configuration of control authority between the human operator and automated control systems. One mode may result in full manual control, another may result in a mix of manual and automatic control, while a third may result in full automatic control over the entire system. The human operator selects an appropriate mode as a function of current goals, operating conditions, and operating procedures. Thus, the operator is put in a position of essentially trying to control two coupled dynamic systems: the target system itself, and also a highly complex suite of automation controlling the target system. From a historical perspective, it should probably not come as a surprise that very little information is available to guide the design of mode-oriented control systems. The topic of function allocation (i.e., the proper division of control authority among human and computer) has a long history in human-machine systems research. Although this research has produced some relevant guidelines, a design approach capable of defining appropriate allocations of control function between the human and automation is not yet available. As a result, the function allocation decision itself has been allocated to the operator, to be performed in real-time, in the operation of mode-oriented control systems. A variety of documented aircraft accidents and incidents suggest that the real-time selection and monitoring of control modes is a weak link in the effective operation of complex supervisory control systems. Research in human-machine systems and human-computer interaction has barely scraped the surface of the problem of understanding how operators manage this task.The purpose of this paper is to present the results of a field study which examined how operators manage mode selection in a complex supervisory control system. Data on mode engagements using the Boeing B757/767 auto-flight system were collected during approach and descent into four major airports in the East Coast of the United States. Protocols documenting mode selection, automatic mode changes, pilot actions, quantitative records of flight-path variables, and verbal reports during and after mode engagements were collected by an observer from the jumpseat. Observations were conducted on two typical trips between three airports. Each trip was be replicated 11 times, which yielded a total of 22 trips and 66 legs on which data were collected. All data collected concerned the same flight numbers, and therefore, the same time of day, same type of aircraft, and identical operational environments (e.g., ATC facilities, weather patterns, traffic flow etc.)

Degani, Asaf↗

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↗

Autonomous Satellite Command and Control through the World Wide Web: Phase 3

NASA's New Millenium Program (NMP) has identified a variety of revolutionary technologies that will support orders of magnitude improvements in the capabilities of spacecraft missions. This program's Autonomy team has focused on science and engineering automation technologies. In doing so, it has established a clear development roadmap specifying the experiments and demonstrations required to mature these technologies. The primary developmental thrusts of this roadmap are in the areas of remote agents, PI/operator interface, planning/scheduling fault management, and smart execution architectures. Phases 1 and 2 of the ASSET Project (previously known as the WebSat project) have focused on establishing World Wide Web-based commanding and telemetry services as an advanced means of interfacing a spacecraft system with the PI and operators. Current automated capabilities include Web-based command submission, limited contact scheduling, command list generation and transfer to the ground station, spacecraft support for demonstrations experiments, data transfer from the ground station back to the ASSET system, data archiving, and Web-based telemetry distribution. Phase 2 was finished in December 1996. During January-December 1997 work was commenced on Phase 3 of the ASSET Project. Phase 3 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 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 is examined in the next section. Significant sections of this report were also published as a conference paper.

Cantwell, Brian↗

The Mars surveyor operations project command generation process

The methods employed by the Mars surveyor operations project (MSOP) flight team to accelerate the command generation process are described. The approach adopted was to develop a ground system which could simultaneously support as many as three spacecraft in various phases of flight and two in development. The uplink element of the MSOP is discussed, including the control of the science instruments and the spacecraft bus using real-time commands as well as time-tagged stored sequences. The non-interactive payload command process, the express command process, the coordinated command process and the stored sequence process are described. The automation of these processes resulted in flight operations cost savings while maintaining a minimum of risk.

Brooks, Robert N., Jr.↗