Search NASA⌕ Search

SEARCH · Search NASA

Results for “sequencing mission operations system”

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 163 records · Page 9

Operational Experience with Autonomous Star Trackers on ESA Interplanetary Spacecraft

Mars Express (MEX), Rosetta and Venus Express (VEX) are ESA interplanetary spacecrafts (S/C) launched in June 2003, March 2004 and November 2005, respectively. Mars Express was injected into Mars orbit end of 2003 with routine operations starting in spring 2004. Rosetta is since launch on its way to rendezvous comet Churyumov-Gerasimenko in 2014. It has completed several test and commissioning activities and is performing several planetary swingbys (Earth in spring 2005, Mars in spring 2007, Earth in autumn 2007 and again two years later). Venus Express has also started routine operations since the completion of the Venus orbit insertion maneuver sequence beginning of May 2006. All three S/C are three axes stabilized with a similar attitude and orbit control system (AOCS). The attitude is estimated on board using star and rate sensors and controlled using four reaction wheels. A bipropellant reaction control system with 10N thrusters serves for wheel off loadings and attitude control in safe mode. Mars Express and Venus Express have an additional 400N engine for the planetary orbit insertion. Nominal Earth communication is accomplished through a high gain antenna. All three S/C are equipped with a redundant set of autonomous star trackers (STR) which are based on almost the same hardware. The STR software is especially adapted for the respective mission. This paper addresses several topics related to the experience gained with the STR operations on board the three S/C so far.

Lauer, Mathias↗

Metrics for Flight Operations: Application to Europa Clipper Tour Selection

Objective measures are ubiquitous in the formulation, design and implementation of deep space missions. Tour durations, flyby altitudes, propellant budgets, power consumption, and other metrics are essential to developing and managing NASA missions. But beyond the simple metrics of cost and workforce, it has been difficult to identify objective, quantitative measures that assist in evaluating choices made during formulation or implementation phases in terms of their impact on flight operations. As part of the development of the Europa Clipper Mission system, a set of operations metrics have been defined along with the necessary design information and software tooling to calculate them. We have applied these methods and metrics to help assess the impact to the flight team on the six options for the Clipper Tour that are currently being vetted for selection in the fall of 2021. To generate these metrics, the Clipper MOS team first designed the set of essential processes by which flight operations will be conducted, using a standard approach and template to identify (among other aspects) timelines for each process, along with their time constraints (e.g., uplinks for sequence execution). Each of the resulting 50 processes is documented in a common format and concurred by stakeholders. Process timelines were converted into generic schedules and workforce-loaded using COTS scheduling software, based on the inputs of the process authors and domain experts. Custom code was generated to create an operations schedule for a specific portion of Clipper's prime mission, with instances of a given process scheduled based on specific timing rules (e.g., process X starts once per week on Thursdays) or relative to mission events (e.g., sequence generation process begins on a Monday, at least three weeks before each Europa closest approach). Over a 5-month period, and for each of six Clipper candidate tours, the result was a 20,000+ line, workforce-loaded schedule that documents all of the process-driven work effort at the level of individual roles, along with a significant portion of the level-of-effort work. Post-processing code calculated the absolute and relative number of work hours during a nominal 5 day / 40 hour work week, the work effort during 2nd and 3rd shift, as well as 1st shift on weekends. The resultant schedules and shift tables were used to generate objective measures that can be related to both human factors and to operational risk and showed that Clipper tours which utilize 6:1 resonant (21.25 day) orbits instead of 4:1 resonant (14.17 day) orbits during the first dozen or so Europa flybys are advantageous to flight operations. A similar approach can be extended to assist missions in more objective assessments of a number of mission issues and trades, including tour selection and spacecraft design for operability.

Sarrel, Marc↗

A Comparison Between Orion Automated and Space Shuttle Rendezvous Techniques

