JMASS What it implies,'''and What that means

1
Peddling MS for DoD Acquisition ProgramsA
Snollygoster's Paradise!
Briefer Bob Meyer, JMASS JPO
Navy Senior Engineer Date 1-2 April 2003
2
Peddling MS for DoD Acquisition ProgramsA
Snollygoster's Paradise!
Briefer Bob Meyer, NAWCWD Ops
Research Analyst Date 1-2 April 2003
3
Peddling MS for DoD Acquisition ProgramsA
Snollygoster's Paradise!
Briefer Bob Meyer, US Citizen
Professional Iconoclast Date 1-2 April 2003
4
Purpose of this Presentation
Characterize DoD's approach to the Holy Grail of
MS
Review the "truths," implications and their
meaning to the JMASS modeling and simulation
(MS) "paradigm shift."
Highlight the common dependence of all DoD
combat-related MS on the existence and
maintenance of a stable, consistent, well-managed
set of system and phenomena models.
Argue that a consortium-based approach is both
necessary and sufficient to properly create and
manage such a model set.
Recommend that DoD use the JMASS experience to
begin implementation of this consortium-based
approach to MS.
Conclude with a shameless plug
5
Holy Grail, or Alphabet Soup ?

• There are myriad "joint" and other, more truthful
  MS programs within the DoD these days
• The original three JWARS, JSIMS, JMASS
• The new wave JVB, JSB, JBE, DEP, JDEP, FEX,
• The simulation architectures DIS, HLA, TENA,
• The commercial products FLAMES, TACTICS,
• The "service standards" ModSAF, OneSAF, CSF,
• And still others ACS, JAMIS,
• They all have two things in common, one is

They are all application oriented
6
Lexicological Roulette

• DoD can't even agree on basic terms of MS
• Simulation animation of coupled models over
  time
• Model representation of system and/or
  phenomenon
• Accuracy measure of exactness of model
  representation
• Detail measure of completeness of model
  representation
• Fidelity measure of perceivable/perceived
  resolution
• Resolution convolution of model accuracy and
  detail
• Some work done within SISO/SIW, but little or no
  benefit to/impact on the practitioners of the
  trade.

Further reference SIW paper 98S-SIW-245
7
Joint Modeling and Simulation System

• JMASS is a systems-level software architecture
  that supports MS analysis across the entire
  acquisition cycle - in short, JMASS embodies the
  SBA concept
• Model Standards
• Software Structural Model for Reuse
• Model Application Programming Interface
• Simulation Support Environment
• Simulation Engine
• Model Development Tools
• Analysis Tools
• COTS Legacy Tool Interface
• Model Library Repository
• Local Model and Data Library
• Modeling and Simulation
• Resource Repository

The ability to reuse and interchange
high-fidelity, physics-based models is perhaps
the most visible and important of the many
benefits of JMASS The JMASS customer base
continues to expand and includes a wide variety
of applications supporting acquisition, TE and
operational activities JMASS is currently
supporting Operation Iraqi Freedom
8
"Truths of JMASS"
JMASS is NOT a simulation

• JMASS is NOT a simulation
• All JMASS action is player-based
• JMASS is interface ignorant
• Compliant is NOT interoperable
• JMASS is NOT "plug and play"

9
Implications of JMASS paradigm

• JMASS is (supports/needs) distributed development
• Threat models from DIA, blue models from SPOs,
  etc.
• Orthogonal view gives user and developer
  perspectives
• JMASS is (promotes/defines) simulation
  integration
• Simulation integration begins with problem
  decomposition
• Application functionality player list model
  requirements
• JMASS is (enables/benefits from) software reuse
• Software reuse in MS can/does occur at all
  levels
• Debate rages over optimum level of software reuse
• JMASS reuse currently focused at the player level

JMASS is NOT a simulation
10
The meaning of what JMASS implies

• Distributed development, simulation integration
  and software reuse focus on two common themes,
  the first of which is process-related
• First step is to decompose analysis problems into
  system and environment players, including model
  requirements, as illustrated by the rows on the
  matrix view of JMASS.
• Second step is to (re)compose the simulations
  which will be used to address these analysis
  problems by choosing and combining system and
  environment players along with the architecture
  and tool components.
• Last step is to accredit this simulation for its
  intended application based on the VV of the
  constituent parts
• Not likely a trivial combo of the pedigree of
  these constituent parts

JMASS is NOT a simulation
11
Matrix view of the JMASS system
JMASS is NOT a simulation
12
Views/aspects of a (SAM) simulation

• Legacy
• Monolithic code
• Functional style
• Structured language
• Skewed fidelity
• Do-loop sim engine
• Inter-player interface hidden/convoluted
• Single developer
• Integration occurs "automatically"

• JMASS
• Modular code
• Object-based style
• OO language
• Balanced fidelity
• Separate sim engine
• Inter-player interface visible/concise
• Multiple developers
• Integration requires separate activity

JMASS is NOT a simulation
SIMULATION
Model Interfaces
Simulation Engine
Acq Radar
Track Radar
Missile
Aircraft
ECM Sys
RF Env
13
Views/aspects of a (SAM) simulation

• Legacy
• Monolithic code
• Functional style
• Structured language
• Skewed fidelity
• Do-loop sim engine
• Inter-player interface hidden/convoluted
• Single developer
• Integration occurs "automatically"

• JMASS
• Modular code
• Object-based style
• OO language
• Balanced fidelity
• Separate sim engine
• Inter-player interface visible/concise
• Multiple developers
• Integration requires separate activity

SIMULATION
Model Interfaces
Simulation Engine
Acq Radar
Common Architecture Interfaces
Unique Application Interfaces
Track Radar
Missile
Aircraft
ECM Sys
RF Env
14
The meaning of what JMASS implies

• Distributed development, simulation integration
  and software reuse focus on two common themes,
  the second of which is infrastructure-related
• The development, "ownership" and management of
  system and environment models as illustrated by
  the columns on the matrix view of JMASS

JMASS is NOT a simulation
Essential to JMASS a stable, reusable,
well-managed, interface-based set of system and
environment models
Further references SIW paper 01S-SIW-117
and SIW paper 01F-SIW-109
15
Matrix view of the JMASS system
JMASS is NOT a simulation
16
Relationship to JSIMS/JWARS

• Joint Simulation System (JSIMS) Joint Warfare
  Simulation (JWARS) - DoD MS programs
• JSIMS focused on training, JWARS on campaign
  analysis
• More aggregate (than JMASS) system/environment
  models
• Models aggregated from engagement (JMASS) results
  
• Future may include direct use of JMASS, if
  meaningful

Important to both a stable, well-managed,
consistent, interface-based set of system and
environment models
17
JVB/JSB/JBE/etc. Connections

• Joint Virtual Battlespace (JVB - the Army
  approach) Joint Synthetic Battlespace (JSB -
  the Air Force term) Joint Battlespace
  Environment (JBE - the JFC entry) FEX (the Navy
  entry?) others (JDEP, etc.?)
• Synthetic (simulated) arena of weapon systems
  interacting with each other and natural/man-made
  physical environment
• Goal is to "immerse" warfighter in this simulated
  battle arena
• Focus on System Under Test or Training (SUT),
  with other systems and physical environment
  represented appropriately

They all need a stable, well-managed, consistent,
interface-based set of system and environment
models
18
Has anyone addressed this?

• Mr. Jim O'Bryon, former Deputy Director for Live
  Fire Test in the OSD/DOTE office, suggests that
  a (set of) consortium (ia) of subject matter
  experts might be a way to manage MS resources.
  His exact words were
• "Program Managers would initially describe their
  .. MS requirements to a consortium which would
  then .. make the decisions as to which MS tools
  best suit the PMs needs and subsequently ..
  upgrade extant models where available and
  originate MS only when absolutely necessary."

Further reference Presentation at JASA
Workshop on MS Credibility, Reno,
NV, 12-15 February 2001
19
The MS/Analysis Pyramid
20
A matrix view of DoD MS
X
21
What would these consortia do ?

• Roles would include but not be limited to
• Defining/documenting component/model requirements
• Based on customer/program input for
  components/models
• Matching/merging requirements among applications
• Managing model development/modification/configurat
  ion
• Defining/documenting model capabilities/limitation
  s/VV
• Maintaining/distributing current
  components/models
• Ensuring consistency between model abstraction
  levels
• Defining/deriving how models relate between these
  levels

Further reference SIW paper 97S-SIW-181
22
The MS/Analysis Pyramid
23
How might they do these tasks ?

• Establish a methodology for dealing with families
  of models at different abstraction levels
• For example, adopt a functional/object-oriented
  template approach previously used by the EDSWG
  (those of "dancing pig" fame!)
• Allow for uniqueness of approach based on the
  nature of the system/phenomenon involved

Further reference SIW paper 97F-SIW-115
24
A mechanism for VVA
Requirements Templates
25
Template Structure
26
Template Structure
27
Environment Requirements
ENVIRONMENT/TERRAIN EFFECTS/LINE OF SIGHT
Detections shall account for intervisibility
between radar sensor (TTR or missile seeker) and
target, using the implemented terrain model
(round, flat, or terrain elevation data).
28
Standards-based DoD MS

• Establish a consortia approach to implement a
  standards base for DoD MS
• System/phenomena consortia would manage models
• An architecture consortium would begin the
  arduous task of narrowing down how best to
  architect a solution
• Consider using SISO/SIW as DoD MS consortium
• Many of the tracks and forums already match the
  columns of the DoD MS matrix

Further reference Jeff Steinman, Paper for
Summer Computer Simulation Conference, San
Diego, CA, 14-18 July 2002
29
The DoD MS Iceberg?
System/Phenomenon
Aircraft
Tanks
etc
Ships
Atmosphere
Campaign
Acquisition / TE
Analysis/Experimentation
Force
Training / Education
Aggregation Level
Mission
Engagement
Application
Engineering
30
Why JMASS may show the way

• JMASS originally focused on airborne EW/EC
• Work from 1989-1998 was for Air Force EW program
• True Joint Program Office formed in 1999
• Responded to Joint Operational Requirements
  Document
• Full, funded participation by other
  services/agencies
• Current user community very diverse, includes
• Dismounted infantry fighting urban warfare
• Aero design/development of UAV platform
• Torpedo engagements as part of undersea warfare
• Oh yes, and airborne EW/EC its original
  customer!

Key aspect JMASS is Open Source
31
What about Open Source ?

• Are we paying for the same code over and over ?
• How much of the code is similar/duplicative in
  DoD MS ?
• Could simulation engines and services be
  standardized and made open source "share-ware" ?
• What does the commercial world have to say ?
• "The advent of open source means that the point
  of greatest profit shifts from the software
  provider to the service provider. Open source
  means that it will no longer be possible to
  charge exorbitant prices for basic software
  resources. The days of high prices will come
  to a close."

Further reference Russell Pavlicek, D-Word
Dissection, InfoWorld, Vol 25, No 1, 6 Jan 03
32
In summary...

• JMASS has highlighted the DoD corporate need for
  a stable, consistent, well-managed,
  interface-based set of system and environment
  models.
• JMASS doesn't melt the DoD MS "Iceberg," but it
  does reveal a tip, complete with lessons learned.
  
• Composable simulations before composability was
  cool!
• Ability to compose simulations requires
  well-ordered mix of common (joint) MS standards
  and specific applications.
• Time is right for DoD to step up to the daunting
  task of actually managing combat-related MS
  software.

33
Recommendations

• DoD establish/fund a consortium-based approach to
  provide a stable, well-managed, consistent,
  interface-based set of system/environment models,
  and their supporting architectures.
• DoD support/fund JMASS-related consortia as a
  pilot effort for implementation of this
  consortium-based approach to manage MS resources
  for DoD engagement-level analysis applications.
• DoD explore opportunities to leverage SISO/SIW to
  support/implement application of a
  consortium-based approach to all DoD
  combat-related MS.

34
To contact JMASS Program Office

• http//www.redstone.army.mil/amrdec/jmass
• [phone] (DSN 478-)
• Lt Denise Herrera, Deputy Program Manager
• E-mail Denise.Herrera_at_hanscom.af.mil
• ESC/CXES
• 15 Eglin Street, Bldg 1607
• Hanscom AFB, MA 01731-2100