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 217 records · Page 12
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Methodology for Designing Fault-Protection Software

A document describes a methodology for designing fault-protection (FP) software for autonomous spacecraft. The methodology embodies and extends established engineering practices in the technical discipline of Fault Detection, Diagnosis, Mitigation, and Recovery; and has been successfully implemented in the Deep Impact Spacecraft, a NASA Discovery mission. Based on established concepts of Fault Monitors and Responses, this FP methodology extends the notion of Opinion, Symptom, Alarm (aka Fault), and Response with numerous new notions, sub-notions, software constructs, and logic and timing gates. For example, Monitor generates a RawOpinion, which graduates into Opinion, categorized into no-opinion, acceptable, or unacceptable opinion. RaiseSymptom, ForceSymptom, and ClearSymptom govern the establishment and then mapping to an Alarm (aka Fault). Local Response is distinguished from FP System Response. A 1-to-n and n-to- 1 mapping is established among Monitors, Symptoms, and Responses. Responses are categorized by device versus by function. Responses operate in tiers, where the early tiers attempt to resolve the Fault in a localized step-by-step fashion, relegating more system-level response to later tier(s). Recovery actions are gated by epoch recovery timing, enabling strategy, urgency, MaxRetry gate, hardware availability, hazardous versus ordinary fault, and many other priority gates. This methodology is systematic, logical, and uses multiple linked tables, parameter files, and recovery command sequences. The credibility of the FP design is proven via a fault-tree analysis "top-down" approach, and a functional fault-mode-effects-and-analysis via "bottoms-up" approach. Via this process, the mitigation and recovery strategy(s) per Fault Containment Region scope (width versus depth) the FP architecture.

Barltrop, Kevin↗
NASA NTRS2006

NASA Tech Briefs, September 2006

