C&C Candidates Mar 15, 2004

1. C&C CandidatesMar 15, 2004 POC: M. Redding G. Shea P. Tingler

2. Analysis for theBacking up Ownship Tasking with Onboard Assets(TAR06) Candidate POC: G. Shea

3. Backing up Ownship Tasking with 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: High • CR Summary • Adaptive: 1 • Perfective: 1 • Corrective: 0 • TOTAL: 2

4. Backing up Ownship Tasking with 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: AnIFIR and ICN to 3900/146 are needed. • Risk: Medium • Addresses: 2 CR Eliminates: 0 TTBs/TIP entries

5. Backing up Ownship Tasking with Onboard 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?

6. Backup SlidesBacking up Ownship Tasking with Onboard Assets (TAR06)

7. Backing up Ownship Tasking with Onboard Assets (TAR06) CR Summary

8. Backing up Ownship Tasking with Onboard Assets(TAR06)–Design Concept • CR 8036 – Add an option that would let you highlight an existing MSN from the Tasking Manager window and Replan that mission by creating a new engagement based on the data associated with that MSN. • 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 • Addressed in the White Paper • CR 11234 – Plan SCOMPL without launching a missile • This CR is OBE due to the implementation of CR 8036 by letting the plan SCOMPL and then Replanning it.

9. Analysis for theStrike Package Coordination(TAR11) Candidate POC: G. Shea

10. Strike Package Coordination(TAR11)Overview • Summary Description • Strike Package Coordination • Provide the capability to have all tasked timing be based off of the Strike Reference Time (SRT) in the Strike Package (SP). The SRT 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: Medium • CR Summary • Adaptive: 1 • Perfective: 1 • Corrective: 0 • TOTAL: 2

11. Strike Package Coordination(TAR11) Analysis • Technical Description • Provide the capability to have all tasked timing be based off of the Strike Reference Time (SRT) 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 SRT in the SP. • The SRT 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 SRT 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 SRT in an existing SP, shall achieve the same results. • Effort: Medium • Size: Low • Complexity: Medium • External Dependencies: Requires an IFIR and an ICN to 3900/146 • Risk: Medium • Addresses: 2 CR Eliminates: 0 TTBs/TIP entries

12. Strike Package Coordination(TAR11) Recommendation • Recommendation Implement in v6 Defer 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 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.

13. Backup SlidesStrike Package Coordination(TAR11)

14. Strike Package Coordination(TAR11) CR Summary

15. Strike Package Coordination(TAR11) – Design Concept • CR 11312 – The system should provide a global change launch time and timing type capability. • Tasked times in the SP would be Delta times based off of the SRT in the SP. • The SRT 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 SRT 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 SRT in an existing SP, shall achieve the same results. • Addressed in the White Paper • External CR 11253 – The concept behind SRT is to enable the TSC to move all assignments in the strike in time, without needing to modify each assignment and retransmit the strike package. • Covered in implementation of CR 11312.

16. Analysis for the Coordinate between FRUs for Backup Plans(TAR12) Candidate POC: G. Shea

17. Coordinate between FRUs for Backup Plans (TAR12) - Overview • Summary Description • Provide the capability to semi-automatically coordinate launch times between the primary and backup launch platforms for backup tasking. • This completes the implementation that was started in V5 with: • The operator enters the LAC intentions for delta time between Primary/Backup launches. • The operator then gets the Backup Launch Platforms OTW timing and manual plays with the OTW route to include the Backup timing. • Fleet Benefit • Provides automation for planning launch times of Primary/Backup missiles which was partially implemented in TTWCS V5. • Fleet Importance: Low • CR Summary • Adaptive: 1 • Perfective: 0 • Corrective: 0 • TOTAL: 1

