Military

Improving Our Ability To Fight (And Win) Theater Air Campaigns

 

CSC 1992

 

SUBJECT AREA - National Military Strategy

 

 

 

                                                EXECUTIVE SUMMARY

 

 

Title:  Improving Our Ability to Fight (and Win) Theater Air Campaigns

 

 

Author:  Major A. L. Mink II, United States Air Force

 

 

Thesis:  Although Desert Storm highlighted critical weaknesses in the Air Tasking Order

(ATO) process and the computer systems used to support the process, a new USAF

system, CTAPS, will overcome the limitations of the current system and promote

interservice cooperation.

 

 

Background:  The Desert Storm air campaign was generally viewed as a tremendous

success. The air campaign was fought using the USAF doctrine of centralized control

and decentralized execution. The link between centralized control and decentralized

execution was the Air Tasking Order. During Desert Storm, the ATO process suffered

from inadequate automation support. The centralized planning phase of the ATO process

benefited from only a handful of independent, "stovepipe" systems. The ATO

management phase relied on the Computer Assisted Force Management System, which

was underpowered, outdated, and unfamiliar to most of the coalition air forces. The

mission execution phase made use of several tactical planning systems -- but few of them

shared data or were capable of working together.

  

The USAF is developing a comprehensive system to support the ATO process:

the Contingency, Tactical Air Control System, Automated Planning System (CTAPS).

CTAPS will use standard commercial hardware and software. It will conform to DoD

joint standards. Furthermore, CTAPS will be interoperable with the newest C3I systems

under development by the USN, USA, and USMC.

 

 

Conclusion:  CTAPS provides new functions and integrates existing functions into one

unified system. By using standard, commercial hardware and software, CTAPS will be

affordable, upgradable, and dependable. By complying with DoD standards, CTAPS

will be interoperable with systems designed by the other services, providing joint support

for the ATO process. CTAPS will provide our military with the automation needed to

fight the next air campaign.

 

 

IMPROVING OUR ABILITY TO FIGHT (AND WIN) THEATER AIR CAMPAIGNS

 

                                                OUTLINE

 

Thesis:  Although Desert Storm highlighted critical weaknesses in the Air Tasking

Order (ATO) process and the computer systems used to support the process, a

new USAF system, CTAPS, will overcome the limitations of the current system and

promote interservice cooperation.

 

I.          The ATO process

            A.            USAF doctrine

            B.            Personal observations

 

II.            Centralized planning

            A.            Target nomination

            B.            EOB updates

            C.            Target selection

            D.            Support planning and air space control

 

III.       ATO management - CAFMS

            A.            CAFMS' poor design

            B.            CAFMS outdated hardware

 

IV.       Mission execution

            A.            Unfamiliarity with CAFMS

            B.            CAFMS' inadequate terminals

            C.            Lack of systems integration

 

V.            CTAPS

            A.            Standard hardware

            B.            Standard development software

            C.            Specific modules

                        1.            Centralized planning

                        2.            ATO management

                        3.            Mission execution

 

VI.            CTAPS in the joint arena

            A.            USN - Copernicus and NTCS-A

            B.            USA-STACC and MCS

            C.            USMC-ATACC

 

VII.            CTAPS - the solution

            A.            Supports the ATO process

            B.            Interoperable and joint

            C.            Links centralized control with decentralized execution

 

 

IMPROVING OUR ABILITY TO FIGHT (AND WIN) THEATER AIR CAMPAIGNS

 

       Combat actions in the Persian Gulf again demonstrated the growth of the role of air

       forces in war.  [Desert Storm] demonstrated the kind of combat might aviation

       possesses.

                           -V.P. Chigak Voyennaya Mysl' [Military Thought], USSR

 

 

       The successful Desert Storm air campaign bolstered the credibility of the USAF

approach to controlling combat forces. USAF doctrine directs that "aerospace forces

should be centrally controlled by an airman to achieve advantageous synergies, establish

effective priorities, and capitalize on unique strategy and operational flexibilities." (1:8)

During Desert Storm, the airman centrally controlling the aerospace forces was

Lieutenant General Charles A. Horner, the Joint Forces Air Component Commander

