Friday, June 27, 2014

Chancellorsville Update

The U-T San Diego news website reported on the findings of Navy report on the Chancellorsville drone crash incident (1) (see, "Chancellorsville Hit By Drone").  The report was obtained through a Freedom of Information Act request.  The website made the following points in the quotes below. 

• The target drone's control system failed, causing it to ignore the “turn away” command given by the Point Mugu control room.

• The operator of the ship's Close-In Weapons System – a warship's last line of defense against incoming missiles – received a “recommend fire” alert at his console, and reported it verbally. The ship's air warfare coordinator – one of three people on the ship with the authority to engage weapons – heard but did not act on the alert.

• The Point Mugu control room did not immediately call "rogue drone" when the drone failed to turn away a little more than 2 nautical miles from the ship. Sailors relied upon this "rogue drone" call. Not hearing the call, they did nothing to protect the ship, the report said.

• The team at Point Mugu knew the drone control system had failed or showed glitches several times that day, but they didn't stop the exercise or even tell the ship. “I question this control team's ability to continue to adequately service Pacific Fleet ships,” Harris said in his comments.

• The ship's combat systems coordinator changed the protocol for automatically activating the Chancellorsville's surface missile tracking system – without telling the skipper. The crew expected the missile system to track the drone and “were distracted attempting to conduct manual (tracking) while the drone continued inbound.”

Some initial reports had suggested that the ship’s CIWS had engaged the drone and missed but this report suggests the CIWS never engaged.

Plenty of blame to go around.


  1. It's almost as if these people didn't fully grasp that they were aboard a real warship sailing around on a real ocean and that a real drone missile was flying around out there whose mission was to test just how well the crew would actually perform in a close-to-for-real environment.

    You have to wonder if the active participants in this exercise hadn't been conditioned by long sessions with simulators to reflexively view the exercise as merely a big video game, one where you could just hit the reset button if things went south.

    1. Spoken by someone who has never been in either range control or in CIC of a ship doing qualification testing of a new system.

      Lets see, from the report, and not to go into any detail of what is happening on the ship.
      1. The drone turns away a little over 2nm from the ship, executing both an altitude change and a course change. So lets say 10 seconds or so to make the call that the drone is out of control, press the fire button on CIWS, and destroy the drone before it hits the ship. At the scale in question, the ship can not tell if the drone is turning away, it is totally dependent on Range Control. And before sprouting some nonsense about leaving CIWS in AAW Auto, every target, whether it turned away or not, would be engaged by CIWS. Since shooting down drones costs money, delays testing, may jeopardize the purpose of the test, and can be dangerous, it is not done. Range Control did not call rogue drone.

      2, The purpose of the test is not to test the crew, it is to test the combat system. It is highly scripted and the crew has to follow the script or else you do it over. You have numerous people not normally in the loop who are observing the actions of the system, not the crew. Notice that there was someone sitting at the CIWS who called out that the system recommended firing, but since no one reported the drone out of control, no one gave permission to fire. Again, unless someone says the drone is out of control, the ship will not fire.

      3. Range Control has something less than 5 seconds to identify the drone is out of control, remember the signal is sent around 2nm, attempt to regain control/resend the signal, and then call rogue drone. Even then, the drone or pieces of it will likely still hit the ship as there is no warhead to explode and at 500kts, it will keep moving forward. Its not like a pilot in a plane, you are watching radar screens and sending info to the drone. You have to tell by the radar display (admittedly a very good one) that the drone is behaving correctly. Remember, every drone shot down adds costs, delays the testing, and creates delays to the entire program. So yes, they had issues that need to be corrected, but they are juggling numerous details far beyond the scope of the actual event. Also from the report, the primary purpose of the run was already scrubbed because one of the drones failed earlier, so there was already a large amount of distraction in range control.

      So to summarize, the ship and the range control made mistakes, but it is far from treating the test (it is not an exercise) as a big video game. If anything, it was the desire to move the tests along, get the most possible out of the testing, and prove the system works that motivated everyone to try to maximize the benefit of a already failed test. It appears that everyone understood that you couldn't just hit the Reset button.

    2. USNVO, your points are on target to the extent that what one sees here in this incident is what happens when a systematic Conduct of Operations breakdown occurs under circumstances that are highly unforgiving.

      The report says that there were indications of problems with the drone earlier that day. Continuing to use it presented risks. If the decision was made by Range Control to continue using it -- and I won't second guess that decision because I'm not technically qualified to make that kind of specific judgement -- then the risks should have been communicated to those potentially in harm's way from another malfunction.

      When these kinds of things happen, and the ones I am most familiar with happened in the nuclear industry, one often discovers that an abnormal situation was progressively developing in which several opportunities were available to avoid the incident, but were not taken.

      The most common reason why it happens is that a complicated potentially dangerous situation is present and that other priorities -- cost, schedule, mission completion, management or command pressures, etc. etc. -- affect the decision as to whether to continue with operations or whether to stop at least temporarily to take stock of the developing situation.

      The BP oil spill and the Port Royal grounding are other examples of this kind of thing.


Comments will be moderated for posts older than 7 days in order to reduce spam.