The Orion spacecraft will replace the space shuttle and will be the first human spacecraft since the Apollo program to leave low earth orbit. This vehicle will serve as the cornerstone of a complete space transportation system with a myriad of mission requirements necessitating rendezvous to multiple vehicles in earth orbit, around the moon and eventually beyond . These goals will require a complex and robust vehicle that is, significantly different from both the space shuttle and the command module of the Apollo program. Historically, orbit operations have been accomplished with heavy reliance on ground support and manual crew reconfiguration and monitoring. One major difference with Orion is that automation will be incorporated as a key element of the man-vehicle system. The automated system will consist of software devoted to transitioning between events based on a master timeline. This effectively adds a layer of high level sequencing that moves control of the vehicle from one phase to the next. This type of automated control is not entirely new to spacecraft since the shuttle uses a version of this during ascent and entry operations. During shuttle orbit operations however many of the software modes and hardware switches must be manually configured through the use of printed procedures and instructions voiced from the ground. The goal of the automation scheme on Orion is to extend high level automation to all flight phases. The move towards automation represents a large shift from current space shuttle operations, and so these new systems will be adopted gradually via various safeguards. These include features such as authority-to-proceed, manual down modes, and functional inhibits. This paper describes the contrast between the manual and ground approach of the space shuttle and the proposed automation of the Orion vehicle. I will introduce typical orbit operations that are common to all rendezvous missions and go on to describe the current Orion automation architecture and contrast it with shuttle rendezvous techniques and circumstances. The shuttle rendezvous profile is timed to take approximately 3 days from orbit insertion to docking at the International Space Station (ISS). This process can be divided into 3 phases: far-field, mid-field and proximity operations. The far-field stage is characterized as the most quiescent phase. The spacecraft is usually too far to navigate using relative sensors and uses the Inertial Measurement Units (IMU s) to numerically solve for its position. The maneuvers are infrequent, roughly twice per day, and are larger than other burns in the profile. The shuttle uses this opportunity to take extensive ground based radar updates and keep high fidelity orbit states on the ground. This state is then periodically uplinked to the shuttle computers. The targeting solutions for burn maneuvers are also computed on the ground and uplinked. During the burn the crew is responsible for setting the shuttle attitude and configuring the propulsion system for ignition. Again this entire process is manually driven by both crew and ground activity. The only automatic processes that occur are associated with the real-time execution of the burn. The Orion automated functionality will seek to relieve the workload of both the crew and ground during this phase

Ruiz, Jose O,↗

Rover Sequencing and Visualization Program

The Rover Sequencing and Visualization Program (RSVP) is the software tool for use in the Mars Exploration Rover (MER) mission for planning rover operations and generating command sequences for accomplishing those operations. RSVP combines three-dimensional (3D) visualization for immersive exploration of the operations area, stereoscopic image display for high-resolution examination of the downlinked imagery, and a sophisticated command-sequence editing tool for analysis and completion of the sequences. RSVP is linked with actual flight-code modules for operations rehearsal to provide feedback on the expected behavior of the rover prior to committing to a particular sequence. Playback tools allow for review of both rehearsed rover behavior and downlinked results of actual rover operations. These can be displayed simultaneously for comparison of rehearsed and actual activities for verification. The primary inputs to RSVP are downlink data products from the Operations Storage Server (OSS) and activity plans generated by the science team. The activity plans are high-level goals for the next day s activities. The downlink data products include imagery, terrain models, and telemetered engineering data on rover activities and state. The Rover Sequence Editor (RoSE) component of RSVP performs activity expansion to command sequences, command creation and editing with setting of command parameters, and viewing and management of rover resources. The HyperDrive component of RSVP performs 2D and 3D visualization of the rover s environment, graphical and animated review of rover-predicted and telemetered state, and creation and editing of command sequences related to mobility and Instrument Deployment Device (IDD) operations. Additionally, RoSE and HyperDrive together evaluate command sequences for potential violations of flight and safety rules. The products of RSVP include command sequences for uplink that are stored in the Distributed Object Manager (DOM) and predicted rover state histories stored in the OSS for comparison and validation of downlinked telemetry. The majority of components comprising RSVP utilize the MER command and activity dictionaries to automatically customize the system for MER activities. Thus, RSVP, being highly data driven, may be tailored to other missions with minimal effort. In addition, RSVP uses a distributed, message-passing architecture to allow multitasking, and collaborative visualization and sequence development by scattered team members.

Cooper, Brian↗

Transportation-Driven Mars Surface Operations Supporting an Evolvable Mars Campaign

