[American Institute of Aeronautics and Astronautics 2008 U.S. Air Force T&E Days - Los Angeles,...

American Institute of Aeronautics and Astronautics

1

Development of a Test & Verification Approach for the Constellation Program

Ed Strong1 and Rayelle Thomas2 NASA Johnson Space Center, Houston, TX 77058

Arturo Vigil3 NASA Johnson Space Center, Houston, TX 77058

and

Renee Cox4 NASA Marshall Space Flight Center, Huntsville, AL 35812

NASA’s Constellation Program was established to implement the Vision for Space Exploration announced by President George Bush in 2004. The Program seeks to develop the crewed space vehicle and associated architecture that will serve as the successor to the Shuttle Program when it is retired in 2010, providing crew and cargo access to the International Space Station, returning human presence to the moon, and then to Mars and beyond. Given the wide scope of the Program and the challenges it entails, a comprehensive test and verification program is required. This paper describes the vision, strategy, and overall approach for the Constellation Program test and verification effort, including the organization, processes, and facilities that will be required to ensure the systems operate as expected. This paper will describe test and verification vision, organizations, documentation, processes, special test facilities, integrated ground tests, and initial flight testing,

I. Introduction N January 2004, President George W. Bush announced the new Vision for Space Exploration for the National Aeronautics and Space Administration (NASA). The fundamental goal of this vision is to advance U.S. scientific,

security, and economic interests through a robust space exploration program. This vision is being implemented through NASA’s Constellation Program (CxP). The CxP will focus first on replacing the aging Space Shuttle for missions to the International Space Station (ISS), followed by missions to the Moon in order to prepare for eventual exploration of Mars.

II. Constellation Program Description The CxP architecture includes the Ares I Crew Launch Vehicle (CLV) and Ares V Cargo Launch Vehicle

(CaLV) systems, the Orion Crew Exploration Vehicle (CEV) spacecraft system, the Earth Departure System (EDS), Extravehicular Systems, the Altair Lunar Surface Access Module (LSAM) System, Lunar Surface Systems, Mission Systems and Ground Systems. See Figs. 1, 2, and 3.

1Environments & Constraints Systems Integration Group Lead, Constellation Program Office, NASA Johnson Space Center, AIAA Senior Member. 2 Chief, Constellation Flight & Integrated Testing Office, Constellation Program Office, NASA Johnson Space Center, AIAA Member. 3 Integrated Test Engineer, Constellation Flight & Integrated Testing Office, Constellation Program Office, NASA Johnson Space Center. 4 Systems Integration Plan Lead for Initial Capability, Vertical Integration Office, Constellation Program Office, Marshall Space Flight Center

I

U.S. Air Force T&E Days 5 - 7 February 2008, Los Angeles, California

AIAA 2008-1625

Copyright © 2008 by National Aeronautics and Space Administraion. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.


2

8March 2007

Ares V -Heavy

LiftLaunch Vehicle

Ares V -Heavy

LiftLaunch Vehicle

Ares I -Crew

Launch Vehicle

Ares I -Crew

Launch Vehicle

Earth Departure

Stage

Earth Departure

StageOrion -Crew

Exploration Vehicle

Orion -Crew

Exploration Vehicle

Lunar LanderLunar Lander

Components of Program Constellation

Figure 1. Components of Constellation Program

Figure 2. Ares/Orion Stack Elements


3

III. Verification Approach

A. Vision for Verification The vision for CxP verification was developed early in the formation of the CxP. The vision was based on

lessons learned from previous NASA programs and the desire to develop a high level of excellence in the CxP. The vision of the CxP Test & Verification (T&V) office is that the following items be established, integrated, maintained, and be readily retrievable for all levels of the CxP Architecture throughout the life of the CxP:

1) A formalized verification process that ensures CxP hardware/software (HW/SW) complies with applicable design-to/performance/build-to specifications

2) A complete and readily accessible “materiel history” for all CxP “end items” 3) Processes and tools to support the planning, execution, and assessment of effectiveness for verification

activities performed throughout the mission integration lifecycles of each Design Reference Mission (DRM)

4) A formalized validation process that confirms that CxP HW/SW and processes fulfill their intended capability, functionality, and performance

B. Organizational Structure The CxP organization consists of the Exploration Systems Mission Directorate (ESMD) at NASA Headquarters

