Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “mission 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 379 records · Page 21
All sourcesNASA NTRSDOE OSTI
NASA NTRS1975

Apollo Soyuz Test Project Weights and Mass Properties Operational Management System

The Apollo Soyuz Test Project (ASTP) Weights and Mass Properties Operational Management System was established to assure a timely and authoritative method of acquiring, controlling, generating, and disseminating an official set of vehicle weights and mass properties data. This paper provides an overview of the system and its interaction with the various aspects of vehicle and component design, mission planning, hardware and software simulations and verification, and real-time mission support activities. The effect of vehicle configuration, design maturity, and consumables updates is discussed in the context of weight control.

Collins, M. A., Jr.↗
NASA NTRS1987

Planning Orbiter Flights

Shuttle Mission Design and Operations Software (SMDOS) assists in design and operation of missions involving spacecraft in low orbits around Earth by providing orbital and graphics information. SMDOS performs following five functions: display two world and two polar maps or any user-defined window 5 degrees high in latitude by 5 degrees wide in longitude in one of eight standard projections; designate Earth sites by points or polygon shapes; plot spacecraft ground track with 1-min demarcation lines; display, by means of different colors, availability of Tracking and Data Relay Satellite to Shuttle; and calculate available times and orbits to view particular site, and corresponding look angles. SMDOS written in Laboratory Micro-systems FORTH (1979 standard)

Harris, H. M.↗
NASA NTRS2008

JPL Test Effectiveness Analysis

1) The pilot study provided meaningful conclusions that are generally consistent with the earlier Test Effectiveness work done between 1992 and 1994: a) Analysis of pre-launch problem/failure reports is consistent with earlier work. b) Analysis of post-launch early mission anomaly reports indicates that there are more software issues in newer missions, and the no-test category for identification of post-launch failures is more significant than in the earlier analysis. 2) Future work includes understanding how differences in Missions effect these analyses: a) There are large variations in the number of problem reports and issues that are documented by the different Projects/Missions. b) Some missions do not have any reported environmental test anomalies, even though environmental tests were performed. 3) Each project/mission has different standards and conventions for filling out the PFR forms, the industry may wish to address this issue: a) Existing problem reporting forms are to document and track problems, failures, and issues (etc.) for the projects, to ensure high quality. b) Existing problem reporting forms are not intended for data mining.

failure cause↗
NASA NTRS2014

Lessons Learned in the First Year Operating Software Defined Radios in Space

Operating three unique software defined radios (SDRs) in a space environment aboard the Space Communications and Navigation (SCaN) Testbed for over one year has provided an opportunity to gather knowledge useful for future missions considering using software defined radios. This paper provides recommendations for the development and use of SDRs, and it considers the details of each SDRs approach to software upgrades and operation. After one year, the SCaN Testbed SDRs have operated for over 1000 hours. During this time, the waveforms launched with the SDR were tested on-orbit to assure that they operated in space at the same performance level as on the ground prior to launch to obtain an initial on-orbit performance baseline. A new waveform for each SDR has been developed, implemented, uploaded to the flight system, and tested in the flight environment. Recommendations for SDR-based missions have been gathered from early development through operations. These recommendations will aid future missions to reduce the cost, schedule, and risk of operating SDRs in a space environment. This paper considers the lessons learned as they apply to SDR pre-launch checkout, purchasing space-rated hardware, flexibility in command and telemetry methods, on-orbit diagnostics, use of engineering models to aid future development, and third-party software. Each SDR implements the SCaN Testbed flight computer command and telemetry interface uniquely, allowing comparisons to be drawn. The paper discusses the lessons learned from these three unique implementations, with suggestions on the preferred approach. Also, results are presented showing that it is important to have full system performance knowledge prior to launch to establish better performance baselines in space, requiring additional test applications to be developed pre-launch. Finally, the paper presents the issues encountered with the operation and implementation of new waveforms on each SDR and proposes recommendations to avoid these issues.

radio equipment↗
NASA NTRS2014

Lessons Learned in the First Year Operating Software Defined Radios in Space

