Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “sequencing commanding operations”

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 NTRS2013

Multi-User Space Link Extension (SLE) System

The Multi-User Space (MUS) Link Extension system, a software and data system, provides Space Link Extension (SLE) users with three space data transfer services in timely, complete, and offline modes as applicable according to standards defined by the Consultative Committee for Space Data Systems (CCSDS). MUS radically reduces the schedule, cost, and risk of implementing a new SLE user system, minimizes operating costs with a lights-out approach to SLE, and is designed to require no sustaining engineering expense during its lifetime unless changes in the CCSDS SLE standards, combined with new provider implementations, force changes. No software modification to MUS needs to be made to support a new mission. Any systems engineer with Linux experience can begin testing SLE user service instances with MUS starting from a personal computer (PC) within five days. For flight operators, MUS provides a familiar-looking Web page for entering SLE configuration data received from SLE. Operators can also use the Web page to back up a space mission's entire set of up to approximately 500 SLE service instances in less than five seconds, or to restore or transfer from another system the same amount of data from a MUS backup file in about the same amount of time. Missions operate each MUS SLE service instance independently by sending it MUS directives, which are legible, plain ASCII strings. MUS directives are usually (but not necessarily) sent through a TCP-IP (Transmission Control Protocol Internet Protocol) socket from a MOC (Mission Operations Center) or POCC (Payload Operations Control Center) system, under scripted control, during "lights-out" spacecraft operation. MUS permits the flight operations team to configure independently each of its data interfaces; not only commands and telemetry, but also MUS status messages to the MOC. Interfaces can use single- or multiple-client TCP/IP server sockets, TCP/IP client sockets, temporary disk files, the system log, or standard in, standard out, or standard error as applicable. By defining MUS templates in ASCII, the flight operations team can include any MUS system variable in telemetry or command headers or footers, and/or in status messages. Data fields can be arranged within messages in different sequences, according to the mission s needs. The only constraints imposed are on the format of MUS directive strings, and some bare minimum logical requirements that must be met in order for MUS to read the mission control center's spacecraft command inputs. The MUS system imposes no limits or constraints on the numbers and combinations of missions and SLE service instances that it will support simultaneously. At any time, flight operators may add, change, delete, bind, connect, or disconnect.

Perkins, Toby↗
NASA NTRS2011

MSLICE Sequencing

MSLICE Sequencing is a graphical tool for writing sequences and integrating them into RML files, as well as for producing SCMF files for uplink. When operated in a testbed environment, it also supports uplinking these SCMF files to the testbed via Chill. This software features a free-form textural sequence editor featuring syntax coloring, automatic content assistance (including command and argument completion proposals), complete with types, value ranges, unites, and descriptions from the command dictionary that appear as they are typed. The sequence editor also has a "field mode" that allows tabbing between arguments and displays type/range/units/description for each argument as it is edited. Color-coded error and warning annotations on problematic tokens are included, as well as indications of problems that are not visible in the current scroll range. "Quick Fix" suggestions are made for resolving problems, and all the features afforded by modern source editors are also included such as copy/cut/paste, undo/redo, and a sophisticated find-and-replace system optionally using regular expressions. The software offers a full XML editor for RML files, which features syntax coloring, content assistance and problem annotations as above. There is a form-based, "detail view" that allows structured editing of command arguments and sequence parameters when preferred. The "project view" shows the user s "workspace" as a tree of "resources" (projects, folders, and files) that can subsequently be opened in editors by double-clicking. Files can be added, deleted, dragged-dropped/copied-pasted between folders or projects, and these operations are undoable and redoable. A "problems view" contains a tabular list of all problems in the current workspace. Double-clicking on any row in the table opens an editor for the appropriate sequence, scrolling to the specific line with the problem, and highlighting the problematic characters. From there, one can invoke "quick fix" as described above to resolve the issue. Once resolved, saving the file causes the problem to be removed from the problem view.

Crockett, Thomas M.↗
NASA NTRS2021

