Search NASA⌕ Search

SEARCH · Search NASA

Results for “Mission manager software”

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 289 records · Page 16

LADEE Preparations for Contingency Operations for the Lunar Orbit Insertion Maneuver

The Lunar Atmosphere and Dust Environment Explorer (LADEE) spacecraft was launched on September 6, 2013, and completed its mission on April 17, 2014 with a directed impact to the Lunar Surface. Its primary goals were to examine the lunar atmosphere, measure lunar dust, and to demonstrate high rate laser communications. The LADEE mission was a resounding success, achieving all mission objectives, much of which can be attributed to careful planning and preparation. This paper discusses the specific preparations for fault conditions that could occur during a highly-critical phase of the mission. To get to the Moon, the spacecraft traversed multiple phasing loops around the Earth, and then executed a breaking maneuver to achieve lunar orbit. This Lunar Orbit Insertion (LOI) maneuver was perhaps the most time-critical phase of the entire mission. The LOI maneuver had to occur within a twenty minute window in order to achieve lunar orbit with an acceptable amount of propellant remaining. Missing this window would have likely resulted in a loss of the entire mission. An additional challenge of the maneuver was that spacecraft was out of view for approximately one hour prior to the main thruster burn, with the burn needing to occur within five minutes after coming into view. These conditions resulted in unique challenges for ground operations and the fault management system. Early in the planning stages of the mission, the criticality and challenges of this maneuver were evident to the system designers. The major concern was that any triggering of the on-board fault management system, whether it is in response to a true fault or a false positive, would result in an unacceptable delay to the burn. Therefore the flight software was designed with a flexible fault management system, such that any or all of the fault management responses could be disabled for the lead up and execution of the maneuver. Later, a triage was conducted to develop a list of fault responses, mapped to various parts of the timeline of the maneuver. Some of these contingency responses were solely ground-based if the time to detect, diagnose, and respond were adequate. Other responses were automated on-board if the response time from the ground would have been inadequate. For instance, in order to recover from a system reboot, on-board automation would have automatically reconfigured the spacecraft for the burn and reoriented the spacecraft to the burn attitude.These contingency responses were practiced, over and over, during numerous rehearsals. Although the LOI maneuver was executed without having to use any of these contingencies, the LADEE team was adequately prepared for this highly critical phase of the mission.

Cannon, Howard↗

Real-time solar magnetograph operation system software design and user's guide

The Real Time Solar Magnetograph (RTSM) Operation system software design on PDP11/23+ is presented along with the User's Guide. The RTSM operation software is for real time instrumentation control, data collection and data management. The data is used for vector analysis, plotting or graphics display. The processed data is then easily compared with solar data from other sources, such as the Solar Maximum Mission (SMM).

Wang, C.↗

The Mission Oriented Terminal Area Simulation (MOTAS)

A new simulation facility is described in which flight management and flight operations research studies can be conducted in a highly realistic terminal area environment. The historical evolution and justification of the facility is discussed, along with the design configuration of the system hardware and software. Details are provided on the traffic management features of the terminal area model as well as the human controller and multicockpit interface capabilities. The facility is currently operational with two cockpit simulators, two air traffic control (ATC) stations, four pseudo pilot stations (PPS), a metering and spacing system of traffic flow control management, and terminal area models providing two route structure environments: area navigation (RNAV) for advanced-equipped aircraft and vectoring for conventionally-equipped aircraft. Plans for future experiments utilizing the facility are discussed.

Naftel, P. B.↗

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↗

A new systems engineering approach to streamlined science and mission operations for the Far Ultraviolet Spectroscopic Explorer (FUSE)

The Mission Operations and Data Systems Directorate (MO&DSD, Code 500), the Space Sciences Directorate (Code 600), and the Flight Projects Directorate (Code 400) have developed a new approach to combine the science and mission operations for the FUSE mission. FUSE, the last of the Delta-class Explorer missions, will obtain high resolution far ultraviolet spectra (910 - 1220 A) of stellar and extragalactic sources to study the evolution of galaxies and conditions in the early universe. FUSE will be launched in 2000 into a 24-hour highly eccentric orbit. Science operations will be conducted in real time for 16-18 hours per day, in a manner similar to the operations performed today for the International Ultraviolet Explorer. In a radical departure from previous missions, the operations concept combines spacecraft and science operations and data processing functions in a single facility to be housed in the Laboratory for Astronomy and Solar Physics (Code 680). A small missions operations team will provide the spacecraft control, telescope operations and data handling functions in a facility designated as the Science and Mission Operations Center (SMOC). This approach will utilize the Transportable Payload Operations Control Center (TPOCC) architecture for both spacecraft and instrument commanding. Other concepts of integrated operations being developed by the Code 500 Renaissance Project will also be employed for the FUSE SMOC. The primary objective of this approach is to reduce development and mission operations costs. The operations concept, integration of mission and science operations, and extensive use of existing hardware and software tools will decrease both development and operations costs extensively. This paper describes the FUSE operations concept, discusses the systems engineering approach used for its development, and the software, hardware and management tools that will make its implementation feasible.

