joint rapid scenario generation (jrsg) systems engineering · pdf filejoint rapid scenario...

22
Joint Rapid Scenario Generation (JRSG) Systems Engineering October 2008 Mr. Ralph O’Connell US Joint Forces Command Joint Capability Development (J8) Senior Systems Engineer

Upload: vuongdang

Post on 06-Feb-2018

240 views

Category:

Documents


0 download

TRANSCRIPT

11

Joint Rapid Scenario Generation(JRSG)

Systems EngineeringOctober 2008

Mr. Ralph O’ConnellUS Joint Forces Command

Joint Capability Development (J8)Senior Systems Engineer

2

AnalysisTraining

Planning Acquisition

MissionRehearsal

Test &Evaluation

DomainsDomains

DefineEvent

UserManagement

Schedule

Obtain Data

ProcessData

Release Product

Common processessupport all domains

Experimentation

Common services support common processes

OperationsAssessment

Department of DefenseM&S Budget in FY08 is ~$11B** **Source: Dan Cuda, Mike Frieders, IDA CARD

JRSG Problem Statement

• The increasing use of complex M&S applications requires data with greater fidelity with a rapid production time.

• There are common capability gaps that transcend all domains.

• Combined, Joint, Services, and Agencies (C/J/S/A) are developing independent improvements to their scenario generation capabilities.

Generation of scenario data sets do not support operational requirements for near real time mission rehearsal, course of action analysis, and adaptive planning.

JRSG Activity Model & Domain Support

Scenario generation expenses reported in FY07 are >$400M*

*Source: JRSG Evaluation of Alternatives Survey

No one in is responsible for orchestrating the DoD enterprise solution.

3

JRSG Systems EngineeringObjective and Constraints

Objective: Integrate existing Combined, Joint, Service, and Agency (C/J/S/A) scenario generation capabilities into an enterprise solution that can rapidly translate authoritative data into a set of initialization products that support mission critical timelines.

Constraints:• Comply with Net-Centric Data Strategy (NCDS) and

Universal Core (UC) data schema• Utilize Net-Centric Enterprise Services (NCES)• Synchronize capability development with Net-Enabled

Combat Capability (NECC) and the Command and Control (C2) Domain Core data schema

• Evolve best of breed C/J/S/A capabilities• Adhere to Information Assurance policy

4

Demonstrate JRSG Service Oriented Architecture (SOA)

JRSG Systems Engineering ApproachEstablish JRSG Community of Interest (COI)

Determine JRSG Demonstration Objectives• Integrate existing capabilities as enterprise solution• Determine Combatant Command priority data sharing needs

Geospatial Data Discovery Order of Battle DataDiscovery/Delivery

Map Metadata to GSIP

Build Message Broker

Deploy Agents

Map OOB to JC3IEDM

Build Message Broker

Invoke GFM DI Service

5

JRSG Community of Interest (COI)

Program Executive OfficeSimulation Training, Instrumentation

TopographicEngineering Center

NationalSimulation Center

SyntheticEnvironment Core

Simulation to C4IInteroperability

US Joint Forces Command

US Air Force

Naval AviationSystem Master Plan

US Navy

US Marine Corps

US Army

Air Force AgencyFor Modeling& Simulation

Air ForceResearch Lab

Joint ChiefsOf Staff

US Special Operations Command

National GeospatialIntelligence Agency

6

Notional “As-Is” Baseline Capability

OtherFFDB

SOFPREP Archive

Force Structure

SGS

JTDS ArchiveEOB

C4ISR Systems

SIM Systems

PFPS, ASI

ACSIS JTDS

SECORE

SOFPREP

JDS

UOBDAT

NGOThreat Forces

FFDBBLSDMTOE

EnvironmentModel Parametric

GCCSSPIRITJCOFA

ATOACOUOBMIDBN-PSI

UOBDAT

Source Data

OtherNSC

NWDC

Other

LEGEND

•Data Input •Initialization Data Output

Target Systems

Category 1 - Baseline

NGTS Threat Scenario

SOCOM Simulators

OOS, CCTT

