Analysis for the Track Validity Checker (COP02) Candidate

1. Analysis for theTrack Validity Checker (COP02) Candidate POC: D. Calkins/R. Sullivan

2. Track Validity Checker (COP02) Overview • Summary Description • Checks track database for tracks with invalid data and provides notification if problems are found • Operator notified of problems via an additional status on the Mode State Console (COP Health) which will also affect the rollup status shown on the Job Bar • Fleet Benefit • Increased confidence that the track data is valid • Increased confidence in the data used for avoidance calculations • Immediate operator notification if track problems are detected • Fleet Importance: Low • CR Summary • Adaptive: 0 • Perfective: 1 • Corrective: 1 • TOTAL: 2

3. Track Validity Checker (COP02) Analysis • Technical Description • Check for issues with track data • Invalid data (lat/lng/time/etc.) • History points which do not belong with the rest (tracks jumping) • Provide a background process to check for a set of known issues in the track database • Scan the complete database initially, followed by a scan of changes as they occur • Notify operator if track problems are discovered • Effort: Medium • Size: Medium • Complexity: Medium • External Dependencies: None • Risk: Low • Addresses 2 CRs Eliminates 0 TIP entries

4. Track Validity Checker (COP02) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • Operator can check track data manually • Implementation may become obsolete in v7 with a new, different track database • Issues • None

5. Backup Slides Track Validity Checker (COP02)

6. Track Validity Checker (COP02)CR Summary

7. Track Validity Checker (COP02) Design Concept • Track Validity Checker design needs to do the following: • Register for notifications of changes to the track database • Provide method to loop through all tracks currently in the database and check the validity on all the tracks, and return status to the operator • When notifications of changes to the track database are received, provide software to check the validity of the associated track records and return status to the operator if invalid data is found • Check to include: • Track history points which do not fit with the rest of the points • Invalid values for track report fields (lat/lng/time/etc.) • Invalid time sequencing of reports • Tracks without reports

8. Analysis for theCST Enhancements (COP03) Candidate POC: D. Calkins/R. Sullivan

9. CST Enhancements (COP03) Overview • Summary Description • Broadens the types of data that can be exchanged between TTWCS and GCCS-M using the COP Sync Tool (for example, Almanac Data and OPNOTES) • Fleet Benefit • Facilitates new data exchanges between TTWCS and GCCS-M such as OPNOTES and GPS Almanac Data • Fleet Importance: Low • CR Summary • Adaptive: 1 • Perfective: 0 • Corrective: 0 • TOTAL: 1

10. CST Enhancements (COP03) Analysis • Technical Description • CST supports passing a fixed set of data types across the interface • Provide a generic encoder/decoder pair that makes use of plug-in libraries to allow extensibility of the CST interface in support of data types not foreseen by CST • Almanac Data • OPNOTES • Effort: Medium • Size: Medium • Complexity: Medium • External Dependencies: SPAWAR/NG • Risk: Medium • Addresses 1 CRs Eliminates 0 TIP entries

11. CST Enhancements (COP03) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • There is no v6 operational requirement identified that calls for the exchange of GPS Almanac Data and OPNOTES between GCCS-M and TTWCS • Issues • Need specifics on the encoder/decoder  TTWCS SW interface • This candidate will provide a solution for CR 9084, currently associated with MLS01(a v7 candidate), as the generic encoder/decoder could most likely be used to send OPNOTES • Potential Security Issue • Need to ensure that the types of data which can be sent are controlled • Definitely a conflict between generality of the encoder/decoder and the ability to restrict certain types of data

12. Backup Slides CST Enhancements (COP03)

13. CST Enhancements (COP03)CR Summary

14. CST Enhancements (COP03) Design Concept • In response to requests for data passing over CST, Northrop Grumman proposed creation of a generic encoder/decoder pair • Plug-in libraries would decode data based on the message header information and perform the following actions: • Incoming GPS almanac data is placed into the ILOG for processing • Outgoing OPNOTES are sent over the interface

15. Analysis for theDTED Processing Improvements (MAP03) Candidate POC: D. Calkins/R. Sullivan

16. DTED Processing Improvements (MAP03) Overview • Summary Description • Eliminates the use of the artificially high terrain elevations for areas that are water • A full set of DTED is not always available for an area • Currently, TTWCS avoids the entire area by using an artificially high elevation, even if partial DTED is available • Uses the partial DTED to determine if there is open water and assigns an elevation of zero to open water areas • Provides a graphical display of the regions covered by loaded DTED • Fleet Benefit • Allows retargeting and rapid response missions through water areas • Provides a visual aid to the operator to assist in managing DTED • Fleet Importance: Low • CR Summary • Adaptive: 1 • Perfective: 1 • Corrective: 0 • TOTAL: 2

17. DTED Processing Improvements (MAP03) Analysis • Technical Description • Use World Vector Shoreline data to make better use of partial DTED data • Areas which are known as ocean given an elevation of 0 • High elevation given to areas where the elevation is truly not known • Handle elevation assignments when the DTED.CELLS segment is installed • Dynamically update and display graphical overlays that represent the set of loaded DTED • Effort: Medium • Size: Medium • Complexity: Medium • External Dependencies: None • Risk: Low • Addresses 2 CRs Eliminates 0 TIP entries

18. DTED Processing Improvements (MAP03) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • Implementation may become obsolete in v7 with a new, different COE • Issues • DTED covered areas need to be shaded. Verify this can be done using the GOLD overlay messages

19. Backup Slides DTED Processing Improvements (MAP03)

20. DTED Processing Improvements (MAP03) CR Summary