This paper describes the results of a study evaluating options for supporting a series of human missions to a single Mars surface destination. In this scenario the infrastructure emplaced during previous visits to this site is leveraged in following missions. The goal of this single site approach to Mars surface infrastructure is to enable "Steady State" operations by at least 4 crew for up to 500 sols at this site. These characteristics, along with the transportation system used to deliver crew and equipment to and from Mars, are collectively known as the Evolvable Mars Campaign (EMC). Information in this paper is presented in the sequence in which it was accomplished. First, a logical buildup sequence of surface infrastructure was developed to achieve the desired "Steady State" operations on the Mars surface. This was based on a concept of operations that met objectives of the EMC. Second, infrastructure capabilities were identified to carry out this concept of operations. Third, systems (in the form of conceptual elements) were identified to provide these capabilities. This included top-level mass, power and volume estimates for these elements. Fourth, the results were then used in analyses to evaluate three options (18t, 27t, and 40t landed mass) of Mars Lander delivery capability to the surface. Finally, Mars arrival mass estimates were generated based upon the entry, descent, and landing requirements for inclusion in separate assessments of in-space transportation capabilities for the EMC.

Toups, Larry↗

Unmanned surface traverses of Mars and Moon: Science objectives, payloads, operations

Science objectives and properties to be measured are outlined for long surface traverse missions on Mars and the Moon, with remotely-controlled roving vehicles. A series of candidate rover payloads is proposed for each planet, varying in weight, cost, purpose, and development needed. The smallest weighs 35 kg; the largest almost 300 kg. A high degree of internal control will be needed on the Mars rover, including the ability to carry out complex science sequences. Decision-making by humans in the Mars mission includes supervisory control of rover operations and selection of features and samples of geological and biological interest. For the lunar mission, less control on the rover and more on earth is appropriate. Science portions of the rover mission profile are outlined, with timelines and mileage breakdowns. Operational problem areas for Mars include control, communications, data storage, night operations, and the mission operations system. For the moon, science data storage on the rover would be unnecessary and control much simpler.

Jaffe, L. D.↗

Lunar Excavator Mission Operations using Dynamic Movement Primitives

To support sustainable infrastructure on the Moon, NASA must leverage robots to extract lunar resources for in-situ processing and construction. As part of this effort, NASA is launching the in-situ resource utilization (ISRU) Pilot Excavator later this decade to validate a robotic regolith excavator based on the Regolith Advanced Surface Systems Operations Robot (RASSOR). RASSOR is designed to extract and transport regolith to meet the needs of ISRU architectures. During its mission, Pilot Excavator will be tasked with driving in test patterns to demonstrate the operational concept. One of these tests is a circular trajectory around the lander while avoiding miscellaneous surface hazards such as lunar rocks. To this end, we utilize dynamic movement primitives to represent navigation sequences as primitive trajectories. Here, we introduce a novel obstacle avoidance parameter, which is configured to avoid rocks throughout testing exercises. We demonstrate the effectiveness our method in a newly developed simulation tool called the Simulated Excavation Environment for Lunar Operations (SEELO) using models based on the NASA RASSOR 2.0 excavator. After making key changes to the obstacle avoidance formulation, our results show that the robot is able to safety and robustly navigate the lunar surface with densely populated rock obstacles while retaining the desired circle pattern behavior.

Space Robotics and Automation↗

Viking adaptive mission sequence and control operations

Viking mission operations were required to provide an adaptive sequencing capability in which future observations could be influenced by the latest information about Mars as it was obtained and analyzed. The mission operations strategy that was developed met this requirement and provided the capability to respond smoothly and efficiently to spacecraft subsystem anomalies with minimum impact on the science data gathering process. A description of the major elements of this adaptive man-in-the-loop control system is provided. Specific cases showing how it was utilized to enhance scientific return and to respond to spacecraft anomalies are also provided.

Larman, B. T.↗

HELIOS Third Joint Working Group Meeting

