Patriot Missile Crises
By Benji Boban
Abstract
During the Persian Gulf War conflict (August 2, 1991 to February 28, 1991) the Patriot Missile Defense system was deployed to provide the US Army and the Israeli defense with a shield from, among other things, the ballistic missiles used by Iraqi forces. The success of this system is a highly debated subject, however one major failure of this system was realized when 28 American soldiers were killed on February 25, 1991 as the system failed to detect the incoming Scud missile. This paper analyzes the issues of the Patriot missile system as deployed in the Gulf conflict and tries to provide an explanation of the adopted resolution while also evaluating the failures in the requirements of this particular deployment. In order to better understand the problem, we will gain an understanding of the particular system, research the various papers detailing the problem, specifically with reports from oversight committees to congress as well as the scholarly essays on the subject, and conclude with a look at the eventual resolution of the problem and compare them with other possibilities of resolution.
Introduction
During the Persian Gulf War, also called Operation Desert Storm, a Patriot Missile System failed to intercept an incoming Scud missile and an army barracks in Dhahran, Saudi Arabia was hit. 28 American soldiers were killed. The purpose of this document is to explain the system, discuss the failure, understand the reason for failure, and discuss the solution implemented.
The Patriot Missile system is a Surface to Air Missile system. Its main purpose is to detect, track and destroy enemy airplanes and missiles. It primarily is created to operate on the battlefield and thus has many unique requirements. Raytheon was the primary contractor on this system and worked with the Patriot Project Office and the Army to create this system. As it was produced in 1976, and warfare has changed between 1976 and 1991, there have been changes in requirements.
The disaster which occurred on Dhahran was not the result of one major problem. In fact the root cause in many pieces of literature point to a software issue. However, there were many other problems with this system of systems, as evidenced in the report to congress and other sources. The failure however, was corrected via software, which in essence was the beauty of the Patriot Missile System. It is a hardware system whose functionality can be affected primarily by software.
The question then becomes what was the cause of failure? Was it the domain shift, or the requirements creep, or a change in the software model of the system? Inherent in answering these questions, is a brief look into the domain of the Patriot Missile System, the requirements for the system, and the software world of the system. However, it is difficult to take a complete look into the requirements and software world as it restricted information. Looking at these three components we can understand the “As-is” nature of the original Patriot Missile System versus the “To- Be” nature required in the Persian Gulf War, as well as propose the correct “To-Be” nature differences from the deployed system. This will involve a look into the solution used in order to better understand the interaction of the enterprises involved in the system, as well as a comparison of the deployment of the Patriot Missile system in the Persian Gulf War to a typical systems lifecycle and any extrapolations which can be derived from it.
In conclusion we need to take both the good and the bad lessons learned from this disaster at a requirements/systems level and understand how to apply them to future requirement engineering practices. It is my belief that a better appreciation for the domain of a system, a better feedback loop for any requirements creep, as well as the implementation and adherence to a requirements lifecycle can provide the military and its contractors as well as any other systems developers with less of a chance at a catastrophe as the disaster in Dhahran.
There are many related works to this paper, but the primary version is the “Report to the Chairmn, Subcommitte on Investigations and Oversight, Committee on Science, Space and, Technology, House of Representatives – Patriot Missile Defense, Software Problem led to System failure at Dhahran, Saudi Arabia.” Due to the military application of this Patriot Missile System, certain documents, such as user manuals, requirements documentation, etc, were difficult to obtain. However, there is plenty of information regarding the system itself in news articles as well Raytheon’s website.
1 As-Is
1.1 The Patriot Missile System of Systems
The Patriot Missile System was first produced in 1976 as a Surface to air missile system. It has been in service from 1981 onwards and has been involved in various conflicts around the world. The system is truly a system of systems. It consists of 4 major systems with the functions of Communications, Command and Control, Radar Surveillance and Missile guidance. During its initial use, its major functionality was as an anti-aircraft system. However, shortly before the Persian Gulf War the system was modified to include anti-ballistic tactile abilities. The name of the system comes from its first component, the radar surveillance unit AN/MPQ-53 (the 65 was developed for the PAC-3 missiles, which was developed after the Persian Gulf War). The AN/MPQ is the “Phased Array Tracking Radar to Intercept on Target” or “Patriot”, which soon became the common name for the whole system. The AN/MPQ 53 consisted of a scanned array radar with identification capability, the ability to evade ECM (electronic countermeasures) such as wave jamming, and the track via missile guidance system. The AN/MPQ is a single unit, as opposed to multiple radars for the system. Basically it is the only array used from the missile detection to the missile engagement and or destruction. The second system is the command and control station, AN/MSQ-104 engagement control station. This subsystem of the Patriot SoS consisted of 5 major parts. The first is the Weapons Control Computer (WCC), which was the main computer of the Patriot missile system. The second is the Data Link Terminal which is the interface to the missile launchers. The third is the UHF communications array which creates the medium for the network communications between the patriot missile systems. The fourth component of the AN/MSQ-104 is the Routing Logic Radio Interface Unit, which is the router for all the data traffic of the Patriot system. The last component is the two computer manstations, which is where the operators interface with the system. All of these components are contained in a mobile shelter capable of withstanding electromagnetic interference, chemical/biological attacks, and also acts as protection against the elements. The third system in the Patriot Missile SoS is the OE-349 Antenna Mast Group. It consists of a mobile platform and a 2-pair 4 antennae system with the associated amplifiers and radios. The OE-349 AMG’s primary purpose is to create the Patriot communications network. The next system is the M901 launching station. This is where the missiles and the launchers are contained. They are remotely controlled as well as are a self-contained system. The last, but
arguably the most important component of the Patriot SoS is the Patriot Missile itself. There are three primary versions of the missile. The first was the MIM-104A which was created solely for anti-aircraft purposes. The second, MIM-104C/D/E (also called PAC-2) was created to extend the use of the missiles for anti-missile engagements. The MIM-104C was the primary version used in the Persian Gulf War. The MIM-104F or PAC-3 is the latest version. Other than improved tracking and flying capabilities, the PAC-3 is a hit to engage type of missile as opposed the PAC-2 which tried to destroy the enemy missiles by exploding in their vicinity. All of the missile types consisted of 4 major sections. The first is the radome, which is the tip of the missile and contains the window and the protection for the RF seeker. The second is the guidance section which consisted of the auto-guidance systems and also the track via guidance system (from the ground control). The third and fourth sections are the Warhead section and the Propulsion section. The last section is the Control actuator section which controls the fins of the missile for stability and steering. These five subsystems of the Patriot Missile System are systems in their own rights and are responsible for the four main areas of the system by working together. They each interact with each other and the domain in order to perform their respective functions within the overall system.
1.2 The Domain and the Problem
In order to properly understand the Patriot Missile system, a proper understanding of the domain of the system must be developed. Inside of the domain there is the interaction between the customer and vendor and also the environment for which the system was created. The environment was the battlefield and the main operators are soldiers who would receive training. Initially the system was a customer driven product for the United States Army and the initial purpose was an anti-aircraft missile. According to one report “The Patriot system was originally designed to operate in Europe against Soviet medium- to high-altitude aircraft and cruise missiles…To avoid detection it was designed to be mobile and operate for only a few hours at one location.” [1] As a typical customer driven product the requirements should have come from the Army. Since the initial request for the system occurred when the need was for anti-aircraft missiles on the European front, primarily against the Soviets, the domain environment and the need has shifted dramatically with respect to the Persian Gulf warfront. There were two main players in the Patriot Missile system creation environment, they are as follows: The Army and the contractor (primarily Raytheon). Even though the contractor and the users stayed the same, the environment in which the system would be used changed. The environment in which the Patriot Missile was went from high mobility anti-aircraft attacks to stationary barrack/civilian population protection. The changes in the environment were accounted for; however the changes were made after the systems were deployed in the war. “As information from all sources became available, software changes were made from August 1990 to February 199 1 by the Patriot Project Office in Huntsville, Alabama, to adapt the system to the Desert Storm environment.” [1]
The shift in the environment and in essence the requirement produced several problems with the Patriot Missile System. The can be divided into three major categories. The first is the software issues, the second is the hardware issues, and lastly the user or enterprise issues. The Software issues dominate any conversation and/or report with respect to the failure in Dhahran. Most reports point to the failure of the software to manage the clock drift or account for the round off error. However, there were also other issues with the software such as software upgrade time, software delivery time, and the reboot time for a system to come up. For example the software upgrade time required the Patriot systems to be shutdown for 1 to 2 hours, and thereby provided a vulnerability to any attacks. Also the reboot time, in order to reinitialize the clock, required 60 to 90 seconds [1]. One other major problem, which is virtually forgotten in the current day of high speed global internet connections, was the fact the upgrades had to be shipped to each site for an upgrade. Therefore, each upgrade could take days to reach the Patriot Missile Battery and then at least an hour for an upgrade. On the other hand, due to its dependence on software for many of its functional capabilities, the hardware concerns of the System had to be taken care of prior to deployment on the warfront. The main hardware concerns during the Persian Gulf conflict was the absence of a recorder for the system performance and the different types of the enemy missiles which needed to be accounted for in this war. It seemed the recorder was not part of the initial requirements and therefore was not included in the system. There were external recorders available, however, “…U.S. commanders decided not to use them because they believed the recorders could cause an unanticipated system shutdown.” [1] The enemy missiles and aircraft for which the Patriot Missile System was designed for had top speeds of MACH 2. However, in the Persian Gulf War, Scud missile had speeds of MACH 5. In a testament to software’s strengths, this hardware problem was solved via software algorithms to create a faster response from the system as opposed to improving the speed of the missiles. The last major area of issues was the user issues. The main issues involving the end user, i.e. soldiers, included the lack of an audible cue to know when an enemy target has appeared and the information about the operation doctrine in lessons to the end soldiers. If the end soldiers understood better how the Patriot Systems worked, especially in the expectation that the system would be “…relocated twice daily, and its software reinitialized after each move” [2] and how that affects the underlying components of the system, then the disaster at the barracks may have been avoided. Basically a high level understanding of the operating doctrine of the system should have been made available to the users of the system.
2 To Be
2.1 Solution to the Problem
In order to understand the solution, the problem must be clearly stated. The problem in the Dhahran attack was the system failed to detect a missile after the system had been running continuously for over 100 hours. Most major articles on this topic concluded the main culprit behind this problem was the Range-Gate algorithm and clock error. This paper will describe the problem as discussed by other papers as well as the solution provided by the Patriot Project Office (software division in charge of the Patriot missile system). We will also look into a higher level view of the problem both from the ware perspectives as well as from a requirements lifecycle perspective.