(JFACC). General Horner decentralized the execution of each mission to "achieve

effective spans of control, responsiveness, and tactical flexibility." (1:8) The critical link

between centralized control and decentralized execution during Desert Storm was the Air

Tasking Order (ATO). The JFACC Staff created a new ATO each day. It contained the

taskings for every mission to be flown the next day. It also provided each wing with

much of the information needed to fly the tasked missions. During Desert Storm,

inadequate computer support and communication links hindered the ATO process and

nearly undermined the combat capability of the coalition air forces. Fortunately, the

USAF has seriously studied its lessons learned and is about to field a new system for

theater battlefield management (TBM):  the Contingency, Tactical Air Control System,

Automated Planning System (CTAPS). CTAPS will solve most of the shortcomings of

the ATO process noted during Desert Storm. Furthermore, CTAPS will use commercial

and DoD standard hardware and software resulting in lower costs, future growth, and

interservice compatibility.

       During Desert Storm, the overall process of centralized planning, ATO

management, and mission execution became known as the "ATO process." The daily

ATO process spanned three phases and required hours to complete (figure 1).

 

 

Click here to view image

 

 

I observed this ATO process first hand. As a liaison officer assigned part-time to

CENTAF, I worked with the central planning teams managing the two air plans (the

defensive plan and the closely held offensive air campaign). As an officer with

education and experience with computer systems, I was tasked to connect a computer

terminal at our wing in Diego Garcia (BIOT) to the main ATO computer in Riyadh, SA.

As a strike planner and B-52 pilot, I planned and flew B-52 combat sorties. From this

experience, I learned that our air forces lacked adequate automation to support each

phase of the ATO process. The few systems that were employed to support the process

operated independently of each other and required unique, individual computer

equipment

       The first phase of the ATO process matched targets with strike aircraft and then

assigned support aircraft to create a strike package. This phase started during the early

morning, two days prior to the eventual strike. The first step in this phase was to develop

the list of possible targets. Each category of targets (e.g. bridges, C2, NBC, ground

forces, airfields) was tracked by an individual target officer dedicated to gathering all the

information relevant to the category of targets. (17) These officers were usually pilots,

not intelligence specialists. They worked with intelligence staff from CENTCOM,

CENTAF, and the other services components, as well as the staffs located in-the U.S. that

controlled national surveillance assets. Some of the targets, particularly the fixed-

location targets, were described in the U.S. target intelligence database and were

identified by a Basic Encyclopedia (BE) number. Unfortunately, the target officers did

not have direct access to the computerized BE database -- it was a stand alone system

owned by the intelligence shops. Some target officers resorted to simple computer

spreadsheets for managing their list. Most target officers just used a notebook and a

pencil.

       Because there was no centralized CENTAF target database, the target selection

process became dependent upon the target officers. The time these target officers spent

acquiring information from different sources could have been spent better on other tasks.

Clearly, the first step in the first phase of the ATO process could have benefited from

computer support.

       During the next step (and throughout the process), various agencies updated their

Enemy Order of Battle (EOB). Unfortunately, there was not one EOB, but eight

separate EOB databases. (8:1) For example, CENTCOM, CENTAF, and NAVCENT

each maintained a separate EOB -- the EOBs frequently portrayed conflicting enemy

capabilities. The CENTAF intelligence network system, Sentinel-Byte, emphasized the

location and capabilities of enemy defenses. Unfortunately, Sentinel-Byte was another

stand alone system, requiring its own unique computer and having only a limited ability

to share information with other planning systems.

       The third step in the CENTAF planning phase was target selection. This usually

occurred late in the afternoon, two days prior to the eventual strike. The Director of

Campaign Plans, Brigadier General Buster C. Glosson, selected a set of recommended

targets from the target nomination list. General Glosson then briefed this target set,

known as the "master attack plan," to the JFACC who, in turn, presented it to

CINCCENT at the nightly CINC's meeting. (18) General Glosson and his staff

accomplished this step without any automated support. Although this step required

subjective judgment it could have benefited from a smart "knowledge based" computer

system employing artificial-intelligence technology. At the very least this step could

have benefited from an automated capability to print the master attack plan onto daily

briefing slides. Had the master attack plan been stored on a computer, the final step in