Concept of Operations for OSIRIS-REx Optical Navigation Image Planning

Optical navigation (OpNav) is a critical subsystem of the OSIRIS-REx asteroid sample return mission, which operated in the vicinity of near-Earth asteroid (101955) Bennu from August 2018 through April 2021. A substantial amount of mission resources across multiple subsystems and institutions is required to ensure that the OpNav data are successfully acquired. The KinetX OpNav team, part of the Flight Dynamics System (FDS), is responsible for performing required analysis to develop the OpNav operations plans; requesting, reviewing and verifying the plans; and ultimately using the image data for critical navigation operations. The FDS team, responsible for the mission navigation, is operated by KinetX Aerospace with management and operations support from NASA’s Goddard Space Flight Center. The Science Processing and Operations Center (SPOC), located at the University of Arizona’s Lunar and Planetary Laboratory, is responsible for generating the planning products for all science and most OpNav data. These plans are integrated into the spacecraft sequences, tested, and commanded by the Mission Support Area (MSA) at Lockheed Martin Space. To ensure mission-critical navigation image data are successfully acquired, the plan is developed through a waterfall of planning cycles over the course of 3 months prior to onboard plan execution. During the initial strategic planning for a mission phase, detailed analysis is performed by the OpNav team to conceptualize the concept of operations (ConOps) for image data collection. This phase OpNav Narrative is included along with other strategic planning documents for the key ground segment stakeholders to review and provide feedback. The detailed OpNav plans get defined in the tactical planning cycle, which spans 8 to 3 weeks before the week-long integrated sequence is executed on-board the spacecraft. During the tactical cycle, the initial OpNav Request is submitted along with the science requests, kicking off development of the science and OpNav plans. Once the initial plan is drafted, interfaces are exercised so that the plan can be reviewed and iterated, if necessary. A rigorous schedule is followed by the planning teams during the implementation cycle, spanning the last 18 days before uplink, to ensure all the necessary integration, testing, and reviewing can occur on time. The development of the OpNav planning ConOps, including responsibilities, interfaces, timelines, and procedures, took extensive collaboration across mission elements and institutions. The process was robust throughout the 137 weeks of continuous Optical Navigation Operations at Bennu, which concluded on April 9th, 2021.

Coralie D. Adam↗
NASA NTRS2002

Timeliner: Automating Procedures on the ISS

Timeliner has been developed as a tool to automate procedural tasks. These tasks may be sequential tasks that would typically be performed by a human operator, or precisely ordered sequencing tasks that allow autonomous execution of a control process. The Timeliner system includes elements for compiling and executing sequences that are defined in the Timeliner language. The Timeliner language was specifically designed to allow easy definition of scripts that provide sequencing and control of complex systems. The execution environment provides real-time monitoring and control based on the commands and conditions defined in the Timeliner language. The Timeliner sequence control may be preprogrammed, compiled from Timeliner "scripts," or it may consist of real-time, interactive inputs from system operators. In general, the Timeliner system lowers the workload for mission or process control operations. In a mission environment, scripts can be used to automate spacecraft operations including autonomous or interactive vehicle control, performance of preflight and post-flight subsystem checkouts, or handling of failure detection and recovery. Timeliner may also be used for mission payload operations, such as stepping through pre-defined procedures of a scientific experiment.

Brown, Robert↗
NASA NTRS2016

On the Maneuvers Operational Response for NASA’s Soil Moisture Active-Passive (SMAP) Mission

