1. International Defence Enterprise Architecture Specification (IDEAS)
Analyzing and Presenting Multi-Nation Process Interoperability Data for End-Users
20 February 2008

2. Experiment & Exercise Overview Components of the IDEAS Project
Briefing Outline
IDEAS Overview
Experiment & Exercise Overview
Components of the IDEAS Project
Data
Methods
Presentation

3. The IDEAS Group
International Defense Enterprise Architecture Specification for exchange
Australia, Canada, UK, USA
Sweden & NATO (observers)
Established 2005
Objective:
To deliver a unified specification for the exchange of military architectures between coalition partners.
A formal ontology is being employed as a foundation
Often in international missions it is valuable to be aware of any process dis-interoperabilities prior to mission commencement. For example, for Coalition Operations, it is important to know how battlefield casualties will be handled by the participants, in the event one’s own casualty soldier is being taken care of by another nation’s medical corps, or vice-versa, where one is caring for another nation’s casualty. There may be legal and cultural requirements, notification, reporting, timeline, or event response expectations, and so forth that we would not want to discover during the mission, but, rather, be aware of ahead of time so the processes can be adjusted or so that commanders are aware of how their casualties will be taken careof and can adjust their expectations. The United Kingdom, United States, Canada, and Australia are working on just such an experiment as part of the International Defence Enterprise Architecture Specification (IDEAS) project. While the focus of the project has been on the architecture data ontology, there is also recognition that the process mismatches need to analyzed and displayed to commanders in a way that alerts them to significant issues and that makes their jobs of planning for the Coalition mission easier and more thoroughly thought through. This presentation reports on IDEAS experimentation progress to date, describes analysis algorithms being worked on, and shows various notional and real presentation options that would be meaningful and useful to commanders. It describes issues in multi-source EA data analysis and possible remedies. Issues with end-user display of multi-source EA data analysis results are also discussed along with various alternatives being experimented with by the IDEAS project.

4. Side Benefits
UK and US requirements for standard dictionaries to support MODAF and DoDAF architectures
MODEM and DoDAF Conceptual and Logical Data Models
Plan is to leverage the IDEAS model to provide the top level of the ontology
Interest in ontology is developing all over Govt.
Usage being investigated for data integration in Logs and Casualty tracking – i.e. the benefits and possible uses go well beyond enterprise architecture
Possible interest for operational data, e.g., Situation Awareness and Coalition sensor and data fusion to collaborate on derivation of such

5. Military Utility - Current Experiment
Objective
Show relevance to procedures, tools, methods, etc., that coalition operations planners would actually use
What aspects of interoperability is this experiment series focused on?
Nations agreed on a Military Casualty Management example scenario.
There have been issues in recent years, e.g., Scud attack on US barracks in Desert Storm
Compare and contrast coalition processes (not technical)
Process data flow (OV-5) and Event Trace/Sequences (OV-6c) data.
How does such an exchange help a coalition ops planner?
Brings out unknowns ahead of time, e.g.:
CM reporting and timeline differences
needed data exchange
CM assets sufficiency
process / business rule differences

6. Components of the IDEAS Project: DATA

7. What Makes IDEAS Different ?
Foundation Layers
Foundation based on Set Theory
Traditional data modelling is generally not founded in mathematic principles
IDEAS uses formal set theoretic tools to accurately represent the structure of real-world concepts
Next – common patterns based on the foundation
Next – domain patterns that specialize the common patterns
BORO Methodology
Relies on the only thing that is irrefutable, the physical extent of something
All analysis is rooted in 4D spatio-temporal “individuals” that are instances-of Types
Naming Pattern
Allows separation of linguistics from semantics

8. Example of the BORO Process

9. The Naming Pattern The Naming Pattern
It is useful to ignore names when developing the ontology, as they carry too much baggage and confusion – people tend to cling onto names of things rather than trying to work out if things are the same or not
It brings in the opportunity for international coalition interoperability
Once the semantic de-confliction is done, the names can be re-assigned, in context of their owners – and this is how interoperability is achieved
Enables stakeholders to continue working with their own terminology

10. Foundation Top Level Everything’s a Thing:
Individuals that have spatio-temporal extent
Types that are sets of Things
Tuples that relate Things in a specified manner (tuplePlaces)

