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 955 records · Page 53

PHALANX: Expendable Projectile Sensor Networks for Planetary Exploration

Technologies enabling long-term, wide-ranging measurement in hard-to-reach areas are a critical need for planetary science inquiry. Phenomena of interest include flows or variations in volatiles, gas composition or concentration, particulate density, or even simply temperature. Improved measurement of these processes enables understanding of exotic geologies and distributions or correlating indicators of trapped water or biological activity. However, such data is often needed in unsafe areas such as caves, lava tubes, or steep ravines not easily reached by current spacecraft and planetary robots. To address this capability gap, we have developed miniaturized, expendable sensors which can be ballistically lobbed from a robotic rover or static lander - or even dropped during a flyover. These projectiles can perform sensing during flight and after anchoring to terrain features. By augmenting exploration systems with these sensors, we can extend situational awareness, perform long-duration monitoring, and reduce utilization of primary mobility resources, all of which are crucial in surface missions. We call the integrated payload that includes a cold gas launcher, smart projectiles, planning software, network discovery, and science sensing: PHALANX. In this paper, we introduce the mission architecture for PHALANX and describe an exploration concept that pairs projectile sensors with a rover “mothership.” Science use cases explored include reconnaissance using ballistic cameras, volatiles detection, and building timelapse maps of temperature and illumination conditions. Strategies to autonomously coordinate constellations of deployed sensors to self-discover and localize with peer ranging (i.e. a “local GPS”) are summarized, thus providing communications infrastructure beyond-line-of-sight (BLOS) of the rover. Capabilities were demonstrated through both simulation and physical testing with a terrestrial prototype. The approach to developing a terrestrial prototype is discussed, including design of the launching mechanism, projectile optimization, micro-electronics fabrication, and sensor selection. Results from early testing and characterization of commercial-off-the-shelf (COTS) components are reported. Nodes were subjected to successful burn-in tests over 48 hours at full logging duty cycle. Integrated field tests were conducted in the Roverscape, a half-acre planetary analog environment at NASA Ames, where we tested up to 10 sensor nodes simultaneously coordinating with an exploration rover. Ranging accuracy has been demonstrated to be within +/-10cm over 20m using commodity radios when compared to high-resolution laser scanner ground truthing. Evolution of the design, including progressive miniaturization of the electronics and iterated modifications of the enclosure housing for streamlining and optimized radio performance are described. Finally, lessons learned to date, gaps toward eventual flight mission implementation, and continuing future development plans are discussed.

Dille, Michael↗

Nodes - Network & Operation Demonstration Satellite

Nodes is a technology demonstration mission that will launch from the International Space Station (ISS) in early 2015 and will demonstrate new network capabilities critical to the operation of swarms of multiple spacecraft. Nodes continues the legacy of the PhoneSat series of small satellites that first introduced and successfully implemented the use of Android Smartphone technology to perform many of the spacecraft functions previously accomplished through custom technology development efforts. The Nodes mission consists of two 1.5-unit (1.5U) nanosatellites each weighing approximately 2 kilograms (4 pounds) and measuring 10 centimeters by 10 centimeters by 15 centimeters. The Nodes spacecraft are derived from the hardware and software developed for the EDSN (Edison Demonstration of Smallsat Networks) mission (a swarm of eight spacecraft). Each Node utilizes the Android operating system with EDSN-specific software programmed to perform command and data handling tasks that allow the satellites to 1) relay ground commands through one satellite to the second satellite, 2) collect and relay science data from each satellite to the ground station, and 3) autonomously determine which of the two satellites is best suited to control the space network and relay data to the ground (“Captain”) and notify the ground system and second satellite (“Lieutenant”) of the result.

Network and Operations↗

Electronic collection system for spacelab mission timeline requirements

This paper describes the Functional Objective Requirements Collection System (FORCS) software tool that has been developed for use by Principal Investigators (PI's) and Payload Element Developers (PED's) on their own personal computers to develop on-orbit timelining requirements for their payloads. The FORCS tool can be used either in a totally stand-alone mode, storing the information in a local file on the user's personal computer hard disk or in a remote mode where the user's computer is linked to a host computer containing the integrated database of the timeline requirements for all of the payloads on a mission. There are a number of features incorporated in the FORCS software to assist the user. The user may move freely back and forth between the various forms for inputting the data. Several methods are used to input the information, depending on the type of the information. These methods range from filling in text boxes, using check boxes and radio buttons, to inputting information into a spreadsheet format. There are automated features provided to assist in developing the proper format for the data, ranging from limit checking on some of the parameters to automatic conversion of different formats of time data inputs to the one standard format used for the timeline scheduling software.

