COP APPLICATION / Dangers and Guidelines IST-043-RWS-006 / Toronto 15 th September 2004 Olivier de...
-
Upload
benjamin-wilkins -
Category
Documents
-
view
226 -
download
1
Transcript of 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
Page 2 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
Page 3 COP Application / Dangers and Guidelines
Joint C3I systems / Years of experience
EADS References
SICA, PSP : FRANCE
OFEQ : OMAN
GHQ : UAE
BEMILOPSCIS : BELGIUM
SEDENA : MEXICO
Page 4 COP Application / Dangers and Guidelines
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
Page 5 COP Application / Dangers and Guidelines
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.
Page 6 COP Application / Dangers and Guidelines
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.
Page 7 COP Application / Dangers and Guidelines
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.
Page 8 COP Application / Dangers and Guidelines
“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.
Page 9 COP Application / Dangers and Guidelines
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, ...).
Page 10 COP Application / Dangers and Guidelines
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
Page 11 COP Application / Dangers and Guidelines
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)
Page 12 COP Application / Dangers and Guidelines
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 ?
Page 13 COP Application / Dangers and Guidelines
LC2IEDM example
Where ? and When ?
OBJECT-ITEM
LOCATION
REPORTING-DATA
XXX
XXX
XXX
XXX
1
23
4
CONTEXT
OBJECT-ITEM-STATUS
Page 14 COP Application / Dangers and Guidelines
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, ….
Page 15 COP Application / Dangers and Guidelines
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.
Page 16 COP Application / Dangers and Guidelines
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
Page 17 COP Application / Dangers and Guidelines
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
Page 18 COP Application / Dangers and Guidelines
Decision making : today and tomorrow