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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2016

Making Debris Avoidance Decisions for ESMO's EOS Mission Set

The presentation will cover the aspects of making debris risk decisions from the NASA Mission Director's perspective, specifically for NASA Earth Science Mission Operations (ESMO) Earth Observing System (EOS) mission set. ESMO has been involved in analyzing potential debris risk conjunctions with secondary objects since the inception of this discipline. Through the cumulated years of experience and continued exposure to various debris scenarios, ESMO's understanding of the problem and process to deal with this issue has evolved. The presentation will describe the evolution of the ESMO process, specifically as it relates to the maneuver execution and spacecraft risk management decision process. It will briefly cover the original Drag Make-Up Maneuver, several day, methodical manually intensive, ramp up waive off approach, to the present day more automated, pre-canned onboard command, tools based approach. The presentation will also cover the key information needed to make debris decisions and challenges in doing so while still trying to meet science goals, constellation constraints and manage resources. A slide or two at the end of the presentation, will be devoted to discussing what further improvements could be helpful to improve decision making and future process improvement plans challenges.

debris↗
NASA NTRSDate not supplied

Lunar Command and Control Interoperability (LuCCI) Project Overview

The Lunar Command and Control Interoperability (LuCCI) project was formed 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.

Communications↗
NASA NTRS1994

Re-Engineering the Multimission Command System at the Jet Propulsion Laboratory

This paper will discuss the design and implementation of the command software, especially trade-offs and lessons learned from practical operational use in JPL's Advanced Multimission Operations System.The command system provides an advanced multimission environment for secure, concurrent commanding of multiple spacecraft. The lessons learned have resulted in a re-engineering of the command system, especially in its user interface and new automation capabilities. This paper will also discuss new development work including a multimission command database toolkit, a universal command translator for sequencing and real-time commands, and incorporation of telecommand capabilities for new missions.

re-engineering↗
NASA NTRS2020

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con- trol its next near term behavior. We present a high-level view of the automated flight rule checker Frc for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there- fore be verified with a trace analysis tool. Frc is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con- text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

Kurklu, Elif↗
NASA NTRS2020

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con-trol its next near term behavior. We present a high-level view of the automated flight rule checker FRC for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there-fore be verified with a trace analysis tool. FRC is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con-text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

LADEE↗
NASA NTRS2003

Continuous Improvements to East Coast Abort Landings for Space Shuttle Aborts

Improvement initiatives in the areas of guidance, flight control, and mission operations provide increased capability for successful East Coast Abort Landings (ECAL). Automating manual crew procedures in the Space Shuttle's onboard guidance allows faster and more precise commanding of flight control parameters needed for successful ECALs. Automation also provides additional capability in areas not possible with manual control. Operational changes in the mission concept allow for the addition of new landing sites and different ascent trajectories that increase the regions of a successful landing. The larger regions of ECAL capability increase the safety of the crew and Orbiter.

Butler, Kevin D.↗
NASA NTRS1998

Autonomous Satellite Command and Control Through the World Wide Web

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

Cantwell, Brian↗
DOE OSTI2026

Rhythm

Rhythm is a small Python framework that automates Cadence Spectre simulations from the command line. Instead of creating an ADE testbench, you'll write a Rhythm Recipe, a short, readable Python script that contains each step needed to test your circuit from setting up libraries and stimulus waveforms to setting up analyses and reading the results (in Rhythm, these steps are called stages). Need to run more than one simulation? Use a Rhythm Campaign to easily sweep across corners and test conditions with a live dashboard and multithreading support.

