jtls-2008-10001 pass tacelint to real world systems(elint) collection mode is activated. the...

Design Plan JTLS-2008-10001 ROLANDS & ASSOCIATES Corporation

JTLS-2008-10001 Pass TACELINT To Real World Systems

Joel Modisette, Reenah Kang, Ellen Roland

1.0 Summary of Model Change Request

Tactical Electronic Intelligence (TACELINT) messages generated by JTLS must have the requiredinformation and proper format so they can be passed directly to real-world C4I systems.

Required information in a well-formed TACELINT message includes ELINT notation (ELNOT),emitter frequency, and emitter pulse repetition. This information is neither available to norrepresented by JTLS. Also, a real-world TACELINT feed for external C4I systems requires acontinuous stream of tactically dynamic message content. The volume of this continuous streamwill create processing overhead that would impact overall JTLS performance.

This model change request presents a preferred option for creating and passing ELINT data toexternal C4I systems. The design will externally resolve the issue of a well-formed TACELINTmessage supply without excessive CEP processing.

2.0 Design Summary

JTLS currently can generate TACELINT messages only if the National Electronic Intelligence(ELINT) collection mode is activated. The national capability will generate a Tactical ELINT(TACELINT) message each time a sensor with an ELINT Notation (ELNOT) code is turned on or off.The sensor can be represented by a JTLS Sensor target or by a Fire Control sensor associatedwith an Air Defense target. A summary message is periodically generated for all activeELNOT-specified Sensors.

This ECP resolves several known issues that involve the JTLS representation of TacticalElectronic Intelligence information:

• Only National ELINT collection is represented and is available 100% of the time. Themodel must represent airborne ELINT collectors and represent national-level cover, but ona more limited basis.

• Whether an Air Defense site is turned on or off cannot currently be known. The modelconsiders the site’s Rules of Engagement (ROE). The site is assumed to be turned on if ithas any positive ROE and has received permission to fire. A site for which all ROEs areHold Fire cannot be turned on. Similarly, users cannot turn off an electronic Fire Controlsensor and fire without greatly reduced accuracy. If a Fire Control sensor is destroyed, thesite may still have some ability to fire, depending on the data.

JTLS 4.1.0.0 225 25 February 2013

ROLANDS & ASSOCIATES Corporation Design Plan JTLS-2008-10001

• A realistic TACELINT feed must be continuous and the messages must be issued bymeans of a continuous feed instead of the current periodic mechanism.

• Electronic emissions from aircraft cannot be detected and reported. The model reportsemissions only from ground or sea-based Sensors, Jammers, and Fire Control sensors.

• The current JTLS capability cannot represent some of the most important electronicinformation, such as an enemy Air Defense site locking on to a target. This capability isalso desired for realism.

The collection and reporting of ELINT is a highly classified concept, but this design isunclassified. The format of a TACELINT message is unclassified, but the data it holds areclassified at special access levels. The JTLS design team has not referred to any documentation,classified or unclassified, to obtain realistic values for our examples. These examples are purelyfictitious, highly unreasonable, and are therefore intended to illustrate the capability to beimplemented with no possibility of providing classified data. When used within a real game, thedatabase must be classified at a level that is consistent with the data that are used.

3.0 Detailed Design

3.1 Background

Non-configuration managed data were quickly added to the JTLS 4.0 model in response to aspecific exercise event. These non-configuration managed data (Table 1) include two new SensorType data text attributes and three new Jammer Type attributes.

If a JTLS 4.0 Sensor or Jammer was functioning, specified a non-blank ELNOT, and the NationalELINT capability was activated, TACELINT messages for the Sensors and Jammers weregenerated. This example illustrates a TACELINT message generated for a functional Sensor withan ELNOT of ROL, a Frequency of 101.7HZ, and a Pulse Rate Interface of 45.5MS. Fields

Table 1. JTLS 4.0 ELINT Data

NEW DATABASE PARAMETERSENSOR TYPE

DATA

JAMMER TYPE DATA

ELNOT: Text string Existing in JTLS 4.0

New

Frequency: This text string includes the Hertz measure, such as 15HZ or 20MHZ.

New New

Pulse Rate: This text string represents the Sensor or Jammer pulse rate. New New

25 February 2013 226 JTLS 4.1.0.0


highlighted red are filled based on the game situation. All other fields are hard-coded in theMessage Definition file.

EXER/JTLS41/MSGID/TACELNT/NAT/5/NOV//COLLINFO/ZZ//SOI/-/280500Z/280500Z/ASR/RED LR AIR/QQ/102-SHIP-RDR/RED BB-28/-/AC//EMLOC/-/P/LS:491838N0050744E/-/-/-/-//PRM/-/101.7HZ/45.5MS//AMPN/SURFACE_SHIP_EMITTER FROM COMBATANT: TYPE NJCLASS.PROBABLE RED.BB-28 FROM RUSSIAN//DECL/DERI:SIMHQ/-/-/X1//

3.2 Collection Improvements

These ELINT collection capabilities will be represented:

• current 100% theater coverage,

• National Pass collection,

• stationary and mobile ELINT Target collection, and

• theater airborne asset collection.

This section describes each of these methodologies.

3.2.1 Existing Theater-Wide Collection

This capability is current, but the associated order will be modified to make it more user-friendly.The Assign National Assets order is currently used to establish this capability and specifies whichcollection modes cover the entire theater area 100% of the time. This order is used to establishthat ELINT covers the entire theater area, and also that the sensors capable of detecting TheaterBallistic Missile launches cover the area. This order currently has these fields:

