eda symposium 7-9 october 2006 2 nd event processing symposium military scenario use case 7-9...

EDA Symposium 7-9 October 2006

2nd Event Processing Symposium

Military Scenario Use Case

7-9 October 2006Hosted by Oracle

Dr. Opher EtzionGreg Porpora


Use Case Detailed Description This Use Case will represent a Defense – Naval Real-time

Complex Event Processing flow across the entire Enterprise of a Naval Combatant from Sensors to Command & Control (C2) to Weapons depicting the complex flow of information and events necessary for the ship to sense, track, assess, engage and destroy an incoming missile threat. The scenario will be unclassified, simplistic and representative to only a general/notional sense of actual Naval weapon systems.

The scenario will depict and examine the interacting relationships of events and information across multiple time epochs and systems throughout our imaginary ship.


Detailed Naval Scenario DescriptionThis scenario represents a sequence of events necessary for a Naval ship to defend its self against a missile threat. This ship has 10 seconds to react and destroy the missile, in that time our Real-Time Event Driven Architecture must assess, correlate, transform, enrich and route a multitude of complex event streams across three time epochs from sensors to command and control (C2) and finally weapons across its associated Real-time Enterprise Service Bus (ESB).

1000m = .5 NM 6000m = 3 NM

SPD : 820 mph = 1203 ft/sec

T0T0 + 10 sec

Impact point

Normal Ops

t0

Detection Correlation Classification Tracking Validation Assess Confirm Task Execute

T0 + 1 T0 + 2 T0 + 3 T0 + 4 DestroyT0 + 5 T0 + 8 T0 + 9T0 + 7T0 + 6

SENSORS COMMAND & CONTROL(C2)

WEAPONS

SPD : 1000 mph = 1467 ft/secss ms

µs

RT- ESB

RT EDA-SOA

C2

ECM

PhasedArray

RADARMissile

LauncherSilkworm

RAM


Detailed Use Case Event FlowTime Sequence

Process Activity Event Thread Activity QoS SLA for

RT-Middleware

EDA RT- ESB Activity

Complex Event Process

Phase 1 Detection •Radar & Electronic Counter measures systems detect contact

•Send contact data to tracker

•Latency Budget (time-based, dead-line)•Ownership Strength•Reliability

•Discovery

•QoS Validation

•Monitoring

•Linkage

•Validate

•Route

Phase 2 Correlation •Combine contacts via correlation algorithm

•Compute Pd >.9

•Build Track File

•Latency Budget (time-based, dead-line)

•Discovery

•QoS Validation

•Monitoring

•Store and Hold

•Enrich

•Transform

Phase 3 Classification •Compare contact electronic signature to class library

•Compare contact SPD & BNG to Threat thresholds

•Classify as Hostile Missile and send alert for C2

•Latency Budget (time-based, dead-line)•Ownership Strength

•Discovery

•QoS Validation

•Monitoring

•Store and Hold

•Linkage

•Enrich

•Transform

•Route

Phase 4 Tracking •Tag Track file and assign highest priority

•Send to Command & Control (C2) as highest alert track

•Lower priority of other track and non-essential processes and re-task IT assets


•Discovery

•QoS Validation

•Monitoring

•Linkage

•Enrich

•Route

Sensors Time Epoch: 500us – 2ms


Detailed Use Case Event FlowTime Sequence

Process Activity

Event Thread Activity QoS SLA for

RT-Middleware



Phase 5 Validation •Interrogate Track against Identification Friend or Foe (IFF) systems

•Latency Budget (time-based, dead-line)•Ownership Strength•Durability•Reliability

•Discovery

•QoS Validation

•Monitoring

•Enrich

Phase 6 Threat Assessment

•Compare track to other high priority tracks and assign Threat Assessment as Priority 1


•Discovery

•QoS Validation

•Monitoring

•Store and Hold

•Enrich

•Transform

Phase 7 Confirmation •Probability of Detection (Pd) + Threat Assessment > .9

•Send Engage Order to Weapon Systems


•Discovery

•QoS Validation

•Monitoring

•Linkage

•Transform

•Route

Command & Control (C2) Time Epoch: 2ms –

250ms


Detailed Use Case Event Flow

