ROLANDS & ASSOCIATES Corporation

The latest version of TBMCS and the format of some database tables have been changed. The JTLS Transaction Operational Interface (JTOI)  must be improved to work with the older TBMCS X or the new TBMCS Y.

Migrate from the hex-based road network to a real-world road network.

Develop an Attach Unit option that attaches all detached units.

Enhance these Controller orders to include Execution Time: Magic Move, Magic Move Formation, Controller Kill Aircraft, Reactivate Unit, Alter Terrain, and Set Disease.

A user order to attack an unidentified object is converted to attack a location. When the mission arrives and the UI has moved, the Player receives no information that the UI is absent. The minimum improvement involves removing the UI because the unidentified object is not located where it was most recently detected.

An Air Mission that cannot determine an optimal path because National Boundaries intervene stops optimizing and magically moves to the specified location. Solutions for improvement include: ignore the National Boundary and prompt the user to input more specific instructions or direct the mission to remain at its location and request more specific instructions. Each of these solutions offers advantages and disadvantages. Another solution that avoids the magic move may be possible.

The group Move order allows users to select a lead unit and all of its subordinates or select a list of units. The list of units does not include a subordinate capability. The desired capability would allow a user to Group Move Unit A and the listed units that include Unit B, Unit C and all of its subordinates, Unit D, Unit E, and Unit F and its subordinates.

An Operations Area (OPAREA) has special Surface-to-Air and Air-to-Air ROEs. Add special Surface-to-Surface or Ground Combat ROEs also.

JTLS represents UAVs as aircraft. To properly gather desired information, these UAVs must not fly higher than 1000 feet over the terrain. This behavior must be represented for the purposes of a realistic Common Operational Picture (COP). Although JTLS does not alter the intelligence that can be collected based on sensor altitude, the UAV must obey this altitude restriction. When a user represented this restriction by ordering a UAV maximum altitude of 1000 feet, the aircraft could not fly over high plateaus of Afghanistan that are higher than 1000 feet. The best sof many possible solutions will properly represent the situation. A UAV can easily fly at altitudes above sea level that exceed 1000 feet.. The proper solution represents the maximum sensor altitude, which should restrict searching missions below the collection altitude.

A naval unit or formation currently will optimize a path to the search area vertex that is nearest the object's current location. the model rejects the order if no optimal path to this location is determined. The model should also consider an optimal path to the search area's other vertices.

JTLS Air Missions currently do not receive their home Squadron's National Boundary ROE override. A design is needed to determine when a mission should or should not use the National Boundary overrides assigned to a Squadron.

The TRIPP sends a request for new data to the TRIPP's JXSR. Unlike a WHIP during game execution in which several WHIPs share a JXSR, a one-to-one relationship exists between a TRIPP and its JXSR. Thus a specific TRIPP can increase the rate to query the JXSR for new data allowing the TRIPP to execute at faster speeds and display smoother flow of object movement on the map.

When executing the TRIPP capability, a user can select the game speed and replay the situation for analysis purposes, but must set the game speed to zero to stop the replay capability. Users have requested a capability to select a game pause time.

Moving the TRIPP to a specific time by moving the time scroll bar is difficult, especially after an extended execution time. The TRIPP must allow users enter a specific time and jump to the selected time. [duplicates 2009-10416]

A mission can be directed to load special weapons, but no capability exists to order a mission to load a special sensor. The sensor configuration is automatically selected by the load assigned to the mission.

Like all JTLS objects, Air Missions have a primary name that is used to identify the object. When a user submits an order, the name of the mission is used to identify the mission that is inteded to execute the order. For primary Force Side missions, the mission name is typically the mission number assigned as part of the ATO process. Air Missions are unique in that some users refer to the mission by its mission number but also its Call Sign as specified in the ATO. When the exercise audience requests the response cell to alter a mission's directives, the mission is commonly identified by its Call Sign. The JTLS WHIP operator must use the IMT to determine the Call Sign and then determine the corresponding mission number, This time-consuming process must be simplified.  A thorough design may include configuring whether Air Missions are displayed on the map using their mission number or call sign or  allowing WHIP users to enter a Call Sign on the Map Find box.

Each object displayed t in the WHIP is associated with a context-sensitive menu, which is activated by right-clicking the object icon. This menu allows users to select the capability to find the object on the map, which is extensively used. Users have expressed a desire to use additional options for Air Mission objects: a Find On Map option or a Find on Viewer option that allows the ATO Viewer to automatically reposition on the selected object and highlight the mission.

JTLS is delivered with an automatic script that moves a production checkpoint to a shadow game. The generated TRIPP files are not a part of the automated procedure. Users must move the TRIPP data files manually to execute a TRIPP on the shadow game. The TRIPP files are not located within the typical checkpoint directory structure. User backup procedures are complicated by determining which TRIPP files are new and must be backed up. The current preferred solution moves saved TRIPP files under the checkpoint directory structure.

The WHIP Map component can be configured by each user and the configurations are saved for convenient recall when a new Map is opened or the WHIP is started. Other WHIP components, such as the ATO Viewer, IMT, and Message Browser, can also be configured by each user, but no configuration save capability exists. When a user restarts the WHIP, these components must be reconfigured to match the user's needs. A configuration save capability is required for each WHIP component to eliminate this time-consuming process.

During a recent exercise, a context-sensitive menu order option was discovered to be invalid. The menu file incorrectly listed an order that no longer exists. A verification procedure exists for orders description files, but no equivalent procedure exists for menu description files. Since users can create their own menu description files, such a procedure must be developed.

Field restrictions allow programmers to indicate that the selected value of an order field affects the allowable values for another order field. For example, the Fire Artillery order currently limits the units that can be selected based on the Caliber entered in the field and vice versa. If a unit is entered, the Targetable Weapons displayed are limited to the unit's Caliber. The same concept is needed for several other order panels; for example, restrict the missions shown in the pull-down menu on the Change Mission Parameter order based on the selected group: Recce, AWACS, etc.

The ATOT currently allows a user to choose whether slides for the Air Control order are generated. If the slides are generated, the ACMIDs are grouped by type into slides. Thus, all Air Refueling locations are included in an Air Refueling slide, or all Polygons are in included in a Polygon slide. During a recent exercise, the Air Player requested that each ACMID appear in its own slide. When they needed to see maritime patrol area (MPA_1) - they didn't have to figure out which slide it was in. The slide was named MPA_1. They could quickly call it up and send a mission to the location depicted in the slide. This capability must be formalized and users should select whether grouped slides or individual slides will be generated. Alternatively, the ATOT could create both types of slides.

Link-16 Air Tracks are assigned a quality rating. Tracks that move out of range degrade until they are lost. JTLS does not currently represent this behavior.  JTLS uses the concept of number of missed detections prior to track loss. Developers recommend that an Air Mission JODA attribute be set to indicate a strong detection when a detection occurs. The value of this attribute is decreased when a missed detection occurs. The track would be dropped after a database-specified number of missed detections occur.

WHIP users can "prune" or hide portions of the Command Hierarchy to simplify viewing. This pruning capability can be used as a filter that displays only units not pruned on the Map or IMT.

Provide a user capability to add a single text note to a unit record that could be displayed on the IMT or from a context-sensitive menu. For example, a note may state "Selected For MEL/MIL 3.4 - Do Not Use". Such user reminder or MEL/MIL notes are useful to record unit activities.

The ICC separates its MISREPs into 132-character segments. JTLS requires this capability to allow the JTLS Operational Interface (JOI) to fill the proper ICC MISREP fields.

JTLS currently holds orders that specify an execution time as Received Orders for all units except naval units. Develop order queues for each unit that are displayed on the IMT as currently displayed for naval units.

Create Convoys that execute at a future time. For example, leave the support unit at time X and head for Unit B. Convoy behavior could resemble Air Mission behavior. Convoys and HRUs could also be combined as a single object, which may be more difficult.

Develop user capability to filter objects by an order group or an activity. For example, show only units that are moving into position for a northern attack.

This capability is listed separately, although it is linked to two other ECPs. Maritime Supply Routes (MSRs) should be available to use as part of the ship smooth movement incorperated in the smooth movement ECP. MSRs and roads and should be included in the ECP that includes named object routes within the model; objects follow the named object routes. Users can specifically enter the routes to be followed, which can be displayed on the WHIP.

Insert/Extract missions currently cannot always find moving ships, causing difficulties to properly represent medical evacuation from these ships.

The SITREP Window must always list the time at which a unit is epxected to reach its destination when the unit is moving.

On the minelaying order, list only the available mine after a unit name is entered. When a mine name is entered, list only the units that have that weapon available.

The current ATO Viewer has a sorting capability. Using time as a secondary sort criterion while sorting by posture or other criterion is desired to allow users to more easily track missions on the Viewer.

Current JTLS data documentation indicates that catapults represent carrier catapults and arresting gear, which is incorrect and requires improvement. Fixed-wing aircraft are allowed to land when the catapults are non-operational.

Users are allowed to highlight one or more records on the DDS spreadsheet windows. A Quick Retrieve button allows opening a new spreadsheet window that displays the subrecords for the highlighted objects. Display the record count on this button to indicate whether records are available for retrieval.

When a Theater Ballistic Missile is fired, the model computes an error ellipse within which the missile is likely to land. This error ellipse is passed to real-world C4I systems. Develop a capability to display this information on the WHIP.

The WHIP Map currently displays requested updated data from the JXSR every 20 seconds for Windows users. This interval is too long for Ballistic Missiles and may also be too long for Cruise Missiles and aircraft. Enhance the data update rate to be configurable by object type.

Adding, changing, or deleting a minefield deactivation event is not currently possible. This capability is needed for complete flexibility.

Minefields specified in the database cannot be assigned a deactivation time. The database requires this capability.

The WHIP is currently able to display user lines. These objects are comprised of two types: the model generates lines to indicate where a displayed object will move; users or the ATOT can draw lines and figures to indicate specific areas of responsibility for Air Control Areas. Develop a KOI capability to display both types of lines.

Develop an IMT option that color-codes each line based on the object's posture. An intercepting mission would highlight the line to improve visibility to users. Apply this feature to other mission types.

JTLS Players typically use a forward obsever and do not obtain BDA from artillery fire. BDA should be available.

The Change Command Authority order is significantly different for Players and Controllers. Design separate orders or improve the selection criteria for field display based on whether the order originates from a Player WHIP or Controller WHIP.

Develop a drag map capability for the WHIP Map component.

LARCOM allows users to specify a wait time at various ground route points. For example, a ground unit can be directed to move to Point A, wait 15 minutes, move to Point B wait 45 minutes, and continue to Point C. This behavior is difficult to accomplish within JTLS. A direct JTLS capability would reduce the need for LARCOM. The wait time must be both relative and absolute; for example, wait 15 minutes or leave at 011200Z.

Add REPOL, MUNREP USMTF messages to JTLS. Add NATO LOGASSESSREP and LOGUPDATE messages to JTLS.

Monitor aircraft tail numbers and be able to provide a history of each tail number's activity during an exercise.

JTLS does not represent power grids or model the effects of destroying a power grid (Windows users). This representation must be modeled as part of the increased emphasis on Effects Based Operations (EBO).

JTLS does not internally model killboxes. JTLS users must manually assign targets to an orbiting OAS mission and assign a target in an ATO-specified killbox. If the model supports the killbox concept and the OAS mission is assigned to the killbox, the model could select a default target instead relying on a user decision.

JTLS users should be able to issue an order to an intercepting mission that indicates which weapon should be fired at the intercepting target. As an alternative or addition to this capability, the selection logic could be improved to consider the cost of the fired weapon. If the enemy aircraft cannott return fire, a long-range weapon should not be wasted on the aircraft. Move in closer and use the lower-cost short-range weapon. Also, some type of data could be added to the model to allow determining a preferred weapon. The PK database is currentl used, but has proven to limit the ability to formulate cost-related questions. The costlier weapon will deliver a higher P(K), but may not be efficiently used against a transport mission.

Real-world COPs use a visual intercepting bar associated with a mission symbol to indicate that the mission is intercepting a track. JTLS provides only the information available on the IMT.

Only the JTLS Strategic Lift order currently allows users to specify the ICAO of the airbase from which a unit or supplies should be picked up and to which a unit or supplies should be dropped. This capability is desirable for the Airlift, Air Transport, and Insert/Extract orders. User must currently enter the latitude and longitude of the pickup and dropoff locations, which is cumbersome and requires meticulous assignment of the location.

Displacement is an important value for naval personnel to determine the importance or size of a specific ship; greater values indicate larger ships. JTLS does not represent these data within Ship Unit Prototype (SUP) definitions. Users are required to understand the type of ship, based on its name and other characteristics. Add this data parameter to SUP definitions to provide users a realistic reference point for understanding the object the SUP represents.

If some AAR data is lost, the AAR becomes useless because objects are missing. The AARC startup could be improved to include a download all objects from the JODA and ensure that the objects exist in the database. The AARC could create the object even if not all data are available for the object creation. The AAR could save the majority of data from that point forward to be used for analysis purposes.

Repair Combat System and Aircraft events are not recorded in the AAR database. Information pertaining to the repair times of these objects cannot be obtained.

Cruise Missiles are currently not included in the AAR database.  The number of missiles fired or the damage assessments cannot be determined.

JTLS users can easily access OPM pages for other Force Sides by opening an OPM and navigating to an enemy Side. A password system is required for security.

Ships can shadow other ships, but Formations cannot accept shadow orders. This capability is needed.

The Fire Artillery order limits the weapons that a unit can fire based on the Caliber of the selected unit. However, the Fire Missile order does not limit the weapons that can be fired based on the SSM Targets owned by the selected unit. This limitation logic must be implemented within the WHIP.

Naval Formation orders are not currently acknowledged because the algorithm to determine the time delay for the order can be complex. Each ship in the Formation could possibly have a different reporting time based on their training and status of their communications equipment. Implement a logic time delay or review the necessity of delaying order acknowledgment messages. Order acknowledgment delays positively enhance the "fog" of war needed for a realistic decision environment.

JTLS unit attachment currently allows attachment for task re-organization and attachment for reconstitution options. If the attach is complete and the JTLS user chooses to detach the same unit, the model currently removes the complete TO&E for the unit. Users would prefer an option to indicate whether the unit should take exactly what it provided the attached unit, take a proportion of the systems equal to the proportion of the original two units' TO&E, or take the detached unit's full TO&E. Users request that objects killed while attached do not return to the detaching unit if the first option is selected.