(commonly referred to as Level 1), the CxP Office (Level 2), and lower level project offices (Level 3) for the Ares launch vehicle, the Orion spacecraft, the Altair lunar lander, lunar surface systems, ground systems, missions systems, and extravehicular activity (EVA) systems (see Fig. 4). The various projects are distributed across multiple NASA centers located across the U.S. (see Fig. 5). Many of the project offices include support from multiple NASA centers as well.

C. Verification Organization Structure Test & Verification responsibilities are shared between the CxP Systems Engineering and Integration (SE&I)

Office and the CxP Test & Evaluation Office. The SE&I Office is generally responsible for defining verification requirements, while the T&E Office focuses on planning integrated and flight tests and managing test facility development and use. Each CxP project office has a corresponding verification function responsible for its system.

Figure 3. Orion Crew Exploration Vehicle Elements


4

Figure 4. Constellation Program Organization Structure

Figure 5. Constellation Program Centers

2

Dryden

♦ Lead Abort Flight Test Integration/Operations

♦ Abort Test Booster procurement

♦ Flight Test Article Development/ Integration

Ames

♦ Lead Thermal Protection System ADP

♦ Aero-Aerothermal database

♦ Ares Abort simulations

JPL

♦ Thermal Protection System

Johnson

♦ Home for Program ♦ Home for Projects: Orion,

Mission Ops, EVA, Lunar Lander

Kennedy

♦ Home for Ground Ops Project

Langley

♦ Lead Launch Abort System integration

♦ Lead landing system ADP

♦ Ares I-1 vehicle integration ♦ Ares aerodynamics lead ♦ SE&I Support

Marshall ♦ Home for Ares Project

Glenn

♦ Lead Service Module and Spacecraft Adapter integration

♦ Flight Test Article “Pathfinder” fabrication

Goddard

♦ Communications Support

Stennis

♦ Rocket Propulsion

Office of the Program Systems

Engineer

Crew Exploration

Vehicle Project

Exploration Launch Projects

Ground Operation

Project

Program Planning &

Control Office

Test and Evaluation

Office

Operations Integration

Office

Systems Engineering &

Integration Office

Safety, Reliability & Quality

Assurance

Program Manager

Deputy Manager

EVA Systems Project

Mission Operations

Project

Lunar Lander Project

Chief Engineer Lunar and Planetary Exploration Office

Administrative Office

Advanced Projects Office


5

D. Document Structure NASA Headquarters requirements (referred to as Level 0/1 requirements), along with the operations concept

(including DRMs), and CxP Needs, Goals, and Objectives (NGOs), were used to build the program architecture level requirements for the CxP. These requirements are documented in the CxP 70000, Constellation Architecture Requirements Document (CARD). Lower level system requirements are contained in Section 3.7 of the document and drive the content of the lower level System Requirements Documents (SRDs) and Interface Requirements Documents (IRDs). Design requirements are contained in Section 3 of the CARD, with verification requirements in Section 4. Figure 6 shows the relationships of the content of each document.

The CxP has emphasized clear requirements at the outset of the program; formal training was mandated across the program prior to baselining the CARD. Of special emphasis was building the verification requirements early in the program; the program did not allow CARD design requirements to be baselined without their verification counterpart. All verification products, or links to their data, will be loaded into the Cradle® EXPL database or the Windchill® data repository by requirement owner or data producer.

Policy and guidelines for performing and managing verification activities across the CxP are documented in the

CxP 70008, Master Integration and Verification Plan (MIVP). The MIVP serves as the parent document for lower level plans for integrated testing, software verification and validation (V&V), and flight testing. In addition to the planning documentation, CxP is developing environmental qualification and acceptance testing requirements in the CxP 70036, Constellation Program Environmental Qualification and Acceptance Testing Requirements (CEQATR) document. See Fig. 7.

Figure 6. Requirements Documents Structure


6

E. The CxP Verification Process The establishment of a program-wide verification process for the CxP is challenging for several reasons.

Verification processes and documentation between NASA centers, NASA programs (and even within centers and programs) tend to vary significantly. Processes from previous human rated programs were not always directly applicable to CxP due to the wide variation in configurations and missions. Simply establishing a common nomenclature between the CxP and projects required a significant amount of discussion. In addition, many processes from previous programs were specific to the paper forms used. Advances in Information Technology (IT) allows CxP to make use of relational databases and workflow software that were not available in earlier programs.

The “Vee” Diagram in Fig. 8 illustrates the product development process adopted for the CxP, and the relationship between the verification, integration, and validation processes in the CxP. System decomposition and definition descends down the left side of the “Vee,” and system integration and verification ascend the right side of the “Vee.”