11. Foundation: Key Objects in the Common Patterns – All Specializations of Couple (a type of Tuple)
A special type of membership where a set is an element of a some other set (or class, to be more precise), e.g.,
The set of Government workers is an element of the set of worker types
Can be thought of as the way to say set membership, i.e., aÎ{A}
one tuplePlace points to the element
the other tuplePlace points to the set
Can be thought of a subset, e.g.,
F-18 (type) is a subset of the set of Fighter (type) is a subset of the set of Aircraft (type)
Means the 4D spatio-temporal extent of the Part is contained within the 4D spatio-temporal extent of the Whole

12. Sample EA Domain Patterns: Familiar EA Constructs Specialize the Foundation and Common Patterns

13. Components of the IDEAS Project: METHODS OF ANALYSIS

14. Many Aspects of Interoperability – Not Just Electronic Communication
PROCEDURAL/DOCTRINAL
Interoperability
Tactics, Techniques and Procedures (TT&P), Training
PHYSICAL
RF Waveform
Modulation
Compression Technique (JPEG, etc.)
DATA TRANSFER
Protocol (Pull, push, etc.)
Bulk/Change
Publish/Subscribe
etc.
SECURITY
Crypto (Procedural)
Over the Air Rekeying
Sanitizers
MLS
DATA FORMATS
Bit oriented Formats (TADIL A, J, K, etc)
Character oriented Formats
USMTF
HTML, XML, XSI, etc.
Air control procedures (Navy vs. Air Force)
Tactical datalink conops, etc.
Joint/Coalition tactics and training
Joint/Coalition C2W (mop 6, 30)
Joint surveillance Conops (IFF, etc)
etc.
PRESENTATION
Symbology
GIS types (e.g., PPI vs map/chart)
Filtering
Formats
INFORMATION SEMANTICS
Battlespace Objects (e.g., GCCS and Combat System “track files” vs analysis data like ASAS vs. IEW data)
Prior Intelligence (e.g., OOB vs. IPB, Characteristics and Performance)
Geophysical (e.g., NGA vs. tactical)
Logistics (e.g., field vs. “reachback”)
etc.
ALGORITHMS
Tracking and correlation algorithms
Target ID
SYSTEM
Interoperability

15. Examples of Interoperability Analyses That Could be Done
Doctrine mismatch
Tactics, techniques, and procedures
Training and skills mismatch
Systems mismatch
Communications
Processing
Data formats
Capabilities gaps and overlaps
Scope for ’08 experiment

16. Initial Idea – Compare Doctrines
Went down this path for a while but then,…
Looking at recent CM “lessons learned” led us a different way, e.g.,
Scud missile attack on US barracks near end of Desert Storm

17. Background and Categories of Lessons Learned in Report
An Iraqi scud missile strikes a warehouse at U.S. Aujan compound in Saudi Arabia
Lessons Learned Categories
Planning
Communications
Coordination
Reporting

18. Planning and Comms Lessons Learned
Casualties removed randomly
Barracks mistaken for hospital
No landing site for Evacuation helicopters
Casualties not taken to U.S. facilities
Weapons and personal items secured by Saudis, not U.S.
No emergency plan in place
Communications
Saudis only communicated within their own network
Soldiers removed without U.S. notification
No direct communication existed
U.S. Army and Saudi ambulances had no radios
Evacuation helicopters had no contact with Medical Group communications center
No communications plan in place
Planning
• Within minutes of blast, Saudi civil defense system was activated. Saudi ambulances were randomly removing the living and the dead into the Saudi trauma system.
U.S. Army bus left Aujan with four wounded soldiers for an Army hospital. The vehicle mistakenly arrived at a barracks, not a medical installation (the building had once served as a clinic and sported a large Red Crescent on the outside).
• As the first Army medical Evacuationuation helicopter landed at Aujan, no landing site had been planned or marked; the wash of the blades sent shards of glass, metal, sand, fiberglass, and debris everywhere.
• The majority of US casualties were taken to the local Saudi trauma center, not U.S. facilities
Weapons and personal items were secured by the Saudi hospital staff, not U.S.
• The survivors of the attack had nothing to help the wounded. Bandages, splints, and dressings were not available. Unit members were unaware of an emergency plan. The location of a landing zone, protection of the perimeter, self-defense, and chain of command initially did not happen.
Communications
• The local Saudi civil defense system responded but was only communicating within its own network.
• Many Saudi ambulances were on site and removing soldiers before the U.S. military was even notified.
• Calling between the civilian and military communities was problematic. Direct communication was impossible.
• Army ground ambulances did not carry radios.
• Not all Saudi ambulances had radios.
• Medical Evacuationuation helicopters could communicate with their headquarters but not with the 173rd Medical Group communications center.
• There was no plan regarding how all of the potential participants would communicate.

