Reprogramming the Navy
On October 15, 2016, the United States Navy christened the USS Zumwalt. The destroyer is packed with new gear, is manned by a smaller crew, and has a design so stealthy it requires specialized reflectors when it wants to be seen. The warship also heavily relies on automation, which is one reason it can be operated with a smaller crew. This use of automation has given rise to questions about whether sailors should be able to use scripts—short programs written to automate processes—to change software on the fly.
Such a system has both benefits and risks; it could allow the ship’s systems to be changed for specific challenge or could lead to a system failure. Of course, whether such an adaptable system results in benefits or is disaster is likely to rely on the specific programmer and the situation at hand. In having the debate over reprogramming, though, the Navy should remember that they already have adaptable, high-risk systems in their fleet: aircraft carriers.
Airplanes at Sea: Complicated Systems
Scholars have previously used the U.S. Navy’s aircraft carriers of how highly complex organizations each high levels of reliability. The cost of the platforms and the hazardous nature of the work they do makes it so that carriers operate with an expectation of “failure-free” performance. Though there have been failures—there was a near-crash in March this year—aircraft carriers have generally performed well. That performance should not be taken for granted, given the complexities of launching and landing planes from a moving airstripe—covered in salt water and oil and staffed by young operators with high turnover.
In 1987, a group of scholars examined aircraft carriers to figure out how such a high-risk, complex, and technical system produced the reliability it did. They concluded that a range of factors were in play, from unusual formal and informal relationships to standard operational procedures and redundancies. The unusual combination, according to the study, resulted in a self-designing redundant organizational system. What would normally be confusing or inefficient in another scenario proved essential to the safe operation of the carrier.
To Each Their Own
Another characteristic of the carrier fleet the authors highlighted was how unique each ship was:
“For a variety of reasons, no two aircraft carrier, even of the same class, are quite alike. Even if nominally the same, as are the recent Nimitz-class ships, each differs slightly in equipment and develops a unique personality during its shakedown cruise and first workup and development.”
Even with physical similarities, each carrier developed different processes within the overall mission. Different ships worked in different environments, had different commanding officers, different equipment, and different histories.
The standardization of carriers is different today than it was when the study was conducted, but it pointed out something useful: a reliable organization can organically develop for high-risk missions without strict predetermined operating procedures. Not only did this occur on aircraft carriers, but the ships’ unusual organizational structure might have been the best approach for their time.
Altering the Automated
Why does this apply to the Zumwalt-class destroyers and the conversation over editing its software? The Navy has demonstrated that there is value in non-standard operating procedures across the fleet, with variations for different parts of the world, different equipment, or different missions. More importantly, these variations can be used without degradation to the mission. There are risks to having changes within such a complex system, but the history of aircraft carriers demonstrate that these changes can be beneficial.
With software replacing crewmen on the Zumwalt-class destroyers, the ability to create variations will increasingly rely on edits to that software. It has yet to be seen how beneficial the use of such scripts would be, but it might not be wise to blanket ban them before their viability can be tested.
The carriers also demonstrate how such testing can be handled, given that the cost of an error could be the loss of a ship worth over $4 billion dollars. In high-risk systems that need to be high reliability, redundancies can be useful instead of costly. Redundant versions of software could be saved on the ship in case changes to one version causes problems or doesn’t work. Unlike on aircraft carriers, these redundant systems would not rely on multiple crewmembers for one job, and so could be cheaper. If scripts are allowed on the new destroyers, the could be reviewed before execution.
The benefits or risks of using scripts in software-heavy platforms will only really be properly vetted through tests in real operating scenarios. When all three ships are finished, different use of scripts can be used in each, determining what works and what doesn’t. This decentralized approach can help the Navy use each ship to greatest extent. If changes on one ship work particularly well, it can be copied on the other two.
The high level of automation in the Zumwalt-class destroyers gives the Navy an opportunity to test the next generation of adaptability on high-risk platforms. The history of the aircraft carrier shows how useful that adaptability can be.