JTLS is able to run several JXSRs to serve XML data to WHIPs. Users cannot deterrmine whether a JXSR is overloaded or underutilized. Provide statistical data or information for Technical Control to determine whether more or fewer JXSRs are required.

Users entering rectangles or polygons have expressed a preference to manually enter lat/long pairs. Manual entry is currently allowed for single location fields, but not for rectangle and polygon fields.

While modeling natural disasters, Controllers can submit changes to terrain that represents the affected area.  Reconnaissance assets, whether airborne or on the ground, must report these terrain changes.

A simple radar detection model exists that links radar detection range to the size of the target. The description of the algorithm is a PDF document attached to an e-mail held under Future Task within the Hotmail account.

Not all weapons explode on impact. Unexploded ordinance will slow unit progress like a minefield. Improve the JTLS respresentation of this behavior.

JTLS currently represents external fuel tanks, which are filled to capacity when the mission first takes off. The model assumes that these fuel tanks are jettisoned as soon as they are empty. However, some tanks may be retained. If the mission lands at an airbase and refuels mid-flight, the external tanks would again be filled to capacity. Developer Note: Is it possible to have external fuel tanks filled during in-flight re-fueling? Can the fuel "flow into" the tanks during aerial refueling? If so, this must also be considered.

The weapon selection algorithm for the naval automatic firing capability must be improved. If the weapon must fly over land to move from the firing ship to the target ship, SSMs labeled as water-only should not be considered.

Order fields to can be linked to other fields. For example, the Fire Artillery order allows users to limit the list of Targetable Weapons that should be fired to only those weapons that can be fired by the Caliber of the unit to which the order is issued. An order field cannot be linked to another order field that is a utility list. For example, when a user enters a list of weapons that should be fired, the list of weapons cannot be limited by Caliber because no WHIP structure exists to allow the utility list panel to receive the unit name from the primary order panel.

Smooth network movement of ground objects was delivered with JTLS 4.0. Similar changes for air and naval objects should also be accomplished. The ECP discusses Space objects, but since JTLS currently does not represent moving space objects, the ECP should be viewed as incorporating the movement of space objects in a smooth manner.

Any WHIP can currently alter an existing Air Mission. Develop a Command Authority that allows Air Missions to ensure that multiple users do not issue a mission ambiguous orders. Possible options include command authority over the Squadron, command authority of missions, or only the submitting WHIP.

A mission name entered from the WHIP is currently limited to 8 characters, but the mission name entered from external programs can be a maximum of 15 characters. The 8-character limit indicates that the model should not check for uniqueness in the mission name, but should add an identifier to ensure uniqueness. If the model receives more than 8 characters, it checks for uniqueness and rejects the order if the name is not unique. Implement this option for the Player WHIP.

Implement a pop-up message to allows users quick and easy access to weapon information while building a weapon load. For example, display range and minimum and maximum altitude from which the weapon can be fired.

The Air Mission Package field is currently a text string that allows typographical errors  when WHIP users enter the package to which a mission should belong. This field should include a drop-down list that displays available packages.

The Air Ground Attack mission currently includes a field that indicates which target should be attacked. This list currently includes Friendly as well as Enemy targets. Friendly targets are included for "overrun" situations in which the enemy has overrun the position of one of your targets and you want to destroy it. This situation is unusual. Usesr should be able to significantly limit the contents of the drop-down list.

A JTLS weapon can currently be placed on an aircraft if it is assigned a Air-to-Air Kill Lethality or Surface Kill Lethality attribute. The AKL attribute is acceptable, but the SKL attribute allows users to place illogical Surface-to-Surface missiles on aircraft. Add a new attribute and enforce aircraft weight restrictions. Include the concept of the Side that can use the weapon or the aircraft that can suitably carry the weapon.

A user issued an order to an inactive Formation during a recent exercise. The WHIP processed this order and the CEP did not properly identify the error. The CEP was corrected to identify the error. To implement error checking as "close" to the user as possible, the WHIP should allow entry of  only active Formations in order fields.

Recent JTLS changes allowed Stratgic Lift missions to move personnel and tons of supplies from a TPFDD. The model does not maintain sufficient statistics that pertain to the throughput of TPFDD- related personnel and supplies through any specified airbase. This information must be available to the exercise audience.

No method exists to send a message via the JOI to drop an orphaned track from a C4I system. Although this could be a COP manager issue, this JOI capability would be useful.

A new capability has been added to JTLS to represent the concept of a Combat Zone. This zone causes Strategic Lift missions to operate in a different manner. IQuickly determining which airbases have been labeled in the Combat Zone is not possible. Display this attribute in the IMT.

Strategic Lift missions are currently able to fly to multiple locations and accomplish tasks. Each of these stops is visible on the IMT. Air Transport and Insert/Extract missions are also able to make several stops. Display each stop on the IMT in a manner similar to the Strategic Lift missions.

A recently reviewed OPTASK Link message revealed capabilities that JTLS could not accomplish. A specific Call Sign can be assined a Link-16 Source JU number; JTLS is incapable of handling this situation because the model randomly assigns a Source JU number and block from a set of available blocks. Track blocks apparently can be assigned to a specific Side; for example, AWACS should use Block AAAAA to BBBBB for Blue missions and CCCCC to DDDDD for Red missions. Geographic definitions apparently are a capability; for example, while in the area of Island 1, use Block EEEEE to FFFFF while in the area of Island 1; everywhere else use Block GGGGG to HHHHH.

The TRIPP reads files created by the Logging JODA. These files can occupy a significant amount of disk space, which should be conserved during an exercise. Automatically compress and decompress these files as needed by the TRIPP.

Several years ago, the Government decided to alter the logic within JTLS when an air mission decided to go for base fuel. The old logic allowed the mission to divert for base fuel and then continue on with its mission. The Government change was to automatically cancel the mission when it headed for base fuel. Several users have complained about this new logic. The suyggestion is that whether the mission cancels or not should be a database parameter or several database parameters. For example, - Should rotary aircraft automatically cancel - Should cancellation be an ACP characteristic. - Should there be a difference between the rules for refueling from a land base or a naval ship - Should the rules be the same for each mission type.

Finding a specific order in the WHIP order menu can be difficult. I know what I want to do and find, but cannot find it on the menu. Develop a method to quickly call up a specific order.

Moving a slider bar is the only method currently available to a TRIPP user to view a specific time. After the game has executed for a duration, the "precision" causes difficulties to select a specific time. Implement a capability to enter a specific time.

A JTLS Player can direct an Air Misison to fly at 100 feet (AGL) and then airdrop personnel at a drop zone. It is impossible to safely Airdrop personnel wearing parachutes cannot be safely dropped from 100 feet. The Player is avoiding the aircraft detection by entering this directive. A minimum and maximum altitude (AGL) at which personnel can "jump" out of aircraft should be specified. These altitudes could possilby be a function of aircraft type, allowing helicopters to perform airdrops from 50 feet (representing personnel using a rope to propel to the ground ) or allowing C130 airdrops from altitudes greater than 5000 feet (representing personnel using parachutes).

Aircraft can currently be directed not to intercept certain types of aircraft based on the Aircraft Target Class (ATC) attribute. Provide the same capability for Surface-to-Air Missile (SAM) sites that allows ROEs to fire or hold fire according to aircraft type. For example, a SAM site could allow firing on Cruise Missiles, TBMs (ATC Type Missile), or SU-27s (ATC Advanced Fighter), but hold fire on UAVs (ATC UAV) or Helicopters (ATC Rotary).

JTLS currently allows representing weather fronts through which certain types of aircraft are not allowed to travel. Enhance the detail of this representation .

-The model assumes weather is constant throughout all altitude zones, which is seldom realistic. It is possible to fly over some weather conditions, but not through the weather conditions.

-If an Air Mission cannot find an optimal path around a weather condition, the model currently does not know what to do with the mission and flies the mission through the weather condition. The model should represent consequences to the mission for flying through the weather condition, such as by increasing its probabilty of an inflight failure. Such probability would be a database parameter. 

Submitting a ground movement order to occur immediately returns an acknowledgement and an ETA message. If the movement occurs at a future time, an acknowledgement generated, but no ETA message. Generate the ETA messages for orders scheduled for future execution times.

Users cannot correct or alter the Cumulative KIA and WIA columns of a unit's Combat Systems array. This capability is needed to correct reporting errors.

Add concentration, cloud movement, and multiple hex coverage to JTLS chemical effects representation.

Air Transport and Insert/Extract missions have Transport Instructions that indicate the mission's destination. Entering the instruction number is necessary to edit these instructions, but WHIP users cannot view these numbers. Display this information on the WHIP.

If an Air Mission is not assigned a specific IFF Mode 3 Squawk, the model currently assumes the mission is squawking Visual flight Rules (VFR) 1200. Purposefully turning off the Mode 3 squawk cannot be represented.

Transportation Command (TRANSCOM) has a Single Mobility System (SMS) C4I system that allows personnel can to track the status of TRANSCOM missions flown, flying, and planned in support of a Time Phased Force Deploymnent Data (TPFDD) plan. TRANSCOM has limited resources to support all Combatant Command (COCOM) exercises conducted during a year, but visibility of the SMS and its data are desired during these COCOM exercises. To support this capability, U.S. Forces Japan (USFJ) has developed an SMS-Simulator (SMSS) that allows exercise participants to view SMS data on a realistic SMS display as the exercise progresses. This tool is proven to be very useful to USFJ, but is static in nature. Altering the plan to reflect the dynamic nature of the exercise forces is not possible. For example, if a missile attack closes one of the TRANSCOM used airbases, altering the force flow to represent that simulated closure cannot be accomplished. This ECP is intended to link the SMSS to JTLS to allow a more dynamic representation of force flow during COCOM exercises.

A database builder using JSYMS assigns a Organization Type to a graphic symbol. C4I systems require this Organization Type. JYMS currently displays only the Short Name of an Organization Type. Users should select by Long Name, but only the Short Name should be passed to the model. NATO and the U.S. use separate lists of allowable Organization Types. Develop a method to indicate to the user which Organization Types should be selected.

Represent the concept of IEDs or roadside bombs within JTLS. IEDs are typically represented represented as minefields that units must consider as they travel. All types of moving units, such as HRUs, ARUs, and Convoys, are susceptible to roadside bombs. These units typically travel at a designated speed and no cause-and-effect relationship exists between speed of the object and its ability to detect an IED before encountering it. Reviewe and evaluate the entire process to optimize the representation of IED detection, removal, and damage.

Add the capability to filter by area to the JOI filtering criteria. For example, do not display objects in Region A.

Place Air Missions on alert at off-board locations. The limitation of accomplishing their task on the game board is sufficient, but the missions must go on alert from the offboard location.

Represent the influence of aircraft weight on takeoff length, landing length, fuel consumption, maximum speed, and other effects.

When a unit is ordered to cache supplies, the model determines the cache in which the supplies are placed. Allow Players to indicate that supplies should be moved to Supply Storage targets and use an "Open" flag to indicate whether the supplies are detectable based on the "Open" flag. The supplies will not affect the storage capacity of the unit that owns the target. For example, ammuition should be stored in protected underground bunkers that cannot currently be easily represented. Unused Targetable Weapons returned from Air Missions are placed in open storage instead of protected ammunition bunkers.

JTLS does not consider differences between an Air Mission traveling at an altitude Above Sea Level (ASL) or Above Ground Level (AGL). All algorithms must be reviewed to develop a consistent and explicit representation of the altitude of an Air Mission or Cruise Missile (Targetable Weapon) at ASL or AGL. C4I devices display the altitude of an Air Mission at low altitudes as AGL. When a user orders an aircraft to fly at 10 feet, the JTLS mission flies at 10 feet AGL. The mission reports its altitude as 10 feet, when its actual altitude in a hex at 10,000 feet elevation is 10,010 feet.

Allow Helicopters to refuel directly from SSAs. The French indicated that this was a definitely used capability in the real world. It is common practice to pre-position hidden caches of fuel that helo pilots can use during various special operations missions.

Allow land-based sensors to detect land units. Add a capability for Land Radar Targets that used Ground Search Sensors to detect Land Units. Right now, a land based radar will detect ships at sea, but will not detect land units, even though that same sensor carried by a RECCE mission does detect land units. They said that land-based land search radars do in fact exist and should be included in JTLS.

Air Refuel missions allow only specific location orbiting instructions. Allow tankers to select and follow any available orbit path option.

Develop an "oval" orbit type that allows users to enter a series of transit points. A mission currently flies from Point 1 to Point 2 to Point 3, then reverses (the sequence 1, 2, 3, 2, 1, 2, 3,...). etc. The desired oval sequence is 1, 2, 3, 1, 2, 3, 1, 2, 3,..., which allows users to specify a "racetrack" mission course.

Provide capability for visiting exercise users, such as Battalion staff in training, to conduct off-site TRIPP replay at their command location without a complete JTLS installation.

Allow users to modify the Target Type List (TTL) of an Air Mission after the original order has entered the game

The Message Browser design currently allows users to open several Message Browsers and set each instance to retrieve different messages. This capability uses significant display area. Users have expressed a preference for "named" Message Browser tabs. Each tab could be named and assigned different retreival crtieria. Each tab would display only the requested messages.

JTLS Air Missions cirrently attempt to automatically avoid air defense. When flying over long distances, the missions avoid air defense by mving right or left along their straight-line path. When moving into the target area or heading for fuel, they avoid air defense by raising and lowering their altitude. The current logic for raising and lower altitude presents two basic issues:

The logic currently assesses only whether the avoiding Side has perception of the enemy air defense Side and that this perception is greater than 0.0. The logic does not attempt to analyze the danger of the site. The site may have  zero PK against the avoiding aircraft, but the aircraft still changes altitude to avoid the site.

Aircraft sometimes fly unrealistically low to avoid the air defense sites. A minimum altitude should be established for aircraft to avoid this unrealistic representation.

