Case Study in Developing the System Integration Strategy and Plan for the Constellation Program

Transcription

1 47th AIAA Aerospace Sciences Meeting Including The New Horizons Forum and Aerospace Exposition 5-8 January 2009, Orlando, Florida AIAA Case Study in Developing the System Integration Strategy and Plan for the Constellation Program Keith A. Williams 1 NASA Johnson Space Center,Houston, Tx David A. Dress. 2 NASA Langley Research Center, Hampton, VA, This paper is a case study on the development of the integration strategy for NASA s Constellation Program (CxP) which is based on a structure that satisfies not only the near term and long term needs of the program, but lays out a general approach for Systems-of- Systems integration that can be scaled up or down to support other Programs or Projects. The CxP is a multi-decadal, System-of-Systems space program. The Program has a timephased buildup of capabilities starting with the capability to transport crew and cargo safely to and from the International Space Station (ISS) and eventually leading to the return of humans to the Moon and the establishment of a lunar outpost. CDR = Critical Design Review CoFR = Certification of Flight Readiness CoFTR = Certification of Flight Test Readiness CxP = Constellation Program DCR = Design Certification Review DS = Design Synthesis FOC = Full Operational Capability HW = Hardware Nomenclature IC = Integration Cycle IOC = Initial Operational Capability ISS = International Space Station LEO = Low Earth Orbit PDR = Preliminary Design Review = Systems Integration Plan SW = Software TBD = To Be Determined I. Introduction NASA s Constellation Program (CxP) is incrementally building capabilities over time to accomplish its space exploration needs, goals, and objectives. A Program level strategy was needed to align and integrate project hardware (HW) and software (SW) into an operable architecture to perform the Exploration mission across each of the Program Phases and Stages. The Systems Engineering and Integration process is comprised of Systems Engineering, Systems Management, and Systems Integration. This process has widely accepted standards for Systems Engineering (left side of the V e.g IEEE ) and Systems Management (cross V activities e.g. EIA ), but there is no standard defined to address Systems Integration (the right side of the V ). The standards associated with the right side of the V are mostly verification process related or related to individual projects and not the process/approach for program level integration for a time phased buildup of capability over multiple decades. A top level Systems Integration Plan has been developed for NASA s Constellation Program to address this need. During the initial formulation of a program, structure is needed to provide a mechanism for the various program organizations to plan. A lessons learned is that it is never too early to develop the strategy and define common terms leading to defining the time phased build up of capability. This strategy will become the basis for all work to 1 Chief Architect, Constellation Systems Engineering and Integration, NASA Johnson Space Center, 2101 NASA Rd One Houston, Tx Manager, Constellation Project Office, Exploration and Space Operations Directorate, NASA Langley Research Center, MS 494, Hampton, VA 23681, AIAA Associate Fellow 1 This material is declared a work of the U.S. Government and is not subject to copyright protection in the United States.