• The Force Side that owns the theater-wide asset

• An indicator field as to whether coverage should be started, stopped, or simply reported

• ELINT Spot Report

• ELINT Report Interval

• TBM Report Modes opens a utility that has only one field to allow users to select severallisted options, IMAGERY, ELINT, VISUAL, RADAR, IR, ACOUSTIC, and OTHER, which arecurrently used to represent Communications Intelligence.

JTLS 4.1.0.0 227 25 February 2013


The current order is confusing because of these issues:

• The utility list is labeled "TBM Mode", but is also used to assign the National ELINTcapability, which is unrelated to TBM modes.

• The model inconsistently assigns theater-wide capability to a Force Side. The modelallows coverage for ELINT, and IR detection of TBMs only. For OTHER, the model allowsdetection of TBMs marked for detection by OTHER sensors, but COMINT is notimplemented.

• Users must ensure that a "fake" Target owned by the Force Side Commander exists toallow the TBM detections to work properly, but the ELINT has no such requirement. Thisissue is not directly related to this design, but is addressed as part of the order redesign.

This design eliminates the ELINT Spot Report and the ELINT Reporting Interval, whichsignificantly simplifies the order. Table 2 describes the new order panel layout.

Table 2. New Assign National Asset Order

FIELD GROUP FIELDS DESCRIPTION

Force Side The Force Side for which the national theater-wide capability is assigned.

Set or Show Selecting the proper radio button presents various options for this group.

Set Option IMAGERY Coverage (Optional)

A list of all feasible Imagery Sensors in the database will be displayed. Users can select the NONE option, which turns national Imagery off, or one of the Imagery Sensors. A selected Sensor will be the only imagery Sensor that covers the entire theater for the Force Side. No associated Target will be required.

ELINT Coverage (Optional)

The same as IMAGERY, but the list will include NONE and all ELINT Sensors in the database.

Visual Coverage (Optional)

The same as IMAGERY, but the list will include NONE and all Visual Sensors in the database.

Radar Coverage (Optional)

The same as IMAGERY, but the list will include NONE and all Radar Sensors in the database.

IR Coverage (Optional)

The same as IMAGERY, but the list will include NONE and all IR Sensors in the database.

Acoustic Coverage (Optional)

The same as IMAGERY, but the list will include NONE and all Acoustic Sensors in the database.

Other Coverage (Optional)

The same as IMAGERY, but the list will include NONE and all Other Sensors in the database.

25 February 2013 228 JTLS 4.1.0.0


3.2.2 National Asset Pass Collection

Information for the National Asset Pass is greatly expanded as part of JTLS-2012-11382 SatelliteService. A program is provided under that ECP to develop realistic national asset collectioncapabilities. Data include the:

• name of the National Mission,

• Sensor to be used by the mission,

• entry time into the theater,

• location of entry into the theater,

• exit time from the theater, and

• location of exit from the theater.

The number of Directed Search Areas (DSAs) that can be covered by the national capability isremoved from the order and replaced as an IIP TIME PER DSA COLLECTION IntelligenceInformation Prototype characteristic, as fully described in JTLS-2012-11382 Satellite Service.National asset sensors are limited to Surface Search sensors, as specified by the ST USEparameter.

Table 3 defines how the model will handle the various types of Surface Search sensors that canbe specified. The design team is not indicating that these capabilities exist in the real world, butis defining how the model will work under each of the feasible database alternatives.

To represent a geosynchronous asset, the theater capability described in Section 3.2.1 is themost appropriate and efficient.

Show Option No Fields. The current settings of each Sensor Type will be delivered to users as part of a returned message.

Table 2. New Assign National Asset Order (Continued)

FIELD GROUP FIELDS DESCRIPTION

JTLS 4.1.0.0 229 25 February 2013


3.2.3 Airborne Asset Collection

Air Missions currently work in many various ways, mainly to reduce processing time. This designintends to enforce consistency among all aircraft and mission types (Table 4). Region "tags" willbe placed on the terrain board for the Sensors highlighted green, if they have an ST REPORTINGMETHOD of REPORT.SWATH. Those sensors that require Directed Search Areas (DSAs) will notcreate covered region tags. The marked Sensors’ region tags will be dispersed immediately whenthe mission takes off and recovered when the mission lands. The tags will move as the AirMission moves.

Each type of tag can detect a specific set of objects, as annotated in Table 4. This informationdescribed in this table is the most important and must be thoroughly reviewed and accepted aspart of this design. Of greatest importance in enforcing these rules is the result that radarsensors on-board aircraft are no longer be able to collect ground intelligence information. Thismajor departure from previous JTLS versions allows a much more realistic representation of real-world capabilities.

Table 3. National Asset Pass Sensor Logic

ST COLLECTION MODE ST REPORTING METHOD

IMAGERYVISUALRADARIR

Only DSA reports will be generated for IIR or RECCEXREP as the national asset passes over the region.

SWATH detections will occur as accomplished for RECCE Air Missions that carry SWATH Sensors. Sensor "tags" will also be placed in all covered regions. Table 4 describes the use of these tags.

ELINT SWATH is the only logical reporting method. Tags representing the ELINT coverage will be moved as the National asset moves. Section 3.3 describes the use of these tags.

ACOUSTIC The design team believes that National Assets should not be allowed to hold ACOUSTIC Sensors. If a database builder includes this capability, the model will handle the situation in the same manner as IMAGERY Sensors.

OTHER(Renamed COMINT as part of this design)

