Joint Modeling and Simulation System JMASS What it Implies,and What that Means

About This Presentation

Title:

Joint Modeling and Simulation System JMASS What it Implies,and What that Means

Description:

First prototype set the stage by having agencies with authority/expertise do the ... example could be (re)used in other engagement-level applications, e.g., air-to-air ... – PowerPoint PPT presentation

Number of Views:345

Avg rating:3.0/5.0

Slides: 40

Provided by: robertj160

Category:

more less

Transcript and Presenter's Notes

Title: Joint Modeling and Simulation System JMASS What it Implies,and What that Means

1
Joint Modeling and Simulation System (JMASS)What
it Implies,and What that Means!
Briefer Bob Meyer, JMASS JPO
Navy Senior Engineer Date 11 September 2001
2
Purpose of this Presentation
Review five basic "truths" of the JMASS approach
"truths" that reveal how JMASS embodies changes
of the type that are often lumped together under
the moniker of "paradigm shift."
Identify the implications of JMASS, both for the
modeling and simulation development community and
for the engineering and engagement (and mission)
level analysts.
Discuss the meaning of these implications and how
they will strongly shape JMASS' actual benefit to
the DoD community.
3
What is JMASS ?

JMASS software (as it comes on the CD or through
the download) consists of the following
the architecture, consisting primarily of a
simulation engine and associated services
interface standards between this architecture and
the various system and phenomena models which
might make up a JMASS simulation
a variety of GUI-based tools to assist in this
process, from building a model, to assembling
models into a simulation, to analyzing results of
a simulation run

4
"Truths of JMASS"

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"

5
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
Track Radar
Missile
Aircraft
ECM Sys
RF Env
6
"Truths of JMASS"

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"

7
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
Track Radar
RF Signal Data Structure
Missile
Aircraft
ECM Sys
RF Env
8
"Truths of JMASS"

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
Views/aspects of a (SAM) simulation
Port Mechanism

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
Track Radar
RF Signal Data Structure
Missile
Aircraft
ECM Sys
RF Env
10
"Truths of JMASS"

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"

11
Views/aspects of a (SAM) simulation
Port Mechanism

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
Track Radar
RF Signal Data Structure
Missile
Aircraft
ECM Sys
RF Env
12
"Truths of JMASS"

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"

13
Views/aspects of a (SAM) simulation
Code Generation
Port Mechanism

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
Track Radar
RF Signal Data Structure
Missile
Aircraft
ECM Sys
RF Env
14
Implications of JMASS paradigm

"User assembly required" nature raises issues
Who builds the models? Coordination, resources,
etc.
JMASS is distributed development
Interface-based MS both flexible and challenging
Any problem solvable big effort for any "first"
problem
JMASS is simulation integration
Reuse eminently possible, but is NOT "automatic"
Must be promoted by processes and/or
infrastructure
JMASS is software reuse (and interoperability)

15
JMASS is distributed development

JMASS has been about distributed development from
its very inception
First prototype set the stage by having agencies
with authority/expertise do the model development
Threat system representations defined by the
various DIA intelligence production centers
Blue system models envisioned for definition by
the appropriate system program offices
Environment models done by the JPO initially, but
planned for transition to subject matter working
groups

16
Simulation/model requirements

Look at JMASS paradigm from two perspectives
Analyst-user view comes from simulation
application
Analyst has specific problem to solve, question
to answer
Usually involves interaction between
models/players
Developer-user view comes from model applications
Develops model(s) for multiple simulation
applications
Multiple applications may (probably do!) have
different requirements for models of the same
object class or type
Suggests an orthogonal (matrix) type of solution
Analyst requirements guide developer requirements
Documentation of requirements is absolutely
essential
Both for the analyst-user and the developer-user

17
Matrix view of the JMASS system
18
JMASS is distributed development