21. DTED Processing Improvements (MAP03) Design Concept • When DTED is loaded/updated, the system should sense which DTED CDs are loaded and then update an overlay(s) to reflect this graphically • Provide a dynamic picture of which geographic areas are covered by loaded DTED • Use NIMA partial DTED data and World Vector Shoreline data to generate DTED files with the high terrain elevation only for landmasses of unknown elevations • Ocean areas have elevation of 0 • Landmasses with partial DTED make use of the appropriate elevation

22. Analysis for theDigital Nautical Charts (MAP04) Candidate POC: D. Calkins/R. Sullivan

23. Digital Nautical Charts (MAP04) Overview • Summary Description • Uses digital nautical charts to provide more precise data than is provided by World Vector Shoreline data • Much higher resolution data • Current data results in finer grain geographic details being lost, forcing hand-plotting on paper • Fixes the (auto) placement of waypoints too close to land • Fleet Benefit • Improved, more accurate chart display • Elimination of hand-plotting of geographic details by the operator • Fleet Importance: Medium • CR Summary • Adaptive: 1 • Perfective: 0 • Corrective: 1 • TOTAL: 2

24. Digital Nautical Charts (MAP04) Analysis • Technical Description • Digital Nautical chart data is available, but not currently being used by TTWCS. • Data is more accurate • DNC will only be used for display purposes not for route calculations • Auto-router placed a waypoint at 2.9 mi from land with land avoidance set to 3 mi • Effort: Low • Size: Low • Complexity: Low • External Dependencies: None • Risk: Low • Addresses 2 CRs Eliminates 0 TIP entries

25. Digital Nautical Charts (MAP04) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • Improved chart accuracy • Conformance to specified avoidance parameters • Issues • Need to prototype use of digital nautical charts to determine performance impacts

26. Backup Slides Digital Nautical Charts (MAP04)

27. Digital Nautical Charts (MAP04) CR Summary

28. Digital Nautical Charts (MAP04) Design Concept • OE mods to incorporate these products • Corrective issue with auto-router placing a waypoint too close to land

29. Analysis for theLaunch Area ACMS (OVL03) Candidate POC: D. Calkins/R. Sullivan

30. 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

31. 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: IFIR circular areas • Risk: Low • Addresses 3 CRs Eliminates 0 TIP entries

32. 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

33. Backup Slides Launch Area ACMS (OVL03)

34. Launch Area ACMS (OVL03) CR Summary

35. Launch Area ACMS (OVL03) Design Concept • Modify CsMs to forward Launch Area messages to the applications • Add a drop-down pick list from which the operator could choose a launch point derived from a previously received Launch Area message • Add new overlay type for Launch Areas • When a Launch Area ACMS is received, have TC2 request the creation of a representative overlay by CS • Have TC2 query the overlay DB to get a list of the Launch Areas • Alternate approach: Launch Areas could also be created on the GCCS-M and shipped over to TTWCS as GOLD messages, if the proper remarks fields are used

36. Analysis for theOverlay Server Enhancements (OVL04) Candidate POC: D. Calkins/R. Sullivan

37. Overlay Server Enhancements (OVL04) Overview • Summary Description • Provides for faster loading of the overlay database • Decreases response time of the system • Fleet Benefit • Better, faster system performance when a large number of overlays are present in the system • Fleet Importance: Low • CR Summary • Adaptive: 1 • Perfective: 3 • Corrective: 1 • TOTAL: 5

38. Overlay Server Enhancements (OVL04) Analysis • Technical Description • Increase the performance of CsOs by using a new set of COE overlay SPIs • Reduce time required to load overlay data • No need to maintain the entire database in memory because a change notification feature will be provided • Effort: Medium • Size: Medium • Complexity: Medium • External Dependencies: COE SPIs • Risk: Medium • Addresses 5 CRs Eliminates 0 TIP entries

39. Overlay Server Enhancements (OVL04) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • Implementation may become obsolete in v7 with a new, different COE • Issues • None

40. Backup Slides Overlay Server Enhancements (OVL04)

41. Overlay Server Enhancements (OVL04) CR Summary

42. Overlay Server Enhancements (OVL04) Design Concept • CsOS - use new COE SPIs

43. Analysis for theOverlay Management (OVL05) Candidate POC: D. Calkins/R. Sullivan

44. Overlay Management (OVL05) Overview • Summary Description • Allows easier editing of a parent overlay based on selection of an overlay segment on the chart • Facilitates operator selection of chart overlays for editing • Operator double-clicks on the desired overlay segment on the chart and the overlay editor window opens to enable the operator to make overlay edits • Fleet Benefit • Reduces operator workload • Fleet Importance: Medium • CR Summary • Adaptive: 0 • Perfective: 1 • Corrective: 0 • TOTAL: 1

45. Overlay Management (OVL05) Analysis • Technical Description • Currently, when you double-click on an overlay segment displayed on the chart, you get the editor for that segment • There isn’t an easy way to be able to directly open the parent overlay window from the segment editor window • COE enhancement to provide an easy way to get to the overlay editor window from a double-click on the chart • Effort: Medium • Size: Medium • Complexity: Medium • External Dependencies: COE changes • Risk: Medium • Addresses 1 CRs Eliminates 0 TIP entries

46. Overlay Management (OVL05) Recommendation • Recommendation Implement in v6 Defer for future consideration • Rationale • Minimizes operator workload • Issues • Need to work with SPAWAR for COE changes

47. Backup Slides Overlay Management (OVL05)

48. Overlay Management (OVL05) CR Summary

49. Overlay Management (OVL05) Design Concept • Need COE patch

50. Analysis for theSCO Improvements (OVL06) Candidate POC: D. Calkins/R. Sullivan