1. 2. 3. 8. C V.

All View-1 Overview and Summary Information..49 OV-1 High Level Concept Description..50 OV-2 Operational Node Connectivity...51 OV-3 Operational Information Exchange Matrix.56 OV-4 Organizational Relationships..58 OV-5 Operational Activity Model..63 SV-1 System Interface Description...66 SV-2 Systems and Services Communications Description and SV-6 Systems Services Data Exchange Matrix.67 CONCLUSIONS: POSSIBLE IMPACT OF DODAF ON THE PACIFIC TRACKER PROGRAM..69
SOME IMPLICATIONS FOR OTHER MDA TEST ASSET DEVELOPMENT PROJECTS...73
LIST OF REFERENCES....75 INITIAL DISTRIBUTION LIST....77

LIST OF FIGURES

Figure 1. The S.S. Beaver State as it is being towed from Suisun Bay Reserve Fleet in Benicia, CA to be temporarily berthed at Alameda, CA. (T. Amundsen, personal communication, 4 April 2008)..2 The MV Pacific Collector. The twin 7m dishes of the Transportable Telemetry System are seen in the aft section of the ship (T-AGS-29, n.d.).10 USAV Worthy....11 Observation Island: The S-Band phased array is seen on the aft deck, and the X-Band radar is seen atop the house, aft of the smokestack (USNS Observation Island, 2001)...12 Sea-Based X-Band Radar: The X-Band radar is under the large center dome (SBX, 2007)...13 Organization of the Pacific Tracker and major sensors projects..18 Schedule for the project presented at ASP by DTR...23 MARADs power option 1...26 Power option 2....27 SRR power option 3....28 TTS antenna configuration with 37 ft high radomes mounted on the main deck....31 TTS antenna and deck configuration for option 2..32 Option 3 with 42 ft tall radomes and antennas mounted on hatch coamings.32 One line diagram of the power generation and distribution system presented at the CDR....36 Interrelationships among DoDAF views..42 DoDAF Products....46 Architecture Products and their Applicability..47 Pacific Tracker Overview and Summary Information..50 Pacific Tracker High Level Concept Description..51 OV-2 Operational Node Connectivity Description..53 OV-2 Operational Node Connectivity Description Test Event Data..55 OV-2 Operational Node Connectivity Description Test Event Voice.56 OV-3 Operational Information Exchange Matrix with Test Event Data.57 OV-3 Operational Information Exchange Matrix with Test Event Voice.58 OV-4 Organizational Relationships August 2007..60 OV-4 Organizational Relationships January 2009..61 OV-4 Organizational Relationships, Possible End State Pacific Tracker.62 OV-4 Organizational Relationships, Possible End State Pacific Tracker (Flight Test Operations)...63 OV-5 Operational Activity Model..65 OV-5 Operational Activity during test execution..66 SV-1 System Interface Description...67 SV-2 Systems and Services Communications Description..68 SV-6 Services Exchange Matrix...69 ix

Figure 1.