The SDC currently has an internal capability to have a specifically set perception or multiple perceptions. For example, users can indicate that only ground truth and Blue Side perception be placed in the SDC database. No other program within the JTLS system recognizes this capability. For example, Technical Control is unable to use the Interface Control Program (ICP) to configure the SDC to output only ground truth and Blue Side perception, and assumes that the SDC will always output ground truth and all Side perception data. This capability was built into the SDC to limit the data in SDR, but has been  unnecessary; however, this SDC capability can be used to speed the population of the Oracle SDR database if the Oracle server is executing on a multiple-CPU machine. Separate SDC processes could be used for a five-Sided game. SDC 1 could be used to populate the SDR with Ground Truth and Side 1 data. SDC 2 could be used to populate the SDR with Side 2, 3, 4, and 5 data. The same amount of data would enable an increase in the efficiency of downloading the current game state data.

JTLS currently allows an Air Mission to be assigned a route, which is a series of points through which the mission must travel. One of these route points can be designated as a refuel location. Specifying a landing point for helicopters or other aircraft types should be allowed, not necessarily for fuel, but for waiting without using fuel for a period of time.

Several Player options available to detach a portion of a ground unit. The Detach By Combat System option allows users to enter a specific list of Combat Systems to detach. The mandatory Days Of Supply field accepts a desired value and the model computes the number and amount of supplies needed to support the Combat System for the specified number of days. The order is rejected if the unit from which the systems are to be attached has insufficient supplies to support the systems for the specified duration. Add a field be added to the order that indicates whether the Days of Supply field is mandatory or only recommended. If the supplies are not available when the Days of Supply are recommended but not mandatory, the model automatically would revert to a pro-rated division of the available supplies and the order would be allowed to execute.

Information can be cut and pasted between WHIP locations. For example, copy a location specified in a message and paste the location in the "Find Map" box. If the the copied string includes one or more terminal spaces, the Find fails, implying that the entered location is not legal. Ignore terminal spaces when users paste a text string or the WHIP checks the location validity.

An Air Mission can be directed to fly to a specified point on its assigned path and wait until a specific absolute time, such as 061439ZJUN09, to continue to fly. Allows Players to optionally order the mission to wait for 30 minutes, a relative time instead of an absolute time.

When a model checkpoint is taken, all Scenario Data Repository (SDR) Tools, OEC, SDC, and ARC, take a checkpoint of their respective SDR data tables. When the model is backed up to a previous checkpoint and restarted model using the Push Order capability, the OEC tables cannot be reset to the checkpoint time because they contain orders that have already been submitted to the model and will be pushed. This makes management of what portions of the SDR will be restored difficult. Label each Critical order with the source of the order and allow Technical Control to stop all orders from a specific source when pushing orders during a restart.

Users can use the mouse scrolling wheel to zoom the WHIP Map view. The zoom center is based on the center of the current Map display. Establish the zoom center at the mouse cursor position instead of the Map display center.

A recent exercise required simulating the failure of an AWACS mission's ability to detect aircraft. This task could not be accomplished because the mission's sensors are always assumed to be on and operational. Players should be able to turn airborne sensors on or off. Consider whether to randomly represent airborne sensor failure or implement as a user action.

If an exercise requires that an Air Mission escort another mission, the situation cannot be realistically represented to the exercise audience. The escorting mission typically receives an intercept command. The mission intercepts the foreign mission and follows, which accomplishes the desired task. However, after the intercept occurs the escorting (intercepting) mission continue to travel at its maximum intercept speed, which is visible on the COP. The speed of an intercepting mission cannot be altered to a more realistic speed.

Implement either or both of these solutions: allow Players to alter the speed of an intercepting mission or build a JTLS Air Mission shadow capability. The existing intercept logic could be used, but the mission could automatically mirror the location and speed of the shadowed mission after the intercept.

Some JTLS orders require users to enter an OPAREA or National Boundary name. These fields are text fields that require users to type the object names. Provide drop-down menus of available OPAREAs and National Boundaries for user selection.

Currently a foreign object must be detected for it to be visible on a player's WHIP. Part of the information held for detected foreign objects is the time of last detection. This information is easily available to the player on both the IMT and on the SITREP component. The desire is to also hold onto the name of the object that made the detection and make this information available to the player.

There is a desire to better track detached squadrons created when aircraft are temporarily assigned to forward operating locations. Several ideas have been identified. One problem is that the naming conventions does not indicate where the squadron was located. Instead of naming the detached squadron as home squadron.1 and hone squadron.2, if the name could indicate which airbase the aircraft were located, it would be easier to track. For example, assume a squadron called FS312 has four aircraft detached to operate out of Ramstein. The detached squadron could be called FS312.RAMSTEIN or fs312.ICAO with the ICAO code for the forward operating location. If the detached squadron reattaches to the home squadron, it would only be used if aircraft were again sent to RAMSTEIN in our example. In addition special care should be taken to easily obtain detached squadron histories from the AAR database.

The Controller has the ability to change the majority non-name database parameters after game start. Currently the Controller cannot change the Basic Type of a Ship Unit Prototype which indicates that the ship is a combatant or a helicopter capable combatant etc. This was not done because of the implications of taking things away from ships. It is easy to change a ship basic type of combatant to helicopter-capable combatant, but not so easy to change it from helicopter-capable to non-helicopter-capable especially if it has a squadron onboard. The desire is to implement the capability to change the SUPs basic ship type.

Currently we need to create squadron units to fly UAVs. It should be possible to fly a UAV from a non-squadron unit.

Some targets own supplies. It is possible to look at the supplies owned by the target on the IMT, but the IMT table displayed contains the same information that units show. This includes the columns for Reorder Level and Stockage Objective. This information does not pertain to targets and should not be displayed. A separate IMT screen should be designed for Target Supplies

Users have requested that the allowable weapon list be reduced on the Fire Missile Order. This list can be reduced by the type of SSM that is selected. This ECP is closely related to ECP JTLS-2006-1761 and the design for this ECP should consider JTLS-2006-1761.

We are having trouble with C2PC. When the C2PC technicians built their system they only built the internal database to handle 2000 tracks. We have more than 2000 tracks because we are holding onto old tracks – they haven't been seen for several days. We need to build into JTLS the ability to remove tracks/icons from the display if they are old. We have always said that this should simply be a filtering option. Don't know if that is operationally true or not. As I see it we have several options: 1. Change JTLS – so we can drop tracks and reset ones perception to not seen. This would get passed to JOI and the tracks would be dropped. 2. Change JOI- so it can automatically send out a drop track when the last detection time exceeds some value. Obviously this would be a filter of some type and changeable on the “fly”.

A Recce asset has flown over the area and expected to see the 2INDIV at the designated location. It did not see the object there. It had a “good” look and so it knows that he is not there. When this happens, the model marks the object as “NOT SEEN”. The symbol for “NOT SEEN” is the general unit symbol which in this database is CITY (52). Thus an Infantry Division was being displayed as a CITY. The desire is to add a new "NOT SEEN" Unit Symbol to the database.

Users have complained that the time field on order panels is confusing and hard to manipulate. No suggestions have been made to improve the field. It also has been noted that the user cannot enter the time via the keyboard.

When delivering wet supplies to a unit, a full tanker truck of supplies is loaded and delivered. When it gets to the receiving unit, the full load is delivered to the unit. If it cannot store the wet supplies, the excess are dumped on the ground. Either the tanker truck should not be fully loaded or the excess should be backhauled. They should not be dumped on the ground.

During an exercise, it sometimes becomes necessary to alter the JTLS system. For example an error may be found in a message definition file. Technical Control has no step-by-step guide available to help them determine what to do. Such a Guide should be added to the Technical Controllers User Manual. As a minimum the following things have been identified: Change Symbols Change Organization Types In symbols Change Message subject Lines Change Messages Change Orders Change Static.voc files Change Dynamic.voc files

Currently the maximum number of entries that can be placed in a Utility List is a function of the type of list. The restriction is needed to insure that the size of the order does not exceed 32000 characters. A single type of Utility can be on more than one order. The list could contain 50 entries when on one order but only 5 entries when on a different order. This means that the Utility has the minimum sized specified. The maximum number of entries should be a function of the order field and not a list itself.

Naval Formations can be active (fully functioning), inactive (no ships in the formation), or incomplete (ships in the formation but no ships on stations, i.e. the ships are still moving toward their assigned station locations). On orders, the drop-down menu from which Naval Formations are selected cannot be restricted by the status of the formation. All formation whether inactive, active, or incomplete, are shown. Some orders cannot be accepted for inactive or incomplete formations. The drop-down menu should not show the names of illegal formations.

If a user wants to change a mission's Time On Target (TOT) or Time On Task (TOT) the only option is to cancel the mission and re-enter the order. It would be nice if this was feasible through the Change Air Mission Parameter order.

Currently when an air mission determines which combat systems it is aiming at the model determines whether the fired weapon is a precision guided or non-precision guided weapon. If non-precision guided the combat systems that are hit are "mixed" up a little to show there was not much control over what was hit. If the weapon was precision guided, the model always selects the highest priority items and hits those in order. Thus a helicopter will "fly" all over a unit hitting all of its tanks. Once those are gone it will go after APCs. This leads to an unrealistically good and a list of damage which make any sense. In reality the helicopter would hit a tank and then hit the APC next to it before continuing to the next tank. There needs to be some mix up even for precision guided weapons.

Currently the blast damage algorithm determines the distance between the target subject to blast damage and the impact point of the weapon. The Probability of being killed decreases the further away the target is from the impact location. This method does not properly represent CBU damage in which multiple bomblets are dropped over the blast damage area. For these type of weapons, we suggest that the distance between the target and the impact point not be considered. Instead draw a random number between 0.0 and 1.0 to represent the distance of a bomblet impact location. We suggest that no new data is required for this effort. Simply, if the TW has multiple sub-munitions, is a conventional effects weapons use this algorithm.

Current there are five "dummy" target categories. Ships is one of them. We would have a major reduction in data if we removed ships from this list. If we did so, we would need to hold the data for PHL and PKL for ships in a different way. Bernie is suggesting that Ship PKL and Ship PHLs become there own data structure and that an SKL point to a target PHL, a target PKL, a Ship PHL, and a Ship PKL. Finally we would need to determine how to put the data held on the IIP TGC object for ships since they would no longer be held there. These two data items are the probability of detection multiplier and the probability of detection moving multiplier.

As part of the Change Air Mission Parameter order, the user should have the ability to cancel a portion of the mission's route, such as canceling the transit route or the egress route without requiring the user to enter a new "dummy" route

The Strategic Lift mission was developed for use with the Joint Deployment Logistics Model (JDLM). When the mission was off the JTLS game board, the mission belonged to JDLM and so much of the model processing for these missions while off the game board can not be accomplished by a JTLS player. JDLM is no longer being used with JTLS, but the strategic lift mission is very useful. We need to implement the full capability within JTLS. this includes altering these missions, creating list status reports for these missions and allowing these missions to be canceled or changed while they are on or off the game board.

Any air mission has the ability to place a route hex with a Leave Not Earlier (LNE) than time in the mission's route. In addition several missions allow for multiple stops. At the stops the user also has the ability to specify an LNE time for the stop. Prior to reaching the airborne hold point or the ground delay point, this information can be changed. Once at the hold point the time cannot be changed. The user should have the ability to cancel the LNE time or extend the time.

JTLS does not fully represent High Power Microwave (HPM) weapons. It should.

It would be good to have the WHIP visually identify air missions that have fuel problems especially if their expected tanker is not available.

It would be easier if the Manual Pair order had an additional field which told the mission to ignore the break off logic. This can be done with a separate order but it is time consuming to do this in two steps. The one order with the additional field would be more efficient and help the air cell user.

n JTLS 3.2 the Lanchester attrition logic changed to a random integerized version of Blanchester. The Lanchester Development tool, responsible for developing Lanchester coefficients no longer works. This ECP requests that a new LDT be created.

Currently before an aircraft can pass TADIL-J / Link16 information a receiver must be in range of the Link16 transmitter. Daisy-chaining is feasible in which one aircraft passes information made available from another aircraft that is out of range. This is currently not represented in the model.

The desire is to add information to the air-to-air engagement records and the Surface-to-air engagement records. The new information would be the number of aircraft that existed in the mission prior to the start of the engagement.

Currently the AAR does not do a good job of representing and saving data concerning multi-element targets. These targets can move during a game from one unit to another (either a detachment or an HRU). This information needs to be saved in some manner.

Currently the Air Mission Package table does not include the time associated with the Air Mission Package. The time can be either a Time Over Target (TOT) or a Reference Time. This information needs to be in the AAR table.

The desire is to create a query that can be used to report all information held in the AAR database concerning a given air mission package. This is a complicated query and needs to be delivered as part of the JTLS system.

Currently within the AAR we link order to specific units, but we have no ability to link orders to Naval Formations. The ECP requests this ability only for Naval Formations, but we believe a full evaluation of the orders needs to be accomplished to determine exactly what orders should be linked to objects. For example, should air mission orders be saved and linked to the missions.

Currently the AAR only adds records to the data tables. For speed purposes updates to records are not accomplished. This means that we cannot update the air mission record with information such as ATO_ID and actual number of aircraft launched. The desire is to have this information available in the AAR Air Mission table.

Sometimes the user wants to alter the results generated by the model and there is no way to represent this in the AAR. For example, the mission had 3 aircraft killed, but for exercise purposes, the Controller only wants one aircraft kill counted. This capability needs to be added to the AAR

JTLS has a Regain Object order but it is supposed to only be used in an emergency when JTLS wants to mark a unit back in JTLS because the federation has been stopped for some reason. The Regain order should also be allowed in a non-emergency situation to follow the JMRM protocol to ask JCATS for control.

A naval unit patrol an area based on the speed that the ship entered the patrol area. Thus the user must set the desired patrolling speed on the last leg of the ship's Ingress route. This is arbitrary and a nuisance to set up. The order should simply have a field that holds the speed at which the ship should patrol.

The Naval Shadow order has no associated times, i.e. Start time or Stop time. This makes it hard to setup the order and leave when running the model in either a batch mode or a non-monitored mode during night operations. Similarly the Patrol order has no Start time, but it does have a Stop time. This ECP requests that all naval mission orders be reviewed and consistently include both a Start time and a Stop time for the mission.