The Soil-Moisture Active-Passive (SMAP) spacecraft requires various kinds of in-orbit maneuvers over the course of its three-year mission. The types of maneuvers include pre-planned commissioning maneuvers to reach its science orbit, regularly executed orbit maintenance maneuvers to overcome drag and other nominally occurring phenomena, as well as (the possibility of) collision avoidance maneuvers. The architecture of the spacecraft – in terms of availability of commanding via ground assets, the inherited avionics' ability to sequence and execute commands, and the capability of available subsystems able to carry out maneuvers – was well defined early in the development of the spacecraft and mission, well before the operational plan for responding to maneuver requests was cemented. The systems engineering challenge became: how to accommodate all three types of maneuvers in the confines of this well-defined architecture. This paper will describe how the operations team on SMAP successfully met this challenge. Specifically, it will dive into the three pronged approach that SMAP developed to handle each type of maneuver described above – to meet the timeliness requirements leveraged on the operations team to execute said maneuvers, while continuing to fit within the allotted staffing profile during nominal operations. Defining this paradigm to fit the mission’s architecture meant re-defining the original paradigm, (planned maneuvers being thought of separately than collision avoidance maneuvers), and re-classifying all responses to maneuver requests as variations and permutations of a singular operational response to a maneuver request. This paper will also describe the tools that were created to simplify the human interface and automate as much of the response as was possible. Finally, this paper will describe, at a very high level, some of the problems encountered and lessons learned by the operations team when this process was executed the first four times during the first ninety days of operations. Though the architecture of the operations team's response to maneuver requests will never be repeated exactly, the flexibility that was inserted via redefining the scope of the problem and by redefining the human interfaces should influence future projects' architectures earlier in their development – in the hopes that said influence will save time and money in the future.

Tirona, Joseph↗
NASA NTRS2021

Robotics Instrument Deployment System Surface Operations for the InSight Mars Lander

This paper describes NASA’s first successful precision robotics instrument placement and release on another astronomical body since Apollo. This operations breakthrough enabled NASA’s InSight lander to detect the first known ‘marsquake’, a faint trembling of Mars’s surface on 6th April 2019, 128 Martian days after landing on Mars on the 26th November 2018. This is the first quake detected on an astronomical body other than Earth or the Moon. This paper describes the operations of the Robotics Instrument Deployment Systems (IDS) that successfully deployed the InSight science payload to the surface of Mars. The payload includes a seismometer (SEIS), Wind and Thermal Shield (WTS) and Heat Flow and Physical Properties Package (HP3), enabling scientists to perform the first comprehensive surface-based geophysical investigation of Mars’ interior structure. In addition, the paper describes the IDS planning and command sequence generation process used for the successful deployment of SEIS, WTS and HP3 on the surface of Mars. The paper concludes with recommendations based on the experience gained from InSight IDS operations. This includes identified technology gaps in the operations of in-situ manipulators for planetary exploration.

Yen, Jeng↗
DOE OSTI2021

MultiPhATE2: code for functional annotation and comparison of phage genomes

To address a need for improved tools for annotation and comparative genomics of bacteriophage genomes, we developed multiPhATE2. As an extension of multiPhATE, a functional annotation code released previously, multiPhATE2 performs gene finding using multiple algorithms, compares the results of the algorithms, performs functional annotation of coding sequences, and incorporates additional search algorithms and databases to extend the search space of the original code. MultiPhATE2 performs gene matching among sets of closely related bacteriophage genomes, and uses multiprocessing to speed computations. MultiPhATE2 can be re-started at multiple points within the workflow to allow the user to examine intermediate results and adjust the subsequent computations accordingly. In addition, multiPhATE2 accommodates custom gene calls and sequence databases, again adding flexibility. MultiPhATE2 was implemented in Python 3.7 and runs as a command-line code under Linux or MAC operating systems. Full documentation is provided as a README file and a Wiki website.

59 BASIC BIOLOGICAL SCIENCES↗
NASA NTRS1975

Titan/Centaur T/C-1 post flight evaluation report