2 be aligned. The implementation of this strategy requires a framework to align project HW and SW deliveries from both a horizontal (ensure properly phased) and vertical (ensure deliveries aligned with integration objectives) perspective. The focus of this integration is in response to program risk mitigation, to ensure progress of the design maturity, and to identify key verification closure opportunities associated with system-of-systems level integration activities. To accomplish this, the CxP developed a Systems Integration Plan () that: 1) defines the program phases and breaks those phases into additional manageable parts (program stages and integration cycles) 2) focuses on multi-system design integration for and between each Program Stage, 3) defines the process and metrics for ensuring the Program aligns the technical content for each of the HW and SW builds, 4) plans the integration strategies for large hardware/software integration events. A key tenet of integration planning and the Constellation is to drive a right-to-left planning approach (keeping the end-state in mind for the full operational capability for each Program Stage) to ensure the appropriate personnel, processes, and data are compatible to support a left-to-right execution leading up to key program milestones. Each of these activities will enable the CxP to take advantage of opportunities to minimize cost, schedule, and performance risks to the Program. II. Program Phase/Stage and Integration Cycle Definitions The CxP will field operational capability via multiple Program Phases with the first two planned program phases being our Initial Capability for International Space Station (ISS) crew and cargo rotation and Lunar Capability for human lunar return to the moon s surface and the building the core infrastructure for a lunar outpost. These Program Phases have also been decomposed into Program Stages (ISS Initial Operational Capability (IOC), CxP Low Earth Orbit (LEO) Operations, Human Lunar Return, and Core Lunar Infrastructure) for each phase. The defining of these terms is a key point as it will drive budgets, planning for the hardware/software deliveries, and planning content to be provided at the different design reviews. Figure 1 depicts the Program Phases/Stages which are each further decomposed into integration cycles for the Constellation Program. Phase 1: Initial Capability Cx LEO Ops ISS IOC Phase 2: Lunar Capability Core Lunar Human Lunar Infrastructure Return Each Program Stage is decomposed into Integration Cycles Design Synthesis Integration Cycle Initial Operational Capability Integration Cycle Full Operational Capability Integration Cycle Each IC feeds the Follow-on ICs providing incrementally Sustainment Increasing maturity and capability Integration Cycle Figure 1 Program Phases/Stages and Integration Cycles Integration cycles are composed of the buildup and integration of executable packages of activity or integration events within a Program Stage. Each integration cycle includes strategy definitions, common activities and 2

3 templates, definitions of the required integration activities/events, and definitions of the configurations per build plans for each of those integration activities/events. The CxP defines an integration activity/event as any flight test, ground test, or activity/event where the Constellation Program either executes or requires insight to support integration. These cycles are the implementation steps used to integrate the time-phased buildup of capabilities across the program, ultimately mitigating program risk. Each Program Stage will have, at a minimum, the following integration cycles: Design Synthesis (DS), Initial Operational Capability (IOC), Full Operational Capability (FOC), and Sustainment. Additional cycles may be added for different Program Stages as deemed necessary. Each integration cycle focuses on key program milestones and plans the necessary integration activities from right-to-left based on the completion criteria for the program milestone. These integration cycles are shown in Table 1. A key benefit of this approach is the ability to allocate, at a high level, the functional capabilities for the time phased buildup of capabilities and to defer definition of the later parts till they are needed. It also allows the additional definition of new program phases after key formulation activities have been completed. The Presidents Vision for Space Exploration establishes the exploration of Mars as one of the goals for NASA. This activity is still in early formulation and may be added as an additional program phase to the Constellation Program in the future. A lesson learned in the definition of this top level strategy for a multi-decal program is to plan for change. The program phase and capability definition will change over time with the addition of missions or new capabilities. A key is keeping the definitions based on major, operational, fielded capabilities, allowing for functionality to shift between the individual builds that lead to that operational capability. This will provide program flexibility to manage the many challenges that will occur but yet still meet the overall objective. III. Overall Integration Strategy Defining the top level strategy and framework is a first step. The next step is to develop the strategy to integrate within and across the integration cycles. The Constellation Program is using a two-prong strategy to accomplish this that includes: 1) Top-Down Planning 2) Bottoms-Up Reconciliation A lesson learned in defining this approach is to realize that this activity is more than schedule integration, though many will try to make it such. Schedule integration ensures that a delivery milestone is provided prior to the need date. It does not ensure that the functional capabilities provided at this milestone are aligned with the objectives for the milestone. It also does not ensure the proper logic network is in place to support the overall program integration. Another lesson learned is to protect against limiting the scope of the integration activities for verification. There are a number of activities that will define a test or have hardware/software deliveries where no verification will be performed. Typical events that fall into this category are development testing or model validation related testing. These activities should also be included in your integration plan to ensure that all aspects of the work to be performed have been addressed. To ensure the proper logic and capabilities are aligned with the event objectives, the Program established planning using a Top Down approach. The top-down planning approach is executed by the requirements owners who determine the capabilities or activities that require verification and validation. This strategy starts with the end state (for example, flight, mission completion, etc.) and uses right-to-left planning of activities and events such as test- and demonstration- generated information to align with the integration cycles and established templates. This approach is equivalent to developing your operational concepts prior to writing your requirements. 3