Topics covered include: Improving Thermomechanical Properties of SiC/SiC Composites; Aerogel/Particle Composites for Thermoelectric Devices; Patches for Repairing Ceramics and Ceramic- Matrix Composites; Lower-Conductivity Ceramic Materials for Thermal-Barrier Coatings; An Alternative for Emergency Preemption of Traffic Lights; Vehicle Transponder for Preemption of Traffic Lights; Automated Announcements of Approaching Emergency Vehicles; Intersection Monitor for Traffic-Light-Preemption System; Full-Duplex Digital Communication on a Single Laser Beam; Stabilizing Microwave Frequency of a Photonic Oscillator; Microwave Oscillators Based on Nonlinear WGM Resonators; Pointing Reference Scheme for Free-Space Optical Communications Systems; High-Level Performance Modeling of SAR Systems; Spectral Analysis Tool 6.2 for Windows; Multi-Platform Avionics Simulator; Silicon-Based Optical Modulator with Ferroelectric Layer; Multiplexing Transducers Based on Tunnel-Diode Oscillators; Scheduling with Automated Resolution of Conflicts; Symbolic Constraint Maintenance Grid; Discerning Trends in Performance Across Multiple Events; Magnetic Field Solver; Computing for Aiming a Spaceborne Bistatic- Radar Transmitter; 4-Vinyl-1,3-Dioxolane-2-One as an Additive for Li-Ion Cells; Probabilistic Prediction of Lifetimes of Ceramic Parts; STRANAL-PMC Version 2.0; Micromechanics and Piezo Enhancements of HyperSizer; Single-Phase Rare-Earth Oxide/Aluminum Oxide Glasses; Tilt/Tip/Piston Manipulator with Base-Mounted Actuators; Measurement of Model Noise in a Hard-Wall Wind Tunnel; Loci-STREAM Version 0.9; The Synergistic Engineering Environment; Reconfigurable Software for Controlling Formation Flying; More About the Tetrahedral Unstructured Software System; Computing Flows Using Chimera and Unstructured Grids; Avoiding Obstructions in Aiming a High-Gain Antenna; Analyzing Aeroelastic Stability of a Tilt-Rotor Aircraft; Tracking Positions and Attitudes of Mars Rovers; Stochastic Evolutionary Algorithms for Planning Robot Paths; Compressible Flow Toolbox; Rapid Aeroelastic Analysis of Blade Flutter in Turbomachines; General Flow-Solver Code for Turbomachinery Applications; Code for Multiblock CFD and Heat-Transfer Computations; Rotating-Pump Design Code; Covering a Crucible with Metal Containing Channels; Repairing Fractured Bones by Use of Bioabsorbable Composites; Kalman Filter for Calibrating a Telescope Focal Plane; Electronic Absolute Cartesian Autocollimator; Fiber-Optic Gratings for Lidar Measurements of Water Vapor; Simulating Responses of Gravitational-Wave Instrumentation; SOFTC: A Software Correlator for VLBI; Progress in Computational Simulation of Earthquakes; Database of Properties of Meteors; Computing Spacecraft Solar-Cell Damage by Charged Particles; Thermal Model of a Current-Carrying Wire in a Vacuum; Program for Analyzing Flows in a Complex Network; Program Predicts Performance of Optical Parametric Oscillators; Processing TES Level-1B Data; Automated Camera Calibration; Tracking the Martian CO2 Polar Ice Caps in Infrared Images; Processing TES Level-2 Data; SmaggIce Version 1.8; Solving the Swath Segment Selection Problem; The Spatial Standard Observer; Less-Complex Method of Classifying MPSK; Improvement in Recursive Hierarchical Segmentation of Data; Using Heaps in Recursive Hierarchical Segmentation of Data; Tool for Statistical Analysis and Display of Landing Sites; Automated Assignment of Proposals to Reviewers; Array-Pattern-Match Compiler for Opportunistic Data Analysis; Pre-Processor for Compression of Multispectral Image Data; Compressing Image Data While Limiting the Effects of Data Losses; Flight Operations Analysis Tool; Improvement in Visual Target Tracking for a Mobile Robot; Software for Simulating Air Traffic; Automated Vectorization of Decision-Based Algorithms; Grayscale Optical Correlator Workbench; "One-Stop Shopping" for Ocean Remote-Sensing and Model Data; State Analysis Database Tool; Generating CAHV and CAHVOmages with Shadows in ROAMS; Improving UDP/IP Transmission Without Increasing Congestion; FORTRAN Versions of Reformulated HFGMC Codes; Program for Editing Spacecraft Command Sequences; Flight-Tested Prototype of BEAM Software; Mission Scenario Development Workbench; Marsviewer; Tool for Analysis and Reduction of Scientific Data; ASPEN Version 3.0; Secure Display of Space-Exploration Images; Digital Front End for Wide-Band VLBI Science Receiver; Multifunctional Tanks for Spacecraft; Lightweight, Segmented, Mostly Silicon Telescope Mirror; Assistant for Analyzing Tropical-Rain-Mapping Radar Data; and Anion-Intercalating Cathodes for High-Energy- Density Cells.

Source record↗
NASA NTRS2011

Attitude Determination and Control Subsystem (ADCS) Preparations for the EPOXI Flyby of Comet Hartley 2

On November 4, 2010 the former "Deep Impact" spacecraft, renamed "EPOXI" for its extended mission, flew within 700km of comet 103P/Hartley 2. In July 2005, the spacecraft had previously imaged a probe impact of comet Tempel 1. The EPOXI flyby was the fifth close encounter of a spacecraft with a comet nucleus and marked the first time in history that two comet nuclei were imaged at close range with the same suite of onboard science instruments. This challenging objective made the function of the attitude determination and control subsystem (ADCS) critical to the successful execution of the EPOXI flyby.As part of the spacecraft flyby preparations, the ADCS operations team had to perform meticulous sequence reviews, implement complex spacecraft engineering and science activities and perform numerous onboard calibrations. ADCS contributions included design and execution of 10 trajectory correction maneuvers, the science calibration of the two telescopic instruments, an in-flight demonstration of high-rate turns between Earth and comet point, and an ongoing assessment of reaction wheel health. The ADCS team was also responsible for command sequences that included updates to the onboard ephemeris and sun sensor coefficients and implementation of reaction wheel assembly (RWA) de-saturations.

