Roadmap Draft Implementation Plan for the Indian Air Traffic Flow Management System (ATFMS)

Transcription

1 Roadmap Draft Implementation Plan for the Indian Air Traffic Flow Management System (ATFMS) July 19, 2011 Prepared by the Volpe National Transportation Systems Center For the use by the Airports Authority of India

2 [This Page Intentionally Left Blank] i

3 Table of Contents 1 INTRODUCTION AND SCOPE BACKGROUND OBJECTIVE CURRENT ATFMS BASELINE ORGANIZATIONAL IMPACTS OF IMPLEMENTING AIR TRAFFIC FLOW MANAGEMENT Safety Collaborative Decision Making (CDM) System Engineering Organization Systems Integration Organization Operational Test and Evaluation Air Traffic Control System Modifications Weather System Modifications Air Carrier System Modifications Operational Procedures Development Staffing Certification ALTERNATIVE PROCUREMENT STRATEGIES ATFMS ROADMAP IMPLEMENTATION PLAN ATFMS ROADMAP ELEMENTS AND SCHEDULE ATFMS Development and Implementation Revised ConOps, Specification and Architecture Develop Configuration Management (CM) Plan and Implement CM Assemble Tender Package System Requirements Statement of Work Source Selection Plan Award and System Development System Requirements Review (SRR) Design Reviews Program Management Reviews (PMRs) and Technical Interchange Meetings (TIMs) System Verification Test and Installation System Transition and Operation Procedures and Agreements Development Airspace Adjustments Coordination with ATC Military Coordination Airline Coordination Airport Coordination Bilaterals as Needed Staffing and Training Required Infrastructure/Interface Preparation Collaborative Decision Making Preparation ii

4 Military CDM Domestic Carriers CDM International Carriers CDM En Route CDM Terminals CDM Towers CDM Short term ATFMS solutions Implement Miles In Trail (MIT) restrictions between centers and nationally Implement Ground Delay Programs (GDPs) Implement Ground Stops (GSs) Implement Call for Release ATFMS IMPLEMENTATION ENGINEERING CONSIDERATIONS Performance and Capacity Reliability/Maintainability/Availability (RMA) Contingency Planning/Backup Monitoring and Control Information Security Safety Engineering/Safety Management System (SMS) Human Factors Engineering Management Communication Planning Risk Management WORK BREAKDOWN INTRODUCTION Purpose Organization and Scope Usage Discussion of Process, Decisions, and Assumptions ATFMS DETAILED WORK BREAKDOWN STRUCTURE ATFMS Mission Analysis (Figure 5 Box 1.0; Figure 6 Box 1.0) Identify Projected Demand for Services (Figure 6 Box 1.1) Identify Technological Opportunities (Figure 6 Box 1.2) Identify Projected Supply of Services (Figure 6 Box 1.3) Mission Needs Analysis and Assessment (Figure 6 Box 1.4) ATFMS Investment Analysis (Figure 5 Box 2.0; Figure 7 Box 2.0) Requirements Definition (Figure 7 Box 2.1) Initial Requirements Definition (Figure 7 Box 2.1.1) Finalize Requirements (Figure 7 Box 2.1.2) Alternatives Identification and Analysis (Figure 7 Box 2.2) Alternatives Identification Figure 7 Box 2.2.1) Alternatives Analysis (Figure 7 Box 2.2.2) ATFMS Solution Development (Figure 5 Box 3.0; Figure 8 Box 3.0) Program Management (Figure 8 Box 3.1; Figure 9 Box 3.1) Work Planning, Authorization, and Management (Figure 9 Box 3.1.1) Program Control (Figure 9 Box 3.1.2) Contract Management (Figure 9 Box 3.1.3) System Engineering (Figure 8 Box 3.2; Figure 10 Box 3.2) System Requirements and Definition (Figure 10 Box 3.2.1) iii

5 Analysis, Design, and Integration (Figure 10 Box 3.2.2) Value Engineering (Figure 10 Box 3.2.3) Supportability, Maintainability, and Reliability Engineering (Figure 10 Box 3.2.4) Quality Assurance Program (Figure 10 Box 3.2.5) Configuration Management (Figure 10 Box 3.2.6) Human Factors (Figure 10 Box 3.2.7) Security (Figure 10 Box 3.2.8) HW/SW Design, Development and Production (Figure 8 Box 3.3; Figure 11 Box 3.3) Hardware Design and Development (Figure 11 Box 3.3.1) Software Design and Development (Figure 11 Box 3.3.2) HW/SW Integration, Assembly, Test and Checkout (Figure 11 Box 3.3.3) Production Engineering (Figure 11 Box 3.3.4) Production (Figure 11 Box 3.3.5) Facilities and Physical Infrastructure Design and Development (Figure 8 Box 3.4; Figure 12 Box 3.4) Facility Planning and Design (Figure 12 Box 3.4.1) Real Estate (Figure 12 Box 3.4.2) Physical Infrastructure (Figure 12 Box 3.4.3) Test and Evaluation (Figure 8 Box 3.5; Figure 13 Box 3.5) System Development Test and Evaluation (Figure 13 Box 3.5.1) System Operational Test and Evaluation (Figure 13 Box 3.5.2) System Independent Software Verification and Validation (Figure 13 Box 3.5.3) Site Acceptance Testing (Figure 13 Box 3.5.4) Independent Operational Test and Evaluation (Figure 13 Box 3.5.5) Documentation (Figure 8 Box 3.6) Support (Figure 8 Box 3.7; Figure 14 Box 3.7) Logistics Support Planning (Figure 14 Box 3.7.1) Test and Measurement Equipment Acquisition (Figure 14 Box 3.7.2) Support and Handling Equipment Acquisition (Figure 14 Box 3.7.3) Support Facilities Construction / Conversion / Expansion (Figure 14 Box 3.7.4) Support Equipment Acquisition / Modification (Figure 14 Box 3.7.5) Support Facilities and Equipment Maintenance (Figure 14 Box 3.7.6) Initial Spares and Repair Parts Acquisition (Figure 14 Box 3.7.7) Initial Training (Figure 14 Box 3.7.8) ATFMS Implementation( Figure 5 Box 4.0; Figure 15 Box 4.0) Program Management (Figure 15 Box 4.1; Figure 16 Box 4.1) Work Planning, Authorization, and Management (Figure 16 Box 4.1.1) Program Control (Figure 16 Box 4.1.2) Contract Management (Figure 16 Box 4.1.3) Engineering (Figure 15 Box 4.2) Environmental and Occupational Safety and Health Compliance (Figure 15 Box 4.3) Site Selection and Acquisition (Figure 15 Box 4.4) Construction (Figure 15 Box 4.5) Installation and Checkout (Figure 15 Box 4.6) Commissioning/Closeout (Figure 15 Box 4.7) Telecommunications (Figure 15 Box 4.8) Implementation Training (Figure 15 Box 4.9) ATFMS In Service Management (Figure 5 Box 5.0; Figure 17 Box 5.0) Preventive Maintenance/Certification (Figure 17 Box 5.1) Corrective Maintenance (Figure 17 Box 5.2) Modifications (Figure 17 Box 5.3) iv

6 Maintenance Control (Figure 17 Box 5.4) Technical Teaming (Figure 17 Box 5.5) Shift Augmentation (Figure 17 Box 5.6) Program Support (Figure 17 Box 5.7; Figure 18 Box 5.7)) Work Planning, Authorization and Management (Figure 18 Box 5.7.1) Program Control (Figure 17 Box 5.7.2) Contract Management (Figure 17 Box 5.7.3) Logistics (Figure 16 Box 5.8; Figure 19 Box 5.8) Supply Support (Figure 19 Box 5.8.1) Repair (Figure 19 Box 5.8.2) Support Equipment Maintenance (Figure 19 Box 5.8.3) Warranty Tracking (Figure 19 Box 5.8.4) In Service Training (Figure 17 Box 5.9) Second Level Engineering (Figure 17 Box 5.10) Infrastructure Support (Figure 17 Box 5.11; Figure 20 Box 5.11) Hazardous Materials Handling (Figure 20 Box ) Utilities, Building and Grounds Upkeep and Maintenance (Figure 20 Box ) Telecommunications (Figure 20 Box ) Building and Infrastructure Improvements (Figure 20 Box ) Real Estate Acquisition and Management (Figure 20 Box ) Flight Inspections and SIAP Development (Figure 17 Box 5.12) System Performance Assessment (Figure 17 Box 5.13) System Operations (Figure 17 Box 5.14) ATFMS Disposition (Figure 5 Box 6.0; Figure 21 Box 6.0) Program Management (Figure 21 Box 6.1) Decommissioning (Figure 21 Box 6.2) Engineering (Figure 21 Box 6.3) Environmental (Figure 21 Box 6.4) Dismantle/Removal (Figure 21 Box 6.5) Site Restoration/Closeout (Figure 21 Box 6.6) DELIVERABLES APPENDIX B: ABBREVIATIONS AND ACRONYMS APPENDIX C: DATA ITEM DESCRIPTIONS MISSION NEED STATEMENT INVESTMENT ANALYSIS REPORT ACQUISITION STRATEGY PAPER INTEGRATED PROGRAM PLAN ATFMS TENDER STATEMENT OF WORK HARDWARE CONFIGURATION ITEMS (HWCIS) COMPUTER SOFTWARE CONFIGURATION ITEMS (CSCIS) INTERFACE CONTROL DOCUMENT (ICD) FACILITIES AND PHYSICAL INFRASTRUCTURE PLAN LOGISTICS PLAN TRAINING PLAN AND CURRICULUM T&E PLANS SITE ACCEPTANCE PLANS FACILITY DRAWINGS v

7 List of Figures Figure 1 ATFMS High Level System Architecture... 2 Figure 2 Master Roadmap Plan... 3 Figure 3 Expanded Master Roadmap Plan... 5 Figure 4 The System Engineering Process... 6 Figure 5 : ATFMS Life Cycle Work Breakdown Structure Figure 6 ATFMS Mission Analysis WBS Level Figure 7 ATFMS Investment Analysis WBS Level Figure 8 ATFMS Solution Development WBS Level Figure 9 Components of the Program Management Element of the WBS Figure 10 Components of the ATFMS System Engineering Element of the WBS Figure 11 Components of the ATFMS H/w & S/W Design, Development & Production Element of the WBS Figure 12 Components of the Facilities and Physical Infrastructure Element of the WBS Figure 13 Components of the ATFMS T&E Element of the WBS Figure 14 Components of the Support Element of the ATFMS WBS Figure 15 Elements of then ATFMS Implementation Segment of the WBS Figure 16 The Components of the Program Management Element of the ATFMS WBS Figure 17 ATFMS In Service Management WBS Figure 18 ATFMS Program Support WBS Components Figure 19 Components of the Logistics Element of the WBS Figure 20 Components of the Infrastructure Support Component of the WBS Figure 21 The ATFMS Disposition Portion of the WBS List of Tables Table 1 Top Level ATFMS Roadmap Table 2 ATFMS Development and Implementation Roadmap Table 3 Procedures and Agreements Development Roadmap Table 4 Staffing and Training Roadmap Table 5 Infrastructure and Interface Preparation Roadmap Table 6 Collaborative Decision Making Preparation Roadmap Table 7 Short Term ATFMS Solutions vi

8 [This Page Intentionally Left Blank] vii