The S.S. Beaver State as it is being towed from Suisun Bay Reserve Fleet in Benicia, CA to be temporarily berthed at Alameda, CA. (T. Amundsen, personal communication, 4 April 2008)
S.S. Beaver State is a former cargo ship that was converted to a crane ship. The purpose of a crane ship is to unload or load other ships at ports with inadequate facilities. This sort of ship may be used to help put ashore a surge of materiel to support sustained combat operations. When Beaver State was converted to a crane ship, three large cranes were installed. To power the cranes, two 1200 kW diesel generators were also added. This size and number of generators are needed to reliably provide electrical power to the radar. The size of the ship and generators make Beaver State suitable to host the XTR-1 and TTS-2 systems and become Pacific Tracker. In the course of converting Beaver State into Pacific Tracker, the large cranes will be removed and other modifications to the ship will be necessary to host the XTR-1 and the TTS-2. There are five major efforts in the conversion process: 1. 2. Ship reactivation; Modification of the ship to host the primary sensors, the adjunct systems, and the respective operators; 3. 4. Installation and integration of the primary sensors and adjunct systems; Development, installation, and accreditation of the communications system; and 5. Coast Guard certification.
The major engineering efforts in the conversion process that are considered in this thesis are: 1) The design of the modification for the ship to host the radar, telemetry, adjunct systems, and the respective operators; and 2) the design of the communications system. This thesis will review the history of these two aspects of this conversion process, review DoDAF 1.5, assess the applicability of DoDAF 1.5 to the Beaver State conversion process, and suggest opportunities for improvement of similar MDA test asset development programs.
PURPOSE The purpose of this thesis is to: 1) Describe the conversion of SS Beaver State
into SS Pacific Tracker, a project that did not incorporate DoDAF methodology; 2) Assess whether incorporating DoDAF would have improved the way the project was done; and 3) Provide recommendations on incorporating DoDAF into other MDA test asset development projects. C. RESEARCH QUESTIONS The following questions will be addressed in this thesis: 1. 2. 3. 4. How was the Beaver State conversion project conducted? What is DoDAF? What DoDAF products might have been produced to support the project? How may have the DoDAF methodology changed the way the project was done? 5. Would the DoDAF methodology have been useful to the project or be useful in future MDA test asset development projects? D. BENEFITS OF STUDY This thesis will document practical lessons derived from the Beaver State conversion. Recommendations will be provided on the application of the derived lessons to other MDA one of a kind, or few of a kind, test asset development. E. SCOPE AND METHODOLOGY 1. Scope

The mission of the Sea-Based Platform Product Office (SBP) is to maintain, operate, and develop sea-based platforms to support MDA flight test activities. The SBP was initially formed in July 2007. The first two platforms in SBPs portfolio were the telemetry collection ship Pacific Collector and the Mobile Launch Platform (MLP). The MLP is the ex-USS Tripoli, a former Iwo Jima class amphibious assault ship. The primary function of the MLP is to serve as a launch platform for target missiles, similar to Scuds, for BMDS testing. The MLP is operated as a live-aboard barge and is towed by the former fleet tug, Narragansett. With the completion of the 24 August 2007
Acquisition Strategy Panel (ASP), DTR assigned the development effort, Pacific Tracker, to the SBP. Responsibility for the ship passed from the Radar Product Branch to the SBP. The initial tasking of the SBP was to finalize ship selection and convert the selected ship to accommodate the XTR-1 radar. Once Beaver State was selected, the SBP had to complete five major efforts to convert Beaver State to Pacific Tracker. The five major efforts in the conversion process are: 1) Ship reactivation; 2) Modification of the ship to host the primary sensors, the adjunct systems, and the respective operators; 3) 15
Installation and integration of the primary sensors and adjunct systems; 4) Development, installation, and certification of the communications system; and 5) Coast Guard certification. This thesis is primarily centered on the utility of DoDAF for the ship modifications necessary to host the radar and the development of the communications system. The five major efforts are described in more detail below. 1. Ship reactivation: Covers all actions to return the ship to sea-worthy
condition. Based upon the ASP decision, the ships considered for conversions were all U.S. government-owned and mothballed in the inactive fleet. Mothballed is used here to describe measures taken to protect the ship and equipment from corrosion or deterioration. At a minimum, the preservation measures needed to be removed and the equipment returned to operating condition. Repairs would be needed to address
deficiencies in the ships condition at the time of the mothballing and to address deficiencies resulting from deterioration that occurred while mothballed. Part of the ship selection process took into account the overall condition of the ships. 2. Modification of the ship to host the primary sensors, the adjunct systems, The ship selected for conversion would require
and the respective operators:

however, that was only the coarsest form of control. The PTPM provided funding directly to three organizations: Johns Hopkins University/Applied Physics Laboratory 17
(JHU/APL), NSWC Corona Division, and MARAD HQ. The bulk of the funding, roughly 97%, went to MARAD. MARAD and NSWC received funds via Military Interdepartmental Purchase Request (MIPR). MDA had a contract with JHU/APL, and the PTPM was the task manager for that contract.

Figure 6.