attitude determination and control↗
NASA NTRS2010

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,↗
NASA NTRS2008

VML Sequencing: Growing Capabilities over Multiple Missions

Virtual Machine Language (VML) is an award-winning advanced procedural sequencing language in use on NASA deep-space missions since 1997. Missions featuring VML include Spitzer Space Telescope, Mars Odyssey, Stardust, Genesis, Mars Reconnaissance Orbiter, Phoenix, Dawn and Juno. The latest deployed version, VML 2.0, features parameterized functions, conditionals, polymorphism, a rich set of control directives and data types, event detection and response, and on-the-fly creation of spacecraft commands. This feature set is used to simplify spacecraft operations and science gathering activities. A new 2.1 version is being prototyped for use as an executive within flight instruments, and may be deployed on Juno.

Dawn↗
NASA NTRS1996

DKRZ workload analysis

The UniTree product as it is released emits a rather large amount of logging information into various log files, but this data typically is meant for operator information in difficult operational situations or directly for debugging purposes. It is strongly advised that the existing logging functionality in the standard release is advanced by adding messages with relevant parameters for every major event in the course of executing file or device oriented requests as described. This upgrade would be relatively easy in terms of implementation effort. The benefit is a complete sequence of transaction descriptions generated by external user requests or by internal administration commands. This collection of transaction records can be used for intensive statistics and performance evaluations. It is furthermore a perfect source to drive realistic system simulations to study the effects of possible hardware or software changes.

Fichter, Hartmut↗
NASA NTRS2006

The K9 On-Board Rover Architecture

This paper describes the software architecture of NASA Ames Research Center s K9 rover. The goal of the onboard software architecture team was to develop a modular, flexible framework that would allow both high- and low-level control of the K9 hardware. Examples of low-level control are the simple drive or pan/tilt commands which are handled by the resource managers, and examples of high-level control are the command sequences which are handled by the conditional executive. In between these two control levels are complex behavioral commands which are handled by the pilot, such as drive to goal with obstacle avoidance or visually servo to a target. This paper presents the design of the architecture as of Fall 2000. We describe the state of the architecture implementation as well as its current evolution. An early version of the architecture was used for K9 operations during a dual-rover field experiment conducted by NASA Ames Research Center (ARC) and the Jet Propulsion Laboratory (JPL) from May 14 to May 16, 2000.

Bresina, John L.↗
NASA NTRS1991

Collision avoidance for CTV: Requirements and capabilities

Cargo transfer vehicle (CTV) operations near Space Station Freedom will require positive collision avoidance maneuver (CAM) capability to preclude any change of collision, even in the event of CTV failures. The requirements for CAM are discussed, and the CAM design approach and design of the Orbiting Maneuvering Vehicle (OMV) are reviewed; this design met requirements for OMV operation near the Space Station, provided a redundant collision avoidance maneuver capability. Significant portions of the OMV CAM design should be applicable to CTV. The key features of the OMV design are summarized and related to the CTV mission design to that of OMV's. CAM is a defined sequence of events executed by the CTV to place the vehicle in a safe position relative to a target such as the Space Station. CAM can be performed through software commands to the propulsion system, or through commands pre-stored in hardware. Various techniques for triggering CAM are considered, and the risks associated with CAM enable and execution in phases are considered. OMV CAM design features both hardware and software CAM capability, with analyses conducted to assess the ability to meet the collision-free requirement during all phases of the mission.

Nosek, Thomas P.↗
NASA NTRS1999

Design of the Automated Rendezvous and Capture Docking System

This paper describes the Automated Rendezvous and Capture (AR&C) system that was designed and is being tested at NASA's Marshall Space Flight Center (MSFC). The AR&C system incorporates some of the latest innovations in Global Positioning System (GPS), laser sensor technologies and automated mission sequencing algorithms as well as the capability for ground and crew monitoring and commanding. This paper summarizes the variety of mission scenarios supported by the AR&C system. It also describes the major components of the AR&C system including the Guidance, Navigation and Control system, GPS receivers, relative navigation filter and the Video Guidance Sensor. A discussion of the safety and reliability issues confronted during the design follows. By designing a safe and robust automated system, space mission operations cost can be reduced by decreasing the number of ground personnel required for the extensive mission design, preflight planning and training typically required for rendezvous and docking missions.

