top of page
Line Concept Level 3 page 2.PNG

The Devil’s Advocate: Common Operational Picture (COP) — S.C. Collective

In this post, S.C. Collective assumes the role of the ‘devil’s advocate’ and challenges the military’s beatification of the Common Operational Picture (COP) as a concept and technology.

The Advocatus Diaboli (Latin for Devil’s Advocate) was formerly an official position within the Catholic Church: one who “argued against the canonization (sainthood) of a candidate … to uncover any character flaws or misrepresentation of the evidence favouring canonization”. In common parlance, the term devil’s advocate describes someone who, given a certain point of view, takes a position he or she does not necessarily agree with (or simply an alternative position from the accepted norm), for the sake of debate or to explore the thought further.Wikipedia

First, a definition from doctrine: “Common Operational Picture – A single identical display of relevant information shared by more than one command that facilitates collaborative planning and assists all echelons to achieve situational awareness. Also called COP.”

So, what is wrong with this definition? Well, the Common part, the Operational part, and (predictably) the Picture part.

The Common part, especially the “single identical” truth concept, sounds good until you examine the unintended consequences. To establish commonality, everyone needs to have all the information. That is clearly problematic when operating in constrained and contested networking environments, but it also implies some centralised decision making and likely centralised fusion to determine what everyone should see. Different crew members on the same jet don’t have identical displays, so why would we want it across commands? The concept of common also conflicts with security compartmentalisation, so we end up with COP-like systems at multiple independent levels of security (i.e. not common).

The Operational part is perhaps less problematic if you’re working at the operational level. However, most of us aren’t – we’re working at the tactical level. Those of us conducting the “collaborative planning” work in the Targeting and Master Air Planning processes in the Air and Space Operations Centre (AOC) aren’t really that concerned about what is currently airborne. That makes for a small operational audience (basically only the Combat Operations Division). Further, the current implementation of the COP (notionally based on aggregating Recognised Air Picture, Recognised Maritime Picture, the Wide Area Surveillance Picture and Regional Area Surveillance Picture and a spare plug for the Recognised Land Picture) is completely platform-centric, whereas the operational level should be focused on effects.

The Picture part is arguably the worst aspect of the COP because focusing on portrayal constrains our thinking – icons on a digital map is not much progressed from the WWII manual plots.

The Operations Room at RAF Fighter Command's No. 10 Group Headquarters, Rudloe Manor (RAF Box), Wiltshire, 1943. © IWM (CH 11887)

The Operations Room at RAF Fighter Command’s No. 10 Group Headquarters, Rudloe Manor (RAF Box), Wiltshire, 1943. [Image Credit: © IWM (CH 11887)]

That ‘icons on the map’ view focusses on platforms rather than effects and does not provide a meaningful way to show communication links, electromagnetic spectrum usage, information operations, or cyber considerations. It also limits what can be displayed to available screen space. The primary COP source (for the ‘as built’ system) could provide significantly more information, but is filtered at the source. As the complexity of the environment and sensor capabilities increase, we will need to throw increasing larger amounts of information away to avoid making the picture opaque.

Even a limited display is often hard to understand – turning coordinates into icons on the map doesn’t make it information. Instead, we need that data to drive decision support tools and provide cueing and targeting assistance – ideally autonomous, but not retyping the coordinates would be a step forward.

Sample tactical graphics display, with at least one hostile displayed. [Image Credit: Supplied by author]

Sample tactical graphics display, with at least one hostile displayed. [Image Credit: Supplied by author]

Even et Diabolus would concede that the current COP does support filtering and some analysis – it is not just a picture. However, to the extent that we know how to get something useful out of it, we often don’t. Perhaps that is because of the name – we think of it as a picture to fill half the big display at Joint Operations Command, not a tool, and certainly not as task-relevant information.

With these issues in mind, what should we look for instead? As the Advocatus Diaboli, my aim with this post is not to provide a better solution; however, if we want to support collaborative planning and situational awareness, then our priorities might include:

  1. Crew and user specific task-related information, rather than commonality.

  2. Implications: The system needs to understand each users’ task context and what data would be relevant to those tasks, and to present the relevant data elements in a way that makes sense to the task(s).

  3. Data for decision support tools and user views of networks and effects, rather than a single (picture) portrayal of platforms.

  4. Implications: We need to agree on open standards for data models, and protocols for exchanging that data, not just a standard set of icons.

  5. Prioritising near over distant, and aggregating distant things, rather than treating all information the same way. This is in accordance with Tobler’s law: ‘everything is related to everything else, but near things are more related than distant things’. In geospatial terms, these distances are in metres; in network terms, they are in milliseconds.

  6. Implications: We need a system architecture that provides decentralised fusion and aggregation, to support decentralised execution, and to manage throughput in a congested or contested network connection when things are getting emotional. This requires adaptive rules for filtering; policy for when and how aggregation can support security outcomes for “special” capabilities; and detailed understanding of how the filtering and aggregation affect decision support tools.

  7. Alerting of exceptions, rather than providing ‘as expected’.

  8. Implications: System definition of what is exceptional given the operational context, and the level of alerting that is appropriate given the user needs, network capability and the other alerts.

Once we have all that, we can find a better name.

The S.C. Collective is a self-synchronising (sometimes only plesiochronous) independent thought activity with a penchant for Old Horizon Fridays. Current focus activities include integration of ISR with non-kinetic effects.


bottom of page