Butler, Madeline J.↗

ISS Solar Array Management

The International Space Station (ISS) Solar Array Management (SAM) software toolset provides the capabilities necessary to operate a spacecraft with complex solar array constraints. It monitors spacecraft telemetry and provides interpretations of solar array constraint data in an intuitive manner. The toolset provides extensive situational awareness to ensure mission success by analyzing power generation needs, array motion constraints, and structural loading situations. The software suite consists of several components including samCS (constraint set selector), samShadyTimers (array shadowing timers), samWin (visualization GUI), samLock (array motion constraint computation), and samJet (attitude control system configuration selector). It provides high availability and uptime for extended and continuous mission support. It is able to support two-degrees-of-freedom (DOF) array positioning and supports up to ten simultaneous constraints with intuitive 1D and 2D decision support visualizations of constraint data. Display synchronization is enabled across a networked control center and multiple methods for constraint data interpolation are supported. Use of this software toolset increases flight safety, reduces mission support effort, optimizes solar array operation for achieving mission goals, and has run for weeks at a time without issues. The SAM toolset is currently used in ISS real-time mission operations.

Williams, James P.↗

Evolution of the Hubble Space Telescope Safing Systems

The Hubble Space Telescope (HST) was launched on April 24 1990, with an expected lifespan of 15 years. Central to the spacecraft design was the concept of a series of on-orbit shuttle servicing missions permitting astronauts to replace failed equipment, update the scientific instruments and keep the HST at the forefront of astronomical discoveries. One key to the success of the Hubble mission has been the robust Safing systems designed to monitor the performance of the observatory and to react to keep the spacecraft safe in the event of equipment anomaly. The spacecraft Safing System consists of a range of software tests in the primary flight computer that evaluate the performance of mission critical hardware, safe modes that are activated when the primary control mode is deemed inadequate for protecting the vehicle, and special actions that the computer can take to autonomously reconfigure critical hardware. The HST Safing System was structured to autonomously detect electrical power system, data management system, and pointing control system malfunctions and to configure the vehicle to ensure safe operation without ground intervention for up to 72 hours. There is also a dedicated safe mode computer that constantly monitors a keep-alive signal from the primary computer. If this signal stops, the safe mode computer shuts down the primary computer and takes over control of the vehicle, putting it into a safe, low-power configuration. The HST Safing system has continued to evolve as equipment has aged, as new hardware has been installed on the vehicle, and as the operation modes have matured during the mission. Along with the continual refinement of the limits used in the safing tests, several new tests have been added to the monitoring system, and new safe modes have been added to the flight software. This paper will focus on the evolution of the HST Safing System and Safing tests, and the importance of this evolution to prolonging the science operations of the telescope.

Pepe, Joyce↗

SMC: SCENIC Model Control

NASAs Space Communications and Navigation (SCaN) program manages three active networks: the Near Earth Network, the Space Network, and the Deep Space Network. These networks simultaneously support NASA missions and provide communications services to customers worldwide. To efficiently manage these resources and their capabilities, a team of student interns at the NASA Glenn Research Center is developing a distributed system to model the SCaN networks. Once complete, the system shall provide a platform that enables users to perform capacity modeling of current and prospective missions with finer-grained control of information between several simulation and modeling tools. This will enable the SCaN program to access a holistic view of its networks and simulate the effects of modifications in order to provide NASA with decisional information. The development of this capacity modeling system is managed by NASAs Strategic Center for Education, Networking, Integration, and Communication (SCENIC). Three primary third-party software tools offer their unique abilities in different stages of the simulation process. MagicDraw provides UMLSysML modeling, AGIs Systems Tool Kit simulates the physical transmission parameters and de-conflicts scheduled communication, and Riverbed Modeler (formerly OPNET) simulates communication protocols and packet-based networking. SCENIC developers are building custom software extensions to integrate these components in an end-to-end space communications modeling platform. A central control module acts as the hub for report-based messaging between client wrappers. Backend databases provide information related to mission parameters and ground station configurations, while the end user defines scenario-specific attributes for the model. The eight SCENIC interns are working under the direction of their mentors to complete an initial version of this capacity modeling system during the summer of 2015. The intern team is composed of four students in Computer Science, two in Computer Engineering, one in Electrical Engineering, and one studying Space Systems Engineering.