Currently JTLS reports the weapon load of all aircraft, whether they are owned by JTLS or JCATS. On the other hand JCATS only reports the weapon load for their own aircraft. The desire is to have JCATS report the weapon load even if the aircraft are owned externally. This is primarily a JCATS ECP, but needs to be prioritized by the JTLS board because it will involve JTLS testing resources.

As a JTLS game executes it is possible to fill and use three sets of Oracle tables, the AAR tables (filled by the After Action Review Client), the OEC tables (filled by the Order Entry Client), and the SDC tables (filled by the Scenario Data Client). The AARC and the OEC automatically create a backup of their tables each time the CEP does a checkpoint. The SDC does not need to do so because its tables are completely filled from the current data held in the JODA each time the game is restarted. Some users have created their own tables and these tables are not saved as part of the checkpoint procedure. The desire is to provide a capability that users can "tap" into to save their non-configuration managed tables as part of the JTLS checkpoint procedure.

Need to relate messages to the orders that generated the messages. NC3A tools enter requests for information and when the return messages are generated they have no way of knowing which message was in response to which order. Including the order name in the subject or as part of the Meta-data is needed. This of course also requires that all order have a reference - currently many of the query orders do not have references.

You can filter messages on units and their subordinates. The desire is to be able to filter not just on a unit but on a unit attribute, such as give me all message for units that have a posture of "WIPED OUT". That is only an example, expanded attributes need to be designed.

When you cancel an air mission there is a reason code that the user can enter. The desire is to have a user code called "Operator Error". The end result is the mission would stop completely, not go into maintenance, and no MISREP would be generated.

The desire is to be able to draw a box around a group of units and magic move the entire group to a new location. This is much like the GDP capability prior to game start. There is a need to do this during the game.

ECP entered at the international users conference. The desire is to allow an ARU to over-watch a refugee camp, which is also represented as an ARU.

Communications Intelligence is not represented in much detail. This should be improved.

There are many detailed weather models available. Have them output detailed weather information and have it read in and used by JTLS throughout an exercise.

The user should be allowed to setup Logistics routes and automatically generated convoys would follow those routes and not necessarily the optimized routes.

All naval routes should allow the player to select the speed at which the naval unit should move along the route.

Air mission and convoy crew requirements should be properly represented in JTLS.

The desire is to build a disguise or guise function into JTLS similar to the JCATS function. This GUISE function should be able to be assumed by all objects, HRUS, air missions, convoys, ARUs, naval units.

Combat System Damage Reports should list how many went into maintenance and how many were catastrophic kills.

NIIRS is a rating scale given to imagery sensor. The scale indicates what type of information is available from images collected by the sensor. JTLS should properly represent NIIRS and model the restrictions by a sensors NIIRS rating.

The ELS needs to represent terrain in more detail. It would be good if its representation of terrain matched JCATS.

The JMRM needs to make use of the munitions detonation interaction so it can more easily have other models join the federation.

Allow for cross-model aircraft refuel. A JTLS tanker should be able to refuel a JCATS owned aircraft and vice versa.

JTLS needs to model Forward Observers so guided weaponry can be properly represented.

Allow better representation of HARMS across JTLS and JCATS. For a HARM to work properly it needs to home in on a radiating target. A HARM fired in JTLS and aimed at JCATS needs to know whether the target is or is not actively radiating. The reverse also needs to be properly represented.

Allow JTLS owned minefields to cause damage to JCATS owned objects and vice versa.

Allow JTLS to fire on Cruise Missile in JCATS, much like JTLS can fire on JCATS aircraft. Similarly let JTLS cruise missiles be attacked by JCATS owned air defense capabilities.

The Pass Control Order should be easily accessible for objects that can be legally passed to JCATS.

Improve JMRM BDA reporting. For example, JCATS kills are not reported within JTLS BDA boxes.

If a JCATS units fires on a JTLS unit, the JTLS unit should automatically initiate counter-fire.

Be able to pass naval units back and forth between JTLS and JCATS.

HRUs must be defined in the JMRM XML file to be marked as passable objects. HRUs should work like air missions and they should be able to be created dynamically and then recognized by JCATS.

The AAR Replay Tool called the TRIPP does not deliver messages. Add the capability to have messages delivered to the TRIPP at their appropriate times as time is moved forward during replay.

Several improvements are desired to the template building tool that is used to create ELS templates.

Allow units that can be passed to JCATS to Attach, Detach, and Cross-Attach prior to the passing the unit to JCATS and while the unit is owned by JCATS.

Allow the Controller to set the perceived capability of an object. Currently a Controller can set the actual capability or set the perceived capability to actual capability. It is impossible to select what the desired perceived capability of the target. For example, the target may be completely dead but for exercise purposes, the Controller may want one side to believe the target is at 50% strength. This capability should exist for all perceived attributes.

The MISREP damage report section summarizes the damage caused by each weapon. The damage should be summarized by target or object damaged.

The user can deeply leaflet but there is never any feedback on whether it is doing any good. The submitter never explained exactly what feedback should be provided nor any indication of what you would get in the real world. It is possible that information about desertions is the type of information desired.

In the Message Browser it is possible to search through displayed messages for a specific string. The Message Browser finds the string and displays the messages that contain the matching string. The desire is for those messages to be placed in a new Message Browser that is automatically opened, leaving the original Message Browser to display the current filtered messages.

Currently the launch capable message includes only the name of the mission. It would help if this message include more information about the mission such as home squadron and aircraft type.

The desire is to allow the user to cancel and Air Ground Attack Mission and if it has air-to-ground weapons still available, it should be able to convert to an Orbiting OAS mission until the player decides where the mission should go or what the mission should attack.

It is not easy to build the Link16/TADIL-J Source and Track numbers. It would help if a summary report of this information was available in the DDS to help with the building and verification of the data during the building process.

Each row on the IMT Combat System Screen displays the information concerning one of the Combat Systems owned by the unit. One of the columns lists the percent capable of the unit. When viewing this display that column shows the same value for each combat system. It would be more useful if the column displayed the percentage of the specific system that are still alive instead of the percent strength of the unit as a whole. In addition the percentage of a supplies basic load is also desired on the Supply Category screen.

Configure a WHIP to be used as a Common Operational Picture (COP). Design must take into account a WHIP that can be configured to enable/disable these permissions: no orders, no IMT, no MPP, access to Command Hierarchy, and access to Logistics Hierarchy. Display Unit Long Names, Not JTLS Names

Each displayable object on the WHIP has access to a "Context Sensitive" menu from which a user can easily access an order to give to the unit. When you right click on the object, the context sensitive menu appears. The contents of this menu is pre-determined by the development team. The ECP desires that the contents of this menu can be altered by the user to meet their specific needs.

When an air mission order is entered, the user can submit a lit of objects that the mission should search for. This list is primarily used to determine what weapon load should be placed on the mission. During the mission's flight it is also used to determine, especially for Armed Recce missions the type of objects that are important and should be considered when determine what should be attacked. Once the mission order is accepted, this information cannot be changed. The desire is to have the capability to change this information.

Air Mission Target search lists do not have the ability to list specific SUPs. Thus if a user is only interested in attacking certain classes of ships, it is impossible to do so using the currently implemented target search list capability.

The desire is to have visibility of the contents of a convoy on the IMT. Thus the owner and the Controller could highlight a specific convoy, click on the "Supply" Quick retrieval button and a new IMT window would come up listing all of the supplies on the convoy.

There are currently two versions of the USMTF Initial Imagery Report (IIR) supported. The first lists all of the intelligence collected by the mission and the second organizes the information by the Directed Search Area in which the information was collected. The format of the report is determined by the Controller and can only be changed by the Controller. The desire of this ECP is allow the Player to select which version is desired. Presumably the user wants to look at the report using both methods and then selecting which method should be sent forward to the exercise audience.

The JOI should automatically adjust the size of fields to accommodate different object name lengths.

When an aircraft goes down in JTLS, it is possible that a Downed Pilot HRU is created. The name of the HRU is based on the call sign of the air mission from which the aircraft was destroyed. This naming convention does not match what is desired for the Common Operational Picture (COP). This ECP simply needs to change the name of the HRU to match what is desired for the COP.

Within the JTLS Combat Events Program (CEP) each air mission that is active has a unique name. The name that is sent to the COP is a sub-string of the unique mission name in JTLS. The result is that the COP has two missions with the same name and the track keeps jumping back and forth each time the JOI sends an update to each of the air missions. This ECP asks that the problem be solved in some manner so duplicate COP missions names cannot occur.

The status of some JOI tracks is confusing. The status descriptions should be made more user friendly.

JTLS can be executed on either 32-bit or 64-bit machines. On a 32-bit machine the maximum size of an order is 32,000 characters. On a 64-bit machine, the maximum size of the order string is significantly larger. The model has not been changed to allow for the increase in order size capability because the Order Verification Libraries do not know whether the 32-bit limit or the 64-bit limit should be enforced. This ECP asks that the OVT be informed whether the model is running on a 32-bit machine or a 64-bit machine and which order size limitation should be enforced.

Currently if you want to move combat systems from one unit to another, you need to detach a unit and then attach the unit to the receiving unit. The desire of the ECP is to allow the player to directly move combat systems from one unit to another in a manner similar to the Mandatory Transfer Supply Order

Currently it is possible to Attach one unit that owns targets to another. When it comes time to detach a unit, you cannot detach the targets. Furthermore if you says you want to detach 30% of a unit, 30% of the combat systems are taken but there is no ability to take some of all of the targets owned by the unit from which the detachment is being taken.

It is not easy to install JTLS. The desire is to create a script procedure to automatically install JTLS, in the same manner that Personal Computer (PC) software is delivered.

Properly represent the transmission of identifying information that is required of all civilian shipping. This information should be fed to C4I systems.

Generate Link11 messages and feed these messages to the appropriate C4I systems.

Create a WHIP-like interface for the Air Tasking Order Generator or include its capability within the WHIP itself.

The following should be done for all objects (Ground, HRU, Naval): a. Compliance messages should include the destination in addition to the expected arrival time. Example: Unit 123ARMBN's withdrawal has approximately 0 days 5 hours and 25 minutes of travel remaining. The estimated time of arrival at 12-34-56N 023-45-54E is 022357ZFEB07. b. The Unit Strep message response should also show the destination to which the unit is going.

Currently the WHIP SITREP panel is defined as part of the various WHIP menu files. The desire is to allow the Player to decide exactly what information should be displayed in the SITREP window. The same is true for the pop-up object information bubble. The user should be able to select and design the information that should be placed in the bubble.

Allow the user to input spaces into the long name of a target as is possible with the long name of units.

Request a new ATOT report be created that we can e-mail to the response cell forward for Keen Edge 07. Request the report include the following fields: ATO ID/CHG#/UNIT NAME/MSN#/CALL SIGN/ SCHEDULED TAKE OFF TIME/TIME ON STATION/TIME OFF STATION/ ESTIMATED LAND TIME/ MISSION TYPE/# AND TYPE AIRCRAFT.

The WHIP shows the user the last seen location for foreign objects even if this information is several days old. The desire is to be able to filter which objects are seen by the time of their last detection so the user is not confused by the old information. This ECP has been expanded to include the ability to filter objects based on other object attributes. The design will outline which attributes are to become filterable attributes.

Two stationary naval units cannot detect one another. This limitation needs to be fixed.

Every unit in JTLS has a percent capability which is a measurement of their current strength or ability to conduct operations. This ECP is requesting that the user be given the ability to ask for a rolled up unit strength. For example, the user could ask for the rolled up strength of a Corps. The model would take that unit and all of its subordinates and determine what the full strength of the rolled up or combined assets.

Every WHIP has the ability to select the units of measure that should be used to display information on the IMT and within messages. This information must be setup by the user. It cannot be shared. The ECP desires the ability to share this information. Thus only one WHIP would need to setup the UOM preferences and this one setting could be shared across all WHIPs.

During a recent exercise, JTLS could not accurately represent Air Defense Artillery (ADA) missile allocation. A missile allocated to a missile target could not be recalled or reallocated to other targets. This capability is extremely important when an ADA target is damaged. The Player is unable to move the remaining missiles to other operational ADA sites. Accurate missile representation is therefore not possible. The Controller can magically assign these "abandoned" missiles to other functioning ADA sites. However, if a damaged site is repaired, these missiles immediately become available again and more missiles than desired are accessible to the scenario's represented forces. At the time that this ECP is implemented, the design must include the capability to view the weapons that are owned by the ADA site.

Almost all aircraft and ships have some form of passive electronic surveillance measures (ESM) and active sensors. These devices are able to determine the direction of incidence and the type of sensor. This needs to be more robustly represented in JTLS.

Create a new Periodic Report called “AIRBASE REPORT”. It should contain the following information: a. Sorties flown during reporting period by base and type of aircraft at that base. b. Report should also summarize aircraft losses by type. The losses should be presented in a spreadsheet format making it easy to copy and paste into an excel type spreadsheet. c. Should be broken down by faction. d. Weapons expended per base (fired, dropped, due to enemy action and lost due to aircraft loss). e. Damage sustained per base. No need to list supplies, just combat systems and targets. f. Fuel used. g. Fuel lost due to enemy action. ICs should be able to request this periodic report so it covers the entire exercise period or an interval specified by the IC. In fact, all requested periodic reports should have this option. ICs should be able to tell the model to give them a report at a pre-determined interval. We need some way to keep from double counting or presenting confusing facts. The current report format is confusing because some missions are in the air at the time of the report. Maybe we could have two categories: tasked and flown. Tasked would be those that obviously were tasked during that reporting period and they could be awaiting launch or in the air. Flown would be those that had actually flown and had landed during that reporting period. We might also want to make a distinction between alert aircraft and those that actually flew. This seems to always come up. The next issue is that JTLS always lists every type aircraft in the database or every type mission. We only want the aircraft listed at that base or the mission type actually flown, or the munitions actually expended - no extraneous data.

Currently supply convoys will not deliver supplies to a unit that is a part of a force-on-force Lanchestrian battle. The desire is to properly model the delivery of supplies to a unit under these conditions.

If Unit A is told to attack Unit B and Unit B is told to attack Unit A, each unit starts moving towards one another into an attack position. The units pass each other and end up where Unit A takes the old position of Unit B and Unit B takes the position of Unit A. The attack location should be changes as the unit being attacked moves. The same situation occurs if Unit B starts to withdraw. Unit A should continue to attack toward the current location of Unit B.