During the past six months since the Second Helios Joint Working Group Meeting held 27-30 April 1970 at Goddard Space Flight Center, the TDS Sub-Group supported the Helios Project Office and the other Sub-Groups in the timely disposition of action items and the dissemination of information pertinent to the development of interface documentation. Of particular importance during this time period was the Project's decision to incorporate a single-channel telemetry system design aboard the spacecraft. The TDS Sub-Group participated actively in the process that led to this decision. Still under active study with TDS participation is the pending Project Office decision regarding the incorporation of a ranging capability within the telecommunications design. The TDS Sub-Group assisted the Mission Analysis and Operations Sub-Group in establishment of a study effort concerning the Near-Earth Sequence of Events from launch to launch plus 8 hours. This study, which will provide valuable data for the spacecraft telecommunications design, will include participation by the Experiment, Launch Vehicle, Spacecraft, as well as the TDS and MA&O Sub-Groups. Also during the past 6-month period, the TDS, in conjunction with the Spacecraft Sub-Group, initiated activity to develop the Helios Spacecraft/TDS Compatibility Test Plans and Procedures. Activity concerning the foregoing interface discussions has been and will continue to be based upon the "TDS Estimated Capabilities Document for the Helios Missions" (613-1), and the "DSN/Flight Project Interface Design Handbook" (810-5). These will continue to be considered TDS controlling documents until specific Helios Project/TDS interface documentation is generated and signed off by the respective parties. In addition to the above, the DSN continued the Helios Trainee Program with seven GfW/DFVLR trainees in residence at JPL. Two trainees will complete their year's residency concurrent with the Third Helios Joint Working Group Meeting, while four new trainees are expected to arrive following the Third Helios Joint Working Group Meeting. These and other activities are reported in detail in the paragraphs that follow.

Ousley, Gilbert↗

Multimission high speed spacecraft simulation for the Galileo and Cassini missions

A simulation system has been developed which is capable of bit level simulation of spacecraft data systems. Object oriented techniques and an embedded interpreted language have been employed to produce a highly configurable tool for control and viewing of spacecraft states. Parallel processing computers have been used for running simulations to achieve execution performance of up to ten times real time, which allows for effective utilization of the simulator in testing spacecraft command sequences before they are committed to operation. Elements of simulations can be reused as-is in the construction of new simulators.

Morrissett, Alan↗

Plasma Sheath Behavior of the ProSEDS Delta II

The Propulsive Small Expendable Deployer System (ProSEDS) mission is a demonstration of the orbit lowering capabilities of an electrodynamic tether. The system is sequenced through various electrical modes, involving both open circuit and closed circuit configurations, so that the performance capabilities of the system can be studied. Ionospheric electrons are collected on the upper end of the bare tether, conducted through the tether, and returned to the ionosphere at the lower end (Delta I1 2nd stage) via the operation of a Hollow Cathode Plasma Contactor (HCPC). The working gas of the HCPC is xenon. Environmental plasma measurements and sheath potential are obtained from the Differential Ion Flux Probe w/Mass Analysis (DIFPM) and Langmuir Probe and Spacecraft Potential (LPSP) instruments. Each instrument has three sensors symmetrically placed about the strut section of the Delta 2nd stage. A magnetometer is also included in the ProSEDS instrumentation suite. An initial analysis of the rocket stage sheath behavior as a function of ProSEDS configuration (open or closed circuit), ambient ionospheric density, orientation to velocity vector (ram-wake influence), and magnetic field orientation is presented. An initial assessment on how well the plasma contactor grounded the rocket stage is also presented.

Wright, K. H.↗

Aquarius Digital Processing Unit

Three documents provide information on a digital processing unit (DPU) for the planned Aquarius mission, in which a radiometer aboard a spacecraft orbiting Earth is to measure radiometric temperatures from which data on sea-surface salinity are to be deduced. The DPU is the interface between the radiometer and an instrument-command-and-data system aboard the spacecraft. The DPU cycles the radiometer through a programmable sequence of states, collects and processes all radiometric data, and collects all housekeeping data pertaining to operation of the radiometer. The documents summarize the DPU design, with emphasis on innovative aspects that include mainly the following: a) In the radiometer and the DPU, conversion from analog voltages to digital data is effected by means of asynchronous voltage-to-frequency converters in combination with a frequency-measurement scheme implemented in field-programmable gate arrays (FPGAs). b) A scheme to compensate for aging and changes in the temperature of the DPU in order to provide an overall temperature-measurement accuracy within 0.01 K includes a high-precision, inexpensive DC temperature measurement scheme and a drift-compensation scheme that was used on the Cassini radar system. c) An interface among multiple FPGAs in the DPU guarantees setup and hold times.

