1 / 66

TTWCS v6 Candidates April 29, 2004

TTWCS v6 Candidates April 29, 2004. Roger Newton. TC2S Impacts by v6 Candidates. Analysis for the More Descriptive and Reliable Reporting (TAR04) Candidate. More Descriptive and Reliable Reporting (TAR04) Overview. Summary Description

lan
Download Presentation

TTWCS v6 Candidates April 29, 2004

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TTWCS v6 CandidatesApril 29, 2004 Roger Newton

  2. TC2S Impacts by v6 Candidates

  3. Analysis for theMore Descriptive and Reliable Reporting (TAR04) Candidate

  4. More Descriptive and Reliable Reporting (TAR04) Overview • Summary Description • Provides clearer exceptions from validation and pre-selection processing for the Strike Package Exception Report • Provides more accurate launch status associated with Post Launch Report • Removes requirements to process and send Post Strike Report • Fleet Benefit • Provides a more accurate picture to the tasker on what is happening on the shooter • Improves reliability and consistency of the Strike Package Exception Report and Post Launch Report • Improves overall system reliability and performance • Fleet Importance: High • CR Summary • Adaptive: 2 • Perfective: 9 • Corrective: 5 • TOTAL: 16

  5. More Descriptive and Reliable Reporting (TAR04) Analysis • Technical Description • Provide more descriptive exception text which the system generates for a strike package exception report • Remove child strike package for CFF and make it part of the parent strike package • Simplifies association of strike package exception and post launch reports • Respond to changes in contents of a strike package when determining when to send a post launch report • As strike package are revised during OPS, update the post launch whenever the strike package is changed and allow a post launch report to be sent after the revision and condition are met • Remove the post strike report for post strike analysis • Remove reference and formatting of the report • Remove the automatic transmission of reports from the HCI • Effort: Medium • Size: Medium • Complexity: Medium • External Dependencies: 3900/146 – Updated status fields • Risk: Medium

  6. More Descriptive and ReliableReporting (TAR04) Recommendation • Addresses: 16 CRs Eliminates 2 TIP entries • Recommendation Implement in v6 Defer for future consideration • Rationale • Provides a clearer picture to the tasker on what is happening on the shooter • Issues • None

  7. Analysis for theStrike Package Coordination(TAR11) Candidate

  8. Strike Package Coordination(TAR11)Overview • Summary Description • Strike Package Coordination • Provide the capability to have all tasked timing be based off of a Strike Time (ST) in the Strike Package (SP). The ST would be received electronically in a SP or the operator could modify it as an edit to an existing SP. • Fleet Benefit • Provides a means to move the entire launch time of all tasks within a SP without having to send a complete revision to the SP or have the operator manually computing and editing each tasked time in the SP. • Fleet Importance: High • CR Summary • Adaptive: 1 • Perfective: 1 • Corrective: 0 • TOTAL: 2

  9. Strike Package Coordination(TAR11) Analysis • Technical Description • Provide the capability to have all tasked timing be based off of the Strike Reference Time (ST) in the Strike Package (SP). This would be received electronically in a SP or performed as an edit to an existing SP. • Tasked times in the SP would be delta times based off of the ST in the SP. • The ST could only change if the SP was at a Use State of Launch Plan or Hold Fire. • When a Revision to the SP is received with the ST changed, TTWCS shall compute the actual tasked times for each engagement, update all the tasked times for each engagement, and replan the engagement based on the updated time. LPMP missions would have to be recreated or verified as still valid. • A manual edit to the ST in an existing SP, shall achieve the same results. • Effort: Medium • Size: Low • Complexity: Medium • External Dependencies: Requires an IFIR and ICN to 3900/146 • Risk: Medium

  10. Strike Package Coordination(TAR11) Recommendation • Addresses: 2 CRs Eliminates: 0 TTBs/TIP entries • Recommendation Implement in v6Defer for future consideration • Rationale • Candidate has been suggested by the Captain and by PMA 281 as a viable way to move the entire launch time of a SP without putting a load on the operator or having to perform a complete Revision to the Strike Package. • Issues • If the IFIR/ICN to 3900/146 is not approved, TTWCS can still perform an edit to a SP to accomplish the intent of the candidate. Need to determine impact on Strike Execution time, SP Tasking Start and End time specified in the SP.

  11. Analysis for theFiring Status Report to TC2S(TAR14) Candidate

  12. FSR to TC2S(TAR14) - Overview • Summary Description • Semi-automated Firing Status Report (FSR) message that is sent at different times for FSR and at ½ hour prior to first missile away in a Strike Package to the TSC/LAC for the Launch Time Strike Plan (LTSP). • Fleet Benefit • Provides a means to automate a manually created opnote or voice reports to the TSC/LAC that is currently being used in the Fleet. • Fleet Importance: High • CR Summary • Adaptive: 1 • Perfective: 0 • Corrective: 0 • TOTAL: 1

  13. FSR to TC2S(TAR14) - Analysis • Technical Description • Provide a new Firing Status Report (FSR) formatted message that is auto-populated. For the Launch Time Strike Plan (LTSP) report, the operator would be notified 30 minutes prior to first missile away in a Strike Package to send the FSR. The 30 minutes time for the LTSP notification would be an operator editable time. The FSR would include as many as possible of the Firing Status Reports listed in Appendix M of the NTTP 3.03-1. The FSR would be sent by the operator when the reports are needed. The operator would be able to select one or several reports to send at a time • Effort: Medium • Size: Medium • Complexity: Low • External Dependencies: Requires an IFIR and ICN to 3900/146 • Risk: Low • Addresses: 1 CR Eliminates: 0 TTBs/TIP entries

  14. FSR to TC2S(TAR14) - Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • This was requested by the submarine community and directed by Captain Sullivan. • Issues • Need to coordinate with PMA 281 and the Fleet as to what they want and the concept and content of this message. When using Block IV missiles with their relatively short alignment time, is the Fleet going to spin them up more then ½ hour prior to launching?

  15. Analysis for theRedirection Improvements (IFM08) Candidate

  16. Redirection Improvements (IFM08) Overview • Summary Description • Prevents control of an in-flight missile by more than one TTWCS operator at the same time • Updates 3900/146 to allow Tactical Change SP to contain route altitude • Fleet Benefit • Enhances the capability to redirect missiles in flight • Prohibits multiple TTWCS operators from controlling the same missile • Fleet Importance: High • CR Summary • Adaptive: 2 • Perfective: 1 • Corrective: 0 • TOTAL: 3

  17. Redirection Improvements (IFM08) Analysis • Technical Description • Remove possibility of competing requests for redirection from operators • Allow only one position to be in control of a missile • Allow TC2S to task route altitude for retargets and aimpoint updates for missile in flight (Tactical Change SP) • Effort: Medium • Size: Medium • Complexity: Medium • External Dependencies: Requires 3900/146 Change (IFIR 3900146-022 approved by PMA 281, ICN A31 pending) • Risk: Medium • Addresses: 3 CRs Eliminates 1 TIP entries

  18. Redirection Improvements (IFM08) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • Control conflict could lead to a serious problem • IFIR for 3900/146 already approved, though ICN needed • Issues • Need 3900/146 ICN

  19. Analysis for theBacking up Ownship Tasking with Onboard Assets(TAR06) Candidate

  20. Backing up Ownship Taskingwith Onboard Assets (TAR06) - Overview • Summary Description • Provide the operator the ability to choose a tasking line that fails during or after launch and be able to quickly replan and execute the task. • The Replan would more then likely be using a Pooled missile for Block III or any Block IV since the launch timeline would be past missile select and thus would need a missile which could be launched quickly to meet tasked time. The concept of a Replan launch time would be similar to using a LLRS as is currently being used today. This means that the system would plan a primary engagement with time wasting waypoints which would include a delta time for the late launch of the Replan. This Replan delta time would be operator settable. • Fleet Benefit • Provides automation for ownship to backup its own tasking with limited assets. • Provides the operator an easy method to replan tasking that has failed before or after launch and still achieve the tasking. • Fleet Importance: Medium • CR Summary • TOTAL: 2

  21. Backing up Ownship Taskingwith Onboard Assets (TAR06) - Analysis • Technical Description • If a Primary task does not have a ready spare or a late launch ready spare associated with it and it fails before or after launch, the operator needs a way to quickly replan that mission if so tasked by the TSC. • This Replan function is very similar to using a LLRS missile. The LLRS has a delta time associated with it in the tasking such that if the primary fails there will still be time for the LLRS to achieve tasked timing. Thus, the Replan function shall have a global Replan delta time associated with it such that the Primary shall have a time-of-flight OTW that includes the Replan delta time (I.e. time wasting waypoint). • Tasking would designate which Primary tasks ownship would backup. • The system would plan the OTW route for these designated Primary tasks to include the Replan delta time • An operator control would be added to be able to select a SCOMPLed MSN. • An operator control would be added to be able to replan that MSN. • The system would handle the Replan task just as a Strike Package revision would be handled (I.e. it goes through Validation but the revision does not change since tasking has not changed). The time-of-flight would not includethe Replan delta time. • The system, through Preselection, would be able to choose a missile that would satisfy the tasking. This would included Pooled missiles, Reload missiles or any asset that would meet the mission and timing requirements. • Effort: Medium • Size: Medium -- Complexity: low • External Dependencies: An IFIR and ICN to 3900/146 are needed • Risk: Medium • Addresses: 2 CRs Eliminates: 0 TTBs/TIP entries

  22. Backing up Ownship Tasking withOnboard Assets (TAR06) - Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • This candidate is requested by the Captain to reduce workload and the timeline for operators when replanning a task that has failed before or after launch. • Issues • Need to prototype the operator interface to determine the optimal sequence for the operator. Also need to integrate the design with the Task Center design. Would this cause a revision to the Strike Package? How would TTWCS report failures after launch and when using a pooled missile? Need to include in tasking if ownship is to backup its own task (i.e. tasking must tell ownship to plan the primary with time-wasting waypoint). Need to determine how to report using Pooled assets. If TAR15 (LER) is implemented, we don’t want to be sending a LER when we are backing up our own tasking. Should the Post Launch Report state the use of a Pooled missile? How do we report the use of a different asset?

  23. Analysis for the Receive Avoidance Areas from TC2S(LMC09) Candidate

  24. Receive Avoidance Areas from TC2S (LMC09) Overview • Summary Description • The operator would be able to use Avoidance Areas in LPMP and Retarget missions in addition to current constraints (I.e. no-fly, etc). • Fleet Benefit • Requested by Fleet Commanders at the OAG as a better way to establish what potential threats should or should not be avoided based on the current available picture. • Fleet Importance: Medium • CR Summary • Adaptive: 2 • Perfective: 0 • Corrective: 0 • TOTAL: 2

  25. Receive Avoidance Areas from TC2S (LMC09) Analysis • Technical Description • TC2S would transmit Avoidance Areas to use in LPMP and Retarget mission creation in addition to current constraints (I.e. no-fly, etc). • Avoidance Areas ACMS messages would be processed into Overlays. • LPMP would route around the Avoidance areas if possible. If not, it would fly through the Avoidance areas. LPMP would avoid Threats in the Avoidance areas as it currently doing. The Threats in the Avoidance area would just have a higher cost. • Effort: Medium • Size: Medium • Complexity: Medium • External Dependencies: 3900/146 ICN A32 pending. (IFIR 023 has been approved by PMA 281) • Risk: Medium (Due to Medium Effort and Minor Issues) • Addresses: 2 CRs Eliminates: 0 TTBs/TIP entries

  26. Receive Avoidance Areas fromTC2S (LMC09) Recommendation • Recommendation Implement in v6Defer for future consideration • Rationale • Requested by Fleet Commanders at the OAG as a better way to establish what potential threats should or should not be avoided based on the current available picture • This candidate is associated with candidate LMC03, LPMP Options for Use of Routing Constraints. If LMC03 is implemented, operator would be able to select/deselect routing constraints as tasked • Issues • Requires 3900/146 IWG to determine just how and when to use Avoidance Areas and how to task them

  27. Analysis for theImprove Missile Comms (IFM03) Candidate

  28. Improve Missile Comms (IFM03) Overview • Summary Description • Provides improved visual indications of portions of route where TSN connectivity may be lost • Provides increased automation in creating communication scheduling • Provides operator the capability to confirm response to IMMM based on verbal reports • Improves probability of receipt of BDI by SC • Fleet Benefit • Improves usability of status and control for in-flight missiles • Fleet Importance: Medium • CR Summary • Adaptive: 3 • Perfective: 3 • Corrective: 2 • TOTAL: 8

  29. Improve Missile Comms (IFM03) Analysis • Technical Description • Display communications blackout periods and calculated periods of low link margin on the existing missile route display • Add capability to send BDI from ownship to the strike controller (approved IFIR 021) • Add capability to easily select scheduled H&S comm load on a LOW/MEDIUM/HIGH bias • Improve PLE processing in support of H&S generation • Add capability to allow the operator to provide visual confirmation that a redirection has taken place • Add field to display to show time until next (when not in blackout period) or time until exit (when in blackout period) • Effort: High • Size: High • Complexity: Medium • External Dependencies: 3900/146 IFIR 021 approved, ICN A30 pending • Risk: Medium • Addresses: 8 CRs Eliminates 1 TIP entries

  30. Improve Missile Comms (IFM03) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • This candidate builds on functionality already present • Issues • Need 3900/146 ICN A30, not yet drafted • Depends on assumption in IFIR 3900146-021 that the FRU is the missile controller

  31. Analysis for the LPMP TGT Capability(LMC10) Candidate

  32. LPMP TGT Capability(LMC10) Overview • Summary Description • Provide LPMP with the capability to plan Time on Target (TGT) missions • Fleet Benefit • Provides the TSC with the capability of tasking Time-on-Target LPMP missions • Fleet Importance: Low • CR Summary • Adaptive: 1 • Perfective: 0 • Corrective: 0 • TOTAL: 1

  33. LPMP TGT Capability(LMC10) Analysis • Technical Description • Provide the capability to receive a TGT timing type and time in the MSNO of a Strike Package from TC2S • The TGT can be tasked via ESP or voice tasking. • LPMP would use the specified TGT time when creating a mission. • LPMP would provide a “Best Effort” in accomplishing the timing. • If the TGT is not specified in the message, LPMP would use the current design of TOL. • Effort: High • Size: High • Complexity: Medium • External Dependencies: Requires an ICN to PEO(W) 3900/146 (IFIR has not been submitted) • Risk: High (Due to High Effort) • Addresses: 1 CR Eliminates: 0 TTBs/TIP entries

  34. LPMP TGT Capability(LMC10) Recommendation • Recommendation Implement in v6Defer for future consideration • Rationale • Candidate is a Low Fleet priority and the Effort and Risk associated with this candidate are High • Issues • None

  35. Analysis for theLaunch Area ACMS (OVL03) Candidate

  36. Launch Area ACMS (OVL03) Overview • Summary Description • Makes use of Launch Area ACMS messages to provide the operator with an additional decision aid to use in selecting a launch point • Messages provide geographic regions that indicate an area within which the missiles need to be launched • Fleet Benefit • Automates launch area usage and launch point selection • Facilitates the operator selection of an appropriate launch point using a menu drop-down • Fleet Importance: Low • CR Summary • Adaptive: 1 • Perfective: 2 • Corrective: 0 • TOTAL: 3

  37. Launch Area ACMS (OVL03) Analysis • Technical Description • Send Launch Area messages to the applications • Add processing/storage of the Launch Area messages • Add user interface components to allow the operator to easily select from a list of launch positions calculated based on received Launch Area messages • Drop-down list with a set of Launch Areas from which the operator chooses • Effort: Medium • Size: Medium • Complexity: Medium • External Dependencies: 3900/146 IFIR 010 approved, ICN A28 pending (Circular ACMS-FRU Launch Area) • Risk: Low • Addresses: 3 CRs Eliminates 0 TIP entries

  38. Launch Area ACMS (OVL03) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • Automating the process of using Launch Area ACMS messages is a low priority, nice-to-have feature • Issues • One possible design that has been discussed involves using the center point of the launch area • Investigate geo-feasibility issues with getting to the center point

  39. Analysis for theLaunch Exception Reports(TAR15) Candidate

  40. Launch Exception Reports (TAR15) Overview • Summary Description • Provide a quick response to TC2S when a launch failure occurs to allow other assets to be applied • Fleet Benefit • Eliminates the need for the operator to make a voice report on each missile failure • Fleet Importance: Low • CR Summary • Adaptive: 1 • Perfective: 0 • Corrective: 0 • TOTAL: 1

  41. Launch Exception Reports(TAR15) Analysis • Technical Description • Upon receipt of each launch in which there is a failure, the system shall generate and transmit a launch exception report message indicating the failure condition. • TC-AH receives the missile status message indicating the launch state, creates a launch exception report and depending on the state of transmission automation either requests the operator to transmit the message or sends the message. • HCI provides a display to allow the operator to add free text • HCI provides for manual creation of a LER for failure to transition to cruise • Effort: Low • Size: Medium • Complexity: Low • External Dependencies: 3900/146 to modify LER message • Risk: Low • Addresses: 1 CRs Eliminates 0 TIP entries

  42. Launch Exception Reports(TAR15) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • Reduces operator mistakes • Issues • Need agreement from 281 to change the contents of the LER

  43. TC2S Impacts by v5 Candidates not Implemented • TLD implementation was not completed in v5 • Current v4 implementation was to use the MSN • This implied only one MSN per aimpoint • Limited the TSC when requiring multiple assets on the same aimpoint • v5 was to implement a TLD scheme in place of the ASN • Scheme was never defined so the MSN has continued to be used The operator has to enter something in the TLD field if he wants it • PMA 281/ PMA 282 IWG was held to determine the scheme. Actions assigned • Currently no approved scheme to date • There is no v6 candidate to implement any new scheme.

  44. TSN Impacts by v6 Candidates

  45. Analysis for theImproved IMMM Identification (IFM04) Candidate

  46. Improved IMMM Identification (IFM04) Overview • Summary Description • Improves usability of received H&S messages for reporting and planning • Fleet Benefit • Improves usability of status and control for in-flight missiles • Fleet Importance: Medium • CR Summary • Adaptive: 0 • Perfective: 3 • Corrective: 1 • TOTAL: 4

  47. Improved IMMM Identification (IFM04) Analysis • Technical Description • Use the updated aimpoint information in the H&S message to confirm receipt of a redirection (uses change in OES 033 of missile) • Generate an immediate H&S request before an Aimpoint Update to improve position information • Provide correlation of missile with missed IMMM • Effort: High • Size: Medium • Complexity: High • External Dependencies: Requires 3900/114 Change (Code implemented in AUR IOC build) • Risk: Medium • Addresses: 4 CRs Eliminates 0 TIP entries

  48. Improved IMMM Identification (IFM04) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • This candidate will provide significant improvement to the IMMM capability for a relatively low cost • Issues • Need 3900/114 documentation change to be completed (No ICN yet, original IFIR was rejected as unnecessary because of change to AUR OES) • Need to decide whether automatic position check should be implemented for retarget as well as Aimpoint Update

  49. IDS-8 Impacts by v6 Candidates

  50. Analysis for theMultiple Re-targets and Aimpoint Updates(LMC11) Candidate

More Related