Air Defense
Air Defense
Posted on Apr 11, 2024
How Patriot proved itself in Ukraine and secured a fresh future
496
23
10
5
5
0
"It has shot down Russian aircraft like Su-34 fighters flying nearly 100 miles away, and intercepted missiles as far as 130 miles away, according to Oleksandr Musiienko, head of the Kyiv-based nongovernmental organization the Center for Military and Legal Studies."
How Patriot proved itself in Ukraine and secured a fresh future
Posted from armytimes.com
Air Defense
Technology
Tactics
Posted 19 d ago
Responses: 4
4
4
0
1. There was no Patriot failure in Saudi Arabia. It was operator error.
2. As to friendly fire if the Pilots do not turn on their transponder or return in specified lanes and altitude they will be targeted and engaged as they are considered enemy targets and they know this
3. It's propaganda about the targets at 100 plus miles. No one engages at that distance as your chance of a kill is very low. Not saying it cannot be done or ws done but the closer the target the greater the chance of a kill.
4. I see problems with this new radar just from the pic. Its not going to function to the level of a patriot system.
2. As to friendly fire if the Pilots do not turn on their transponder or return in specified lanes and altitude they will be targeted and engaged as they are considered enemy targets and they know this
3. It's propaganda about the targets at 100 plus miles. No one engages at that distance as your chance of a kill is very low. Not saying it cannot be done or ws done but the closer the target the greater the chance of a kill.
4. I see problems with this new radar just from the pic. Its not going to function to the level of a patriot system.
(4)
(0)
COL Randall C.
SGT (Join to see) - The error was not a "known issue long before Desert Storm".
While I wasn't with the Battalion during DS/DS (I was in another ADA unit in the 11th), I became the S-2 after they returned from the Gulf and was involved with many of the investigations (particularly the GAO one) that occured after the fact to determine what went wrong.
The error caused by long periods of operation was only reported a couple of weeks prior to the incident from the Patriot units that were deployed in Israel. It took the PPO (Patriot Project Office) and Raytheon two weeks to track down and implement a fix for the software and start distributing it to the field, and the patch was delivered to the unit in Dhahran on February 26th, one day after the Scud impacted on the warehouse.
While the PPO did send a message out to the field a few days prior to the Scud incident warning about the issue ("long run times" could affect TBM targeting) and that there would be a software upgrade in the next few days, there was no action directive nor did it specify what "long run times" were.
As Alpha Battery (the one who's footprint covered the projected impact area of the Scud) was in continuous operation because the other battery they were collocated with had their radar down for repairs, the decision was made not to bring it down until the patch was on-site.
** EDIT ** - was able to track down the GAO report on the incident - https://www-users.cse.umn.edu/~arnold/disasters/GAO-IMTEC-92-96.pdf
While I wasn't with the Battalion during DS/DS (I was in another ADA unit in the 11th), I became the S-2 after they returned from the Gulf and was involved with many of the investigations (particularly the GAO one) that occured after the fact to determine what went wrong.
The error caused by long periods of operation was only reported a couple of weeks prior to the incident from the Patriot units that were deployed in Israel. It took the PPO (Patriot Project Office) and Raytheon two weeks to track down and implement a fix for the software and start distributing it to the field, and the patch was delivered to the unit in Dhahran on February 26th, one day after the Scud impacted on the warehouse.
While the PPO did send a message out to the field a few days prior to the Scud incident warning about the issue ("long run times" could affect TBM targeting) and that there would be a software upgrade in the next few days, there was no action directive nor did it specify what "long run times" were.
As Alpha Battery (the one who's footprint covered the projected impact area of the Scud) was in continuous operation because the other battery they were collocated with had their radar down for repairs, the decision was made not to bring it down until the patch was on-site.
** EDIT ** - was able to track down the GAO report on the incident - https://www-users.cse.umn.edu/~arnold/disasters/GAO-IMTEC-92-96.pdf
(1)
(0)
SGT (Join to see)
COL Randall C. - Then how was I aware of it before Desert Storm. As to Raytheon's knowledge I'm sure they also knew but they most likely considered it a low priority to address due to normal thinking that at no time would a system be required to run that long without being shutdown. It was a simple ting to fix. All one had to do was shutdown the radar for a period of time that would allow the capacitors to disperse their charge then power back up.
There were 2 other issues that arose that Raytheon's Knowledge Base could not address. One was totally situational ,basically a 1 in a billion chance of happening. The other one was a 1 in a million chance and most likely overlooked as a possibility for causing the problem I was facing. Now we know that mechanical systems vibrate harmonically at certain discrete frequencies which are known as natural frequencies of a system and the question I was facing was according to the diagnostic tapes was either a loose connection or card. Yet the fault was being reported at a faster rate than the natural frequencies of the system. Using Raytheons diagnostic tapes to confirm my suspicions along with Doc's agreement with my assessment that it was a component that was breaking down such as an oscillator. and not a vibrating connection I went and back traced the signal unit I discovered the oscillator, replaced the card and confirmed that the problem had been fixed.
My guess is that when the diagnostic software was developed this possibility just was not considered which is why only a loose connection was indicated as the problem and I'm sure its been corrected as they spent 3 days confirming my solution to the problem.
There were 2 other issues that arose that Raytheon's Knowledge Base could not address. One was totally situational ,basically a 1 in a billion chance of happening. The other one was a 1 in a million chance and most likely overlooked as a possibility for causing the problem I was facing. Now we know that mechanical systems vibrate harmonically at certain discrete frequencies which are known as natural frequencies of a system and the question I was facing was according to the diagnostic tapes was either a loose connection or card. Yet the fault was being reported at a faster rate than the natural frequencies of the system. Using Raytheons diagnostic tapes to confirm my suspicions along with Doc's agreement with my assessment that it was a component that was breaking down such as an oscillator. and not a vibrating connection I went and back traced the signal unit I discovered the oscillator, replaced the card and confirmed that the problem had been fixed.
My guess is that when the diagnostic software was developed this possibility just was not considered which is why only a loose connection was indicated as the problem and I'm sure its been corrected as they spent 3 days confirming my solution to the problem.
(1)
(0)
COL Randall C.
SGT (Join to see) - How you were aware of it prior to the rest of the Army? I have no idea. Which unit were you with? 3-43? 32d AADCOM? I guess it's possible that it was known to you and your unit and never properly reported up to the PPO so that the rest of the Army would be aware of the issue. As to the other issues you raise, I can't comment as I'm not knowledgeable about them.
The first it was reported to the PPO was when the Patriot units in Israel reported an issue to them on February 11th, two weeks prior to the Scud landing on the warehouse. That's not in dispute by any official record.
However, I suppose the GAO, Raytheon, the Patriot Project Office, the Pentagon, and the 11th ADA Brigade leadership could have been covering up that a 20+ hour error was known prior to it being officially reported to the PPO, but that's probably a stretch.
The first it was reported to the PPO was when the Patriot units in Israel reported an issue to them on February 11th, two weeks prior to the Scud landing on the warehouse. That's not in dispute by any official record.
However, I suppose the GAO, Raytheon, the Patriot Project Office, the Pentagon, and the 11th ADA Brigade leadership could have been covering up that a 20+ hour error was known prior to it being officially reported to the PPO, but that's probably a stretch.
(1)
(0)
CPL LaForest Gray
1.) PATRIOT MISSILE DEFENSE: Software Problem Led to System Failure at Dhahran, Saudi Arabia
Organization(s):
GENERAL ACCOUNTING OFFICE WASHINGTON DC INFORMATION MANAGEMENT AND TECHNOLOGY DIV
Pagination:
18
SECURITY MARKINGS
Distribution:
APPROVED FOR PUBLIC RELEASE
Terms
Collapse
Descriptor(s):
*WEAPON SYSTEM EFFECTIVENESS, *SURFACE TO AIR MISSILES, *GUIDED MISSILE TRACKING SYSTEMS, *BALLISTIC MISSILE INTERCEPT SYSTEMS, *COMPUTER PROGRAM RELIABILITY, *FAILURE(ELECTRONICS), COMPUTER PROGRAMS, MILITARY OPERATIONS, ISRAEL, IRAQ, CONTROL SYSTEMS, COMPUTATIONS, DEFENSE SYSTEMS, ATTACK, ARMY FACILITIES, FAILURE, ACCURACY, LONG RANGE(TIME), WEAPON CONTROL, SAUDI ARABIA, BARRACKS
Field(s)/Group(s):
Computer Programming and Software, Antimissile Defense Systems, Electrical and Electronic Equipment, Surface-Launched Guided Missiles
Report Date:
1992 Jan 01
SOURCE : https://apps.dtic.mil/sti/citations/ADA344865#:~:text=The%20Patriot%20battery%20at%20Dhahran,the%20longer%20the%20system%20operated.
The Patriot battery at Dhahran failed to track and intercept the Scud missilebecause of a software problem in the systems weapons control computer. This problem led to an inaccurate tracking calculation that became worse the longer the system operated.
2.) Patriot Missile Defense:
Software Problem Led to System Failure at Dhahran, Saudi Arabia
IMTEC-92-26
Published: Feb 04, 1992. Publicly Released: Feb 27, 1992.
SOURCE : https://www.gao.gov/products/imtec-92-26
3.) PATRIOT MISSILE DEFENSE
Software Problem Led to System Failure at Dhahran, Saudi Arabia
SOURCE : https://www.gao.gov/assets/imtec-92-26.pdf
* Raytheon's Response to WGBH FRONTLINE
* "Gulf War"
SOURCE : https://www.pbs.org/wgbh/pages/frontline/gulf/weapons/raytheontext.html
Organization(s):
GENERAL ACCOUNTING OFFICE WASHINGTON DC INFORMATION MANAGEMENT AND TECHNOLOGY DIV
Pagination:
18
SECURITY MARKINGS
Distribution:
APPROVED FOR PUBLIC RELEASE
Terms
Collapse
Descriptor(s):
*WEAPON SYSTEM EFFECTIVENESS, *SURFACE TO AIR MISSILES, *GUIDED MISSILE TRACKING SYSTEMS, *BALLISTIC MISSILE INTERCEPT SYSTEMS, *COMPUTER PROGRAM RELIABILITY, *FAILURE(ELECTRONICS), COMPUTER PROGRAMS, MILITARY OPERATIONS, ISRAEL, IRAQ, CONTROL SYSTEMS, COMPUTATIONS, DEFENSE SYSTEMS, ATTACK, ARMY FACILITIES, FAILURE, ACCURACY, LONG RANGE(TIME), WEAPON CONTROL, SAUDI ARABIA, BARRACKS
Field(s)/Group(s):
Computer Programming and Software, Antimissile Defense Systems, Electrical and Electronic Equipment, Surface-Launched Guided Missiles
Report Date:
1992 Jan 01
SOURCE : https://apps.dtic.mil/sti/citations/ADA344865#:~:text=The%20Patriot%20battery%20at%20Dhahran,the%20longer%20the%20system%20operated.
The Patriot battery at Dhahran failed to track and intercept the Scud missilebecause of a software problem in the systems weapons control computer. This problem led to an inaccurate tracking calculation that became worse the longer the system operated.
2.) Patriot Missile Defense:
Software Problem Led to System Failure at Dhahran, Saudi Arabia
IMTEC-92-26
Published: Feb 04, 1992. Publicly Released: Feb 27, 1992.
SOURCE : https://www.gao.gov/products/imtec-92-26
3.) PATRIOT MISSILE DEFENSE
Software Problem Led to System Failure at Dhahran, Saudi Arabia
SOURCE : https://www.gao.gov/assets/imtec-92-26.pdf
* Raytheon's Response to WGBH FRONTLINE
* "Gulf War"
SOURCE : https://www.pbs.org/wgbh/pages/frontline/gulf/weapons/raytheontext.html
(0)
(0)
3
3
0
1.)Nuclear War Map
Simulations : Maps : References
SOURCE : https://www.nuclearwarmap.com
2.) SEPTEMBER 18, 2019 CAMPAIGN NEWS
New Study on US-Russia nuclear war: 91.5 million casualties in first few hours
34.1 million people could die, and another 57.4 million could be injured, within the first few hours of the start of a nuclear war between Russia and the United States triggered by one low-yield nuclear weapon, according to a new simulation by researcher’s at Princeton‘s Science and Global Security programme.
SOURCE : https://www.icanw.org/new_study_on_us_russia_nuclear_war
3.) FEMA - Planning Guidance for Response to a Nuclear
Detonation
Third Edition
SOURCE : https://www.fema.gov/sites/default/files/documents/fema_nuc-detonation-planning-guide.pdf
Simulations : Maps : References
SOURCE : https://www.nuclearwarmap.com
2.) SEPTEMBER 18, 2019 CAMPAIGN NEWS
New Study on US-Russia nuclear war: 91.5 million casualties in first few hours
34.1 million people could die, and another 57.4 million could be injured, within the first few hours of the start of a nuclear war between Russia and the United States triggered by one low-yield nuclear weapon, according to a new simulation by researcher’s at Princeton‘s Science and Global Security programme.
SOURCE : https://www.icanw.org/new_study_on_us_russia_nuclear_war
3.) FEMA - Planning Guidance for Response to a Nuclear
Detonation
Third Edition
SOURCE : https://www.fema.gov/sites/default/files/documents/fema_nuc-detonation-planning-guide.pdf
(3)
(0)
3
3
0
LTC Eugene Chu In the dead of night in May, Russia launched a Kinzhal hypersonic missile at the Ukrainian capital of Kyiv.
The air-launched weapon can reach speeds up to Mach 10, which equates to about 7,700 mph.
The air-launched weapon can reach speeds up to Mach 10, which equates to about 7,700 mph.
(3)
(0)
Read This Next
Continue with Facebook 
Continue with Google 