9 1 Introduction and Scope The use of air transportation in India continues to grow rapidly and this trend is likely to continue to expand into the future. Increased traffic is expected at many or all of the existing major airports. This increase in demand requires a corresponding effort to utilize system capacity efficiently. This will require Air Traffic Flow Management (ATFM) capabilities beyond what are available today. These new tools will enable improved management of demand and capacity, and will help system stakeholders deal with the increased complexity of the nation s air routes. This document outlines recommended steps for a phased implementation improving ATFM operations in India. It will serve as a critical planning tool. 1.1 Background India must satisfy this increased demand while operating under difficult weather constraints (e.g., extensive and long lived fog, turbulence and convective weather associated with monsoons and the occasional typhoon), and living within the national security constraints that result from the extensive airspace used exclusively by the Indian military. This document has been prepared based on the results obtained in references 1, 2, and 3 namely: Concept of Operations for Indian Air Traffic Flow Management, VNTSC, August 13, 2010 Qualitative Requirements for an Indian Air Traffic Flow Management System, VNTSC, February 9, 2011 System Architecture and Specification For An Indian Air Traffic Flow Management System, VNTSC, May 6, Objective The objective of this document is to establish an implementation roadmap that will provide the required improvements in India s Air Traffic Flow Management System (ATFMS). A top level view of this system is provided in Figure 1Error! Reference source not found.. Referring to this figure, the Central Command Center (CCC) shall be established to optimally balance airspace/airport capacity vs. demand both strategically and dynamically by integrating various operational constraints and weather parameters. Mitigating measures and alternate actions to avoid congestion and delay both in the terminal and enroute airspace and airports will be achieved through collaborative decision making process involving all stakeholders. The CCC will be located at Delhi. In addition, the Indian airspace is managed by both Civil and Military authorities in their respective areas. The airspace available for civil flight operations is divided into enroute sectors operated through 11 ACCs based on the major traffic flows. ACC TMUs are located at each of these ACCs. The ATC systems and personnel interface accepts flight data and aircrafts position report containing radar track and ADS data from the 11 ACC systems presently located at: Mumbai; Delhi; Chennai; Kolkata; Trivandrum; Mangalore; Hyderabad; Nagpur; Varanasi; Ahmedabad; and, Guwahati. 1

10 Figure 1 ATFMS High Level System Architecture The data will be concurrently sent to the CCC to construct a comprehensive traffic picture. These 11 ACCs will be amalgamated into four ACCs located at Delhi, Mumbai, Chennai and Kolkata. In the long term, these four ACCs will be amalgamated into two ACCs located at Delhi and Mumbai. Terminal flow control will be implemented at busy terminal approach areas (APP TMUs) and airports TWR TMUs) which are capacity constrained. The demand will be balanced with the capacity through strategic slot management process and dynamic flow control measures. Necessary ATM traffic management tools and decision making tools will be integrated with ATM automation system to provide integrated strategic and tactical ATM solutions. Appropriate ATC procedures also will be essential to ensure successful implementation of terminal flow control. 1.3 Current ATFMS Baseline Today, the primary method for long term balancing demand with system capacity is to restrict demand by allocating a fixed number of arrival/departure slots to scheduled aircraft operating into and out of India s major, congested airports. Slot allocations are made on a quarterly basis, with the numbers adjusted for seasonal weather and traffic conditions. The slots equitably distribute the restricted airport and airspace capacity to aircraft operators. Short term (e.g., during a flight day) balancing is 2

11 accomplished by air traffic control (ATC) imposing delays on aircraft and airlines decisions to divert to alternate airports during periods of weather restricted capacity. Weather information and airport capacity information is made available to ATC and flights via India s Aeronautical Information System (AIS). Each party makes independent decisions about how to restrict and manage flights during problem periods. This often results in less than optimal utilization of available airspace, airports, and aircraft resources. 1.4 Organizational Impacts of Implementing Air Traffic Flow Management Aside from the impacts the ATFMS will have on the AAI structure and interfaces with other systems and organizations which are discussed later in this document there are impacts at a higher level which will be discussed here. Figure 2 illustrates the Master ATFMS roadmap with the organizational impacts at a high level. Figure 3 illustrates the Expanded Master ATFMS roadmap with the organizational impacts with the details of implementing the ATFMS and its required infrastructure. 3

12 Figure 2 Master Roadmap Plan Safety The ATFMS is not a safety critical system but it will improve overall safety and efficiency of the National Air Space (NAS). All organizations within AAI need to be made aware of what TFM does for the NAS and its impact on safety. However, it is not operated as a safety critical system since it is not responsible for critical aircraft separations. None the less safety analysis is required to ensure that the ATFMS does not adversely affect the safety of the Air Traffic management System. This analysis is conducted as part of the System Engineering Process described in section Collaborative Decision Making (CDM) This is discussed later in the document as how it pertains directly to the ATFMS but this concept also affects all of AAI and all of the users of India s NAS. All areas of AAI and all users need to be made aware of CDM and how it will impact their operations. CDM will directly impact not only the TFM organization but also the ATC organization, the military, and the airlines. Further discussion of CDM is provided in 4

13 section Analysis of the impact of CDM on the ATFMS concept and architecture is performed as part of the System Engineering Process described in the next paragraph System Engineering Organization AAI will either have to create an internal system engineering organization or obtain the capability using a support contractor. The system engineering organization is responsible for implementing the process depicted in Error! Reference source not found. below. Examination of this figure identifies the primary system engineering tasks namely: Operations and Requirements Analysis; Functional Analysis and Requirements Allocation; and, System Synthesis. In addition, these primary system engineering tasks are supported by: System Analysis and Control; and, Validation and Verification Figure 4Error! Reference source not found. also illustrated the interaction among the primary and support tasks and identifies the major inputs and outputs of each task. For example, Verification and Validation is responsible for performing analysis of test results, simulations, test and evaluation, and independent verification and validation of the operational requirements, concept, and architecture; the functional architecture; and, the technical architecture and system design. Based on the results of the Verification and Validation task, feedback concerning the operational, functional, and technical requirements and architectures are provided to the other appropriate system engineering tasks. In addition, the System Analysis and Control Task provided V&V with the system metrics, system models, and human factors guidelines that will be used in the V&V evaluations. 5

14 Figure 3 Expanded Master Roadmap Plan 6

15 Figure 4 The System Engineering Process It is of particular importance to mention the System Analysis and Control Task since this task performs studies that significantly contribute to the final ATFMS hardware and software design. This activity accepts inputs from all other process elements and provides the analytic support needed to support those elements. System Analysis and Control task activities include: System Trade Studies Feasibility studies Performance Assessments Benefit Assessments Safety Assessments Cost Assessments Risk Assessments Technology Assessments Human Factors Guideline development Configuration Management Data Management Interface Management Metrics Development, and Transition/Implementation Analysis 7

16 1.4.4 Systems Integration Organization AAI will either have to create an internal systems integration organization or contract it out. There are many new systems and interfaces that are being developed due to the implementation of ATFMS therefore some entity needs to be responsible to ensure that all these systems are communicating properly and sharing all the correct data. This function is normally accomplished by the Systems Engineering Organization as part of the System Synthesis Task Operational Test and Evaluation AAI will either have to create an internal operational test and evaluation organization or contract it out. After all these independent systems have been tested the integrated system needs to be tested and evaluated end to end. Again, this function is normally accomplished by the System Engineering Organization as part of the Validation and Verification and the System Analysis and Control Tasks Air Traffic Control System Modifications The air traffic control function consist of complex tasks demanding a high degree of skills and abilities for quick and fast information processing, reasoning and decision making. Operational efficiency of the controller and ATFM specialists could be improved by providing appropriate decision support software tools for support of air traffic flow management. These tools will assist the controller in conflict prediction, detection, advisory and resolution and the ATFM specialist in the identification and resolution of congestion problems The expectation is that greater degrees of accuracy could be achieved through the sophisticated data processing associated with automation and should allow more direct routings. Furthermore, traffic congestion in en route and terminal airspace as well as at airports should be more accurately forecasted and efficient traffic management initiatives formulated. These systems should be implemented at all ATC centers, busy terminals and airports. The role of automation should enhance controller and ATFM specialist performance with consequential benefits in increased safety, capacity and efficiency. The level of automation must be compatible with the humans ability to execute and manage the task. There should be a back up system to cope up with system failure. As defined above, ATC automation will require modifications primarily because the ATFMS and the ATC systems need to exchange information bidirectionally. An example of this data exchange happens during the implementation of GDPs or GSs. The ATFMS will produce a list of flights affected with their Estimated Departure Clearance Times (EDCT) and then the controllers will either hold these flights or release them later in order to meet the ATFMS assigned EDCT Weather System Modifications The ATFMS may require modifications to various weather systems this could be for additional data that is required to perform a function or to achieve connectivity between the two systems. The AAI in 8

17 coordination with the India Meteorological Department (IMD) is preparing for the upgrading of meteorological facilities at India s airports. This will include provision of: New integrated automated weather information system, Web based meteorological information, Interfacing of MET Computers with Air Traffic Services (ATS) Automation System at major airports for enhancing the efficiency of Pilots and Controllers. Integrated MET data display of current and forecast Weather (Wx) data directly from the MET computer in all ATC units in major airports/ centres Real time Satellite Wx picture with Wx warnings. Wake vortex warning. OPMETF data exchange through AFTN AFTN Wx database. Uplink / downlink of MET data Integrated ATS/MET/AIS pre flight briefing to specialists and ATS personnel Air Carrier System Modifications The ATFMS may require modifications to various air carrier systems this could be for additional data that is required to perform a function or to achieve connectivity between the two systems. For example, CDM will require interaction between the airlines AOCs and the ATFMS automation systems and personnel Operational Procedures Development Due to the new positions being created within the AAI organization of TMCs and STMCs, how these positions fit into the current organization including how they will communicate with the ATC organization needs to be addressed. A discussion of these new positions and operational procedures is contained in section 3 of the ATFMS CONOPS provided as reference Staffing The staffing of Traffic Management Specialists needs to be addressed at all facilities as well as the need for staffing of Weather System Specialists at facilities. Further discussion of staffing is provided in section Certification These new operational systems and interfaces need to be certified by an AAI organization that has the responsibility and enforcement power to ensure that these systems are operating safely and as intended. For example, in the United States, FAA software certification is based on the standard RTCA/DO 178B. The standard provides information about all aspects of the software certification process including the following sections: software planning process, software development process, software verification process, and the certificate liaison process. The software verification process 9

18 includes more than testing, since testing in general cannot show the absence of errors. Therefore, the software verification process is usually a combination of review, analyses, and testing. Review and analyses are performed on the following different components. [RTCA92] Requirements analyses To detect and report requirements errors that may have surfaced during the software requirements and design process. Software architecture To detect and report errors that occurred during the development of the software architecture. Source code To detect and report errors that developed during source coding. Outputs of the integration process To ensure that the results of the integration process are complete and correct. Test cases and their procedures and results To ensure that the testing is performed accurately and completely. 1.5 Alternative Procurement Strategies AAI has two paths that they can go down in regards to the tender. The first path is one in which AAI goes out for an international tender in which they follow the guidelines outlined below for procuring a system from a vendor based in any country in the world. The other alternative is to have the Volpe Center through the FAA procure and/or develop India s ATFM system. This alternative would free AAI from directly dealing with contractors and/or vendors. Three top level strategies exist for the typical international tender and implementation of India s ATFMS. These include procurement of: 1. Commercially available hardware and software 2. Commercially available hardware and developmental software 3. Developmental hardware and software There also exists the possibility of a blend of these strategies. For example, it is possible and even likely that a proposed ATFMS implementation would consist of a combination of commercially available and developmental hardware and software. Developmental hardware and software may be necessary in order to provide interfaces with existing AAI Traffic Management Systems as well as Airline Operations Systems and the Military. In the event that developmental hardware and/or software are required, it is recommended that techniques such as rapid prototyping be used in order to reduce development risk. It is recommended that the AAI tender for the ATFMS allow for all strategies and that the selection of the winning proposal be based on cost, schedule, demonstrated past performance and other criteria of interest to AAI. 10