Forgione, Joshua↗

Leveraging Existing Mission Tools in a Re-Usable, Component-Based Software Environment

Emerging methods in component-based software development offer significant advantages but may seem incompatible with existing mission operations applications. In this paper we relate our positive experiences integrating existing mission applications into component-based tools we are delivering to three missions. In most operations environments, a number of software applications have been integrated together to form the mission operations software. In contrast, with component-based software development chunks of related functionality and data structures, referred to as components, can be individually delivered, integrated and re-used. With the advent of powerful tools for managing component-based development, complex software systems can potentially see significant benefits in ease of integration, testability and reusability from these techniques. These benefits motivate us to ask how component-based development techniques can be relevant in a mission operations environment, where there is significant investment in software tools that are not component-based and may not be written in languages for which component-based tools even exist. Trusted and complex software tools for sequencing, validation, navigation, and other vital functions cannot simply be re-written or abandoned in order to gain the advantages offered by emerging component-based software techniques. Thus some middle ground must be found. We have faced exactly this issue, and have found several solutions. Ensemble is an open platform for development, integration, and deployment of mission operations software that we are developing. Ensemble itself is an extension of an open source, component-based software development platform called Eclipse. Due to the advantages of component-based development, we have been able to vary rapidly develop mission operations tools for three surface missions by mixing and matching from a common set of mission operation components. We have also had to determine how to integrate existing mission applications for sequence development, sequence validation, and high level activity planning, and other functions into a component-based environment. For each of these, we used a somewhat different technique based upon the structure and usage of the existing application.

Greene, Kevin↗

Flat Surface Damage Detection System (FSDDS)

The Flat Surface Damage Detection system (FSDDS} is a sensory system that is capable of detecting impact damages to surfaces utilizing a novel sensor system. This system will provide the ability to monitor the integrity of an inflatable habitat during in situ system health monitoring. The system consists of three main custom designed subsystems: the multi-layer sensing panel, the embedded monitoring system, and the graphical user interface (GUI). The GUI LABVIEW software uses a custom developed damage detection algorithm to determine the damage location based on the sequence of broken sensing lines. It estimates the damage size, the maximum depth, and plots the damage location on a graph. Successfully demonstrated as a stand alone technology during 2011 D-RATS. Software modification also allowed for communication with HDU avionics crew display which was demonstrated remotely (KSC to JSC} during 2012 integration testing. Integrated FSDDS system and stand alone multi-panel systems were demonstrated remotely and at JSC, Mission Operations Test using Space Network Research Federation (SNRF} network in 2012. FY13, FSDDS multi-panel integration with JSC and SNRF network Technology can allow for integration with other complementary damage detection systems.

Williams, Martha↗

Science opportunity analyzer - a multi-mission tool for planning

For many years the diverse scientific community that supports JPL's wide variety ofinterplanetary space missions has needed a tool in order to plan and develop their experiments. The tool needs to be easily adapted to various mission types and portable to the user community. The Science Opportunity Analyzer, SOA, now in its third year of development, is intended to meet this need. SOA is a java-based application that is designed to enable scientists to identify and analyze opportunities for science observations from spacecraft. It differs from other planning tools in that it does not require an in-depth knowledge of the spacecraft command system or operation modes to begin high level planning. Users can, however, develop increasingly detailed levels of design. SOA consists of six major functions: Opportunity Search, Visualization, Observation Design, Constraint Checking, Data Output and Communications. Opportunity Search is a GUI driven interface to existing search engines that can be used to identify times when a spacecraft is in a specific geometrical relationship with other bodies in the solar system. This function can be used for advanced mission planning as well as for making last minute adjustments to mission sequences in response to trajectory modifications. Visualization is a key aspect of SOA. The user can view observation opportunities in either a 3D representation or as a 2D map projection. The user is given extensive flexibility to customize what is displayed in the view. Observation Design allows the user to orient the spacecraft and visualize the projection of the instrument field of view for that orientation using the same views as Opportunity Search. Constraint Checking is provided to validate various geometrical and physical aspects of an observation design. The user has the ability to easily create custom rules or to use official project-generated flight rules. This capability may also allow scientists to easily impact the cost to science if flight rule changes occur. Data Output generates information based on the spacecraft's trajectory, opportunity search results or based on a created observation. The data can be viewed either in tabular format or as a graph. Finally, SOA is unique in that it is designed to be able to communicate with a variety of existing planning and sequencing tools. From the very beginning SOA was designed with the user in mind. Extensive surveys of the potential user community were conducted in order to develop the software requirements. Throughout the development period, close ties have been maintained with the science community to insure that the tool maintains its user focus. Although development is still in its early stages, SOA is already developing a user community on the Cassini project, which is depending on this tool for their science planning. There are other tools at JPL that do various pieces of what SOA can do; however, there is no other tool which combines all these functions and presents them to the user in such a convenient, cohesive, and easy to use fashion.

