Search NASA⌕ Search

SEARCH · Search NASA

Results for “integrated system testing”

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 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS1995

Spacecraft System Integration and Test: SSTI Lewis critical design audit

The Critical Design Audit package is the final detailed design package which provides a comprehensive description of the SSTI mission. This package includes the program overview, the system requirements, the science and applications activities, the ground segment development, the assembly, integration and test description, the payload and technology demonstrations, and the spacecraft bus subsystems. Publication and presentation of this document marks the final requirements and design freeze for SSTI.

Brooks, R. P.↗
NASA NTRS2015

Integrated Test Approach

This paper describes a testing methodology undertaken on the Facilities Development and Operations Contract (FDOC) by Lockheed Martin. The methodology was defined with the intent of reducing project schedule time to enable NASA's Johnson Space Center (JSC) to be able to deliver the Mission Control Center (MCC) 21 project as quickly as possible. 21 represents the 21st century where NASA JSC is updating its control center with new technology and operational concepts in order to support NASA customers wanting to use control center assets to support space vehicle operations. In collaboration with the NASA customer, a new test concept was conceived early during MCC21 project planning with the goal of reducing project delivery time. One enabler that could help reduce delivery time was testing. Within the project, testing was performed by two entities, software development responsible for subsystem testing and system test responsible for system integration testing. The MCC21 project took a deliberate review of testing to determine how it could be performed differently to realize an overall reduction in test time to support the goal of a more rapid project delivery.

Cotton, Will↗
NASA NTRS1989

Detection and avoidance of errors in computer software

The acceptance test errors of a computer software project to determine if the errors could be detected or avoided in earlier phases of development. GROAGSS (Gamma Ray Observatory Attitude Ground Support System) was selected as the software project to be examined. The development of the software followed the standard Flight Dynamics Software Development methods. GROAGSS was developed between August 1985 and April 1989. The project is approximately 250,000 lines of code of which approximately 43,000 lines are reused from previous projects. GROAGSS had a total of 1715 Change Report Forms (CRFs) submitted during the entire development and testing. These changes contained 936 errors. Of these 936 errors, 374 were found during the acceptance testing. These acceptance test errors were first categorized into methods of avoidance including: more clearly written requirements; detail review; code reading; structural unit testing; and functional system integration testing. The errors were later broken down in terms of effort to detect and correct, class of error, and probability that the prescribed detection method would be successful. These determinations were based on Software Engineering Laboratory (SEL) documents and interviews with the project programmers. A summary of the results of the categorizations is presented. The number of programming errors at the beginning of acceptance testing can be significantly reduced. The results of the existing development methodology are examined for ways of improvements. A basis is provided for the definition is a new development/testing paradigm. Monitoring of the new scheme will objectively determine its effectiveness on avoiding and detecting errors.

Kinsler, Les↗
NASA NTRS2006

NASA Stennis Space Center Integrated System Health Management Test Bed and Development Capabilities

Integrated System Health Management (ISHM) is a capability that focuses on determining the condition (health) of every element in a complex System (detect anomalies, diagnose causes, prognosis of future anomalies), and provide data, information, and knowledge (DIaK)-not just data-to control systems for safe and effective operation. This capability is currently done by large teams of people, primarily from ground, but needs to be embedded on-board systems to a higher degree to enable NASA's new Exploration Mission (long term travel and stay in space), while increasing safety and decreasing life cycle costs of spacecraft (vehicles; platforms; bases or outposts; and ground test, launch, and processing operations). The topics related to this capability include: 1) ISHM Related News Articles; 2) ISHM Vision For Exploration; 3) Layers Representing How ISHM is Currently Performed; 4) ISHM Testbeds & Prototypes at NASA SSC; 5) ISHM Functional Capability Level (FCL); 6) ISHM Functional Capability Level (FCL) and Technology Readiness Level (TRL); 7) Core Elements: Capabilities Needed; 8) Core Elements; 9) Open Systems Architecture for Condition-Based Maintenance (OSA-CBM); 10) Core Elements: Architecture, taxonomy, and ontology (ATO) for DIaK management; 11) Core Elements: ATO for DIaK Management; 12) ISHM Architecture Physical Implementation; 13) Core Elements: Standards; 14) Systematic Implementation; 15) Sketch of Work Phasing; 16) Interrelationship Between Traditional Avionics Systems, Time Critical ISHM and Advanced ISHM; 17) Testbeds and On-Board ISHM; 18) Testbed Requirements: RETS AND ISS; 19) Sustainable Development and Validation Process; 20) Development of on-board ISHM; 21) Taxonomy/Ontology of Object Oriented Implementation; 22) ISHM Capability on the E1 Test Stand Hydraulic System; 23) Define Relationships to Embed Intelligence; 24) Intelligent Elements Physical and Virtual; 25) ISHM Testbeds and Prototypes at SSC Current Implementations; 26) Trailer-Mounted RETS; 27) Modeling and Simulation; 28) Summary ISHM Testbed Environments; 29) Data Mining - ARC; 30) Transitioning ISHM to Support NASA Missions; 31) Feature Detection Routines; 32) Sample Features Detected in SSC Test Stand Data; and 33) Health Assessment Database (DIaK Repository).