19 2 ATFMS Roadmap Implementation Plan This section consists of a description of the major ATFMS roadmap elements and schedules; several engineering considerations that are critical to successful development, procurement, and implementation of India s ATFMS; and, a discussion of the recommended ATFMS procurement and implementation steps. 2.1 ATFMS Roadmap Elements and Schedule The top level ATFMS roadmap is presented as Table 1. This roadmap provides for ATFMS Initial Operational Capability at the end of the second quarter of calendar year While this schedule is considered ambitious, it is consistent with AAI plans as stated in references 4, 6, and 7. Table 1 Top Level ATFMS Roadmap The following paragraphs in this section provide schedules and discussion of each of the major activities identified in Table ATFMS Development and Implementation The elements and schedule for the development and implementation of the ATFMS are summarized and presented in Table 2. The Concept of Operation, Qualitative Requirements, and the System Specification and Architecture have been delivered to AAI as shown in the above schedule and are cited as references 1, 2, and 3. This document represents the Roadmap document that will be delivered to AAI in the July, The remaining elements shown in Table 2 are discussed below Revised ConOps, Specification and Architecture The initial imperative of system modernization is to develop and regularly update an Concept of Operations document (ConOps). The ConOps serves as the driver for all solution implementation activities. It reflects the needs of the future and the expected benefits; whenever possible, benefits will be stated in quantitative terms. An initial ConOps has already been developed for India s ATFM, reference 1. As the program evolves, the ConOps will be regularly updated and will be consulted for the updating of the qualitative requirements and the system specification and architecture, references 2 and 3 respectively. This activity is scheduled to occur during the fourth quarter of 2011 and the first quarter of 2012 and will be performed in parallel with the development of the CM Plan and its implementation. 11

20 Table 2 ATFMS Development and Implementation Roadmap Develop Configuration Management (CM) Plan and Implement CM Configuration management activities consist of planning and management, configuration identification (including baselining), configuration control, configuration status accounting, and data management. Planning and management ensures appropriate governance is in place for the assignment of configuration management responsibility and decision making. It also provides for development of guidance for how CM is applied. Configuration identification activities establish the configuration baseline for each configuration item. Baselining involves managerial agreement on the content of the ATFMS and its Configuration Items (e.g., acquisition program baseline (APB), program requirements document, system specification, and product specification) by the designated configuration control board. Configuration control is the process of developing, coordinating, approving, documenting, and releasing changes to configuration items throughout solution implementation and in service management, again controlled by the designated configuration control board. Configuration status accounting provides the means to record and report on configuration data. Audit and verification activities ensure that each investment or configuration item meets its requirements and that requirements address the stated need. Data management ensures shared information is appropriately accessible, provides mechanisms for standardizing data formats, and enables control of program related work products, including baseline information and supporting program documentation (such as configuration control board operating procedures and plans). 12