Time Sequence

Process Activity

Event Thread Activity QoS SLA for

RT-Middleware



Phase 8 Tasking •Task Track to best engagement weapon (Missile System) for engagement

•Select Missile cell

•Warm-up Missile

•Task Counter-Measure system to activate

•Launch Counter-Measures

•Program Missile with Track data


•Discovery

•QoS Validation

•Monitoring

•Linkage

•Enrich

•Transform

•Route

Phase 9 Execution •Activate Guidance

•Deactivate Fail-Safe

•Open Vertical Launch Hatch

•Launch Missile

•Start Engagement Sequence

•Latency Budget (time-based, dead-line)•Reliability

•Discovery

•QoS Validation

•Monitoring

•Linkage

•Enrich

•Transform

•Route

Phase 10 Destruction •Receive Missile Track Intercept data

•Receive Detonation signal from Missile

•Latency Budget (time-based, dead-line)•Reliability

•Discovery

•QoS Validation

•Monitoring

•Linkage

•Route

WeaponsTime Epoch: 1us - 500us


High Level Missile Engagement Flow

PhasedArray

RADAR

ElectronicsCounterMeasureSystem H

igh

Pe

rfo

rma

nc

e E

SB

Sensors

ThreatEngagement

ProcessorH

igh

Pe

rfo

rma

nc

e E

SB

MissileControlSystem

VerticalMissile

Launcher

Medium Performance ESB

Command &

Control

GCS

GRS

Me

diu

m P

erf

orm

an

ce

ES

B

INTELL

AREPS

PC-IMAT

NITES II

CADRTS

Me

diu

m P

erf

orm

an

ce

ES

B

Track Manager

High Performance ESB

Weapons

Command and Control

Phase 1

Phases 2 - 7

Phases 6 - 10

Total Time Sequence ~ 750 ms




Multiple domains of time-dependent control

Non-real time

seconds

milliseconds

microseconds Radar Weapon

Tracking

Command & Control

Logistics


An SCA modellers view

Tracking subsystem

C2 subsystem

Sonarsubsystem

Weapons subsystem

Geospatialsubsystem

Intelligencemanagement subsystem

ECMsubsystem

Radarsubsystem

DPE1A

DPE2

DPE1U

DPE3

Track Module

Fuser AnalyserDPE4

DPE5

MissionDoctrine Module

DPE6

Threatengage WCS

Missilelauncher

DPE7 DPE8

GeospatialReplication

SITUprocessor

GeospatialCollaborator

GeospatialData

Meteo

Nav


High Level Weapon System Context Diagram

Non-OrganicInputs

Situational AwarenessProcessor

Geo-SpatialCollaboration

Processor

Track & MissionDoctrine/Policy

Global TrackFederation and Fusion

Processor

Threat trackAnalyzer

Geo-SpatialReplication

Service

ThreatEngagement

Processor

Meteorological&

Ocean EnvironmentProcessed Data

Ships NavigationData

Environment PredictionAnalysis

For Weapons

WeaponEngagement

Manager

WeaponResource

Scheduling

WeaponSelector

MissileController

MultimodePhasedRadar

ElectronicCounter-Measure

System

UnderwaterDetection

SonarSystem

GlobalCommand

&ControlSystemMaritime

Multi-DisplaySystem

IntelligenceManagement

System Filtered Intelligence

Common Operation Picture

Air & Surface Tracks

Air & Surface Tracks

Under

water

Tra

cks

Sur

face

Tra

cks

Non-OrganicInputs

Track ClassificationDoctrine

Updated as needed

All Tracks overlayed on Geo-Spatial

Context

Track ClassificationDoctrine

Updated as needed

Integrated/FusedGeo-Spatial Content

Threat Tracks

SelectedThreat Tracks

Prioritized/SelectedThreat Tracks


WeaponsCEP

C2ISR

Seconds : Near Real-Time

Milliseconds : Soft Real-Time

Microseconds : Hard Real-Time

The Complex Event Processing engine within an Event Driven system’s Enterprise Service Bus (ESB) must be able to recognize event patterns across the functional and technology gradients of an ecosystem to the lowest level of determinism and route the aggregated results.

Finder

Shooter

Decider&

Connector