Every ground-based unit has the concept of the distribution of their combat power. The unit's distribution of their available combat systems is altered as the situation around the unit changes. When a unit is in defend the combat systems are not shifted. The ECP is requesting that a unit, while in the Defend posture. re-distribute its combat power based on the location of enemy units within combat range.

There is an inconsistency in the information required for many of the ground orders. Some orders take place immediately, some orders have the user enter the start time for the order and some orders have the user enter the time at which the task associated with the order should start. The purpose of this ECP is to make the Ground orders more consistent. The user should be allowed to enter either the order start time or the order task time which would occur after the unit moved into position for the task.

When listing the names of Combat Systems on Order panels, the names associated with the CSP of the Force Side Commander are used. This is confusing and is particularly hard when attempting to detach a unit by Combat Systems when the unit uses a CSP other than the one used by the Force Commander. The desire is for the Order Panel to list the CSP names of the selected unit.

When you cancel an air mission, the model picks up the closest point on the air mission's egress route. The desire of this ECP is to add a field to the Cancel Air Mission order indicating that the mission should go straight home and not pickup the closest egress point.

The desire of this ECP is to rick click on a Refuel Chit listed in an IMT window and alter the data associated with the Refuel Chit. For example, the chit could be deleted, the amount of fuel to be transferred could be changed as well as the time of refuel or the tanker that is to provide the fuel.

Currently Naval Formations are not displayable objects. The purpose of this ECP is to make them displayable objects. Once the object is displayed, the desire is to activate the object's context sensitive menu.

Naval Formations are listed on the IMT. The WHIP needs the ability to create a Context Sensitive Menu for Naval Formations, so the user can right click on a formation name in an IMT window and have formation orders easily available.

It is possible for the WHIP to restrict units listed in a Fire Artillery Order to those units capable of firing the select artillery weapon. The desire of this ECP is to restrict units listed in the Fire missile order to those units that own an SSM target which can own the selected SSM. This is related to ECP JTLS-2009-10162 that asks that the Targetable Weapon list be "tied" to the type of SSM selected. When designing this ECP, JTLS-2009-10162 should be considered.

It is not unusual for a single player to be responsible for more than one side. To accomplish this task, the user needs access to a WHIP for each side for which it is responsible. This ECP desires to access more than one side from a specific WHIP. In some manner the ECP desires that the user can select a button and switch from a Green-side perception and access to Green side forces to a Purple-side WHIP and Purple side forces.

When a user asks to display an Order Group Editor on a WHIP, the Order Group editor panel is opened and displays all available orders organized into folders - one folder for each order type. The folders are named using the order type abbreviations and are open, i.e. list each order within the folder. It is possible to "close" the folder, reduce the size of the order list, so the orders contained within the folder cannot be seen. This ECP requests that all folders should start out closed and should be named with the full order name not the abbreviation.

Currently, an IC does not get Lanchestrian damage reporting outside of a BDA box. There needs to be some method available to obtain this information.

Create a new logistics report called the "Consumption Report" (CONSREP). Follow the USMTF format and information.

The Joint Deployment Logistics Model (JDLM) is a strategic logistics model which receives operational data from several real-world Command and Control (C2) logistics systems and feeds other real-world logistics C2 systems. The HLA link between JTLS and JDLM provides the access to these systems for the JTLS audience. Within this link JDLM is responsible for controlling ships and lift aircraft until they reach the JTLS play-box, where ownership is then passed to JTLS. At this point JDLM issues the corresponding movement plans for strategic sealift or airlift missions. After receiving the plans JTLS models and continues the strategic lifts within the JTLS theatre. A movement plan consists of one or more strategic stops and a stop is either a port, an airbase, or a geological location. Currently, JTLS has the capability to add or update stops in a plan that has already been sent, but does not have a means to remove a stop. During the Terminal Fury (TF06) exercise, various JDLM originated missions were planned for stops at a particular airbase for on-loading/offloading. Later the missions were required to "divert" from this stop due to problems at the airbase. Because the delete capability did not exist at the time the only method available to accomplish the desired diversion was to modify the stop location. This ECP implements the modifications necessary to enable an external model such as JDLM to remove any existing stops in a movement plan for sealift or airlift missions as they are held in JTLS.

Currently Technical control must check to make sure that there are no objects in the middle of being transferred from JTLS to JCATS or vice versa prior to taking a federation save. This should automatic to insure that problems are not accidently introduced by a federation save.

JTLS models Torpedoes in a similar fashion to Cruise Missiles. In fact the Cruise Missile object class is used as the class from which Torpedoes are created and updated in the JODA. During the Terminal Fury '06 exercise a client of the JODA was not capable of distinguishing Torpedoes from Cruise Missiles when updating various C4I systems. This left the GCCS users, for example, without a clear method for identifying Torpedoes as they were being detected. The JODA needs to indicate whether the cruise missile is airborne or underwater.

All air missions with Air Search radars should activate the radar upon launch and leave the radar on for the entire mission. In the current JTLS only AWACS, CAP, and Escort missions turn on Air Search sensors for their entire route. Other missions perform the function when they arrive at their orbit location, and turn them off when they leave the orbit location. Modifying so that all missions will turn them on at launch will cause the generation of an ELINT report on takeoff for all missions that carry air search sensors.

Currently DSA information is not provided through the SDR database. DSA names and their corresponding regions should be made available.

When creating an Insert/Extract or Air Transport mission the operator submits a Delivery Item List of actions for the air mission. The operator may also modify items on the list by number. However, every time a modification is done the numbers assigned to all items are changed, and the operator has not report that will provide him with the current numbers.

The operator can Add and Remove DSAS from a RECCE missions list of search DSAs. However no method exists for the operator to get a list of the mission's current DSAs.

When creating Insert/Extract or Air Transport missions the operator specifies a Delivery Item List. Each point within this list can have a Not Leave Earlier Than Time. This instructs the mission to stay at that location at least until the specified time. The problem is that once the mission is at that location, and in HOLDING posture, it is not possible to adjust this time.

A RECCE mission from Airbase A was assigned as a strip alert mission at Airbase B. Once on alert, the mission was sent a Change Mission Parameter order assigning Airbase B as its Return Base. When the mission went off alert it launched, flew back towards Airbase A before flying to Airbase B. This was in accordance with the mission's Egress route. The mission should have realized it was already at the new home base and discarded its Egress Route.

Air missions with on orbit times before Started are submitted at Started. They exceed their orbit times. When a strip alert or orbiting mission is submitted the operator specifies the On Station Time and the Duration. These two pieces of data are used to calculate an Off Station Time which is held by the model. This is the time that the mission will leave its orbit/strip location even if it is late arriving there. If the On Station Time is less than or equal to zero, the Off Station Time is set to the current game time plus the Duration. This allows the user to enter ASAP as the On Station Time and still have a reasonable flight profile. The problem is that ATO missions with an On Station Time before game start will also fall into this category, and will therefore stay at their orbit locations longer than the ATO calls for. An exclusion should be permitted for such missions so that they will terminate at the scheduled ATO time.

Since the OPM pages are static pages, generated only when the OPM program is run, they do not reflect the dynamic nature of a JTLS game. If the player creates a new unit, via detachment, during game play that unit will not have an associated OPM page until the next time the OPM program is run. It is desired that a more dynamic OPM be developed.

When a full sized scenario is brought up with WHIPS assigned functional area names instead of force side names it can be difficult to find information on a specific WHIP on the Synapse. If the WHIPS were broken into force side groupings the task would be easier.

Currently to view road networks within the WHIP you must be zoomed in close enough to see hexes. It is desirable to be able to see the road networks on the larger map.

It would add a lot of flexibility if the WHIPS accepted the names of objects within location fields. As an example, an Airlift order could use the name of the unit being lifted in the location field. The WHIP could then translate the unit name to a valid location based on the operator's current perception.

JTLS requires a higher level of fidelity in modeling Effects Based Operations (EBO) in order to meet TC AoA Gaps and Requirements. Refer to attachment in this ECP.

JTLS requires a higher modeling representation of Virtuals and must also have the capability to dynamically interface with Virtuals in order to meet TC AoA Gaps and Requirements.

JTLS requires a higher level of fidelity in CBRNE Modeling to meet TC AoA Gaps and Requirements. Refer to Attachment to this ECP.

JTLS requires a higher level of fidelity in Medical Modeling to meet TC AoA Gaps and Requirements and support JMRM federation.

JTLS requires a higher level of fidelity in Civil Environment Modeling to meet TC AoA Gaps and Requirements.

Develop and use External Data Representation (XDR) Encoding Schema.

Model Array Radars in JTLS.

Suggest modeling different Sonar environments by polygons. Polygon will have specific sound attenuation loss factors and other transmission loss factor.

JTLS does not model ocean currents and non-moving ships drifting with the currents. Of particular importance is the impact on drifting mines and HRU small boat movement and barge movement. This should be properly represented.

Surveillance Aerial Vehicles/Aircraft Detection of Ssubmarines (to include sonobuoys). Required further design discussion as to what capabiltiies JTLS is not correctly modeling.

Develop the JTLS to accommodate two JTLS Play boxes simultaneously -- in a single game or through federation with another JTLS game.

Sea state affects the speed at which ships can travel, the ability to conduct flight operations, and the ability to fire weapons or accurately fire weapons. All of these affects need to be modeled within JTLS.

Model Ship towing.

JTLS does not do a very thorough job of modeling Anti-radiation missiles only being able to attack targets when they are actually radiating. This needs to be corrected.

JTLS does not model unmanned underwater vehicles . This needs to be properly represented.

Properly model Inter-launch time, inter-recovery time, and the time required to switch from launch to recovery operations onboard naval carriers.

JTLS does not model some of the precision guided munitions associated with naval warfare. Specifically the difference between acoustic and non-acoustic weapons are not represented nor is the concept of wake homing weapons.

JTLS does not represent the impact of cloud cover and cloud height on detections. It should.

Port storage capacities are not properly represented. Not only does JTLDS need to represent the maximum number of ships in port but the supplies that can be stored and off-loads need to be considered for port capacity.

Sonar detection ranges are greater in deeper water.

Commercial shipping must transmit information identifying the vessel. This needs to be represented in JTLS and picked up as part of the Electronic Emissions intelligence data.

ICs are unable to assign IFF for hand jammed air missions. He must use the Change Air Mission Parameter order forcing him to give two orders. Add IFF (1, 2, 3, 3C, 4, etc) capability to all air orders using a pull down menu in order to keep the order panels small. This should be an optional field.

Current air operations often dual task tactical aircraft with air-to-ground and air-to-air missions. JTLS does not have this capability. If one launches an attack mission it will RTB after dropping its bombs. The only way to keep it in the area is to assign it to a target using the Assign Multi-Target order and keep one bomb on it. Recommend changing air orders allowing an IC to give an aircraft a primary mission (OAS for example), a secondary mission (CAP) or even a tertiary one. The aircraft would fly to its assigned area, perform its primary mission then turn into its secondary role. As an alternative, the CCB would really like any mission to change into any other type of mission given the database indicates that the aircraft has the ability. Exceptions maybe Airlift type missions, but as much as possible the desire is to be as flexible as possible.

Currently JTLS will not allow a unit to be supported by a different side within a coalition. Allow an IC to: 1. designate a support unit from a different (friendly or neutral) side in the database build. 2. designate a support unit from a different (friendly or neutral) side via player order. 3. do all logistics related orders (reports, mandatory transfer, directed resupply, etc) to units on friendly or neutral sides. JTLS will also automatically generate supply convoys in accordance with the support unit's logistics prototype. 4. Automatically break the above support chains if side relationship changes to suspect or enemy and assign an appropriate own side support unit. 5. Transport other side units by truck, rail and barge.

Airlift order lack flexibility. IC should be able to give multiple airlift instructions to the same mission via the same order panel. Allow for greater flexibility so an IC can launch a mission to pickup a unit at one airbase or location, drop it off at another then continue for subsequent missions. It will also allow the airlift order to be much more efficient especially when dealing with ships. The HRU Insert/Extract order should also be changed to allow for the mission to pickup or drop off the unit at either a unit (naval/airbase), or a location.

This ECP would provide either for the creation of a new Player logistics order or would provide for an additional option on the Directed Resupply order. It would allow the Player to instruct a unit to move to the location of a known Supply Storage Area target (SSA) and take specified or needed quantities of supplies from it.

Requirement is for JTLS terrain to develop away from hex based logic. Rivers currently must run along the edges of hexes. Roads must run through the center of hexes. Roads and rivers in JTLS should correctly match geographical locations and directions as depicted in real-world. Use of polygonal representation must be compatible with current JTLS terrain generation tools such as JIDPS.

A new Investigate Command is needed. This command should tell an air mission to “investigate” a point, then continue with its current tasking. The end result would be that a specific aircraft would be identified as no problem or a problem. There are many other issues other than simply accomplishing the investigate. Specifically, this ECP needs to address the idea that suspect/enemy sides fly air mission that have no ill intent and other that do have ill intent. The investigate command needs to be able to tell the difference which means that the enemy needs to indicate its intent by the order - this may be possible via ROE or at least some flag on the order.

The user should be allowed to send a message to an opposing side concerning the force down of an aircraft. If the aircraft does not land or accept the force down, the player can then shoot it down. The timing of this capability is extremely important and the design needs to consider whether this force down will be automatic or require actions from the opposing side player.

Some users have indicated that the Area Report, Unit Report, and Target Report similarities and differences are not well documented or are inaccurate. A special review of these capabilities within the documentation needs to be accomplished.

Add a Pre-Strike Recce mission to improve perception and lead to the “Yes” flag for the new detection required capability.

When trying to extend an orbiting missions time on station, the model rejects orders which extend a mission beyond its crew duty day. The desire is to place a flag in the model to indicate whether all missions or a specific mission should ignore the crew duty day limitation.

The user needs the ability to tell an Air Refuel mission to leave its orbit and meet a mission that needs fuel.

Assign any aircraft or ADA unit for any side/faction a Weapons Engagement Status (Weapons Free, Hold, or Tight), including dual status for TBM-equipped systems and Primary Target Line (PTL) and Ground Impact Point (GIP) radius input for ADA and surface/ground equipped systems.