21 The system to be procured, and all hardware, software, and documentation items that are part of the contract, must be placed under configuration management. Documentation includes not only equipment documentation, but also contract and program management documents such as the schedule, implementation plan, and the configuration management plan itself. Each hardware, software, and documentation component is broken into Configuration Items (CIs), and each CI is baselined at the appropriate time. Following baselining, all changes to the CI must be tracked with dates, nature of change, who changed it and why Assemble Tender Package The three key elements of the Tender Package are the System Requirements, the Statement of Work and, the Source Selection Plan System Requirements In order to derive a set of requirements that can be used for the system tender, extensive review is required by operational, technical, and program management personnel in AAI. It is very helpful to have an initial draft set of requirements and an initial system specification and architecture that have been developed in conjunction with a draft ConOps, as was done for this program. If these documents have not been developed in conjunction, the first step should be to cross validate the documents against each other. In fact, this is useful even if they have been developed in conjunction, in order to systematically ensure that the documents map to each other. A general philosophy must be decided early in the procurement activity for the level of detail at which the requirements will be specified. That is, will the requirements simply indicate what sorts of operational goals need to be met (this type of requirement may be referred to as a Statement of Objective (SOO), or will the AAI specify that system is required to provide certain specific functions to meet these goals, or will details be specified regarding how the function should be implemented (e.g., details of the algorithm or the user interface)? For the procurement of the advanced ATFM system for India, it is likely that the majority of requirements will be at the SOO and functional level, though most fairly large scale systems contain a mix of requirement types. Structured internal Requirements Reviews should take place, first allowing various relevant AAI personnel to review the requirements and comment on any specific items that are duplicated, contradictory, unnecessary or missing. Small expertise groups may be assigned to review certain sections of the requirements. After sufficient time has been given for individual or small group review, if time permits the larger team can meet to review the comments one by one, updating and adding the requirements as necessary. It is ideal to keep the requirements in a database, and possibly use a dedicated tool such as DOORS. This way, changes and discussions can be tracked systematically, from requirements definition all the way through system testing, and should it ever become necessary, a justification and history are available for every requirement. The vendor comments that are received from the Request For Information (RFI) activities should be reviewed using a similar process. Naturally, a comment from one vendor that they cannot fulfill a certain requirement is not sufficient reason to change or delete it. However, if multiple vendors indicate that a 13

22 requirement or set of requirements is unreasonable, difficult or expensive to implement, it may be unrealistic to retain it. Special care must be taken that suggested changes or additions to a requirement do not bias the requirement in favor of the particular vendor s solution. Despite these concerns, experience has shown that a vendor review process can improve the quality of the requirements document and increase the AAI s awareness of what is available in the industry to meet the operational needs. If the timing is right, the vendor and internal reviews can take place at the same time. This could save time by reducing the number of meetings and the amount of coordination. However, if this is not possible, it is acceptable to conduct the review activities separately, especially since the internal and vendor comments are likely to be somewhat different Statement of Work The Statement of Work details everything the contractor is required to do in the performance of the contract. It includes a definition of the contractor s responsibility at all phases of the program following contract award, including documentation requirements which are generally captured in a Contract Document Requirements List (CDRL). The CDRL may be an appendix or section in the Statement of Work (SOW), or may be a separate document. A Work Breakdown Structure (WBS) is typically developed in conjunction with the SOW that is released as part of the RFI and later the Request For Proposal (RFP). The WBS identifies the individual components of the program (e.g. tasks and subtasks), and also the hardware, software and data CI s (see the earlier discussion of Configuration Management) and their relationships with each other. An activity list may be developed as an extension to the WBS, in much the same way that the requirements flow from the ConOps. The activity list and WBS can be used as a mutual cross check, to ensure that all AAI and contractor activities and deliverables are included, and the activities can then be translated into specific tasks required of the contractor. As mentioned earlier, certain elements of the program, such as training and maintenance, may be specified as options in the SOW portion of the RFP. The bidders are free to propose what support they can offer in these optional areas and at what cost. AAI may decide later at what level, if any, to hire the contractor to perform these activities in addition to providing the automation system and associated hardware and documents Source Selection Plan A decision must be made regarding the type of procurement to be conducted. For example, a sole source contract may be awarded without competition, or the procurement might be an open competitive bid. If the latter approach is chosen, the contract award decision might be solely cost based, i.e. award the contract to the bidder with the lowest price offer, provided that they can meet all or some predefined high percentage of the system and contract requirements. Alternatively, the contract may be given to the bidder with the most favorable offer, considering both price and the evaluated quality of the offered solution. Issues to be considered in making this decision include national procurement laws, 14

23 and the results of the trade studies and other context surveying activities, all of which help to determine how many different companies are capable of providing the required system and services. Whichever option is chosen, the methodology and criteria of proposal evaluation must be clearly stated in a Source Selection Document. This document is included as part of the RFP. A detailed, defensible description of the evaluation process, reviewed by legal experts, is very important in any procurement, especially if the proposals will be scored as opposed to looking only at price. Supplemental procurement documents may be included with the Source Selection Document, providing, for example, summaries of applicable procurement law and instructions for proposal formatting. It is highly recommended that bidders be required to structure their proposals in accordance with the requirements and SOW documents, in other words providing responses to each system and contract requirement in the order in which they appear in the RFP documents. This allows for a more efficient and consistent evaluation. It may be worthwhile to require that a live demonstration of the system be part of the evaluation. This is especially helpful with the evaluation of Human Factors related requirements. If this strategy is adopted, especially if a score based evaluation method is used, objective criteria must be defined and adhered to for this part of the evaluation. In addition, this strategy may not be feasible if major aspects of the system have not yet been built and implemented Award and System Development Following the preparatory activities discussed in the previous section, the RFP is released. If the earlier planning and preparation phases have been done well, the Procurement Decision phase is likely to go smoothly. Following RFP release, while waiting for vendors to prepare and submit their proposals, AAI can prepare for the evaluation activity by designing and testing any necessary scoring tools and databases, forming expertise based sub teams to evaluate specific areas of the proposal, and familiarizing themselves with the system and contract requirements and agreed upon evaluation measures. After proposals are received, the evaluation process begins. Sufficient time must be allowed for this process, especially if a scoring method is going to be used, so that the response to each requirement from each vendor may be reviewed properly by evaluators. This is true even for simpler cost based or even sole source procurement methods, because it is still necessary to evaluate each requirement for compliance, and the advanced ATFM system is likely to have hundreds or perhaps over a thousand requirements. Based on the results of whatever evaluation takes place, a preferred contractor is selected and notified of the decision. Depending on local procurement laws and the Source Selection plan, there may be opportunity for negotiation on price or other terms of the contract. If problems develop during this phase, and agreement with the preferred vendor cannot be reached on the final contract terms, negotiation may begin with the second contractor choice. Once a contractor is chosen to provide the system, the system development phase begins. During this process, the system described by AAI in the RFP and offered by the contractor in the proposal is defined in a precise manner. Any discrepancies are resolved between AAI and contractor understanding of 15

24 requirements, and then the contractor defines details such as system architecture, system interfaces, and user interfaces. These details are discussed in a series of formal reviews. Before and during these reviews, any issues with the design details are resolved. When AAI gives final approval, the design phase concludes and the system may begin to be built System Requirements Review (SRR) Following contract award, work will commence to finalize the system design. This begins with preparation for the Contractor Level SRR. As the internal SRR described above clarifies the requirements before they are formally released, the contractor level version of the review ensures that the AAI and contractor have a common understanding of the requirement meaning. AAI might identify requirements where the contractor s proposal response, though judged compliant, was unclear or in some way indicates they might not have completely understood the intended meaning of the requirement. In addition, the contractor may initiate lists of requirements that need to be clarified, admitting that they intend to comply with the operational need but did not fully understand what was required. Care must be taken, when reviewing the contractor requirements list that they are not attempting to change the content of the proposal or avoid fulfilling a requirement that they promised in the proposal to fulfill. If applicable law permits, the proposal should be made a binding part of the contract so that any statement made in the proposal must be followed unless explicitly approved by AAI. At the SRR, AAI and contractor lists of requirements for review will be covered in detail. Coordination should take place before the SRR meetings, and if there are a large number of requirements, the parties should attempt to resolve as many as possible beforehand. In addition to requirements discussion, the contractor should present a preliminary System Architecture during the SRR. The main product of the review is a Requirements Baseline, which is as close as possible to the specified requirements that were listed in the RFP, with any mutually agreed clarifications or modifications. The Requirements Baseline is used by the contractor to construct a detailed system design Design Reviews The SOW/CDRL should require the contractor to produce several system design documentation items. The most important at this stage is the System/Subsystem Specification (SSS). The SOW/CDRL should require the contractor to construct this document according to the same structure as the requirements document, just as the proposal is required to follow the requirements document structure. The initial version of the Specification may be at a fairly high level, especially in the case where a lot of the system functionality is being newly developed rather than existing in an off the shelf system. The high level Specification will serve as input to the Preliminary Design Review (PDR), which is a formal review of the relatively high level design. The purpose of the PDR is to ensure that the design is consistent with the functional and performance requirements. Once the preliminary Specification is approved, it will be taken down to the next level of detail, where the SSS begins to specify at a lower level of detail how the system is divided up into subsystems, and what key functions are accomplished by each subsystem. For this reason, the product being worked 16

25 toward at this phase is known as the Allocated Baseline, because functions are allocated to specific subsystems. The architecture chosen by the contractor may or may not map closely to the structure of the requirements and architecture documents created by the AAI. The RFP will likely not mandate all details of the final system architecture. Therefore the contractor is required to provide requirements traceability, indicating how each of the requirements as contained in the Requirements Baseline, maps to subsystem elements by using a table referencing the original requirement to sections of the detailed design documentation. All of this documentation will be reviewed in the Critical Design Review (CDR). Details of the user interface will also begin to develop between the PDR and CDR. If possible, a prototype of the software should be provided before the CDR for advance review by the AAI. More detailed review of the user interface, and of all design documentation including system interfaces, will take place at the CDR. The main output of the CDR is a final system design and approval to begin any system fabrication that needs to take place Program Management Reviews (PMRs) and Technical Interchange Meetings (TIMs) PMRs should be held on a regular basis, every few months until CDR as well as during fabrication. The duration and location can be determined by negotiation between the AAI and the contractor, with the AAI having the final approval authority for the schedule and locations. A common arrangement is to alternate the location of PMRs between the AAI facility and the contractor facility. PMR agenda items include, but are not necessarily limited to reviews of contract performance and schedule metrics, risk reviews, and action item reviews. Working level technical meetings are known as TIMs. They are generally scheduled on an as needed basis as approved by both parties, and may coincide with PMRs. The contract should specify the location and maximum frequency of TIMs System Verification Test and Installation System testing ensures that the system complies with all requirements. It is more properly referred to as verification, because there are four distinct ways to verify requirement compliance, only one of which is actually referred to as testing : Inspection Inspection determines compliance without utilizing any specialized equipment, and consists of examining displays, equipment and/or documentation to ensure the requirement is met. Analysis Analysis uses some form of scientific or algorithmic analysis to prove that the requirement is met, when this cannot be directly demonstrated. For example, RMA requirements are usually verified through analysis, because required maximum frequencies for system failures are so infrequent that it is not practical to run the system and wait until an actual failure occurs. 17

26 Demonstration Demonstration requires that specific test steps be defined to verify that a relevant set of actions will achieve the desired result. The system is observed to confirm that the result dictated by the requirement will actually happen. Test Test is the most controlled form of verification, wherein specific steps are defined to verify the requirement, and some form of quantitative measurement is taken. The Factory Acceptance Testing (FAT) and Site Acceptance Test (SAT) both follow the same principles. The difference is, obviously, that the FAT takes place at the factory prior to delivery and installation of the system, and the SAT takes place at the site. Both test events are necessary because serious problems discovered during FAT may indicate that the system is not yet ready for delivery. Furthermore, some requirements can only be verified at the operational site, or at least can only be verified properly at the site, with all interfaces active and real data being processed by the system. The contractor should be required to construct a test plan mapping each requirement or set of requirements to a verification procedure. AAI must approve the allocation of requirements to verification steps, the verification method for each requirement. The SOW and contract should dictate that following the SAT, or as part of the SAT, Operational performance testing be conducted with simulated high levels of workload (e.g., large amounts of data being processed) to test the limits of the system and ensure that Performance and Capacity requirements are met. Following the SAT, it may be desirable to specify that the AAI has the right to operate the system in shadow mode for some length of time on a continuous basis before final acceptance (a typical length of time is one month). Real data will be processed by the system, and for some part of this test phase, operational personnel should be permitted to use the system, not to perform actual operations but to become familiar with the system and to ensure that normal usage does not cause system problems or outages. Any malfunction discovered during any phase of the testing will be tracked via the Problem Trouble Report (PTR) system. As mentioned earlier, maximum levels of each defined severity of system problem will be established, and if the number of outstanding problem reports exceeds the maximum at any key program milestone, the system will not be accepted until a sufficient quantity of the problems are addressed. On site installation takes place between the FAT and SAT. This is a phase of the program that should go smoothly, provided that proper preparation activities have been executed. Specifically, one or more site surveys should take place to ensure that the contractor, and/or any subcontractor responsible for installation tasks, understand the physical environment and are aware of any hindrances to a smooth installation and have planned how to mitigate these. The results of the site survey are used to construct an installation plan which must be approved by AAI. The installation plan will include considerations for safety, physical security, insurance, and a plan to ensure that installation does not interfere with day today operations at the site. 18

27 System Transition and Operation Transition from the old operation to the new operation following system acceptance is an important consideration. In the case of the ATFM program, especially for the large scale advanced system that is expected to be procured, there will not likely be a transition from an old system to a new system, but rather the addition of a new system and transition to a an enhanced way of performing ATFM tasks. Therefore much planning is needed for this phase. A Cutover and Transition plan document must be produced by the contractor and approved by AAI. This document includes a study of alternatives, including the previously mentioned issue of whether all facilities in the nation should receive the new equipment at the same time, as opposed to a phased approach. The transition plan must consider operator workload, organizational change, and other human resource issues. After operations are fully transitioned to the new (or upgraded) system, the system and the relationship with the contractor must be managed throughout the system life cycle. Many of the issues relating to In Service Management are addressed earlier in this document. For example, the maintenance and warranty strategy will affect the degree to which a relationship must be maintained with the contractor, and will have human resources implications such as staffing and training of technical personnel. If a similar or generic version of the procured system is planned to become part of the contractor s product line and possibly be offered to other ANSPs, relevant contract terms must be settled upon with the contractor. Specifically, it must be stated in the SOW and contract whether any upgrades the contractor does to the system to improve its salability to other customers, will be available to the AAI. One possible strategy is to mandate that any upgrades that the contractor creates during the warranty period be available to AAI at no cost, with upgrades occurring after the warranty period offered to AAI at favorable pricing with the option to procure or decline. From the Information Security perspective, it may be wise to require that any updates to the procured antivirus and other security solutions, be available at no cost, at least for the entire duration of the warranty period Procedures and Agreements Development As illustrated in Table 3, Procedures and Agreements includes: adjustment to the airspace; coordination between ATFMS and ATC, the Military, airlines, and airports; and the negotiation of new and/or existing bilateral agreements as required by the introduction of the ATFMS. Each of these items are discussed in the following paragraphs. 19

28 Table 3 Procedures and Agreements Development Roadmap Airspace Adjustments According to reference 4, the Indian airspace structure will be reorganized to ensure positive air traffic control in the entire control areas, control zones and along the entire length of ATS routes outside the controlled airspace. The existing classification of Class E airspace along the ATS routes outside the controlled airspace will be upgraded as Class D in continental airspace. To provide operational flexibility to VFR flights and helicopters, airspace with Class F and G category airspace will be made available appropriate to the operational needs. In addition, the entire route structure needs to be restructured to provide direct point to point flight with shorter distance and fuel economy. Multiple direct parallel routes between city pairs with reduced lateral separation based on RNAV/RNP specifications will be implemented. ATS route structures will be designed in such a way to minimize traffic congestion and conflict over converging / crossing points. ATS route structure should support the needs of the airspace users to operate along preferred and dynamic flight trajectories that will increase capacity and enhance aircraft operating efficiency. In order to exploit the airborne capabilities of modern aircraft to navigate with required level of position accuracy without relying on ground based navigational aids, design and implementation of RNAV/ RNP routes to be implemented both in enroute and terminal approach environment Coordination with ATC The automation of coordination tasks between adjacent sectors improves the quality of information on traffic transiting between sectors and makes it more predictable, thereby allowing reduced separation minima, decreased workload, and increased capacity and more efficient flight operations. Closer coordination between ATC service providers and ATFM specialists can reduce the need for routine tactical intervention which is often disruptive to aircraft operations. 20

29 Military Coordination According to reference 4, civil and military agencies are the two major airspace users with conflicting demands to meet their objectives. While the military is mostly concerned with attaining the highest level of military capability, the first priorities for civil aviation are commercial and successful operation within the safety requirements. Military flying activities are conducted to prepare military forces for tactical and combat operational requirements. The military flying missions are normally time critical involving special maneuvers and hence needs freedom to operate at any given time and altitude which requires priority handling by the controlling agency (military ATC). The military authorities therefore evaluate their airspace needs from a different perspective than civil aviation. The primary objective of military flying activities is to achieve the tactical and combat operational requirements to meet the real time military operations. Such flying activities need to be operated without ground control under certain missions / conditions / circumstances with certain degree of confidentiality and secrecy and hence considered to be a hazardous activity for the safety of civil aircraft. The Civil traffic on the other hand requires more airspace to ensure safe, efficient and economical operations to maintain their schedule and to fulfill the customer needs. Industrial, commercial and economic growth of the state largely depends on the successful commercial civil aviation activities to the large extent. In order to sustain civil traffic growth and military needs at the same time the Air space utility needs to be optimized on real time requirement basis instead of permanent segregation and effectively managed to fulfill various user requirements while maintaining or improving the safety standards. Under the Flexible Use of Airspace Concept the entire airspace will be considered as one continuum to be allocated according to actual user requirements on need basis. Fundamental to this policy is the establishment of an Airspace Co ordination Cell which will carry out strategic planning and conduct day to day allocation of airspace to various users. Predetermined route profiles for military fighter flight operations shall be worked out and notified. Flight Plans shall be filed at least 12 hrs in advance with the ATC concerned and clearance obtained. The routes which require passing through military areas will be implemented in coordination with Military authorities based on the flexible use of airspace concept. Dynamic application of the flexible use of airspace will be implemented throughout the FIRs based on the actual user requirements Airline Coordination The AAI ATM Concept of Operations envisages a more strategic approach to ATM overall, and through collaborative decision making, a reduction in the reliance on tactical flow management. It is inevitable that tactical flow intervention will continue to be required; however closer coordination between airspace users and ATM service providers including ATFM specialists can reduce the need for routine tactical intervention which is often disruptive to aircraft operations Airport Coordination According to reference 4, the CCC will be established to optimize the airspace /airport capacity vs. demand both strategically and dynamically by integrating various operational constraints and weather parameters. Mitigating measures and alternate actions to avoid congestion and delay both 21

30 in the terminal and enroute airspace and airports will be achieved through collaborative decision making process involving all stakeholders Bilaterals as Needed Before an airline can operate international services to another country, the government must first negotiate a treaty level agreement with the destination country's government. These treaties are known as bilateral air services agreements. Bilateral air services agreements/arrangements contain provisions for: Traffic rights - the routes airlines can fly, including cities that can be served within, between and beyond the bilateral partners. Capacity - the number of flights that can be operated or passengers that can be carried between the bilateral partners. Designation, Ownership and Control - the number of airlines the bilateral partners can nominate to operate services and the ownership criteria airlines must meet to be designated under the bilateral agreement. This clause sometimes includes foreign ownership restrictions. Tariffs - i.e. prices. Some agreements require airlines to submit ticket prices to aeronautical authorities for approval (it is not current practice for Australian aeronautical authorities to require this), and Many other clauses addressing competition policy, safety and security. The result is that international aviation is regulated by a complex web of over 3000 interlocking bilateral air services agreements. In recent years, groups of countries have come together to negotiate air services agreements. These are known as plurilateral agreements; however the majority of international air services are still traded bilaterally. It is expected that the existing bilateral agreements and additional agreements resulting from the implementation of the AAI ATFMS will be identified and negotiated in a timely manner and prior to the IOC of the ATFMS as indicated in the schedule shown in Table 3. Additionally with the advent of modern ATM computer systems there has been the proliferation of treaties for the exchange of ATM computer data this enables the countries to have advance notice of flights inbound to them and the capability to track flights outbound from their airspace thus smoothing flows and mitigating congestion Staffing and Training Development of the training strategy is a key aspect of system planning which should begin early in the program. In other words, even though much of the training activity will take place after the advanced system is procured, planning should begin in the near term. For example, the functional analysis will help determine what staff will be performing advanced ATFM functions, and what gaps exist between their skills and the skills needed for the ATFMS. 22

31 Perhaps socialization is a better term for this phase in which the ATC community becomes better informed of what TFM is and how it operates. This is also carried out with other aviation partners such as the airlines and the military. Until the system and the future AAI personnel picture are better defined, it is not possible to predict what type of training will best serve the needs of India s ATFM in the long term. A few general principles can be noted, however. The potential of technology to enhance training should not be ignored. Although there is sometimes no substitute for classroom based training, Computer Based Training (CBT) should be considered as part of the training plan. In addition, it is worth considering that the operational systems be adaptable for use in training. It may be desirable to require potential contractors to propose a training plan along with their proposal for the system, with AAI retaining the option to use contractor delivered training at any level they choose based on the proposal. Taking advantage of regional training centers, as discussed in ICAO s 1998 Worldwide CNS/ATM Systems Implementation Conference, may be one useful strategy at least for high level training in ATFM concepts. This would enable an understanding that is in line with global standards and trends, and enable ATFM specialists to learn from each other. Participation in the ICAO TRAINAIR Program may also be worth considering. A schedule for the actual training of personnel is provided in Table 4. Planning of the training program is not included in this schedule but should begin when the ATFMS award is made in the first quarter of Once again, this planning may be considered as part of the contract award and the contractor s responsibility. Table 4 Staffing and Training Roadmap Required Infrastructure/Interface Preparation The advanced ATFM system will need to interface with many other systems, including the en route, approach and tower ATC systems and the AIS system. In order to ensure smooth transfer of the necessary data between systems, the final requirements package will include a document or section on interface requirements. The requirements will list what systems must interface with each other, 23

32 message types and message rates, standards to be followed, what level of security is required, and possibly some specific details on the nature of the interface, for example the transmission protocol to be used. In some cases, the latter decision may be left to the contractor. The contractor responds to the interface requirements with Interface Control Documents (ICDs), describing at the lowest level of software and hardware detail how data will proceed across the interfaces between systems. Example data to be included are signal characteristics including voltage levels, cable and connector types, timing data, and pin assignments. For interfaces between procured systems and existing AAI systems, the AAI may need to provide ICDs to the contractor. Reference 3, System Architecture and Specification For An Indian Air Traffic Flow Management System, VNTSC, May 6, 2011, provides a detailed description of each of the interfaces identified in Roadmap Table. Table 5 Infrastructure and Interface Preparation Roadmap Collaborative Decision Making Preparation The effectiveness of CDM is greatly improved by all units and stakeholders sharing the same situational awareness and using common flow planning tools to arrive at optimal Traffic Management Initiatives (TMIs). TMIs are actions taken to balance current or anticipated demand with available capacity. Examples include imposing a minimum Kilometers in Trail (KMIT) between aircraft in an en route flow or stopping departures of all aircraft destined for a particular city (a Ground Stop, or GS). TMIs work best 24

33 when all participants work together to create technological and procedural solutions to traffic flow problems, and respond collaboratively to real time operational constraints. CDM was the successful guiding philosophy for the FAA during its development of ATFM in the United States. It provides a unified approach to improve the ATM system and services through increased information exchange and a common situational awareness among stakeholders resulting in enhanced options, improved decision making, and stakeholder acceptance and support. In the United States, CDM is a formal program involving the government both the civilian and the military departments, airlines, general aviation, industry, and academia. In the FAA the entire Air Traffic Organization (ATO) has been involved in CDM from the start. It is important to include the air traffic controllers as well as the traffic management specialists. Table 6 provides a roadmap for the education of the stakeholders that are expected to participate in CDM. This preparation is described in the following paragraphs Military CDM CDM with the Military is primarily focused on the availability of Special Use Airspace. This coordination will permit the civil ATM system to use this airspace when it is not being used by the Military. In addition all TMIs issued by the ATFMS will be coordinated with the Military. Table 6 Collaborative Decision Making Preparation Roadmap Domestic Carriers CDM All TMIs developed by the ATFMS will be coordinated with India s domestic air carriers in order to assist them in their planning and to receive input with respect to potential impacts on their operations and possible alternative recommendations concerning the TMIs. 25

34 International Carriers CDM All TMIs developed by the ATFMS will be coordinated with India s international air carriers in order to assist them in their planning and to receive input with respect to potential impacts on their operations and possible alternative recommendations concerning the TMIs En Route CDM ACCs are responsible for developing TMIs within their area of responsibility. These TMIs must be coordinated with the CCC and with the affected APP TMUs and TWR TMUs within the ACC s area of responsibility. In the event that TMI s are required across ACC boundaries, the CCC is responsible for coordinating these TMIs with the affected ACCs. Feedback among the CCC, ACCs, APP TMUs and TWR TMUs is expected and encouraged in order to create the most efficient TMIs that have minimal impact on traffic operations. This feedback and coordination also extends to the ATC personnel that are responsible for implementing the TMIs Terminals CDM The APP TMUs receive TMIs from their ACC. They may also recommend TMIs to their ACC. These TMIs must be coordinated with the ATC personnel that are responsible for their implementation Towers CDM The TWR TMUs receive TMIs from their ACC and the APP TMUs. They may also recommend TMIs to their ACC and the APP TMU. These TMIs must be coordinated with the ATC personnel that are responsible for their implementation Short term ATFMS solutions These short term solutions will enable AAI to implement Traffic Flow Management (TFM) without automation and can provide immediate TFM benefits. These all require the following 5 steps being completed before the measures can be implemented: 1. Integrate all surveillance systems 2. Establish voice communications between all ACCs 3. Establish TMUs in all ACCs 4. Have TMUs work directly with ATC to manage local flow problems and with adjacent ACC TMUs by voice to manage wide area flow problems. 5. Establish a pseudo CCC at one of the ACC TMUs to act as the command center. Table 7 provides a Roadmap for implementing these short term ATFMS solutions. 26

35 Table 7 Short Term ATFMS Solutions Implement Miles In Trail (MIT) restrictions between centers and nationally A specified interval between aircraft expressed in nautical miles that meet a specific criteria. The criteria may be separation, airport, fix, altitude, sector, or route specific. MIT are used to apportion traffic into manageable flows, as well as, provide space for additional traffic (merging or departing) to enter the flow of traffic Implement Ground Delay Programs (GDPs). A GDP is a TFM process administered by the CCC; when aircraft are held on the ground in order to manage capacity and demand at a specific airport, by assigning arrival slots. The purpose of the program is to support the TFM mission and limit airborne holding. It is a flexible program and may be implemented in various forms depending upon the needs of the air traffic system. The EDCT is calculated based on the estimated time en route and the arrival slot. It is important for aircraft to depart as close as possible to the EDCT to ensure accurate delivery of aircraft to the impacted location. GDPs provide for equitable assignment of delays to all system users Implement Ground Stops (GSs) The GS is a process that requires aircraft that meet a specific criteria to remain on the ground. The criteria may be airport specific, airspace specific, or equipment specific. GSs normally occur with little or no warning. Since GSs are one of the most restrictive methods of traffic flow management, alternative initiatives should be explored and implemented if appropriate. GSs should be used: a. In severely reduced capacity situations (below most user arrival minimums, airport/runway closed, or aircraft accidents/incidents); b. To preclude extended periods of airborne holding; c. To preclude sector/center reaching near saturation levels or airport grid lock; 27

36 d. In the event a facility is unable or partially unable to perform ATC services due to unforeseen circumstances; e. When routings are unavailable due to severe weather; and f. When routings are unavailable due to catastrophic events Implement Call for Release. This is an easily implemented TMI that requires verbal coordination initiated by a terminal facility to secure ACC approval for releasing a departure into the en route environment. 28

37 2.2 ATFMS Implementation Engineering Considerations The requirements for a large scale system, or any system, do not consist only of the functions that the system needs to achieve, but also how reliably it will serve the necessary purposes. In other words, functional requirements dictate what the system shall do, the Statement of Work dictates what the contractor shall do and what equipment is to be provided and performance requirements indicate how well the system must perform the required functions. The engineering considerations described in this section provide support for the accomplishment of the ATFMS implementation as described in section 2.1 by specifying specific factors to be included as part of the ATFMS tender Performance and Capacity This section focuses on the set of requirements for performance and capacity. This refers to things like reaction time (how fast the system shall process certain data and user inputs), accuracy (especially important is accuracy of reporting data to the operator about where the relevant flights are and for ATFM, accurate prediction of demand), and capacity (for example, how many flights can be in the system at once). References 1, 2, and 3 provide a set of requirements that are reasonable for vendors to meet, and that meet and exceed expected traffic loading in India. Specifically, section 4.12 of reference 2 and 5.13 of reference 3 address ATFMS Performance Requirements Reliability/Maintainability/Availability (RMA) It is critical that any system supporting the management of air traffic be highly reliable, not subject to system outages, and redundant. RMA requirements, as provided in references 2 and 3, dictate how frequently the system is permitted to experience outages, and how much time the outage is permitted to last. When the system is delivered, this type of requirement cannot be tested directly, because RMA requirements typically require that outages occur on a very infrequent basis. Therefore, the contractor will be required to provide analysis to demonstrate low likelihood of failure and ease of repair, including records of the performance of similar systems they have implemented in other locations. A maintenance strategy will also need to be developed. Decisions must be made by AAI regarding how much of the system maintenance will be the responsibility of the system contractor and how much will be conducted internally. The final decision will depend on cost and personnel considerations, and many other factors. The analysis may be done before the procurement to determine a strategy, or the RFP may request the bidders to indicate the system maintenance level they are able to provide and the cost for the service. The latter strategy allows AAI to defer the decision and make the decision based on written, formally submitted information rather than estimates. A useful strategy is a phased maintenance transition from contractor to AAI, where a warranty period of several years takes place at the beginning of system usage, during which the contractor is responsible for certain types of maintenance. During the early part of the warranty period, perhaps the first year, the contractor may be required to dispatch on site maintenance personnel who are based at the system location. They will be responsible for immediately addressing any maintenance issues and for training AAI maintenance and technical personnel. As time goes on, the AAI personnel can take on more and 29

38 more responsibility for system operation, so that by the end of the warranty period, they are fully capable of conducting all maintenance activities which AAI has chosen not to contract out Contingency Planning/Backup Closely related to RMA issues, contingency planning outlines what will be done in the rare cases where system failure does occur. System recovery and data backup requirements are specifically addressed in sections 4.12 of reference 2 and 5.13 of reference 3. As previously mentioned, these requirements cannot be directly tested and it is unlikely but possible that when an actual system outage occurs, it may be more severe or last longer than the requirements permit. Contingency/backup planning should lead to specific system requirements that are placed in the ATFMS tender. For example, a hot backup CCC is specified in reference 3. Thus, the backup CCC must be specified as a contract deliverable Monitoring and Control The issue of planning for Monitoring and Control has two aspects. The first has to do with the assessment how well the ATFMS is performing its intended functions while the second is concerned with ATFMS hardware and/or software failure detection. References 2 and 3 address both of these considerations and should be included as part of the tender statement of work Information Security Due to the worldwide increase in hacking and information attacks, Information Security is one of the most critical engineering considerations and is a key component of the ATFMS Architecture as described in reference 3. The contractor should be required to not only respond to the security requirements included in the ATFMS tender, but also to develop and submit a system security plan which will indicate all securityrelated system components, and how they will be monitored and tracked throughout the life of the contract Safety Engineering/Safety Management System (SMS) It is important to put in place an SMS process based on international standards. The primary references of an SMS process can be found in ICAO Annex 11 (Standards and Recommended Practices SARPs), particularly the section on ATS Safety Management, and ICAO 4444 (Procedures for Air Navigation Services ATM, PANS ATM), which also contains a section on ATS Safety Management. The FAA and other ANSPs around the world also have mature SMS plans and procedures that can serve as a reference. ATFM is not as directly related to safety as ATC; therefore, this subsection will describe SMS only at a very high level. However, ATFM issues can have an indirect, though very real, impact on safety. For example, a goal of ATFM is to keep ATC workload at a manageable level, and if it does not succeed in this goal, an unsafe situation may result. 30

39 The Safety Management process can be described as consisting of several stages: prevent; report; and learn. Obviously the best solution to safety issues is to prevent them. Safety Reviews and Safety Assessments must be conducted at all stages of the ATFMS implementation and operation to determine where the safety risks are and how they can be mitigated. The report activity involves safety monitoring and investigation of occurrences after the fact. From this activity, AAI can learn what Safety Enhancement Measures can be implemented to reduce the risk of future occurrences. After ATFMS acceptance, the transition plan needs to be assessed from a safety perspective to ensure that operators are familiar enough with the new system and are not confused by differences or similarities between the new and old way of performing their tasks. Ongoing safety assessments are necessary throughout the life cycle, of the system, environment, and facilities, on a continual basis. The ATFMS must be included as an integral part of the overall AAI safety monitoring as assurance procedures Human Factors Engineering Management Any automation system procured for ATM is procured in order to support human operators in their tasks. Specific requirements must be defined to ensure that the system is easy to use for the operators and enables them to have correct and understandable information to make decisions. The FAA has published a comprehensive set of Human Factors requirements known as the Human Factors Design Standard (HFDS) which has been used not only in the US, but globally to ensure the safe and efficient use of ATM automation. Requirements based on Human Factors standards are sometimes quantitative and easy to test. Others, however, are subjective and present more of a challenge at the stages of proposal, system evaluation, and requirement verification. For testing the acceptability of a system from the Human Factors perspective, AAI and the contractor must work closely together to define tests that measure standards compliance in an objective manner. Test design and execution personnel should have expertise in the Human Factors specialty. Operational personnel should review the ATFMS during proposal evaluation and during system design and testing to ensure acceptability. Though this evaluation will be partially subjective, quantitative instruments can also be developed and employed to demonstrate in a defensible way why one system is preferable to another in the context of a specific Human Factors standard, or why one design feature is preferable to another. Reference 3 specifically addresses the specifications for the ATFMS Specialist Displays in section 3.1. These specifications should be included as part of the ATFMS tender Communication Planning The program requires communication among all stakeholders, particularly AAI and the contractor. A formal communication plan defines the who, what, when and how of communication. Specifically, formal rules must be established for the life of the ATFMS implementation, specifying who must receive a certain piece of information regarding the system or program status, precisely what information they receive, by what means, and in what timeframe. For example, items such as progress reports, program reviews, design documentation and the like should be defined in detail in this plan. This plan is defined 31

40 by AAI as the customer, with contractor input as appropriate and AAI retaining the authority for final approval of the Communication Plan Risk Management The Risk Management process enables AAI to track all risks associated with the program. Risks include anything that represents an adverse effect to successful and timely completion of the ATFMS implementation program. Risk may be discovered by examining the implementation schedule or the implementation plan, which may reveal tasks that depend on each other and do not have enough slack built into the schedule. In the Risk Management process, either AAI or the contractor may identify a risk. A database system or dedicated System Engineering tool should be used to track risks, and will contain important fields such as the name and description of the risk, the party responsible, and the probability and severity of the event occurring. A mitigation strategy and contingency plan must also be included with each risk. Formulas will be developed, by mutual agreement of AAI and the contractor, and based on accepted standards, to assign a risk level to each risk item based on its probability and severity. The risk level may be defined numerically or categorically (e.g., Severe, High, Medium, Low, or Negligible). For example, an event with a 70 percent probability of occurrence and resulting in a possible danger to ATC related safety might be assigned a risk level of 9 on a 1 to 10 scale, or a category of High. However, these are only examples. AAI will have final approval on the risk formulas. The contractor should be responsible for tracking all risks and reporting their status on a regular basis and this requirement should be included as part of the ATFMS tender. 32

41 3 Work Breakdown 3.1 Introduction Purpose The work breakdown structure presented in this roadmap establishes a common framework and uniform work activity definitions for use by the AAI acquisition management workforce when planning lifecycle acquisition management activities, estimating associated costs, and collecting actual costs. This work activity is engineered to define, obtain, and support the ATFMS over its service life Organization and Scope The ATFMS work breakdown structure is organized by lifecycle management phases as shown in Figure 5. 33

42 Figure 5 : ATFMS Life Cycle Work Breakdown Structure ATFMS Mission analysis The data collection and analysis activities required to quantify AAI s ability to satisfy existing and emerging demand for services. These work activities precede the establishment of specific investment programs and are undertaken to define AAI strategic and performance goals and identify promising opportunities and technologies for achieving those goals. ATFMS Investment analysis This element includes all activities required for investment and alternatives analysis. These work activities are performed to analyze alternative solutions and develop detailed planning and baseline values for the best overall approach. ATFMS Solution Development All activity required for ATFMS solution development including hardware systems, software systems, facilities, physical infrastructure, and telecommunications. This also consists of those activities associated with initial development, modifications, upgrades, and preplanned product improvements. ATFMS implementation All activity required for site planning and preparation through commissioning. 34

43 During this phase, work is performed by the prime contractor, the AAI ATFMS program office, and other supporting AAI offices. Note that Site Acceptance Test (SAT) activities are not captured here, but are in WBS Task 3.5 Test and Evaluation ATFMS In service management All activities required for in service management. This Includes all activities associated with directly operating, providing maintenance functions (both scheduled and unscheduled), or furnishing technical or logistics support for maintenance of AAI systems, sub systems, services or equipment. It also includes associated travel time required to support the system. These work activities support and sustain operational assets over their service life whether they are systems, equipment, facilities, infrastructure, or services. ATFMS Disposition All activities required for the disposal management, dismantling/demolition/removal, restoration, and salvage of decommissioned equipment, systems or sites Usage This WBS defines the top levels of work breakdown for the ATFMS. The WBS is used to develop detailed implementation plans and cost estimates. Users employ only those work activities that apply to their task and may add detail below the levels presented herein. Contractors should submit proposals and structure their contract WBS consistent with this ATFMS WBS. The WBS work activities during solution implementation are organized as a program work breakdown structure for use by program management organizations when planning program implementation and estimating costs for development, deployment, and lifecycle support. The same work breakdown may be used to gather and track actual costs against planed costs. Contract WBS structures should be derived from and mirror this AAI ATFMS WBS with lower levels of work specificity adding to the appropriate lowest activity of this WBS Discussion of Process, Decisions, and Assumptions This AAI Standard Work Breakdown Structure (WBS) represents the complete set of activities that may be accomplished to provide a solution that satisfies the AAI mission need for the ATFMS. The ATFMS includes products and services such as hardware, software, facilities, communications services, technical assistance services, infrastructure, etc. This WBS will support management of solutions during the solution implementation and in service management phases, and will aid in the comparison of life cycle cost estimates to actual costs that have been collected by AAI. In this WBS, Mission Analysis and Investment Analysis activities precede the formal establishment of a specific solution. The remaining elements in the WBS are activities that are directly associated with a specific solution. The elements in the WBS represent activities; not the resources needed to accomplish the activities. These activities are arranged hierarchically and no sequence or organizational responsibility is implied. This WBS is also intended for use by AAI in developing life cycle cost estimates of alternative solutions 3.2 ATFMS Detailed Work Breakdown Structure The following paragraphs present the ATFMS WBS. It is expected that the ATFMS tender will require the proposing contractors to use this WBS and to explain their approach to accomplishing the tasks contained in this WBS by providing at least one additional level of detail. 35

44 3.2.1 ATFMS Mission Analysis (Figure 5 Box 1.0; Figure 6 Box 1.0) The second level of the ATFMS Mission Analysis element of the WBS is presented as Figure 6 Figure 6 ATFMS Mission Analysis WBS Level Identify Projected Demand for Services (Figure 6 Box 1.1) All activities required, including data collection, to identify and quantify projected demand for ATFMS services, based on diverse inputs in the form of: external demand for service and capacity; long range plans and projections; local site trends; and performance and supportability trends of fielded equipment. These activities are assumed to have been completed Identify Technological Opportunities (Figure 6 Box 1.2) All activities required to identify and quantify projected technological opportunities that will enable the AAI to perform its mission more safely, efficiently, and effectively are included in this element of the WBS. These activities include review of hardware, software and systems currently available commercially or projected to be available commercially, instead of hardware, software and systems that could be custom developed for the AAI. The extent to which these activities have been completed are not presently known Identify Projected Supply of Services (Figure 6 Box 1.3) This element includes all activities required to identify and quantify existing and projected supply of services based on performance and supportability data; external and internal assessments of AAIprovided services; and assessments of current and planned ATFMS capabilities. The extent to which these activities have been completed are not presently known Mission Needs Analysis and Assessment (Figure 6 Box 1.4) All activities required to analyze, quantify and prioritize capability shortfalls (the difference between demand and supply) and technological opportunities to increase operational safety, efficiency, or 36

45 effectiveness. This includes documentation of the mission analysis itself, and the preparation and approval of the Mission Need Statement. These activities are assumed to have been completed ATFMS Investment Analysis (Figure 5 Box 2.0; Figure 7 Box 2.0) Three levels of the ATFMS Investment Analysis element of the ATFMS WBS are presented as Figure 7. Figure 7 ATFMS Investment Analysis WBS Level Requirements Definition (Figure 7 Box 2.1) This includes all activities that are required to translate information in the Mission Need Statement into a Requirements Document, consistent with the ATFMS Operational Concept (Reference 1) Initial Requirements Definition (Figure 7 Box 2.1.1) All activities required to translate information in the Mission Need Statement into an Initial Requirements Document. This has been accomplished with the delivery of Reference 2 Qualitative Requirements and Reference 3 ATFMS Architecture and Specification Finalize Requirements (Figure 7 Box 2.1.2) All activities required to finalize and approve the Requirements Document after the market analysis, analysis of alternatives, and affordability assessment. This activity has been scheduled in this Roadmap (see Table 2 ATFMS Development and Implementation Roadmap) and remains to be accomplished Alternatives Identification and Analysis (Figure 7 Box 2.2) 37

46 This WBS element includes those activities required to identify and analyze alternatives, including affordability assessment and all activities required for the investment decision. The AAI status of alternatives identification and analysis is not presently known although several alternatives exist as pointed out in Section Alternatives Identification Figure 7 Box 2.2.1) All activities required to use the initial requirements as a basis for identifying all potential material and nonmaterial solutions to the mission need, using market surveys as well as input from industry and AAI organizations that have potential solutions. The status of this activity is not known Alternatives Analysis (Figure 7 Box 2.2.2) All activities required to evaluate candidate solutions by compiling and analyzing such factors as life cycle cost (including sustainment, supportability, and disposal), cost benefits, risk, technical performance, schedule, human factors, space, real estate, heating and cooling, power, telecommunications, physical infrastructure, training, environmental impact, security, radio frequency spectrum, logistics support, compatibility with ATM Architecture, regulatory and procedural impact, operational suitability, and disposal of obsolete assets. All activities required to assess the affordability of each candidate solution against all other programs in the AAI plans. All activities required to document the results of the investment analysis in the Investment Analysis Report. The report defines each candidate solution to a mission need, including an Acquisition Program Baseline for each candidate solution, and compares the relative strengths and weaknesses of each for all evaluation factors considered during investment analysis. The status of these activities is not known ATFMS Solution Development (Figure 5 Box 3.0; Figure 8 Box 3.0) Two levels of the ATFMS Solution Development element of the ATFMS WBS are presented as Figure 8. A brief description of each of these elements is also presented in this section. A third level for each of these second level elements is presented in the following paragraphs. 38