Operating three unique software defined radios (SDRs) in a space environment aboard the Space Communications and Navigation (SCaN) Testbed for over one year has provided an opportunity to gather knowledge useful for future missions considering using software defined radios. This paper provides recommendations for the development and use of SDRs, and it considers the details of each SDR's approach to software upgrades and operation. After one year, the SCaN Testbed SDRs have operated for over 1000 hours. During this time, the waveforms launched with the SDR were tested on-orbit to assure that they operated in space at the same performance level as on the ground prior to launch to obtain an initial on-orbit performance baseline. A new waveform for each SDR has been developed, implemented, uploaded to the flight system, and tested in the flight environment. Recommendations for SDR-based missions have been gathered from early development through operations. These recommendations will aid future missions to reduce the cost, schedule, and risk of operating SDRs in a space environment. This paper considers the lessons learned as they apply to SDR pre-launch checkout, purchasing space-rated hardware, flexibility in command and telemetry methods, on-orbit diagnostics, use of engineering models to aid future development, and third-party software. Each SDR implements the SCaN Testbed flight computer command and telemetry interface uniquely, allowing comparisons to be drawn. The paper discusses the lessons learned from these three unique implementations, with suggestions on the preferred approach. Also, results are presented showing that it is important to have full system performance knowledge prior to launch to establish better performance baselines in space, requiring additional test applications to be developed pre-launch. Finally, the paper presents the issues encountered with the operation and implementation of new waveforms on each SDR and proposes recommendations to avoid these issues.

space communication↗
NASA NTRS1994

CCS-MIP: Low cost Customizable Control Centre

The positioning and station keeping of French national satellites are among the main missions of CNES French Space Agency CNES. The related experience and skills of the Toulouse Space Centre are reknown and often required at international level for a wide range of missions. CISI, a software engineering company, has been contributing during the last 20 years to the development of the French space programs, particularly in the field of space missions ground control segments. The CCS-MIP system, presented here, is a satellite positioning and station-keeping system designed to answer the CNES multi-mission needs, easily adaptable for a wide range of applications.

Labezin, Christian↗
NASA NTRS1987

Space Station Mission Planning Study (MPS) development study. Volume 3: Software development plan

A software development plan is presented for the definition, design, and implementation of the Space Station (SS) Payload Mission Planning System (MPS). This plan is an evolving document and must be updated periodically as the SS design and operations concepts as well as the SS MPS concept evolve. The major segments of this plan are as follows: an overview of the SS MPS and a description of its required capabilities including the computer programs identified as configurable items with an explanation of the place and function of each within the system; an overview of the project plan and a detailed description of each development project activity breaking each into lower level tasks where applicable; identification of the resources required and recommendations for the manner in which they should be utilized including recommended schedules and estimated manpower requirements; and a description of the practices, standards, and techniques recommended for the SS MPS Software (SW) development.

Klus, W. L.↗
NASA NTRS1994

The NASA Mission Operations and Control Architecture Program

The conflict between increases in space mission complexity and rapidly declining space mission budgets has created strong pressures to radically reduce the costs of designing and operating spacecraft. A key approach to achieving such reductions is through reducing the development and operations costs of the supporting mission operations systems. One of the efforts which the Communications and Data Systems Division at NASA Headquarters is using to meet this challenge is the Mission Operations Control Architecture (MOCA) project. Technical direction of this effort has been delegated to the Mission Operations Division (MOD) of the Goddard Space Flight Center (GSFC). MOCA is to develop a mission control and data acquisition architecture, and supporting standards, to guide the development of future spacecraft and mission control facilities at GSFC. The architecture will reduce the need for around-the-clock operations staffing, obtain a high level of reuse of flight and ground software elements from mission to mission, and increase overall system flexibility by enabling the migration of appropriate functions from the ground to the spacecraft. The end results are to be an established way of designing the spacecraft-ground system interface for GSFC's in-house developed spacecraft, and a specification of the end to end spacecraft control process, including data structures, interfaces, and protocols, suitable for inclusion in solicitation documents for future flight spacecraft. A flight software kernel may be developed and maintained in a condition that it can be offered as Government Furnished Equipment in solicitations. This paper describes the MOCA project, its current status, and the results to date.

Ondrus, Paul J.↗
NASA NTRS2014

Empirical and Face Validity of Software Maintenance Defect Models Used at the Jet Propulsion Laboratory