When reporting air mission damage, the order in which the messages are generated is not optimal from the users perspective. For example, a mission of two aircraft were engaged and killed by SAMS. The messages appear as follows: Aircraft from AREC-010007 Lost Mission Report AREC-010007 - Completed Mission Commander Trouble Report - Mission AREC-010007 Aircraft from AREC-010007 Lost Mission Commander Trouble Report - Mission AREC-010007 This order is confusing. Here is what is happening - first this message order is reversed in time, i.e. the first message on the list is the last message entered. So read the messages in reverse order and the only problem is that the MISREP is before the last lost aircraft report. That is the only item that needs to be fixed with this ECP.

External Events allow the user to plan an event, such as sabotage, at a specific game time. These events are typically used to fulfill Master Scenario Event List (MSEL) items. In JTLS, either the database builder can create External Events or Senior Control can as the game is executing. Once created there are only two choices: the event executes as planned or the event is deleted and never executed. We need the ability to alter the time at which the event will occur.

Currently if a mission flies through the same hex as its Refuel Chit assigned tanker, the mission receives fuel. The ATO-Translator makes sure this happens. For a general user this is a time consuming process to insure this happens. Improve the model logic so the mission automatically knows that it should go to the tankers orbit location on either its inbound leg or its outbound leg.

Provide the option for the user to specify whether a CAP mission with a protected mission list should stay at a pre-designated orbit location or whether it should move to the centroid of its protected missions. This allows to create, packages of missions without really having packages defined.

Given the Wild Weasel mission a “Runway” capable” mode. Any orbiting mission profile should have this capability.

Allow Electronic Combat missions to be a part of air mission packages. As part of the order allow the user to specify the stand-off location for the mission. The user should decide if the mission should follow the package into the target area or standoff and do its jamming.

The ATO-T needs a new warning that the selected squadron is currently not in the theater. This warning would have avoided several problems during a recent exercise.

The user needs the ability to specifically tell a mission the direction from which an attack should occur. This capability can be accomplished through an ingress route, but an easier method is desired. The same should be done concerning the direction the mission should leave the target area.

JTLS needs to better model visual identification. An air search sensor should indicate what information, such as aircraft number, aircraft type, altitude, and location can be obtained from the sensor. Only the information should be provided for the detected mission. For surface sensors, especially against naval units, the specific ship that has been detected can only be verified by a visual ID. This needs to be better represented.

An air mission should not make its divert decision when it arrives at home. If the mission realizes that the base is closed and will not be open prior to getting there, it should go directly to its designated alternate base.

Currently a mission can become launch capable even if not all aircraft are assigned to the mission. If aircraft come out of maintenance prior to the mission taking off, the newly available aircraft are not added to the launch capable, but incomplete, missions. The newly available aircraft should be made available to these launch capable missions.

Allow an attack mission to stay in the strike area as a RECCE mission after dropping its weapons. Currently a mission says I have no weapons; therefore, I am obviously of no use - go home. In addition the Air Working Group indicates that a package commander should never head home early. It should stay in the area as the commander of the package.

Provide the user the capability to delay or change the mission time for a mission that is in a Pre-Launch or scheduled state.

Currently the IMT displays the amount of fuel a mission currently has and the percentage of its full load this fuel represents. Tanker missions display two different values. Instead of display the amount of fuel the mission currently has for its own use, the tanker mission displays the amount of fuel that the tanker has to give to other missions. The percentage represents the percentage of the fuel that is non-committed. The desire is for a tanker mission to display its own fuel along with all other missions and to add two new data fields for the tanker mission that indicate the amount of fuel that is still available for off load and the percentage of that fuel that is non-committed.

It is not unusual to have the need to represent over 50,000 targets within a large JTLS database. It takes a fairly long time for this data to be read in and maintained in memory. The vast majority of these targets are fixed, stationary facilities. Alter JTLS to be able to handle 50,000 targets within the speed requirements of a large exercise.

During TF05, in some instances, one squadron has fewer aircraft then the others. The ATOT continues to task the squadron with fewer aircraft resulting in multiple missions going into delay status. The ATOT should recognize that one squadron has more aircraft is task it proportionately more. A second problem arose when the Wing or squadron was divided between bases. The ATOT tasked one base or the other. The ATOT should task on both the unit name and location (ICAO) of takeoff.

Input all phase-of-flight orders to be input with a selection of multiple Units of Measure such as LAT/LONG, UTM, GEOREF, etc. The Air Working Group indicated that they need to enter locations using the Military Grid Reference System (MGRS).

Specifically the desire is to be able to retrieve the current “orders” or flight plan for a mission and allow any user to alter these orders from any interface station.

Dynamic ability to activate or deactivate radar from any equipped air or ground platform that affects the air domain. The Air Working Group indicated that they want the default for air missions to be “Turned On”, but the user should be allowed to “Turn Off” and air mission’s radars.

Ability to ‘Drop’ an aircraft, resulting in aircraft taking on ‘Stealth’ capability, i.e., dropping an aircraft from radar visibility. The Air Working Group insisted that an order be created to override the air detection model and not allow the detection under any circumstances.

Ability to click on any display entity and another entity, base, or point in space producing a readout in the GIAC SITREP of magnetic bearing and range.

Visual display of aircraft call sign by first and last letter of call sign followed by last two numbers of mission number. The Air Working Group indicated that the desire is to name missions as such: DUSTER 05 would be named DR05. If there is also a mission called DEXTER 05, it would be named DE05 (taking the penultimate letter in the name).

Many of the existing ground orders have an option for the player to input either a single point or a route of points. This is very convenient. The withdraw order does not have this option and it would be nice to have this simplifying order capability.

Currently when Manual Pair Required is selected for two opposing aircraft that have ROE of FIRE, and the aircraft move into the same hex, they automatically fire at each other. We recommend the Manual Pair Required override the ROE, as there may be circumstances when we would not want the engagement to take place (i.e. Defectors). We believe that when Manual Pair Required is selected, firing should only take place when manually paired.

Can't manual pair interceptor against a cruise missile track. Model won't auto pair either. MPP says ''Your side does not currently have a track called DA00002.'' In FIND.TRACK, model checks for track name in the COMPLETE.MISSION.SET which appears to only contain Air Mission objects, not cruise missile objects

For some time, the JSTARS airborne radar imaging collection system has been modeled in JTLS – which lacks the ability also to produce the correct Moving Target Indicator (MTI) message reports associated therewith. Hence, we have relied on uniformed Air Force JSTARS SMEs for smooth MTI scripting, using portable message masks and basing their product inputs on “air-gapped” JTLS raw data, as the means of support to Joint exercises in this regard. Usually an unsatisfactory arrangement, due to non-availability of such SMEs (often the case); to lack of decent replication of the expected real-world report volumes concerned; and/or to complexities often experienced in the manual correlation of JTLS entities to actual MTI coverage objectives – e.g., SAM TELs. Consider measures enabling use of this feature with DSAs created by tech control’s automatic DSA generator

Surrender- As a unit surrenders, it changes sides. The surrendering unit could become a faction called “EPW” of the gaining side (DB defined faction). It would still remain as an icon in the game, would still cause congestion and delays for the capturing side and would require supplies for the capturing side. It would also be vulnerable to attrition from area effect weapons.

Loss of unit cohesion - As a unit loses morale, it would pass a database assigned threshold after which it conducts a periodic random draw to determine if it loses cohesion. A unit that loses cohesion and is not decisively engaged withdraws. This withdrawal is assumed to be disorderly, and a unit in this state would inflict no attrition on hostile units. A unit that has lost cohesion and is decisively engaged, surrenders. There should also be an increased chance of loss of cohesion in a case where a unit is surrounded.

Version 3.0 will add a rudimentary aircraft battle damage representation. This MCR describes a more detailed representation. Each Targetable Weapon will have a killing value TW KILL VALUE based on the size and type of warhead. Each Aircraft Class will have a survivability score AC SURVIVE SCORE based on how much damage it can sustain and keep flying. Each aircraft in an air mission will have a damage score AM AC DAMAGE SCORE based on how much damage it has actually sustained. There will be a new data structure called Aircraft Damage Levels. Each Damage Level will be defined by a minimum damage % for an aircraft to be considered at that Damage Level. Each Damage Level will have the following attributes: % speed reduction, % remaining fuel loss, % abort, % sensor effectiveness, % weapon effectiveness, and average maintenance time in days.

Currently if more than one air-to-air weapon is within range, the highest Pike weapon is selected. The desire is to sometimes use a lower Pike short range weapon to save longer range weapons for later use.

Although the formats are different, both IPIR and RECCEXREP reporting serve similar purposes to provide initial photo interpretation to satisfy essential elements of information (EEIs). Unfortunately, both JTLS and JQUAD either provide too much information overwhelming the training audience and/or not enough information to satisfy specific EEIs, e.g. provide a count of destroyed and/or damaged tanks. To better meet the needs of the training audience, we need to be able to tailor collection to satisfy specific reporting requirements. I believe that IPIR/RECCEXREP reporting requirements fall into three general categories: (1) Indications and Warning (I&W); (2) Disposition of Forces; and (3) Battle Damage Assessment (BDA).

JTLS must provide all Operators at all workstations the ability to override all JTLS automatic flight profiles and restrictions, regardless of faction, side, or control level. These capabilities apply to all phases of flight from initialization of a mission through the ATOT to completions of the mission (landing).

JTLS does not provide adequate interpretation, visual display, and ability to change/modify airspace coming from the Airspace Control Order. Current interface lacks the ability to produce initial ACO products and/or changes. Operators/Controllers have to do extensive workarounds to create a visual reference which is neither accurate in location, size, shape, or dimensions.

You get an error every time you select Specific Logistics, then Supplies. It states there are too many retrieval objects and will only display the first 2500. Recommend adding additional filters such as category, e.g. only CL I and CL V, or a type of base, e.g. only airbases.

Recommend deleting this screen option and moving some of the attribute filters to other screens for more efficient data gathering. This would also allow operators to minimize the number of IMT windows open at the same time.

Request the capability to gather sortie info by ATO, base and squadron to include scheduled, flown, RTB and destroyed.

Request the existing LOGSITREP be modified to include aircraft type, aircraft TOE, aircraft avail, aircraft in maintenance, repair time, number (associated with the repair time)

Request the capability to gather fuels info by base to include consumption and receipts since a specified date time group.

We need the ability to determine how many days of supply a support unit has for the units it's supporting. Currently, the logistics report will give the days of supply for a support unit (which has supplies to support it's supported units) not taking the supported units into account. This greatly exaggerates the days of supply of the support unit. There should also be an automatic computation that tells the support units how much of a particular class of supply it needs to bring to theater based on the number of units it's supporting

We need the ability to create a report, by unit (with option of a unit rollup), by subclass of supply, quantity on hand, quantity received, quantity expended, and quantity in maintenance. This would be for a selected time frame for selected day, for example, using a pull down selection window.

Allow the ability to select which items are reported in the Logistics Report. For example, not all classes of supply are required.

Need a NEO report which is a cumulative report on the number of personnel lifted by air, sea (ship/ferry), and ground in a certain time frame from a specific location to specific locations. Need the capability to break these figures down by unit, faction, or side. The time frame, and departure and arrival locations should be variables

We need the ability to load actual forces from the CFDB (Conventional Forces Data Base).

Greater fidelity and reality needs to be built into the consumption of supplies. For example, currently Class III ground is based on 8 gallons per person per day. Consumption should be based on ground equipment assigned rather than number of personnel assigned.

As of version 2.4 the existing combat system % non-visible data is now used to limit the number of combat systems that point weapons may attack. The % non-visible data only represents the effect of terrain. The victim unit’s posture should also be considered. A unit defending can be assumed to have dug in and camouflaged its systems. The ability to acquire all of a defending units combat systems for purposes of fire engagement should be limited. On the other hand, a unit in a moving posture should have most of its combat systems eligible to be fired upon.

Point weapons with multiple sub-munitions currently prioritize and select one object to damage. Then all sub-munitions are applied against that type of object until there are no more of that type of object. Only then is a new object selected. Recommend that each sub-munitions be allowed to select its own object to attack. More than one sub-munitions may still select the same type of object to attack. This would allow a better representation of damage results against ground and naval units.

Point weapon lethality is not currently affected by the posture or terrain of the victim unit. Appropriate modifiers should be applied to point weapons.

A multiple destination convoy to a location (rather than a unit) does not use ELFs. The convoy status says the convoy is using MHE to unload even though there are no MHE in the hex. If a friendly side unit is in the destination hex, use that unit’s ELFs to unload the convoy. If there are no friendly units in the destination hex, then the convoy should unload using implicit ELFs: the drivers and perhaps some bodies brought along for just this purpose.

Short range ADA systems are not firing often enough against attacking air missions. Short range ADA is normally not included in the IADs network. This means each short range ADA site must make its own detection attempt and then pass a Per check to be able to fire. This is OK for a mission just passing through the hex. Missions that are attacking the hex that a short range ADA is in should be treated differently. Per should be checked and modified normally for the range of the ADA system compared to the size of the hex.

There is nothing in the model to prevent a mission from flying at extremely low altitudes. JTLS does not allow planes to fly into the ground (unless they run out of fuel!) In reality, reasonable minimum altitudes are a function of the aircraft class and the pilots’ training. Add a new aircraft characteristic called minimum altitude and an array indexed by altitude zone and fixed wing flag.

A player has no visibility of the ELF status in a unit. Add ELF status to the LOGREP in a way similar to TRUCK asset status: TOE/BUSY/IDLE.

When a unit is given an Attack order, it cannot conduct its operations under SOF alert. Both operations should be able to be conducted simultaneously.

Currently if a Support type unit is told to transport another unit by truck, and the unit being transported has any self-propelled combat systems in maintenance, then the Support unit must have HETs to move the systems in maintenance. Unless the fraction fail on issue is set to zero for all self-propelled combat systems, they will always have something in maintenance. Even a small fraction of a combat system in maintenance requires a HET. Even the three special truck combat systems, which normally are used by the unit for its self transport when it is moving by truck, need a HET for trucks in maintenance.

Pilot ability and training are key factors in air combat. Recommend adding data parameters UT AIR TO AIR EFFECTIVENESS and UT AIR TO GROUND EFFECTIVENESS to represent pilot ability and training-two primary aircraft roles. These parameters would only be used only by Squadron units and applied as modifiers to lethality computations.