Quinn, Adam [Fermi National Accelerator Laboratory↗
DOE OSTI2018

Teaching Computational Reproducibility for Neuroimaging

We describe a project-based introduction to reproducible and collaborative neuroimaging analysis. Traditional teaching on neuroimaging usually consists of a series of lectures that emphasize the big picture rather than the foundations on which the techniques are based. The lectures are often paired with practical workshops in which students run imaging analyses using the graphical interface of specific neuroimaging software packages. Our experience suggests that this combination leaves the student with a superficial understanding of the underlying ideas, and an informal, inefficient, and inaccurate approach to analysis. To address these problems, we based our course around a substantial open-ended group project. This allowed us to teach: (a) computational tools to ensure computationally reproducible work, such as the Unix command line, structured code, version control, automated testing, and code review and (b) a clear understanding of the statistical techniques used for a basic analysis of a single run in an MR scanner. The emphasis we put on the group project showed the importance of standard computational tools for accuracy, efficiency, and collaboration. The projects were broadly successful in engaging students in working reproducibly on real scientific questions. We propose that a course on this model should be the foundation for future programs in neuroimaging. We believe it will also serve as a model for teaching efficient and reproducible research in other fields of computational science.

60 APPLIED LIFE SCIENCES↗
NASA NTRS1994

Earth Observing System/Advanced Microwave Sounding Unit-A (EOS/AMSU-A): Software concept document

This document presents the concept for two separate but closely related software systems. The first is the special test equipment (STE) software used at Aerojet for AMSU-A instrument testing, and the second is the workstation software used at the spacecraft integration facility to monitor the AMSU-A instrument when installed on the spacecraft. The primary use of the STE software is to monitor the data output from the AMSU-A instruments, to command the instruments, and to perform automated thermal-vacuum calibration testing. The primary use of the workstation software is to monitor the AMSU-A instrument's performance through an Ethernet link during the instrument/spacecraft integration process.

Schwantje, Robert↗
NASA NTRS1998

Automated Planning and Scheduling for Goal-Based Autonomous Spacecraft

Automated planning and scheduling technology - we'll call it automated planning systems, for the sake of brevity-is applicable to a wide spectrum of spaceflight missions, from those with limited onboard computational capabilities, such as Lunar Prospector, to those with highly sophisticated software, such as Cassini.

automated planning systems command mission operati↗
NASA NTRS2005

Software for Automation of Real-Time Agents, Version 2

Version 2 of Closed Loop Execution and Recovery (CLEaR) has been developed. CLEaR is an artificial intelligence computer program for use in planning and execution of actions of autonomous agents, including, for example, Deep Space Network (DSN) antenna ground stations, robotic exploratory ground vehicles (rovers), robotic aircraft (UAVs), and robotic spacecraft. CLEaR automates the generation and execution of command sequences, monitoring the sequence execution, and modifying the command sequence in response to execution deviations and failures as well as new goals for the agent to achieve. The development of CLEaR has focused on the unification of planning and execution to increase the ability of the autonomous agent to perform under tight resource and time constraints coupled with uncertainty in how much of resources and time will be required to perform a task. This unification is realized by extending the traditional three-tier robotic control architecture by increasing the interaction between the software components that perform deliberation and reactive functions. The increase in interaction reduces the need to replan, enables earlier detection of the need to replan, and enables replanning to occur before an agent enters a state of failure.

Fisher, Forest↗
NASA NTRS2007

Integrating Automation into a Multi-Mission Operations Center

NASA Goddard Space Flight Center's Space Science Mission Operations (SSMO) Project is currently tackling the challenge of minimizing ground operations costs for multiple satellites that have surpassed their prime mission phase and are well into extended mission. These missions are being reengineered into a multi-mission operations center built around modern information technologies and a common ground system infrastructure. The effort began with the integration of four SMEX missions into a similar architecture that provides command and control capabilities and demonstrates fleet automation and control concepts as a pathfinder for additional mission integrations. The reengineered ground system, called the Multi-Mission Operations Center (MMOC), is now undergoing a transformation to support other SSMO missions, which include SOHO, Wind, and ACE. This paper presents the automation principles and lessons learned to date for integrating automation into an existing operations environment for multiple satellites.

Surka, Derek M.↗
NASA NTRSDate not supplied

Design and Applications of Tethered Spacecraft Simulators

Small, tethered spacecraft, or space tugs, are a promising space capability. They can be deployed on tethers and used for a wide variety of in-space activities; a large portion of which fall under in-space servicing, assembly, manufacturing (ISAM) functions. This includes functions such as structural mating and assembly, servicing, proximity operations, capture, docking, mating, and relocation. However, there is a great deal of work to be done to raise the Technology Readiness Level (TRL) of the capabilities needed to fully realize these capabilities. The Flat Floor Robotics Lab (FFRL) at NASA’s Marshall Spaceflight Center (MSFC) has been working on space tug development for several years. The eponymous floor is 44 by 86 feet, made from a self-leveling epoxy. This creates an extremely smooth surface that air bearings can float on with very little friction, creating a simulation of zero gravity in a two-dimensional plane. The lab has several platforms of various sizes that act as vehicle simulators for testing sensors, control algorithms, mechanisms, etc. One of these platforms is a small spacecraft simulator, which can be tethered to simulate a space tug. In the last several months, the FFRL team has been working with MSFC’s welding group to conduct a laser beam welding demonstration on air bearing platforms. This demo is utilizing a space tug simulator to fly up to a floating weld platform, where two parts are clamped together and laser welded. The space tug simulator has an air bearing to provide float, as well as several actuated air thrusters to provide propulsion and make the simulator maneuverable. Currently, flights of this simulator are completed by a human operator. An RF hand controller sends signals to both actuate and fire three sets of thrusters on the simulator. This makes any maneuvers of the space tug highly subject to human error, and operators must have dedicated practice time before being able to perform maneuvers with any sufficient reliability. For the current laser welding demonstration, human operated performance is sufficient, but future implementations of in-space welding and other ISAM efforts will require higher precision, reliability, and autonomy. MSFC has funded a project that will allow a small team in the FFRL to develop the next generation of space tug simulator, which will be automated. Closed loop control will allow a user to command a position, or set of positions, that the simulator will be able to “fly” to on its own. This Maneuverable Automated Tethered Spacecraft (MATS) simulator will have configurable design, to allow a variety of payloads and mission configurations to be demonstrated on the air bearing floor. This will be an invaluable test bed for low and mid TRL advancement for space tether mission subsystems, such as more advanced demonstrations of in-space welding. Once one MATSS is constructed and demonstrated effectively, several more can be built, enabling more advanced tether missions; Electric Sail test beds, sensor arrays, and other science-enabling missions. This paper will detail the design and test of the FFRL’s MATS simulator, including efforts to establish closed loop control and autonomous capabilities. It will also detail use cases for this technology, and how it will further develop both develop science and exploration missions.

Space Tethers↗
NASA NTRS1982

Space station automation and autonomy - Advantages and problems

Design guidelines and functional systems being considered in the process of defining the configuration of the automated systems for a manned space station are outlined. The requirements are dependent on life-cycle costing and will set the necessary level of automation, as well as autonomy from outside commands. Fault protection routines have been largely devised according to successful programming on the Voyager spacecraft. An analysis is still needed of the housekeeping functions, including human necessities, machine functions, and mission objectives. A data base will result, defining the functions that have historically been delegated to either man or machine. Care must be taken to coordinate and document stationkeeping functions that might interface with mission functions. A data management system that is flexible with regards to changing mission objectives and to the MTBF factors, which will determine the level of technology to be used is required. Expert systems will be integrated into the automation to guide the machines in problem solving, including ensuring adequate management of the battery subsystem.

Carlisle, R. F.↗
NASA NTRS2015

Attitude Design for the LADEE Mission

The Lunar Atmosphere and Dust Environment Explorer (LADEE) satellite successfully completed its 148-day science investigation in a low-altitude, near-equatorial lunar orbit on April 18, 2014. The LADEE spacecraft was built, managed and operated by NASA's Ames Research Center (ARC). The Mission Operations Center (MOC) was located at Ames and was responsible for activity planning, command sequencing, trajectory and attitude design, orbit determination, and spacecraft operations. The Science Operations Center (SOC) was located at Goddard Space Flight Center and was responsible for science planning, data archiving and distribution. This paper details attitude design and operations support for the LADEE mission. LADEE's attitude design was shaped by a wide range of instrument pointing requirements that necessitated regular excursions from the baseline one revolution per orbit "Ram" attitude. Such attitude excursions were constrained by a number of flight rules levied to protect instruments from the Sun, avoid geometries that would result in simultaneous occlusion of LADEE's two star tracker heads, and maintain the spacecraft within its thermal and power operating limits. To satisfy LADEE's many attitude requirements and constraints, a set of rules and conventions was adopted to manage the complexity of this design challenge and facilitate the automation of ground software that generated pointing commands spanning multiple days of operations at a time. The resulting LADEE Flight Dynamics System (FDS) that was developed used Visual Basic scripts that generated instructions to AGI's Satellite Tool Kit (STK) in order to derive quaternion commands at regular intervals that satisfied LADEE's pointing requirements. These scripts relied heavily on the powerful "align and constrain" capability of STK's attitude module to construct LADEE's attitude profiles and the slews to get there. A description of the scripts and the attitude modeling they embodied is provided. One particular challenge analysts faced was in the design of LADEE maneuver attitudes. A flight rule requiring pre-maneuver verification of in-flight maneuver conditions by ground operators prior to burn execution resulted in the need to accommodate long periods in the maneuver attitude. This in turn complicated efforts to satisfy star tracker interference and communication constraints in lunar orbit. In response to this challenge, a graphical method was developed and used to survey candidate rotation angles about the thrust vector. This survey method is described and an example of its use on a particular LADEE maneuver is discussed. Finally, the software and methodology used to satisfy LADEE's attitude requirements are also discussed in the context of LADEE's overall activity planning effort. In particular, the way in which strategic schedules of instrument and engineering activities were translated into actual attitude profiles at the tactical level, then converted into precise quaternion commands to achieve those pointing goals is explained. In order to reduce the risk of time-consuming re-planning efforts, this process included the generation of long-term projections of constraint violation predictions for individual attitude profiles that could be used to establish keep-out time-frames for particular attitude profiles. The challenges experienced and overall efficacy of both the overall LADEE ground system and the attitude components of the Flight Dynamics System in meeting LADEE's varied pointing requirements are discussed.

LADEE↗
NASA NTRS1994

Test/score/report: Simulation techniques for automating the test process

A Test/Score/Report capability is currently being developed for the Transportable Payload Operations Control Center (TPOCC) Advanced Spacecraft Simulator (TASS) system which will automate testing of the Goddard Space Flight Center (GSFC) Payload Operations Control Center (POCC) and Mission Operations Center (MOC) software in three areas: telemetry decommutation, spacecraft command processing, and spacecraft memory load and dump processing. Automated computer control of the acceptance test process is one of the primary goals of a test team. With the proper simulation tools and user interface, the task of acceptance testing, regression testing, and repeatability of specific test procedures of a ground data system can be a simpler task. Ideally, the goal for complete automation would be to plug the operational deliverable into the simulator, press the start button, execute the test procedure, accumulate and analyze the data, score the results, and report the results to the test team along with a go/no recommendation to the test team. In practice, this may not be possible because of inadequate test tools, pressures of schedules, limited resources, etc. Most tests are accomplished using a certain degree of automation and test procedures that are labor intensive. This paper discusses some simulation techniques that can improve the automation of the test process. The TASS system tests the POCC/MOC software and provides a score based on the test results. The TASS system displays statistics on the success of the POCC/MOC system processing in each of the three areas as well as event messages pertaining to the Test/Score/Report processing. The TASS system also provides formatted reports documenting each step performed during the tests and the results of each step. A prototype of the Test/Score/Report capability is available and currently being used to test some POCC/MOC software deliveries. When this capability is fully operational it should greatly reduce the time necessary to test a POCC/MOC software delivery, as well as improve the quality of the test process.

Hageman, Barbara H.↗