the CENTAF planning phase, support planning, would have been easier, too.

       Around 2000 each night, the support mission planners received a copy of the

master attack plan. They were tasked with supporting the strike aircraft with support

missions. Support missions included air refueling sorties, suppression of enemy defenses

(SEAD) missions, and fighter escort missions. Some of the planners had special

computer systems for determining support requirements. For example, the tanker staff

used the Computer Mission and Route Planning System (CMARPS). CMARPS, like the

other support systems, was also a special purpose, independent computer. Another task

accomplished during this phase was airspace control. The airspace over Saudi Arabia

was covered with air refueling tracks, AWACS orbits, JSTARs orbits, fighter caps, and

missile engagement zones. The air space was crowded. Without a system to control the

airspace, coalition forces probably would have suffered losses from mid-air collisions.

Although the air space control system did a great job deconflicting airways and restricted

areas, it also required a unique computer and could not share information with other

CENTAF planning systems.

       At about 0400 the morning after CINC's approval of the master attack plan, the

CENTAF planners passed the entire day's missions, special instructions, and airspace

control orders to the "fraggers" at the ATO shop to begin the next phase of the ATO

process, ATO management. The ATO shop was manned by 100 fraggers. Each day the

fraggers would take the master attack plan and supporting information and type it into

the Computer Assisted Force Management System (CAFMS). One reason ATO

management was so labor intensive was that the ATO shop received their ATO

information on paper worksheets. None of the work from the CENTAF planning phase

could be transmitted electronically into CAFMS. The other reason this phase was labor

intensive was CAFMS itself.

       CAFMS was conceived in 1979 as a tool to improve the operational capabilities

of a USAF Tactical Air Control Center (TACC). (17:1) CAFMS was originally

designed to eliminate "the time-consuming manual postings of vast amounts of data

needed to plan and coordinate operations, [thus] improving the timeliness and efficiency

of combat theater operations." (17:1) During Desert Storm, CAFMS permitted fraggers

in the ATO shop to create a database containing the ATO, and then enabled any operator

to view the ATO on a computer screen or to print the ATO with a special printer.

       It should be no surprise that an ATO computer system designed in 1979 should

show deficiencies in the warfighting environment of the 1990s. Part of the problem

today stems from the poor process used to design CAFMS. In 1988, the Air Force Audit

Agency criticized Tactical Air Command (TAC designed CAFMS) for violating USAF

regulations governing the development of information systems. The "ad hoc"

development resulted in "cost overruns and inadequate testing." (17:3)

       In November 1990 I visited the CENTAF ATO shop and listened to the

frustrations voiced by the fraggers. The most common complaint was that the system

was slow and under powered. Even with all five CAFMS systems eventually

interconnected at CENTAF (there were only five CAFMS systems in the world),

operators had to wait 15 seconds between entries, which caused frustration and limited

efficiency. The screen layout for entering ATO information was cumbersome and

operators declared CAFMS "user hostile," indications of a poor man-machine interface.

       Another problem with CAFMS was that the old equipment was bulky, requiring

most of the capacity of a C-141 to airlift a single system. Furthermore, the five systems

employed during Desert Storm had to be located near each other because of the technical

limitations of their interconnections. Because of their combined bulk, the systems were

placed in the parking lot outside HQ CENTAF and within 100 yards of a public street. *

The entire CENTAF ATO system and TACC was vulnerable to an enemy agent with a

shoulder fired attack weapon.

 

 

* CAFMS was moved inside HQ CENTAF shortly before the start of the air campaign.

 

     Despite the limitations of CAFMS, the ATO shop usually managed to finish

typing and then validate the final ATO database around 1700. Unfortunately, the

problems with the ATO process did not end with the completed database. The wings and

the other services needed the ATO to accomplish their mission.

       The wings and the other remote agencies were referred to as Wing Operating

Centers (WOCs). The WOCs included the USMC Defensive Air Support Center, USN

carriers, air wings from other services, and the various USAF wings. The most striking

limitation of the ATO process, particularly during the early months of Desert Shield, was

the WOC's inability to obtain a copy of the ATO. Few WOCS had any previous