47 Figure 8 ATFMS Solution Development WBS Level Program Management (Figure 8 Box 3.1; Figure 9 Box 3.1) Business and administrative planning, organizing, directing, coordinating, controlling, and approval actions designed to accomplish overall program objectives. This activity has been partially accomplished. The activities within this element of the WBS are illustrated in Figure 9. Figure 9 Components of the Program Management Element of the WBS Work Planning, Authorization, and Management (Figure 9 Box 3.1.1) This includes all activities required to develop the strategy for implementing and executing the overall program. It also consists of those activities required to plan, authorize and manage all actions and 39

48 activities that must be accomplished for successful program development which includes preparation of the Acquisition Strategy Paper and Integrated Program Plan and project specific input to planning documents, such as the tender and the ATFMS architecture. This activity has been partially completed with the delivery of references 1, 2, and 3 in addition to this roadmap Program Control (Figure 9 Box 3.1.2) All activities required to ensure that all cost, schedule, performance, and benefit objectives are met. Risk and requirements management activities are also included. This activity is partially complete Contract Management (Figure 9 Box 3.1.3) All activities required to award and manage project related contracts. This activity is partially complete System Engineering (Figure 8 Box 3.2; Figure 10 Box 3.2) All technical and management activities associated with a specific solution. These activities include directing and controlling a totally integrated engineering effort of a solution. This activity has been partially accomplished. The activities within this element of the WBS are illustrated in Figure 10 Figure 10 Components of the ATFMS System Engineering Element of the WBS System Requirements and Definition (Figure 10 Box 3.2.1) These system engineering activities are to transform the performance requirements into specifications and a preferred solution configuration. This system engineering effort, which is applicable to each component of the solution throughout all phases, includes developing and maintaining design criteria and preparing and maintaining system level data flows, block diagrams, change proposals and documentation trees. An initial set of qualitative requirements, architecture and ATFMS specification have been delivered to AAI as references 1, 2, and 3 and satisfy this activity Analysis, Design, and Integration (Figure 10 Box 3.2.2) This activity includes overall analysis, design and integration of the solution, e.g., hardware system, software, facility, telecommunications. Includes design integrity analysis, intra and inter system compatibility assurance (interface identification, analysis and design), and the integration and balancing of reliability, maintainability, producibility, safety, and survivability. Design includes allocating functions to appropriate elements (e.g., hardware, software, telecommunications, user functions, services, facilities, etc.), and presenting prepared design information at identified design reviews. This activity remains to be accomplished. 40