4 Program Program Phase Stage Summary Description Phase 1: Initial Capability Phase 2: Lunar Capability Stage 1: ISS IOC Stage 2: Cx LEOs Stage 1: Human Lunar Return (Lunar Transport) Stage 2: Core Lunar Infrastructure Program Stage Provides crew and cargo transport to/from the ISS. Provides crew rotation (6month stays) and cargo transport to/from the ISS. Provides crew and cargo transport to/from the Lunar Surface. Provide initial infrastructure that can support extended stays on the lunar surface. Table 1 Integration Cycle Scope and Definition. Design Synthesis Intg Cycle Initial Capability specific PDR to CDR to validate the design prior to production. Human Lunar Return (Lunar Transport) specific PDR to CDR to validate the design prior to production. Integration Cycles Initial Operational Capability Intg Cycle This Integration Cycle includes the test flights leading to the first Human Flight to ISS, and is complete after the post flight analysis for first Human Flight. The first ISS IOC Flight is a short duration missions docked to ISS for up to 14 days. This Integration Cycle includes test flights leading to the first Human Flight to the Lunar Surface and is complete after the post flight analysis for that flight. The first Human Lunar Return IOC flight is a short duration lunar surface missions for up to 7 days. Full Operational Capability Intg Cycle This Integration Cycle includes flights after IOC that lead to the full crew rotation capability, and is complete after the post flight analysis for the first crew rotation mission. The first ISS FOC flight provides for six month crew rotation missions docked to ISS for up to 210 days (includes contingency days). This Integration Cycle includes flights after IOC that lead to the full crew lunar transport capability, and is complete after the post flight analysis for the FOC flight.. The first Human Lunar Return FOC flight with full sortie mission capabilities complete. Initial Lunar Infrastructure specific PDR to CDR to validate TBD TBD TBD the design prior to production. Sustainment Intg Cycle Provides the sustaining engineering and production. This Integration Cycle starts with the completion of ISS Mission FOC and & ends with the completion of the CxP support for the ISS mission. Provides the sustaining engineering and production. This Integration Cycle starts with the completion of Lunar Transport FOC & ends with the completion of the CxP support for the Lunar Missions. An example of this strategy would start with the certification of flight readiness (CoFR) for individual flights and work from right-to-left to determine what is needed to safely get to this readiness state. Each integration event and its objectives should be addressed including the required configuration (HW and SW), as well as all needed items such as emulators, simulators, flight hardware, models, etc. The definition of the configuration will become the formal program and project controlled nomenclature. This strategy will ensure that systems and development do not preclude future program stage needs. For example, the design, analysis, and test of the Orion crew vehicle should not only support the Initial Capability Program Stages but should also be assessed to ensure a growth path to meet the requirements for Human Lunar Return and Core Lunar Infrastructure Stages. The bottoms-up reconciliation approach will be used to align the developer build and test plans (HW and SW) across the projects (at level III) and with the top down plan. As the program and designs mature, so will the level of detail associated with the bottoms-up reconciliation. 4