The CxP MIVP delineates “Qualification Verification” from “Acceptance Verification.” Qualification verification is performed to ensure that the system, as designed, will meet its design-to requirements (e.g., the CARD for the Constellation Architecture). Acceptance verification is performed to ensure that the system, as produced and manufactured, meets its build-to requirements. Acceptance verification is generally performed after a system has been qualified.

Validation that the correct products have been created is also illustrated on the left side of the “Vee.” Here, validation ensures that the interim products and systems engineering artifacts reflect the correct problem and that a valid solution has been identified.

Figure 7. CxP Verification Plans & Testing Requirements


7

Figure 9 describes the verification process flow adopted for the CxP. The goal in defining this process is to allow

flexibility at lower levels, while defining the process at a level that retains the ability to share and retrieve verification related data.

Verification requirements are derived from design requirements and are used to develop more detailed objectives

in Test & Verification Requirements (TVRs). The term “TVR” was coined in order to ensure that users would fully understand its content, rather than simply defaulting to documentation used in previous programs. Verification Logic Networks (VLNs) are used to delineate capture interdependencies between TVRs. VLNs are separate from networks of verification events, which are captured in plans and schedules. Test Readiness Reviews are conducted prior to tests or demonstrations; less formal reviews may be conducted for inspections and analyses. Following

Figure 8. “Vee” Diagram

Figure 9. Verification Process Flow


8

completion of the verification event, verification reports and closure documentation are prepared and used to support Functional Performance Audits/Physical Performance Audits (FCA/PCA), System Acceptance Reviews, and Certification of Flight Readiness (CoFR) Reviews.

F. The CxP System Integration Plan (SIP) In order to ensure that the proper testing and verification occurs at the integrated level, the CxP has developed a

program-level System Integration Plan (SIP) for integration of the Constellation Architecture. The key purpose of the CxP SIP is to establish a strategy and framework to align the project hardware and software deliveries from both a horizontal perspective (to ensure events are properly phased), and vertical perspective (to ensure deliveries are aligned with integration objectives). To accomplish this, the SIP will:

1) focus on multi-system design integration for and between each program phase, 2) define the process and metrics for ensuring the CxP is aligned properly, 3) assess the technical content with the definition of each of the hardware and software builds, 4) provide templates of key integration activities to drive integration planning, 5) plan the integration strategies for large hardware/software program events in response to program risk

mitigation, and 6) address design maturity and key verification closure opportunities associated with “system of systems”

level integration events. Each of these activities will enable the CxP to take advantage of opportunities to minimize cost, schedule and

performance risk to the Program. To satisfy these goals, the SIP will use a right-to-left planning approach (keeping the end-state in mind for the

final operational capability for each program phase) to ensure the appropriate personnel, processes and data are compatible to support a left-to-right execution leading up to key program milestones.

In late 2006, the Constellation Program Manager chartered a Constellation Program Excellence Team (PET) to focus on refining integrated program and project roles, responsibilities and processes, including those for verification. PET decisions addressed the roles and responsibilities of Level 2 and Level 3 offices in terms of the key verification-specific sections of the CARD, each SRD, and each system-level IRD. The goal of this activity was that roles for interface and integrated testing would leverage the existing capabilities within the individual projects as much as possible, eliminating the need to repeat testing

G. Avionics and Software Testing Increasing cost and schedule pressures are leading avionics and software developers for the CxP to question the

benefit of large-scale centrally-located system-level testing, versus development of a distributed verification capability. The concept of having increasing fidelity representations produced in multiple quantities for delivery to each system developer, and a single high fidelity delivery to a central location traditionally known as a “hanger queen” or “iron bird” for “big bang” verification has grown cost and schedule prohibitive. With the development of high speed, high bandwidth, wide area network (WAN) connectivity, the ability to perform avionics and software test and verification in geographically distributed labs has evolved.

Distributed avionics and software test and verification on the CxP will seek to utilize assets already in place for system-level integration and verification testing, which will primarily only incur a portion of the scheduling costs. Leveraging the same resources and infrastructure already in place for system integration at each vendor not only provides the most experienced personnel resources for a particular system, but also provides immediate access to the most up-to-date representation of a system for integration. A small number of lower fidelity emulators are required due to the “lead and lag” associated with system-to-system development schedules across multiple vendors. However, the CxP will be implementing an Integrated Master Schedule (IMS) that will be utilized to analyze system development progress to ensure synchronization.