18. Coordinate between FRUs for Backup Plans (TAR12) - Analysis • Technical Description • Provide the capability to automatically coordinate launch times between the primary and backup launch platforms for backup tasking. • When a Backup Launch Platform has Backup tasking, it will plan the engagement plan with the most direct route to the FPPWP. • When the system has planned the Backup Engagement, it shall notify the operator that the Primary Launch Platform needs to be notified of the time-of-flight. • The Backup Launch Platform’s operator will then send its OTW time-of-flight in a formatted message to the Primary Launch Platform (as designated in the Strike Package Tasking) for the MSN its backing up. • The Primary Launch Platform will receive the message and notify the operator that the Primary MSN now has the Backup Launch Platform’s time-of-flightfor the Backup MSN. • The Primary Launch Platform’s operator will then select the Primary MSN to initiate the planning (or replanning) of its engagement plan to have an over-water time-of-flight that exceeds the time-of-flight of the Backup MSN plus the time specified in the LAC intentions for the delta time between Primary and Backups. • Effort: Medium • Size: Medium -- Complexity: Low • External Dependencies: Document the message between FRUs. • Risk: Medium • Addresses: 1 CR Eliminates: 0 TTBs/TIP entries

19. Coordinate between FRUs for Backup Plans (TAR12) - Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • Fleet requested improvement. Partially developed in V5. Automation would occur in V6 • Issues • What interface do we use? How does the primary launch platform know that it has to have a backup time-of-flight or does the system need to know it unless it gets it (i.e. if a OTW time comes in for a MSN, then use it for the MSN designated otherwise don’t worry about it.)?

20. Backup SlidesCoordinate between FRUs for Backup Plans (TAR12)

21. Coordinate between FRUs for Backup Plans (TAR12) - CR Summary

22. Coordinate between FRUs for Backup Plans (TAR12) – Design Concept • CR 10016 – The fleet has requested that TTWCS have a capability to coordinate between primary and backup launch platforms to insure TSC guidance for accomplishing backup tasking. • When a Backup Launch Platform has Backup tasking, it will plan the engagement plan with the most direct route to the FPPWP. • When the system has planned the Backup Engagement, it shall notify the operator that the Primary Launch Platform needs to be notified of the time-of-flight. • The Backup Launch Platform’s operator will then send its OTW time-of-flight in a formatted message to the Primary Launch Platform (as designated in the Strike Package Tasking) for the MSN its backing up. • The Primary Launch Platform will receive the message and notify the operator that the Primary MSN now has the Backup Launch Platform’s time-of-flightfor the Backup MSN. • The Primary Launch Platform’s operator will then select the Primary MSN to initiate the planning (or replanning) of its engagement plan to have an over-water time-of-flight that exceeds the time-of-flight of the Backup MSN plus the time specified in the LAC intentions for the delta time between Primary and Backups. • Addressed in the White Paper

23. Analysis for theLaunch Time Strike Plan (LTSP) to TC2S(TAR14) Candidate POC: G. Shea

24. LTSP to TC2S(TAR14) - Overview • Summary Description • Semi-automated Launch Time Strike Plan (LTSP) message that is sent ½ hour prior to first missile away in a Strike Package to the TSC/LAC. • Fleet Benefit • Provides a means to automate a manually created opnote or voice report to the TSC/LAC that is currently being used in the Fleet. • Fleet Importance: Low • CR Summary • Adaptive: 1 • Perfective: 0 • Corrective: 0 • TOTAL: 1

25. LTSP to TC2S(TAR14) - Analysis • Technical Description • Semi-automated Launch Time Strike Plan (LTSP) that is sent ½ hour prior to first missile away in a Strike Package. • TTWCS shall notify the operator ½ hour prior to first missile away in a Strike Package to send a LTSP. • TTWCS shall automatically populate the LTSP with: a) MSN’s in the Strike Package that are to be launched; b) MSN’s Launch Time; c) MSN’s Cell/Tube #: d) MSN’s Subscriber ID (SID) for Block IV AURs; e) SP ID. & Rev number; f) Message header (same as Exception Report). • Effort: Medium • Size: medium • Complexity: Low • External Dependencies: Requires an IFIR and an ICN to 3900/146. • Risk: Low • Addresses: 1 CR Eliminates: 0 TTBs/TIP entries

26. LTSP to TC2S(TAR14) - Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • This was requested by the sub community and directed by the Captain. • 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 !V missiles with their relatively short alignment time, is the Fleet going to spin them up more then ½ hour prior to launching?

27. Backup SlidesLTSP to TC2S(TAR14)

28. LTSP to TC2S(TAR14) - CR Summary