49 Value Engineering (Figure 10 Box 3.2.3) All activities involved in analyzing current designs verses alternative designs in order to quantify the value added and cost reduction of alternative architectures. This activity remains to be accomplished Supportability, Maintainability, and Reliability Engineering (Figure 10 Box 3.2.4) This activity represents all engineering activities and analyses undertaken during solution development as part of the engineering and design effort, to assist in complying with supportability and other logistics support objectives. All maintenance planning activities required to measure the ability of an item or solution to be retained at or restored to a specific condition of readiness. All activities associated with reliability engineering, defined as the engineering process required to examine the probability of a solution performing its mission adequately over the intended period of time and under expected operation conditions. This activity remains to be accomplished Quality Assurance Program (Figure 10 Box 3.2.5) All activities associated with development of planning, procedures, examinations, and tests required during procurement, production, receipt, storage, and issue that are necessary to develop the solution in accordance with identified standards and specifications. This activity remains to be accomplished Configuration Management (Figure 10 Box 3.2.6) All activities associated with the establishment, monitoring and administration of change control procedures, including collection, processing, distribution and tracking of modification request forms, establishment and administration of change control boards, and formal audits to compare product to documentation. It includes configuration management of hardware, software, facilities, data, interfaces, tools, and documentation. It is assumed that AAI has existing CM processes in place and that adaptation to ATFMS is all that is required. This has also been partially accomplished with the delivery of references 1, 2, and Human Factors (Figure 10 Box 3.2.7) All activities required to define, as a comprehensive technical and engineering effort, the integration of doctrine, personnel, material, operational effectiveness, human characteristics, skill capabilities, and training. This has been partially accomplished with the delivery of references 1, 2, and Security (Figure 10 Box 3.2.8) All engineering activities and tasks associated with security requirements and issues (information security, physical security, personnel security, etc.). This has been partially accomplished with the delivery of references 1, 2, and HW/SW Design, Development and Production (Figure 8 Box 3.3; Figure 11 Box 3.3) All activities required to design and develop hardware and software configuration items at the development facility, and the resulting integration, testing, assembly, checkout, and production. This total activity remains to be accomplished. The activities within this element of the WBS are illustrated in Figure