Time Epochs


Complex Event Processing and Event-based Architecture Support

Validate

Enrich

Transform

Route

Operate

Filtering; Temporal and causality constraints

Aggregation; event-data join

Intelligent routing; content-based routing; event-driven flows

Service invocation; alert; dynamic flows

Create “complex event”

Event Source

Event Consumer

Summary of activity over 1 hour

ComplexEvent

Processor


F1

Node: ISR1

F2

F3

F1

Node: ISRn

F2

F3

D1

Node: C21

Co

nn

ecto

r In

fras

tru

ctu

re

D1

Node: C22

CEP ActionS1

Node: S1

CEP ActionS2

Node: S2

CEP ActionS3

Node: S3

CEP ActionSn

Node: Sn

Dee

p S

enso

r an

d H

isto

rica

l d

ata

Rea

chFINDERS•Intelligence•Surveillance•Reconnaissance

DECIDERS•Command & Control

SHOOTERS•Weapons

Near Real-Time Soft Real-Time Hard Real-Time


High level Event Processing Flow for Naval Use Case

Sensor 1

Sensor 2

Sensor 3

EP 1

TrackData

Sensor 1

Sensor 2

Sensor 3

AlertTrigger

EP 2

A1orA2orA3

E[Alert trigger (Ax)]

)321( SSSAx

)321( orAsorAsAsAT

E[Alert Track]

EP 4

Fire Intercept Missile

)(ATIFFAT

EP 3 EP 5

ASSET 1

ASSET 2

ASSET n

AssetsThat canIntercept

(FINDERS)

IFF(AT) Trigger

E[Alert Confirm]

Compute Intercept PointAssign asset

E[Alert Track]

E[Intercept Asset (Asn)]

(DECIDER) (SHOOTER)

Total Time from Detect to Engage = 10 seconds

Microsecond ESB

Millisecond ESB

Second(s) ESB


Problem Space Inability to manage Latency and Determinism Lack of tools Large Data ingest High message traffic Large Legacy Domain Lack of temporal interlock Complexity or perception Ability to abstract Domains for determinism is a relative term Reactive versus proactive Take RT Event and compare against massive amount of history Simple patterns Making incremental change based on incremental pieces of data Must think of the problem at different levels of the stack (Vertical

versus Horizontal)


Problem Domain at a High level - Continued With these three key parameters (Bandwidth/Communication, Memory, CPU processing) how

do we architect an EDA IT infrastructure that can meet the Deterministic latencies required to intercept the Missile. However, if we examine the end to end Missile engagement process it is a very large Stochastic

Process whereby there is only a probability of achieving RT Determinism

The most critical constraint is provision in the face of either high data ingest or faults

How do we degrade gracefully in this situation…. How do we trade off Urgency of processing versus importance

How will your system perform in the presence of overload and resource starvation ( Shed Load, lockup, etc.)

It is not good enough to just reduce priorities or make something a higher priorities, Resource management and provisioning play crucial role here this goes for memory, CPU and BW). Also not all processes can be arbitrarily stopped some provide critical admin and support services that must continue to execute otherwise we run the risk of catastrophic system collapse

This problem is not unlike a futures market whereby you ensure against risk by over provisioning

We work well on a per single node bases but when executing multiple JVM’s on a single CPU resource provision and scheduling become more complex.


Value of Using RT Event Processing In specific Domain Spaces i.e. DoD can not meet 2010 Mission Requirements

without RT CEP

Address the latency Gap

Become more proactive to predict future events

Modelling based on historical data and current understanding of event cloud to predict near term outcomes with updating for continuous learning

Real-time is relative term depending on required predicted outcome

Extract to higher levels of abstraction for inference


Market Drivers, Motivators, Challenges and Entry Points Drivers

Predictability

Adaptability

Dynamic

Latency and Determinism management Motivators

Tactical as well as strategic information advantage

Get inside competitive decision loop Challenges

Legacy Integration

Cost

Complexity

Entry Points Start small


Where do we go from Here ?

Better understanding of respective Domain space requirements and constraints

Standards

Tools Modelling Development Trace and Monitoring

eda symposium 7-9 october 2006 2 nd event processing symposium military scenario use case 7-9...

Documents