29. LTSP to TC2S(TAR14) – Design Concept • CR 10567– Tasking node requires the following information 1/2 hour prior to first missile away and an electronic message is required: - MSN - Launch Time - Cell # per MSN - Subscriber ID (SID) for Block IV AURs. • TTWCS shall notify the operator ½ hour prior to first missile away in a Strike Package to send a LTSP. • TTWCS shall automatically populate the LTSP with: a) MSN’s in the Strike Package that are to be launched; b) MSN’s Launch Time; c) MSN’s Cell/Tube #: d) MSN’s Subscriber ID (SID) for Block IV AURs; e) SP ID. & Rev number; f) Message header (same as Exception Report). • Addressed in the White Paper

30. Analysis for theLaunch Exception Report(TAR15) Candidate POC: G. Shea

31. Launch Exception Report(TAR15) Overview • Summary Description • Semi-automated Launch Exception Report (LER) that is sent when a Launch Platform fails to accomplish a Primary task in a Strike Package. • Fleet Benefit • Provides a means to semi-automate a manual process of reporting to the TSC/LAC that a Launch Platform has failed to accomplish a task. • Fleet Importance: Low • CR Summary • Adaptive: 1 • Perfective: 0 • Corrective: 0 • TOTAL: 1

32. Launch Exception Report(TAR15) Analysis • Technical Description • Semi-automated Launch Exception Report (LER) that is sent when a Launch Platform fails to accomplish a Primary task in a Strike Package. • TTWCS will notify the operator to send a LER when an engagement plan has been SCOMPLed and it has failed to complete Primary Salvo requirements. • The system shall auto-populate the LER with the failed MSNs, the reason for the failure, and the MSN used in its place. • Effort: Medium • Size: medium • Complexity: Low • External Dependencies: Requires an IFIR and an ICN to 3900/146. • Risk: Medium • Addresses: 1 CR Eliminates: 0 TTBs/TIP entries

33. Launch Exception Report(TAR15) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • This was requested by TC2S. • Issues • Need to coordinate with PMA-281 as to what they want, and the concept and content of this message. • Needs to be coordinated with TAR06, Pool Missile Selection (allow replanning with Pool missile) as to how to report using a Pooled asset for the failed primary. Also when primary fails, we don’t want to send the LER if we are authorized to use onboard assets as backup.

34. Backup SlidesLaunch Exception Report(TAR15)

35. Launch Exception Report(TAR15) CR Summary

36. Launch Exception Report(TAR15) – Design Concept • CR 12043 – TransmitLaunch Exception Report (LER) to TC2S. • TTWCS will notify the operator to send a LER when an engagement plan has been SCOMPLed and it has failed to complete Primary Salvo requirements. • The system shall auto-populate the LER with the failed MSNs, the reason for the failure, and the MSN used in its place. • Addressed in the White Paper

37. Analysis for the LPMP Options for Use of Routing Constraints(LMC03) Candidate POC: G. Shea/P. Tingler

38. LPMP Options for Use of Routing Constraints (LMC03) Overview • Summary Description • Provide LPMP with operator controls to select/deselect routing constraints, i.e., no fly zones, threats, etc. • Provide the operator the ability to specify a minimum MAXSOR when creating an LPMP mission. • Fleet Benefit • Provide the operator with more planning options for LPMP in order to produce the desired mission. • Fleet Importance: Medium • CR Summary • Adaptive: 2 • Perfective: 1 • Corrective: 0 • TOTAL: 3

39. LPMP Options for Use of Routing Constraints (LMC03) Analysis • Technical Description • Provide LPMP with operator controls to select/deselect routing constraints • Provide a GLOBAL setting to enable the operator to set routing constraints for ALL LPMP missions before tasking is received per Tactical Doctrine. • Provide operator controls to enable/disable EVERY TYPE of routing constraint for an INDIVIDUAL LPMP mission. • Provide operator controls to enable/disable an INDIVIDUAL routing constraint for an INDIVIDUAL LPMP mission. • When LPMP fails to create a mission, provide operator controls to be able to enable/disable routing constraints before re-running LPMP. • Provide the operator the ability to specify a minimum MAXSOR when creating an LPMP mission. • Add the capability for the operator, before tasking is received, to enter a global minimum MAXSOR that LPMP must use when creating a mission. • Provide error conditions if LPMP cannot meet the minimum MAXSOR. • Current design would allow a mission to be created that has a small or no MAXSOR due to routing constraints. • Effort: High • Size: High • Complexity: Medium • External Dependencies: None • Risk: High (Due to High Effort) • Addresses: 3 CRs Eliminates: 0 TTBs/TIP entries