Lindberg, James P.↗

Automated Target Planning for FUSE Using the SOVA Algorithm

The SOVA algorithm was originally developed under the Resilient Systems and Operations Project of the Engineering for Complex Systems Program from NASA s Aerospace Technology Enterprise as a conceptual framework to support real-time autonomous system mission and contingency management. The algorithm and its software implementation were formulated for generic application to autonomous flight vehicle systems, and its efficacy was demonstrated by simulation within the problem domain of Unmanned Aerial Vehicle autonomous flight management. The approach itself is based upon the precept that autonomous decision making for a very complex system can be made tractable by distillation of the system state to a manageable set of strategic objectives (e.g. maintain power margin, maintain mission timeline, and et cetera), which if attended to, will result in a favorable outcome. From any given starting point, the attainability of the end-states resulting from a set of candidate decisions is assessed by propagating a system model forward in time while qualitatively mapping simulated states into margins on strategic objectives using fuzzy inference systems. The expected return value of each candidate decision is evaluated as the product of the assigned value of the end-state with the assessed attainability of the end-state. The candidate decision yielding the highest expected return value is selected for implementation; thus, the approach provides a software framework for intelligent autonomous risk management. The name adopted for the technique incorporates its essential elements: Strategic Objective Valuation and Attainability (SOVA). Maximum value of the approach is realized for systems where human intervention is unavailable in the timeframe within which critical control decisions must be made. The Far Ultraviolet Spectroscopic Explorer (FUSE) satellite, launched in 1999, has been collecting science data for eight years.[1] At its beginning of life, FUSE had six gyros in two IRUs and four reaction wheels. Over time through various failures, the satellite has been left with one reaction wheel on the vehicle skew axis and two gyros. To remain operational, a control scheme has been implemented using the magnetic torque rods and the remaining momentum wheel.[2] As a consequence, there are attitude regions where there is insufficient torque authority to overcome environmental disturbances (e.g. gravity gradient torques). The situation is further complicated by the fact that these attitude regions shift inertially with time as the spacecraft moves through earth s magnetic field during the course of its orbit. Under these conditions, the burden of planning targets and target-to-target slew maneuvers has increased significantly since the beginning of the mission.[3] Individual targets must be selected so that the magnetic field remains roughly aligned with the skew wheel axis to provide enough control authority to the other two orthogonal axes. If the field moves too far away from the skew axis, the lack of control authority allows environmental torques to pull the satellite away from the target and can potentially cause it to tumble. Slew maneuver planning must factor the stability of targets at the beginning and end, and the torque authority at all points along the slew. Due to the time varying magnetic field geometry relative to any two inertial targets, small modifications in slew maneuver timing can make large differences in the achievability of a maneuver.

Heatwole, Scott↗

Is Structured Agile an Oxymoron? Tales from Implementing and Executing Agile in a US Government Environment

To paraphrase a famous quote, "No plan survives contact with the reality." Software (SW) development is often a classic example of this: whatever the plan was for a particular development, it often does not survive contact with technical realities, budget realities, program realities and schedule realities. Traditionally, SW development has followed a waterfall methodology with requirements being rigorously specified before the design, which was completed before the coding and unit testing started, which were in turn finished before validation and verification started. This model of SW engineering derives much from the HW engineering of large systems, and has been the standard methodology used in US government software acquisitions and systems for decades, with highly variable results. US Government SW requirements are built around Waterfall concepts, which assume that the plan will survive contact with reality, or at least that modifications to the plan are relatively small, and relatively few.Because of the inefficiencies and difficulties inherent in Waterfall, the commercial SW world started using a different SW development methodology called Agile more than 20 years ago. Agile believes that a plan should evolve and learn rapidly in response to the realities encountered. At its core, there are a few key elements of Agile:- A small team of people which is highly flexible and adaptive. The team collaborates and interoperates through sophisticated development architectures and release environments- An iterative, incremental development and release approach which is based upon the concept that knowledge comes from experience within the team, and that the team makes decisions based upon what it knows- A team culture which prizes transparency, inspection and adaptation. These values are necessary so that the team experience and decision making is transparent and responsive to the realities encountered during development and testingSo, how to use Agile in a US Government environment? GMSEC (Goddard Mission Services Evolution Center) develops satellite ground system software for NASA and other US Government agencies. The SW developed by the team contains a large code base of many applications used within satellite mission operations centers. It spans the full gamut of SW development types: from SW which is in a classic maintenance and sustainment mode, to new developments with a fairly well understood scope and approach, to new developments whose scope and approach are quite unclear and which require significant research and prototyping. Team members move between all of these different types of SW development. Waterfall was inadequate to the programmatic and technical needs of the team, as well as the various types of SW development being done. The software plan was not surviving contact with the technical and programmatic realities experienced by the team. To address this, the team started a small pilot project in 2016 to test the use of Agile within a small subset of the team for a new web services application. In early 2018, the use of Agile was expanded to the whole team and all the software, but we had to fulfill the NASA SW development requirements. And we needed to do this while still remaining true to the key Agile elements of transparency, inspection and adaption. In order to do this, the team worked very closely with the Software Process Improvement (SPI) team at NASA Goddard, as well as NASA engineering manageme

