The investigation revealed all the usual suspects associated
with any disaster: poor communications,
violation of standards, ignorance of facts about equipment and procedures, lack
of preparation, failure to anticipate the worst case scenario, equipment
failure, misjudgments, and so on. I’m
not going to bore you with a recitation of the details because, frankly, they read
exactly the same as for any and every other accident and there is nothing
worthwhile in them. Reports have been
written, endless recommendations have been made (closing the barn door after
the horse is out), and the same incident will, inevitably happen again sometime
because no real change will occur. So,
moving on …
 |
| Chancellorsville Drone Strike |
As a reminder, here is a brief description of the drone from
the report memos.
…
the BQM-74E ia an aerial target drone produced by Northrup Grumman. It is
turbine-powered, recoverable, remote controlled, and subsonic. It. is capable
of speeds up to Mach .86 or 515 knots at sea level. It is 12.95 feet long, 5.78
feet wide, weighs 455 pounds, and resembles a small Tomahawk cruise missile,
though is painted bright orange. (1)
On a macabre note, the test range personnel issued a “Rogue Drone”
call 17 seconds AFTER the drone struck the ship.
The
drone struck the ship at 13:14:00. The Test Conductor called "Rogue
Drone" at 13:14:17. (1)
While there was plenty of failure on the part of the ship’s
company to anticipate, observe, and engage the rogue drone, I’d like to focus
on the drone control failure. The drone
is controlled by the test range System for Naval Target Control (SNTC). From the report,
The
SNTC consists of the following major components: Master control Consoles
(MCCs). Target control Consoles (TCCs). Ground Radio Frequency Units (GRFUs).
UHF antennas, GPS antennas, Model 53 Portable Test Set (PTS), Model 280-l UHF
Transponders, Shipboard Transponders, Airborne Relays and associated ancillary
equipment. The SNTC provides system operators with a Microsoft Windows based
interface enabling system configuration and control. (1)
On a more complex scale, this is the equivalent of the
handheld controller that you would use to control a remote control model
airplane.
I’d now like to look a few specific aspects of the incident.
Network Issues – “The investigation determined that the SNTC
was incorrectly configured and caused a significant increase in network message
transmissions and system instability.” (1)
On a relative basis, the networking involved in controlling
a target drone is about as simple as it gets.
Further, this network had been in use for some time. Despite this, the network failed, to an
unspecified degree. How many times has
ComNavOps warned about our headlong pursuit of networks as the advantage we’re
going to pin our war-winning hopes on?
If we can’t make even simple, isolated networks work reliably how are we
going to make staggeringly complex networks work in the face of enemy electronic
countermeasures and cyber attacks? The
desire to place all our hopes on data and networks is lunacy and this incident
is yet another piece of proof.
Electromagnetic
Issues – “The frequency spectrum that
SNTC operates in is a congested electromagnetic environment and susceptible to
interference that can result in difficulties controlling drone flight
operations.” (1)
What the military fails to grasp is that ALL frequencies,
across the entire spectrum, will be congested and susceptible to interference. This vulnerability will only get worse once
the enemy initiates electronic countermeasures, jamming, and cyber
attacks. We’re currently using the
electromagnetic (EM) spectrum as if it’s a free tool that we have exclusive and
unhindered rights to – and, in peacetime, that’s somewhat true. The enemy will quickly change that when war
comes. This is analogous to our
addiction to, and dependence on, GPS positioning. We need to accept that our free and easy use
of the EM spectrum will not continue in combat.
To that end, we need to build in much more simplicity, redundancy, and
brute force in our EM use. We also need
to train to operate in a compromised EM spectrum, something we’re only doing to
a very limited extent, right now. Every
exercise we do should include an OpFor dedicated to degrading our own EM
environment so that we learn what equipment works and what is vulnerable and
how to operate without an unhindered EM battlefield.
System Degradation
– “Prior to the launch of the BQM-74E
drones, one of which impacted CHV, the control team knew the target drone
control system had failed or exhibited abnormalities several times that day;”
(1)
Consider this statement:
Prior to the [fill in the blank] incident, it was well known
that problems existed in the [fill in the blank].
This statement appears in almost every incident ever
reported. The recent Burke collisions
were laced with known manning, training, and certification problems prior to
the incidents. The riverine boats that
got lost and were surrendered to the Iranians were known to have problems with
leadership, training, readiness, planning, and mechanical issues. And so on.
Despite this consistent element to every incident, the Navy
has made no effort to change the culture which encourages personnel to ignore
obvious problems. Until this changes,
incidents will continue unabated. This
is a leadership deficit, pure and simple, starting at the highest level.
Discrimination – “Based on previous tracking presentations,
drone tracks would coast and appear to be inbound to the ship even after
turning outbound.” (1)
We want to construct massive, regional, all-seeing,
all-knowing networks with perfect awareness and real-time data so that we can
bring our enemies to their knees with our overwhelming situational
knowledge. You’d think firepower would
play a part in victory, too, but our Navy leaders seem not to think that. But, I digress …
The point is that our very best Aegis radar system appears
to have a systemic “latency” or inertia in that the displayed tracks “coast”
toward the ship even though the actual object has turned away. Presumably, all tracks have this latent
inertia and, if so, that’s got to make missile intercepts a lot more
challenging since we never know whether that incoming missile that is engaged
in terminal maneuvering is actually where it appears or if it’s jinked onto a
new course! So, much for all-seeing,
all-knowing, real-time, perfect awareness!
If our very best sensor system has that kind of reality “delay”, you
have to question the very foundation of our network/data wishful thinking.
There was nothing in the reports indicating that this
latency inertia was a brand new phenomenon, just discovered in the course of
this incident - quite the opposite. It
appears to be a well known system flaw that has been around for quite some
time. So, why hasn’t it been
addressed? This ties back into the
System Degradation comments and the deficiencies and culpability of Navy
leadership.
Summary – Every incident
like this is yet another in an endless string of opportunities for the Navy to institute
real, positive, effective change and yet they never do. Instead, they write reports, generate long
lists of recommendations, create more and more layers of paperwork, and
accomplish nothing. The Navy’s biggest
problem is not maintenance, readiness, training, manpower, numbers of ships, or
anything of that nature. The biggest
problem is leadership – the total, complete absence of effective
leadership. Until that changes, nothing
else will improve.
__________________________________
Re: the latency. That's ... inexcusable. "Latency" is what drunk drivers experience -- delayed perception and reactions. Fat, drunk, and stupid is no way to go through life. I don't know that the opposition is any better, but we're risking another Savo Island without the industrial capacity to replace the losses. Then again, we don't have the missile stocks to fight for very long, so in the end, what difference does it make?
ReplyDeleteI wonder if the computer is having some predictive pathing bleeding over? Intercepts need to be made where the missile is going to be, not where it is. It is inexcusable no matter what is.
DeleteHoly shit! Look at the size of that hole from a simple drone. These are ships that we’d go to war with and even an inert drone goes through the thin hull. We need armor ASAP.
ReplyDeleteYou make a very good point about the degree of damage and penetration from a subsonic, lightweight drone with no warhead. The Ticonderoga superstructure, as you probably know, is aluminum rather than steel. So, not only should we have armor but the superstructure should be steel.
DeleteGood comment.
While reading through the report, the potential for shrapnel damage to the ship from engaging a BQM-74 drone with CWIS caught my attention. The report (Paragraph 5(e)3 under Actions on page 50) reads, “Conduct technical analysis, modeling and simulation to determine actual risk to ships in the event of a drone is enabled with CWIS. There is a widespread belief in the Fleet that CWIS engagements of BQM-74 drones within 2 nautical miles will result in significant shrapnel damage to the ship.”
ReplyDeleteIf there is a risk of shrapnel damage from engaging a subsonic, lightweight drone (549 lb. gross weight according to Wiki), what is the risk to the ship in engaging a heavyweight (1,000 lbs. plus) Russian or Chinese missile going Mach 2 or better?
What is your point?
DeleteJust what I wrote. In a multi-missile attack, its possible that CWIS would engage a missile inside 2 nautical miles. If a lightweight drone with no warhead can cause this much damage, how much damage would a heavyweight missile with a 500-600 pound warhead cause? And, how do we proof the ship from such an engagement? The comment suggests such an engagement could result in damage to the ship's radars, antennas, and other exposed components.
DeleteAt the same time, if there indeed is a "widespread belief" of damage to the ship from engaging a target at 2 nautical miles, why hasn't the Navy already conducted the analysis and modeling as recommended in the report? I have to think that somebody somewhere (e.g., Navy Sea Systems Command, Naval Postgraduate School, etc.) has already looked into this.
Has anyone ever looked at more of a "cluster bomb" effect warhead? Instead of going for 1 massive warhead, go more for a bunch of smaller warhead/clusters? You probably won't get a full kill BUT with all the radar,electronics, etc and no armor, why bother? Not sure it could be technically done but you would overwhelm the CWIS with multiple smaller warheads/bomblets all hitting the superstructure....the closest thing I know of is Starstreak but I'm thinking something a lot bigger for ASM application.
Deletehttps://en.wikipedia.org/wiki/Starstreak
@NICO: If you're talking about damaging the systems, you might as well just go for the biggest warhead you can carry, because kinetic impact and shockwave are going to hurt today's lightly armored ships. Consider the USS Stark attack: shockwave from the detonating Exocet broke Stark's systems, preventing a retaliatory shot with SM-1.
DeleteYou have a point with overwhelming the CIWS - and as an aside, the USN considers JSOW a threshold ASuW weapon - but the problem I see is that in order to deploy submunitions your missile is going to have to do a pop up maneuver and rise pretty high, which is going to make it an easier target for point defenses to engage with, since it's no longer sea-skimming. I feel if you were going to go through all that trouble you might as well just fire more missiles, especially since a credible attack is going to feature multiple missiles being fired at the target ship anyway.
"Just what I wrote."
DeleteYou didn't offer any point. You repeated a statement from the report.
"how do we proof the ship from such an engagement?"
How do you "proof" a ship from damage in battle????? You can't!
If you're asking how we can better protect our ships, I'm sure you know the answer(s): armor, more CIWS, more SeaRAM, distributed sensors for longer range detection and engagement, more manning for damage control, more redundancy, and so on.
You've asked questions but you haven't offered any point or solutions. Nothing wrong with asking questions but I'd prefer solutions and I'm sure you knew the answers.
"why hasn't the Navy already conducted the analysis and modeling as recommended in the report?"
Why hasn't the Navy designed better ships? Why hasn't the Navy better trained its officers and men? Why hasn't the Navy provided a munition for the Zumwalt AGS? Why hasn't the Navy built a dedicated minesweeper? We can list "why hasn't the Navy" questions all day. The answer is that combat is not their priority - budget is. Again, you know this.
Harden would have been a better word to use. Also, I would add compartmentalization to the list. Armor is fine, but as you well know, there are many external components that can't be armored because that would affect their performance.
DeleteSay what you want about the Zumwalt and the other recent failures of the Navy, the threat from heavy antiship missiles is 30+ years old, so it's not a recent phenomenon. And, Phalanx itself, is just as old as the threats it faces.
If using CWIS can cause damage to the ship, that is something that should have been characterized and understood. Of course, you wouldn't detonate a 500 lb warhead near an actual ship, but testing could be performed on land against a variety of simulated targets to characterize the potential for damage to the ship.
"Of course, you wouldn't detonate a 500 lb warhead near an actual ship"
DeleteActually, we can. The Navy has a remote controlled weapons testing ship.
"testing could be performed on land"
And you're spot on with this one! A CIWS with a simple sheet metal wall behind it to simulate the ship's superstructure and we could know exactly how much shrapnel, if any, would be generated at any given range from any given size/speed missile.
Excellent!
I am just totally baffled by the Navy's refusal to conduct any kind of realistic testing. The benefits would be enormous and their is not downside other than finding flaws in some weapon systems and finding that some of our beliefs are incorrect - and those are actually benefits!
"Armor is fine, but as you well know, there are many external components that can't be armored because that would affect their performance."
DeleteIs that really true? Or, is it just something we've come to accept because no one has tried? Consider the tank. It has many sensors and they're armored on all sides but one and even that one open side is semi-encased in armor. Why can't ship sensors be enclosed in a similar fashion? A radar, for example, only "sees" in a restricted field of view. The other sides could be armored. In fact, many radars could be housed in retractable/closeable armored housings that could be shut when attacking missiles get close enough to hit. Remember, that last, terminal engagement is by SeaRAM and CIWS which don't need ship's radar - they have their own. Just something to think about.
For historical perspective, the WWII ships had armored fire control directors.
For current perspective, we enclose radars and radar arrays in superstructures (Zumwalt) and masts (LPD-17). If those structures were armored, it would go a long way towards hardening our ships.
Just a bit of thinking outside the Navy box.
I've wondered if a radar-transparent kevlar-like shield (I don't know if kevlar is transparent at the right frequencies) over the radiating panels would be feasible. Obviously it would only help against splinters/shrapnel, but it might help protect the radiating elements from near missed (or a close-in CIWS destruction of an incoming missile).
DeleteI wonder if this incident will be used as a justification against acquiring super-sonic target drones?
ReplyDeleteToo dangerous? Yeah, that sounds all too possible these days. :(
DeleteThey have been using supersonic sea skimmer targets for decades. The only difference is they are not allowed to be used in a fly by wire manual mode like the BQM-74's. They are pre-programmed on their flight path and under very strict Range Safety rules for flight termination from the missile range. The fact that the Aegis weapon system shoots them down at over 3.5 times the speed of a BQM while doing turns questions the accuracy in this article;
DeleteQUOTE: (systemic “latency” or inertia in that the displayed tracks “coast” toward the ship even though the actual object has turned away).
" questions the accuracy in this article;"
DeleteThe latency is a fact that was reported in the memos. You've lost me. What are you questioning?
The Command Investigation document you link to is fascinating to me because it is revealing, more so than I'd ever thought possible. It states, as you quoted: "Based on previous tracking presentations, drone tracks would coast and appear to be inbound to the ship even after turning outbound." And you stated " ... our very best Aegis radar system appears to have a systemic “latency” or inertia in that the displayed tracks “coast” toward the ship even though the actual object has turned away."
ReplyDeleteI disagree with your assessment of system "latency". I will try to explain. I am a retired systems engineer. I have NO experience with Aegis but I am professionally familiar with a number of modern radar and sonar tracking systems.
Modern tracking systems are tuned to match the expected scenario. This greatly enhances track declaration performance against clutter and noise. Otherwise the tracking system has to consider the full range of possble variations in contact velocities from one update to the next, and it would be necessary to boost the track declaration threshold because a greater range in random motion in threshold-crossing contacts would have to be screened out, so as not to have an unnacceptable false alarm rate for track declaration.
For example, a torpedo detection and tracking system might be tuned to limit track declarations to those contacts that are maneuvering while consistently closing range.
In such a system, a real contact that has velocity behavior that violates this tuning will cause problems. Say it is incoming and has been detected, has exhibited enough consistency of amplitude and motion to be declared a pre-track, and then due its continuing consistency over multiple updates has been promoted to the attention of the subsequent system functions and the operator if there is an operator in the loop. This is indeed a latency but not exceeding the specifications for system performance.
Suddenly the actual target reverses course. The system will lose track - temporarily it hopes - because the contact's behavior has exceeded the tuned expections for maneuverability but the tracking system assumes it is a temporary signal-to noise problem. The tracking system will present a "coasting track" to the subsequent system functions and the operator while it waits for the contact to reappear at its predicted future locations in an alloted time interval, based on the its previous velocity behavior or eventually redetect it as a new track with a different velocity. This is what "track coasting" signifies - it is not a latency applied to all tracks.
So I'm not surprised the operators were conditioned to expect to see an incoming track on a fast-moving drone when it had reversed course, or to be surprised when that incoming track was for real. I do not know if the Aegis displays diffentiate between actual and coasting tracks but I can imagine that at the speed of the drone that there would be little time for the operator figure it out and obtain permission to act or react correctly to the CIWS recommendation to shoot it down, when the drone was expected to have reversed course as it always has in the past.
In summary, my point is that radar system detection performance is enhanced by tuning to expect that normal incoming missles are not expected to reverse course at the final seconds of approach, and that system operators are tuned by experience to expect that incoming drones on a test range are not supposed to fail to reverse course.
I think that a special tracking mode for Aegis that is tuned to expect a drone to behave differently than a real missle would not be good for training because it won't behave like the operational system.
First, let me thank you for sharing your knowledge and providing a good explanation.
Delete"I disagree with your assessment of system "latency"."
I don't think you're actually disagreeing with me. What you seem to be doing is trying to be a bit more precise about the use of the term "latency". When I used the term in the post, I put it in quotes to indicate that I was using it somewhat generically.
That aside, you provided an explanation for the mechanism of the "latency" while not actually disputing the fact of its existence - hence, no actual disagreement. Feel free to correct me if I failed to understand your point.
Here's a few comments about your comment:
note - I am not a radar expert at all! - just a common sense engineering and software background.
1. I suspect that your background and experience is with rotating radars. A rotating radar can't help but have latency because it loses contact with the target on every revolution. In such a case, I can easily see that the system designers would program in (tune, to use your word) a continuation of the last valid track data while the lost contact phase occurred. With Aegis (or any non-rotating array), there is no lost contact so the track data should be completely up to data (real time) barring any true latency (true latency being the time required to translate the signal to the display - presumably very, very short). Therefore, I would be very surprised to find systematic predictive (coasting) behavior! This very issue is why military radars have moved away from rotating radars to fixed, flat panel arrays.
2. Given that modern anti-ship cruise missiles have terminal phase, violent maneuvers designed to defeat defenses, the tendency to display unreal tracks (coasting) would be a major weakness in the radar system - kind of the point of the post.
What do you think?
" I am professionally familiar with a number of modern radar and sonar tracking systems."
DeleteExcellent! In particular, I'd love to have you weigh in on sonar discussions. Sonar performance is poorly understood in the public domain. For example, the difference between sonar performance and tactics between deep water, open ocean and shallow water is not well documented and our discussions would benefit immeasurably from some genuine expertise. I look forward to hearing from you on future posts.
You are right, my experience is with rotating radars. You are also right that a rotating radar system should never be asked to maintain track on a sharply maneuvering contact.
DeleteSo I looked into online literature on the passive electronically scanned array (PESA) technology that underlies currently deployed AEGIS radar systems.
My point is still the same - that a detect/track/classify system has no choice but to “coast” a track over a specified period of time after the contact is lost, before it can be dropped. This is standard doctrine for track-before-detect systems.
The tracking system is not allowed to assume a lost track is “just gone” and to resume scanning for new tracks in the region of the old track. This is a lot of track history that must not be lost without good reason.
The allowed coasting period is determined by previous contact and track characteristics - like velocity, signal-to-noise ratio, previous track persistence - as well as expected target characteristics - speed, maneuvering limits, target strength at different aspects - and mission characteristics - arrival sector, general alert level, specific alert thresholds, etc. The target and mission characteristics sets are generally what is signified by the references to “doctrine” in your reference (1).
The need for coasting a track is not track update-time related (rotating radar vs scanned array) but due to interruptions from the environment - like elevated background noise due to own-ship maneuver perhaps, and clutter level, etc. It might also be due to failure of the track system to maintain track in the face of a contact maneuver that falls outside the doctrine of possible target motion, such as what might have happened with the Chancellorsville.
In summary: a PESA radar or any sensor system should not be asked to maintain track on a high speed contact that suddenly reverses course unless this type of maneuver is incorporated in its doctrine. Incorporating this into the tracker doctrine will change the operational nature of the system.
"any sensor system should not be asked to maintain track on a high speed contact that suddenly reverses course unless this type of maneuver is incorporated in its doctrine."
DeleteIn this particular, specific case the conditions were ideal (weather, etc.), the drone was subsonic, the drone was very close range, AND THE DRONE NEVER CHANGED COURSE. The operators saw the incoming track and ASSUMED THE TARGET HAD TURNED AWAY AS IT WAS SUPPOSED TO DO AND THEY WERE JUST SEEING COASTING. This is the crux of the problem. If our best radar, with continuous contact, under ideal conditions, is assumed to by the operators to not be capable of real time tracking then we have serious problems with the system.
Common sense would suggest that a better display scheme would be to show a "lost" track as an expanding circle of possible location based on last known speed (and unknown course) rather than coasting which leads the operator to believe he's seeing something real when he isn't. An expanding circle would make instantly clear that the track is lost and the operator should be alert. If contact is regained in a moment the circle simply disappears indicating that the target is "real" and live again.
To repeat, if Aegis is presenting "coasting" data often enough that operators have come to believe it's normal then Aegis has serious problems considering it's supposed to be able to track wildly maneuvering missiles.
Those idiots at Point Mugu should be fired, charged for negligence and then sent to jail. I doubt the ship was cleared to fire on the range which is probably why they did not fire. If your on a training range and don't have the "Green Light" to fire you don't fire any weapons. The fault is on Point Mugu not the ship. If it would have been a live fire event rather than a Track-Ex those drones would have been taken out long before they got that close to the ship.
ReplyDeleteBefore you lay all the blame on the range, you might want to read the linked memo reports, if you haven't. They strongly suggest that the ship was pre-cleared to fire CIWS but weren't mentally or procedurally ready to do so.
DeleteRead the following from the report;
Delete3. (U) Findings of Fact (FoF). I concur with and approve the IO's FoFs as previously modified and supplemented by the intermediate endorsers, subject to the following in the report:
a. (U/FOUO) FoF 128 is approved as modified: (U/FOUO) The script did not include actions to engage a drone with CIWS or a procedure to determine whether the missile was continuing inbound after the planned turn out point. [Encl 51]
The ships CIC was waiting on a "Rogue Drone" call from Point Mugu (next page 4 c.). Yet another reason to have Range Safety present during a 0 offset drone run. The last thing you want is CIWS stray rounds flying around the range and John Paul Jones (DDG 53) was on the range with them when this happened.
Point Mugu screwed up.
From the memo reports,
Delete"The ship's Close-In Weapons System (CIWS) operator received a "recommend fire" alert at his console The operator reported the alert verbally in CIC but did not pass the alert over an internal control net. In accordance with the ship's standard procedures at the time, only the Air Warfare Coordinator (AWC), Tactical Action Officer (TAO) or the Commanding Officer (CO) had the authority to authorize engagement. While the AWC did hear the "recommend fire" call, he did not act on it. "
This strongly suggests that the ship did have CIWS fire authority but were not mentally or procedurally ready to implement it. They were at fault for that portion.
Further, all Navy ships are expected to protect their ship under any circumstances. They have the inherent right to protect themselves. To suggest otherwise is absurd. The report notes this,
" However, notwithstanding the control team's failurea, the IO determined that CHV's CO had the obligation and means to defend his ship, which he failed to do. I concur. The CO's enduring responsibility that places safety of his ship as paramount per Navy regulations was not sufficiently met in exercise preparation, rehearsal, pre-briefing and execution."
There are so many great aspects that can be discussed about this: training in general, degree of realism in training, combat mentality, alternate training modes, etc. To focus on the degree of blame to be assigned to ship or range is the least useful and productive aspect as far as this blog is concerned.
That's enough on this discussion.
Im starting to get a feeling of deja vu here recently... Weve seen deployment and rotational schedules upset. Theres been a large uptick of COs across the military being relieved for "no confidence". Many failures of systems tests, whether experimental or active, have been reported. The budget wars are intensifying as the purse strings have loosened (at least temporarily). Articles about how our carriers and Navy are now helpless and obsolete saturate the net...
ReplyDeleteI feel as if Im reading a roles reversed version of "Red Storm Rising"... Is our military really being pushed from above to get its collective act together?? And/or, how many of these articles on the net are written for the eyes of foreign intelligence services?
The CO of the Chancellorsville was never relieved of his duty and in command of the ship until his tour as CO on the Chancellorsville was completed. As a matter of fact the Chancellorsville now has a GOLD Battle E displayed on the ship after this which can never be erased. Good going USS Chancellorsville and Godspeed.
ReplyDelete