Search NASA⌕ Search

SEARCH · Search NASA

Results for “ground data system”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 235 records · Page 13
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

Test/score/report: Simulation techniques for automating the test process

A Test/Score/Report capability is currently being developed for the Transportable Payload Operations Control Center (TPOCC) Advanced Spacecraft Simulator (TASS) system which will automate testing of the Goddard Space Flight Center (GSFC) Payload Operations Control Center (POCC) and Mission Operations Center (MOC) software in three areas: telemetry decommutation, spacecraft command processing, and spacecraft memory load and dump processing. Automated computer control of the acceptance test process is one of the primary goals of a test team. With the proper simulation tools and user interface, the task of acceptance testing, regression testing, and repeatability of specific test procedures of a ground data system can be a simpler task. Ideally, the goal for complete automation would be to plug the operational deliverable into the simulator, press the start button, execute the test procedure, accumulate and analyze the data, score the results, and report the results to the test team along with a go/no recommendation to the test team. In practice, this may not be possible because of inadequate test tools, pressures of schedules, limited resources, etc. Most tests are accomplished using a certain degree of automation and test procedures that are labor intensive. This paper discusses some simulation techniques that can improve the automation of the test process. The TASS system tests the POCC/MOC software and provides a score based on the test results. The TASS system displays statistics on the success of the POCC/MOC system processing in each of the three areas as well as event messages pertaining to the Test/Score/Report processing. The TASS system also provides formatted reports documenting each step performed during the tests and the results of each step. A prototype of the Test/Score/Report capability is available and currently being used to test some POCC/MOC software deliveries. When this capability is fully operational it should greatly reduce the time necessary to test a POCC/MOC software delivery, as well as improve the quality of the test process.

Hageman, Barbara H.↗
NASA NTRS1999

SIRTF Science Operations System Design

SIRTF Science Operations System Design William B. Green Manager, SIRTF Science Center California Institute of Technology M/S 310-6 1200 E. California Blvd., Pasadena CA 91125 (626) 395 8572 Fax (626) 568 0673 bgreen@ipac.caltech.edu. The Space Infrared Telescope Facility (SIRTF) will be launched in December 2001, and perform an extended series of science observations at wavelengths ranging from 20 to 160 microns for five years or more. The California Institute of Technology has been selected as the home for the SIRTF Science Center (SSC). The SSC will be responsible for evaluating and selecting observation proposals, providing technical support to the science community, performing mission planning and science observation scheduling activities, instrument calibration during operations and instrument health monitoring, production of archival quality data products, and management of science research grants. The science payload consists of three instruments delivered by instrument Principal Investigators located at University of Arizona, Cornell, and Harvard Smithsonian Astrophysical Observatory. The SSC is responsible for design, development, and operation of the Science Operations System (SOS) which will support the functions assigned to the SSC by NASA. The SIRTF spacecraft, mission profile, and science instrument design have undergone almost ten years of refinement. SIRTF development and operations activities are highly cost constrained. The cost constraints have impacted the design of the SOS in several ways. The Science Operations System has been designed to incorporate a set of efficient, easy to use tools which will make it possible for scientists to propose observation sequences in a rapid and automated manner. The use of highly automated tools for requesting observations will simplify the long range observatory scheduling process, and the short term scheduling of science observations. Pipeline data processing will be highly automated and data-driven, utilizing a variety of tools developed at JPL, the instrument development teams, and Space Telescope Science Institute to automate processing. An incremental ground data system development approach has been adopted, featuring periodic deliveries that are validated with the flight hardware throughout the various phases of system level development and testing. This approach minimizes development time and decreases operations risk. This paper will describe the top level architecture of the SOS and the basic design concepts. A summary of the incremental development approach will be presented. Examples of the unique science user tools now under final development prior to the first proposal call scheduled for mid-2000 will be shown.

Green, William↗
NASA NTRSDate not supplied

Commanding Constellations (Pipeline Architecture)