5 The construct of the CxP incorporates the use of a tiered structure (i.e., Tiers 1, 2 and 3). 1) Tier 1 is the top level document that defines the integration definitions, strategies, and processes as well as Responsibility, Authority, and Accountability. 2) Tier 2 encompasses the Program Phase/Stage s. This is the right to left planning portion for each Program Phase where the Constellation Program identifies the events (HW, SW, ground tests, analytical studies, etc.) that are needed as well as the objectives, configurations, and when they are needed. 3) Tier 3 is a database of program and project information that drives the Tier 2 plans. The Tier 3 database is actually a set of inter-related databases which each contain the authoritative data for the program. Figure 2 depicts the three tier 2 Program documents with a further decomposition showing the four integration cycles for the Initial Capability. Tier 1 - Top level (this document) defines the process which sets strategy and definitions Tier 2 - Program Phase/Stage specific s that include the following: Guiding document Detailed program test and analysis plans specific to stage (right to left planning portion of ) Items needed (integration events) and when they are needed laid out in a dynamic database Identification of Level II objectives being fulfilled by key Level III integration events (i.e. Pad abort test) Tier 3 Project portion of that includes: Items being provided and when they are provided laid out in a dynamic database Comparison between planned and actual databases Cx IC DS Cx Human Cx Lunar Human Return Lunar Return Cx IC Design Synthesis Integ Cycle Cx IC IOC Integ Cycle Cx IC IOC Top Level Cx Integration construct Cx Initial Cx Initial Capability Capability Cx Core Lunar Cx Core Infrastructure Lunar Infrastructure Cx IC FOC Integ Cycle Database contributions from the projects Figure 2 CxP Tiers Pyramid Cx IC FOC Cx IC Sustainment Integ Cycle Cx IC Sus IV. Program Phase Integration Plans (Tier 2 ) The Tier 2 s will define the specific integration and verification strategy for their applicable Program Phase/Stages and associated integration cycles. The Tier 2 s will address each integration event for specific flights, analysis cycles, ground tests, and demonstrations. The Constellation Program has allocated the requirements the program must verify versus those to be verified by the projects. The Tier 2 s identify the integration events necessary to integrate, verify, and validate the Program requirements. The logic network for these events are established and integrated into the overall Program Integrated Master Schedule. There are recurring themes which have been used to establish generic templates for activities such as analysis cycles. These program event templates will be applied to the actual events as part of planning and executing the Program Stages. The Tier 2 s will contain the results of applying, tailoring, and adapting these templates to the actual events. Figure 3 depicts a notional logic network leading to the program s Initial Operational Capability. These s will also contain the top level definitions for the configurations at each of the major events. It will also include a list of integration events for each cycle as well as metrics specific to those cycles. The build plans from the projects are the key ingredients for generating this Tier 2. Each integration event will include specific content such as a list of primary and secondary objectives, identification of HW/SW configurations or applicable models and simulations, identification of required model validation data, expectations per flight event, and post-flight analysis plans and reports. The Tier 2 will utilize database reports that define each of the integration events associated with that program phase. 5

6 Ares I-Y Ground Test Test Correlated Models Ares I-Y Verification Analysis CoFTR Ares I-Y Orion 1 Ground Test Test Correlated Models Orion 1 Verification Analysis CoFTR Orion 1 Orion 2 Ground Test Test Correlated Models Orion 2 Verification Analysis Figure 3 Notional Logic Network leading to Initial Operational Capability DCR CoFR Orion 2 Initial Operational Capability V. Integration Planning Tool (Dynamic Database Tier 3 ) Tier 3 of the Constellation Systems Integration Plan is a dynamic database populated with project data that will be combined (linked within the databases) with the program data to integrate the detailed technical content within and across the integration cycles. This dynamic database consists of the authoritative data from multiple sources across the program. These sources currently are: 1) Requirements Database (including verification requirements and verification closure tracking) 2) Program Integrated Master Schedule (integration event schedule information) 3) Risk Management System (linkage to risks with tests/demonstrations as approved mitigation steps) 4) Integrated Hazards Database (linkage for events needed for hazard closures) 5) Program Data Management System (linkage to configuration definitions/requirements, drawings, test results, material history). The approach to dynamically link these tools is still in work by the program. The process of gathering this data for integration purposes is currently being done manually by the program. VI. Integration Phase Processes The strategies and definitions of the integration phases, stages, cycles, and events provide the structure for creating and populating the Tier 3 databases. Once these databases are created, the next step is implementation of the to integrate the time-phased buildup of capabilities across the program, ultimately mitigating program risk. To implement the, both Program Level II and III have responsibilities for executing integration in a four step process: 1) Plan the cycle (align the program needs with the Project deliverables) 2) Assess what is brought to an event versus what was planned (adjust as necessary) 3) Post event assessment (adjust future plans as necessary) 4) Post cycle assessment (adjust as necessary/certify as appropriate) These specific integration processes provide the Constellation Program with the necessary assessment points to integrate the multiple HW and SW builds throughout the program s lifecycle. It is key to remember that for any integration cycle, the purpose of each of the flight tests, ground tests, and analysis efforts are not an end in themselves but part of a larger effort to build confidence that the fielded system will provide the operation capabilities and performance desired. 6