Figure 10 depicts a potential instance of how multiple distributed activities can occur simultaneously with existing distributed resources.


9

H. CxP Test Facilities The CxP will require the development and use of unique test facilities. The CxP has formed the Constellation

Asset Management Panel (CAMP) for integrating the facility and equipment needs of organizations performing activities for the CxP and to ensure, in collaboration with the performing organizations, that facilities and equipment are available and ready when needed for their task.

CxP is converting the existing A-1 engine test stand used for the Space Shuttle Program at the Stennis Space Center (SSC) to a new engine test facility for the CxP. The A-3 Test Stand will provide altitude testing for NASA's developing J-2X engine. That engine will power the upper stages of NASA's Ares I and Ares V rockets. A-3 is the first large test stand to be built at SSC since the site's inception in the 1960s.

The CxP has also begun modifying the Space Power Facility at NASA Glenn Research Center's Plum Brook Station in Sandusky, Ohio. Its size (100 feet in diameter and 122 feet tall) and ability to simulate the vacuum of space make it ideal for testing the Orion CEV. A new vibration and acoustic test chamber, a mechanical vibration test stand, and electromagnetic interference equipment will enable the facility to simulate the conditions Orion must endure on its mission. The new reverberant acoustic chamber will subject Orion to the intense vibrations and shockwaves it will endure during launch and ascent. In the vacuum chamber, infrared lamps and cold walls flushed with liquid nitrogen will simulate the extreme hot and cold temperatures of space. The electromagnetic interference (EMI) tests will also take place inside the vacuum chamber, which is EMI shielded.

I. Integrated Testing Verification of the Constellation components, sub-systems, and systems is expected to be performed at the

lowest level of indenture possible. Integrated testing of the system and element set, such that verification of the systems themselves, and validation that the systems have been properly built up, is a key feature of the CxP test plan. At the Project level, CxP systems will verify that they meet the CARD requirements. At the Program level, CxP has initiated a set of interface validation tests. These tests are planned for “one time” performance, unless a CxP system has undergone significant software or hardware upgrades from its previously flown configuration. In this way, the CxP will confirm that the projects have complete and flight-ready hardware, and that the earlier testing of the hardware actually did validate all the flight components. The means that CxP will use to validate the overall systems is through integrated interface testing. This testing is broken into two types: Multi-Element Integrated Test/Testing (MEIT) and Flight Element Integrated Test/Testing (FEIT).

Figure 10. Distributed Testing Example utilizing System Integration Labs (SILs) for CxP


10

MEIT is performed on the ground to verify interfaces that see their first connection in space, and cannot be verified using all of the flight hardware involved. This may be due to one side of the interface already being in orbit, or due to limits imposed by the zero gravity environment. The Orion CEV will interface with the International Space Station (ISS), and in later phases, the Altair vehicle. As lunar outposts are created, MEITs will also be used to ensure that outposts will also be validated and confirmed ready for an outpost set up on the lunar surface. In addition to flight equipment interfaces, MEIT will exercise the integrated Communications and Tracking (C&T) networks, including ground stations and communications satellites. See Fig. 11.

FEIT is for the flight “stack,” consisting of the Ares I or V launch vehicle and its corresponding payload (Orion

or Altair). The FEITs are full checkouts of the stack itself. See Figs. 12a and 12b. When Constellation enters its operational phase, a smaller version of the FEIT will be performed to verify that connections have been made and the stack is ready to fly.

Figure 11. Multi-Element Integrated Testing (MEIT)

CEV ISS

CEV LSAM

C&T NW

MS

CEV C&T NW

LSAM C&T NW

C&T NW MS

CEVMS

LSAM MS

C&T NW Communications and Tracking Network CEV Crew Exploration Vehicle ISS International Space Station LSAM Lunar Surface Access Module MS Missions Systems


11

J. FLIGHT TEST STRATEGY The CxP has developed a flight test strategy that reduces the programmatic and safety risks that are associated

with the development of the Ares CLV and the Orion CEV. The philosophy of the strategy is the continual demonstration of incremental capability. There are two types of tests needed to build capability. The first type is developmental, as it serves as an opportunity to gather engineering data necessary for design maturation. The remaining type of test focuses on validating the flight hardware previously tested and verified on the ground, in an operational environment.