Cruzen, Craig A.↗
NASA NTRS2005

Development of Software for a Lidar-Altimeter Processor

A report describes the development of software for a digital processor that operates in conjunction with a finite-impulse-response (FIR) chip in a spaceborne lidar altimeter. Processing is started by a laser-fire interrupt signal that is repeated at intervals of 25 ms. For the purpose of discriminating between returns from the ground and returns from such things as trees, buildings, and clouds, the software is required to scan digitized lidar-return data in reverse of the acquisition sequence in order to distinguish the last return pulse from within a commanded ground-return range window. The digitized waveform information within this range window is filtered through 6 matched filters, in the hardware electronics, in order to maximize the probability of finding echoes from sloped or rough terrain and minimize the probability of selecting cloud returns. From the data falling past the end of the range window, there is obtained a noise baseline that is used to calculate a threshold value for each filter. The data from each filter is analyzed by a complex weighting scheme and the filter with the greatest weight is selected. A region around the peak of the ground return pulse associated with the selected filter is placed in telemetry, as well as information on its location, height, and other characteristics. The software requires many uplinked parameters as input. Included in the report is a discussion of major software-development problems posed by the design of the FIR chip and the need for the software to complete its process within 20 ms to fit within the overall 25-ms cycle.

Rosenberg, Jacob S.↗
NASA NTRS2008

Replacement Sequence of Events Generator

The soeWINDOW program automates the generation of an ITAR (International Traffic in Arms Regulations)-compliant sub-RSOE (Replacement Sequence of Events) by extracting a specified temporal window from an RSOE while maintaining page header information. RSOEs contain a significant amount of information that is not ITAR-compliant, yet that foreign partners need to see for command details to their instrument, as well as the surrounding commands that provide context for validation. soeWINDOW can serve as an example of how command support products can be made ITAR-compliant for future missions. This software is a Perl script intended for use in the mission operations UNIX environment. It is designed for use to support the MRO (Mars Reconnaissance Orbiter) instrument team. The tool also provides automated DOM (Distributed Object Manager) storage into the special ITAR-okay DOM collection, and can be used for creating focused RSOEs for product review by any of the MRO teams.

Fisher, Forest↗
NASA NTRS1969

Surveyor Project Final Report: Part 1 - Project Description and Performance, Volume 1

The Surveyor Project planned and conducted seven unmanned lunar missions for which spacecraft were launched between May 1966 and January 1968. Each of the spacecraft was successfully launched with the then newly developed Atlas/Centaur vehicle which utilized for the first time a high-specific-impulse, liquid hydrogen/liquid oxygen fueled stage. Five of the spacecraft successfully soft-landed and returned a great quantity of engineering and scientific data on extensive postlanding operations, accomplishing all mission and project objectives. Four of the spacecraft soft-landed at selected mare sites to provide data which were required to support the Apollo Program. The final spacecraft was then successfully used for scientific investigation of a contrasting site in the rugged lunar highlands. Surveyor was a fully attitude-stabilized spacecraft designed to receive and execute a wide variety of earth commands, as well as to perform certain automatic functions including the critical terminal-descent and soft-landing sequences. Significant new and advanced subsystems that were developed and/or used in combination to enable Surveyor to execute the complex terminal phase of flight were: (1) a solid-propellant main retro motor, (2) throttlable liquid-propellant vernier engines (also used for midcourse velocity correction), (3) highly sensitive velocity- and altitude-sensing radars, and (4) an automatic closed-loop guidance and control system. The first Surveyor spacecraft carried a survey television camera which, together with other engineering instrumentation, obtained in-flight and postlanding data. The complement of instruments carried on later missions included various combinations of the following additional devices: (1) a soil mechanics/surface sampler instrument for picking, digging, and handling lunar surface material; (2) an alpha scattering instrument for performing a chemical analysis of the lunar surface material; and (3) magnets attached to the spacecraft for determining magnetic properties of the soil.