Organization of the Pacific Tracker and major sensors projects.
The PTPM assigned JHU/APL to provide detailed engineering analysis, as needed, and to provide systems engineering to support to the Pacific Tracker development efforts. The Radar Development Branch selected NSWC Corona to develop the communications system for the XTR-1 mission equipment. Corona was experienced with integrating SATCOM with MDA test assets. Corona had developed the SATCOM system linking TTS-1 and TTS-2 and successfully revamped the SATCOM on the MLP to name two projects. MARAD was assigned to make recommendations for the ship selection; to re-activate the ship; to modify the ship; and to gain CG certification. 3. Acquisition Approach
MDA considered several approaches for acquiring a ship to become Pacific Tracker. Among the approaches considered were a new acquisitiondesigning and 18
building a new special purpose ship; drawing a ship from the U.S. Inactive Reserve Fleet (which is also sometimes referred to as the MARAD option); or a lease arrangement with a ship owner/operator. MDA/DTR considered designing and building a special purpose ship and quickly deemed the expected costs to be too high based upon a recent Navy contract award. The Navy had recently selected the design and build new approach for its Cobra Judy replacement program. In 2006, the Navy made a $199M contract award for the design and construction (VT Halter, 2006) of a new ship based upon the existing T-AGS 39 design. The $199M price tag for the Cobra Judy replacement far exceeded MDAs budget for Pacific Tracker. MDA considered two options in more detail: 1) drawing a ship from the U.S. Inactive Reserve Fleet and 2) a lease arrangement with a ship owner and operator. The acquisition of Pacific Collector followed the approach of drawing a ship from the U.S. Inactive Reserve Fleet. Given the success of Pacific Collector, MDA embarked on the same approach with Pacific Tracker. While MARAD was conducting the initial assessment of available ships in the inactive reserve fleet for MDA, Edison Chouest (an offshore vessel services company) approached MDA with the Lease option. Edison Chouest proposed to modify one of their vessels to support XTR requirements and then operate the ship for MDA under a ten-year lease. Once MARAD had completed the initial assessment, MDA performed a business case analysis of the three options in the summer of 2007. The results are shown in Table 5. The Director, Test Resources presented these results to MDAs Acquisition Strategy Panel (ASP) on 24 August 2007.

At the time of the ASP briefing, the technical approach had four major steps. The first step was for the XTR-1 developer, Massachusetts Institute of Technology Lincoln Laboratory, to produce an interface control document (ICD). MIT Lincoln Laboratory is a federally funded research and development center chartered to apply advanced technology to problems of national security (MIT/LL, n.d.). The second step was for naval architects, under contract to MARAD, to develop a design in accordance with the XTR-1 ICD. The third step was for a shipyard to make the modifications to the ship. The fourth step was for the XTR to be integrated on the ship, once the shipyard work was completed. As the program progressed, TTS-2 and the communications system were added to the effort. The steps for TTS and the communications system followed a path of requirements definition, design, modification, and installation similar to XTR-1. The first step of developing the ICD was expected to be straight forward for the developer. The XTR-1 was in a relatively advanced stage of development and it already was being fabricated. The XTR-1 ICD was expected to describe the interfaces between the radar and the ship as well as identify other requirements for space, electrical power, and cooling for the radar. Likewise, the second step was expected to be straight forward for the naval architects to produce a design to host the radar. It was envisioned that the naval
architects would quickly produce a detailed design. There were three major components of the design: the electrical system, structural modifications, and machinery (predominantly a chilled water system to cool the radar). It was understood that the electrical system would have to be modified to allow the radar to draw power from either diesel generator. Structural modifications that included building out rooms such as office spaces and control and computer rooms were expected to be relatively simple. While a larger effort, even the structural modifications foundation for the XTR antenna was considered to be straight forward. It was thought the design of chilled water cooling system was largely a matter of selecting the correctly sized commercial system. Once the modification design was complete, the third step was to compete the modification work among interested shipyards and have the winning shipyard perform the modifications. The modifications would be coupled with dry-dock work in the 21
competitive package. The dry-dock work would be routine items necessary to activate the ship and meet regulatory requirements. After the shipyard completed the