SWATH is the only logical reporting method. Tags representing the COMINT coverage will be moved as the National Asset moves. Each tagged coverage region will be susceptible to obtaining information through the JTLS-represented communication model.

25 February 2013 230 JTLS 4.1.0.0


3.2.4 Stationary and Mobile Target Asset Collection

Each Surface Search and Air Search sensor Target currently places tags in each theater regioncovered by the Sensor when it is turned on or functional. The tags are moved if the Sensor movesfor any reason. A purpose of this design is to centralize how these tags are used; their functionshould be the same, regardless of which collection asset owns the tags. Consequently, the rulesapplied to airborne platform Sensors will be the same rules used for stationary and mobileTargets. Table 4 fully describes these rules.

Table 4. Sensor Activation Rules For All Platforms

COLLECTION MODE

ST USE

SURFACE SEARCH AIR SEARCH PASSIVE ACTIVE SONARCOUNTER-BATTERY

IMAGERY:VISUAL,IR

Tags are placed and can detect surface ships and TBM launches with the proper collection mode.

Tags are placed and can detect aircraft.

Assumed never to be set Tags are placed to detect artillery fire and automatically respond.RADAR

ELINT Tags placed and can detect emitting objects and TBMs launches with ELINT detection mode.

Assumed never to be set

Assumed never to be Sst

ACOUSTIC Tags placed and can detect surface ships and TBM launches with the ACOUSTIC detection mode.

Legal, but tags are not used to passively detect submarines.

Tags are placed and can detect any ship.

OTHER (COMINT)

Tags placed and can obtain communication information from the area and TBM launches with the OTHER (COMINT) detection mode.

Assumed never to be set

JTLS 4.1.0.0 231 25 February 2013


3.3 TACELINT Collection

Although Section 3.2 departs from the subject of this ECP, the described Sensor representationconsistency improvements are required to properly implement this design. This section describesTACELINT message generation.

3.3.1 Basic Design Concept

The JTLS Operational Interface (JOI) that manages all links to real-world C4I systems will beresponsible for distributing TACELINT messages. The information the JOI needs to accomplishthis task will be available from the JTLS Object Distribution Authority (JODA). Figure 1 depicts therelationship between these components.

FIGURE 1. Basic TACELINT Generation and Delivery

All connections are sockets or inter-program communication links that have been approved bythe Department of Defense (DoD) Information Assurance Certification and Accreditation Process(DIACAP). The connection between the JOI and the real-world C4I system is assumed to passthrough a security layer that does not directly involve the JOI.

These links are feasible because such a socket has been tested with the JTLS Message DeliveryProgram (MDP) in a recent exercise. The link worked properly and TACELINT messages weresuccessfully delivered to the real-world system, but the process was not workable from anexercise capability perspective. The MDP only delivered TACELINT messages generated by JTLS,which could not be generated at a rate that was sufficient to keep the secure line open to the C4Isystem without impacting the model, the management of model-generated messages, and theability of the XML Message Server (XMS) to process the messages.

3.3.2 Basic CEP Changes

This design proposes several changes that increase the fidelity of the emitter representation.These improvements are described in Section 3.4. This section explains the basic model

CEP JODA JOI

C4I System

25 February 2013 232 JTLS 4.1.0.0


changes to identify an emitting Sensor, which allow the JOI to generate and send the TACELINTmessage to the real-world system.

The existing JTLS Sensor attribute ST JAMMABLE FLAG will continue to be used to indicate thatthe Sensor is electronic and is emitting a signal from which an ELINT collection Sensor cancollect. All JTLS Jammers are assumed to be electronic and their emissions can also be subjectto collection by an ELINT Sensor.

Jammers and Sensors can be associated with JTLS objects, as described in Table 5, but onlythose Sensors and Jammers associated with a JTLS Target or Air Mission can be detected by anELINT collection asset.

Under these circumstances, the CEP will consider the feasible emitting object and determinewhether it is emitting. If the object is emitting, the model will determine which Force Sidescurrently have an ELINT “tag” that covers the object’s region location. If such a tag exists, themodel will set each appropriate Side’s perceived emitting flag for the object in the JODA.

• When an emitting Target moves into a another hex, including when a new Target iscreated, magic moved, or arrives in theater, the check for an ELINT tag occurs for eachscenario Force Side. If the tag exists, the Side’s perceived emitting flag is set to “true”. Ifthe tag does not exist, this flag is set to “false”.

• When an emitting Air Mission moves into a another hex, the same check is performedwith the same results.

• When a Target is turned on or turned off, the same check must be performed. TheEmission Control order can currently be used to control specific Sensors and Jammers.However, SAM sites do not have this capability and are assumed to be emitting while theyhave a positive ROE. Section 3.4.2, describes how this design changes this logic to makeSAM sites’ capabilities match the Sensor and Jammer targets.

Table 5. Sensors And Jammers Subject To ELINT Collection

OWNING OBJECT SENSORS JAMMERS

Target: Sensor, Jammer, and Surface-to-Air Missile (SAM) Targets with a jam-capable Fire Control sensor.

Can be collected on if they are considered emitters, turned on, and not damaged.

Air Mission

National Capability Feasible in JTLS, but will not be subject to ELINT collection. These assets can collect ELINT, but are not subject to collection.

Not represented in JTLS

National Asset Pass

JTLS 4.1.0.0 233 25 February 2013


• Users have previously requested the capability to specifically turn on and turn off Sensorand Jammer capabilities onboard aircraft. This capability is part of this design and isdescribed in Section 3.4.1. Therefore, the ELINT collection check must be performedwhen an airborne Sensor is turned on or off.