19. Coordination and Reporting Lessons Learned
U.S. and Saudi hospitals had disparate disaster plans
Many casualties initially unaccounted for
No coordination between military and civilian assets.
No civilian understanding of military concept of echelons of care.
Reporting
U.S. military not contacted for 22 minutes after attack
Families learned of attack via media
Delays in notification of status to families
Casualties unaccounted for at least 48 hours
Coordination
• Both U.S. and Saudi hospitals were working on their own disparate disaster plans
• During the initial hours after the attack, it was impossible to account for all of the wounded, seriously ill, and very seriously ill personnel.
• No joint planning or coordination occurred between military and civilian assets.
• Civilians did not understand or utilize the military concept of echelons of care.
Reporting
• Call that would bring U.S. military support and air ambulances to the scene was not phoned in until 22 minutes after the blast.
• Cameramen from CNN broadcast to the United States that a scud had struck an Army Reserve unit before military authorities in Saudi Arabia could respond. Soldiers could quickly phone home to reassure worried families, but the dead or wounded could not call.
• The casualty reporting system could not keep up with this instantaneous communication. For many families, the delay in notification of the status of their loved ones for additional days brought added hardship.
• The location of all of the casualties was not known for at least 48 hours.

20. What Architecture Datasets Might have Illuminated these
EA Datasets
Lessons Learned

21. Components of the the IDEAS Project: PRESENTATION

22. Coalition Ops Planning Processes “As-Is”
AUS Plan
CAN Plan
GBR Plan
USA Plan
etc.

23. They See Differences in Process
Canada
United States

24. They See Differences in Reporting

25. Implication • 3 mental data parses • 3 mental comparison per country =
• 12 mental data parses IAW national background • 12 mental comparisons
A very manual process

26. Automation Assistance via IDEAS
Automated Compare
CA EA
UK EA
AU EA
1 data parse
IDEAS
US EA
• 4 mental data parses of our native doctrine (instead of 12)!
• 0 mental comparisons (instead of 12) against an consistent ontology vice a national background!

27. Process Comparison Presentation
May employ a workflow analysis technique
Suggestion that perhaps a Failure Mode Analysis techique would work
Example workflow analysis tool

28. IDEAS Data Exchange Format (RDFS)
Visualization Environment
Decision Environment
Envisioned “To-Be”
Relational DB Query Environment
SQL Query
OWL/RDFS DB Data Mining Environment
RDFS Database
IDEAS Data Exchange Format (RDFS)

29. Summary
Exchanging architecture data during coalition operations planning process:
Can automate interoperability comparisons to:
Reduce resource requirements
Speed the process
Potentially detect issues that may have been missed
De-bias national interpretations of other doctrines
Identify critical interoperability or capability “failure” points
Depends on a precise data exchange standard
IDEAS grounding in a formal ontology provides such precision
A limited experiment in ’08 will demonstrate some of these benefits
An exercise in ’09 is planned to show these in a broader context

30. Next Steps Data Methods Presentation Management
Baseline the model and put under a Configuration Management discipline (not too onerous, just enough)
Determine which parts are mature enough to release to our framework teams (in-progress)
Shared “master” model for IDEAS Group on the modelfutures server so each nation can work its domain level’s somewhat independently, coordinate and reconcile at quarterly meetings (in-progress)
Process for queuing and prioritizing outstanding issues and incompletions
Finish the “Work in Progress” areas, mostly in the SV/TV’s
Document the model
Develop training material
Methods
Propose some Casualty Management metrics that can be used as a basis for “failure mode analysis” (in-progress)
Presentation
Continue looking into process / workflow interoperability analysis tools
Look in “failure mode analysis” presentation tools
Management
Continue bi-weekly telecons with modelers
Continue quarterly intensive modeling sessions to “sync up”
Maintain program plan for experimentation, exercise, and productionization of capability
Share national positions regarding relationships with framework teams and vendors (including OMG)

31. BORO Methodology website
Questions?
IDEAS Group Wiki
IDEAS Group website
BORO Methodology website