Figueroa, Fernando↗
NASA NTRS2008

Integrated Testing Approaches for the NASA Ares I Crew Launch Vehicle

The Ares I crew launch vehicle is being developed by the U.S. National Aeronautics and Space Administration (NASA) to provide crew and cargo access to the International Space Station (ISS) and, together with the Ares V cargo launch vehicle, serves as a critical component of NASA's future human exploration of the Moon. During the preliminary design phase, NASA defined and began implementing plans for integrated ground and flight testing necessary to achieve the first human launch of Ares I. The individual Ares I flight hardware elements - including the first stage five segment booster (FSB), upper stage, and J-2X upper stage engine - will undergo extensive development, qualification, and certification testing prior to flight. Key integrated system tests include the upper stage Main Propulsion Test Article (MPTA), acceptance tests of the integrated upper stage and upper stage engine assembly, a full-scale integrated vehicle ground vibration test (IVGVT), aerodynamic testing to characterize vehicle performance, and integrated testing of the avionics and software components. The Ares I-X development flight test will provide flight data to validate engineering models for aerodynamic performance, stage separation, structural dynamic performance, and control system functionality. The Ares I-Y flight test will validate ascent performance of the first stage, stage separation functionality, validate the ability of the upper stage to manage cryogenic propellants to achieve upper stage engine start conditions, and a high-altitude demonstration of the launch abort system (LAS) following stage separation. The Orion 1 flight test will be conducted as a full, un-crewed, operational flight test through the entire ascent flight profile prior to the first crewed launch.

Taylor, James L.↗
NASA NTRS2001

Design, Fabrication, and Testing of an Auxiliary Cooling System for Jet Engines

This report summarizes the technical effort of the Active Cooling for Enhanced Performance (ACEP) program sponsored by NASA. It covers the design, fabrication, and integrated systems testing of a jet engine auxiliary cooling system, or turbocooler, that significantly extends the use of conventional jet fuel as a heat sink. The turbocooler is designed to provide subcooled cooling air to the engine exhaust nozzle system or engine hot section. The turbocooler consists of three primary components: (1) a high-temperature air cycle machine driven by engine compressor discharge air, (2) a fuel/ air heat exchanger that transfers energy from the hot air to the fuel and uses a coating to mitigate fuel deposits, and (3) a high-temperature fuel injection system. The details of the turbocooler component designs and results of the integrated systems testing are documented. Industry Version-Data and information deemed subject to Limited Rights restrictions are omitted from this document.

Leamy, Kevin↗
NASA NTRS1989

Big Viterbi Decoder (BVD) results for (7,1/2) convolutional code

The Big Viterbi Decoder (BVD), capable of decoding convolutional codes with constraint lengths of up to 15, is under development for the Deep Space Network (DSN). As part of the development, a commercial single-chip (7,1/2) Viterbi decoder is used to enable early start of system integration. Tests of the integrated partial system (including simulator, input systems, output interfaces, and computer controls) were recently completed at the DSN Compatibility Test Area (CTA-21) at JPL. The system elements used for the demonstration and test results are described.

Statman, J.↗
NASA NTRS2010

Integration Process for the Habitat Demonstration Unit

