The Combat Cloud
Most readers will have heard or read discussions about the ‘combat cloud’.
Like the white fluffy things from which its named is derived, the combat cloud can seem to be an ethereal thing – composed mostly of vapour and not necessarily establishing solid foundations upon which to build.
That is a shame, particularly for the Australian Defence Force and Australia’s defence industry, because combat clouds are potentially a critical element in Australia’s realisation of a truly integrated force that can genuinely punch above its weight.
So, how do we define what a combat cloud is? Borrowing from its commercial progenitor, the combat cloud conveys a system in which data is pooled and is available from this via a number of different means. The essence of the ‘cloud’ notion in combat cloud is that a user is not dependent upon information being pushed to them via a specific means; they are connected to the cloud via whatever means they have at their disposal, and can pull data they are authorised to see as and when necessary.
This aspect is only part of the story though. The combat cloud terminology may suffer from being an idea that is a little before its time, as the more recent notion of an ‘internet of things’ is a more appropriate descriptor for what people seem to be trying to achieve with the combat cloud.
The combat cloud is not just about smoothing the passage of information in the way that Dropbox or iCloud does for its users. Instead, the concept of the combat cloud is about sharing information and resources across a networked force in a manner than allows the information and resources – sensors, weapons, processors, and deciders – to be optimised for the task at hand.
This is more akin to a combat internet of things than a combat cloud, because a user can control and exploit resources anywhere on the network, not merely access the information available on the network.
Much is made of the F-35A’s own and multi-ship fusion capabilities that enhance its ability to locate, identify, and track targets. This is indeed impressive, but the combat cloud allows this fusion effort to be scaled up exponentially. Instead of the data collected by the F-35A’s sensors being processed solely onboard, it can also be pooled with information from the E-7A Wedgetail, Hobart-class DDG, EA-18G Growler, MQ-4C Triton, Jindalee Over-the-Horizon-Radar (JORN), and orbital sensors, and then processed in server racks onboard a nearby orbiting KC-30A tanker to generate a high-fidelity multi-source track.
The combat cloud concept matters for the ADF because it has the potential to enhance a small force’s lethality, survivability, resilience, and efficiency. The combat cloud has the power to enhance the ADF’s potency by allowing engagement at greater ranges, using a greater array of weapon systems from potentially unexpected aspects. Physics dictates that an aircraft can only carry a limited number of missiles of a certain size, and that the more missiles the aircraft carries, the larger its signature becomes and the less distance it can travel. But in a combat cloud, the aircraft is not dependent upon the weapons it carries.
Instead, it can call for fires from weapons on any of the platforms available in the network.
In this instance, an F-35A called on land-based long-range surface-to- air missiles (SAM) to engage targets far beyond the horizon of the ship’s own sensors. The SAM battery’s crew, coordinating via datalink with the F-35A formation, swap the explosive warheads on several missiles for a microwave attack system designed to disable electronic systems and arrange to fire two salvoes.
The first salvo of explosive and microwave weapons is fired, intended to disrupt the enemy strike package. Meanwhile, a second salvo of weapons flies to programmed waypoints to await updated targeting information from the F-35A.
The first salvo does its work and the second salvo, approaching from a different aspect, targets remaining high value targets thanks to updated information from the on-scene F-35A. The enemy’s inbound strike package had no idea what hit them.
There were no emissions until aircraft started exploding or falling out of the sky with malfunctioning electronics.
In many ways, it was the combat cloud that hit them because the combat cloud had enabled crumbs of information from multiple sources to be fused into robust tracks. Aside from low probably of intercept/low probability of detection datalink transmissions, neither HMAS Hobart nor the F-35A force emitted at all during this engagement.
The F-35A’s targeting data was derived from its own impressive onboard systems but was also fused – in server racks onboard a KC-30A refuelling a pair of Growlers – with sensor information from offboard systems. This was important as the F-35A force had detected the incoming enemy aircraft minutes earlier but could not identify them without giving away their own presence.
The cloud’s resilience had also been on show. The processing performed onboard the KC-30A was usually done in server rooms located in Canberra via satellite communications.
But a Carrington Event the year before this story had disrupted most satellite communications. Enemy counter-space operations leading up to the attempted strike had compounded earlier problems. But due to the combat cloud, commanders had been able to divert processing power from routine activities towards the fusion of fragments of information from numerous sources to derive a sufficiently clear picture. The only element of this that had been ‘by design’ was the flexibility in the system to rapidly re-orient.
Efficiency had also been optimised due to the combat cloud. HMAS Hobart’s long- range SAMs were closer to the inbound strikers, but the cloud had recommended to the area air defence commander aboard an E-7A Wedgetail that the DDG’s weapons be preserved for defence of the amphibious task group she was escorting. Besides, the upgrades to allow HMAS Hobart’s crew to swap out warheads were not due to come online until next year, and the enemy’s single axis formation presented an opportunity to disable multiple targets with a limited number of non-kinetic payloads.
The efficiency had also been apparent in the cloud’s optimisation of sensor allocation. Instead of the Wedgetail’s MESA radar radiating continuously, the cloud’s processing had identified the few targets that other sensors had been unable to identify and directed pulses of the MESA radar onto those targets, and those targets only, until they were identified sufficiently.
Moreover, the smarts of the combat cloud allowed the battery commander to launch dumb weapons, preserving her active radar-homing missiles for subsequent missions. The fidelity and granularity with which the combat cloud could resolve targets, and the assuredness with which weapons could be guided to the target via a variety of data links, meant the weapons themselves could simply do as they were told until impact.
This key breakthrough had enabled the rapid warhead swap as the missile’s payload would not interfere with a delicate guidance system. Of course, most of the above is fiction. The ADF will have a HMAS Hobart, F-35A, and land-based SAMs, but otherwise this is a made-up story. But it does not need to be.
This fictional combat cloud vignette illustrates why the combat cloud is more than an easily accessible data swamp, and why it offers such potential for the ADF’s realisation of an integrated force. Like its real-world namesake, the combat cloud presents an outside observer with a seemingly unified and impenetrable mass, with untold latent potential.
This is precisely why Peter Layton felt the combat cloud was “perhaps better named a ‘combat thunderstorm’, hurling destructive lightning bolts from any part of the cumulonimbus.”
The ADF and its industry partners have a unique opportunity to drive towards a combat cloud. The ADF’s highly capable mix of USAF, USN, and bespoke equipment on a relatively small scale means it is well placed to tackle the challenges of integrating weapons systems with fundamentally different, and often hostile DNA. Proprietary, security, and other regulatory controls on information sharing must be overcome.
However, this presents an opportunity for Australian industry to present itself as an impartial broker, one that can potentially find a way to bridge the divides that arise between industry primes’ valuable intellectual property, the need for security, and government’s desire to control the release of sensitive information.
In an insightful study on battle network competition in the twentieth century, the US-based Center for Budgetary and Strategy Assessment identified that as competitions went on, the rate of change accelerated until the fundamental character of the competition was disrupted.
Realising the combat cloud’s vision is essential if the ADF and its partners are to realise and maintain comparative advantage.
A combat cloud that delays or precludes the integration of a new sensor, weapon, processor, or algorithm due to integration delays, is the combat cloud that the enemy in our scenario possessed. The results speak for themselves.
This article was originally published in ADBR March/April 2018 edition.
Wing Commander Chris ‘Guiness’ McInnes is an officer in the Royal Australian Air Force. The opinions expressed are his alone and do not reflect those of the Royal Australian Air Force, the Australian Defence Force, or the Australian Government.
First published by Central Blue on June 24, 2018.
And the following comments have been made on The Williams Foundation website and provide insight into the discussion.
Byron Reynolds 24/06/2018 at 10:57 pm
I think you’re right that the concept envisaged by the ‘combat cloud’ is not directly analogous to cloud computing, but I’m not sure that the Internet of Things (IoT) comparison is entirely valid either. IoT is a relatively dumb concept, by which I mean the devices in IoT are reliant on something else to do the processing of any data obtained/created.
What the ‘combat cloud’ really seeks to implement is ‘edge computing’ or ‘fog computing’ where processing is distributed to the devices/nodes and shared at a layer closer to the edge. This increases processing speed and allows the very redundancy you have proposed in your vignette.
This semantic question is important, because it allows us to clarify where the processing and decision-making is being done. Rather than some nebulous concept like ‘the cloud’ conducting algorithmic activities such as sensor allocation, track fixing and identification, weapon recommendations etc, those decisions will be made at a node.
As with all machine learning and AI, we are a long way from implementing algorithms that have sufficient transparency in their learning and consequent decision-making. By having those activities conducted as a human-machine partnership, the human at the node will better understand the processing and retain whatever oversight is deemed necessary (or, indeed, legal).
(Post-script: This is not specifically an argument for maintaining manned aircraft, though. CAOC, DGS, AEW&C etc are all options for relocating human decision makers to a node where they can best supervise AI-enhanced decision-making)
Guy Reeve 25/06/2018 at 11:58 am
Great article @Chris McInnes, and well observed comment by @Byron Reynolds re processing on the node. The combat cloud can give life to the concept of ‘data as a weapon’: it will need to get the right data to the right person and/or platform/system, in real time, and securely – which an easily accessible ‘data swamp’ is not capable of doing.
Industry is ready, wiling and able to take on the challenge of integrating “weapons systems with fundamentally different, and often hostile DNA”.
A key component that will be required to give life to the combat cloud is an ‘agile data integration backbone’ or ‘data hub’ able to ingest multiple sources of disparate data, in real time, and push/publish it to those entities/actors that need it or have subscribed to it.
It will be important to manage this data not just in real time, but throughout its life cycle, including some or many years after an event/incident (viz current prosecutions in UK of soldiers serving on Op BANNER in Northern Ireland in the 1970s. We’ll surely see the same sort of inquiries following Op SLIPPER/HIGHROAD).
Given the nature of modern warfare and the potential for civilian casualties, there will always unfortunately be a requirement for forensic diagnosis of decision making in theatre. Such after-action review (as well as for lessons-learned purposes) will need to be able to see what data was available to a commander at a specific point in time. This is particularly important in a dynamic environment in which data is constantly being updated, both manually and, increasingly, automatically.
The good news is that operational data hub architectures are proven and at least one technology platform exists which can achieve the tasks of both challenging real time operational data fusion and provisioning requirements as well as those of lifecycle information governance.
A successful sound data hub platform will need to provide a range of capabilities:
– appropriately performant in real-time, mission-critical solutions,
– assuring defence-grade security – down to element level – and ‘anti-Snowden’ encryption,
– be able to deal with high-precision geospatial (nanometres) data (including high precision fusion of track and target data),
– temporal/bi-temporal (ie what did we know at a particular point in time), and perhaps most crucially,
– flexible replication to allow for data to be accessed and processed ‘at the tactical edge’ – or ‘on the node’ – be that a ground force headquarters, or an airborne or maritime platform, in an contested, disrupted comms environment,
– low compute platform requirements (ie easily deployable on a small footprint in mobile, ‘edge node’ platofrms),
– flexible deployment, and easily scalable to meet changing mission requirements,
– provide OWL/RDF semantic capabilities to enable smart, intelligent and/or automated solutions.
Flexible replication is key: force elements must be able to deploy with a ‘mission information payload’, have prioritised synchronisation within (changing) bandwidth constraints, as well as be able to continue to operate and process data in disconnected mode.
This latter requires the ability to instantly synchronise the latest, authoritiative situational awareness data in real time as soon as comms are re-established, so that the commander and/or weapon system operator has absolute confidence that they are looking at the current COP, not a version from minutes or hours previously.
The technology and architectures exist which can deliver against these challenging requirements: what is required to fill the current data integration capability gap is strong leadership, a good awareness and understanding of modern technology architectures and platforms and a commitment to an iterative, evolutionary development path which can start small, demonstrate what can be achieved, and rapidly scale up.