8124 record(s) found.
Improvement List
| Info | Area | Subarea | Description | |||
|---|---|---|---|---|---|---|
| Model | When Missile Heading Toward Object Update Faster During a recent exercise, a Torpedo was fired against a ship. The torpedo was updating its location event 30 seconds, but the ship against which it was fired only updated its position every 10 minutes. The ship was traveling faster than the torpedo and could have easily out run it, but this was not properly represented because for 10 minutes the ships were 'stationary' and was not moving away from the torpedo. Suggestion is that when a missile heads towards a moving object, the moving object should update its location as often as the missile, so an accurate representation of the closure rate is modeled. | ||||
| Model | Provide Run Statistics When Model Changes Speed Whenever the model changes game speed it would be useful if it provided information on the previous game speed. Such information should include the start time, the end time, the requested game speed, and the actual game speed. This would help to determine the performance of the CEP when checking the shadow game, or if checking against implementation options. Whether this information should always be displayed or should be tied to an existing debug flag is immaterial to the goal. | ||||
| WHIP | WHIP Terrain Masking Radar Coverage Radar Coverage on the map needs to be adjusted according to the terrain types/elevation details. JTLS-GO does have a terrain masking algorithm which is only as good as the detail associated with the terrain grids. The JTLS-GO Development Team intends on allowing the user to select the option of showing which grids will result in detections based on the range of the sensor, the elevation of the sensor, the elevation of possible detected object, and whether the sensor is an over-the- horizon sensor. In all likelihood, this computation will be accomplished by the GSS Service that already exists within JTLS-GO. The WHIP will request the information from the GSS and then highlight the grid in which detection is allowable providing the requested detailed terrain based range capability. | ||||
| Model | Simplify OrderCapability Investigate the possibility to link the actual FORCE FLOW graphics with quick order generation capability. The features could be useful for users who needs to handle 'background noise forces' or for wargaming capabilities in case of force flow move. Move Concept. Intention maybe tied to force flow graphics. | ||||
| WHIP | Geo-Reference Messages The desire is to add a single location parameter to every generated report as part of the report’s Meta Data. Once a report has location Meta data, a display mechanism should be created to show where reports are referenced and display this information on a map. A user can then click on the map location and read the message that has something to do with that geo-reference. For example, consider the following use case: Every time a weapon impacts, a Controller Damage Report is generated. This report describes damage at a specific location and a mark would be placed on the map. Anyone wanting to look at Controller Damage Reports for a specific area could easily only click on the report icons in the desired area. | ||||
| Database | Add Location To All Unit Table The Database Development System (DDS) has separate unit takes for Ground Units, Airbases, Squadrons, Forward Arm and Refuel Points (FARPs), Support Units, and Naval Units. The DDS maintains a table called the All Unit Table that holds the data common to all units, such as the prototype and Higher HQ. The desire is to add location to the All Unit Table since each of the JTLS-GO Basic Unit types have a location. Development Team Addition. If this is done for the All Unit table for consistency it should also be done for the All Target table. | ||||
| C4I | Add Comments To Read Order Files For wargaming capabilities, provide the ability to add comments to orders. These files can be large and difficult to manage. Comments will help the development of the wargaming order sets. | ||||
| Tools | Add Percentage Of Unit Lost In BDA Report Within the AAR include the percentage of the unit lost during a reported engagement. | ||||
| Model | Allow Satellites To Be Part Of IADS Network Satellite can be a part of an IADS detection network. Allow this representation in the database. | ||||
| Model | Air | Allow Controller Change Maint Time For Multiple Aircraft Currently the Controller Change Maintenance Time Order only allows the control to change the maintenance time of one aircraft at a time. A more efficient method is desired. | |||
| Model | New AAR Mining Ops Report Implement a new AAR report that covers Mining Operations. Add the following new data to the AAR SDR database to be included in the new report: Name of the mining asset (ship name or air mission name) Mining operation type (Lay or Sweep) Applicable phase (Exploration, Reconnaissance, Clearance) if naval Time the operation (or phase) began/ended Minefield type Targetable weapon Number of mines detected, laid, or cleared. | ||||
| Model | Navy | Naval Task Speed Adjustment The Naval Cell would like to change the speed of a Naval Task prior to the ask starting. This request would require that the assigned task speed would need to be displayed on the Task IMT screen. The ECP has been registered and no further action is planned until approval and funding for the ECP has been identified. | |||
| Model | Allow Mission Type Change While On Alert The Mission Type cannot be changed using the Manage Air Mission Tasks order while on alert, but it should. | ||||
| Tools | ATOT Squadron Assignment Assistance In the ATOT, the Aircraft Assignment popup allows squadrons to be filtered in 3 ways: All, Close Matches, or Exact matches. The way it does this filtering is hidden from the user. It would be nice to display the current string we’re filtering against (the asset name) . | ||||
| Model | Delete Multiple DSAs Using Utility Order Currently a player can delete multiple DSAs by selecting them on an IMT screen and submitting a spreadsheet order. This ECP requests the capability to delete multiple DSAs using a Utility panel on the Manage DSA order. This allows the multiple deletes from a single order, rather than the two-step process of selecting the DSAs on an IMT and then submitting the multiple orders. | ||||
| Model | Allow Cruise Missiles To Change Altitude Currently Cruise Missiles fly at one specific altitude from firing to impact. Some Cruise Missiles are more advanced than that and can change altitude along the way to avoid air defenses or to fulfill other mission specific requirements. The model should be able to represent this. | ||||
| Model | Navy | Improve Naval Shadow Movement Logic Naval Units conducting a shadow task can too easily run into land resulting in the inability to maintain their shadowing location. Also submarines travel at their cruise speed to get to a shadow location, making too much noise. This needs to be looked into. | |||
| Model | Intel | Represent Aircraft And Combat System Decoys You can represent decoy systems but not the ability or inability for the enemy to detect whether it is a decoy or not. | |||
| Tools | Expand ATOT RECCE Checks Currently the Air Tasking Order Translator (ATO-T) checks that an Electronic Combat (EC) Mission has the proper type of jammers in its database load. The EC mission may be told to jam sensors or jam communications. These are different types of jammers. If the ATO indicates that the mission is the type that jams communications, the ATOT creates a warning if the database does not include a communications jammer within the Standard Conventional Load (SCL). The same concept exists for RECCE missions, but the ATOT does not do any checking. For example, if an ATO indicated that a mission should be a CINT mission, which stands for Communications Intelligence Collection mission, the mission load should include a JTLS-GO COMMINT Sensor. Similarly, an ATO ELECT mission type indicates the mission should collect Electronic Intelligence (ELINT) and the ATOT should check that the load in fact includes an JTLS-GO ELINT Sensor. | ||||
| C4I | Improve COP Filtering Of Weapons and Missiles Players complained that JDAMS while flying were displayed on the COP. Currently the JOI has no weapon type distinction. If a weapon is told to 'fly' grid-by-grid and the database indicates it can be detected, then the weapon will show up on the COP. A complete review of how to filter all missiles for the COP needs to be accomplished and a flexible system implemented. | ||||
| C4I | Include Detected HRUs In IIR Message HRUs are being detected and there is no code to report their existence in the IIR message. This portion of the model needs to be improved. | ||||
| Model | Intel | Improve Large Area DSA Collection The Intel Cell wanted to make the DSA larger and have the model hold on to the all collected intelligence until the complete DSA was covered by multiple air mission moves and then send out the IIR. Developer Note: During the exercise, there were complaints that the Intel Cell had nothing to do. I believe that the Panamax Exercise Audience is used to watching MUSE/AFSERS and determining what should be displayed on the COP. They could have done the same thing with JTLS-GO but no one had this in the exercise architecture. | |||
| Model | Allow Controller To Change Faction Of A Unit Currently Factions are allowed to change sides and the Controller is allowed to create new factions and place units in the new faction. If the order to create a new faction is not accomplished properly, the extraordinary measures must be taken to get a unit into a faction. Basically another new faction is needed and then the Controller needs to merge factions, leaving an old faction around. This is cumbersome. A simply ability to tell a unit to change from one faction on its side to another faction on its side is needed. The documentation should specifically tell the Controller the implications of a unit changing factions. | ||||
| C4I | Searchable ATOT Module Drop-Down Lists When working with the ATOT Linking file from the ATOT Module, there are numerous instances for which the user is presented with a drop-down list of items from which to select. This list is alphabetized, but not searchable. For example, when defining an SCL, the user is presented with a long list of available Targetable Weapons. A better and more user friendly interface is needed. | ||||
| Tools | Improve ATOT Weapon Selection Interface During ATOT training, the general consensus was that the ATOT module interface for SCL processing was not user friendly. Currently when the ATOT encounters an SCL that is unrecognized, a warning is generated. The user can go to the SCL definition panel and correct the problem. If the user does not correct the problem, the ATOT generates an order indicating that the model should select the best load to accomplish the mission. If this is the desire, there is no way to indicate to the ATOT that the warning is not a problem. It is impossible to stop the ATOT from generating the warning. This in turn makes it difficult for the ATOT user to keep track of which warnings are important and which warnings should be ignored. The solution to this issue is fairly straight forward. The ATOT user should be allowed to enter an SCL definition panel solution of 'BEST'. This means that the user would have three options available for correcting the SCL definition. -->Existing - in which the ATO SCL is linked to a JTLS-GO database SCL. This option currently exists in the ATOT. -->New - indicating that the ATOT should provide a new SCL as part of the order. This option currently exists in the ATOT. -->Best - indicating that the model should select the best SCL when it is time for the mission to fly. This is a new option, and if selected the ATOT warning concerning an unidentified SCL should not be generated. | ||||
| Model | Include Fuel Sanity Check Within The ATOT The ATOT does numerous ATO sanity checks, including an estimate whether the assets available at a squadron can support the plan ATO flights. PACAF requested that the ATOT be expanded to provide a fuel sanity check. In other words an estimate concerning whether the specified mission flight profile can be accomplished with the fuel indicated within the ATO using the fuel consumption data within the model. Such a check will point out possible mismatches between the fuel consumption data within the model and the fuel consumption data held within TBMCS. | ||||
| Model | Represent Weapon Variants One of the major issues encountered during KE22 was the assignment of weapons to missions as part of ATO’s Standard Conventional Load (SCL). SCLs, as indicated within TBMCS and the ATO message, does not provide information concerning the exact weapon variants desired. For example, the ATO specified SCL for a mission may indicate that the mission should load SCL 24G38, meaning that the mission should load 24 GBU38 JDAM weapons. The issue is that the SCL does not indicate which variant should be used. For example, should the mission be loaded with 24 'GBU38 JDAM MK82' weapons or 24 'GBU38 Version 5 JDAM' weapons. Each of these weapons exist in the database, but each weapon may not be available to the squadron that should fly the mission. As PACAF mentioned, within real operations, the squadron's load master would make this decision/ This implies that the model should make the decision. There are several solutions to this problem: -->Prior to the exercise, conduct a review of the weapons represented in the database and remove any weapon variants that should not be considered. Any remaining weapon variants should specifically be specified by the AOC as part of the SCL definition. This solution has several problems. Mainly the review will take time and the AOC may not want to get down to that level of detail. -->Build into the JTLS-GO database the concept of interchangeable weapon variants. If the ATOT produced an order indicating that the mission should load 24 'GBU38 JDAM MK82' weapons and those weapons are unavailable, the model should be allowed to automatically alter the order and load 24 'GBU38 Version 5 JDAM' weapons instead. Naturally this option is also not fool proof. It is possible that this automatic substitution, simulating the load master’s decision process, may not always be desired. Implementing such a capability will take some serious design considerations but a workable solution to this problem is required prior to executing another major kinetic exercise such as KE22. | ||||
| Model | Represent Air Mission Mode 'S' PACAF indicated that Air Missions should be able to represent Mode 'S' transponders. Although the transponders on aircraft are considered part of the database, model changes will be required to properly have Air Mission provide the necessary identification information provided by Mode 'S' transponders. | ||||
| Tools | Create ATO Change Difference Tool PACAF indicated that processing ATO Changes during Keen Edge was not straight forward. Within an ATO Change messages, there are several types of changes that can occur. These include: -->Changes that have already been implemented because the AOC contacted the Response Cell directly and then following up by publishing the ATO Change after the fact. Obviously the ATO-T should not create orders to re-implement the change. -->Changes that have no impact on JTLS-GO. For example, the change may indicate that air missions should communicate with the Airborne Warning And Control System (AWACS) on a different radio frequency. This is not represented within JTLS-GO; therefore, these changes should also be ignored. -->Mission changes that should be implemented. -->New missions which should be translated and created. -->Missions that should be deleted. R&A asked how the Air Warfare Simulation (AWSIM) model handled this situation. PACAF indicated that AWSIM has a built in comparison tool; thus, allowing the user to easily categorize the changes contained in a message. This is a perfectly reasonable idea, and understandably will make the job of processing ATO Change easier. | ||||
| Model | Improve Automatic Intercept Rules The PACAF discussions led into an explanation of the 'Automatic Intercept Rules' used by JTLS-GO. It was PACAF’s opinion that these rules could be more robust if the rules also included information concerning the current Rules of Engagement under which the mission were operating. | ||||
| Tools | Interpret ATOT Fuel Type Information One of the improvements in JTLS-GO 6.1 was to represent several types of aviation fuel, such as JP-8 and JP-5. When translating the ATO, only some of the Air Refueling missions indicated which type of fuel should be carried. In addition, it was unclear to the JTLS-GO Development Team whether a single Air Refueling mission could carry multiple fuel types. PACAF indicated that multiple fuel types can be carried in separate fuel bladders, but they were unclear how that fact is specified in the ATO message. Despite this detail, improving the ATO-T to properly specify which type of fuel or eventually fuels should be loaded on the Air Refueling mission. Dual Fuel tankers should be considered but it is not mandatory. | ||||
| WHIP | IMT | Joint Desired Point of Impact (JDPI) New Attribute Pacific Air Force (PACAF) representatives indicated that the targeting process includes labeling JDPIs as either: -->Assignment allowed, -->Assignment requires special approve, or -->Assignment unallowed. They would like this information readily and easily available on the Web Hosted Interface Progrm (WHIP) user interface. Their design preferences included being able to color-code Information Management Terminal records based on this new attribute or even color-coding the order drop-down menus from which JDPIs are selected. Implementing this ECP will help ensure a user does not accidentally target an undesired JDPI. | |||
| Tools | Allow Controller To View ATO MTF Messages Please add the capability for the controller to be able to view ATO MTF messages. When processing a multi-sided ATO it is easier to use the controller to monitor the Browser messages and IMT data for all missions for all ATO sides at a single time. When possible problems are encountered the user can not review the ATO MTF messages from the controller making it necessary to open the respective player WHIP. | ||||
| C4I | TACELINT Common Message Format JTLS-GO needs to generate TACELINT messages using the newer Common Message Format. | ||||
| C4I | Better Representation Of IMT Quick Buttons From the IMT Unit Supply Category IMT screen, if the user selects the Quick Button for the same Supply Category, the user gets the supplies records for units and air missions. The user thinks this should be an option of some type. Needs a global design to meet a variety of requirements. | ||||
| Tools | Allow ATO-T To Create Aircraft Load In The Game An ATO-T User believes it would be useful for the ATO-T to automatically create new Weapon Loads in the model. | ||||
| C4I | Implement Naval J13.3 Messages JTLS-GO should generate Naval Unit store information - J13.3 messages | ||||
| WHIP | Ability To Turn Range Rings All Mission Sensors It would be useful to have an easy way to turn on all Air Search Sensor Type A Range Rings for all air missions. | ||||
| Model | Air | Allow Foreign Squadrons To Be Based On Ships During Cobra Gold, we were told it is an operational need to place US aircraft on a coalition partner carrier. This is common practice and cannot be represented in JTLS-GO | |||
| Model | Accurate Airlift Movement of UAVs. During a recent exercise, the model crashed when a user input a Mobility Mission Order to airlift a Ground Unit that had UAVs. The crash occurred because the Aircraft do not have a database parameter indicating whether it can be airlifted and if so how much it weighs. The model was changed to simply always lift all UAVs. For a more realistic representation, Aircraft need a lift weight in the database. | ||||
| WHIP | IMT | Change Mission Parameter WHIP Order Spreadsheet The desire is to develop a WHIP Order Spreadsheet capability to submit the Change Air Mission Parameter orders. | |||
| WHIP | Airbase Closed Indicator An airbase closed or not fully operational because of RNWY should be identify with a symbol in the Orbat tree. | ||||
| WHIP | IMT | IMT Color Code Line Users to assign a color to IMT lines (colors shared across users) – operator can agree on a meaning (i.e high importance units etc. ) | |||
| C4I | Postponed Task Restart Location Improvement Operators noticed that missions after breaking off to refuel and finishing with it, they got back where they were on their the initial task and not at the last location when they actually break off. | ||||
| Model | Ground | Unit Location After TPFDD Leave Theater Lately several user scenarios have units operating within Africa. The method of determining where a unit that is removed from the theater using the TPFDD Leave Option needs to change. It causes confusion to move the unit location to 0, 0. | |||
| WHIP | Title IMT Screens Given the addition of polygon filters for IMTs, it is becoming more difficult to distinguish what filters are being used by a specific IMT screen. The user should be able to assign a 'Title' to a specific IMT screen to help with the distinction. | ||||
| WHIP | Dropping Items From An IMT Screen A design decision was made early in the development of the IMT that displayed items should not move nor be removed without interaction from the user. Even though this means that a displayed object that no longer passes the filters will remain on the IMT screen overall the decision has served the operator well. However, a need for a Foreign Air Track IMT Screen has developed, and when a track is lost the name displayed on the IMT screen goes blank, but the current location of the track can still be found by performing a Find On Map action on the blank name. This is one case where an item that no longer passes filters should be removed from the IMT screen. A capability should be developed to permit the removal on a screen by screen basis. | ||||
| Model | No Visibility On EMCON Events An Emission Control plan, turning sensors on and off, can be developed by the operator and submitted to the model. However, there is no way for the operator to see what current EMCON events exist, nor to cancel any events. These capabilities are a necessity for proper EMCON management. | ||||
| Tools | Availability of ELINT Records In AAR The AAR contains a table for ELINT detections that is not currently filled. Emitter objects are reported via the JODA and fused ELINT detections appear in the AAR detection table. The developer does not know what information would be valuable to the clients to include in the ELINT detection table or whether it is obsolete at this time. | ||||
| Tools | Sharing Multiple Slides A request was made by the ACC to have the ACO generated slides shared with the Civilians side. The WHIP permits the capability to change who a slide is shared with on a slide by slide basis. Since this was a fairly normal ACO it had 260 slides generated from it. Either the WHIP needs a method to alter slide sharing en masse or the TechTool needs the capability to perform the operation. |