Design Plan JTLS-2012-11413
ROLANDS & ASSOCIATES Corporation
JTLS-2012-11413 Expand Six Part ICC MISREP
Reenah Kang, Patrick Sandoz
1.0 Summary of Model Change Request
JTLS must be able to produce Air Mission Reports (MISREPs) in ICC 2.8.2 format following
ADATP3 standard. The MISREP produced by JTLS needs to be broken into six parts according to
the new ICC 2.8.2 data structure.
2.0 Design Summary
This ECP provides for developing messages based on the mission information compiled by the
model during the life of a mission. These partial mission messages will be transmitted built and
transmitted as specific key mission events occur. This key event data (such as enemy air defense
engagements) will be retained by the mission, as is currently done, and subsequently used to
build the final MISREP upon mission completion.
3.0 Detailed Design
In addition to developing the structures that allow key mission event data to be used to update
the ICC as the mission progresses, the ECP also provides for some changes to what mission
information is collected by the CEP in preparation for an end of mission MISREP message. It also
provides for changes to how that data are formatted for presentation to Players and Controllers
on Message Browsers at their WHIPs.
3.1 Message Building
Throughput a run of JTLS, various "messages" describing exercise events are developed by the model
and are made available to Players at their WHIPs. At appropriate times, the CEP creates streams of
data representing messages, saves the data to disk, and lets Player and Controller WHIPs know that
there are messages to be read.
The JTLS Support Tool called XMS (XML Message Service) provides message notifications to the
WHIP Message Browsers. Players see the title and a date for each message. Messages are held on the
server until Players elect to read them. When a message title is selected for viewing, the data stream
representing the message is delivered to the Message Browser. The Message Browser in turn formats
that data stream in accordance with the format selection chosen by the Player at the WHIP.
JTLS 4.1.0.0
607
25 February 2013
ROLANDS & ASSOCIATES Corporation
Design Plan JTLS-2012-11413
3.2 Message Numbering
There are currently a total of 330 individual messages that can be generated by the CEP for
viewing on a WHIP. The format definition for each is held in an individual file built specifically for
that message. Each message is assigned a “message number”. The individual Message
Definition Files (MDFs) are named using the appropriate message number, for example
2100.mdf, and held in the appropriate configuration managed directory. These numbers are
designed primarily for internal use, and are not displayed on WHIPs.
For example, Message 2360 is the message created when an HRU has been destroyed. It is a
“SPOT REPORT” format message, and is relatively short. Other messages are longer, and require
more effort for the CEP to prepare. For example, the 4310 message is the Logistics Report, and
is significantly longer due in large part because of the various selection options on the Logistics
Report Query order.
This design provides for changes to the 3180 Message, the Mission Report. This message is not
only one of the longer ones, but is also one of the more complex messages that the CEP
generates. Section 3.4 both describes the current structure of the 3180 message, and also
outlines the changes to be made to it.
The ECP also provides for developing several "hidden" messages, numbered 9998. These will be
built using the same data used to construct the final MISREP. However the 9998 messages will
be used by the JTOI to provide COP updates to ICC as the mission progresses.
3.3 Message Format Files
In order to understand the changes to be made to the Mission Report message, it is necessary to
know about how the various message data files are built, maintained, and accessed.
A JTLS delivery currently includes two configuration managed directories that hold message
definition files: English and MTF. The difference is that the English directory includes message
definition files for ALL messages, while the MTF directory holds only a subset of the complete list
of message definition files.
The idea is that not all messages require an MTF format, so there is no need to maintain one.
Examples include those messages that are for Controllers only - such as the Restart Complete
message. These would never be sent to a C4I system, so MTF formatting is irrelevant. The English
directory holds the master set of files. The English formatting file for a message is used when
either the Player has selected "english" as the desired format for messages. All message are
formatted using the appropriate numbered file from this directory.
If however, the user selects "MTF" as the desired format for messages, then the Message
Browser must make a decision as to how each message is formatted. When a message is
selected to be read, one of two situations will exist:
25 February 2013
608
JTLS 4.1.0.0
Design Plan JTLS-2012-11413
ROLANDS & ASSOCIATES Corporation
• MTF Definition DOES Exist for the Message Number
If the selected message number DOES have a MTF definition, then the data stream
representing the message is formatted in accordance with the MTF format definition for it.
• MTF Definition DOES NOT Exist for the Message Number
In this case, the message is still displayed for viewing on the Message Browser. But since
there is no MTF format definition, the Message Browser uses the English format do
display the data in the message.
Most of the Controller-only messages do not have a corresponding MTF format definition. None is
really needed.
Starting format selection determined by Exercise Control when each WHIP is defined during the
configuration process. Players can switch to different format files at will at any time during the
game. In other words,
The 9998 messages that will be referenced throughout this design are not held in the MTF or
English message data files. They are formatted by a different method. However, the data in them
will be the same data that will eventually be used to construct the 3180 message, either in
English or in MTF format.
3.4 Current Mission Report Message
For any given message (including the 3180 message) the data are divided into a few or
sometimes many "Submessages". This is done so that individual parts of the entirety of the
possible message data can added or not added to a message as the situation dictates. For
example, on a Situation Report message, there is a section (a Submessage) that lists all the
foreign units the unit in question is fighting. If the unit is not in combat with anyone, then the
specific Submessage is simply not written to the string of data representing the message.
The 3180 message has a total of 29 possible Submessages that can be added to a specific
MISREP depending on the type of mission and what has transpired during the mission life. Many
of these Submessages have their own list of possible sub-Submessages. For example,
Submessage 22 to the MISREP has a total of 120 possible submessages of its own.
The following Submessages are part of the current Mission Report Message
• SUBMESSAGE 1 - Mission routing information
• SUBMESSAGE 2 - Mission launch and recovery locations
• SUBMESSAGE 3 - Mission target designations
JTLS 4.1.0.0
609
25 February 2013
ROLANDS & ASSOCIATES Corporation
Design Plan JTLS-2012-11413
• SUBMESSAGE 4 - Not used at present
• SUBMESSAGE 5 - Mission damage reports
• SUBMESSAGE 6 - Reports of enemy air defense engagements
• SUBMESSAGE 7 - Reports of enemy aircraft encounters
• SUBMESSAGE 8 - Aircraft Losses Summary
• SUBMESSAGE 9, 12, 14, 15, 16, 17 - Pre-launch mission cancellation reasons
• SUBMESSAGE 10, 11, 18, 21 - Reasons why the mission was Destroyed
• SUBMESSAGE 13 - Mission Complete statement
• SUBMESSAGE 17 - Mission Results summary
• SUBMESSAGE 22 - This submessage includes detailed, event by event mission activity.
Individual mission events are described in its Submessages 1 to 120.
• SUBMESSAGE 23, 24 - These place "nothing more to report" endings at appropriate
places.
• SUBMESSAGE 25, 26, 27, 28, 29 - These relate to the Mission Load carried, and its usage
3.4.1 Current Mission Report Examples
The Mission Report (3180) message is a complex message. It is generated shortly after the
mission lands. It is also generated if the mission is terminated for some other reason. For
example, the model still generates a report if the mission is killed during flight. Also, mission
reports are generated for missions that never actually took off - perhaps having been cancelled
by a Player before launch.
Unlike most other messages, the mission report is not created by the model just before the CEP
sends it. Rather, as the mission is flying, all the various key events in the mission are being
recorded and archived (the mission going to a Tanker for fuel, the mission conducting a ground
attack, a surface to air engagement of the mission, and so on). We will take advantage of this
method of holding data at the mission entity level when building the individual ICC update 9998
messages.
The following is an example of a nominal 3180 message, first formatted in MTF format and then
in English format.
3.4.1.1 MTF MISREP Format
25 February 2013
610
JTLS 4.1.0.0
Design Plan JTLS-2012-11413
ROLANDS & ASSOCIATES Corporation
280323ZDEC99 (0.141180)
EXER/pat41//
MSGID/MISREP/500TFS/1/DEC//
MSNID/RDREC/2AW/-/3231-280//
UNID/500TFS//
ROUTE/280239Z/502114N0084034E/RH
/280250Z/503038N0104053E/RH
/280258Z/505804N0115713E/RH
/280302Z/511409N0115507E/RH
/280309Z/505350N0110812E/RH
/280310Z/505247N0105332E/RH
/280323Z/502154N0084048E/RH
//
FLTDTAIL/NONE /NAME:2 AIR WING/4/AIRAND/280239Z
/LATS:502154N0084048E/280323Z/-/-//
TIMESPEC/TFRM:TASK/280239Z/280323Z//
TGTPOS/AAA SITES/ENEMY POSITION/-/POSNID:511409N0115507E//
SAFIRE/ZSU23-/2/LATS:505350N0110812E/280309Z/ALT:120/HEAVY//
DETAILED MISSION INFORMATION:
280301ZDEC99 ARRIVED ON STATION. STARTING TO PATROL
280309ZDEC99 FIRED WEAPONS
FIRED HARM AT 102ADA-ZSU02 HIT FIRE CONTROL SENSORS
DAMAGED 102ADA-ZSU02
ATTACKED 102ADA-ZSU02 KILLED 1 FIRE CONTROL SENSORS.
ATTACKED 102ADA-ZSU02 KILLED 1 FIRE CONTROL SENSORS.
ATTACKED 102ADA-ZSU02 KILLED 1 LAUNCHERS
ATTACKED 102ADA-ZSU02 KILLED 0 LAUNCHERS
ATTACKED 102ADA-ZSU02 KILLED 1 LAUNCHERS
ATTACKED 102ADA-ZSU02 KILLED 0 LAUNCHERS
ATTACKED 102ADA-ZSU02 KILLED 1 LAUNCHERS
ATTACKED 102ADA-ZSU02 KILLED 0 LAUNCHERS
ATTACKED 102ADA-ZSU02 KILLED 1 FIRE CONTROL SENSORS.
280323ZDEC99 CALL SIGN: NONE REPAIRING COMBAT DAMAGE
EXPECTED AVAILABILITY: 300648ZDEC99
THIS LOAD CONTAINED THE FOLLOWING:
WEAPON
LOADED
RETURNED
USED
SPARROW
8
8
0
HARM
16
0
16
//
DECL/DERI:JWFC/-/-/X1//
3.4.1.2 ENGLISH Format
JTLS 4.1.0.0
611
25 February 2013
ROLANDS & ASSOCIATES Corporation
Design Plan JTLS-2012-11413
280323ZDEC99 (0.141180)
JTLS Exercise ratest41
Mission Report for 3231-280003 Belonging to 500TFS
Type: ARMED_RECCE
The Mission Flew along the Following Route:
280239ZDEC99
50-21-14.6N 008-40-34.8E
280250ZDEC99
50-30-38.7N 010-40-53.7E
280258ZDEC99
50-58-04.0N 011-57-13.1E
280302ZDEC99
51-14-09.0N 011-55-07.0E
280309ZDEC99
50-53-50.9N 011-08-12.2E
280310ZDEC99
50-52-47.6N 010-53-32.0E
280323ZDEC99
50-21-54.6N 008-40-48.0E
Departed From:
Returned To:
Designated Target:
At location:
TOT:
Damage Reported:
50-21-14.6N 008-40-34.8E at 280239ZDEC99 With 4 F16
50-21-54.6N 008-40-48.0E at 280323ZDEC99 With 4 F16
AAA_SITES ENEMY_POSITION From 51-14-09.0N 011-55-07.0E
280309ZDEC99
Mission Encountered the Following Air Defense Activity:
Time: 280309ZDEC99 Site: ZSU23-4
Fired: 2
Location: 50-53-50.9N 011-08-12.2E Lost A/C: 0 Alt: 120 (Hundreds of
Feet)
Mission complete - Returned with 4 aircraft.
Detailed mission report for 3231-280003:
280301ZDEC99 Arrived on station. Starting to patrol area.
280309ZDEC99 Expended weapons.
Fired HARM at 102ADA-ZSU02 hitting fire control sensors from
12000 feet.
Damaged 102ADA-ZSU02.
Attacked 102ADA-ZSU02 killed 1 fire control sensors.
Attacked 102ADA-ZSU02 killed 1 fire control sensors.
Attacked 102ADA-ZSU02 killed 1 launchers.
Attacked 102ADA-ZSU02 killed 0 launchers.
Attacked 102ADA-ZSU02 killed 1 launchers.
Attacked 102ADA-ZSU02 killed 0 launchers.
Attacked 102ADA-ZSU02 killed 1 launchers.
Attacked 102ADA-ZSU02 killed 0 launchers.
Attacked 102ADA-ZSU02 killed 1 fire control sensors.
280323ZDEC99 Call Sign: NONE repairing combat damage.
Expected availability: 300648ZDEC99
280323ZDEC99 Call Sign: NONE repairing mechanical failure.
Expected availability: 290716ZDEC99
280323ZDEC99 2 aircraft entered routine maintenance. Available shortly
Nothing further to report.
The aircraft were carrying
load BLUE.WILD.WEASL.
25 February 2013
612
JTLS 4.1.0.0
Design Plan JTLS-2012-11413
Weapon
SPARROW
HARM
ROLANDS & ASSOCIATES Corporation
Loaded
8
16
Returned
8
0
Used
0
16
3.5 The 9998 Messages
To meet the ICC 2.8.2 requirements, a total of eight separate (but related) individual types of
9998 messages will be utilized. These messages will be processed by the JTOI and the ICC will be
updated.
The "9998 1" message is already in use for a slightly different purpose. It is used to let the JTOI
know that an end-of-mission MISREP (in the existing format) has been generated by the model
and is ready for acceptance.
The next six 9998 message types will be the "9998 2" through "9998 7" messages. These will be
used to report to the COP various key non-attack events during mission life. Six type of events will
be reported. These are described in the six Field Sets directly below the MISREP Tab as defined
for the ICC 2.8.2 MISREP TOTE Application.
The basic "9998 2 (through 7)" structure will be the following:
9998 misrep_type
mission_name
DTG (in decimal days after game start)
decimal_lat decimal_long (current mission location)
&event description& (for each individual 9998 type)
The integer references to the six possible entries in the "misrep_type" field will:
• 2 for EWSPT - Electronic Warfare Support Intercept Data
• 3 for JAM - Reporting The Presence Of Jamming
• 4 for SAFIRE - Enemy Surface to Air Engagement
• 5 for ENINCEPT - Foreign Aircraft Intercept
• 6 for ACLOS - Reporting Loss Of One Or More Aircraft
• 7 for SIGHTING - Not Used At Present
In the MISREP example in Section 3.4.1, a SAFIRE event was reported in the 3180 message. That
event, will now also generate a “9998 4" message of the following form:
JTLS 4.1.0.0
613
25 February 2013
ROLANDS & ASSOCIATES Corporation
Design Plan JTLS-2012-11413
9998 4 3321-280003 0.13125 50.897222 11.1366667 & ENGAGED BY: 1 ZSU23-4 A/C
LOST: 0 ALT: 120 FT&
In this case, the SAM AAA site missed, so no ACLOS (aircraft lost) message would be generated.
As another example, the ENINCEPT message (9998 5) will be structured as follows. Note that
this message was build from a different example game.
9998 5 Q_CAP-280002 0.090032 50.6226750
ALT: 50000 FT &
9.3712945 &
INTERCEPTING 2 MIG27,
The final type of 9998 message to be generated is the "9998 8" message. This message is
processed by JTOI and appropriate database elements are updated in the ICC when the mission
deploys air to ground weapons. The structure of the "9998 8" message will be the following:
9998 8
mission_name
ut.short.name (or tg.ccf.number)
&ut.long.name& (or tg.name)
jdpi_description (or "-" if not a JDPI)
ut.country.code (or tg.country.code)
dec.lat
dec.long
DTG (Time of weapon delivery, in decimal days)
course (Degrees)
speed (FAST, MEDIUM, SLOW, NO_SPEED)
&target element description& (20 characters or less)
number destroyed
result (OPR, LOP, NON, DESTR, DAMAG)
impact point (dec lat)
impact point (dec long)
weapon_type (from the list of legal values, FFIRN/FUDN 1477/224)
number_weapons_dropped
enemy_activity_type (If applicable, ATTACK, DEFEND, MOVE, COUNTER BATTERY,
DIRECT SUPPORT, MINE CLEARING, RESUPPLY, TRANSPORTING, OTHER, UNKNOWN)
activity location (lat)
activity location (long)
The CEP already collects the majority of the data required for these structures. In the cases
where the CEP does not collect the needed data for the particular message, some changes may
be made. When possible, we will cause the model to build and collect the needed data for the
mission. When this is not possible, default (or nominal) values of the data will be provided in the
field to compete the structure of the specific message.
The expectation is that only minor changes will be needed to the data already compiled and held
by the mission entity as it carries out its tasking.
25 February 2013
614
JTLS 4.1.0.0
Design Plan JTLS-2012-11413
ROLANDS & ASSOCIATES Corporation
In the MISREP example in Section 3.4.1, weapons were expended and subsequently reported in
the 3180 message. Each weapon delivery event, will also generate a "9998 8" message such as
the one that follows (taken from that MISREP data):
9998 8 3321-280003 102ADA-ZSU02 &102.ZSU.2& QQ 50.8974722 11.1367222
0.090032 0 NO_SPEED &fire control sensors& 1 DESTR 50.8974722 11.1367222
HARM 1 OTHER 50.8974722 11.3033889
3.6 Implementation Comments
The code to generate these seven message type will be encapsulated beneath a single
subroutine in the CEP code. Calls to that subroutine will be made from the various (and
numerous) places in the rest of the CEP where the individual events are processed. The
advantage to doing this is that if changes to the structure of the messages will be relatively easy.
The CEP, during the life of a mission, saves various mission event data in sets of items owned by
the mission entity. These sets, the AM INFORMATION SET and the AM MESSAGE SET, are what
the model uses to build the end-of-mission MISREP message. The calls to the routine that writes
the new "9998 n" messages throughout the mission life will be made at the same time that the
data for each appropriate mission event are placed in the applicable mission data set. This
means that there will be a direct correspondence between each "9998 n" message and some
line item in the final MISREP.
We do not foresee a need to repeat all the "9998 n" messages created during the life of the
mission again at the completion of the mission. This seems redundant since each of them has
already been sent once to the ICC and since the currently existing MISREP message will still be
available. However, since all the data for the individual events exist in the mission data sets just
described, this is certainly possible.
4.0 Data Changes
No database parameter or structure changes are required to implement this design.
5.0 Order Changes
No order parameter or structure changes are required to implement this design.
6.0 JODA Changes
No JODA Data System parameter, structure, or protocol changes are required to implement this
design.
JTLS 4.1.0.0
615
25 February 2013
ROLANDS & ASSOCIATES Corporation
Design Plan JTLS-2012-11413
7.0 Test Plan
25 February 2013
616
JTLS 4.1.0.0