The Habitat Demonstration Unit (HDU) is an experimental exploration habitat technology and architecture test platform designed for analog demonstration activities The HDU project has required a team to integrate a variety of contributions from NASA centers and outside collaborators and poses a challenge in integrating these disparate efforts into a cohesive architecture To complete the development of the HDU from conception in June 2009 to rollout for operations in July 2010, a cohesive integration strategy has been developed to integrate the various systems of HDU and the payloads, such as the Geology Lab, that those systems will support The utilization of interface design standards and uniquely tailored reviews have allowed for an accelerated design process Scheduled activities include early fit-checks and the utilization of a Habitat avionics test bed prior to equipment installation into HDU A coordinated effort to utilize modeling and simulation systems has aided in design and integration concept development Modeling tools have been effective in hardware systems layout, cable routing and length estimation, and human factors analysis Decision processes on the shell development including the assembly sequence and the transportation have been fleshed out early on HDU to maximize the efficiency of both integration and field operations Incremental test operations leading up to an integrated systems test allows for an orderly systems test program The HDU will begin its journey as an emulation of a Pressurized Excursion Module (PEM) for 2010 field testing and then may evolve to a Pressurized Core Module (PCM) for 2011 and later field tests, depending on agency architecture decisions The HDU deployment will vary slightly from current lunar architecture plans to include developmental hardware and software items and additional systems called opportunities for technology demonstration One of the HDU challenges has been designing to be prepared for the integration of presently unanticipated systems Results of the HDU field tests will influence future designs of habitat systems.

Gill, Tracy↗
NASA NTRS2005

Rocket Testing and Integrated System Health Management

Integrated System Health Management (ISHM) describes a set of system capabilities that in aggregate perform: determination of condition for each system element, detection of anomalies, diagnosis of causes for anomalies, and prognostics for future anomalies and system behavior. The ISHM should also provide operators with situational awareness of the system by integrating contextual and timely data, information, and knowledge (DIaK) as needed. ISHM capabilities can be implemented using a variety of technologies and tools. This chapter provides an overview of ISHM contributing technologies and describes in further detail a novel implementation architecture along with associated taxonomy, ontology, and standards. The operational ISHM testbed is based on a subsystem of a rocket engine test stand. Such test stands contain many elements that are common to manufacturing systems, and thereby serve to illustrate the potential benefits and methodologies of the ISHM approach for intelligent manufacturing.

Figueroa, Fernando↗
NASA NTRS2011

Flight Systems Integration and Test

Topics to be Covered in this presentation are: (1) Integration and Test (I&T) Planning (2) Integration and Test Flows (3) Overview of Typical Mission I&T (4) Supporting Elements (5) Lessons-Learned and Helpful Hints (6) I&T Mishaps and Failures (7) The Lighter Side of I&T and (8) Small-Group Activity. This presentation highlights a typical NASA "in-house" I&T program (1) For flight systems that are developed by NASA at a space flight center (like GSFC) (2) Requirements well-defined: qualification/acceptance, documentation, configuration management. (3) Factors: precedents, human flight, risk-aversion ("failure-phobia"), taxpayer dollars, jobs and (4) Some differences among NASA centers, but generally a resource-intensive process

Wright, Michael R.↗
NASA NTRS2007

ISHM Anomaly Lexicon for Rocket Test

Integrated Systems Health Management (ISHM) is a comprehensive capability. An ISHM system must detect anomalies, identify causes of such anomalies, predict future anomalies, help identify consequences of anomalies for example, suggested mitigation steps. The system should also provide users with appropriate navigation tools to facilitate the flow of information into and out of the ISHM system. Central to the ability of the ISHM to detect anomalies is a clearly defined catalog of anomalies. Further, this lexicon of anomalies must be organized in ways that make it accessible to a suite of tools used to manage the data, information and knowledge (DIaK) associated with a system. In particular, it is critical to ensure that there is optimal mapping between target anomalies and the algorithms associated with their detection. During the early development of our ISHM architecture and approach, it became clear that a lexicon of anomalies would be important to the development of critical anomaly detection algorithms. In our work in the rocket engine test environment at John C. Stennis Space Center, we have access to a repository of discrepancy reports (DRs) that are generated in response to squawks identified during post-test data analysis. The DR is the tool used to document anomalies and the methods used to resolve the issue. These DRs have been generated for many different tests and for all test stands. The result is that they represent a comprehensive summary of the anomalies associated with rocket engine testing. Fig. 1 illustrates some of the data that can be extracted from a DR. Such information includes affected transducer channels, narrative description of the observed anomaly, and the steps used to correct the problem. The primary goal of the anomaly lexicon development efforts we have undertaken is to create a lexicon that could be used in support of an associated health assessment database system (HADS) co-development effort. There are a number of significant byproducts of the anomaly lexicon compilation effort. For example, (1) Allows determination of the frequency distribution of anomalies to help identify those with the potential for high return on investment if included in automated detection as part of an ISHM system, (2) Availability of a regular lexicon could provide the base anomaly name choices to help maintain consistency in the DR collection process, and (3) Although developed for the rocket engine test environment, most of the anomalies are not specific to rocket testing, and thus can be reused in other applications.