At the Mission Design and Navigation Software Group at the Jet Propulsion Laboratory we make use of finite exponential based defect models to aid in maintenance planning and management for our widely used critical systems. However a number of pragmatic issues arise when applying defect models for a post-release system in continuous use. These include: how to utilize information from problem reports rather than testing to drive defect discovery and removal effort, practical model calibration, and alignment of model assumptions with our environment.

software reliability↗
NASA NTRS2010

The General Mission Analysis Tool (GMAT): Current Features And Adding Custom Functionality

The General Mission Analysis Tool (GMAT) is a software system for trajectory optimization, mission analysis, trajectory estimation, and prediction developed by NASA, the Air Force Research Lab, and private industry. GMAT's design and implementation are based on four basic principles: open source visibility for both the source code and design documentation; platform independence; modular design; and user extensibility. The system, released under the NASA Open Source Agreement, runs on Windows, Mac and Linux. User extensions, loaded at run time, have been built for optimization, trajectory visualization, force model extension, and estimation, by parties outside of GMAT's development group. The system has been used to optimize maneuvers for the Lunar Crater Observation and Sensing Satellite (LCROSS) and ARTEMIS missions and is being used for formation design and analysis for the Magnetospheric Multiscale Mission (MMS).

Conway, Darrel J.↗
NASA NTRS2012

Tools Ensure Reliability of Critical Software

In November 2006, after attempting to make a routine maneuver, NASA's Mars Global Surveyor (MGS) reported unexpected errors. The onboard software switched to backup resources, and a 2-day lapse in communication took place between the spacecraft and Earth. When a signal was finally received, it indicated that MGS had entered safe mode, a state of restricted activity in which the computer awaits instructions from Earth. After more than 9 years of successful operation gathering data and snapping pictures of Mars to characterize the planet's land and weather communication between MGS and Earth suddenly stopped. Months later, a report from NASA's internal review board found the spacecraft's battery failed due to an unfortunate sequence of events. Updates to the spacecraft's software, which had taken place months earlier, were written to the wrong memory address in the spacecraft's computer. In short, the mission ended because of a software defect. Over the last decade, spacecraft have become increasingly reliant on software to carry out mission operations. In fact, the next mission to Mars, the Mars Science Laboratory, will rely on more software than all earlier missions to Mars combined. According to Gerard Holzmann, manager at the Laboratory for Reliable Software (LaRS) at NASA's Jet Propulsion Laboratory (JPL), even the fault protection systems on a spacecraft are mostly software-based. For reasons like these, well-functioning software is critical for NASA. In the same year as the failure of MGS, Holzmann presented a new approach to critical software development to help reduce risk and provide consistency. He proposed The Power of 10: Rules for Developing Safety-Critical Code, which is a small set of rules that can easily be remembered, clearly relate to risk, and allow compliance to be verified. The reaction at JPL was positive, and developers in the private sector embraced Holzmann's ideas.

Source record↗
NASA NTRS2000

IMAGE Software Suite

The IMAGE Mission is generating a truely unique set of magnetospheric measurement through a first-of-its-kind complement of remote, global observations. These data are being distributed in the Universal Data Format (UDF), which consists of data, calibration, and documentation. This is an open dataset, available to all by request to the National Space Science Data Center (NSSDC) at NASA Goddard Space Flight Center. Browse data, which consists of summary observations, is also available through the NSSDC in the Common Data Format (CDF) and graphic representations of the browse data. Access to the browse data can be achieved through the NSSDC CDAWeb services or by use of NSSDC provided software tools. This presentation documents the software tools, being provided by the IMAGE team, for use in viewing and analyzing the UDF telemetry data. Like the IMAGE data, these tools are openly available. What these tools can do, how they can be obtained, and how they are expected to evolve will be discussed.

Gallagher, Dennis L.↗
NASA NTRS2013

NASA Spinoff Article: Automated Procedures To Improve Safety on Oil Rigs

