Trying to identify a critical flaw in a highly complex planetoid-sized battle station, under extreme time pressure, with no clear idea where the vulnerability may lie – this is the challenge faced by the Rebel Alliance in the film Star Wars. After receiving stolen plans, they have just four days before the Death Star bears down on the rebel base on the planet Yavin’s fourth moon.
Unlikely as it sounds, trying to establish how the Death Star came to be destroyed can help us – over here in the real, more mundane world – to find weaknesses in our complex systems. In the real world many types of systems need testing – from business practices, machines, and software, to arguments and theories. Anything complex can be made more simple, and therefore its strengths and weaknesses brought more clearly into focus, using systems analysis.
Back when the original Star Wars (Episode IV, A New Hope) premiered in 1977, the method of choice for analysing system safety was the hazard and operability study, or HAZOP. This method was developed by ICI in the 1960s, and applied the kind of brute force deterministic logic that took humankind to the moon during the same decade.
HAZOP works by breaking down a system into its component parts, and then working through each asking questions like “could this task take place sooner than …” or “later than …” or “be omitted altogether .. ” and so on. HAZOP strikes fear into the hearts of industrial personnel, because no matter how many cups of tea and biscuits are provided, conducting a HAZOP study is an arduous business. Would it work for the Death Star, or one of today’s complex systems?
Look at the HAZOP on that
We tried it and the answer is no.
First, it took longer to work our way through all the component tasks involved in operating a Death Star than it took for the battle station to arrive at Yavin. Ignoring this point, merely breaking down the Death Star into its component tasks only exposed component failures. And none of these included a farm hand from the planet Tatooine flying an X-wing fighter along the Death Star’s equatorial trench, evading turbo laser towers and squadrons of Tie fighters, and firing a pair of proton torpedoes into a two metre-wide thermal exhaust port.
Clearly, understanding individual component hazards in isolation cannot hope to reveal all the various interactions of them that cause complex systems like the Death Star to fail.
We don’t have access to the plot of the new Star Wars film (Episode VII, The Force Awakens) but it would be good safety management to at least plan for the appearance of a third Death Star given that a second cropped up in Return of the Jedi (Episode VI). Instead of applying HAZOP we need to apply a more contemporary method that reflects our knowledge and understanding of systems safety and resilience in 2015.
A systems approach
State of the art approaches no longer use deterministic logic to break complex systems into simpler ones. Instead we examine the things which constrain or enable behaviour. One method is work domain analysis, which comes from early cognitive systems engineering research originally applied to Danish nuclear reactors.
It was very quick to create a work domain analysis of the Death Star – quick enough to complete within the four-day window, and able to show us many different vulnerabilities and how they could interact to cause a systems failure. This included everything from identifying how the navigation computer might be used to collide the Death Star into a real star, through to how the air conditioning could be used for bio-warfare.
In fact the actual vulnerability exploited in the first Star Wars film (the small thermal exhaust port into which proton torpedoes were fired leading to an explosive chain reaction) was one of the potential problems revealed by the work domain analysis. That’s the beauty of systems thinking: we can look at systems and ask ourselves not what it should do, nor even what it actually does, but what it could, potentially do given certain circumstances.
Other ways to destroy a Death Star
This method is so powerful that it revealed a large number of different, and perhaps more convenient ways to destroy the Death Star: attack the executive docking bay as the Emperor arrives and other VIPs are assembled? Disrupt the command and control infrastructure? After all it would take ages to get from one side of the Death Star to the other to chat in person. A major space vermin infestation (tribbles, perhaps) would seriously degrade the ability of the Death Star to provide life support, nibbling cables and using up oxygen resources. Maintenance droids could be put to nefarious use – perhaps we could capture a couple of them with the Star Wars equivalent of Stuxnet malware, encouraging normal failures and allowing them to worsen.
All of which brings us to the top ranked (following formal risk assessment) Death Star vulnerability, one that could avoid all the death, destruction and general inconvenience of flying squadrons of fighters to the surface of the Death Star, evading multiple layers of defences in order to fire proton torpedoes into an unfeasibly small hole. Let’s just send in R2D2 to upload a computer virus.
After all, the pint-sized droid had already plugged himself into the Death Star’s systems twice during the film. The downside is that you’d end up with Independence Day and not Star Wars and, come to think of it, the first computer virus wasn’t unleashed until 1982. From a methodological point of view it doesn’t really matter. The fact the system could be exploited by a computer virus was recognised by the systems-based approach.
Just like Luke Skywalker and the original film’s title, systems-based approaches such as work domain analysis offer us “a new hope”. Only in this case our goal is not to bring down an evil empire but to better understand complex modern systems and design things that are better, safer and entirely lacking in dark side.