• When an ELINT Target moves, including when a new Target is created, magic moved, orarrives in theater, all of its associated coverage tags move. For any region that has achange in coverage, the model must check the region for emitting Targets and AirMissions. If coverage is lost or gained, the associated perceived emitting flag must beupdated in the JODA.

3.3.3 JODA Changes

Two JODA changes are needed to support this design.

3.3.3.1 New Emitter Object

A new Emitter object type will be created in the JODA. This object will be created the first instancean ELINT collection asset detects a Target or Air Mission. Only one Emitter object is needed foreach emitting Target or Air Mission. Air Missions can have multiple emitting assets, but the CEPwill create only one Emitter object for each Air Mission. The active and functional Sensor orJammer emitter with the greatest power will comprise the single Air Mission emitter source ofinformation sent to the JODA.

The associated Emitter object will be destroyed if an Air Mission is destroyed. A Target emitterthat is created will remain as an active JODA object, even if no ELINT collection asset is coveringthe Target.

Emitter object information will not be saved as part of the ASCII checkpoint. When the game isrestarted, new Emitter objects will be created immediately when the restart procedure placesobjects on the game board. This method improves system efficiency by clearing unused Emitterobjects from the JODA.

Table 6 summarizes the attributes of the Emitter object and the information that the CEP mustenter into each of these attributes. To support this design, the JOI must subscribe to this newobject and access its information. All attributes highlighted green are common knowledge.Attributes highlighted yellow are perceived knowledge and will be set according to the Side thatdetects the emission. If the object’s Force Side mask is set, the Force Side sees all common

This description does not include the ELINT Sensor’s ST EFFECTIVENESS. The current plan models the ELINT capability as 100% effective, The model will mark the Side’s perceived emitting flag while an ELINT Sensor covers the emitter’s location, regardless of this database parameter setting. If a probability component must be represented for ELINT detections, the Government must inform us so this design can be altered accordingly.

25 February 2013 234 JTLS 4.1.0.0


knowledge information held on the Emitter object. The CEP will set the Force Side masks basedon the Force Sides that have ELINT collection assets receiving the emitter signal.

Table 6. JODA Emitter Object

EMITTER ATTRIBUTE DESCRIPTION

id The unique JODA identification code or JEDI for this object.

is_target This Boolean attribute indicates whether the emitter originates from a Target. The value “true” indicates a Target and “false” indicates an aircraft.

category This identifier indicates whether this emitter represents a Sensor or a Jammer.

subcategory The name of the specific type of Sensor or Jammer. The combination of Category and Subcategory enables the JOI to access any detailed information pertaining to the emitter.

pulse_rate This text variable represents the normal pulse rate of the Emitter object and is part of new data added to the model, as described in Table 1.

prefire_pulse This text variable represents the pre-firing pulse rate of the Emitter object. This attribute is meaningful for Fire Control settings only and is part of new data added to the model, as described in Table 1.

prefire_flag This Boolean attribute indicates whether the JOI must use the pulse_rate or the prefire_pulse attribute in the message. The CEP can change this attribute to reflect the Sensor’s activity. This will be applied to Fire Control sensors and is described in detail in Section 3.4.3.

freq This current frequency of the emitter represented by the Target is part of the new data added to the model, as described in Table 1.

location Although a Target currently has a perceived location, the TAELNT messages must always be created according to the ground truth location of the Target. The Side that owns the ELINT collection asset may not know where this Target is located and its perceived location may be unknown or incorrect. The ELINT detection is the first indicator the Player will receive that an emitting asset exists. Therefore, the JOI, which can obtain only one perceived location, must access a ground truth version of the location.

ac_name If the Emitter is onboard an Air Mission, this attribute holds the name of the Aircraft Class on which the emitter is located.

sup_id If the Emitter is onboard a naval vessel on the surface, this attribute holds the JEDI of the Ship Unit Prototype (SUP) of the contact.

elnot This mandatory field holds the database ELINT Notation (ELNOT) of the emitter. The Emitter object will not be created if the emitting Sensor is not assigned an ELNOT.

country_code This attribute holds the two-digit text country code for the Target or Air Mission.

function_code This integer identifier of the ELINT function code enables the JOI will to interpret this code and properly fill the TACELINT message.

JTLS 4.1.0.0 235 25 February 2013


3.3.3.2 Change is_rotating Target Attribute

Currently there is a Boolean target attribute called is_rotating. As part of JTLS-2012-11384Direct Link To MUSE, there has been a request to expand this attribute to be three valuesindicating how fast the radar antenna is rotating. This attribute will be changed from a Boolean toan enumerated type with the following legal values:

• 0 means No Rotating

• 1 means Slow Rotation, Acquisition Mode

• 2 means Fast Rotation, Pre-Fire Mode

3.3.4 JOI Changes

The design team believes that a separate ELINT JOI may likely be required for large games, butthis will not be necessary. The JOI possesses all filtering capability needed to properly set up aflexible feeding system. The designers will therefore build the TACELINT reporting capability intothe JOI, instead of a separate program. Users who choose not to execute the TACELINT feedcapability can use the JOI setup procedure to turn off the feed. A separate TACELINT JOI must bestarted with an active TACELINT feed.

target_name If the emission is received at the same location as the perceived Target, the CEP will place the name of the Target in this field. If this information should not be a part of the message, this field will hold the default dash "-" character.

unit_name If the Target is owned by a unit and the emission is received at the same location as the perceived Target, the owning unit’s name is placed in this field. If the Target is not owned and only associated with a unit, this field will hold the default dash "-" character.