On May 11th, 2013, two astronauts emerged from the interior of the International Space Station (ISS) and worked their way toward the far end of spacecraft. Over the next 51/2 hours, the two replaced an ammonia pump that had developed a significant leak a few days before. On the ISS, ammonia serves the vital role of cooling components-in this case, one of the station's eight solar arrays. Throughout the extravehicular activity (EVA), the astronauts stayed in constant contact with mission control: every movement, every action strictly followed a carefully planned set of procedures to maximize crew safety and the chances of success. Though the leak had come as a surprise, NASA was prepared to handle it swiftly thanks in part to the thousands of procedures that have been written to cover every aspect of the ISS's operations. The ISS is not unique in this regard: Every NASA mission requires well-written procedures-or detailed lists of step-by-step instructions-that cover how to operate equipment in any scenario, from normal operations to the challenges created by malfunctioning hardware or software. Astronauts and mission control train and drill extensively in procedures to ensure they know what the proper procedures are and when they should be used. These procedures used to be exclusively written on paper, but over the past decade, NASA has transitioned to digital formats. Electronic-based documentation simplifies storage and use, allowing astronauts and flight controllers to find instructions more quickly and display them through a variety of media. Electronic procedures are also a crucial step toward automation: once instructions are digital, procedure display software can be designed to assist in authoring, reviewing, and even executing them.

traclabs↗
NASA NTRS2023

An Overview of Distributed Spacecraft Autonomy at NASA Ames

Autonomous decision-making significantly increases mission effectiveness by mitigating the effects of communication constraints, like latency and bandwidth, and mission complexity on multi-spacecraft operations. To advance the state of the art in autonomous Distributed Space Systems (DSS), the Distributed Spacecraft Autonomy (DSA) team at NASA's Ames Research Center is developing within five relevant technical areas: distributed resource and task management, reactive operations, system modeling and simulation, human-swarm interaction, and ad hoc network communications. DSA is maturing these technologies - critical for future large autonomous DSS - from concept to launch via simulation studies and orbital deployments. A 100-node heterogenous Processor-in-the-Loop (PiL) testbed aids distributed autonomy capability development and verification of multi-spacecraft missions. The DSA software payload deployed to the D-Orbit SCV-004 spacecraft demonstrates multi-agent reconfigurability and reliability as part of an ESA-sponsored in-orbit technology demonstration. Finally, DSA's primary flight mission showcases collaborative resource allocation for multipoint science data collection with four small spacecraft as a payload on NASA's Starling 1.0 satellites.

Caleb Ashmore Adams↗
NASA NTRS2009

Extreme Programming: Maestro Style

"Extreme Programming: Maestro Style" is the name of a computer programming methodology that has evolved as a custom version of a methodology, called extreme programming that has been practiced in the software industry since the late 1990s. The name of this version reflects its origin in the work of the Maestro team at NASA's Jet Propulsion Laboratory that develops software for Mars exploration missions. Extreme programming is oriented toward agile development of software resting on values of simplicity, communication, testing, and aggressiveness. Extreme programming involves use of methods of rapidly building and disseminating institutional knowledge among members of a computer-programming team to give all the members a shared view that matches the view of the customers for whom the software system is to be developed. Extreme programming includes frequent planning by programmers in collaboration with customers, continually examining and rewriting code in striving for the simplest workable software designs, a system metaphor (basically, an abstraction of the system that provides easy-to-remember software-naming conventions and insight into the architecture of the system), programmers working in pairs, adherence to a set of coding standards, collaboration of customers and programmers, frequent verbal communication, frequent releases of software in small increments of development, repeated testing of the developmental software by both programmers and customers, and continuous interaction between the team and the customers. The environment in which the Maestro team works requires the team to quickly adapt to changing needs of its customers. In addition, the team cannot afford to accept unnecessary development risk. Extreme programming enables the Maestro team to remain agile and provide high-quality software and service to its customers. However, several factors in the Maestro environment have made it necessary to modify some of the conventional extreme-programming practices. The single most influential of these factors is that continuous interaction between customers and programmers is not feasible.

Norris, Jeffrey↗
NASA NTRS2013

Mission Operations Center (MOC) - Precipitation Processing System (PPS) Interface Software System (MPISS)