Six developmental flights have been identified that are designed to validate concepts and to provide engineering data. The Pad Abort (PA) tests intend to validate Orion’s launch abort concept. Concurrent with the pad aborts are the Ascent Abort (AA) flights, which aim to demonstrate the launch abort function at specific points in the ascent trajectory envelope (see Fig. 13). The development tests are to demonstrate the following:

1) LAS capability to propel Crew Module to safe distance during pad abort. 2) Ability of LAS to jettison from the Crew Module. 3) LAS Capability to propel the Crew Module to a safe distance during Max Q conditions. 4) LAS capability to propel the Crew Module to a safe distance during high drag conditions. 5) LAS capability to propel the Crew Module to a safe distance during off-nominal conditions. 6) Perform an in-flight separation staging event between an Ares similar First Stage and a representative

Upper Stage. The Ares I-X development test flight will focus on the flight control system and separation performance of the

First Stage. The Ares 1-X Flight Test Vehicle (FTV) will be comprised of five elements; the First Stage, Upper Stage Simulator (USS), Crew Module/Launch Abort System (CM/LAS) Simulator, Avionics, and Roll Control System (RoCS) (see Fig. 14). The First Stage is the booster for the FTV. A four-segment Reusable Solid Rocket Motor (RSRM) will be used for First Stage, with an additional empty segment to simulate the five-segment booster length. There is no second stage for the FTV because the USS is not equipped with an upper stage propulsion system other than RoCS. The First Stage is separated from the USS during the flight to support recovery of recoverable parts of the First Stage and the data recorder. The USS is mounted atop the First Stage and includes a model of the Orion Service Module (SM), Ares I Upper Stage, and Spacecraft Adapter (SA). The RoCS system is located in the USS and is used exclusively for ascent up to the separation event. The CM/LAS is an Outer Mold Line (OML) model and mass simulator of the Orion CM/LAS. It is hard mounted atop the USS. The simulator is not separated from the stack during the flight test. The Avionics element for the FTV provides Guidance, Navigation, and Control (GN&C), electrical power, data acquisition, recording, telemetry, video, instrumentation, and Ground Command, Control, and Communication (GC3).

Figure 12a. FEIT for CEV/CLV/GS/MS/C&T

Figure 12b. FEIT for CaLV/EDS/LSAM/GS/MS/C&T


12

The validation flights will focus on the lessons learned from the development tests, and demonstrate the capabilities needed for flight progression to reach Initial Operational Capability, leading to Full Operational Capability. This is evidenced by the increasing level of maturity in all the major components like First Stage, Upper Stage, CEV, and LAS. The validation tests are to demonstrate the following:

1) Validate the 5-segment First Stage booster and GN&C design throughout its operational profile. 2) Validate the Ares Upper Stage GN&C and J-2X engine design and operation throughout its operational

profile. 3) Demonstrate LAS jettison during a nominal ascent trajectory. 4) Demonstrate Orion nominal entry performance for Thermal Protection System (TPS) and GN&C systems. 5) Demonstrate Orion landing systems performance for water landing.

Figure 13. Pad Aborts & Ascent Abort Flights

Figure 14 Ares 1-X Flight Test Vehicle


13

6) Demonstrate the Orion service module propulsion system operations and performance for on-orbit operations.

7) Demonstrate integrated avionics, GN&C, and sensors required to support rendezvous proximity operations with ISS.

8) Demonstrate Orion integrated avionics, GN&C, sensors, and docking hardware required for ISS.

K. Flight Manifest Through Full Operational Capability The Flight Test Manifest through Full Operational Capability, as illustrated in Fig. 15, shows all of the flight test

series. These tests build function and capability, including crew systems, leading up to the First Human Launch of Orion 2 to Full Operational Capability. The Full Operational Capability is currently designated as Orion 4, scheduled to launch in 2014.

IV. Conclusion NASA Constellation Program Office has put in place a test and verification program for its new space

transportation system. The strategy satisfies the Constellation Program Management guidance and directives to accomplish a successful first human launch, while minimizing the gap between Shuttle retirement in 2010 and Constellation First Human Launch in 2013.

Figure 15. Flight Test Manifest through Full Operational Capability

AA-3TumbleAbort

PA-2

AA-2 Transonic

Abort

Validation Flight Tests

Development Flight Tests

PA-1

High Altitude Abort

Ares I-Y Orion 1 Orion 2 Orion 3 Orion 4 Ares I-X

Date post:	15-Dec-2016
Category:	Documents
Upload:	renee
View:	212 times
Download:	0 times