AWSIM, NGTS, DICE, LOGSIM, JSAF

JSAF, JCATS, JTLS, JDLM, SIMPLE, OOS, VRSG

AODB, MIDB, TAPDB, TBMCS

ABCS, FBCB2, BFT

Other

Scenario Build Process

7

Conceptual JRSG “To Be” ArchitectureFOCUSED ON PROVIDING LVC FUTURE IMMERSIVE TRAINING ENVIRONMENT

ManningDBs

TargetDBs

Geo-spatialDBs

IntelDBs

PlatformDBs

ForceStructure

DBs

Readi-nessDBs

WeaponDBs

OtherDBs

TPFDDDBs

GIG

ExperimentApps

AdaptivePlanning

Apps

MobilityAnalysis

Apps

TrainingApps

Test &EvalApps

AcquisitionApps

MissionPlanning

Apps

M&S Enabled Applications

Required / Potential Data Sources

MissionRehearsal

Apps

DecisionSupport

Apps

JRSG Services

ForcePlanning

Apps

OtherApps

METOCDBs

LogisticsDBs

PMESIIDBs

GIG: Global Information GridNCES: Net-Centric Enterprise Services

NCESData Strategy

Interoperability & Data Standards

Discovery and Delivery

Collaboration

Portal

SOA Foundation

Common Scenario DefinitionCollaborative Data WorkspaceData CorrelationData Configuration ManagementScenario Data ArchiveTranslation for Export

Distribution

HostingDefineEvent

UserManagement

Schedule

Obtain Data

ProcessData

Release Product

8

JRSG COI Geospatial Metadata Mapping

JRSG COIMetadata

Repository

SOCOMMetadata

Army TECMetadata

Army SECoreMetadata

NGA TGDMetadata

Navy PSIMetadata

JFCOM TGSMetadata

Air ForceSDBF

Metadata

All JRSG COI geospatial discovery metadata mapped to GEOINT Structure Implementation Profile (GSIP) standard

metadata exchange model.

9SIMPLE

AWSIM

Oracle

GIG

GFMOrg

Servers

GFM DIXSD

Log DataLinked to OUID

Ops/Intel Data Linked to OUID

Pers Data Linked to OUID

Order of Battle Scenario Generation Data

PersADSPersADS

PersADS

LogADS

LogADS

LogADS

OpsADS

OpsADS

Ops/IntelADS

Across Warfighter and Business Domains

XSD’s

XSD’s

XSD’s

XSD’s

XSDOUIDs

XSDOUIDs

XSDOUIDs

XSDOUIDs

XSDOUIDs

JointIntegrated

Picture

JCATS

JDLM

JTLS

Joint ExerciseSimulations

JRSG SOA

10

JRSG SOA Pilot Operational Nodes

JRSG SOA

EnterpriseService

Bus (ESB)

ComplexSubscriptionBroker (CSB)

SIPRNet

JRSG SOA

EnterpriseService

Bus (ESB)

ComplexSubscriptionBroker (CSB)

NIPRNet

Cross DomainGuard - TBD

JFCOM JTDS

SOCOM SOFPREP

Army TEC

AFAMS/SGS

NGA Geospatial

Web Services EDCSS (ASNE-

Weather)Web Services

JCS GFM DIAuthorized

ForceStructure

Army SE Core

Navy PSI

JFCOM JTDS

Federation

Federation

Federation

Agent CSB Plug-In Federation SOA Federation

Air Force/DMOC

11

USJFCOM – IBMCooperative Research and Development Agreement

Joint Force OperationsService Oriented Architecture (SOA)

Applying SOA9 October 2008

Paul GiangarraIBM Distinguished Engineer

Office of the CTO, IBM Federal

12

The Path to Integrated Systems

Application 1

Application 2

Application 3

Application 1

Application 2

Application 3

Application 1

Application 2

Application 3

Information Integration

Process Integration

People Integration

Silos Systems of Systems Integrated Systems

13

What is (and isn’t) SOA?

SOA is…

• Service Oriented Architecture• A way of thinking• A means of aligning Business with

Information Technology• An architectural style for the