experience with CAFMS. (23:2)

       Only USAF fighter units had trained with CAFMS before Desert Shield. TAC,

the headquarters for USAF tactical air forces, managed the original design for CAFMS.

Bomber, tanker, and airlift units were never exposed to CAFMS or the ATO it produced.

Prior to the war, no one at our Desert Storm B-52 wing even knew CAFMS existed.

CAFMS was also new to other US services. Colonel Wages, the USAF Liaison Officer

to the Commander of USN forces during Desert Storm (NAVCENT), noted "NAVCENT

forces were unfamiliar with the ATO process and lacked the equipment and operating

procedures to integrate it [CAFMS] quickly or fully." (27:5) Because many Desert

Storm units were unfamiliar with CAFMS and could not understand the ATO, they

lacked the necessary CAFMS equipment and resisted the entire ATO.

       Even had the WOCs been familiar with CAFMS, it's unlikely they would all have

had the proper equipment. To access CAFMS, WOCs required a specially modified PC

that acted as a terminal. Besides being nonstandard, this terminal was very limited. For

example, a CAFMS operator at the WOC could only view 20 lines of the ATO on the

terminal screen. Because CAFMS was so slow (about one minute to access one screen of

data), an operator needed over 10 hours to view the entire 800 page ATO. (23:18)

Unfortunately, printing the ATO was no better. The WOC operator had to first view the

data on the screen before printing the data. This cumbersome process slowed the WOC

flight planning process and tied up personnel.

        Some WOCs could not use a CAFMS terminal had they owned one -- they lacked

a communication link between their unit and the main CAFMS computer at HQ

CENTAF. The most common communication link for WOCs in Saudi Arabia was the

country's telephone system. WOCs outside of Saudi Arabia, such as our unit at Diego

Garcia, relied on Super High Frequency (SHF) satellite links. Most units could also

receive the ATO over AUTODlN, but it usually required more than 10 hours for all the

parts of the ATO to arrive (using FLASH precedence). Some WOCs, particularly the

USN carriers, were unable to receive SHF communications. They lacked the proper

antennas and transceivers. As a result, they relied on a " manual 'pony express' ATO

delivery system [that] reduced mission preparation times for carrier aircrews, consumed

resources inefficiently [shuttle aircraft], and constituted a singularly weak link in that it

was subject to disruption by weather, aircraft problems, etc." (27:5)

       Another frustrating problem with the ATO automation at the WOC was the

proliferation of stand-alone systems. For example, our B-52 wing at Diego Garcia

became the test site for several independent strike planning systems. One system

received photographic-quality faxes from HQ SAC. Another system calculated flight

times and fuel consumption. Still another system calculated bomb run data. Several

systems (including Sentinel-Byte, the EOB system) monitored threats and calculated the

risks of different flight profiles. The problem grew worse as other agencies at the wing

(e.g., maintenance, logistics, and flight squadrons) fielded their own systems. Each

system tracked the aircraft tail numbers, weapon loads, and aircrew. With the exception

of two of the intelligence systems, none of the systems (including CAFMS) could

interact with each other or share information. They were not interoperable. Each system

required its own spare parts, manuals, and training programs.

       All three phases of the ATO cycle (centralized planning, ATO management, and

mission execution) suffered from inadequate and disjointed computer support.

Fortunately, the USAF is about to field a new system to help automate the ATO process,

CTAPS.

       CTAPS will be the standard TBM system for the USAF. A CTAPS system,

regardless of whether it's used for centralized planning, ATO management, or mission

execution, will consist of standardized hardware and integrated software. As a result of

Desert Storm, the USAF has made CTAPS its number one "must fix" C3I system. (21)

CTAPS design and acquisition are now directed by the TBM General Officer Steering

Group, composed of senior leaders from across the USAF. HQ TAC/DOY, the USAF

executive agent for CTAPS, expects 12AF to obtain an Initial Operating Capability using

CTAPS by the end of 1992. (11:15) This ambitious time table is possible because of

CTAPS's standard hardware, integrated software, and standard man-machine interface.

       One of the initial design objectives for CTAPS was the use of industry-standard

computer hardware. CTAPS will use a SPARC ll workstation. Not only is this system

powerful, it is standard across U.S. commercial industry. (13:57) Furthermore, many

