Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Ground 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 721 records · Page 40
All sourcesNASA NTRSDOE OSTI
NASA NTRS2008

Aquarius's Instrument Science Data System (ISDS) Automated to Acquire, Process, Trend Data and Produce Radiometric System Assessment Reports

The Aquarius Radiometer, a subsystem of the Aquarius Instrument required a data acquisition ground system to support calibration and radiometer performance assessment. To support calibration and compose performance assessments, we developed an automated system which uploaded raw data to a ftp server and saved raw and processed data to a database. This paper details the overall functionalities of the Aquarius Instrument Science Data System (ISDS) and the individual electrical ground support equipment (EGSE) which produced data files that were infused into the ISDS. Real time EGSEs include an ICDS Simulator, Calibration GSE, Labview controlled power supply, and a chamber data acquisition system. ICDS Simulator serves as a test conductor primary workstation, collecting radiometer housekeeping (HK) and science data and passing commands and HK telemetry collection request to the radiometer. Calibration GSE (Radiometer Active Test Source) provides source choice from multiple targets for the radiometer external calibration. Power Supply GSE, controlled by labview, provides real time voltage and current monitoring of the radiometer. And finally the chamber data acquisition system produces data reflecting chamber vacuum pressure, thermistor temperatures, AVG and watts. Each GSE system produce text based data files every two to six minutes and automatically copies the data files to the Central Archiver PC. The Archiver PC stores the data files, schedules automated uploads of these files to an external FTP server, and accepts request to copy all data files to the ISDS for offline data processing and analysis. Aquarius Radiometer ISDS contains PHP and MATLab programs to parse, process and save all data to a MySQL database. Analysis tools (MATLab programs) in the ISDS system are capable of displaying radiometer science, telemetry and auxiliary data in near real time as well as performing data analysis and producing automated performance assessment reports of the Aquarius Radiometer.

Source record↗
NASA NTRS1975

Viking mission operations

The Viking Flight Team and ground system must operate in an integrated manner with the two orbiters and two landers to acquire the scientific data that will significantly increase our knowledge of Mars. Viking mission requires an adaptive mode of flight operations which permits reflection of the knowledge gained as the mission progresses into subsequent data acquisition operations. This includes reflection of both the knowledge gained about Mars and knowledge as to how well each of the four vehicles and the ground data system are performing. The requirement for adaptive mission operations has imposed special considerations in the Viking mission design, landing site selection, organization of the Flight Team and in the design and development of the operational tools required by this team. A mission operations strategy has been developed which governs the multivehicle adaptive mission operations.

Young, A. T.↗
NASA NTRS2012

Automation and Process Improvement Enables a Small Team to Operate a Low Thrust Mission in Orbit Around the Asteroid Vesta

NASA's Dawn mission to the asteroid Vesta and dwarf planet Ceres launched September 27, 2007 and arrived at Vesta in July of 2011. This mission uses ion propulsion to achieve the necessary delta-V to reach and maneuver at Vesta and Ceres. This paper will show how the evolution of ground system automation and process improvement allowed a relatively small engineering team to transition from cruise operations to asteroid operations while maintaining robust processes. The cruise to Vesta phase lasted almost 4 years and consisted of activities that were built with software tools, but each tool was open loop and required engineers to review the output to ensure consistency. Additionally, this same time period was characterized by the evolution from manually retrieved and reviewed data products to automatically generated data products and data value checking. Furthermore, the team originally took about three to four weeks to design and build about four weeks of spacecraft activities, with spacecraft contacts only once a week. Operations around the asteroid Vesta increased the tempo dramatically by transitioning from one contact a week to three or four contacts a week, to fourteen contacts a week (every 12 hours). This was accompanied by a similar increase in activity complexity as well as very fast turn around activity design and build cycles. The design process became more automated and the tools became closed loop, allowing the team to build more activities without sacrificing rigor. Additionally, these activities were dependent on the results of flight system performance, so more automation was added to analyze the flight data and provide results in a timely fashion to feed the design cycle. All of this automation and process improvement enabled up the engineers to focus on other aspects of spacecraft operations, including spacecraft health monitoring and anomaly resolution.

ground system automation↗
NASA NTRS1988

Considerations in development of expert systems for real-time space applications