Simulation↗

Intelligent systems and advanced user interfaces for design, operation, and maintenance of command management systems

Historically, command management systems (CMS) have been large and expensive spacecraft-specific software systems that were costly to build, operate, and maintain. Current and emerging hardware, software, and user interface technologies may offer an opportunity to facilitate the initial formulation and design of a spacecraft-specific CMS as well as to develop a more generic CMS system. New technologies, in addition to a core CMS common to a range of spacecraft, may facilitate the training and enhance the efficiency of CMS operations. Current mission operations center (MOC) hardware and software include Unix workstations, the C/C++ programming languages, and an X window interface. This configuration provides the power and flexibility to support sophisticated and intelligent user interfaces that exploit state-of-the-art technologies in human-machine interaction, artificial intelligence, and software engineering. One of the goals of this research is to explore the extent to which technologies developed in the research laboratory can be productively applied in a complex system such as spacecraft command management. Initial examination of some of these issues in CMS design and operation suggests that application of technologies such as intelligent planning, case-based reasoning, human-machine systems design and analysis tools (e.g., operator and designer models), and human-computer interaction tools (e.g., graphics, visualization, and animation) may provide significant savings in the design, operation, and maintenance of the CMS for a specific spacecraft as well as continuity for CMS design and development across spacecraft. The first six months of this research saw a broad investigation by Georgia Tech researchers into the function, design, and operation of current and planned command management systems at Goddard Space Flight Center. As the first step, the researchers attempted to understand the current and anticipated horizons of command management systems at Goddard. Preliminary results are given on CMS commonalities and causes of low re-use, and methods are proposed to facilitate increased re-use.

Potter, William J.↗

Acoustic Emission Health Monitoring of Fill Purge COPV's Used in Aerospace and Automotive Applications and Designed for Long Cycle Life

Cumulative composite damage in composite pressure vessels (CPVs) currently is not monitored on-orbit. Consequently, hazards due to catastrophic burst before leak (BBL) or compromised CPV reliability cannot be ascertained or mitigated, posing a risk to crew and mission assurance. The energy associated with CPV rupture can be significant, especially with high pressure gases are under containment, and the energy releases can be severe enough to cause injury, death, loss of assets or mission. Dual-Use Rationale: CPVs similar to those used by NASA on ISS, for example, are finding increasing use in automotive and transportation industry applications. These CPVs generally have a nonload sharing liner and are repeatedly filled over their service lifetime, typically with hydrogen or compressed natural gas (CNG). The same structural health monitoring equipment and software developed by NASA WSTF for evaluating, in real-time, the health of NASA CPVs on ISS will be used to evaluate the health of automotive CPVs, the only differences being the type and design of the CPV, and the in-service lifetime pressure histories. HSF Need(s)/Performance Characteristic(s) Supported: 1) Enable on-board vehicle systems management for mission critical functions at destinations with > 3 second time delay 2) Enable autonomous nominal operations and FDIR for crewed and un-crewed systems 3) Reduce on-board crew time to sustain and manage vehicle by factor of 2x at destinations with > 6 second time delay (see Crew Autonomy sheet) 4) Reduce earth-based mission ops "back room engineering" requirements for distant mission support delay (see Mission Autonomy sheet)

Waller, Jess↗

Formalizing procedures for operations automation, operator training and spacecraft autonomy

The generation and validation of operations procedures is a key task of mission preparation that is quite complex and costly. This has motivated the development of software applications providing support for procedures preparation. Several applications have been developed at MATRA MARCONI SPACE (MMS) over the last five years. They are presented in the first section of this paper. The main idea is that if procedures are represented in a formal language, they can be managed more easily with a computer tool and some automatic verifications can be performed. One difficulty is to define a formal language that is easy to use for operators and operations engineers. From the experience of the various procedures management tools developed in the last five years (including the POM, EOA, and CSS projects), MMS has derived OPSMAKER, a generic tool for procedure elaboration and validation. It has been applied to quite different types of missions, ranging from crew procedures (PREVISE system), ground control centers management procedures (PROCSU system), and - most relevant to the present paper - satellite operation procedures (PROCSAT developed for CNES, to support the preparation and verification of SPOT 4 operation procedures, and OPSAT for MMS telecom satellites operation procedures).

Lecouat, Francois↗