Jet Propulsion Laboratory↗
NASA NTRS1969

Surveyor Project Final Report: Part 1 - Project Description and Performance, Volume 2

The Surveyor Project planned and conducted seven unmanned lunar missions for which spacecraft were launched between May 1966 and January 1968. Each of the spacecraft was successfully launched with the then newly developed Atlas/Centaur vehicle which utilized for the first time a high-specific-impulse, liquid hydrogen/liquid oxygen fueled stage. Five of the spacecraft successfully soft-landed and returned a great quantity of engineering and scientific data on extensive postlanding operations, accomplishing all mission and project objectives. Four of the spacecraft soft-landed at selected mare sites to provide data which were required to support the Apollo Program. The final spacecraft was then successfully used for scientific investigation of a contrasting site in the rugged lunar highlands. Surveyor was a fully attitude-stabilized spacecraft designed to receive and execute a wide variety of earth commands, as well as to perform certain automatic functions including the critical terminal-descent and soft-landing sequences. Significant new and advanced subsystems that were developed and/or used in combination to enable Surveyor to execute the complex terminal phase of flight were: (1) a solid-propellant main retro motor, (2) throttlable liquid-propellant vernier engines (also used for midcourse velocity correction), (3) highly sensitive velocity- and altitude-sensing radars, and (4) an automatic closed-loop guidance and control system. The first Surveyor spacecraft carried a survey television camera which, together with other engineering instrumentation, obtained in-flight and postlanding data. The complement of instruments carried on later missions included various combinations of the following additional devices: (1) a soil mechanics/surface sampler instrument for picking, digging, and handling lunar surface material; (2) an alpha scattering instrument for performing a chemical analysis of the lunar surface material; and (3) magnets attached to the spacecraft for determining magnetic properties of the soil.

Jet Propulsion Laboratory↗
NASA NTRS2010

AutoGen Version 5.0

Version 5.0 of the AutoGen software has been released. Previous versions, variously denoted Autogen and autogen, were reported in two articles: Automated Sequence Generation Process and Software (NPO-30746), Software Tech Briefs (Special Supplement to NASA Tech Briefs), September 2007, page 30, and Autogen Version 2.0 (NPO- 41501), NASA Tech Briefs, Vol. 31, No. 10 (October 2007), page 58. To recapitulate: AutoGen (now signifying automatic sequence generation ) automates the generation of sequences of commands in a standard format for uplink to spacecraft. AutoGen requires fewer workers than are needed for older manual sequence-generation processes, and greatly reduces sequence-generation times. The sequences are embodied in spacecraft activity sequence files (SASFs). AutoGen automates generation of SASFs by use of another previously reported program called APGEN. AutoGen encodes knowledge of different mission phases and of how the resultant commands must differ among the phases. AutoGen also provides means for customizing sequences through use of configuration files. The approach followed in developing AutoGen has involved encoding the behaviors of a system into a model and encoding algorithms for context-sensitive customizations of the modeled behaviors. This version of AutoGen addressed the MRO (Mars Reconnaissance Orbiter) primary science phase (PSP) mission phase. On previous Mars missions this phase has more commonly been referred to as mapping phase. This version addressed the unique aspects of sequencing orbital operations and specifically the mission specific adaptation of orbital operations for MRO. This version also includes capabilities for MRO s role in Mars relay support for UHF relay communications with the MER rovers and the Phoenix lander.

Gladden, Roy E.↗
NASA NTRS2017

Osiris-REx Spacecraft Current Status and Forward Plans