Assignment and acceptance of "ownership" for the
model classes is essential for JMASS to work
Without assignment, development will never begin
Without acceptance, development will never
complete
Without both, development at first stagnates and
eventually fractionates into irrelevance
Notion of "ownership" also key to effective reuse
Very dependent on informed oversight of what
exists to know what can be considered as reuse
candidates
Distributed development does introduce the need
for a separate simulation integration activity

19
JMASS is simulation integration

Simulation integration begins with decomposition
of the analysis problem to be solved
Identification of players and interactions among
them
Statement of functionality needed to answer the
mail
Functionality player list model requirements
Player roles in simulation dictate player
requirements
Additional "players" may need to be added to
complete the functionality, e.g., metric
collectors
Decomposition is simple, adaptation is harder
Reusing (integrating) existing models/players,
even those built to "standards" is not simple nor
automatic
Existing models built for some other analysis
problem recognizing all aspects of this may be
the hardest part

20
JMASS is simulation integration

Consider an analogy with LEGOs K'NEX
Toys based on connectable, interface-based
piece-parts
Modern day Lincoln Logs, Tinker Toys, Erector
Sets
Reusability of these toys aimed at very low level
Focused on basic, simple (atomic) "building
blocks"
Reusable components don't "look like" anything
LEGOs and K'NEX address a different reuse-type
question than does JMASS
LEGOs/K'NEX ask, "What can I make with these
parts?"
JMASS simulation integration quite differently
asks, "What parts (models) do I need to make this
(simulation)?"

21
JMASS is reuse (and interoperability)

The half-century of software development history
has not been inspirational w.r.t. software reuse
Once thought that after all algorithms had been
coded, the need for computer scientists would
evaporate
Growth of computer science gives the lie to this
thought!
The failure or very slow progress of software
reuse is fundamentally a cultural, vice
technical, issue
Not really a computer science job security
initiative!
Caused by the lack of a process and/or
infrastructure to promote, support or even make
reuse possible

22
JMASS is reuse (and interoperability)

Software reuse in MS can/does occur at all
levels
Certainly occurs at the simulation level using
HLA
Often occurs at the services/sim engine level in
SSE's
Simulation Support Environments, such as JMASS!
Occurs at the "primitive" level in electronic
circuit MS
"Primitives" are components like gates, switches,
etc.
Debate rages over optimum level of software reuse
Famous "bathtub" curve seems to suggest that
middle ground is most cost effective - balances
speed/complexity
JMASS reuse currently focused at the player level
"Aircraft" player in RF SAM example could be
(re)used in other engagement-level applications,
e.g., air-to-air

23
View of IOC SA-8 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 (C)
Balanced fidelity
Separate sim engine
Inter-player interface visible/concise
Multiple developers
Integration requires separate activity

JMASS 5.1
SIMULATION
Model Interfaces
Simulation Engine
Acq Radar
SA-8 Threat
Track Radar
Simple Target (as F-15E)
Missile
Aircraft
ECM Sys
JMOOSE 4.1.1
RF Env
24
View of IOC SA-7 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 (C)
Balanced fidelity
Separate sim engine
Inter-player interface visible/concise
Multiple developers
Integration requires separate activity

JMASS 5.1
SIMULATION
Model Interfaces
Simulation Engine
Operator
SA-7 Threat
Seeker
AH-64 Model
Missile
Helicopter
IRCM Sys
EO/IR Env Player 3.0
EO/IR Env
25
Now substitute F-15E for AH-64!

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 (C)
Balanced fidelity
Separate sim engine
Inter-player interface visible/concise
Multiple developers
Integration requires separate activity

JMASS 5.1
SIMULATION
Model Interfaces
Simulation Engine
Operator
SA-7 Threat
Seeker
Simple Target (as F-15E)
Missile
Aircraft
IRCM Sys
EO/IR Env Player 3.0
EO/IR Env
26
Or the AH-64 for the F-15E!

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 (C)
Balanced fidelity
Separate sim engine
Inter-player interface visible/concise
Multiple developers
Integration requires separate activity