design of business applications in terms of flexible, reusable, loosely coupled service assets

SOA is not…

• A standard• A specification• A programming model• A platform

14

The SOA Journey

SOA Briefings

Business Pilot Workshop

Architecture

&Design

Pilot&

Prototype

• Production ready Code• Technology Proof

Point• Metrics• Center of Excellence

• Create Code• Create Documentation• Establish Governance

Demonstrate SOA Production Feasibility

Deliverables

Agenda

Objective

• Technical Architecture• Definition of Phases• Business Case

• Strategic Roadmap• Project Plan• Service Description• Mission Value

• Handouts• IBM SOA Position• SOA Compass Book

• Architecture Principles• Architecture Decisions• Integration Framework• Pilot Project Plan

• SOA Assessment• Business Process Map• SOA Reference Arch.• SOA Framework• SOA Governance

• SOA Overview• SOA Mission Value• SOA Best Practices• SOA Implementation

Develop Architecture & Implementation Road Map

Define First Project and SOA Roadmap

Build Common Understanding of SOA

15

Business Innovation & Optimization ServicesProvide for better decision-making with real-time mission information

Dev

elop

men

tSe

rvic

es

ModelDesign

ImplementTest

Interaction Services

Enables collaboration between people,

processes & information

Process Services

Orchestrate and automate business

processes

Information Services

Manages diverse data and content in a unified manner

ESB Enable inter-connectivity between services

Partner Services

Connect with mission partners

Business App ServicesBuild on a robust,

scaleable, and secure services environment A

pps

&

Info

Ass

etsAccess Services

Facilitate interactions with existing information and application assets

IT S

ervi

ceM

anag

emen

t

Manage and secure services,

applications &

resources

Infrastructure ServicesOptimizes throughput, availability

and performance

Joint Rapid Scenario Generation SOA Reference Architecture

JRSG Common

Databases (Geospatial, OOB, etc)

JRSG Common

Databases (Geospatial, OOB, etc)

JRSG Common

Databases (Geospatial,

Weather, etc)

Source Data Provider(e.g., NGA, Air Force,

Army, Navy, COCOMs, TEC …)

JFCOM Data Catalog

Portal/User Interface

Event Database

Target SYSTEMS

Customer (Requests and

Product Delivery)

Package Training Product

Catalog New Data Locate

Source Data

Locate Source Data

Future Services

(e.g., Locate Source Data)

Import Customer

Data

JRSG Processes

Joint Organization

Server (GFM DI)

16

Information Lifecycle: The “Problem” Space

Collection

(task/post)

Analyze

(process)

Disseminate

(use)

Satellite

Newsfeeds

Radar

UAV

Weather

Complex image analysis

Add some meta data

GPS metadata, target analysis

GPS metadata

GPS metadata

…Generically steps:

Cleanse, transform, resolve, combine (federation), structure, tag, index

Choreograph the analysis process

Requires deterministic E2E responsiveness

Complex Subscription Broker fits here

Decouple UI from final information “fusion” and filtering

Community based pub/sub

Example communities: jet fighters, bomber pilots, AWACs, AOC (various roles), ….

17

Key Architectural Decision

BrokerRegister

COI BROKER FRAMEWORK

Publish

Subscribe

Notify agen

t

Loosely couple the “Front End” (Human or Machine Interface) from the “Information Broker”, from the Information Source(s) using a Complex Subscription Broker

18

Use Cases to Validate Design Assertions

• Publish Terrain Metadata• Search for and Request Terrain Data• Receive Terrain Data

(Sample) Sequence Diagrams Created to document the use cases:

19

To Push or Pull: Architectural Alternatives

Pull Options: Source responds to metadata requests

Push Options: Source Provider pushes the metadata outside the firewall(s).

20

Logical (Network & Product) Architecture

21

Examples of What is Coming Next

• Finalize Security Model & Design• Finalize the Data Model• Design, Develop, Test & Deploy the Components

and Infrastructure• Governance • Possibly Look at Alternative Interface Options

• Demonstrate the Results• Determine the Next Steps/Spirals

• Document What We Learned

22

QUESTIONS?????