Over the years demand on space systems have been increased tremendously and this trend will continue for the near future. The enhanced capabilities of space systems, however, can only be met with increased complexity and sophistication of onboard and ground systems, and artificial intelligence and expert system concepts have a significant role in space applications. Expert systems could facilitate decision making, improved fault diagnosis and repair, enhanced performance and less reliance on ground support. However, some requirements have to be fulfilled before practical use of flight-worthy expert systems for onboard (and ground) operations. This paper discusses some of the characteristics and important considerations in design, development, implementation and use of expert systems for real-life space applications. Further, it describes a typical life cycle of expert system development and its usage.

Murugesan, S.↗
NASA NTRS1996

High Speed Simulator - A Simulator for All Seasons

This paper will discuss the evolution of the Multimission Ground Systems Office's (MGSO) High Speed Spacecraft Simulator (HSS) development at the Jet Propulsion Laboratory. This paper will examine the evolution from both a development and operations perspective. The HSS in reality is a series of simulators capable of modeling the spacecraft and its subsystems at either the bit or functional level, depending on specific mission needs.

command↗
NASA NTRS2010

Modeling and Performance Considerations for Automated Fault Isolation in Complex Systems

The purpose of this paper is to document the modeling considerations and performance metrics that were examined in the development of a large-scale Fault Detection, Isolation and Recovery (FDIR) system. The FDIR system is envisioned to perform health management functions for both a launch vehicle and the ground systems that support the vehicle during checkout and launch countdown by using suite of complimentary software tools that alert operators to anomalies and failures in real-time. The FDIR team members developed a set of operational requirements for the models that would be used for fault isolation and worked closely with the vendor of the software tools selected for fault isolation to ensure that the software was able to meet the requirements. Once the requirements were established, example models of sufficient complexity were used to test the performance of the software. The results of the performance testing demonstrated the need for enhancements to the software in order to meet the demands of the full-scale ground and vehicle FDIR system. The paper highlights the importance of the development of operational requirements and preliminary performance testing as a strategy for identifying deficiencies in highly scalable systems and rectifying those deficiencies before they imperil the success of the project

Ferrell, Bob↗
NASA NTRSDate not supplied

Fusion of Test and Analysis: Artemis I Booster to Mobile Launcher Interface Validation

NASA is in the midst of bold and exciting next steps in human exploration and spaceflight. The designs of the new Space Launch System (SLS), the Orion spacecraft and the Exploration Ground Systems (EGS) for vehicle processing and launch are essentially complete and there has been significant progress in manufacturing and assembly of specific hardware for the Artemis I and Artemis II missions. Equally as important, the program level and integrated system level testing and analyses are also well underway to support integrated verification, validation, and Certificate of Flight Readiness (CoFR) for Artemis I. Testing and analysis are key to addressing technical challenges faced by the Artemis missions. Building block approaches are required that provide the right balance between component, element, and/or system level testing that satisfies verification and validation objectives where uncertainties are quantified and minimized. Artemis I is a system of systems that requires a fusion of test and analysis that adeptly characterizes critical interfaces between major program elements. An example of this fusion involves characterizing the interface between the SLS booster and the Mobile Launcher (ML) Vertical Support Post (VSP) interfaces. Proper characterization of this interface represents a number of challenges beginning with the fact that it is a mating of ground support structure in the form of a civil structure to flight hardware. Both sides of the interface are built to different construction standards, but are governed by interface requirements to ensure compatibility when mated. From past program experience, the flexibility at the booster to ML interface is critical in developing accurate prelaunch stacking and cryogenic preloads, squat loads, and pad separation release of preloads and squat loads. This same premise holds for Artemis I. To characterize the asymmetric characteristics at this interface, careful consideration of static forces due to gravity loading with the commensurate effects due to leveling during booster stacking (i.e., spacing and shimming) and nonlinear geometric forces are necessary for inclusion in pre-test assessments. This paper will look at these issues for the upcoming Booster Pull Test in which two boosters will be installed on the ML and one of these boosters will undergo static lateral loading followed afterwards with dynamic excitation into resonance and free-decay. This paper evaluates the booster to ML interface characteristics by characterizing the interface flexibility between the booster aft skirt and the ML VSP interfaces. Furthermore, this paper methodically evaluates the effect of the following on the test outcome: gravitational effects on the booster and ML, the effects of VSP leveling, spacing, and shimming under gravitational loading during booster stacking, the effect of geometric nonlinear follower force due to cg offset as booster is laterally displaced, and the system coupling between the booster under test, ML, and the second booster. Simulated results for a static load pull and dynamic excitation provide insight into the differences in measurement responses when boundary conditions and geometric conditions are included and not included.

Joel W Sills Jr.↗
NASA NTRS2013

Citric Acid Alternative to Nitric Acid Passivation