MPISS is an automatic file transfer system that implements a combination of standard and mission-unique transfer protocols required by the Global Precipitation Measurement Mission (GPM) Precipitation Processing System (PPS) to control the flow of data between the MOC and the PPS. The primary features of MPISS are file transfers (both with and without PPS specific protocols), logging of file transfer and system events to local files and a standard messaging bus, short term storage of data files to facilitate retransmissions, and generation of file transfer accounting reports. The system includes a graphical user interface (GUI) to control the system, allow manual operations, and to display events in real time. The PPS specific protocols are an enhanced version of those that were developed for the Tropical Rainfall Measuring Mission (TRMM). All file transfers between the MOC and the PPS use the SSH File Transfer Protocol (SFTP). For reports and data files generated within the MOC, no additional protocols are used when transferring files to the PPS. For observatory data files, an additional handshaking protocol of data notices and data receipts is used. MPISS generates and sends to the PPS data notices containing data start and stop times along with a checksum for the file for each observatory data file transmitted. MPISS retrieves the PPS generated data receipts that indicate the success or failure of the PPS to ingest the data file and/or notice. MPISS retransmits the appropriate files as indicated in the receipt when required. MPISS also automatically retrieves files from the PPS. The unique feature of this software is the use of both standard and PPS specific protocols in parallel. The advantage of this capability is that it supports users that require the PPS protocol as well as those that do not require it. The system is highly configurable to accommodate the needs of future users.

Ferrara, Jeffrey↗
NASA NTRS1996

STS-77 Space Shuttle Mission Report

The STS-77 Space Shuttle Program Mission Report summarizes the Payload activities as well as the: Orbiter, External Tank (ET), Solid Rocket Booster (SRB), Reusable Solid Rocket Motor (RSRM), and the Space Shuttle Main Engine (SSME) systems performance during the seventy-seventh flight of the Space Shuttle Program, the fifty-second flight since the return-to-flight, and the eleventh flight of the Orbiter Endeavour (OV-105). STS-77 was also the last flight of OV-105 prior to the vehicle being placed in the Orbiter Maintenance Down Period (OMDP). In addition to the Orbiter, the flight vehicle consisted of an ET that was designated ET-78; three SSME's that were designated as serial numbers 2037, 2040, and 2038 in positions 1, 2, and 3, respectively; and two SRB's that were designated BI-080. The RSRM's, designated RSRM-47, were installed in each SRB and the individual RSRM's were designated as 360TO47A for the left SRB, and 360TO47B for the right SRB. The STS-77 Space Shuttle Program Mission Report fulfills the Space Shuttle Program requirement as documented in NSTS 07700, Volume VII, Appendix E. The requirement stated in that document is that each organizational element supporting the Program will report the results of their hardware (and software) evaluation and mission performance plus identify all related in-flight anomalies. The primary objectives of this flight were to successfully perform the operations necessary to fulfill the requirements of Spacehab-4, the SPARTAN 207/inflatable Antenna Experiment (IAE), and the Technology Experiments Advancing Missions in Space (TEAMS) payload. Secondary objectives of this flight were to perform the experiments of the Aquatic Research Facility (ARF), Brilliant Eyes Ten-Kelvin Sorption Cryocooler Experiment (BETSCE), Biological Research in Canisters (BRIC), Get-Away-Special (GAS), and GAS Bridge Assembly (GBA). The STS-77 mission was planned as a 9-day flight plus 1 day, plus 2 contingency days, which were available for weather avoidance or Orbiter contingency operations. The sequence of events for the STS-77 mission is shown in Table 1, and the Space Shuttle Vehicle Management Office Problem Tracking List is shown in Table 11. The Government Fumished Equipment/Flight Crew Equipment (GFE/FCE) Problem Tracking List is shown in Table II. Appendix A lists the sources of data, both formal and informal, that were used to prepare this report. Appendix B provides the definition of acronyms and abbreviations used throughout the report. All times during the flight are given in Greenwich mean time (G.m.t.) and mission elapsed time (MET). The six-person crew for STS-77 consisted of John H. Casper, Col., U. S. Air Force, Commander; Curtis L. Brown, Jr., Lt. Col., U. S. Air Force, Pilot; Andrew S. W. Thomas, Civilian, Ph.D., Mission Specialist 1; Daniel W. Bursch, CDR., U. S. Navy, Mission Specialist 2; Mario Runco, Jr., Civilian, Mission Specialist 3; and Marc Gameau, Civilian, PhD, Mission Specialist 4.

Fricke, Robert W., Jr.↗