modifications and work in the dry-dock, the fourth step would be to install the XTR-1 on Pacific Tracker. 5. Schedule and Milestones
The initial schedule that was shown during the ASP briefing is shown in Figure 7. Figure 7 shows Pacific Tracker milestones in relation to upcoming FTGs. FTG is the designation for flight tests of the Ground-based Midcourse Defense (GMD) system. FTG scenarios include the Vandenberg to Kwajalein trajectories. The first milestone is the authority to proceed with ship acquisition. The date coincides with the ASP presentation on 24 August 2007. At that time, the XTR-1 schedule showed that the radar would be ready to install on the ship towards the end of FY 2008. The detail design work prior to entering into the shipyard was scheduled to begin September 2007 and run approximately six months to the end of February 2008. This allowed only six months for MIT/LL to produce an ICD and for MARAD to produce the detailed design to modify the ship to allow it to accept the XTR. The next six months were allotted to shipyard modifications of the vessel. Then another six months were allotted for the installation of the radar on the ship. After another month of sea trials, Pacific Tracker would be ready to support FTG-08.

Figure 7.

Schedule for the project presented at ASP by DTR

Design Evolution History

The design requirements for Pacific Tracker, and hence the corresponding design concepts, underwent significant changes as the project proceeded. A few significant milestones in the program are used to capture the then current design requirements and design concepts at those particular junctures. The first milestone will be the ASP
meeting. Subsequent milestones will be SRR, CDR, and contract award. Between milestones, the design made significant changes due to requirement changes, improved understanding of requirements, and cost constraints. a. Acquisition Strategy Panel
At the time of the ASP, MIT/LL had yet to develop its ICD. There was sufficient understanding of the requirements for electrical power and physical size to select a ship. However, those requirements were not sufficiently understood for the naval architects to begin a detailed modification design. Several months after the ASP, two additional major requirements were added to the program. First was the addition of TTS23

generators operate in parallel; 2) Add a third diesel generator; and 3) Add an uninterruptable power supply (UPS) sufficient to power all of the mission equipment for 30 minutes of operations. Option 1, as shown in Figure 8, has the following features: 1) Lowest cost of the options considered; 2) If one steam turbine generator or one diesel generator fails (after missile launch), the UPS units will provide continuity of mission equipment power for 30 minutes; and 3) Failure of either a diesel generator or diesel generator switchboard 25
will not interrupt power to S and X-Band High Voltage Power Supplies (HVPS) and XTR Antenna Servo Motors. The major disadvantage is that it did not meet
managements desire to have all the mission equipment backed up by a UPS.

Figure 8.

MARADs power option 1
Option 2, as shown in Figure 9, has the following features: 1) Failure of any diesel generator or diesel generator switchboard will not interrupt mission power. The remaining diesel generator can maintain mission power without having to rely on UPS units; 2) The mission power system is completely isolated from the ships power system. Disruptions in the ships power system will not affect mission operations; and 3) According to MARAD, a 1640 kW diesel generator was currently available from another MARAD activity. The disadvantages of this option are: 1) It is the most expensive of all the options; 2) It requires new auxiliary machinery room and associated support systems for the diesel generator installation and a new diesel generator switchboard; and 3) Additional engine room watch personnel would be required.

Figure 9.

Power option 2
Option 3, as seen in Figure 10, has the following features: 1) Failure of any (or both) diesel generator will not interrupt mission power for a minimum of 90 minutes, and 2) The mission power system is completely isolated from the ships power system. Disruptions in the ships power system will not affect mission operations. The disadvantages of option 3 are: 1) It requires installing a new diesel generator switchboard and Mission Switchboard, and four 400 kVA UPS units; and 2) Different voltages of the ships service power system, 450 V, and Mission power systems, 480 V, prevent the capability to parallel systems. Significant modifications are necessary to permit
paralleling to the ships service switchboard and SSTG governors; and 3) The UPS battery life expectancy will likely cause new batteries to be purchased every few years. DT management considered the power options and projected costs. After some additional discussion, DT management decided to relax the requirement for 100% UPS backup for all mission equipment. When the requirement was changed from 100% 27
UPS backup to 100% backup, option 1 became viable. This option uses one of the diesel generators as the primary power source and the other diesel generator as the back up power source for the radar transmitters. Additionally, option 1 uses UPS as the back up power source for the other mission equipment. DT management directed the program to proceed with refining option 1.