50 Figure 11 Components of the ATFMS H/w & S/W Design, Development & Production Element of the WBS Hardware Design and Development (Figure 11 Box 3.3.1) All activities associated with detailed design, fabrication, assembly and checkout of all Hardware Configuration Items (HWCIs) of the initial unit(s) Software Design and Development (Figure 11 Box 3.3.2) All activities associated with the detailed design, prototyping, development and unit level checkout of all Computer Software Configuration Items (CSCIs). A CSCI is an aggregation of software, or any of its discrete portions which satisfies an end use function and has been designated for configuration management HW/SW Integration, Assembly, Test and Checkout (Figure 11 Box 3.3.3) All activities associated with development site integration, assembly, and checkout of hardware, software and telecommunications components. Included are interface materials and parts required for the in plant integration and assembly into the system within suppliers facilities, and all materials and parts or other interfacing equipment furnished by the integrating agency or contractor Production Engineering (Figure 11 Box 3.3.4) Engineering activities involved in taking the development system to production. This includes developing and maintaining production process documentation Production (Figure 11 Box 3.3.5) All activities associated with full scale production necessary to fulfill quantity requirements for solution implementation, including procurement of Commercial Off The Shelf (COTS) or Non Developmental Item (NDI). Includes all activities related to contractor conducted testing performed on each end item before it leaves the factory to verify that the end item conforms to applicable specifications, and is free from manufacturing defects. Includes any non recurring production start up costs associated with the production of the solution such as facility expansion or construction, retooling or production equipment acquisition or modification, etc. 42

51 Facilities and Physical Infrastructure Design and Development (Figure 8 Box 3.4; Figure 12 Box 3.4) All national (non site specific) activities associated with design and development of facilities and physical infrastructure. The AAI status of this entire activity is not presently known. The components of this element of the ATFMS WBS are illustrated in Figure 12. Figure 12 Components of the Facilities and Physical Infrastructure Element of the WBS Facility Planning and Design (Figure 12 Box 3.4.1) All activities associated with translating facility requirements to national level Architecture and Engineering facility design, and planning and programming to accommodate site specific needs. This includes design of lighting, space, environment, heating, ventilation, air conditioning, grounding, bonding, shielding, lightning protection, cabling, etc Real Estate (Figure 12 Box 3.4.2) All activities associated with determining real estate needs and AAI level planning and programming for acquisition Physical Infrastructure (Figure 12 Box 3.4.3) All activities associated with translating physical infrastructure requirements to national level designs, and planning and programming to accommodate site specific needs. This includes design of telecommunications, power systems and commercial power, water and sewage systems, etc. Also includes activity associated with national purchases Test and Evaluation (Figure 8 Box 3.5; Figure 13 Box 3.5) All testing and evaluation activities necessary to verify and validate that products meet specifications, satisfy requirements and are operationally suitable and effective. This entire activity remains to be accomplished. The components of the element of the WBS are illustrated in Figure

52 Figure 13 Components of the ATFMS T&E Element of the WBS System Development Test and Evaluation (Figure 13 Box 3.5.1) All activities associated with test and evaluation conducted to demonstrate that all engineering design and development activities are complete, and that the system will meet specifications. Development test and evaluation includes contractor and in house activities associated with this effort, e.g., software validation and verification. All support activities (e.g. technical assistance, maintenance, labor, material, support elements and testing spares, etc.) required during this phase of testing are included. Development and construction of those special test facilities, test simulators, test beds and models required for performance of the developmental tests necessary to prove the design and reliability of the system or subsystem System Operational Test and Evaluation (Figure 13 Box 3.5.2) All activities associated with test and evaluation conducted to assess the prospective system s utility, operational effectiveness, operational suitability, and logistics supportability (including compatibility, interoperability, reliability, maintainability, logistics requirements, etc.). All support activities (e.g. technical assistance, maintenance, labor, material, support elements and testing spares etc.) required during this phase of testing are included. All activities associated with development and construction of those special test facilities, test simulators, test beds and models required for performance of the operational tests necessary to prove the system s utility, operational effectiveness, operational suitability, and logistics supportability System Independent Software Verification and Validation (Figure 13 Box 3.5.3) All activities performed by organizations other than the developer to determine the degree to which the software fulfills the specifications. Formal verification is a rigorous mathematical demonstration that source code conforms to its requirements. Validation is concerned with evaluation of a software product at the end of the development process to determine compliance with product requirements. 44

53 Site Acceptance Testing (Figure 13 Box 3.5.4) All activities associated with contractor conducted testing performed at field site(s) to verify that the new system is installed and operating properly Independent Operational Test and Evaluation (Figure 13 Box 3.5.5) All activities associated with independent tests and oversight conducted by organizations other than the developer in a realistic environment to confirm the operational readiness (suitability and effectiveness) of AAI systems to become part of the ATFMS. Includes all support activities Documentation (Figure 8 Box 3.6) All activities associated with production, delivery and review of AAI programmatic documents and contractor documentation deliverables. Included are managing, coordinating, editing, scheduling, auditing and assembly of the documents and review packages necessary to the functioning of the program. It includes acquiring, writing, assembling, reproduction, packaging and shipping the data. It also includes the activities involved in converting data from contractor format into government format, as well as reproducing and shipping the data. This activity has been partially accomplished. There are no components of the WBS element Support (Figure 8 Box 3.7; Figure 14 Box 3.7) All activities associated with the acquisition of test and measurement equipment, support and handling equipment, support facilities, initial spares and repair parts and training required to support and maintain the system or portions of the system through the complete delivery of the solution, but not directly engaged in the performance of the system mission. This entire activity remains to be accomplished. The components of this WBS element are illustrated in Figure 14. Figure 14 Components of the Support Element of the ATFMS WBS Logistics Support Planning (Figure 14 Box 3.7.1) All planning activities associated with fulfilling the requirements to provide logistics support to the solution. 45