40. LPMP Options for Use of Routing Constraints (LMC03) Recommendation • Recommendation Implement in v6Defer for future consideration • Rationale • There is a need to ensure that a resulting LPMP mission has a reasonable launch basket that the Launch Platform can achieve. • There are times when LPMP cannot create a mission due to routing constraints. When these exceptions occur, the LPMP capability would be enhanced if the operator, with Tactical guidance, could choose which routing constraint(s) to disable for this particular LPMP mission. • This candidate is associated with candidate LMC09, Receive Avoidance Areas from TC2S. If LMC09 is implemented, this candidate would enable the operator to enable or disable current routing constraints and use the Avoidance Areas as tasked. • Issues • None.

41. Backup SlidesLPMP Options for Use of Routing Constraints (LMC03)

42. LPMP Options for Use of Routing Constraints (LMC03) CR Summary

43. LPMP Options for Use of Routing Constraints (LMC03) – Design Concept • CR 9046, & 9092 – Provide LPMP with operator controls to select/deselect routing constraints (I.e. no fly zones, threats, etc.) • Addressed in the White Paper. • Provide a GLOBAL setting to enable the operator to set routing constraints for ALL LPMP missions before tasking is received per Tactical Doctrine. • Provide operator controls to enable/disable EVERY TYPE of routing constraint for an INDIVIDUAL LPMP mission. • Provide operator controls to enable/disable an INDIVIDUAL routing constraint for an INDIVIDUAL LPMP mission. • When LPMP fails to create a mission, provide operator controls to be able to enable/disable routing constraints before re-running LPMP. • CR 11046 – Provide the operator the ability to specify a minimum MAXSOR when creating an LPMP mission • Addressed in the White Paper. • Add the capability for the operator, before tasking is received, to enter a global minimum MAXSOR that LPMP must use when creating a mission. • Provide error conditions if LPMP cannot meet the minimum MAXSOR. • Current design would allow a mission to be created that has a small or no MAXSOR due to routing constraints.

44. Analysis for the LPMP Threat Data Management(LMC06) Candidate POC: G. Shea/P. Tingler

45. LPMP Threat Data Management (LMC06) Overview • Summary Description • Update threat model to correct for specific threat topology and be able to display the correct topology of the threat. • Fleet Benefit • Provides a more realistic threat topology to ensure that LPMP can route effectively around/over threats. • Fleet Importance: Medium • CR Summary • Adaptive: 0 • Perfective: 1 • Corrective: 0 • TOTAL: 1

46. LPMP Threat Data Management (LMC06) Analysis • Technical Description • Enhance LPMP Threat Model • Update threat model to correct for specific threat topology. • Display the correct topology of the threat to the operator in 2-D Horizontal and 2-D Vertical displays concurrently. • Use this threat topology when creating LPMP missions. • Effort: High • Size: High • Complexity: High • External Dependencies: Requires a source to receive the specific threat topologies needed for this capability. • Risk: High (Due to High Effort and Major Issues) • Addresses: 1 CR Eliminates: 0 TTBs/TIP entries

47. LPMP Threat Data Management (LMC06) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • This is a Fleet directed candidate. • Without this candidate, LPMP will continue to fly over threats using the current cost map. With this candidate, could still fly over threat but raise the flight altitude of the route to avoid the threat lethality. • Without this candidate, the cost map would possibly be higher than needed for any particular threat. • Issues • Can we acquire the correct threat topologies needed for this enhancement? • May require changes to the current threat cone used for the LPMP auto-router cost function. • Would we be able to get the threat topologies in the future if we go to a web site information pull? • As new or updated threat topologies are released in the future, how do they get implemented on the launch platform?

48. Backup SlidesLPMP Threat Data Management (LMC06)

49. LPMP Threat Data Management (LMC06) CR Summary

50. LPMP Threat Data Management (LMC06) – Design Concept • CR 10363 – Enhance LPMP Threat Model • Update threat model to correct for specific threat topology. • Display the correct topology of the threat to the operator in 2-D Horizontal and 2-D Vertical displays concurrently. • Use this threat topology when creating LPMP missions. • Addressed in the White Paper.