At the CDR, it was clear that the expected loads for the other mission equipment were too large for the SSTGs to supply when the radar was operating. The SSTGs could supply sufficient power to the other mission equipment when the radar was not in operation. By operating, it is meant that generating RF energy would either be transmitted or converted into heat in devices known as dummy loads. The cooling necessary while the radar is operating is too much for the SSTGs along with the other mission equipment. When the radar is in operation, both SSDGs are necessary for power. One SSDG is required to power the radar and one SSDG is required to power the other mission equipment. Now, when the power system is configured for radar operation, if the SSDG powering the radar fails, the other SSDG must shed the other mission equipment load and switch to power the radar. The other mission equipment has to rely on the UPS for power. In a similar fashion, when the power system is configured for radar operation and if the SSDG powering the other mission equipment were to fail, the other mission equipment has to rely on the UPS for power. In this case, the other SSDG would continue to power the radar. 37
Two other significant changes were made to the power system design. The size of the UPSs were increased and the utility power for the TTS shelters was moved off the Mission Support UPS and over to the SSTGs. The two 400 kVA UPSs in the SRR concept had to be increased to 750 kVA each. The maximum load on the clean power UPS was expected to be 336 kVA while the maximum load on the mission support UPS had grown to 745 k VA. The predicted load on the clean power UPS did not increase much from the SRR. The predicted load on the mission support UPS had a significant increase. In particular, the chilled water and HVAC were the biggest factors which drove the power requirements. Both UPSs did not have to increase to the 750 kVA size. The clean UPS could have easily stayed at 400 kVA. However, the decision was made to keep the UPSs identical with the expectation of reducing the cost of critical spares that must be kept onboard the ship. One may note the total load is not evenly spread over the two UPSs. The load is not more evenly split because of the type of loads. The compressors and other equipment on the Mission Support UPS are considered to be fairly noisy. And, that equipment does not require clean power as the mission electronics will. The Mission Electronics UPS provides power conditioning for the equipment attached behind it from equipment attached on the front side. It protects the Mission Electronics from noisy loads such as the radars high power voltage power supplies and compressors. This is why the TTS utility power was not shifted over to the Mission Electronics UPS even though there is more than enough margin left on the Mission Electronics UPS to accommodate the TTS utility power. The TTS utility power was shifted off the Mission Support UPS because the predicted load on that UPS had grown so large. The load on the Mission Support UPS provided motivation to move the TTS utility power off that UPS and because the noisy equipment described as TTS Utility could produce problems for the equipment powered by the other UPS. Thus, the decision was made to instead shift the load in question to the SSTGs. This decision avoided the need to go to an even larger or third, smaller UPS. The decision also, however, made the mission equipment more dependent on the SSTGs. Table 8 indicates that both SSTGs are needed to fully supply utility power for 38

increases with the systems complexity. The DoD can ill afford the cost of inefficiencies
produced by extraneous or poorly integrated components. To help ensure interoperable and cost effective military systems, the DoD has established DoDAF to describe DoD system architectures. The DoDAF is an evolution of the 1997 Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture Framework. The DoDAFs purpose is to provide guidance for describing warfighting operations and business operations and processes, not just C4SIR systems. The DoDAF does not provide guidance on how to construct or implement a specific architecture or how to develop and acquire systems. The framework provides rules, guidance, and product descriptions for developing and presenting architecture descriptions. The
principal objective of the framework is to make sure architecture descriptions of DoD systems can be related and compared throughout DoD, across service and even multinational boundaries. Common principles, assumptions, and terminology address this objective. The DoDAF specifies three views that combine to describe the architecture. The three are Operational View (OV), Systems View (SV), and Technical Standards View (TV). Figure 15 (DoDAF Version 1) illustrates the relationships between the three views.

Figure 15.