54 Test and Measurement Equipment Acquisition (Figure 14 Box 3.7.2) All activities associated with the acquisition of test and measurement equipment which is used to evaluate operational conditions of a system or equipment at all levels of maintenance. It includes the test measurement and diagnostic equipment, precision measuring equipment, automatic test equipment, manual test equipment, automatic test systems, test program sets, appropriate interconnect devices, automated load modules, and related software, firmware and support hardware. Packages which enable line or shop replaceable units, printed circuit boards, or similar items to be diagnosed using automated test equipment are also included Support and Handling Equipment Acquisition (Figure 14 Box 3.7.3) All activities associated with acquiring tools and handling equipment used for support of the mission system. Equipment typically included is ground support equipment, powered support equipment, material handling equipment, and software support equipment, both hardware and software Support Facilities Construction / Conversion / Expansion (Figure 14 Box 3.7.4) All activities associated with construction, conversion, or expansion of support facilities for training, testing, inventory, contractor and AAI depot maintenance, hazardous waste management, etc. required for the specific system Support Equipment Acquisition / Modification (Figure 14 Box 3.7.5) All activities associated with acquisition or modification of support equipment or software for training, testing, inventory, contractor and AAI depot maintenance, hazardous waste management, etc. required for the specific system Support Facilities and Equipment Maintenance (Figure 14 Box 3.7.6) All activities associated with maintenance of support facilities and equipment for training, testing, inventory, contractor and AAI depot maintenance, hazardous waste management, etc. required for the specific system prior to the in service decision Initial Spares and Repair Parts Acquisition (Figure 14 Box 3.7.7) All activities associated with the acquisition, provisioning, packaging, handling, storage and transportation of deliverable spare components, assemblies and subassemblies used for initial replacement purposes in the system hardware. Includes the repairable spares and repair parts required as initial stock to support and maintain newly fielded systems or subsystems, including pipeline quantities, during the initial phase of service at all levels of maintenance and support Initial Training (Figure 14 Box 3.7.8) All activities associated with designing, developing, and delivering training services, aids, and materials used to train site technicians, depot technicians, engineers, air traffic controllers, and other personnel ATFMS Implementation( Figure 5 Box 4.0; Figure 15 Box 4.0) Implementation includes all activity required for the site planning and preparation through commissioning. Note: Site Acceptance Test (SAT) activities are not captured here, but are in section 46

55 Test and Evaluation. The elements of the ATFMS Implementation segment of the WBS are illustrated in Figure 15. This portion of the ATFMS has been partially accomplished as illustrated in the following paragraphs. Figure 15 Elements of then ATFMS Implementation Segment of the WBS Program Management (Figure 15 Box 4.1; Figure 16 Box 4.1) Business and administrative planning, organizing, directing, coordinating, controlling, and approval actions designed to accomplish overall program objectives. This activity has been partially accomplished by virtue of the on going ATFMS effort. The components of the element of the WBS are illustrated in Figure 16. Figure 16 The Components of the Program Management Element of the ATFMS WBS Work Planning, Authorization, and Management (Figure 16 Box 4.1.1) All activities required to plan, authorize and manage all actions and activities that must be accomplished for program implementation including preparing project specific input to agency level planning 47

56 documents, such as the call for estimates and the ATFMS Implementation Work Plan. This includes all activities associated with security control. This effort is partially complete Program Control (Figure 16 Box 4.1.2) This includes all activities for ensuring that all cost, schedule, performance, and benefit objectives are met. The status is not presently known Contract Management (Figure 16 Box 4.1.3) All activities associated with the award and management of project related contracts. This effort remains to be accomplished Engineering (Figure 15 Box 4.2) All engineering activities associated with the plants site surveys, design, analysis, and studies. This includes civil, electrical, mechanical, architectural, industrial, and other non electronic plant type engineering positions. This includes drafting, airspace studies, coordination with applicable organizations, and development of plans and specifications. All electronics engineering activities associated with the electronics installation design, analyses, and studies. This includes spectrum analysis, coordination with sponsoring organizations, and development of installation drawings. All physical integration activities associated with site modification requirements to ensure that product integrates into the ATFMS. This includes all activities to assess site conditions, the current product s physical requirements, and transition requirements. All engineering activities associated with achieving both transition and operational requirements for physical security. This activity has been partially accomplished Environmental and Occupational Safety and Health Compliance (Figure 15 Box 4.3) All activities associated with satisfying environmental, occupational safety and health and hazardous materials laws and regulations for the program and its products. This includes environmental impact statements, and assessments. This activity remains to be accomplished Site Selection and Acquisition (Figure 15 Box 4.4) All activities including real estate, initial analysis, data gathering, identifying candidates, analyzing, coordinating, testing, and providing final recommendations for site approval. This includes coordination with all applicable organizations, unions, and the public. All activities associated with acquiring real estate. This includes development and review of property maps, appraisals, title searches, etc. This activity has been partially accomplished with the selection of the four and then two ACCs as well as the location of the CCC Construction (Figure 15 Box 4.5) All activities associated with actual construction or modification of a site. This includes all activities to execute, control, schedule, quality control, and secure plant equipment and utility services to ensure the site meets requirements and provides a safe environment for its life cycle. All activities associated with 48

57 the implementation of telecommunications services required to achieve full operational capability. The status of these activities are not known Installation and Checkout (Figure 15 Box 4.6) All activities associated with installation and checkout of hardware, software, and equipment at the site in order to achieve operational status. This includes coordination with all applicable organizations, unions and the public during installation and transition. This activity remains to be accomplished Commissioning/Closeout (Figure 15 Box 4.7) All activities associated with preparing for and achieving full operational capability (FOC), service availability, and commissioning. This includes operational procedure development or modification, field familiarization activities, preliminary and final commissioning, and other applicable testing. All activities associated with clean up activities required after the new system has been commissioned. This includes capitalization of Facilities & Equipment projects and the update and submittal of redlined facility drawings. This activity remains to be accomplished Telecommunications (Figure 15 Box 4.8) All initial activities required to fully implement telecommunications services required to achieve full operational capability. The status of this activity is not presently known Implementation Training (Figure 15 Box 4.9) All activities associated with development and delivery of initial, refresher, and attrition training for implementation personnel. This activity remains to be accomplished ATFMS In Service Management (Figure 5 Box 5.0; Figure 17 Box 5.0) In Service Management includes all activities required for the In Service Management Phase of the ATFMS. It includes all activities associated with directly operating, providing maintenance functions (both scheduled and unscheduled), or furnishing technical or logistics support for maintenance of AAI systems, sub systems, services or equipment. It also includes associated travel time required to support the system. This entire portion of the ATFMS remains to be accomplished. The components of In Service Management are illustrated in Figure 17. Figure 17 ATFMS In Service Management WBS 49

58 Preventive Maintenance/Certification (Figure 17 Box 5.1) All activities associated with preventive maintenance of hardware and software to include activities specific for certification Corrective Maintenance (Figure 17 Box 5.2) All activities associated with corrective maintenance of hardware and software. This also includes activities related to packaging and shipping components to depot level repair facilities Modifications (Figure 17 Box 5.3) All activities associated with implementation of modifications to in service hardware and software Maintenance Control (Figure 17 Box 5.4) All activities associated with providing oversight/coordination in operating and maintaining the ATFMS infrastructure Technical Teaming (Figure 17 Box 5.5) All activities associated with the investigation and resolution of general technical issues relating to system performance Shift Augmentation (Figure 17 Box 5.6) All additional activity associated with meeting watch standing coverage beyond stated staffing requirements Program Support (Figure 17 Box 5.7; Figure 18 Box 5.7)) All administrative activities associated with planning, organizing, managing, and directing actions required in support of operating and maintaining the solution. The components of this element of the WBS are illustrated in Figure

59 Figure 18 ATFMS Program Support WBS Components Work Planning, Authorization and Management (Figure 18 Box 5.7.1) All activities required to plan, authorize and manage all actions and activities that must be accomplished for operation and maintenance of the solution. This includes preparing project specific input to agencylevel planning documents, such as the call for estimates and ATFMS architecture. This includes all activities associated with security control Program Control (Figure 17 Box 5.7.2) All activities required to ensure that all cost, schedule, operational performance, and benefit objectives are met. Risk management activities are also included Contract Management (Figure 17 Box 5.7.3) All activities associated with the award and management of solution related contracts, such as logistics contracts, service management contracts, equipment repair contracts and maintenance contracts Logistics (Figure 16 Box 5.8; Figure 19 Box 5.8) All activities associated with providing logistics support for the system. The components of this element of the WBS are illustrated in Figure Supply Support (Figure 19 Box 5.8.1) All activities associated with ordering, receiving, tracking, sending, etc. supplies needed in order to operate and maintain the solution. This also includes activities related to Packaging, Handling, Storage and Transportation (PHS&T) for materials needed to support the solution. This also includes inventory management and cataloging. 51

60 Repair (Figure 19 Box 5.8.2) All activities associated with depot level repair of equipment in support of the solution. This does not include costs incurred at the site Support Equipment Maintenance (Figure 19 Box 5.8.3) All activities associated with replenishment, maintenance, and calibration of support equipment Warranty Tracking (Figure 19 Box 5.8.4) All activities associated with managing warranties. Figure 19 Components of the Logistics Element of the WBS In Service Training (Figure 17 Box 5.9) All activities associated with Attrition Training and Refresher Training of personnel who directly operate, maintain, or provide support functions of the solution. This does include contractor provided costs as associated with specific training Second Level Engineering (Figure 17 Box 5.10) This includes all engineering activities in support of the delivery of service, to include development of modifications, documentation and configuration management. It also includes evaluation of potential technology refresh Infrastructure Support (Figure 17 Box 5.11; Figure 20 Box 5.11) Maintenance and operations of leased and owned buildings, structures, grounds, roads, support vehicles for operational systems or people who support or operate those systems. The components of 52

61 this element of the WBS are illustrated in Figure 20. The status of infrastructure support activities are either unknown or remain to be accomplished. Figure 20 Components of the Infrastructure Support Component of the WBS Hazardous Materials Handling (Figure 20 Box ) All activities associated with providing pollution prevention and hazardous waste management and remediation. These activities remain to be accomplished Utilities, Building and Grounds Upkeep and Maintenance (Figure 20 Box ) All activities associated with efforts to routinely maintain, modernize, and relocate the buildings, structures, roads, grounds and support equipment. Recurring costs of utilities (water, electric, gas, oil, etc.) used to provide heat, air conditioning, and water to sites. These activities remain to be accomplished Telecommunications (Figure 20 Box ) All activities associated with maintaining, upgrading or modifying operational and administrative communications services required for the operation and maintenance of the solution. The status of these activities is unknown. 53

62 Building and Infrastructure Improvements (Figure 20 Box ) All activities associated with efforts to upgrade the buildings, structures, roads, and support equipment; i.e. to provide bonding, grounding, lightning protection, heating, cooling, and special access. These activities remain to be accomplished Real Estate Acquisition and Management (Figure 20 Box ) Purchase or leasing of buildings, structures and grounds in which the operational systems or the people who support or operate systems are located. All activities associated with management of AAI owned or leased properties. The status of these activities is unknown Flight Inspections and SIAP Development (Figure 17 Box 5.12) All activities associated with flight inspections of the solution, and the development and revalidation of Standard Instrument Approach Procedures (SIAP) System Performance Assessment (Figure 17 Box 5.13) All activities associated with assessing equipment and system performance and trends, to include metrics development, data collection and trend analysis System Operations (Figure 17 Box 5.14) All non maintenance activities associated with directly operating or monitoring the solution. This includes computer operations, system administration, etc ATFMS Disposition (Figure 5 Box 6.0; Figure 21 Box 6.0) Disposition includes all activities required for the disposal management, dismantling/demolition/removal, restoration, and salvage of decommissioned equipment, systems or sites. This task and remains to be accomplished in the distant future but is included in this WBS for completeness but may never be executed for the ATFMS. The elements of this portion of the WBS are illustrated in Figure 21 The ATFMS Disposition Portion of the WBS Program Management (Figure 21 Box 6.1) 54