vendors "clone" the SPARC ll just as many vendors have cloned the IBM PC.

       CTAPS will reap many benefits from standard hardware. First, CTAPS will not

be dependent on a single vendor. Alternate vendors eliminate the risk associated with

one vendor's inability to supply equipment quickly and in sufficient quantity. Multiple

vendors also increase competition and drive down costs. Another benefit of using

industry-standard computer hardware is that the USAF will be only one of many

customers. A large, diverse customer base allows vendors to amortize fixed costs over

more sales and therefore provides vendors incentives to improve the technology over

time. Another benefit of standard hardware is maintainability. Parts and supplies will be

available around the world and should continue to be available for many years. Looking

to the future, standard hardware permits the USAF to replace the SPARC ll with smaller,

more powerful systems without having to rewrite all the programs that will run on the

SPARC II. The power of the SPARC ll today enables it to do much more than CAFMS

yet be small enough to reduce the airlift and floor space required to deploy it.

       CTAPS hardware will support many software modules, each module capable of

supporting some step in the ATO process. Furthermore, these modules will be integrated

through the use of standard databases, and programming languages. Standard databases

will permit several different software modules to use the same data, eliminating the need

for operators to enter the same data several times. Standard development languages will

speed development and save money. One big savings results from the ability of

programs to be reused by several modules for several different tasks in the ATO cycle.

Paul Strassman, Director of Defense Information, U.S. Defense Department explains:

 

       My favorite [software] component, a very sophisticated and expensive

       program, is the software to allow a computer to determine the date [and

       time to perform a function]. [Each software program] has 45,000 lines of

       code [costing] roughly $100 for each line. Inside DoD we must have done

       this thousands and thousands of times. We have had contractors who sold

       us [the software program] over and over again for the last 30 years. Guess

       what? We are going to have two standard routines in DoD.

 

       CTAPS will also adhere to a standard man-machine interface. In other words, all

the modules will look about the same on the screen. (11:25) The different modules will

also react in a consistent fashion to operator inputs. As a result, CTAPS will be easier to

use and operators will master new modules faster. Furthermore, developers will not have

to devote as much time designing and programming the interface between the operator

and the module.

       Standardized hardware, software and man-machine interface will not help fight

the air war -- unless CTAPS also has modules designed specffically to support the ATO

process. Two of the most important used modules available to assist with the centralized

planning phase will be the Automated Planning System (APS) and the Airspace

Deconfliction Software (ADS). APS will fuse information about selected targets and

available aircraft to match targets with the best suited strike and support aircraft. ADS

enables an operator to "define, categorize, modify, and deconflict air spaces ensuring

their safe use within a tactical environment." (12:2)

       ATO management will be faster and easier because CTAPS will support an

improved version of CAFMS and a new TALK module. The improved version of

CAFMS will fix many of the shortcomings noted during Desert Storm. TALK will

enable operators throughout the ATO process "talk" with each other interactively by

typing on their CAFMS terminal. (12:5)

       Mission execution will benefit from the integration of several flight planning

modules such as Improved Many on Many (IMOM) and Tactical Decision Aids. (12:3)

IMOM enables mission planners to modify the EOB by adding, deleting, and moving

enemy and friendly radar sites recorded in the EOB database. It graphically displays

radar detection limits, antenna beam patterns, stand-off and sell-screening jamming

effects. TDA enables mission planners to select the best guided weapon based on target

characteristics, target background, and weather. TDA provides lock-on and acquisition

ranges as well as thermal contrast information.

       CTAPS will go a long way towards integrating the few existing USAF systems

now supporting the ATO process. CTAPS will also provide many new capabilities,

further improving the USAF capability to fight the air war. Yet, one of the biggest

lessons learned from Desert Storm was that no one service can fight alone. An USAF-

unique system that cannot communicate with systems from other services will not, in the

long run, serve our nation well. Fortunately, CTAPS was designed for compatibility

with the new systems under development by the other services (figure 2).

 

 

Click here to view image

 

 

     The USN is developing Copernicus, a sophisticated architecture that will allow

tactical commanders on land and sea to observe and control the battle. (5:1). Copernicus