Reducing costs of managing and accessing navigation and ancillary data by relying on the extensive capabilities of NASA's spice system

The SPICE system of navigation and ancillary data possesses a number of traits that make its use in modern space missions of all types highly cost efficient. The core of the system is a software library providing API interfaces for storing and retrieving such data as trajectories, orientations, time conversions, and instrument geometry parameters. Applications used at any stage of a mission life cycle can call SPICE APIs to access this data and compute geometric quantities required for observation planning, engineering assessment and science data analysis. SPICE is implemented in three different languages, supported on 20+ computer environments, and distributed with complete source code and documentation. It includes capabilities that are extensively tested by everyday use in many active projects and are applicable to all types of space missions - flyby, orbiters, observatories, landers and rovers. While a customer's initial SPICE adaptation for the first mission or experiment requires a modest effort, this initial effort pays off because adaptation for subsequent missions/experiments is just a small fraction of the initial investment, with the majority of tools based on SPICE requiring no or very minor changes.

ancillary data↗

Should’ve Could’ve: Progress in the Systems Engineering of the Mars2020 On-Board Planner

Mars rover operations has traditionally controlled behavior using meticulously compiled, so-called “Master” sequences that enforce deterministic timing and ordering of activities. While the approach is effective at managing risk and complexity, it can also be inefficient. Extended operations of the Mars2020 rover envisions a fundamentally different scheduling and execution approach. Atomic activities are constrained by mission operators in time, resource usage, and a structure of dependencies. The rover flight software will create and re-create schedules, responding to available energy, data volume, actual activity durations and execution status, observed temperatures, and other on-board state. Schedules are expected to change substantially in the course of execution. The solution space is prohibitively large and probabilistic in nature. A range of emergent behavior is accessible depending on the interaction between actual on-board state and a given formulation of constraints. For years, the specification and implementation of this capability have been considered and refined, as testing and analysis have mapped the contours of the system. Many concepts that could have been adopted were rejected, and in some cases, emergent properties have been exposed and beaten back with approaches to steer the behavior. This paper discusses some of the design history and underlying reasoning in the systems engineering of the first autonomous activity planner on Mars.

Kuhn, Stephen R↗

The SAX Italian scientific satellite. The on-board implemented automation as a support to the ground control capability

This paper presents the capabilities implemented in the SAX system for an efficient operations management during its in-flight mission. SAX is an Italian scientific satellite for x-ray astronomy whose major mission objectives impose quite tight constraints on the implementation of both the space and ground segment. The most relevant mission characteristics require an operative lifetime of two years, performing scientific observations both in contact and in noncontact periods, with a low equatorial orbit supported by one ground station, so that only a few minutes of communications are available each orbit. This operational scenario determines the need to have a satellite capable of performing the scheduled mission automatically and reacting autonomously to contingency situations. The implementation approach of the on-board operations management, through which the necessary automation and autonomy are achieved, follows a hierarchical structure. This has been achieved adopting a distributed avionic architecture. Nine different on-board computers, in fact, constitute the on-board data management system. Each of them performs the local control and monitors its own functions while the system level control is performed at a higher level by the data handling applications software. The SAX on-board architecture provides the ground operators with different options of intervention by three classes of telecommands. The management of the scientific operations will be scheduled by the operation control center via dedicated operating plans. The SAX satellite flight mode is presently being integrated at Alenia Spazio premises in Turin for a launch scheduled for the end of 1995. Once in orbit, the SAX satellite will be subject to intensive check-out activities in order to verify the required mission performances. An overview of the envisaged procedure and of the necessary on-ground activities is therefore depicted as well.

Martelli, Andrea↗

Virtual Sensor Test Instrumentation

Virtual Sensor Test Instrumentation is based on the concept of smart sensor technology for testing with intelligence needed to perform sell-diagnosis of health, and to participate in a hierarchy of health determination at sensor, process, and system levels. A virtual sensor test instrumentation consists of five elements: (1) a common sensor interface, (2) microprocessor, (3) wireless interface, (4) signal conditioning and ADC/DAC (analog-to-digital conversion/ digital-to-analog conversion), and (5) onboard EEPROM (electrically erasable programmable read-only memory) for metadata storage and executable software to create powerful, scalable, reconfigurable, and reliable embedded and distributed test instruments. In order to maximize the efficient data conversion through the smart sensor node, plug-and-play functionality is required to interface with traditional sensors to enhance their identity and capabilities for data processing and communications. Virtual sensor test instrumentation can be accessible wirelessly via a Network Capable Application Processor (NCAP) or a Smart Transducer Interlace Module (STIM) that may be managed under real-time rule engines for mission-critical applications. The transducer senses the physical quantity being measured and converts it into an electrical signal. The signal is fed to an A/D converter, and is ready for use by the processor to execute functional transformation based on the sensor characteristics stored in a Transducer Electronic Data Sheet (TEDS). Virtual sensor test instrumentation is built upon an open-system architecture with standardized protocol modules/stacks to interface with industry standards and commonly used software. One major benefit for deploying the virtual sensor test instrumentation is the ability, through a plug-and-play common interface, to convert raw sensor data in either analog or digital form, to an IEEE 1451 standard-based smart sensor, which has instructions to program sensors for a wide variety of functions. The sensor data is processed in a distributed fashion across the network, providing a large pool of resources in real time to meet stringent latency requirements.