The first Titan/Centaur launch vehicle, TC-1, was launched from the Eastern Test Range Complex 41 at 09:48:01.46 hours Eastern Daylight Time on February 11, 1974. The vehicle carried a dynamic mass model of the Viking spacecraft and a SPHINX spacecraft, intended to study high voltage interactions in space. This launch was a Proof Flight of a vehicle con- figuration integrating the Air Force Titan booster and the NASA Centaur upper stage. It also was the first flight of the Centaur Standard Shroud developed for the Titan/Centaur. The countdown for the launch proceeded normally except for an additional 45 minute hold which was required to resolve a question concerning interpretation of booster hydraulic system data. The launch window opened at 09:03:00 hours Eastern Daylight Time. The vehicle was launched o on a flight azimuth of 105°. The Titan boost phase of flight was satisfactory. Solid Motor operation, Stage I and Stage II operation were normal. Venting of the Centaur Standard Shroud during ascent was successful and shroud separation and jettison was accomplished without incident. At the completion of the Titan Stage II burn, the Centaur successfully separated from the Titan. At this time, the Centaur main engines were sequenced through the first planned starting cycle but failed to achieve steady state operation. The vehicle flight control system, not sensing vehicle acceleration, commanded engine shutdown, and recycled, as programmed, through a back-up engine start attempt. The second engine start attempt was also unsuccessful. The flight control system then placed the vehicle in a coast-phase mode and the vehicle continued downrange in free fall. The vehicle was destroyed by Range Safety when the impact point was approximately 2200 nautical miles downrange, 12 minutes, 28.5 seconds after liftoff.

S. V. Szabo, Jr.↗
NASA NTRS1994

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

The Operations Engineering Lab (OEL) at JPL has developed the multimission command system as part of JPL's Advanced Multimission Operations System. The command system provides an advanced multimission environment for secure, concurrent commanding of multiple spacecraft. The command functions include real-time command generation, command translation and radiation, status reporting, some remote control of Deep Space Network antenna functions, and command file management. The mission-independent architecture has allowed easy adaptation to new flight projects and the system currently supports all JPL planetary missions (Voyager, Galileo, Magellan, Ulysses, Mars Pathfinder, and CASSINI). This paper will discuss the design and implementation of the command software, especially trade-offs and lessons learned from practical operational use. The lessons learned have resulted in a re-engineering of the command system, especially in its user interface and new automation capabilities. The redesign has allowed streamlining of command operations with significant improvements in productivity and ease of use. In addition, the new system has provided a command capability that works equally well for real-time operations and within a spacecraft testbed. 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.

Alexander, Scott↗
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 NTRS2004

Marbles for the Imagination

The end-to-end test would verify the complex sequence of events from lander separation to landing. Due to the large distances involved and the significant delay time in sending a command and receiving verification, the lander needed to operate autonomously after it separated from the orbiter. It had to sense conditions, make decisions, and act accordingly. We were flying into a relatively unknown set of conditions-a Martian atmosphere of unknown pressure, density, and consistency to land on a surface of unknown altitude, and one which had an unknown bearing strength. In order to touch down safely on Mars the lander had to orient itself for descent and entry, modulate itself to maintain proper lift, pop a parachute, jettison its aeroshell, deploy landing legs and radar, ignite a terminal descent engine, and fly a given trajectory to the surface. Once on the surface, it would determine its orientation, raise the high-gain antenna, perform a sweep to locate Earth, and begin transmitting information. It was this complicated, autonomous sequence that the end-to-end test was to simulate.

Shue, Jack↗
NASA NTRS1980

Automation of the Mark 3 field system

The software and hardware components which will enable hands off operation are described. The operation of the field system begins with the scheduling of observations. An interactive program, SKED, provides displays of mutual visibility, automatic calculation of telescope slewing times, and the ability to list and edit the schedule. The output of SKED is a schedule file containing commands in the Standard Notation for Astronomy Procedures (SNAP) language which the field system uses for controlling events during the experiment. The most important features of SNAP include sophisticated time sequencing of events, automatic logging of all commands and responses, and the ability to define often used sequences of commands as procedures. A control program, BOSS, running in an HP 1000 minicomputer, reads the SNAP commands from a schedule file and interprets them in terms of commands and requests to devices. Interactive command input is possible through the operator's display terminal. Communication with all of the Mark 3 electronics modules is done via a small general purpose interface board (a microprocessor based ASCII transceiver) which has been installed in each module. Additional devices are controlled and monitored using the IEEE 488 General Purpose Interface Bus.