Interrelationships among DoDAF views 42
OPERATIONAL VIEW The OV is a description of the mission, warfighting, and other entities that need to
be supported by the system. It describes what is going on with the system in the field. The OV contains textual and graphical products that identify the elements, assigned operations, and information flow between elements. This view reveals requirements for capabilities and interoperability. OV descriptions are useful for DoD wide assessments to examine business processes, technology insertion, or doctrinal and policy implications, to name a few. Usually the OV of a system is doctrine-driven. However, outside forces can cause a system or organization to operate in a manner inconsistent with doctrine. In these cases, the OV can be very useful to determine if doctrine changes are in order or if the root cause is some other factor such as lack of supporting infrastructure or information. Ideally, an OV is independent of materiel. However, new technologies may influence or push elements, assigned operations, and information flow between elements. For this reason, some high-level SV products or data elements may be needed to support information in the OV products. C. SYSTEMS VIEW The SV describes the existing and future systems and physical interconnections that support the mission documented in the OV. As used in DoDAF, a system is defined as any organized assembly of resources and procedures united and regulated by interaction or interdependence to accomplish a set of specific functions (DoDAF Version 1.0). The SV is used to address specific systems. This can include current, developing, or conceptual technologies, depending on the purpose for developing the architecture. The level of detail in the SV will depend on the purpose for developing the architecture. Architectures are developed for a variety of reasons. DoDAF users may develop Systems Views to describe the systems current state, to assist in transitioning to a new state, or to analyze future options.

PTL SAD

Situational awareness

TTS to PTL SAD
TTS antenna position, TM data

TTS operation

XTR-1 to Range

Radar display datat

TTS to Range

Processed TM data

TTS operation and data processing

Figure 23.

OV-3 Operational Information Exchange Matrix with Test Event Data

Test Event Voice

Need Line Information Exchange Sending Node Sending Activity
Collect and disseminate Tracker (XTR-1, TTS, ship, and comm status)
Collect and disseminate participant status

PTL to RO

Tracker Status
Voice, external range net

RO to PTL

Range Count

Conduct Countdown

Execute mission plan or make Voice, external adjustment range net accordingly

PTL to Ship's Master

Request Heading, Speed, Power Transfer, Status, Radiate Acknowledge Heading, Speed, Power Transfer. SOLAS information Changes to Heading, Speed, Power
Execute mission plann or make adjustment Adjust heading and speed, coordinate power transfer, stauts and SOLAS Disseminate changes to heading speed, power

Ship's Master

Approve and implement or disapprove and explain

Voice, internal phone

Ship's Master to PTL

Inform TTSL & XRTL

PTL to XTRL

Respond accordingly

Voice, internal net

XTRL to PTL

Request Heading, Speed, Power Transfer
Execute mission plann or make adjustment
Decide to relay to ship's master or not

PTL to TTSL

Changes to Heading, Speed, Power
Disseminate changes to heading speed, power

TTSL to PTL

Request Heading, Speed

Figure 24.

OV-3 Operational Information Exchange Matrix with Test Event Voice
OV-4 Organizational Relationships
If DoDAF had been used, it is likely that the current and end state organizational relationships would have been considered. The organizational relations evolved over the course of the program. To keep the architecture description current, OV-4 may have been updated from time to time. Here, OV-4 is produced relative to two junctures in the program: the ASP and the shipyard contract award. Figure 25 shows the organizational relationships at the time of the ASP. Figure 26 shows the relationships at the time of the contract award. OV-4 descriptions are also produced for possible end state

configurations. Figure 27 reflects possible overall program relationships, and Figure 28 shows possible relationships during flight test operations on the ship.
Figure 25 shows the relationships between the three branches, also called product offices, within the Test Resource Infrastructure Division (DTRI) involved with the Pacific Tracker program, Flight Safety and Telemetry, Sea-Based Platforms, and the Radar Development Branches. At the time of the ASP, the TM and Flight Safety branch had already developed TTS-1 & 2. This branch also oversaw the TTS-1 operations on the Pacific Collector and TTS-2 operations on land. The TTS was developed and
operated by a group from WSMR. WSMR had selected NSWC-Corona to develop and operate its SATCOM system. The SBP Branch was charged with the responsibility to select and modify a ship to meet XTR-1 requirements. MARAD was the executing agent for SBS. MARAD Western Region, at the direction of MARAD HQ, engaged a firm, ICI and its sub contractor MDO, to perform the naval architecting. MIT/LL was still in the process of developing the XTR-1 for the RD Branch. The RD arranged for the targets group from NAVAIR, Naval Air Station, Pawtuxet River to be the EA for the radar operation through its contractor Computer Sciences Corporation (CSC). It was planned for CSC to provide the permanent crew for the XTR-1. The RD branch also went to NSWC Corona group to develop and operate the STACOM system. At the time of the ASP, the three branches were organizationally on the same hierarchical level; however, SBP was tasked to accommodate RD/XTR-1 requirements and soon after the ASP, TM&Safety/TTS requirements were added to the tasking.
OV-4 Organizational Relationships Development (ASP Aug 2007)

