Print

Print


The term "Scenario" is quite overloaded in the M&S community.   The term is generally accepted as meaning:

Scenario = CurrentSituation(T) + CoursesOfAction(T+1); where T is time. The CoursesOfAction then change the current situation which triggers changes to COAs and the scenario continues to evolve.

MSDL was created to provide a stakeholder domain format of the scenario's Current Situation, independent of how it was to be instantiated. JTLS and other vendor formats are engineered instantiations of domain scenario content.  However, there are other formats on both the instantiation side and the stakeholder (military domain) side that are required to apply a scenario to a need (training, mission rehearsal, wargaming, etc). JEMMS is used to associate a master scenario event list to the instantiations. This builds upon a lot of road to war content (operations other than war) that was not fully covered in the first MSDL standard.  As I understand it the JEMMS scenario authors rely on open source intelligence (newspaper articles, etc) to collect event data, build storylines, and create branches / sequels for training. On the instantiation side, there is the network scenario that can include virtualized networks to separate concerns, or route data in meaningful ways.

I think the bigger issue to be answered is how all of these formats work together. That we have choices for scenario instantiation does not necessarily mean we have unnecessary duplication of formats. It is likely each instiation of a simulation has specific domain strengths (air, ground, sea, space, etc).  Even within the ground domain (Army), you have dismounted infantry, armor, engineering, intelligence, medical and other smaller domains.

So, what is the larger "pattern" of scenario content that makes sense of all of this? Scenario development typically begins on the domain side with road to war content (the current situation), then adds in courses of action. This is all on the domain side.  These domain formats are then transformed into engineering formats (instantiations), than ultimately are transformed back into domain formats for training, wargaming, etc (these transforms are largely enabled by C2SIM).

Let's revisit JEMMS.  JEMMS builds a database of the scenario events, storylines, branches and sequels. This starts with open source that is transformed into database content. JEMMS also provides the facilities for transforming the database content into operational formats (FRAGOs, news articles, scripts for role players, triggers or situational interrupts for SAF/CGF operators, etc.) used to stimulate training, mission rehearsal, or wargames. 

Then there is DSEEP that is used to align domain scenario content with the tools used to instantiate the scenario.  This is somewhat on a parallel path to JEMSS, but occurs on the systems engineering (domain) side. There appears to be a relationship between DSEEP and C2SIM that is worth more investigation; that could better unite all scenario development activities.

We have all of these moving parts, all of which relate back to the "road to war" content. I view the road to war as the common central model of the scenario that everything else in the scenario lifecycle links back to. It provides a foundation for creating DSEEPs' conceptual scenario and for C2SIM's ability to initialize a simulation.

We have a place to start...

From: SAC-PDG-PSG-C2SIM <[log in to unmask]> on behalf of Morse, Katherine L. <[log in to unmask]>
Sent: Saturday, January 26, 2019 5:04 PM
To: [log in to unmask]
Subject: Re: [SAC-PDG-PSG-C2SIM] History of scenario formats
 

If you’ve got a list of those, I’d love to have it. But it also might not be the case entirely. The process could be manual using pucksters with the pucksters reading from a spreadsheet of document.

 

KLM

---

Katherine L. Morse, PhD

Principal Professional Staff

JHU/APL

11100 Johns Hopkins Road

Laurel, MD  20723-6099

(240)917-9602 (w)

(858)775-8651 (m) 

 

 

From: SAC-PDG-PSG-C2SIM <[log in to unmask]> on behalf of Douglas Reece <[log in to unmask]>
Reply-To: SAC-PDG-PSG-C2SIM <[log in to unmask]>
Date: Saturday, January 26, 2019 at 8:43 AM
To: "[log in to unmask]" <[log in to unmask]>
Subject: Re: History of scenario formats

 

Katherine:

 

You mention a JTLS "proprietary" format. If you include those, then probably every constructive simulation product has a format that could be included as well.

 

Doug

 

On Fri, Jan 25, 2019, 5:44 PM Katherine L. Morse <[log in to unmask] wrote:

So, here's what I've found so far. If anyone has any other leads, I'd appreciate having them.

One of the earliest scenario generators was the Training Scenario Generator (TSG), developed for a NASA space shuttle flight controller simulation [Loftin 1987]. As early as 1997 [Bowers], attempts were made to automatically generate training scenarios (event-sets) from a database of individual training requirements (events).

The Joint Theater Level Simulation (JTLS) [Rolands], begun in 1983 [Wikipedia], has a proprietary scenario database.

Joint Exercise Management Module (JEMM) [NATO] is a web-based application designed to support exercise planners, control organizations, and analysts in the design, conduct, and analysis of training and exercise events. JEMM focuses on Main Events List/Main Incidents List (MEL/MIL) scripting and management. JEMM was first deployed in 2004.

The Joint Training Data Services (JTDS) for the Joint Live, Virtual, Constructive (JLVC) Federation, first released in 2007 [Bowers], provides data inputs to scenario generation. Scenarios are stored in JLVC-specific Order of Battle System (OBS) XML format to be read at federation initialization. [This suggests that only the OOB is stored in the scenario file and not runtime events

Coalition Battle Management Language (C-BML) [SISO 2014] is a standard language for expressing and exchanging plans, orders, requests, and reports across command and control (C2) systems, live, virtual and constructive (LVC) modeling and simulation (M&S) systems, and autonomous systems participating in Coalition operations. It describes the data model as a subset of Joint Consultation Command and Control Information Exchange Data Model (JC3IEDM) and specifies the information exchange content and structure in the form of an XML schema. C-BML is properly a runtime data exchange model for expressing events during simulation execution rather than a scenario specification language.

It wasn’t until the advent of Military Scenario Definition Language (MSDL) [SISO 2006] that effort shifted to defining a tool-independent scenario format. The MSDL XML schema is based on the schema of the same name developed for the OneSAF Objective System (OOS). The result of this effort is the MSDL standard [SISO 2015].

There are references to Army Warfare System (AWARS) Millennium Challenge 2002/Combined Arms Planning and Execution System (MC2/CAPES) scenarios, but no evidence of a prescribed format.

KLM
---
Katherine L. Morse, PhD
Principal Professional Staff
JHU/APL
11100 Johns Hopkins Road
Laurel, MD  20723-6099
(240)917-9602 (w)
(858)775-8651 (m)

########################################################################

To unsubscribe from the SAC-PDG-PSG-C2SIM list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-PSG-C2SIM&A=1

 


To unsubscribe from the SAC-PDG-PSG-C2SIM list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-PSG-C2SIM&A=1



To unsubscribe from the SAC-PDG-PSG-C2SIM list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-PSG-C2SIM&A=1



To unsubscribe from the SAC-PDG-PSG-C2SIM list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-PSG-C2SIM&A=1