What is commonality?
An interesting question in its own right, the dictionary definition is
The state of sharing features or attributes.
In a defence context, this means sharing methods, training, procedures and equipment. Commonality in equipment can exist at the system, subsystem or component level. For example, the Army has a number of variants based on the Warrior infantry fighting vehicle, the Royal Navy makes use of the Artisan radar on multiple types of surface vessels and the Royal Air Force uses the same Paveway IV bomb on both the Typhoon and Tornado.
Why do we bother with commonality?
At a fundamental level, we strive for commonality because it reduces cost through a broad number of mechanisms.
The first is economy of scale; if the RAF, RN and Army all use the same personal weapon then the overall pool of personal weapons is larger than if all the services went their own way. A larger overall pool allows us to take advantage volume discount. Research and other setup costs can be shared across a larger number of units and thus more readily absorbed.
Commonality can dramatically reduce through life costs and it is here where the advantages of commonality can be especially realised.
Consider a weapon to be the tip of a triangle.
Sitting underneath the tip is a range of additional ‘stuff’, ‘stuff’ that all costs money.
Project teams at DE&S, support contracts with suppliers, storage of spare parts, the spare parts in sufficient quantities themselves, operating, safety and maintenance documentation, maintainers, training courses, training courses for the maintainers, pensions for everyone involved, space on ICT infrastructure, legal and commercial governance for the support contracts, office space for the project team, lawyers and other support staff, disposal costs and about a million other things that are needed to maintain a single piece of equipment in the field.
When that equipment is in the field, it has to be transported there and when it is there it has to be supported. Considering a relatively simple piece of equipment like a truck, it will need tires, lubricants, filters, wear parts and other consumables such as indicator light bulbs or fuses. Throw in repairs and more involved maintenance tasks and the item count starts to rise dramatically.
If you chose to have dissimilar equipment doing similar things you start to erode the benefits of commonality.
Multiple triangles and increased costs.
Commonality isn’t free, whilst you might be able to specify the same fibre optic connectors or door fittings on all Royal Navy ships through careful design choices underpinned by defence standards, it might be quite costly to dictate to Rheimetall/MAN that they use the same indicator light bulbs on their trucks as Oshkosh do on theirs. The costs of commonality, in this case would, probably outweigh the savings of doing so.
It might also mean making decisions before they are due or withdrawing equipment before it’s out of service date. Other times it is probably not a good idea and commonality sake for commonality sake is just as bad as not striving for it in the first place.
Putting in place enablers like standards is a good idea but not if they contradict others for little or no benefit because all this does is, add costs all round. Stovepiped projects and decision making often conspire against commonality, especially where our general approach to specifying equipment is to define a requirement i.e. avoiding that horrible word, ‘solutionising’.
The process of bringing new equipment into service includes a consideration of the so-called ‘Defence Lines of Development’ that includes logistics and support costs and other considerations that would ideally encourage commonality, but even with that, decisions are still made that result in sometimes inexplicable situations where we have the exact opposite of commonality, leading to a head scratch moment, and a question that sounds something like;
How the bloody hell did we get here?
Commonality is a moving feast, with hundreds of thousands of different pieces of equipment in service at any one time it would be foolish to try and achieve it all at once and as a new component or system comes into service because it offers significant advantages over the preceding item, the old item must eventually go out of service. The desire for commonality cannot be so overwhelming that it retards progress either.
But even accepting the many barriers to achieving commonality, in the round, it is basically a good idea and one we should continually strive to achieve.
This is topical because of two contracts announced in the last couple of days, one that looks sensible from a commonality perspective and the other that has me scratching my head and asking;
How the bloody hell did we get here?
The first is for the RAF’s Watchman radar that is part of the larger PROJECT MARSHALL for the future delivery of military terminal air traffic management. It is a large project being led by Aquilla, a 50/50 joint venture between Thales and NATS.
The Watchman radar forms an important part of the overall military traffic management system and in a £7m contract announced this week, BAE will provide a range of upgrades. This is relevant to the discussion because they will use a number of components such as transmitters and signal processing modules from SAMPSON and ARTISAN. Subsystem and component commonality in action, with an estimated spare parts reduction of 80%. Using a SAMPSON radar in order to maximise commonality would be silly, but reusing components and systems that have been developed for SAMPSON in order to improve Watchman (and address 4G interference issues) seems like a great example of sensible commonality in action.
One the flip side, are a pair of contracts in the maritime mine countermeasures area.
As part of the Royal Navy’s wide-ranging programme of future mine countermeasures the MoD has issued two contracts, one to Thales and the other to Atlas Elektronik (full details here). The Mine countermeasures and Hydrographic Capability (MHC) is in the early stages of the Assessment Phase so nothing yet is firm, and there may well be some changes in the final deployed system. To get to the point, there are two contracts that both use an unmanned surface vessel for sweep and operation of unmanned systems.
One uses an 11m twin engine twin waterjet boat and the other uses a 10.8m twin engine twin waterjet boat.
Both launch and recover various systems from the stern, operated in manned or unmanned modes and be transported by C130. One was built by ICE Marine and the other ASV, one has Yanmar engines, the other, doesn’t.
Can you see where I am going with this?
There are also a number of Combat Support Boats (CSB) already in service. The CSB is slightly smaller at 9m but was used for the SWIMS MCM UOR in Iraq in 2003, oh, and has twin engines and waterjet’s. The CSB may well not have been the ideal platform for launching and recovering sweep and unmanned systems over the stern but could we at least not have specified that they both new boats use a common boat design, or at least common components such as engines and propulsion systems?
Because we are still in the assessment phase for MHC it is not a certainty that the ARCIMS and ASV craft will enter service as they are, but why bespoke designs, the UK is awash with small work boat designers and manufacturers?
Could the final implementation use a single boat design with the same Yanmar engines and Hamilton waterjets as the Combat Support Boat, or would commonality with the Royal Navy Pacific 24 RIBS be more appropriate, they also use Yanmar and Hamilton equipment as it happens?
Or, maybe two boat designs with major components from the same manufacturer (Yanmar and Hamilton for example) is the best solution?
I would hope this is being thought about as MHC progresses.
Commonality is a complex business isn’t it!