is the brainchild of Vice Admiral Jerry O. Tuttle, the Navy's Director of Space and

Electronic Warfare. Admiral Tuttle has been an advocate for C3I systems with the same

design philosophy as CTAPS: standard hardware, standard software, and common man-

machine interface. Therefore, it's no surprise that Copernicus and CTAPS are very

compatible. Each service's system can run software modules built for the other service's

system. To coordinate their efforts, the USAF and USN formed the Air Tasking Order

Interoperability Working Group (AIWG). At their 12 March 92 meeting, the AIWG

developed plans to exchange software modules. (20:1) According to their minutes,

CTAPS can use modules from the ATO subsystem of Copernicus, the Navy Tactical

Command System-Afloat (NTCS-A). The USN, likewise, is interested in incorporating

the APS module from CTAPS into Copernicus.

       USAF/USN interoperability and cooperation is vital because the USN's forward

presence makes it likely that the USN may supply the JFACC, at least initially, during

future conflicts. The interoperability between CTAPS and Copernicus will benefit both

services when DoD adopts Copernicus as the umbrella C3I system for all of DoD.

According to a recent article in Defense News quoting Duane Andrews, Assistant

Secretary of Defense for C3I, DoD plans to expand Copernicus to include links all the

way up to the National Command Authority. (15:1)

       The USA is also developing a family of standard systems to integrate its

collection of existing independent systems. The USA theater level system is the

Standard Theater Army C2 System (STACCS). The USA plans to fund STACCS in FY

95. The USAF and USA are planning to link the two systems at the Air Support

Operations Center (ASOC).

       The USA C31 system planned for the Corps down to the Battalion is the

Maneuver Control System (MCS). Fortunately, MCS is compatible with CTAPS,

facilitating the development of common software modules for planning and coordinating

air support. To speed CTAPS-MCS integration, the USAF and USA are developing a

MSC-CTAPS interface. Major Whitehurst, CTAPS project officer at TAC/DOY, was

enthusiastic after returning from a joint USA/USAF Airspace Command and Control

Working Group, "The US Army is enthusiastic about integrating these two systems, and

their concurrence with MCS-CTAPS interface prior to STACCS fielding [underscores]

their support for this initiative." (29:2) By liking the two systems, both services will

benefit from better air support coordination. The two services plan to demonstrate this

interface by the summer of 1993.

       The USMC is developing the Advanced Tactical Air Command Central

(ATACC). ATACC is a mobile battlefield command center designed to plan and direct

coordinated air operations in support of USMC ground units or joint task forces. Each

ATACC center contains five work stations, two computers, and an array of

communication links. ATACC provides computer support for making and managing an

ATO. Unfortunately, the ATACC is not fully interoperable with CTAPS. (24) The

USMC surfaced this issue in January 1992 at the USN-USAF AIWG. Since then, the

USAF met with members of the ATACC Program Management Office to solve the

problem. Jointly, they determined that ATO information could be transferred through

AUTODIN. During a conflict, AUTODIN will only provide a limited capability to

exchange ATO information. Realizing this, both services are now exploring the

possibilities of establishing better methods to disseminate the ATO and track the status of

missions. The USMC expects to start full scale development of ATACC in 1994.

       During Desert Storm, the air forces were fortunate that the war was preceded by

five months of training, coordination and force buildup. These five months enabled the

coalition's air forces to master the ATO process and learn the system used to manage the

ATO, CAFMS. Furthermore, those five months enabled coalition forces to develop an

overwhelming air force. The overwhelming force mitigated the problems of inadequate

automation and the long 72 hour delay the ATO process required between target

nomination and mission execution.

       Fortunately, CTAPS will solve most of these shortcomings. With CTAPS,

centralized planning, ATO management, and mission execution can all be accomplished

better and faster. CTAPS interoperability with systems such as Copernicus, MCS, and

ATACC holds the promise of closer cooperation and more effective joint employment of

air power.

       "The essence of aerospace operational art is an air component commander

orchestrating the employment of air and space assets to maximize their contribution to

the campaign," states USAF doctrine. (1:10) CTAPS will provide the commander the

tools he needs to achieve this during the next major air campaign.

 

 

                                    BIBLIOGRAPHY

 