SOA science planning mission operations sequence s↗

Parallel Processing Systems for Passive Ranging During Helicopter Flight

The complexity of rotorcraft missions involving operations close to the ground result in high pilot workload. In order to allow a pilot time to perform mission-oriented tasks, sensor-aiding and automation of some of the guidance and control functions are highly desirable. Images from an electro-optical sensor provide a covert way of detecting objects in the flight path of a low-flying helicopter. Passive ranging consists of processing a sequence of images using techniques based on optical low computation and recursive estimation. The passive ranging algorithm has to extract obstacle information from imagery at rates varying from five to thirty or more frames per second depending on the helicopter speed. We have implemented and tested the passive ranging algorithm off-line using helicopter-collected images. However, the real-time data and computation requirements of the algorithm are beyond the capability of any off-the-shelf microprocessor or digital signal processor. This paper describes the computational requirements of the algorithm and uses parallel processing technology to meet these requirements. Various issues in the selection of a parallel processing architecture are discussed and four different computer architectures are evaluated regarding their suitability to process the algorithm in real-time. Based on this evaluation, we conclude that real-time passive ranging is a realistic goal and can be achieved with a short time.

Sridhar, Bavavar↗

Visible Nulling Coronagraphy Testbed Development for Exoplanet Detection

Three of the recently completed NASA Astrophysics Strategic Mission Concept (ASMC) studies addressed the feasibility of using a Visible Nulling Coronagraph (VNC) as the prime instrument for exoplanet science. The VNC approach is one of the few approaches that works with filled, segmented and sparse or diluted aperture telescope systems and thus spans the space of potential ASMC exoplanet missions. NASA/Goddard Space Flight Center (GSFC) has a well-established effort to develop VNC technologies and has developed an incremental sequence of VNC testbeds to advance the this approach and the technologies associated with it. Herein we report on the continued development of the vacuum Visible Nulling Coronagraph testbed (VNT). The VNT is an ultra-stable vibration isolated testbed that operates under high bandwidth closed-loop control within a vacuum chamber. It will be used to achieve an incremental sequence of three visible light nulling milestones of sequentially higher contrasts of 10(exp 8) , 10(exp 9) and 10(exp 10) at an inner working angle of 2*lambda/D and ultimately culminate in spectrally broadband (>20%) high contrast imaging. Each of the milestones, one per year, is traceable to one or more of the ASMC studies. The VNT uses a modified Mach-Zehnder nulling interferometer, modified with a modified "W" configuration to accommodate a hex-packed MEMS based deformable mirror, a coherent fiber bundle and achromatic phase shifters. Discussed will be the optical configuration laboratory results, critical technologies and the null sensing and control approach.

Lyon, Richard G.↗

A Module for Automatic Dock and Detumble (MADD) for orbital rescue operations

The module for automatic dock and detumble (MADD) is an automated device for bringing a passive, tumbling space base under control in an orbital rescue situation. The conceptual design of such a device resulted from a consideration of tumbling motion analyses and mission constraints. Specific topics of investigation include orbit and attitude dynamics and detumble profiles. Position and attitude control systems for the various phases of operation were developed. Dynamic motion of a passive vehicle with MADD attached is considered as an example application and to determine control requirements. Since time is a critical factor in rescue operations, it is essential to execute the detumbling maneuver in a minimum of time. Optimization of the MADD thrusting sequence has also been investigated. Results indicate the control torque must be directed opposite to the angular momentum vector for the assumption used here.

Snow, W. R.↗