The Ground Systems Development and Operations GSDO) Program at NASA John F. Kennedy Space Center (KSC) has the primary objective of modernizing and transforming the launch and range complex at KSC to benefit current and future NASA programs along with other emerging users. Described as the launch support and infrastructure modernization program in the NASA Authorization Act of 2010, the GSDO Program will develop and implement shared infrastructure and process improvements to provide more flexible, affordable, and responsive capabilities to a multi-user community. In support of the GSDO Program, the purpose of this project is to demonstratevalidate citric acid as a passivation agent for stainless steel. Successful completion of this project will result in citric acid being qualified for use as an environmentally preferable alternative to nitric acid for passivation of stainless steel alloys in NASA and DoD applications.

Technology↗
NASA NTRS2007

Mars Reconnaissance Orbiter Mission: Systems Engineering Challenges on the Mars Reconnaissance Orbiter Mission

MRO project is a system of systems requiring system engineering team to architect, design, integrate, test, and operate these systems at each level of the project. The challenge of system engineering mission objectives into a single mission architecture that can be integrated tested, launched, and operated. Systems engineering must translate high-level requirements into integrated mission design. Systems engineering challenges were overcome utilizing a combination by creative designs built into MRO's flight and ground systems: a) Design of sophisticated spacecraft targeting and data management capabilities b) Establishment of a strong operations team organization; c) Implementation of robust operational processes; and d) Development of strategic ground tools. The MRO system has met the challenge of its driving requirements: a) MRO began its two-year primary science phase on November 7, 2006, and by July 2007, met it minimum requirement to collect 15 Tbits of data after only eight months of operations. Currently we have collected 22 Tbits. b) Based on current performance, mission data return could return 70 Tbits of data by the end of the primary science phase in 2008.

systems engineering↗
NASA NTRS1972

Advanced ground support checkout systems.

The experience gained with the acceptance checkout equipment for spacecraft, which was used for checkout on the Apollo and Skylab Programs, is discussed in this paper and related to advanced ground systems for the Space Shuttle Program. The basic capabilities of the checkout system are outlined, goals for future checkout systems are discussed, and the unified test equipment system is described.

Osgood, D. R.↗
NASA NTRS2008

The First Development of Human Factors Engineering Requirements for Application to Ground Task Design for a NASA Flight Program

The National Aeronautics and Space Administration has long applied standards-derived human engineering requirements to the development of hardware and software for use by astronauts while in flight. The most important source of these requirements has been NASA-STD-3000. While there have been several ground systems human engineering requirements documents, none has been applicable to the flight system as handled at NASA's launch facility at Kennedy Space Center. At the time of the development of previous human launch systems, there were other considerations that were deemed more important than developing worksites for ground crews; e.g., hardware development schedule and vehicle performance. However, experience with these systems has shown that failure to design for ground tasks has resulted in launch schedule delays, ground operations that are more costly than they might be, and threats to flight safety. As the Agency begins the development of new systems to return humans to the moon, the new Constellation Program is addressing this issue with a new set of human engineering requirements. Among these requirements is a subset that will apply to the design of the flight components and that is intended to assure ground crew success in vehicle assembly and maintenance tasks. These requirements address worksite design for usability and for ground crew safety.

Dischinger, H. Charles, Jr.↗
NASA NTRS2002

Using Pilots to Assess the Value and Approach of CMMI Implementation

At Goddard Space Flight Center (GSFC), we have chosen to use Capability Maturity Model Integrated (CMMI) to guide our process improvement program. Projects at GSFC consist of complex systems of software and hardware that control satellites, operate ground systems, run instruments, manage databases and data and support scientific research. It is a challenge to launch a process improvement program that encompasses our diverse systems, yet is manageable in terms of cost effectiveness. In order to establish the best approach for improvement, our process improvement effort was divided into three phases: 1) Pilot projects; 2) Staged implementation; and 3) Sustainment and continual improvement. During Phase 1 the focus of the activities was on a baselining process, using pre-appraisals in order to get a baseline for making a better cost and effort estimate for the improvement effort. Pilot pre-appraisals were conducted from different perspectives so different approaches for process implementation could be evaluated. Phase 1 also concentrated on establishing an improvement infrastructure and training of the improvement teams. At the time of this paper, three pilot appraisals have been completed. Our initial appraisal was performed in a flight software area, considering the flight software organization as the organization. The second appraisal was done from a project perspective, focusing on systems engineering and acquisition, and using the organization as GSFC. The final appraisal was in a ground support software area, again using GSFC as the organization. This paper will present our initial approach, lessons learned from all three pilots and the changes in our approach based on the lessons learned.