Currently, under air routes, you can designate that an aircraft stop at a particular base and refuel. There are times when the customer is tracking fuel consumption and having the model select where the aircraft refuels distorts the numbers. Request an option telling the aircraft not to refuel at a particular base similar to the option telling the aircraft to refuel.

The current air-to-air engagements have built-in safety mechanisms to prevent an aircraft from being shot down by a superior fighter or being lured into a SAM threat. There are times when the I/C must force an engagement even though the results might be unfavorable. For example, enemy fighters are using their SAM coverage to launch attacks against friendly forces but model logic will not allow the friendly fighters to go into the SAM envelope to engage. When ROE restricts attacking the SAM, then model logic should allow fighters to engage. Recommendation. Manual pair order should override considerations of enemy fighters or SAM threat. How to address the SAM threat is an operational not model decision to be made.

Currently, Jammers are assumed to be radar jammers. Add the ability to define different types of guidance mechanisms and associated jammers. Each weapon would have a guidance type, possibly two (long range and terminal). Jammers would specify which type of guidance they are capable of jamming.

Currently, all aircraft shelters prevent detection of the sheltered aircraft by Recce assets. This should not be the case for revetments and dispersal areas. Add a flag to the aircraft shelter type data that indicates if the shelter hides the sheltered aircraft from detection attempts.

During an Ambush, the HRU always jumps to the exact location of the ARU and then fights. The logic tries to determine the direction from which the HRU is attacking. Since during an Ambush, this is always directly on top of the unit, a default direction of 1 is returned.

Require a way to drop all orders when the OEC starts.

What to do about MPC restoring the situation within the MPC tables when a restart is accomplished. Would like a more automated save/restore capability available. Something that gives the operator the ability to truncate the tables, and potentially load messages from previous checkpoints. Or not flush the system, and just continue.

Should a CAP mission that determines the enemy poses excessive risk break off intercept if its orbit point is within range of the enemy, or the enemy is intercepting? The ECP requests that this check be done so the intercept does not automatically break off.

Aircraft that run out of fuel should be able to land (or a probability of landing) in a hex with a good road terrain type.

If a mission has a time stamped refuel chit and it does not meet up with its tanker on time it should turn around and go home. This should apply to all missions (orbiting and strike).

There is a desire to allow the Controller to change the name of a unit. This is in particular reference to the subject of squadron detachments. Another option would be to specify a new detachment name on the Transfer Aircraft order

JTLS symbology must be upgraded to comply with Military Standard 2525B and match other simulation models, as well as current C2 systems. JTLS is non-standard in virtually all air symbols, which are not meaningful to a training audience using the Common Operational Picture.

When the pairing template is used to create a pairing between two JTLS entities, no visual symbolic indication shows that the entity is actually paired. A pairing indicator on the entity symbol should visually confirm execution and continuity of the pairing.

Currently there is no global method of telling aircraft to stay above a specified altitude during their bombing run. This problem allows aircraft to be shot down by AAA and shoulder fired SAMs. This is unrealistic since, in the real world, aircraft stay above a predetermined altitude allowing them to remain above any low altitude threat. The only way to accomplish this in JTLS is to set the minimum release altitude for a specific weapon. Because of the number of different munitions, this is cumbersome and inflexible. The IC should be able to change the release altitude as the ATO SPINS or tactical situation dictates. A field should be added to the Rules of Engagement order allowing an IC to specify the minimum release altitude for a single aircraft type or a group of aircraft types.

There is currently no way to assign a specific route of flight to an Air Transport mission via the ATO Spreadsheet. To more accurately reflect real world commercial air traffic schedules and routes, this capability is needed. SUGGESTION: Modify the ACO spreadsheet to allow definition of a transit route between two airports, and allow assignment of this route to an Air Transport mission listed in the ATO spreadsheet.

Counter-Mobility- Hexes containing obstacles should be defined in several categories. These categories should include as a minimum, restricted and severely restricted. The amount of obstacle effort in a given hex should be related to a specific quantity of class IV and the type of terrain. Avenues of Approach would be assumed to be more limited in a forested hex than an open hex. Based on this concept, a single FASCAM mission for an artillery Battalion covering in reality a 400M box obstacle would simply add a low obstacle density to a hex which most combat units would be able to bypass with a minimal delay. Support units moving through the hex would suffer delays if the obstacle were not breached because they would have a low mobility index and would be less able to bypass.

Deliberate Defense- A hex containing a Deliberate Defense should by definition contain situational and positional obstacles. Placing a unit in a deliberate defense would require engineering support, a certain amount of Class IV supplies (based on terrain type), and a specified amount of time such as 48 hours (DB parameter). A unit in a deliberate defense would inflict greater Lanchestrian attrition against an attacker and suffer less attrition during a combat assessment period. Hasty Defense is currently played by the model (No required change).

The difficulty of weapon accuracy from high altitudes is not properly represented in JTLS. A new algorithm should affect weapon lethality based on altitude and type of weapon. This may require a new TW characteristic that reflects guidance type, so that GPS munitions can be differentiated from dumb bombs. This could also be impacted by the type of sensors on the dropping aircraft. Sensors could improve bombing accuracy up to some altitude.

When an air mission takes off it goes immediately to its cruise altitude. It is not subject to enemy air defenses that may cover the hex at altitudes that it had to pass through to get to its cruise altitude. The same thing occurs when an air mission lands. It goes immediately from whatever altitude it was flying at to zero altitude and being on the ground. It is not subject to enemy air defense that may cover the landing hex in lower altitude bands. Air missions that are taking off or landing should be subject to any air defense that covers the hex in any altitude band through which the air mission would had to pass.

Create a Tutorial Program to train players at a remote location how to operate the simulation as required in a player response cell.

Integrate a JTLS WHIP with voice input/output and video.

Provide tools that allow players to share information and coordinate activities.

Increase the logistics information readily available to the player on the Interface.

Add a feature to the command tree that allows the player to select a unit on the map and find it in the command tree.

Add a filter to the CMD Tree to allow players to display aircraft bases and the aircraft assigned to them.

Add a filter to the CMD Tree to allow players to display which ships are in formations.

Add a feature to the CMD tree that allows players to highlight a unit and its subordinates on the map display.

Add a graphic flag to the interface telling a player that a unit has received a message in the MPP.

Convert MPP messages to XML format.

Provide the player with a streamlined more intuitive method of issuing recently used simulation orders.

Reference User Lines for Order Entry.

Enhance the capabilities of the Map display to display unit and target capabilities.

Enhance the capabilities of the Map display to understand the current operations that are being conducted.

Add a filter that allows the player to display units and targets based on attribute.

Provide the player with a set of tools and filters that assist in understanding the terrain.

Allow the player to view clearly the names of units when large numbers of units are grouped in close proximity.

The WHIP currently allows another program to request information, find objects, or draw graphics using a TCP/IP socket connection called the SDI. As an example, the JTLS ATOG requires polygonal attack regions which can be drawn and displayed directly on the WHIP using the SDI. The SDI capability has proved so useful that the IMT was also modified to exchange information with the GIAC. However, the GIAC currently only handles a single client program through the SDI interface. It would be useful and more robust if multiple SDI clients could connect to the WHIP at the same time.

Currently there is no way for an operator to cancel a backorder. This is desirable, especially for backorders that are the result of directed resupplies or other operator action.

A support unit may have supplies available and ready to be delivered, but have no assets to deliver the supplies. This situation is not easily discerned by the player. If it was, the player could allocate delivery assets from other units to help move the supplies. When supplies are available to be delivered, but delivery assets are not available a message should be produced for the player to inform him of the problem.

A unit in combat will not accept an order to clear a minefield. A unit should be able to accept and carry out such an order. Must be in same hex or directed to more. Must be in same hex, or directed to move.

The Automatic Supply Calculation, a DDS utility, produces too high a supply of ammunition. This may be the result of allocating artillery ammunition for both Lanchester use and the default rounds per tube per day. The player should have the option to run the Automatic Supply Calculation without computing Lanchester consumption for indirect fire systems.

When a Communications Jammer was within effective range of two same-side units, a MPP message was received on the jammed side MPP confirming that jamming occurred. however there are no GIAC indications to confirm jamming.

Currently, JTLS models certain aspects of Combat Engineering, such as breaching, bridging and the use of FASCAM. There is currently no way in the model to represent the effects on a military operation of sustained engineering effort over a significant period of time. Request that additional functionality be included in the following areas: 1. Create a distinction between breaching a minefield and clearing a minefield. Currently the model allows beaching only. 2. Create a distinction between bridging efforts using an AVLB and those using pontoon bridges. 3. Create a new database parameter called unit mobility index, as part of the TUP definition, describe a unit’s ability to negotiate an obstacle-restricted hex.

Past high intensity conflicts such as the Persian Gulf War have demonstrated that units surrendering in mass have a major impact on the capturing Army's logistics requirements. Request that the following additions be made: Unit Effectiveness and Unit Morale parameters that are a function of fatigue, commitment, supply level, and attrition.

Currently in JTLS, Air Defense Air Search RADARS can be turned on and off by a player in the response cell which determines the probability of detection against a given air track/ target. The emissions of the fire control radar are not specifically modeled in JTLS This enhancement would require JTLS to create an automated ON/OFF toggle for FC radars, activated when an air track/target previously detected by the air search radar comes within max effective weapons range until the aircraft is either destroyed or moved out of range, then toggle OFF.

Upon completion of the first combat assess event after the arrival in the destination hex of the attacking unit, it should change its facing in the direction of the specified enemy unit if attacking an enemy unit by name. If it is attacking to a location it should change its facing in the direction of either the closest enemy unit, the largest enemy unit, or the most dangerous enemy unit. Some measure of effectiveness similar to the CAS mission selection of which adjacent enemy unit to hit should be used.

Currently, the database builders can specify Operation Areas and assign the areas ROE values within the JTLS database. This includes a pursuit ROE value against a foreign side. However, air missions are not always identified with a force side, and may have an Unknown side. There is currently no way within the database to specify an Operations Area pursuit ROE against an unknown side aircraft. This capability needs to be added.

A patrol mission with a four hour patrol time launched 10 hours late. It flew an Ingress and Egress route, but never patrolled. Should it have launched if its arrival at the patrol area was later than its time on station. A Cancel Delayed Mission order should be scheduled if a mission cannot patrol.

The Logistics Report and Logistics Rollup Report do not account for supplies that are en-route via convoys. This can be a significant quantity of supplies.

A stationary radar is always placed on the ground in a radiating state at game start. This is true even if the owning unit has a TPFDD time greater than zero.

During a recent exercise, a MIG-21 shot down a U-2 when there was considerable altitude difference between the two aircraft. The representation of altitude differences on firing ability is not represented in JTLS and should be. Alternatively, altering the Probability of Kill based on altitude difference is another method to better represent the situation of when two aircraft can engage in air combat when there is a large altitude difference.

JTLS needs to implement a robust and complete personnel report. This report should include number of personnel in theater, number killed, number wounded, number in the hospital etc. This ECP combined with JTLS-0482 (Personnel Accounting)

If an air mission is in weapons delay, there is no way to know if the mission was told to load a specific weapon load or a BEST load was being assigned. This makes it hard for the user to determine what the problem is with the mission and start corrective action. Some type of information should be made available on the IMT.

A submarine's probability of detection should be increased immediately after a detected missile firing. Sides detecting the firing of the missile can assign assets, but the fact that the assets are no longer doing a random search, but are in fact conducting a very detailed search in a small area should be better represented.

Currently, the maximum size of fuel that can be accurately reported on a logistics reports is 99,999,999.9 gallons of fuel. Anything over this is rounded to two significant digits. For example 123,456,789.2 gallons is reported as 120,000,000.0 gallons of fuel. If the report did not report “tenths” of gallon, the maximum size of fuel that can be accurately reported can be increased to 999,999,999.0 gallons of fuel.

Once an HRU goes into Coalition Support, then rules should be defined so a side can determine that the HRU is in Coalition Support of another unit. In particular if you are sharing information concerning your own units to another side, you are currently providing information on the whereabouts of your HRUs, but not the unit to which the HRU is attached.

Develop a system to create several versions of the same message without requiring a completely new full message file. This is needed because there are several different versions USMTF message formats used by various C4I systems. For example, this is true for the TACELINT and TACREP messages.

Show the status of each element in multi-element targets. For example, the IMT should show the status of each fire control sensor and each launcher in a multi-element air defense site.

Currently, the “Own Side Unit Data Report” generated by Periodic/Summary Reports or you can request it (under Intel Reports) only list the units currently in the game – not the ones wiped out. Request this report be expanded to include units at 0 percent strength. Allows accurately summarizing the strength levels of the combat forces in the game by stripping out all CS and CSS units that are not important in defining the combat power of a division or corps sized force. Include wiped-out units in the own side data report.

When several ASMs are fired at an enemy naval unit, the first ASM may sink the enemy ship. The remaining ASMs that are in the air try to find other targets to hit and may select a friendly ship that is near by. The friendly ship cannot protect itself because the model does not allow the ship to fire on friendly incoming ASMs.

During a recent exercise, a convoy with 1134 trucks was dispatched to a single unit. This one unit received its supplies, but no other units could get their supplies for the majority of the exercise. Through data, allow the database developer to limit the size of a convoy.

Need to represent embargoes and/or search and seizure missions. The model needs to represent the ability to search naval units, land-based aggregate units, High Resolution Units, and convoys.

Need to setup some alias names in the jtls_addresses file and include some of the alias in .mailrc for delivery to users. This would give them a small demo of how to setup sending e-mails to specific workstations - all of whom are logged on to jtlsuser.

Currently, there is no way to move or remove an object icon from the GIAC. For example, assume you see an HRU at a location and the HRU is magic moved to a new location. Foreign sides will continue to show the HRU at the old location until it is re-detected at a new location. If the HRU was magic moved to a location outside of the Intel collection bounds of the foreign side, the icon will always show up at the object’s old location. This is not just true for HRUs, but is true for any type of detectable object.

Packages in JTLS have at least one air-ground attack mission in the package. Air planners want to have the ability to fly packages without an air ground attack mission. For example, the package-leading mission could be a RECCE mission.