Beech, Theresa W.↗

Auto-Coding UML Statecharts for Flight Software

Statecharts have been used as a means to communicate behaviors in a precise manner between system engineers and software engineers. Hand-translating a statechart to code, as done on some previous space missions, introduces the possibility of errors in the transformation from chart to code. To improve auto-coding, we have developed a process that generates flight code from UML statecharts. Our process is being used for the flight software on the Space Interferometer Mission (SIM).

autocoding↗

Mapping the infrared background radiation from the Shuttle

The Spacelab-2 Small Helium-Cooled Infrared Telescope will be used to map extended astronomical sources of low surface brightness emission, to measure the Shuttle induced environment and to develop techniques for managing large volumes of superfluid helium in space. The instrument is an f/4 15.2-cm Herschelian telescope with ten photoconductor detectors in the focal plane. This paper describes the hardware and software aspects of the instrument with emphasis on mission operations. In particular, a description is given of the observing plan formulated to meet the scientific and engineering objectives, the scan drive system, the precautions in design and operation necessary to prevent the sun, moon, and earth from adversely affecting the observations, the implications of thruster firings, and the on-board experiment computer application software to control the scanning of the telescope and support on-board displays.

Koch, D.↗

Development of a Space Station Operations Management System

To enhance the productivity of operations aboard the Space Station, a means must be provided to augment, and frequently to supplant, human effort in support of mission operations and management, both on the ground and onboard. The Operations Management System (OMS), under development at the Johnson Space Center, is one such means. OMS comprises the tools and procedures to facilitate automation of station monitoring, control, and mission planning tasks. OMS mechanizes, and hence rationalizes, execution of tasks traditionally performed by mission planners, the mission control center team, onboard System Management software, and the flight crew.

Brandli, A. E.↗

Universal Lambert and Kepler algorithms for autonomous rendezvous

This paper describes Lambert and Kepler algorithms designed to be the core of an autonomous rendezvous guidance system for an onboard computer. Applications include robotic and piloted missions to the moon and planets. Flight software must be compact, fast, and totally reliable. Although high accuracy is not essential for flight, in double precision these algorithms are accurate to at least 14 places almost everywhere. Both are universal; they apply to elliptic, parabolic, hyperbolic, and even rectilinear trajectories. The algorithms are improvements to those published by Battin (1987).

Klumpp, Allan R.↗

An expert system to manage the operation of the Space Shuttle's fuel cell cryogenic reactant tanks

This paper describes a rule-based expert system to manage the operation of the Space Shuttle's cryogenic fuel system. Rules are based on standard fuel tank operating procedures described in the EECOM Console Handbook. The problem of configuring the operation of the Space Shuttle's fuel tanks is well-bounded and well defined. Moreover, the solution of this problem can be encoded in a knowledge-based system. Therefore, a rule-based expert system is the appropriate paradigm. Furthermore, the expert system could be used in coordination with power system simulation software to design operating procedures for specific missions.

Murphey, Amy Y.↗

An approach to the design and implementation of spacecraft attitude control systems

Over 39 years and a long list of missions, the guidance, navigation, and control (GN&C) groups at the Goddard Space Flight Center have gradually developed approaches to the design and implementation of successful spacecraft attitude control systems. With the recent creation of the Guidance, Navigation, and Control Center at Goddard, there is a desire to document some of these design practices to help to ensure their consistent application in the future. In this paper, we will discuss the beginnings of this effort, drawing primarily on the experience of one of the past attitude control system (ACS) groups at Goddard (what was formerly known as Code 712, the Guidance, Navigation, and Control Branch). We will discuss the analysis and design methods and criteria used, including guidelines for linear and nonlinear analysis, as well as the use of low- and high-fidelity simulation for system design and verification of performance. Descriptions of typical ACS sensor and actuator hardware will be shown, and typical sensor/actuator suites for a variety of mission types detailed. A description of the software and hardware test effort will be given, along with an attempt to make some qualitative estimates on how much effort is involved. The spacecraft and GN&C subsystem review cycles will be discussed, giving an outline of what design reviews are typically held and what information should be presented at each stage. Finally, we will point out some of the lessons learned at Goddard.