ada_name If the Sensor is a Fire Control sensor, this field will hold the Air Defense System type name. If this emitter is not a Fire Control sensor, this field will hold the default dash "-" character.

is_active If a specific Force Side has an ELINT collection asset covering the emitter, this perceived attribute flag is set to “true”. The JOI will use this key to determine whether to send TACELINT messages for this Emitter object.

Table 6. JODA Emitter Object (Continued)

EMITTER ATTRIBUTE DESCRIPTION

25 February 2013 236 JTLS 4.1.0.0


3.3.4.1 Setup Procedure

The customary JOI setup procedures that indicate the perceived Side for which the JOI isexecuting will be used for a JOI that sends TACELINT messages. Only two new setup parametersare required for the TACELINT portion of the setup screen:

• The socket over which the feed is sent

• The time (seconds) between TACELINT reports is expected to be less than 10 seconds.The JOI will send a TACELINT message, pause for this interval, and send the nextTACELINT message. Thus, this parameter indicates the frequency the real-world C4Isystem can expect updates and resolves an issue of the previous feed methodology. JTLScould not maintain a constant feed to the real-world system, which caused the system todisconnect from the communication socket.

3.3.4.2 Basic Logic

The JOI will receive Emitter object information from the JODA, maintain a list of these objects,and cycle through this list. The JOI will generate a TACELINT message for the Emitter if theobject’s is_active flag is set to "true", wait the specified setup interval, then proceed to generateand send a TACELINT message for the next listed active Emitter. The feed to the socket must beconstant, even if only one Emitter object exists. In this case, a TACELINT message for the sameemitter will be generated for each time interval.

When new information is received for an Emitter, an updated TACELINT message must be sentimmediately. The design team envisions an internal JOI timer that triggers the next TACELINTmessage. When new information is received from the JODA, the timer is canceled and theobject’s updated TACELINT message is sent. The timer is then restarted and the processresumes with next listed object.

This methodology sends new TACELINT information before the older and unchanged informationis repeated.

3.3.4.3 TACELINT Message Generation

Section 3.1 describes a sample TACELINT message. Table 7 describes how the JOI will fill thismessage.

Table 7. TACELINT Message Generation

LINE DESCRIPTION

1 EXER/JTLS41/

Name of the scenario

JTLS 4.1.0.0 237 25 February 2013


2 MSGID/TACELNT/NAT/5/NOV//

This message count should increase by 1 each time a message is issued. If the month changes, the count should begin at 1.

MSGID/TACELNT/NAT/5/NOV//

This month of the year is sent to a real-world system and should be the month of the system time, not the game time.

3 COLLINFO/ZZ//

This hard-coded field should always appear as shown.

4 SOI/-/280500Z/280500Z/ASR/RED LR AIR/QQ

This current Zulu system time (ddhhmmZ) should match the scenario time during an exercise. Since a real-world system is involved, a real, not simulated, time is required.

SOI/-/280500Z/280500Z/ASR/RED LR AIR/QQ

This current Zulu system time (ddhhmmZ) should match the scenario time during an exercise. Since a real-world system is involved, a real, not simulated, time is required.


Value of the elnot Emitter attribute


Name of the detected Sensor or Jammer. If the attribute category is set to SENSOR, the JOI will enter the ST NAME of the Subcategory number in this field. If the attribute category is JAMMER, the JOI will enter the JT NAME of the Subcategory number. All period "." and underscore "_" characters should be replaced by the space character.


Value of the country_code Emitter attribute

5 /102-SHIP-RDR/RED BB-28/-/AC//

Value of the target_name Emitter attribute. All period "." and underscore "_" characters should be replaced by the space character.

/102-SHIP-RDR/RED BB-28/-/AC//

Value of the unit_name Emitter attribute. All period "." and underscore "_" characters should be replaced by the space character.

Table 7. TACELINT Message Generation (Continued)

LINE DESCRIPTION

25 February 2013 238 JTLS 4.1.0.0


5 (Con’t)


Value of the ada_name Emitter attribute. All period "." and underscore "_" characters should be replaced by the space character.


The function_code Emitter attribute is an integer variable that identifies the ELINT function. The JOI will access the Static Vocabulary file MTF_ELINT_Function table to obtain the character string to be placed in the message. For example, the function_code value “1” is associated with the character string “AC”.

6 EMLOC/-/P/LS:491838N0050744E/-/-/-/-//

Value of the location Emitter attribute.

7 PRM/-/101.7HZ/45.5MS//

Value of the freq Emitter text attribute. The model will output the frequency and unit of measure.

PRM/-/101.7HZ/45.5MS//

Value of the pulse_rate or prefire_pulse Emitter text attribute. If the Boolean prefire_flag attribute is "true", the prefire_pulse parameter is used. If the value is "false", the pulse_rate parameter is used.

Lines 8A are printed only if this emitter is onboard a naval unit and the sup_type attribute is set.

8A AMPN/PROBABLE COMBATANT: TYPE NJCLASS//

The sup_type attribute is the JEDI of a SHIP_UNIT_PROTOTYPE entity, which has a ship_class_type attribute. The Ship_Class_Type Static Vocabulary item should be used to determine the text string to be placed at this position.

AMPN/PROBABLE COMBATANT: TYPE NJCLASS//

The ship_class_name attribute, not the name attribute, of the ship_type JEDI should be placed at this position.

Lines 8B are printed only if this emitter is onboard an aircraft and ac_type attribute is set.

8B AMPN/PROBABLE MIG21 AIRCRAFT//