Vandenbere, N. R.↗
NASA NTRS1998

A Real-Time Telemetry Simulator of the IUS Spacecraft

A real-time telemetry simulator of the IUS spacecraft has recently entered operation to train Flight Control Teams for the launch of the AXAF telescope from the Shuttle. The simulator has proven to be a successful higher fidelity implementation of its predecessor, while affirming the rapid development methodology used in its design. Although composed of COTS hardware and software, the system simulates the full breadth of the mission: Launch, Pre-Deployment-Checkout, Burn Sequence, and AXAF/IUS separation. Realism is increased through patching the system into the operations facility to simulate IUS telemetry, Shuttle telemetry, and the Tracking Station link (commands and status message).

Drews, Michael E.↗
NASA NTRS2008

FootFall: A Ground Based Operations Toolset Enabling Walking for the ATHLETE Rover

The ATHLETE (All-Terrain Hex-Limbed Extra-Terrestrial Explorer) vehicle consists of six identical, six degree of freedom limbs. FootFall is a ground tool for ATHLETE intended to provide an operator with integrated situational awareness, terrain reconstruction, stability and safety analysis, motion planning, and decision support capabilities to enable the efficient generation of flight software command sequences for walking. FootFall has been under development at NASA Ames for the last year, and having accomplished the initial integration, it is being used to generate command sequences for single footfalls. In this paper, the architecture of FootFall in its current state will be presented, results from the recent Human Robotic Systems Project?s Integrated Field Test (Moses Lake, Washington, June, 2008) will be discussed, and future plans for extending the capabilities of FootFall to enable ATHLETE to walk across a boulder field in real time will be described.

SunSpiral, Vytas↗
NASA NTRS2013

Sample Analysis at Mars Instrument Simulator

The Sample Analysis at Mars Instrument Simulator (SAMSIM) is a numerical model dedicated to plan and validate operations of the Sample Analysis at Mars (SAM) instrument on the surface of Mars. The SAM instrument suite, currently operating on the Mars Science Laboratory (MSL), is an analytical laboratory designed to investigate the chemical and isotopic composition of the atmosphere and volatiles extracted from solid samples. SAMSIM was developed using Matlab and Simulink libraries of MathWorks Inc. to provide MSL mission planners with accurate predictions of the instrument electrical, thermal, mechanical, and fluid responses to scripted commands. This tool is a first example of a multi-purpose, full-scale numerical modeling of a flight instrument with the purpose of supplementing or even eliminating entirely the need for a hardware engineer model during instrument development and operation. SAMSIM simulates the complex interactions that occur between the instrument Command and Data Handling unit (C&DH) and all subsystems during the execution of experiment sequences. A typical SAM experiment takes many hours to complete and involves hundreds of components. During the simulation, the electrical, mechanical, thermal, and gas dynamics states of each hardware component are accurately modeled and propagated within the simulation environment at faster than real time. This allows the simulation, in just a few minutes, of experiment sequences that takes many hours to execute on the real instrument. The SAMSIM model is divided into five distinct but interacting modules: software, mechanical, thermal, gas flow, and electrical modules. The software module simulates the instrument C&DH by executing a customized version of the instrument flight software in a Matlab environment. The inputs and outputs to this synthetic C&DH are mapped to virtual sensors and command lines that mimic in their structure and connectivity the layout of the instrument harnesses. This module executes, and thus validates, complex command scripts prior to their up-linking to the SAM instrument. As an output, this module generates synthetic data and message logs at a rate that is similar to the actual instrument.

Benna, Mehdi↗
NASA NTRS1993

Toward an Autonomous Feature-based Pointing System for Planetary Missions

Although the analytical groundwork for understanding two-dimensional object images and various aspects of computer vision has been laid, we have not yet applied these concepts to automating the process of obtaining science images during space exploration missions. Our current approach in specifying pointing-command sequences relies heavily on target predicts, based on predicted target and spacecraft ephemerides, that propagate the target position as a function of time during pointing operations.

Computer↗