Open systems architecture for

1
A Common Architecturefor Situational Awareness

• Open systems architecture for
• national systems
• L.E. Cochran FirstMark Technologies Ltd.

1 December 1999
2
DND Mission Requirements (General Henault 1999)

• Interoperability across variety of DND systems
  and with allied systems
• Fusion of satellite imagery, geomatics data and
  signals intelligence and delivery of information
  to the commander in the field
• Real time access on the global level to COP in
  the theatre
• Battlespace and situation awareness knowledge
• Longevity of systems to evolve with emerging
  technologies
• Integrate current systems

3
The ODIN Project, an Example

• Operational Digital Imagery Navigator
• A near-real time satellite surveillance tool
• MARCOT 98 Exercise demonstrated practical
  application of current technology in integrated
  mission planning, acquisition and target
  detection/reporting.
• Also illustrated need for architecture-centric
  approach to integrated system development
  (sticking COTS software together is a fantasy!)
• Intended to support operational objectives of COP

4
Operational Context
Illustrates Temporal states of SA Systems
5
Operational Concept
Multi-Sensor Platforms
Mission Planning Sensor Data Acquisition Target
Data Fusion Image Data Fusion GeoInfo
Integration Image/Data Analysis Situation
Display Information Distribution
Field Units
Joint C2 Info System
6
Distributed Component System Concept
Fixed Components
Deployable Components
Ground Stations (Mobile/transportable)
Ground Stations (Fixed)
Executive/Command HQ Unit
Airborne Units
Data Repositories
Specialists Applications
Field Command Unit Theatre Ops Support
Naval Units

• Adaptive
• Rapid Deployment
• Mulitple Copies

Mobile Field Units
7
(No Transcript)
8
DISTRIBUTED COMMON ARCHITECTURE
Remote Data Access
Command/Control Environment
ODIN Internal Components

• Ops Planning Scheduling
• Satellite Data Acquisition
• Remote Data Search Access
• Image Processing
• Feature Extraction
• Image Data Fusion
• Auto Target Recognition
• Target Data Fusion
• Image Analysis Annotation
• Map/Display Products
• Target Reports

Data Discovery Environment
Communications Environment
Data Mining Environment
Civil Surveillance Environment
Data Ordering Environment
Simulation/Training Environment
Data Acquisition Environment
Test Environment Environment
Databases
GUI Environment
Domain Object Models
Conceptual Data Model
HARDWARE ENVIRONMENT
WEB ENVIRONMENT
9
External Systems Organizations
FUNCTIONAL CONCEPT

Surveillance Satellites (SAR/Optical)
Operations Planning Scheduling

JC2IS Command Control
Ingested Sensor Data



Satellite Data Acquisition
Image Processing
Feature Extraction

• Collaborative
• Systems
• Aurora
• HFSWR
• Acoustic
• Allied

Target Data From External Systems
Image Data Fusion
AutoTarget Recognition/ Classification

Image Analysis Annotation
Archived Image/Sensor Data

Target Data Fusion

Map/Display Products

Remote Data Search Access
Remote Archives GIS Data

Geospatial Data
Target Reports
Client Organizations
Demonstrated
10
Imagery Geospatial Tools
14 Existing Tool products were identified and
evaluated
Product Name
Product Type/Function
Supplier
Integrated Imagery and geospatial analysis system
Carterra Analyst
Lockheed Martin Space Imaging
ILOG Jviews
ILOG Jviews
2D Java Class Libraries
IMEWS
Image Manipulation and exploitation workstation
PCI
Digital Imagery exploitation and production system
GTE
DIEPS
Khoros
Software Integration and development
environment for data manipulation display
Khoral Research Inc.
IDL
Interactive Data Language for data analysis
visualization
Research Systems
Environment for visualization and image processing
Research Systems
ENVI
Open Geospatial Datastore Interface
J2 Geomatics, Global Geomatics
OGDI
11
Architectural Framework

• Addresses the need for making autonomous systems
  work together (Interoperability)
• Identifies common infrastructure elements
• Provides an incremental and evolutionary
  integration environment
• Is a formalized methodology/process
• Communicates requirements and capabilities
  between all stakeholders
• Is consistent with USDOD system procurement
  practices

12
Architectural Framework
OPERATIONAL ARCHITECTURE
Identifies Operational Relationships and
Information Needs
CONCEPTUAL DATA MODEL
Defines Data Content and Relationships
TECHNICAL ARCHITECTURE
Specific capabilities for Information Exchange
Other Reqmts
SYSTEMS ARCHITECTURE
Relates Capabilities and Characteristics to
Operational Requirements
Prescribes Standards and Conventions
Technical criteria for Interoperable Implementatio
n/procurement
13
ODIN Architecture Framework
Glossary
Operational Architecture
Technical Architecture
System Architecture
Conceptual Data Model
Migration Plan
Technical Architecture Profile
Evolutionary Phase Implementation Plan
Vol I To-Be System Architecture Description
Metadata
Operational Concept Diagram
Imagery
Operational Relationship Chart
Standards Technology Forecast
System Element Interface Description
Air Transportation
Functional Manager Guidance Input Form
Activity Hierarchy
System Information Exchange Matrix
Ground Transportation
Activity Diagram
Water Transportation
Volume II
Information Exchange Requirements Matrix
ODIN Interoperability Profile
Water Features
Cultural Features
Vol III As-Is System Architecture Description
Physiography
Operational Scenarios
Other.
System/Segment Element Interface Diag.
System/Segment Interface Matrix
14
ODIN System Operational Architecture
Description (ODIN OAD)
Specs
ODIN Technical Architecture
ODIN Conceptual Data Model
Interface Control Docs (ICDs)
System Information Exchange Matrix
ODIN Interoperability Profile (ODIN IP)
Application Category
Common Support Services
Application Program Interfaces (APIs)
Media
Format
15
A Common Architecture

• Architectural framework defines a common,
  non-proprietary environment for collaborative
  systems.
• Enables systems to be procured, modified,
  replaced as components in an integrated system.
• Supports multiple vendors rather than single
  vendor.
• Facilitates autonomous organizational units in
  cooperative, economical development operation.
• Provides an operational environment for
  integrating and evaluating new components/technolo
  gies.

16
A Common Architecture (Contd)

• The architectural initiative is connectable to
  and consistent with other initiatives
• Disaster Management
• OGDI III
• CEONet/GEONet
• Geomatics Canada Geoconnections
• Open GIS consortium Web Mapping Testbed
• NIMA USIGS IEC
• US Army TEC

17
Summary

• It is practical to integrate existing sensor
  systems to achieve good operational performance.
• Ad Hoc approach to system procurement should be
  replaced with a common architecture to provide a
  framework for component development.
• The architectural framework emerging from ODIN is
  applicable to and supportive of the individual
  CRAD Thrust areas in C2, surveillance and data
  fusion.
• The implementation of an architectural framework
  should be a joint development.