The ac_type attribute is the JEDI of an AIRCRAFT_CLASS entity, which has a usmtf_name attribute. That text string should be placed at this position.


LINE DESCRIPTION

JTLS 4.1.0.0 239 25 February 2013


3.3.5 WHIP Changes

Detection of electronic emissions as a result of the presence of an ELINT collector in the area isconsidered to be an independent process that will not affect the detection and display on theWHIP or other C4I systems of the physical object emitting the signal. Detection of the emissionshould induce a JTLS Player to send other detection assets, such as visual assets, to investigatethe cause of the emission. Any person viewing the TACELINT message data on a real-world C4Isystem would respond similarly. To enable JTLS Players to be responsive to this detectioninformation, the WHIP must provide a visual display.

This proposal adds an Emissions option to the WHIP Filter Control panel that displays an array ofcheckboxes resembling Figure 2. Selecting an object displays the indicated emission type on theWHIP. This example indicates the displayed emission symbols of detected emitting SAM targetswould be colored green, all detected emitting SAM targets preparing to fire and locked on to atarget would be colored red, and all detected emitting Air Missions would be colored blue.

FIGURE 2. Example Emission Filter Panel

The emission symbol will be an open circle that allows users to view or read the underlying icon ifa non-ELINT detection has occurred. If a detection has not occurred, the emission symbol willappear at an unspecified location and the emission can be investigated as desired. The emissionsymbol will be subject to the Symbol Size specification.

8B (Con’t)

AMPN/PROBABLE MIG21 AIRCRAFT//

The ac_type attribute is the JEDI of an AIRCRAFT_CLASS entity, which has a Boolean fixed_wing_flag attribute. If the value of fixed_wing_flag is "true", the word “AIRCRAFT” should be placed at this position. If the value is “false”, the word “HELICOPTER” appear.

9 DECL/DERI:SIMHQ/-/-/X1//

This hard-coded line should be the same as what the JOI currently delivers when it sends an OTH-Gold message.


LINE DESCRIPTION

Object

SAM Targets

Sensor TargetsJammer TargetsAir Mission

Color Selection Area

Pre-Fire SAM

25 February 2013 240 JTLS 4.1.0.0


The WHIP will retrieve and display all Emitter objects for which the Side has knowledge and theis_active flag is set to “true”. The emission symbol icon will be placed at the location specified bythe location attribute. The emission symbol will appear directly over an icon if the icon has thesame perceived location. All WHIP symbols are placed so the lower left corner of the icon isplaced at the represented object’s specified location. This should also be true for the Emissionopen circle icon.

Table 8 summarizes how the WHIP will determine which Emitter objects should be displayedaccording to the filter settings described in Figure 2.

3.4 JTLS Model Improvements

The model changes described in this section fulfill the design requirements and correct severalother related user issues.

3.4.1 Turn Off Specific Sensors On An Air Mission

Many times during an exercise, the control team must simulate a mechanical failure onboard anaircraft. Such failures frequently involve collection equipment. For example, losing the air picturefor a period of time could be represented by simulating a failure of the onboard Air Search radaran Airborne Early Warning and Control System (AWACS) aircraft. JTLS currently cannotaccomplish this representation.

When an aircraft takes off, all of its Sensors and Jammers will continue to be immediately turnedon. This design will not change this convention.

The Change Mission Parameter order will be used to turn off a specific emitter. The user willenter the name of the mission, the name of the Sensor or Jammer, and indicate whether theasset should be turned on or turned off. Only one Jammer or Sensor can be changed at a time.When the model receives the order, the asset will be altered as requested. If turned off, the assetwill no longer function and not be allowed to work within the model. Any ELINT collecting assetwill see this change and adjust the JODA Emitter object.

Table 8. display_on_map And emitting_flag Attribute Rules

FILTER ATTRIBUTE RULE

SAM TARGET The attribute is_target is "true" and the attribute ADA_name is filled.

SENSOR TARGET The attribute is_target is "true" and the attribute category is set to SENSOR.

JAMMER TARGET The attribute is_target is "true" and the attribute category is set to JAMMER.

AIRCRAFT The attribute is_target is "false".

JTLS 4.1.0.0 241 25 February 2013


To enable users to view the current status of their Sensors and Jammers on a specific mission,these data must be available to the IMT. The design team contends that the mission QuickRetrieval screen currently labeled “Weapon Load” should be renamed as “Mission Load” andinclude all Jammers and Sensors currently on the mission, as well as the onboard weapons.

Table 9 depicts the proposed Mission Load screen that lists all weapons, Sensors, and Jammerscurrently on the mission. The IMT functionality requires Sensor and Jammers to list a NumberExpended value; this field cannot be empty.

3.4.2 Turn SAM Sites On And Off

A JTLS SAM site is currently assumed to be turned on when it is assigned at least one positiveRule of Engagement (ROE). This convention limits the flexibility of SAM sites. For example, somesites are able to fire with reduced effectiveness if their Fire Control radar is non-operative. APlayer cannot assign a positive ROE and not use their Fire Control sensor, which may be detectedas an emitter.

The purpose of this improvement is to separate the concepts of a site’s ROE and a site’s decisionto turn on its Fire Control radar. Our goal is not to make JTLS more difficult to use, so severalautomatic capabilities will remain. Table 10 describes the emitting Fire Control sensor automaticrules.

Table 9. Example Mission Load IMT Screen

AIR MISSION ASSET NAME IMPACT TYPECURRENT NUMBER

NUMBER LOADED

NUMBER EXPENDED

STATUS

5XX8002 20MM.75RD AIR_TO_AIR 14 14 0

