COP APPLICATION / Dangers and Guidelines IST-043-RWS-006 / Toronto 15 th September 2004 Olivier de...

COP APPLICATION / Dangers and Guidelines

IST-043-RWS-006 / Toronto 15th September 2004Olivier de Peufeilhoux / EADS

COP Application / Dangers and Guidelines

COP: Common Operational Picture

Goal Dangers

– Excessive modelling

– Insufficient modelling

– Undisplayability Guidelines

– Right level of modelling

– Right complexity of algorithms

– Display best practices

– Architecture


Joint C3I systems / Years of experience

EADS References

SICA, PSP : FRANCE

OFEQ : OMAN

GHQ : UAE

BEMILOPSCIS : BELGIUM

SEDENA : MEXICO


Goal

Not only to allow the sharing of a common view of the situation among the decision makers,

But, above all, to help them to make the right decision while providing the right information at the right time at the right place.

C3I serves the commander but not the contrary


Excessive modelling dangers

Not possible to build a formal modelling for all the data able to be taken into account in decision process of a commander.

Easy to standardize the description of all elementary physical phenomena (location, time, amount)

Not so easy to synthesise these elementary information’s, into few decision enabled ones, (for instance : operational availability status of a unit)

Very uneasy to formalise intentions and behaviours in spite of their major roles in command process.


Excessive modelling dangers

The measured and the true importance of one information may be different.

Some small details could have strategic interest

Automatic computation of synthesis may erase relevance.


Insufficient modelling dangers

The simple use of COTS products (office tools) to manage and exchange operational information, combined with linguistic diversity within a multinational coalition headquarters , leads to informational anarchy:– Redundant information’s,

– Inconsistent information’s,

– Unqualified information’s.

Major risk of decisional hegemony if the only response to this diversity is the standardisation of all technical solutions and procedures towards a unique system.


“Undisplayability” dangers

The simple accumulation of any available information as different icons on a map leads to : – a beautiful “abstract art” picture

– but not to an operational one.

Danger of information overflow if no filter is applied on available information.

Depending on the user, the context and the time, only a subset must be displayed to be relevant. And within this subset the display rules may be adapted for each use.


Guidelines

Fully theoretical approach quite sterile and may lead to dead end, after numerous and tiring discussions about such bla-bla sentences

Pragmatic approach, based on true experiences and leading to concrete guidelines, only able to improve COP application in C3I systems.

Profitable to study and to experiment similar processes and applications used in civil world (stock exchange dashboard, executive managers dashboard, ...).


Right level of data modelling

Separate, within object description:–part able to be formalised (type, location, time, amount, …)

– part not able to be (intention, behaviour, …)

Complete formal description by simple text (comments) and/or links to office files (documents, pictures, …).

OfficeDocument

Jane’sLibrary

Video File

Image File

Audio File


Right level of data modelling

Reuse, for formal description, experienced data model like C2IEDM (from ATCCIS), based on “5W approach”:

Who (object identity) What (object type) Where (location) When (time) Why (context)


LC2IEDM example

OBJECT-TYPE OBJECT-ITEM

FACILITY-TYPE

FEATURE-TYPE

ORGANISATION-TYPE

PERSON-TYPE

MATERIEL-TYPE

FACILITY

FEATURE

ORGANISATION

MATERIEL

Off. : 34S/Off. : 72MdR : 112

F910 Wielingen

III

XX

DZ

Who ? and What ?


LC2IEDM example

Where ? and When ?

OBJECT-ITEM

LOCATION

REPORTING-DATA

XXX

XXX

XXX

XXX

1

23

4

CONTEXT

OBJECT-ITEM-STATUS


Right complexity of algorithms

Separate common “validated” documents (current situation) and personal documents (reports, forecasts, …),

Combine use of RDBMS requests on formal description and use of a common request engine for informal description.

Stay modest for decision help algorithms. Limit them to “highlighting” of unknown, unrecognised, ….


Display best practices

Allow simultaneous and independent viewpoints on the same information:– geographical viewpoint : icons on a map,

– organisational viewpoint : hierarchical tree,

– chronological viewpoint : bars on a timescale,

– technical viewpoint : bars on a histogram.


Display best practices

Give access from operational presentation to all complementary information’s through clicks (“COP portal”)

Allow each user to define its own “display profile” based on editable requests to get the CROP “Common Relevant Operative Picture”.

ConsultationConsultation

COPPortal

click

Other informations


Architecture

Concurrent design on three levels : database, tools, user,

Generalize distributed architecture model with:

Low level of coupling between different tools,

Independence from database schema, “Services approach” at user level

including a “publish/subscribe” mode to combine “common” and relevant


Decision making : today and tomorrow

COP APPLICATION / Dangers and Guidelines IST-043-RWS-006 / Toronto 15 th September 2004 Olivier de...

Documents

Transcript of COP APPLICATION / Dangers and Guidelines IST-043-RWS-006 / Toronto 15 th September 2004 Olivier de...