Engineering a Defence

by Andrew Wallace

Abstract

Introduction

Tacoma Narrows Bridge is an interesting example in engineering design failure. The suspension bridge collapsed rather spectacularly in 1940, when winds hit the resonance frequency of the bridge. The resulting oscillations were strong enough to rip the bridge apart.

The bridge is now held up as an example of the effects of resonance and the resulting oscillations. But not only that, the bridge disaster also highlights something about human beings; we are very poor at understanding how the real world works. We many think we know, we can even be certain we know, but psychology has show us that we don’t. Now that’s a problem in engineering and science.

Engineering is about making things work in the real world and science is about understanding how the real world works. How do you make things work in the real world when we have such a poor understanding of how the world works? How do we understand the world when we have such cognitive problems?

Human Cognitive Problems

It is not just poor understanding of how the world works but we also have many other cognitive problems. I used to work within psychology at Umeå University as a research engineer. It was quite an enlightening seeing how we fail to think, especially coming from an Artificial Intelligence (AI) background that highlighted what is intelligence. A good summary of human cognitive problems can be found here: Cognitive bias cheat sheet (https://betterhumans.coach.me/cognitive-bias-cheat-sheet-55a472476b18).

In short, we are social creatures evolved to interact with others not build bridges. We can overestimate our abilities, especially when we know very little about a subject (have a look at the Dunning-Kruger effect here: What Is the Dunning-Kruger Effect? (https://www.verywellmind.com/an-overview-of-the-dunning-kruger-effect-4160740) We have to make quick decisions with little information in too short a time so we fill in the blanks and make up stories. That’s ok, it works with social interactions but not when we have to build things in the real world. We don’t know when we get things right, and most probably we are wrong when it comes to understanding the real world.

Making it work

When it comes to engineering and science, the good news is we don’t need to be right. We just need something that is workable. “Being right” and “workable” are not the same thing. As an example, Newtonian physics is wrong but it is workable. With Newtonian physics we can predict the positions of planets over the course of thousands of years. We can land probes on Mars. It is close enough even if it is an incorrect description of the real world.

So, how do we make things work in the real world? In short, through a painful process of trial and error that that has been developed over a span of hundreds, if not thousands, of years. Over time, we have learnt what does work and what doesn’t. An example of this is the Nimrod AEW project that ran in the UK. That project ended in failure. From that failure, the Ministry of Defence (MOD) in the UK developed an engineering management programme (which I was on) to train engineers in how to run projects so that such failures wouldn’t happen again.  Such experiences have been condensed into methods which help us with our understanding of the world. In science the method is the Scientific Method of observation, hypothesis, test, and experimentation with the application of maths and logic. In engineering we have a process of specifications and requirements analysis, proto-typing, top level design, detailed level design, functional design, implementation, and testing (and understanding all this was an important part of the training programme at the MOD when I was there).

These methods are not perfect, not always done in the linnier fashioned suggested and it can require looping back multiple times. We also have monkeys in the loop causing other imperfections. But still, these methods have brought us some degree of success in understanding the world around us and in building things that work (Tacoma Narrows Bridge may have collapsed but countless other bridges stand, some for hundreds of years).

Engineering Defence

We can apply these methods to the military. In deed, we already do when it comes to science. The application of the Scientific Method to the military has been ongoing for hundreds of years (that is why we have a discipline of “war science”).

But we can apply the engineering method to defence as well. A defence force is a system that has to work in the real world. Actually, a defence force is a system of systems of systems (brigades, companies, platoons, pioneer, logistics, to name but a few of the systems). Engineering already has ways to model such complex interaction of systems. We can start with a standard software model using UML. UML is a modeling language composed of diagrams. A UML model sees the system as composed of objects, much like the world around you. It is, in fact, base on how we understand the world around us. So, anything in the real world can be modeled using UML. Each object is an example of a class for that object so that the object is a type (or instance) of class. So, a real physical car is an instance of the class “car”. A real physical ball is an instance of the class “ball”. Or we can say the Volvo I own is a type of “car” and the ball that I kick is a type of “ball”.

In a military context, the 3rd brigade can be modeled as an object of class “brigade”. Anything true for a “brigade” as a class is true for the 3rd brigade as an object.

However, as my background is in artificial intelligence, I would use the concept of multi-agent systems to analyse the defence forces. From a computer science point of view, perhaps an actor model would be useful. The multi-agent and actor model are really equivalent to each other. In both models, the system is seen as composed of actors or agents that do work on a task. They communicate by sending each other messages. Again, this is using ideas that we are familiar with from the real world. For example, a travel agent does work on our behalf when they book a journey for us.

We still have the idea of objects and classes but now a brigade is modeled as having a task to do and it achieves that task by sending messages to battalions. And the battalions send messages back to the brigades. In the real world this message passing is done by sending messages via radio or telephone or even by dispatch riders.

There is a third type of model applicable to the analysis of the defence forces and that is the holonic model. A holonic model captures the system within a system aspect of a defence force as if it was a type of Russian doll. The word “holonic” means “part whole” capturing the idea that an object is in itself an object but forms part of another object and can be composed of objects. An example would be a person where the person’s body is a holon composed of organs which in turn are composed of cells. The person also forms part of a society.

So, a brigade would have inside it a number of battalions and inside the battalion, there are a number of companies and so on. The brigade would form part of something larger, such as division.

All three models can be useful.

Begin at the Beginning

However, a system first needs to be specified before it can be designed and built. This part of the process is important; get it wrong here and the errors propagate throughout the design and into implementation.

Painful experience within engineering has taught that the best way to specify a system is to say what it does but not how it does it. So, for example, if I was to specify the functionality of a keyboard I would say that if I press the “a” key a letter “a” should appear on the screen. What goes in? What goes out? But nothing about how the input is connected to the output. So, nothing about how to identify which key was pressed, nor about how interrupt routines work, nor about which character encoding like ASCII or unicode is to be used, and nothing about buffer sizes. This works well because we have a poor idea how things in the real world work and our ideas about what we want are vague and imprecise, even when we think we know what we want. Coming back to the Dunning-Kruger Effect, when we are confident that we know what we want we are most likely wrong (as we are at the early stages).

The whole engineering process is about taking that vague idea and making it more concrete. We do more detailed analysis. We start testing out ideas by building prototypes and see how they work. When we have a better idea what we want we can start designing. But even at the design stage, details are not yet in focus. So we do a top level (or architure design) and from that we add more details to form a detailed design. The detailed design brings the idea into better focus so we can start a functional design and then start implementing the system. The design stage is important. Design is planning and failure to plan, as the say, is planning to fail. From my experience, failing to design leads to many serious problems with implementation and disasters for software projects. In short; “proper planning prevents piss poor performance”, hence the importance of the UML models above.

At each stage we learn more and gain a better understanding of what it is we are doing. We can then see errors in our understanding. That will often mean we have to back track. From the design we might have to redo part of the specification. From implementation, we might have to redo parts of the design. Until finally we have a concrete implementation which might be different from what we imagined at the start.

The Failure in Defence policy

This is essentially what I feel is has gone wrong with defence; the defence forces are an engineering system but we fail to engineer defence. We have defence decisions that results from insufficient system analysis. We have poor requirements. Design decisions in the specifications. No real or too little prototyping and experimentation to make detailed decisions on.

We have many good ideas for what can be done with the defence but no idea if any of them are workable (even if people think they are) (note, this also goes for me and my ideas and I am criticising myself as much as I am criticising others).

We see the same problem with the proposed defence policy. Design decisions have been made in what should be a specification. We have references to forming light brigades, for example, and details that go down to what equipment and organisation those brigades have. And where do those design decisions come from? Test? Studies? Analysis? Experimentation? Lessons learnt? Where are the requirements? Where are the specifications for the system?

At the level a defence policy, the actual details are still too far away, too fuzzy to start doing design. This is because the defence policy lies at the start of the process not in the middle or towards the end. It is from defence policies that we form defence decisions. From defence decisions we should then design what form the armed forces should take. Then we start building it. Then we can talk about light brigades or not.

Where to go

If we start with a vision; a strong armed forces that is capable of meeting every threat and every challenge. The next thing we need to do is sort out the specification; what would the armed forces need to meet every threat and challenge? From an outside perspective, specifying inputs and outputs with no statements on how.

As a simple example, we could specify that the armed forces would have the ability to stop an invasion of Gotland. The inputs would be ground forces, air force, and navy. They would have to have the capability to stop whatever an enemy force would have (tanks, IFVs, artillery etc.), for example, but we don’t state how (so nothing about having troops stationed on the island or if we should defend the island form the main land or having light brigades or what vehicles they have).  As another example, we could specify that we have to be able to defend against cyber attacks. The input here would be computer equipment and expertise and the output a functioning computer based infrastructure but, again, we don’t specify what computers nor their operating system nor how many experts we would need.

This specification lies high up and at the start of the process. So, this is how we should layout a defence policy at the political party level, even at the defence decision level in the government. It is then the defence forces themselves who have to come back with the how; what type of units, how many, what equipment they will need, and how they are to be utilised, for example.

The author is Dr, BEng(hons) PhD EurIng

References

“The Mythical Man Month” Frederick Brooks https://archive.org/details/mythicalmanmonth00fred
“Object Oriented Software Engineering. Using UML, Patterns, and Java”. Bernd Bruegge and Allen H Dutoit. Prentice Hall. 2004.
“Multiagent Systems”. Gerhard Weiss. The MIT Press. 2013
“Object-Oriented Modeling and Design”. James Rumbaugh et. al. Prentice Hall. 1991
“10 reasons why software development projects fail”
“Psychology. Frontiers and Applications”. Michael W. Passer and Ronald E. Smith. McGraw Hill. 2001.
“Social Psychology”. Jonathan L. Freedman, David O. Sears, and J. Merril Carlsmith. Prentice Hall. 1981.
“Understanding Stupidity” James F Welles, Ph.D.  http://www.mensch.net/stupidity/story2/index2.htm
“Psychology. The Science of Mind and Behaviour”. Richard D. Gross. Hodder & Stoughton. 1992.