7 a. Plan the cycle Planning prior to a cycle start is where a significant amount of the integration will occur. This is where the right to left logic is used to assess the plans that have been developed. A risk assessment should also be done with this activity to ensure that the most difficult and most risky development activities are not left to later deliveries. Leaving these risky items to late in the development provides minimal time to gain confidence in that functionality and will result in schedule risk that might not be acceptable to the program. Several key questions are asked during this assessment to ensure the correct logic is set in place. 1) What data is needed to obtain final acceptance/certification that the system is ready for operational use? 2) Which requirements does this system need to meet and how is that data/objective evidence generated? 3) What analysis is used to generate that data? 4) What model is used for that analysis? 5) What data is used to validate the model? 6) What test is done to develop that data? 7) What supporting data/predecessors are needed to make these steps happen? 8) Do the HW/SW capabilities being provided align with the objectives planned for the event? 9) Are we doing the easy development first, leaving the difficult and risky efforts for later? 10) Which events have similar configuration needs and objectives and can be combined? 11) Can the objectives planned for the events be realigned for a more effective integration and verification program? b. Assess what is brought to an event versus what was planned The final delivered configurations often have differences versus what was previously planned. This is normal. What is needed is a process that enables you to proactively react to these changes. A meeting is held prior to an event s readiness review (2-3 months) to assess what was previously agreed to be provided as part of the cycle planning process versus what will actually be provided at the event. If there are significant capability deltas, the team must assess if the event should be delayed until the required capability is available or if the event should be held as planned but with a reduced set of objectives and a plan for where the objectives would now be satisfied. This approach provides a heads up prior to significant events and allows the team time to modify the plan in the most effective manner. c. Post event assessment After an event has been conducted, the results of the event against the planned (as revised in item b above) objectives must be assessed. The objectives not addressed by the event must be planned to occur in a future event. If additional objectives not previously planned were accomplished, then the impact to the current plan should be assessed so as to not expend resources to redo activities to meet those objectives. This again is typical in development efforts but the program s integration and verification processes need to recognize and plan for this change. d. Post cycle assessment At the end of an integration cycle, the results of the flight tests, ground tests, and analysis will be assessed to determine if confidence has been gained to enable fielding the planned operational capability. This assessment is from both verification (did I meet my requirements) and validation (can I perform my mission) perspectives. 7

8 VII. Conclusion A general, yet comprehensive Systems Integration Plan has been developed to guide the successful and timely execution of NASA s Constellation Program. This type of plan is critical for programs that are incrementally building capabilities over time. When implemented, this plan will help ensure that project deliveries are aligned from both a horizontal (ensure properly phased) and vertical (ensure deliveries aligned with integration objectives) perspective, thus mitigating program risk. There are several lessons learned from the development of the initial integration plan for the Constellation Program. There is always a desire to have the answer as soon as possible and the development of an integration plan is seen as very advantageous. There are many obstacles (availability of data being a key one) to fully define the plan prior to PDR even though there is a strong desire to do so. The projects that make up a program need the time to develop their designs along with their integration and verification approaches. What can be done early in program formulation is definition of the program phasing and definition of your overall integration strategy. During the initial integration planning for the Constellation Program, there were multiple interpretations of the time phased buildup of capabilities and what were the make up of the program phases. It was key for the team to set a common set of terms and to lead a discussion to determine the content associated with these terms. The standardization on common terminology is one key way to drive integration. It is key to establish a process up front to reach agreements for the objectives for integration events and to define the deliverables for those events including the associated content. This enables the measurement of planned versus actual so conscious decisions can be made about impacts to the plan and performance against that plan. The approach used to develop this System Integration Plan is of a general nature, allowing Systems-of-Systems integration that can be scaled up or down to support other Programs or Projects. References Standards 1 Standard for Application and Management of the Systems Engineering Process, IEE Std Processes for Engineering a System, ANSI/EIA