ODonnell, James R., Jr.↗

An Approach to the Design and Implementation of Spacecraft Attitude Control Systems

Over 39 years and a long list of missions, the guidance, navigation, and control (GN&C) groups at the Goddard Space Flight Center have gradually developed approaches to the design and implementation of successful spacecraft attitude control systems. With the recent creation of the Guidance, Navigation, and Control Center at Goddard, there is a desire to document some of these design practices to help to ensure their consistent application in the future. In this paper, we will discuss the beginnings of this effort, drawing primarily on the experience of one of the past attitude control system (ACS) groups at Goddard (what was formerly known as Code 712, the Guidance, Navigation, and Control Branch). We will discuss the analysis and design methods and criteria used, including guidelines for linear and nonlinear analysis, as well as the use of low- and high-fidelity simulation for system design and verification of performance. Descriptions of typical ACS sensor and actuator hardware will be shown, and typical sensor/actuator suites for a variety of mission types detailed. A description of the software and hardware test effort will be given, along with an attempt to make some qualitative estimates on how much effort is involved. The spacecraft and GN&C subsystem review cycles will be discussed, giving an outline of what design reviews are typically held and .what information should be presented at each stage. Finally, we will point out some of the lessons learned at Goddard.

ODonnell, James R., Jr.↗

Automatic Fault Protection in the Voyager Spacecraft

Due to reliability requirements placed on the Voyager spacecraft system design and a mission resulting in long two-way, light time communication links, on-board automatic fault detection and correction capabilities are a significant feature of that spacecraft's design. Most of the protection to otherwise mission-catastrophic failures is implemented in the software of the voyager's central computer, while some resides in an attitude control-dedicated processor. This paper will present the role that automatic fault protection plans in achieving Voyager's overall reliability, its design evolution, and how its design was validated during system testing. In-flight experience will also be described, and from the lessons learned there-in, conclusions and recommendations will be drawn for the benefit of future designs.

Jones, C. P.↗

The Propulsive Small Expendable Deployer System (ProSEDS)

This is the Annual Report #2 entitled "The Propulsive Small Expendable Deployer System (ProSEDS)" prepared by the Smithsonian Astrophysical Observatory for NASA Marshall Space Flight Center. This report covers the period of activity from 1 August 2000 through 30 July 2001. The topics include: 1) Updated System Performance; 2) Mission Analysis; 3) Updated Dynamics Reference Mission; 4) Updated Deployment Control Profiles and Simulations; 5) Comparison of ED tethers and electrical thrusters; 6) Kalman filters for mission estimation; and 7) Delivery of interactive software for ED tethers.

Lorenzini, Enrico C.↗

A survey of ground operations tools developed to simulate the pointing of space telescopes and the design for WISE

WISE, the Wide Field Infrared Survey Explorer, is scheduled for launch in June 2010. The mission operations system for WISE requires a software modeling tool to help plan, integrate and simulate all spacecraft pointing and verify that no attitude constraints are violated. In the course of developing the requirements for this tool, an investigation was conducted into the design of similar tools for other space-based telescopes. This paper summarizes the ground software and processes used to plan and validate pointing for a selection of space telescopes; with this information as background, the design for WISE is presented.

ground system↗

Intelligent systems in space : the EO-1 Autonomous Sciencecraft

The Autonomous Sciencecraft Software (ASE) is currently flying onboard the Earth Observing One (EO-1) Spacecraft. This software enables the spacecraft to autonomously detect and respond to science events occurring on the Earth. The package includes software systems that perform science data analysis, deliberative planning, and runtime robust execution. Because of the deployment to the EO-1 spacecraft, the ASE software has stringent constraints of autonomy and limited computing resources. We describe these constraints and how they are reflected in our operations approach. A summary of the final results of the experiment is also included. This software has demonstrated the potential for space missions to use onboard decision-making to detect, analyze, and respond to science events, and to downlink only the highest value science data. As a result, ground-based mission planning and analysis functions have been greatly simplified, thus reducing operations cost.

Earth Observing One (EO-1) Spacecraft↗