Providing ground command software for constellations of spacecraft is a challenging problem. Reliable command delivery requires a feedback loop; for a constellation there will likely be an independent feedback loop for each constellation member. Each command must be sent via the proper Ground Station, which may change from one contact to the next (and may be different for different members). Dynamic configuration of the ground command software is usually required (e.g. directives to configure each member's feedback loop and assign the appropriate Ground Station). For testing purposes, there must be a way to insert command data at any level in the protocol stack. The Pipeline architecture described in this paper can support all these capabilities with a sequence of software modules (the pipeline), and a single self-identifying message format (for all types of command data and configuration directives). The Pipeline architecture is quite simple, yet it can solve some complex problems. The resulting solutions are conceptually simple, and therefore, reliable. They are also modular, and therefore, easy to distribute and extend. We first used the Pipeline architecture to design a CCSDS (Consultative Committee for Space Data Systems) Ground Telecommand system (to command one spacecraft at a time with a fixed Ground Station interface). This pipeline was later extended to include gateways to any of several Ground Stations. The resulting pipeline was then extended to handle a small constellation of spacecraft. The use of the Pipeline architecture allowed us to easily handle the increasing complexity. This paper will describe the Pipeline architecture, show how it was used to solve each of the above commanding situations, and how it can easily be extended to handle larger constellations.

Tim Ray↗
NASA NTRS2018

F Prime: An Open-Source Framework for Small-Scale Flight Software Systems

Developing flight software for small-scale missions such as CubeSats and SmallSats is challenging. These missions typically have ambitious goals, modest budgets, and tight schedules. To meet these challenges, a good flight software framework is essential. Frameworks can provide an architecture, infrastructure, tools, and reusable software components, all of which can help developers deliver their code on time and on budget. In this paper we present F Prime, a free, open-source flight software framework developed at JPL and tailored to small-scale systems such as CubeSats, SmallSats, and instruments. F Prime comprises several elements: (1) an architecture that decomposes flight software into discrete components with well-defined interfaces; (2) a C++ framework that provides core capabilities such as message queues and threads; (3) tools for specifying components and connections and automatically generating code; (4) a growing collection of ready-to-use components; and (5) tools for testing flight software at the unit and integration levels.We describe the F Prime framework and tools and present our experience using them. We describe several enhancements to the framework currently underway in the areas of software design, software verification, and ground data systems for testing.

Levison, Jeffrey W.↗
NASA NTRS1994

Automatic commanding of the Mars Observer Camera

Mars Observer, launched in September 1992, was intended to be a 'survey-type' mission that acquired global coverage of Mars from a low, circular, near-polar orbit during an entire Martian year. As such, most of its instruments had fixed data rates, wide fields of view, and relatively low resolution, with fairly limited requirements for commanding. An exception is the Mars Observer Camera, or MOC. The MOC consists of a two-color Wide Angle (WA) system that can acquire both global images at low resolution (7.5 km/pixel) and regional images at commandable resolutions up to 250 m/pixel. Complementing the WA is the Narrow Angle (NA) system, that can acquire images at 8 resolutions from 12 m/pixel to 1.5 m/pixel, with a maximum crosstrack dimension of 3 km. The MOC also provides various forms of data compression (both lossless and lossy), and is designed to work at data rates from 700 bits per second (bps) to over 80k bps. Because of this flexibility, developing MOC command sequences is much more difficult than the routine mode-changing that characterizes other instrument operations. Although the MOC cannot be pointed (the spacecraft is fixed nadir-pointing and has no scan platform), the timing, downlink stream allocation, compression type and parameters, and image dimensions of each image must be commanded from the ground, subject to the constraints inherent in the MOC and the spacecraft. To minimize the need for a large operations staff, the entire command generation process has been automated within the MOC Ground Data System. Following the loss of the Mars Observer spacecraft in August 1993, NASA intends to launch a new spacecraft, Mars Global Surveyor (MGS), in late 1996. This spacecraft will carry the MOC flight spare (MOC 2). The MOC 2 operations plan will be largely identical to that developed for MOC, and all of the algorithms described here are applicable to it.

Caplinger, Michael↗
NASA NTRS2022

Mission Planning for Trident: Discovery proposal to Neptune’s moon, Triton

Trident was one of the four Discovery-class Step-1 mission proposals selected by NASA in 2020 for further development and study; however, in 2021, the Step-2 proposal was not down-selected to transition into the next phase of mission development, i.e., a mission for flight.Neptune’s largest moon, Triton, was the primary focus of study for Trident. Triton’s physical and orbital characteristics make it a unique planetary target for scientific exploration, providing opportunities for investigations in a wide variety of scientific fields, including geomorphological, atmospheric, geophysical, magnetospheric, and ionospheric studies. The science objectives of the Trident mission encompassed an in-depth interior-to-exterior set of objectives, focused on multiple outstanding questions resulting from the 1989 encounter of Voyager 2, and subsequent analysis.Ball Aerospace Corp. was tasked with building the Trident spacecraft, with JPL responsible for providing Engineering Support (Mission Design & Navigation, Mission Planning, Flight Operations, Ground Data Systems, Systems Engineering) and leading Project Management. The observatory would carry a wide-ranging suite of scientific instruments onboard, including an Infrared Spectrometer (IRS) and Narrow Angle Camera (NAC) to be provided by Ball Aerospace Corp., a Wide Angle Camera (WAC) from JPL, a Magnetometer from UCLA, a contributed Plasma Science Suite from IRF (Sweden), and a contributed Radio Science instrument from ASI (Italy). All of these instruments would be used to collect unique datasets during the Triton encounter. Trident would have taken advantage of an ~13-yr, nearly-ballistic trajectory to Triton, utilizing a timely Jupiter Gravity Assist, to execute a 10-day long encounter in the Neptunian system. Launch was planned for October 2025, with Triton arrival scheduled for December 2038. The timeline for this mission would have been sub-divided into seven major phases: Launch, Commissioning, Inner Planet Cruise, Outer Planet Cruise, Approach, Encounter, and Science Data Return. Multiple planetary flybys were planned to be performed during the cruise, including three Earth flybys and one Venus flyby in the Inner Planet Cruise phase, and one Jupiter flyby in the Outer Planet Cruise phase. Along with conventional (Range and Doppler) tracking data, Delta-DOR and Optical Navigation data were also to be acquired to assist with spacecraft navigation during the Approach and Encounter phases. A 3 meter X-Band High Gain Antenna would allow playback of all science data at 1 kbps within 1 year after the Triton Encounter. The Mission Planning element on Trident encompassed and informed multiple aspects of this proposal, ranging from science observation planning during the Triton Encounter phase, to generation of activity timelines for all mission phases; performing ground coverage analysis for science observations to be acquired by all instruments and tracing them to science requirements; evaluation of spacecraft resources including data volume stored onboard, power/energy consumption, telecom (commanding/telemetry) requirements, and overall, working at the interface of science and engineering teams on the mission. All of these functions that were performed by the Mission Planning team on this proposal are discussed in this paper.

Prockter, Louise↗
NASA NTRS1976

Pioneer Venus 1978 mission support

The Tracking and Data Acquisition portion of the Ground Data System, which will support the Differential Long Baseline Interferometry Wind Measurement Experiment, is described.

Miller, R. B.↗
NASA NTRS1976

Helios mission support

The Helios-1 third solar occultation and fourth perihelion is covered. A Helios-2 spacecraft emergency and third solar conjunction (occultation) are also discussed. Additional topics include STDN-DSN telemetry and command cross-support, Ground Data System tests, tracking coverage, plus DSN system performance for August and September 1976.

Goodwin, P. S.↗
NASA NTRS1980

DSS command software update

The modifications, additions, and testing results for a version of the Deep Space Station command software, generated for support of the Voyager Saturn encounter, are discussed. The software update requirements included efforts to: (1) recode portions of the software to permit recovery of approximately 2000 words of memory; (2) correct five Voyager Ground data System liens; (3) provide capability to automatically turn off the command processor assembly local printer during periods of low activity; and (4) correct anomalies existing in the software.

Stinnett, W. G.↗
NASA NTRS1988

Generic telemetry processing

The Space Flight Operations Center (SFOC) is a generic suite of ground data systems software. One main subsystem of SFOC is the Telemetry Input Subsystem (TIS). Utilizing techniques for the abstract representation of data, the TIS has provided a flexible software base that can be used as a baseline for multiple spacecraft missions.

Pettit, Richard L., Jr.↗
NASA NTRS1990

Resource Allocation Planning Helper (RALPH): Lessons learned

The current task of Resource Allocation Process includes the planning and apportionment of JPL's Ground Data System composed of the Deep Space Network and Mission Control and Computing Center facilities. The addition of the data driven, rule based planning system, RALPH, has expanded the planning horizon from 8 weeks to 10 years and has resulted in large labor savings. Use of the system has also resulted in important improvements in science return through enhanced resource utilization. In addition, RALPH has been instrumental in supporting rapid turn around for an increased volume of special what if studies. The status of RALPH is briefly reviewed and important lessons learned from the creation of an highly functional design team are focused on through an evolutionary design and implementation period in which an AI shell was selected, prototyped, and ultimately abandoned, and through the fundamental changes to the very process that spawned the tool kit. Principal topics include proper integration of software tools within the planning environment, transition from prototype to delivered to delivered software, changes in the planning methodology as a result of evolving software capabilities and creation of the ability to develop and process generic requirements to allow planning flexibility.

Durham, Ralph↗
NASA NTRS1992

Space Station Freedom payload operations from the user's perspective

This report describes the Microgravity Science and Applications Division's (MSAD) operations concept for using the Space Station Freedom (SSF) program ground data systems and services, and the plans for and capabilities of the MSAD remote User Operations Facilities (UOF) from which the MSAD SSF payloads will be operated. Attention is given to the MSAD operational phases, the MSAD UOF concept, and UOF operations teams. MSAD is planning remote payload operations for a number of Spacelab missions which will supply MSAD valuable information for application to the development of UOFs in the SSF era.

Robey, J. L.↗
NASA NTRS1992

Image processing and products for the Magellan mission to Venus

The Magellan mission to Venus is providing planetary scientists with massive amounts of new data about the surface geology of Venus. Digital image processing is an integral part of the ground data system that provides data products to the investigators. The mosaicking of synthetic aperture radar (SAR) image data from the spacecraft is being performed at JPL's Multimission Image Processing Laboratory (MIPL). MIPL hosts and supports the Image Data Processing Subsystem (IDPS), which was developed in a VAXcluster environment of hardware and software that includes optical disk jukeboxes and the TAE-VICAR (Transportable Applications Executive-Video Image Communication and Retrieval) system. The IDPS is being used by processing analysts of the Image Data Processing Team to produce the Magellan image data products. Various aspects of the image processing procedure are discussed.

Clark, Jerry↗
NASA NTRS1991

The Space Flight Operations Center first phase - Lessons learned

This paper is a retrospective look at the Space Flight Operations Center Project; a large, complex, multimission ground data system which is currently under development at the Jet Propulsion Laboratory (JPL), Pasadena. The Project was established in February 1984 and will be completed in April 1992 when the Magellan, Voyager, Ulysses, Galileo and Mars Observer Projects will be fully supported. The first phase of this project covers the development of a subset of multimission Baseline subsystems, the development of the mission-specific adaptations to this Baseline set for the Magellan Project, the development of a Magellan-specific high rate processor together with the delivery of these subsystems to operations. This first phase became operational in January 1989 in readiness for the Magellan launch in May 1989.

Gainsborough, A. J.↗
NASA NTRS1993

Magellan spacecraft and memory state tracking: Lessons learned, future thoughts

Numerous studies have been dedicated to improving the two main elements of Spacecraft Mission Operations: Command and Telemetry. As a result, not much attention has been given to other tasks that can become tedious, repetitive, and error prone. One such task is Spacecraft and Memory State Tracking, the process by which the status of critical spacecraft components, parameters, and the contents of on-board memory are managed on the ground to maintain knowledge of spacecraft and memory states for future testing, anomaly investigation, and on-board memory reconstruction. The task of Spacecraft and Memory State Tracking has traditionally been a manual task allocated to Mission Operations Procedures. During nominal Mission Operations this job is tedious and error prone. Because the task is not complex and can be accomplished manually, the worth of a sophisticated software tool is often questioned. However, in the event of an anomaly which alters spacecraft components autonomously or a memory anomaly such as a corrupt memory or flight software error, an accurate ground image that can be reconstructed quickly is a priceless commodity. This study explores the process of Spacecraft and Memory State Tracking used by the Magellan Spacecraft Team highlighting its strengths as well as identifying lessons learned during the primary and extended missions, two memory anomalies, and other hardships encountered due to incomplete knowledge of spacecraft states. Ideas for future state tracking tools that require minimal user interaction and are integrated into the Ground Data System will also be discussed.

Bucher, Allen W.↗
NASA NTRS1993

Management of information for mission operations using automated keyword referencing

Although millions of dollars have helped to improve the operability and technology of ground data systems for mission operations, almost all mission documentation remains bound in printed volumes. This form of documentation is difficult and timeconsuming to use, may be out-of-date, and is usually not cross-referenced with other related volumes of mission documentation. A more effective, automated method of mission information access is needed. A new method of information management for mission operations using automated keyword referencing is proposed. We expound on the justification for and the objectives of this concept. The results of a prototype tool for mission information access that uses a hypertextlike user interface and existing mission documentation are shared. Finally, the future directions and benefits of our proposed work are described.

Davidson, Roger A.↗
NASA NTRS1993

Security aspects of space operations data

This paper deals with data security. It identifies security threats to European Space Agency's (ESA) In Orbit Infrastructure Ground Segment (IOI GS) and proposes a method of dealing with its complex data structures from the security point of view. It is part of the 'Analysis of Failure Modes, Effects Hazards and Risks of the IOI GS for Operations, including Backup Facilities and Functions' carried out on behalf of the European Space Operations Center (ESOC). The security part of this analysis has been prepared with the following aspects in mind: ESA's large decentralized ground facilities for operations, the multiple organizations/users involved in the operations and the developments of ground data systems, and the large heterogeneous network structure enabling access to (sensitive) data which does involve crossing organizational boundaries. An IOI GS data objects classification is introduced to determine the extent of the necessary protection mechanisms. The proposal of security countermeasures is oriented towards the European 'Information Technology Security Evaluation Criteria (ITSEC)' whose hierarchically organized requirements can be directly mapped to the security sensitivity classification.

Schmitz, Stefan↗