Wang, Roy↗

Propulsion System Modeling and Simulation

The Aerospace Systems Design Laboratory at the School of Aerospace Engineering in Georgia Institute of Technology has developed a core competency that enables propulsion technology managers to make technology investment decisions substantiated by propulsion and airframe technology system studies. This method assists the designer/manager in selecting appropriate technology concepts while accounting for the presence of risk and uncertainty as well as interactions between disciplines. This capability is incorporated into a single design simulation system that is described in this paper. This propulsion system design environment is created with a commercially available software called iSIGHT, which is a generic computational framework, and with analysis programs for engine cycle, engine flowpath, mission, and economic analyses. iSIGHT is used to integrate these analysis tools within a single computer platform and facilitate information transfer amongst the various codes. The resulting modeling and simulation (M&S) environment in conjunction with the response surface method provides the designer/decision-maker an analytical means to examine the entire design space from either a subsystem and/or system perspective. The results of this paper will enable managers to analytically play what-if games to gain insight in to the benefits (and/or degradation) of changing engine cycle design parameters. Furthermore, the propulsion design space will be explored probabilistically to show the feasibility and viability of the propulsion system integrated with a vehicle.

Tai, Jimmy C. M.↗

Architecting the Human Space Flight Program with Systems Modeling Language (SysML)

The next generation of missions in NASA's Human Space Flight program focuses on the development and deployment of highly complex systems (e.g., Orion Multi-Purpose Crew Vehicle, Space Launch System, 21st Century Ground System) that will enable astronauts to venture beyond low Earth orbit and explore the moon, near-Earth asteroids, and beyond. Architecting these highly complex system-of-systems requires formal systems engineering techniques for managing the evolution of the technical features in the information exchange domain (e.g., data exchanges, communication networks, ground software) and also, formal correlation of the technical architecture to stakeholders' programmatic concerns (e.g., budget, schedule, risk) and design development (e.g., assumptions, constraints, trades, tracking of unknowns). This paper will describe how the authors have applied System Modeling Language (SysML) to implement model-based systems engineering for managing the description of the End-to-End Information System (EEIS) architecture and associated development activities and ultimately enables stakeholders to understand, reason, and answer questions about the EEIS under design for proposed lunar Exploration Missions 1 and 2 (EM-1 and EM-2).

scheduling↗

NASA Lewis' Telescience Support Center Supports Orbiting Microgravity Experiments

The Telescience Support Center (TSC) at the NASA Lewis Research Center was developed to enable Lewis-based science teams and principal investigators to monitor and control experimental and operational payloads onboard the International Space Station. The TSC is a remote operations hub that can interface with other remote facilities, such as universities and industrial laboratories. As a pathfinder for International Space Station telescience operations, the TSC has incrementally developed an operational capability by supporting space shuttle missions. The TSC has evolved into an environment where experimenters and scientists can control and monitor the health and status of their experiments in near real time. Remote operations (or telescience) allow local scientists and their experiment teams to minimize their travel and maintain a local complement of expertise for hardware and software troubleshooting and data analysis. The TSC was designed, developed, and is operated by Lewis' Engineering and Technical Services Directorate and its support contractors, Analex Corporation and White's Information System, Inc. It is managed by Lewis' Microgravity Science Division. The TSC provides operational support in conjunction with the NASA Marshall Space Flight Center and NASA Johnson Space Center. It enables its customers to command, receive, and view telemetry; monitor the science video from their on-orbit experiments; and communicate over mission-support voice loops. Data can be received and routed to experimenter-supplied ground support equipment and/or to the TSC data system for display. Video teleconferencing capability and other video sources, such as NASA TV, are also available. The TSC has a full complement of standard services to aid experimenters in telemetry operations.

Hawersaat, Bob W.↗