JMASS 5.1
SIMULATION
Model Interfaces
Simulation Engine
Acq Radar
SA-8 Threat
Track Radar
AH-64 Model
Missile
Helicopter
ECM Sys
JMOOSE 4.1.1
RF Env
27
JMASS is reuse (and interoperability)

Focus on player reuse doesn't stop other reuse
Every time the JMASS architecture is (re)used
reuse occurs, irrespective of whether any players
are reused!
Every time the JMASS environment players are
(re)used, reuse of JMASS players becomes much
easier
Process and/or infrastructure essential to reuse
Architecture has been successful because a
process (JORD) and infrastructure (JPO) have been
in place
"Ownership" of model classes just as essential
Informed, funded management of models must occur
Solves the requirement (process) and
organizational (infrastructure) needs of JMASS
paradigm shift

28
JMASS is reuse (and interoperability)

Interoperability included parenthetically because
it is somewhat tangential to JMASS currently
Term originated with hardware considerations for
fielded systems to work properly together
Has been expanded to include situations where MS
software needs to function with fielded systems
as well
JMASS can with proper model definition support
interoperability in this way
Some experiments with JMASS have already done so

29
Implications of JMASS paradigm

"User assembly required" nature raises issues
Who builds the models? Coordination, resources,
etc.
JMASS is distributed development
Interface-based MS both flexible and challenging
Any problem solvable big effort for any "first"
problem
JMASS is simulation integration
Reuse eminently possible, but is NOT "automatic"
Must be promoted by processes and/or
infrastructure
JMASS is software reuse (and interoperability)

30
The meaning of what JMASS implies

Distributed development, simulation integration
and software reuse focus on two common themes
Decomposition of analysis problems into system
and environment players, including model
requirements, as illustrated by the rows on the
matrix view of JMASS
Development, "ownership" and management of system
and environment models, as illustrated by the
columns on the matrix view of JMASS

Essential to JMASS a stable, reusable,
well-managed set of system and environment models
31
Matrix view of the JMASS system
32
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
33
JVB/JSB Connections

Joint Virtual Battlespace (JVB - the Army
approach) Joint Synthetic Battlespace (JSB -
the Air Force term)
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

Essential to both a stable, well-managed,
consistent, interface-based set of system and
environment models
34
Has anyone addressed this?

Mr. Jim O'Bryon, Deputy Director for Live Fire
Test in the OSD/DOTE office, suggested in a
recent MS workshop that a consortium of subject
matter experts might be the best way to manage
MS resources.
Mr. O'Bryon's 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."

35
Implications of JMASS paradigm

"User assembly required" nature raises issues
Who builds the models? Coordination, resources,
etc.
JMASS is distributed development
Interface-based MS both flexible and challenging
Any problem solvable big effort for any "first"
problem
JMASS is simulation integration
Reuse eminently possible, but is NOT "automatic"
Must be promoted by processes and/or
infrastructure
JMASS is software reuse (and interoperability)

36
Implications of JMASS paradigm
Components of SBA Approach

"User assembly required" nature raises issues
Who builds the models?, ergo, distributed
development
Coordination difficulties, resource
identification/dedication
Interface-based MS both flexible and challenging
Almost any engagement/engineering problem
solvable
Sizeable coordination/effort to solve first such
problem
Reuse eminently possible, but is NOT "automatic"
Must be promoted by processes and/or
infrastructure
Requirements across application areas must first
be documented, then merged/deconflicted/coordinate
d

Collaborative Environments
Data Interchange Formats
Distributed Product Descriptions
37
Recommendations
DoD carefully consider and examine establishing a
consortium-based approach to satisfy the JMASS,
JSIMS, JWARS, JVB, JSB, and consequently SBA
dependence on a stable, well-managed, consistent,
interface-based set of system/environment
models. DoD leverage and support the JMASS
program as a pilot project for implementation of
a consortium-based approach to manage MS
resources in support of DoD engagement-level
analysis applications.
38
"It's time we face reality, my friends... We're
not exactly rocket scientists."
39
To contact JMASS Program Office