Figure 25.

OV-4 Organizational Relationships August 2007
By the time of the shipyard contract award, the hierarchy among the DTRI branches had changed. Figure 26 reflects the organization at the time of the shipyard contract award. Most of the organizations were still involved; however, there were several significant changes. The TM/Safety Office was brought within SBP so that the vessels and on board instrumentation would have common management within DTRI. SBP also took over responsibility for the communications system and brought the Corona group within the SBP purview. MARAD was able to reduce one contract by moving the Naval Architects subcontract under IAS. By the time the contract was awarded, SBP was also assigned the lead systems engineering role for the Pacific Tracker program, a significantly different role than modifying a ship to meet XTR-1 requirements.

OV-4 Organizational Relationships Development (Shipyard contract award Jan 2007)

Figure 26.

OV-4 Organizational Relationships January 2009
Once XTR-1 development is completed, current plans call for responsibility for XTR-1 to be brought within SBP, just as the TM/Safety Office was brought within SBP so that the vessels and on board instrumentation would have common management within DTRI. As shown in Figure 27, a possible end state is for the SBP office to be relative to only the Pacific Tracker program. Organizational relationships are not shown for the other systems: Pacific Collector, KMRSS/Worthy, and the MLP, within SBP. Figure 27 also shows how SBP will have to interface directly with at least five different organizations in order to manage the Pacific Tracker program.
OV-4 Organizational Relationships Possible End State Pacific Tracker

Figure 27.

OV-4 Organizational Relationships, Possible End State Pacific Tracker
As part of the management of the Pacific Tracker program, the organization relationships onboard Pacific Tracker when at sea also needs to be considered. Figure 28 shows a possible configuration for the system at sea. While MARAD and NAVAIR will not disappear while Pacific Tracker is at sea, their roles will become more indirect, very much like SBP. It is not that the structure shown in Figure 27 goes away. It is that only a subset of the actors relative to the overall program goes to sea. The PTL will have more direct contact with the Range than she will have with the SBP. The thought behind Figure 28 is that the PTL will be responsible for top level direction and coordination of the XTRL, TTSL, communications, and the ship. To this end, the PTL is in the
leadership position over the Pacific Tracker system and people deployed for the flight test. The ships master is shown in a subordinate role to the PTL in relation to flight test support. The intent is to reflect the overall mission of flight test support. The master has supremacy in matters related to Safety of Life at Sea (SOLAS) and the safety of Pacific Tracker. 62
OV-4 Organizational Relationships Possible End State Pacific Tracker (Flight Test Operations)

Figure 28.

OV-4 Organizational Relationships, Possible End State Pacific Tracker (Flight Test Operations)
OV-5 Operational Activity Model
The next view is OV-5, Operational Activity Model. The model shown in Figure 29 closely matches the example in Maj Hartts DoDAF executive seminar presentation (n.d.). In his example, Maj Hartt was using an aerospace operations center (AOC) as an example. On first consideration, a missile range instrumentation ship does not resemble an AOC in form or function. However, in terms of the process, there is much overlap. Both the AOC and test assets can go through a planning execution - maintenance cycle. The first step is to obtain information necessary for planning. Two general types of information entering the program are shown at the top left: Requirements and Test Event Information. 63

INITIAL DISTRIBUTION LIST
1. Defense Technical Information Center Ft. Belvoir, VA Dudley Knox Library Naval Postgraduate School Monterey, CA Steven Lopes Missile Defense Agency Arlington, VA Ivn Romero U.S. Army Space and Missile Defense Command Huntsville, AL Loran Wingfield Missile Defense Agency Huntsville, AL