Schmalzel, John L.↗
NASA NTRS1974

Skylab experiment integration overview

The complex Skylab experiment integration task entailed extensive technical interfacing and liaison. The integrator provided continuity as the experiment evolved through the major program phases. The phases included experiment proposal, experiment development, module integration testing, operations support planning, integrated systems testing, and mission support and evaluation. Skylab experiment program responsibilities are discussed along with a compatibility analysis, questions of documentation, status reviews, and aspects of design philosphy.

Schrock, S. R.↗
NASA NTRSDate not supplied

Accelerance Decoupling: Removing the Influence of the Mobile Launcher from the Space Launch System Integrated Modal Test

Main objective for launch vehicle (LV) modal testing is to quantify the LV’s modal properties in the free-free state (i.e., post pad separation). Given the size of most LVs, free-free testing is a challenge and often not feasible. A test stand, typically the launch pad itself, is utilized as the means to support the LV an Integrated Modal Test (IMT). This shifts the challenge to developing robust numerical methods for removing the influence of the launch pad from the IMT. Preferably fully test driven (method’s that operate based on measured data only). The Accelerance Decoupling (AD) approach, developed and verified by NASA and ASD, is a method with the capability to “subtract out” the influence of the test stand from the IMT using measured data only

Joel Sills↗
NASA NTRSDate not supplied

Design, Instrumentation, and Data Analysis for the SLS Core Stage Green Run Test Series

The Space Launch System (SLS) Core Stage (CS) Thrust Vector Control (TVC) system is comprised of eight mechanical feedback Shuttle heritage Type III TVC actuators and four RS-25 engines, each attached to a Shuttle heritage gimbal block/bearing. The actuators are powered by a Shuttle-derived hydraulic Core Auxiliary Power Unit (CAPU), and integrated with an all-new Core Stage thrust structure. The actuators are interfaced to the SLS Vehicle Management (VM) software via an all-new TVC Actuator Control (TAC) avionics subsystem. Despite the significant test and flight experience of the Shuttle hardware, the SLS Green Run ambient and hot fire test activities revealed a number of new findings associated with the dynamic response of the TVC integrated system. Test responses suggested that the TVC system did not meet its performance specifications and its step and frequency responses exhibited unexpected departures from prior lab tests and modeled behavior. This paper is the fifth installment in a seven-paper series surveying the design, engineering, test validation, and flight performance of the Core Stage Thrust Vector Control system. In this paper, the design of the TVC analyses conducted during the Core Stage Green Run test series are discussed in detail. Throughout the course of the test activities, the SLS flight control team worked diligently with the Core Stage contractor to revise test command profiles and ensure sufficient instrumentation was available to collect data. Post-test analysis combined the Green Run modal, ambient, and hot fire test data, MSFC 2- axis Core Stage TVC Inertial Load Simulator (ILS) data, Hardware-In-the-Loop (HWIL) Systems Integration Lab (SIL) results, and actuator Acceptance Testing Procedure (ATP) responses. These data were used to characterize the response, validate critical math models of the TVC subsystem, and isolate the probable cause of the unexpected responses. Through comprehensive analysis of the available test data sources, the integrated team identified the dominant contributors to the observed response and developed test-correlated rationale for vehicle flight control system performance, ultimately leading to a confident posture for the Artemis I mission.

John H. Wall↗
NASA NTRS1990

Performance measurements for a laboratory-simulated 30/20 GHz communication satellite transponder

NASA has developed a digital satellite communications system simulator and test bed facility, known as the Systems Integration, Test and Evaluation (SITE) Project. The purpose of the facility is to evaluate satellite system components, develop and verify system concepts, and perform satellite system experiments. A recently completed set of experiments measured the performance of the 30/20 GHz satellite transponder portion of the system in terms of RF parameters and high rate digital data transmission. The results of these tests indicate the quality of data transmission which can be obtained under various transponder conditions, as well as the relative effects of degraded RF performance on the bit-error rate (BER) of transmitted data.

Kerczewski, Robert J.↗
NASA NTRSDate not supplied

High Density Vertiplex: Scalable Autonomous Operations Flight Test

The NASA High Density Vertiport project has completed a multi-aircraft flight test of a scalable autonomous vertiport prototype system. These tests included end to end system integration testing of hardware and software, operational procedure testing of defined roles and responsibilities within a vertiport environment, and human factors data collection. This paper provides an overview of the flight test setup , scenarios, and summary results.

AAM↗