1.         Basic Aerospace Doctrine of the United States Air Force Draft. February

1991: 1-8.

 

2.         Cerney, Lt. Col. Ralph. Debrief after Joint USN/USAF Strike Planning

Conference.  November 90.

 

3.         Chigak, V.P. "First Lessons of War." Voyennoya Mysl' [Military Thought]

May 1991: 70.

 

4.         CINC PACAF/CC. "Theater Battle Management and C31 Interoperability."

Message.  31 December 1991.

 

5.            Copernicus Architecture Manual published by the USN Copernicus Project

Office.   August 91:1-G9.

 

6.            Endoso, Joyce. "Joint Chiefs Call for Open Systems in C4I Blueprint."

Defense News July 92: 3,65.

 

7.            Endoso, Joyce. "Navy's Copernicus Repaves the Information Highway."

DoD Computing January 91: 1-2.

 

8.            Grumman Data Systems. "Advanced Tactical Air Command Central."

System Description. November 91: 1.

 

9.         Holzer, Robert and Munro, Neil. "Navy Plans Maritime Air Doctrine Based

on Gulf Experience." Defense News 23 December 91: 8.

 

10.       Joint Staff/J6. "Air Tasking Order Interoperability." Message 13 November 91.

 

11.            Liepman, Capt. Skip. "CTAPS:  the Leading Edge of the USAF Theater Battle

Management Philosophy." Briefing. HQ Tactical Air Command (DOYY). February

92: 1-64.

 

12.            McLaughlin, Capt. Marie. "CTAPS Overview." USAF Background Paper. 14

August 91: 1-18.

 

13.            "Military Computers Directory." Defense Electronics February 92: 57.

 

14.       Mink, Major Allan. "4300 Provisional Bomb Wing - Lessons Learned."

Desert Storm After-Action Report 10 March 91: 1-28.

 

15.       Munro, Neil. "Pentagon Acts to Restore Order in C31 Network." Defense

News January 92: 1-4.

 

16.       Munro, Neil. "Pentagon Presses C31 Effort." Defense News October

91: 1, 82.

 

17.            "Review of the Computer Assisted Force Management System (CAFMS)."

Report of Audit Air Force Audit Agency. 10 April 88: 1-11.

 

18.       Rogers, Major Mark B. Desert Storm Targeting Cell Staff Officer. Interview

July 91.

 

19.            SAF/AQP. "Advanced Technology Battle Management System." Message

19 February 92.

 

20.            Stammler, Col. Richard. "NAVAF ATO Interoperability Working Group."

Minutes 14 January 92: 1-2.

 

21.            TAC/CC. "Theater Battle Management and C31 Interoperability." Message

13 December 91.

 

22.            "Tactical Theater C3I Information Exchange." Briefing MITRE Corporation,

Hanscom AFB.  24 Ju1y 91: 1-4.

 

23.       USA Center for Lessons Learned. Joint Tactical Communications Newsletter

January 92: 1,2,18.

 

24.            USAF/XO. "USAF Air Tasking Order Dissemination to the Army and Marine

Corps."  Message 27 February 92.

 

25.       USMC Combat Development Command. "ATACCS Operational Concept,

Draft 3901."  System Concept.  3 April 90: 1-B3.

 

26.            USN/CNO. "Air Tasking Order Interoperability."  Message 2 November 91.

 

27.       Wages, Col. Brian E. "End of Tour Report to Commander, US Naval Forces,

Central Command for Operations DESERT SHIELD/DESERT STORM."  5 March

91: 1-10.

 

28.       Walsh, Edward.  "Navy Communication Upgrades Geared to Improved

Interoperability."  Armed Forces Journal International December 91: 56-59.

 

29.            Whitehurst, Maj. Charles M. "Airspace Command and Control Working

Group."  Trip Report.  28 February 92: 1-2.

 

30.            Whitehurst, Maj. Charles M. "USAF/USN ATO Interface."  Briefing. HQ

Tactical Air Command (DOYY).  March 92: 1-28.

 

31.            7AF/CS. "Installation of Modular Tactical Air Control Center (MTACC) in

7AF Hardened TACC (HTACC)." Message. 9 December 91.