5XX8002 IRIS-T AIR_TO_AIR 4 4 0

5XX8002 AIR-SR2 1 1 0 TURNED_ON

5XX8002 MK82 SURFACE_BURST 4 4 0

Table 10. Automatic Fire Control Sensor Rules

NEW ROE AGAINST A SIDE

ROES AGAINST ALL OTHER SIDES

AT LEAST ONE FIRE ALLOWED ALL HOLD OR NO FIRE

SET FIRE ALLOWED

Do not change the Fire Control radar status.

Turn on the Fire Control radar. If this is not desired, the Player must specifically turn it off.

STOP FIRE ALLOWED (HOLD OR NO FIRE)

Do not change the Fire Control radar status.

Turn off the Fire Control radar. If this is not desired, the Player must specifically turn it on.

25 February 2013 242 JTLS 4.1.0.0


Non-emitting Fire Control sensors will be turned on immediately when the Target enters thetheater. It will not be changed automatically in the model.

Users will submit the Emission Control order to specifically turn on or turn off a Fire Control radar.The change can be made by selecting the:

• Type Sensor option - The fields described in Table 11 will be displayed.

• Specific Sensor target - This order option will not change. The only necessary change is toenable the order panel to retrieve Air Defense targets as well as Sensor targets. If the userselects an Air Defense target, that Target’s Fire Control sensor will be changed asspecified by the Action field.

Table 11. New Emission Control Order Type Sensor Option

FIELD NAME DESCRIPTION

Emitting Unit The purpose of this existing order field is not altered as a result of the change.

Change All Subordinates The purpose of this existing order field is not altered as a result of the change.

Emitting Flag This new field allows Emitting, Non-Emitting, and Both options.

• Emitting: Only Sensors that are considered emitters (ST JAMMABLE FLAGequal to YES) and active sonars will be adjusted.

• Non-Emitting: Only Sensors that are considered non-emitters (ST JAMMABLEFLAG equal to NO) and passive sonars will be adjusted.

• Both: All Sensors of the specified types will be adjusted.

Surface Search Sensor The purpose of this existing order field is not altered as a result of the change. The user selects whether Surface Search sensor Targets should be turned on or off.

Sonars This new field replaces the previous Active Sonars and Passive Sonars fields. The design team implements only a single reference for Sonars with the addition of the Emitting Flag. Active sonars are adjusted when the Emitting option is selected and passive sonars are adjusted when the Non-Emitting flag is selected.

Air Search Sensors The purpose of this existing order field is not altered as a result of the change. The user selects whether Air Search sensor Targets should be turned on or off.

Counter-Battery Sensors The purpose of this existing order field is not altered as a result of the change. The user selects whether Counter-Battery sensor Targets should be turned on or off.

Fire Control Sensors This new field works identically as the other Sensor Type fields. The user selects whether Fire Control sensors should be turned on or turned off.

JTLS 4.1.0.0 243 25 February 2013


When an Air Defense site fires, the model will consider whether the Fire Control sensor is turnedoff or turned on. If it is turned off, the model applies the same logic that is implemented if theFire Control sensor is destroyed. Depending on the data, the site will not fire or will fire withreduce effectiveness.

3.4.3 Changing Pulse Rate

One of the more important detection capabilities of an ELINT collection asset is the ability todetermine whether an Air Defense site is about to fire. On an unclassified level, this can beaccomplished by detecting a change of frequency or an increase of pulse rate. Immediatelybefore firing, the Air Defense site radar increases its rate of emission. The design team intends torepresent this capability in a rudimentary manner to keep the model unclassified whilecontinuing to represent the basics of the entire collection interpretation process.

In addition to adding the data listed in Table 1, JTLS will add a ST PREFIRE PULSE RATE dataelement to the Sensor Type definition. This parameter will be used to indicate that an Air Defensesite is about to fire. An ELINT collection asset in the area can detect the pulse rate change andgenerate an ELINT message. The real-world C4I system should be able to distinguish the change.

When an Air Mission moves into a new region, the model considers all Air Defense sites thatcover the region. starting an extended process that determines whether the site intends to fire onthe object. Items such as ROE, Probability of Hit, Probability of Kill, weather, interfering terrain,and adequate range given the altitude of the detected aircraft are considered. When finished,the model removes the Air Defense sites that are on an Integrated Air Defense System (IADS)network. All Air Defense sites that remain listed can feasibly fire. The JODA prefire_flag will be setfor these sites.

If the site is covered by an ELINT collection asset, a TACELINT message will be generated thatreports the increased pulse rate.

The most difficult aspect of this design is deciding when and how to turn off the rapid pre-firepulse rate. Within JTLS, the actual firing and assessment of the Air Defense site firing isinstantaneous, and keeping the pre-fire pulse rate in effect for a short period of time will notresult in the expected indications. The model will restore the pulse rate to normal one minuteafter it is set to the Pre-Fire mode. This event will be postponed every time the Air Defense sitefinds itself on a firing list.

4.0 Data Changes

The JTLS-2012-11382 Satellite Service ECP implements several database changes referenced inthis design and describes these data changes.

25 February 2013 244 JTLS 4.1.0.0


Since TACELINT messages will no longer be delivered by the model, the following two databaseparameters will no longer be needed and will be removed from the database:

• IIP ELINT SENSOR

• IIP ELINT REPORT MEAN TIME

The data changes needed for this design formalize the non-configuration managed dataavailable in JTLS 4.0 and include the additional ST PREFIRE PULSE RATE data to enhance therealism of TACELINT messages used by real-world systems.