Reservation of aircraft is only possible in case a specific mission is given for the aircraft. Air planners reserve aircraft also without tasking a mission. The role/mission of the aircraft can be defined later. Because the aircraft are reserved, other operators cannot allocate them. Request the ability to reserve aircraft from a squadron for a specific period by a specific user. Only that user would be allowed to task the aircraft during the alert period.

The JTLS ASSIGN TARGET order does not return a reply. Operators do not know whether the order has been accepted or rejected.

If an OAS mission is sent to a CAS or target, it is impossible to abort the task to attack the target and send the aircraft back to the mission’s alert base or station. The operator should be able to break off the attack of a CAS or target in a manner similar to the break off of an intercept by a Combat Air Patrol.

In its present state, JTLS does not replicate theater collection assets adequately. JTLS needs to accurately portray the following collection platforms and sensors: U-2, Predator UAV, Global Hawk UAV, RC-135, EP-3, and E-8 Joint Stars. Currently, JTLS Instructor Controllers must generate Area Reports for the U-2 and UAV and then forward the reports to a scripting cell for reformatting and editing. The RC-135 and E-8 workaround is rudimentary.

Currently, the model does not allow a Squadron type unit to be airlifted by player order. Squadrons automatically conduct self lifting operations under certain circumstances, such as when under direct fire. However, a Player cannot order a self-lift, or order one squadron to lift another. Users have pointed out the need for a player to be able to order a complete squadron move. The TRANSFER AIRCRAFT order functions should be modified to allow squadron relocation. If all aircraft of a squadron are transferred to a new location, then the squadron unit should also be moved instead of creating a new squadron detachment with a new name.

Currently, the Airlift/Airdrop Report query does not include the current status of Insert/Extract missions. These missions airlift HRUs vice ARUs. A Player should be able to query for their status in the same way that it is possible to query for the status of the air movement of ARUs.

The IMT shows a status of DESTROYED for a convoy that has returned to its home unit. The line item for it on the IMT goes away when the Reload option is selected, or when the IMT screen is closed and reopened. It should only indicate DESTROYED for the ones that really WERE destroyed, for example by air attack. It should indicate COMPLETED for those that have returned to their home units.

When an air mission terminates at an airbase other than its home base, a detachment is generally created. When such a detachment is created, it usually accepts the new base as its UT.HOME.BASE. A problem exists, when the launching squadron and the new airbase are in different Factions, and those Factions access different Sustainment Logistics Prototypes (SLPs). In this case, the aircraft are allowed to land, and the detachment is still created. However, the model does not allow the squadron to accept the airbase as its home base. Because of the different SLPs, resupply anomalies could exist. The result is that since the detachment has no home base, it cannot use any runways and will reject all air mission orders. The aircraft are stuck on the ground at the airbase. This situation should be prevented.

The Controller damage report should provide additional information, such as the position of the firer and the position of the aircraft being fired upon. This should include both perceived position and real position. The additional information would help determine when there’s no damage if the firer was firing at the proper location.

A ship in JTLS is an Aircraft Carrier if its Ship Unit Prototype (SUP) defines its class as having one or more Catapults. Catapults are used to launch fixed wing aircraft, can be damaged ,and are repaired. The current number of operational catapults compared to the database defined full capability number contributes one third to the unit strength computation of such a ship. A Controller can change the strength of a ship, and thereby cause an automatic change in the number of working catapults to a new number determined by the model as a consequence. But there is no SET order that allows the Controller to specifically change the number of working catapults on a given ship.

IMT shows Destination 1 Location for Insert/Extract and Air Transport Missions, but Destination 2Location is blank. Both these missions frequently have multiple stops. As a minimum the second destination should be listed. Ideally the current next two locations on the Insert Extract List or Transport Instructions would be shown on the IMT Air Mission display .In addition, all air missions should list their final destination, including home base location, when it is within the next two.

The Show Target Parameters order currently generates a message that includes IADS link information. The operational status of the link (OPER or NONOP)should be added to the message. Also, the message should include the UT SHORT NAME of the owning unit as well as the UT LONGNAME.

A new database parameter would specify whether a SAM-AAA target of the specified type could be fired when owned by an HRU that is in a COVERT status. This AIR DEFENSE CLASS characteristic would be a YES or NO “flag” value. It For example, one might choose to set the attribute to YES. for shoulder fired SAMs, but set it to NO for SA10s, SA6s, and so on. The goal would be to allow a side to choose not to fire, and therefore, to hide and keep alive, large systems while covert.

A unit should show the SAM weapon availability that is on the target. The IMT says the unit has zero on hand, but it has some on hand, it is currently owned by the SAM target. This is confusing and misleading.

Home on Jamming capability of all applicable weapons does not exist in JTLS.

Radar detection effectiveness should be a function of distance.

Barriers may be impassable to Armor units but not to SOF. There needs to be a distinction.

Improve the Unit Damage and Combat System Periodic Report. It is hard to understand.

Allow WHIP to filter on time of contact.

Be able to filter on the WHIP between radar contacts, sonar contacts, visual contacts, active contacts, and TACINT contacts.

Sunrise and sunset should not be constant over the entire game board.

Have the ability to have “Unknown” side naval and land objects. JTLS has the concept of “Unknown” side air missions, but we do not have it for other represented entities.

Request that the WHIP Strep show the current engineering task for a unit. The SITREP you obtain from the MPP has it but I want to have the WHIP Strep show whether the unit is repairing a target, destroying a target, mining or clearing mines.

'Targetable weapons in JTLS have a single data item for weapon range. This is usually set to maximum or maximum effective range. Realistically for air to ground weapons, release altitude is the primary factor in determining actual weapon range. Maximum ranges are achieved at the highest release altitudes. Low altitude releases can severely restrict range capability.

Redefine time per round and prepare fire time for targetable weapons that are launched from SSMs. Existing definitions work correctly only for single round launchers. Since we can’t designate how many rounds are ready to fire, the reload time is applied after each firing. Expand the SSM structure to define the number of ready rounds per launcher. Redefine the meaning and use of time per round and prepare fire time as appropriate.

Unlike Area effects weapons, Point effects weapons do not use density, nor are there any other modifiers for terrain or posture. This means we can't represent the difference in the ability to acquire individual systems for engagement when the targeted unit is defending in the forest vs. when it is moving in the open. Recommended Solution: There is currently a percent non-visible data item for combat systems. This could be used to limit the potential victims for point weapons. If only 10 of 20 tanks were determined to be visible, then only 10 tanks could be killed. Remaining weapons would engage the next combat system on the priority list. A modifier to the percent non-visible for different postures could be added. Alternatively, separate Pike modifiers for terrain and posture could be added. These would modify the Pike directly.

A helicopter squadron can be ordered to conduct a ground move to a new location. This is not true for a fixed-wing squadron assigned to an airbase. A helicopter squadron that is moving will accept orders to launch missions; however, when it begins air operations, the unit stops moving. After the completion of the air operations, the squadron does not resume its assigned move. Either the mission should continue its assigned move or it should be allowed to conduct air operations while moving.

Capability is needed to alter the assigned Emergency Refuel Location after a mission order is entered.

Players can now request periodic reports. Controllers should have the same ability.

Add a column to the log report for on hand supplies. Currently, it only lists Days of Supplies. You have to go to the IMT to get the required information.

Have the CCO program print out a Controller log concerning all changes that were made to the database from the Controller terminals.

Create a DDS report from OPM that prints out the contents of the Load Assignment array but only for aircraft that exist in the scenario.

The WHIP filter capability should be able to filter on targets that are currently on or off.

Remove the assumption in JTLS that a passive detection capability is always available to all sides or units. Furthermore if a passive detection capability does exist it should be a damageable item on board a ship.

Some ADA systems can be used for air defense, but they can also be used to fire at other naval ships or small boats. This needs to be represented in JTLS.

Be able to filter intelligence information held for different units on the time of the contact. In this way you could ask the WHIP to display all known enemy unit locations that are more than a day old.

Need a naval speed change quick order. Click on a naval unit, and specify a new speed. The ship does not change its designated movement path, but does change speed to the new indicated speed.

Guided missiles can not be successful used against ships which are close to shore. Their guidance system is affected by the terrain background. This should be represented in JTLS.

JTLS Intelligence Collection by “Air Breathers” results in Imagery (IMINT) reports only. This is based on using a “Non-Real Time” Surface Search Sensor (with the collector platform), and the appropriate Directed Search Area (DSA). As part of the Intelligence. Collection capability, certain U.S. and foreign national “Air Breathers” can collect Electronic Intelligence (ELINT). Although JTLS cannot replicate the “Near Real Time” capability of some U.S. platforms, it should be able to replicate the “delayed” reporting capability of the other platforms.

Currently when an HRU starts a reconnaissance patrol, it asks if there is anything in its coverage area. Based on the size of the coverage area, there is a probability that the HRU will detect the object. If the HRU is told to report every hour, he will detect the object quicker than an HRU told to report every 24 hours. It would be better to use a time to detection and schedule an event.

The DDS will allow you to delete ALL runway targets even if they are in use by an airbase. I would prefer if we had to remove the airbase entry first.

Desire is to have a TW attribute which indicates that impact is known or unknown. If unknown, continue firing even after object killed.

Model the detection of submarine false contacts: sonar can pick up false contacts and forces can expend weapons etc. against these false contacts.

Need ability to change a unit’s type in the DDS. For example, change a Ground Unit to a Support Unit.

SSM targets are of no use unless they are owned by a unit, because they have no missiles or supplies of their own. When a unit moves away from a stationary SSM, the SSM target is removed from the game (made inactive). When the game starts, stationary SSMs do not have owners, since no units arrive before stationary targets are emplaced. Therefore, the stationary SSM are rendered inactive. This is situation needs to be corrected.

Improve the logic used to select an appropriate alternative landing location for delivery airlifted supplies. It doesn’t ask where the receiving unit is located. It assumes in the hex where you just tried. This may not be true. It also does not consider friendly or neutral landing locations which are close by.

Large sensor ranges cause too much of a game slowdown. A better way to handle these ranges must be developed.

Improve the Installation Manual to properly explain what should and should not be done if you do not have a SIMSCRIPT compiler.

Electronic Warfare aircraft only affect enemy ADA capability. This should be expanded to disrupt communications as well as weapons.\ a. ESM sensors (passive) should be modeled like active sensors and they should be open to damage. b. Players and units should be able to sense the effect of the jammer. A message to MPP saying that under jam and which sensors are effected and the change in their range. c. In Radar-Jammer interaction frequency should be taken into account.

The DDS does not allow short versions of Latitude/Longitude (i.e., 40N, 130W). Cumbersome to enter 40-00-00N 130-00-00W.

Directed Search Area list function under orbiting reconnaissance requires pull-down menu to show DSAs available. Also OPAREAs and National Boundaries should have pull-down lists.

For Naval Move order, change default speed to 'KNOTS' vice 'KM per day'.

Electronic Warfare aircraft affect enemy ADA capability only. Effects should be expanded to disrupt COMMs as well as weapons. ESM sensors (passive) should be modeled like active sensors and be open to damage. Players and units should be able to sense the effect of the jammer. A message to MPP saying indicates sensors affected and the change in their range. Radar-Jammer interaction frequency should be considered.

Allow Naval Units to travel up navigable rivers and fjords.

Change air refuel attribute type from Boolean to three masked values No would be 000, Boom, Centerline Drogue, and Wingtip Drogue. Then you need to add the data to the tankers to indicate which type it can refuel. Thus a 100 aircraft - indicating it can be refueled by Boom can be refueled by a 111 tanker (meaning any type legal) but not a 011 tanker indicating that both drogues are allowed but not boom.

All range specifications that are currently restricted to a radius should be specified as polygons also: Applies to CAP missions. Applies to ROE setting (especially for surface to air).

Please add subtotals for fixed wing and rotary wing aircraft. Rotary wing aircraft can be identified by a zero runway requirement. During an exercise, the DISTAFF requests reports showing total fixed wing sorties flown. Presently the numbers must be manually added to produce this report.

The Controller Fuse Ghost Order needs an option that does not require the name of a ghost to fuse. It should fuse the unit or target with the newest ghost and delete all other ghosts for that object.

Add setup time for SAM-AAA targets (after moving) similar to new SSM setup time.

Represent human effects factors on unit effectiveness value. Represent differences in squadron training levels, flying hours, computerized bombing, etc. Consider pilot proficiency factor (Air-to-Air/Grid).

Use squadron effectiveness as a pike modifier for air-to-ground and air-to-air attacks. Represent differences in squadron training levels, flying hours, computerized bombing, etc. Consider pilot proficiency factor (Air-to-Air/Grid).

Currently the suppressive effects of ADA are not modeled. Represent ADA suppression of air missions as modifier to aircraft weapon Pk. Levels of suppressive fire intensity. Levels of suppression effect to include complete abort. Every mission has a chance of ignoring suppression. Use Squadron effectiveness level.

Current modeling of missiles doesn’t allow for an adequate representation of long range targeting problems. Long range missiles such as AS-4 and SS-N-19 should require some type of mid-course guidance update if fired beyond a certain range or should suffer a PK degradation.

Moderate differences between air launched and SSM launched missiles. Air launched missiles should fly out, now that missiles can be intercepted in flight.

The Reformat Spreadsheet needs the following improvements: Have the spreadsheet program recognize empty fields with a hyphen or the word NONE.

Players need greater flexibility in amphibious operations. JTLS must allow players to: assign specific units to specific ships; Task organize these units while embarked on ships for amphibious assaults; and have the option of selecting multiple landing sites.

Mission Reports for airlift missions should be generated when the mission delivers its supplies, not when the mission returns to its home base.

Runway list should provide list of existing runways owned by base. It does not. Had to find runway in OPM and enter into directive “Runway List” field.

Add an EGRESS (GRTE) field to ground directives. This would delete the need to create another order after an action. For example a unit could be told where to move after a target is attacked or destroyed.

There is confusion on how to calculate whether there are enough parking spaces for air units to conduct operations. Make it consistent between the SVP, on alert, select divert location, find home base.

Sides that are friendly to each other should be able to use each other's runways -- if not for any other purpose than refuel and airlift of units and supplies. The design should provide additional capability to allow aircraft to land at friendly side runways whether or not a same-side airbase is there.

When a helicopter unit is under attack, the helicopters stay on the ground and ride out the attack. This is unrealistic. The helicopters should take off and move out of the area.