Godfrey, Sara↗
NASA NTRS1969

Automatic frequency control of voltage-controlled oscillators

Optical-capacitive coupling is used for isolation of control voltages, such as the high-voltage level of a klystron control electrode that is not referenced to ground, to serve as error voltages referenced to system ground so that the magnitude and sense of correction may be transferred.

Kolbly, R. B.↗
NASA NTRS1977

LANDSAT D operations control center study

Various aspects of the planned LANDSAT D system are discussed. LANDSAT D incorporates the Thematic Mapper (TM) as a sensor, it utilizes the Multi-mission Modular Spacecraft (MMS), it makes use of the Tracking and Data Relay Satellite System (TDRSS) and it employs a more advanced ground system. Each of these represent significant improvements in the state-of-the-art.

Alexander, L.↗
NASA NTRS2002

Lessons Learned In Developing Multiple Distributed Planning Systems for the International Space Station

The planning processes for the International Space Station (ISS) Program are quite complex. Detailed mission planning for ISS on-orbit operations is a distributed function. Pieces of the on-orbit plan are developed by multiple planning organizations, located around the world, based on their respective expertise and responsibilities. The "pieces" are then integrated to yield the final detailed plan that will be executed onboard the ISS. Previous space programs have not distributed the planning and scheduling functions to this extent. Major ISS planning organizations are currently located in the United States (at both the NASA Johnson Space Center (JSC) and NASA Marshall Space Flight Center (MSFC)), in Russia, in Europe, and in Japan. Software systems have been developed by each of these planning organizations to support their assigned planning and scheduling functions. Although there is some cooperative development and sharing of key software components, each planning system has been tailored to meet the unique requirements and operational environment of the facility in which it operates. However, all the systems must operate in a coordinated fashion in order to effectively and efficiently produce a single integrated plan of ISS operations, in accordance with the established planning processes. This paper addresses lessons learned during the development of these multiple distributed planning systems, from the perspective of the developer of one of the software systems. The lessons focus on the coordination required to allow the multiple systems to operate together, rather than on the problems associated with the development of any particular system. Included in the paper is a discussion of typical problems faced during the development and coordination process, such as incompatible development schedules, difficulties in defining system interfaces, technical coordination and funding for shared tools, continually evolving planning concepts/requirements, programmatic and budget issues, and external influences. Techniques that mitigated some of these problems will also be addressed, along with recommendations for any future programs involving the development of multiple planning and scheduling systems. Many of these lessons learned are not unique to the area of planning and scheduling systems, so may be applied to other distributed ground systems that must operate in concert to successfully support space mission operations.

Maxwell, Theresa G.↗
NASA NTRS2002

Lessons Learned in Developing Multiple Distributed Planning Systems for the International Space Station

The planning processes for the International Space Station (ISS) Program are quite complex. Detailed mission planning for ISS on-orbit operations is a distributed function. Pieces of the on-orbit plan are developed by multiple planning organizations, located around the world, based on their respective expertise and responsibilities. The pieces are then integrated to yield the final detailed plan that will be executed onboard the ISS. Previous space programs have not distributed the planning and scheduling functions to this extent. Major ISS planning organizations are currently located in the United States (at both the NASA Johnson Space Center (JSC) and NASA Marshall Space Flight Center (MSFC)), in Russia, in Europe, and in Japan. Software systems have been developed by each of these planning organizations to support their assigned planning and scheduling functions. Although there is some cooperative development and sharing of key software components, each planning system has been tailored to meet the unique requirements and operational environment of the facility in which it operates. However, all the systems must operate in a coordinated fashion in order to effectively and efficiently produce a single integrated plan of ISS operations, in accordance with the established planning processes. This paper addresses lessons learned during the development of these multiple distributed planning systems, from the perspective of the developer of one of the software systems. The lessons focus on the coordination required to allow the multiple systems to operate together, rather than on the problems associated with the development of any particular system. Included in the paper is a discussion of typical problems faced during the development and coordination process, such as incompatible development schedules, difficulties in defining system interfaces, technical coordination and funding for shared tools, continually evolving planning concepts/requirements, programmatic and budget issues, and external influences. Techniques that mitigated some of these problems will also be addressed, along with recommendations for any future programs involving the development of multiple planning and scheduling systems. Many of these lessons learned are not unique to the area of planning and scheduling systems, so may be applied to other distributed ground systems that must operate in concert to successfully support space mission operations.

Maxwell, Theresa G.↗