ST ELINT PULSE CODE

• Dimension: Variable - Entity Attribute

• Mode: Text

• Unit of Measure: Not applicable, but the text string should include a appropriatepulse code unit of measure, such as MS (milliseconds).

• Range: A valid ELINT pulse rate descriptor. The characters #, &, $, @,/, (,), <, >, and embedded spaces are prohibited.

• Default Value: NULL is allowed and output as NONE.

• Definition: This attribute of the SENSOR TYPE permanent entity is a textstring that holds this Sensor’s normal pulse rate and is usedwhen reporting a detection of its emissions by an ELINTcollection asset. The text string should include the unit ofmeasure. For example, 123MS represents the pulse code 123milliseconds.

• Relationships: ST ELINT NOTATION, ST ELINT FREQ VALUE, and ST PREFIREPULSE CODE must be filled if a value is entered for this databaseparameter.

ST ELINT PREFIRE PULSE CODE


• Mode: Text

• Unit of Measure: Not applicable, but the text string should include an appropriatepulse code unit of measure, such as MS (milliseconds).



JTLS 4.1.0.0 245 25 February 2013


• Definition: This attribute of the SENSOR TYPE permanent entity is a textstring that holds this Sensor’s normal pulse rate and is usedwhen reporting a detection of its emissions by an ELINTcollection asset. The text string should include the unit ofmeasure. For example, 123MS represents the pulse code 123milliseconds.

• Relationships: ST ELINT NOTATION, ST ELINT FREQ VALUE, and ST ELINT PULSECODE must be filled if a value is entered for this databaseparameter. The pre-fire pulse rate is expected to be faster thanthe ST ELINT PULSE CODE.

ST ELINT FREQ VALUE


• Mode: Text

• Unit of Measure: Not applicable, but the text string should include an appropriatefrequency unit of measure, such as HZ (Hertz).



• Definition: This attribute of the SENSOR TYPE permanent entity is a textstring that holds the frequency over which the Sensor transmitsand is used when reporting a detection of its emissions by anELINT collection asset. The text string should include the unit ofmeasure. For example, 123HZ represents the frequency 123Hertz.

• Relationships: ST ELINT NOTATION, ST ELINT PREFIRE PULSE CODE, and STELINT PULSE CODE must be filled if a value is entered for thisdatabase parameter.

JT ELINT.NOTATION


• Mode: Text

• Unit of Measure: Not applicable



25 February 2013 246 JTLS 4.1.0.0


• Definition: This attribute of the JAMMER TYPE permanent entity is a textstring that holds the Jammer’s ELINT Notation (ELNOT) code.

• Relationships: JT ELINT NOTATION, ST ELINT FREQ VALUE, and ST ELINT PULSECODE must be filled if a value is entered for this databaseparameter. If this parameter is not filled, no ELINT collectionasset will obtain information about this type of Jammer.

JT ELINT PULSE CODE


• Mode: Text

• Unit of Measure: Not applicable, but the text string should include a pulse codeunit of measure, such as MS (milliseconds).



• Definition: This attribute of the JAMMER TYPE permanent entity is a textstring that holds this Sensor’s normal pulse rate and is usedwhen reporting a detection of its emissions by an ELINTcollection asset. This text string should include the unit ofmeasure. For example, 123MS represents the pulse code 123milliseconds.

• Relationships: JT ELINT NOTATION and JT ELINT FREQ VALUE must be filled if avalue is entered for this database parameter.

JT ELINT FREQ VALUE


• Mode: Text

• Unit of Measure: Not applicable, but the text string should include a frequency unitof measure, such as HZ (Hertz).



• Definition: This attribute of the JAMMER TYPE permanent entity is a textstring that holds the frequency over which the Sensor transmitsand is used when reporting a detection of its emissions by anELINT collection asset. The text string should include the unit of

JTLS 4.1.0.0 247 25 February 2013


measure. For example 123HZ is an example of the frequency123 Hertz.

• Relationships: JT ELINT NOTATION and JT ELINT PULSE CODE must be filled if avalue is entered for this database parameter.

5.0 Order Changes

The Assign National Asset order will be completely redesigned as described in Table 2.

The Set and Show orders for Sensor Types and Jammer Types must be modified to allow theController to alter the new data parameters described in Section 4.0.

The Emission Control order will be modified as described in Table 11.

Order changes related to the new ST TIME PER DSA COLLECTION database parameter and orderchanges to manage the new National Asset Pass capability are documented in JTLS-2012-11382Satellite Service.

6.0 JODA Changes

A JODA object described in Table 6 will be created.

The JODA Target attribute is_rotating is changing from a Boolean to an Enumerated Type where a0 means not rotating, a 1 means slow rotation, and a 2 means fast rotation.

7.0 Test Plan

The WHIP will display collected Emitter information. A real-world system that can acceptTACELINT messages is therefore not necessary to test the new logic. However, the designimplementation cannot be fully tested and approved until a TACELINT message feed to areal-world system is established.

7.1 Test 1 Title

Purpose: [Describe the specific feature, function, or behavior to be tested or measured.]

Step 1: Text

Step 2: Text

25 February 2013 248 JTLS 4.1.0.0


Expected Results: [Describe the specific model behavior to be observed.]

7.2 Test 2 Title

Purpose: Text

Step 1: Text

Step 2: Text

Step 3: Text

Expected Results: Text

JTLS 4.1.0.0 249 25 February 2013


25 February 2013 250 JTLS 4.1.0.0

jtls-2008-10001 pass tacelint to real world systems(elint) collection mode is activated. the...

Documents