The NASA New Frontiers OSIRIS-REx spacecraft executed a flawless launch on September 8, 2016 to begin its 23-month journey to near-Earth asteroid (101955). The primary objective of the OSIRIS-REx mission is to collect and return to Earth a pristine sample of regolith from the asteroid surface. The sampling event will occur after a two-year period of remote sensing that will ensure a high probability of successful sampling of a region on the asteroid surface having high science value and within well-defined geological context. The OSIRIS-REx instrument payload includes three high-resolution cameras (OCAMS), a visible and near-infrared spectrometer (OVIRS), a thermal imaging spectrometer (OTES), an X-ray imaging spectrometer (REXIS), and a laser altimeter (OLA). As the spacecraft follows its nominal outbound-cruise trajectory, the propulsion, power, communications, and science instruments have undergone basic functional tests, with no major issues. Outbound cruise science investigations include a search for Earth Trojan asteroids as the spacecraft approaches the Sun-Earth L4 Lagrangian point in February 2017. Additional instrument checkouts and calibrations will be carried out during the Earth gravity assist maneuver in September 2017. During the Earth-moon flyby, visual and spectral images will be acquired to validate instrument command sequences planned for Bennu remote sensing. The asteroid Bennu remote sensing campaign will yield high resolution maps of the temperature and thermal inertia, distributions of major minerals and concentrations of organic matter across the asteroid surface. A high resolution 3d shape model including local surface slopes and a high-resolution gravity field will also be determined. Together, these data will be used to generate four separate maps that will be used to select the sampling site(s). The Safety map will identify hazardous and safe operational regions on the asteroid surface. The Deliverability map will quantify the accuracy with which the navigation team can deliver the spacecraft to and from specific sites on the asteroid surface. The Sampleability map quantifies the regolith properties, providing an estimation of how much material would be sampled at different points on the surface. The final Science Value map synthesizes the chemical, mineralogical, and geological, observations to identify the areas of the asteroid surface with the highest science value. Here, priority is given to organic, water-rich regions that have been minimally altered by surface processes. Asteroid surface samples will be acquired with a touch-and-go sample acquisition system (TAGSAM) that uses high purity pressurized N2 gas to mobilize regolith into a stainless steel canister. Although the mission requirement is to collect at least 60 g of material, tests of the TAGSAM routinely exceeded 300 g of simulant in micro-gravity tests. After acquiring the sample, the spacecraft will depart Bennu in 2021 to begin its return journey, with the sample return capsule landing at the Utah Test and Training Range on September 23, 2023. The OSIRIS-REx science team will carry out a series of detailed chemical, mineralogical, isotopic, and spectral studies that will be used to determine the origin and history of Bennu and to relate high spatial resolution sample studies to the global geological context from remote sensing. The outline of the sample analysis plan is described in a companion abstract.

Messenger, Scott↗
NASA NTRS2002

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↗
NASA NTRS2006

Automated Activation and Deactivation of a System Under Test

The MPLM Automated Activation/Deactivation application (MPLM means Multi-Purpose Logistic Module) was created with a three-fold purpose in mind: 1. To reduce the possibility of human error in issuing commands to, or interpreting telemetry from, the MPLM power, computer, and environmental control systems; 2. To reduce the amount of test time required for the repetitive activation/deactivation processes; and 3. To reduce the number of on-console personnel required for activation/ deactivation. All of these have been demonstrated with the release of the software. While some degree of automated end-item commanding had previously been performed for space-station hardware in the test environment, none approached the functionality and flexibility of this application. For MPLM activation, it provides mouse-click selection of the hardware complement to be activated, activates the desired hardware and verifies proper feedbacks, and alerts the user when telemetry indicates an error condition or manual intervention is required. For MPLM deactivation, the product senses which end items are active and deactivates them in the proper sequence. For historical purposes, an on-line log is maintained of commands issued and telemetry points monitored. The benefits of the MPLM Automated Activation/ Deactivation application were demonstrated with its first use in December 2002, when it flawlessly performed MPLM activation in 8 minutes (versus as much as 2.4 hours for previous manual activations), and performed MPLM deactivation in 3 minutes (versus 66 minutes for previous manual deactivations). The number of test team members required has dropped from eight to four, and in actuality the software can be operated by a sole (knowledgeable) system engineer.

Poff, Mark A.↗