SSA v5 Enhancements Candidates 2/3/03

1. SSA v5 Enhancements Candidates2/3/03 Material assembled to allow fleet personal to provide the Software Support Activity (SSA) with candidate priorities.

2. Elements of TTWCS v5 • TTWCS v5 is the next major evolutionary build following I6. IOC is planned for mid-FY 06. • System Requirements Review at LMVF on 11-13 March • Support for Major New Features (establishes the baseline) • SSGN • T+N (Same as ATTWCS) • TTL for SSN and UK • Cruiser Conversion (hybrid VLS) • Common Build (includes UK) • Integrated Training Architecture (ITA)– Level 3 • Enhancements • Corrective (something is broken) – minor SW problems • Perfective (make existing capability better) • Adaptive (add new capability) • Only new or significantly revised capabilities will be listed for review

3. Pre SRR Review of Products • Functional Requirements (SSS & way forward brief) • Special Projects (SP), Combat Fleet Forces Command (CFFC) • Enhancement Candidates (Briefed by functional area) • CFFC, Planners, Tacticians, Trainers • Employment Concept Including Mission Scenarios • Planners, Tacticians, Trainers • User Workflows (Updated and augmented) • Tacticians, Trainers, Strike Officers, Cruise Missile Supervisors • Storyboard Windows (Brief in conjunction with Workflows) • Tacticians, Trainers, Strike Officers, Cruise Missile Supervisors, Fire Control Operators • Usability Prototype (Brief usability test results) • Fire Control Operators

4. SSA v5 Build Def Status • 1036 Candidates Reviewed and Classified as Follows • 684 Worthy of Consideration for v5 • 97 Valid Adaptive Candidates • 223 Valid Perfective Candidates • 364 Valid Corrective Candidates • 345 Will Be Closed Out • 310 Are closed as “Invalid” • 35 To be closed as “Never to be fixed” • 7 Not relevant in the v5 time frame • New Candidates are Being Received and entered as System Change Requests and then sent to the mini-groups for evaluation

5. Working Group Assessments • The 684 remaining valid candidates have been assessed and grouped into 23 functional categories • Each of the 23 categories has some number of sub categories • Seven “mini-working-groups” were formed • Each working group assigned from one to seven categories to evaluate • Each working group was tasked to do the following for each category assigned to them: • Study the candidates assigned to each category • Look for systemic problems • Develop a set of recommended improvements for v5 • Prepare a set of briefing charts for each category • Recommendations presented at an internal TEM on Dec. 11 & 12 • SW folks are evaluating candidates for inclusion in V5 • Only feasible candidates have been included in this brief

6. Guidance for Assessments • The baseline requirements (such as SSGN, TTL, common build, etc.) are not addressed in this assessment • Recommendations should be holistic in nature • All existing candidates should be looked at by the group • Solicit input from all available sources; testers, developers, etc. • It’s up to the group to determine which candidates to address • Recognize the relationships between multiple candidates • Come up with comprehensive rather than “shotgun” solutions • It’s OK to make several recommendations in each category • All evaluations and prioritization should be done from an operator’s perspective • What does it mean to the operator and the mission of the system if we fail to address this concern? • In addition to the obvious, stability, performance, and supportability are valid operator concerns

7. Guidance for Assessments (cont.) • Review all TIPs and TTBs associated with the candidates • Priority should be given to eliminating TTBs and TIPs • Review fleet prioritization of adaptive and certain perfective candidates • Recommendations for additional content must be technically feasible with low risk when constrained by: • Resources consumed adding new capabilities above • Anticipated SSA funding • SSA schedule • Output product is a set of briefing charts for each category. Only high level charts will be briefed • Backup charts must provide sufficient detail to allow the effort to be scoped • Provide package for Software evaluation mid-Dec. Complete • Much of what is included is this package presented to software for scoping

8. Results of Previous Review • Before the holistic approach was agreed upon, the fleet representatives assembled a team to review the preliminary set of candidates • Review conducted on 09/10/02 LANT/PAC surface • Review conducted 09/18/02 submarine community • Final Review by ALCON 9/23/02 • The next three slides reflect the fleet prioritization of the enhancement candidates conducted in late Sept 02. • Not included in this review were : • Display enhancements • Training enhancements • These slides are included as reference only and priority changes are expected since some items have been deleted and some items have been added.

9. A + P High Prioritized One Line TitleRank • CG Conversion (now part of v5 baseline) 1.1 • Insufficient Memory in the System(part of HWD ECP to baseline system) 1.2 • Transfer Threat Data electronically 1.3 • TSN Testing prior to Execution 1.4 • No way to transmit SCO/TIR/OPNOTES to the LAC/Auto Populate the TIR (Fleet combined candidates) 1.5 • Other Platform Tasking Verification/Change ASN to alpha/numeric and • display to operator instead of engagement numbers(combined on 9/10) 1.6 • Save Retarget and Aimpoint Update Missions (Retarget and Aimpoint • updates sequences not in I6) (Aimpoint update of retarget now in I6) 1.7 • Add DTED storage capacity/Better DTED displays 1.8 • Display TTWCS alerts in CCS 1.9 • Proper Tasking Validation (Separate out from tasking by cell iD, etc) 1.10 • Use stored Waypoint set for Auto-planning 1.11 • Enable MM to hold Three GPS Crypto-variable Weekly Keys 1.12 • Auto create LPMP FPPWP near land 1.13 • Send selected 3900/146 messages as man-readable msg (combined with 1.5) 1.14 • Specify PLP for use in creating Engagements (Fixed in I6.04) 1.15 • Use CCS Inventory 1.16 • Auto transition by earliest missile launch 1.17 • Synchronization of EM Database after failure 1.18 • LTA update processing 1.19 • Display improvements for LPMP routes and ACMSs (no-fly, etc.) 1.20 • Send TTWCS Strike Package 1.21 • Transfer LPMP missions (and related data) off-board 1.22

10. A + P Medium Prioritized One Line TitleRank • TSN COMMS Planning and display on platform 2.1 • DBRI Supplement 2.2 • EM Planning chart insets to auto resize to launch basket 2.3 • Selection of Multiple Engagements for SCO Transmission 2.4 • Display all mission Branch IDs 2.5 • CST Setup Macro 2.6 • Single Source Scenario Save and Start 2.7 • Change Post Launch Sim to enable specific faults at known times 2.8 • Trial Heading Functionality 2.9 • Add Router F/O Diagnostic test ` 2.10 • Aimpoint Update clobber analysis improvement 2.11 • Display of VLS configuration 2.12 • Late Launch RS not viewable next to Primary Engagement in status window 2.13 • Saving Textural TS&R reports to files (OBE with CMTpc replacing TSR) 2.14 • Need Default Track Avoidance Values for the Sys Parameters Window 2.15 • PML Search Keys 2.16 • Tasking by cell/torpedo tube/XMID/Tail Number 2.17 • System Plan Parameters Track Avoidance Incorrect (I6 Fix?) 2.18 • Add ALA/Planned Launch Position to Composite Launch Basket window 2.19

11. A + P Medium Prioritized One Line TitleRank • Ship IDs (SIDs) should auto-populate given hull names/Update location codes and SIDS electronically 2.20 • Automatic activation of CG/DDG Audible Salvo Alarm (not a V5 candidate) 2.21 • More User-friendly War Diary HCI 2.22 • Dynamic Launch Baskets when Editing Waypoints 2.23 • Put LAC Name in LAC Indicator field 2.24 • Incorporate VUP Processing into LPMP (not a V5 candidate) 2.25

12. A + P Medium Prioritized One Line TitleRank • Better naming of Strike Package Ids (not a V5 candidate) 3.1 • Use single Engagement database 3.2 • CTU Enhancement 3.3 • Update JCM-2179/2 to CORBA-Based Interface (not a V5 candidate) 3.4 • Password entry synchronization 3.5 • COE Compliance 3.6 • Installation improvements (in work)3.7 • Launch Basket Display Improvements 3.8 • LPMP needs to display Launch Baskets (not a V5 candidate) 3.9

13. 23 Functional Areas • The next few slides will describe the seven mini-groups and how the 23 functional areas were divided between them by combining “like” functions. • Under each of the 23 functional areas are enhancement candidates recommended by each of the mini-groups. • In many cases these enhancement candidates are now a combination of several enhancements to make that specific function work better. • For example, tasking validation enhancement includes: Using the TLD (vs ASN); Other FRU and Ghost Tasking; More user friendly manual tasking entry; and HCI to show Strike Package Revisions. • If enhancement candidates incorporate several “major” enhancements, they will be listed as sub-tasks to the major candidates. • All candidates in Red need to be prioritized and are considered capability enhancements. All other candidates are software only and will be prioritized by the SSA • The functional areas are numbered 1-23 on the following slides

14. System Infrastructure Group 1. Performance/Stability (PFS) • Correct Software Deficiencies • Post Launch Execution (PLE) Rearchitecture • Improved IPC for Stability and Cost-Reduction • Improved Threading and Concurrency • Common Framework for Fault-Detection • Proactive Software Analysis 2. Supportability/Portability • Software Enhancements - v5 • Software Enhancements for COE Compliance - v5 • Memory Leak Evaluation 3. Hardware (HWD) • Software Updates for Replacement of Obsolete Hardware 4. Built In Test (BIT) • Diagnostics/Utilities Improvements • Add Fiber Optic cable test • Fix Temperature sensor reports • Improve operator feedback (PASS/FAIL status, timeout explanation/conclusion)

15. Command and Control Group 5. Tasking and Reporting (TAR) • Improved operator tasking interface. • Tasking by cell, torpedo tube, tail number, or XMID. • More automation in filling in tasking fields. • Targeting by TLD • Highlight to operator changes in SP revisions • Improved SP validation. • Validate ability to support other FRU and Ghost tasking (Includes using preselection for half module checks) • Validation for strike rehearsals. • More descriptive and reliable communications and reporting. • Improved SP exception, post launch, post strike and launch exception reporting. • Usable, man-readable inventory report. • Enhanced interoperability functionality. • Send all manually created or edited strike package to TC2S. • Check TSN availability prior to Execute (TSN ping).

16. Command and Control Group (cont) 6. In Flight Management (IFM) • Improved Missile Communication • Handle Multiple Redirection (Aimpoint Update/Aimpoint Update, and finish Aimpoint Update/Retarget) • Correct Server/Display And Stability Issues • Better Decision Aides For Redirection • Improved IMMM Identification • Provide Capability To Take Control

17. Command and Control Group (cont) 7. Platform Mission Library (PML) • PML Repository Management - Keep entire PML on the hard disks • Improved Operator Decision Support • Improve ability to generate and review LPMP missions • PML Data Completeness • PML Stability Problems • TC2S Reporting • Supplemental DBRI to report true PML statuses • Automatically updated SID and Location code lists • Transmit LPMP and retargeted missions to TC2S platforms

18. Command and Control Group (cont) 8. LPMP Mission Creation (LMC) • Strike Coordination Support • Time on target • Multiple retargets • Improve CEP calculation • LPMP Route Generation • Automatically determine safe aimpoint update (AU) altitude • Auto-generate FPPWP close to land • Control of divert point for AU and retarget missions • Generate shorter, faster routes • Route through very narrow flight corridors • Increase maximum number of waypoints in LPMP missions • LPMP Threat Data Management Improvement (ie. threats outside OPAREA) • Options for Use of Routing Constraints – Ignore threats and No Fly Zones

19. User Performance Group 9. User Performance (UP) • Improved Decision Support • Improved Error Management • Improved Clarity and Consistency • Improved Visualization • Dual Monitor as in ATWCS 1.7.1 • Improved Task Management • Provide more comprehensive task execution and feedback, including sending select prompts/alerts to CCS • Improved Efficiency

20. Overlay, Map, and Engagement Group • Engagement Planning (ENG) • EM Auto-Transition Issues • Default Stored Waypoint Set • Trial Heading • Misc. Items (Improved Eng Mang HCI) • Auto-Router Enhancements • Overlays (OVL) • Rhumbline vs. Great Circle Issue • Overlay Database Synchronization • Overlay Server Enhancements

21. Overlay, Map, and Engagement Group (cont) 12. Common Operational Picture (COP) • Receipt of Threat Data • Consistency/Validity Checker • Dynamic Update of Threat Table • CST Fixes/Enhancements • Maps (MAP) • DTED Enhancements • DTED Updates • OpNotes/OpMsgs (OPN) • OPNOTES over CST

22. Training Group • Operator Proficiency & Training (OPT) • Following should be considered as a single item • Replace TSR with CMTpc • Strike Reconstruction • Coordinated Training Control • Upgrade Post Launch Execution (PLE) Missile Simulation • Upgrade DIS Simulation • Battle Group Training • Remove Recon Opnote • Clean Up VLS Simulator • Clean Up ISS

23. System Functions Group • System Administration (SAM) • Login/Logoff Annoyances • Installation made Easy” • Multi-node installation with GUI like ATWCS 1.7.2 • Increase DTED partition size (entire world, 30 GB for level 1) • “Deinstall Cleanup” • Data Logging/Capture (DLC) • Usability of War Diary • Improve War Diary HCI and completeness • Data Extract Fixes • RDT Enhancements • Provide progress bar during RDT • Allow DX files to be transferred • Improve Archive/Restore • Improve usability of Archive/Restore interface

24. System Functions Group (cont) 18. Failover (FAI) • FAI Automation and Reporting“Installation made Easy” • Multi-node installation with GUI like ATWCS 1.7.2 • Increase DTED partition size (entire world, 30 GB for level 1) • Security Administration (SEC) • Security Anomalies • Password synchronization, eliminates having to change passwords on 3 additional processors • System Bootup/Shutdown (SBS) • Verify configuration/restore defaults • Create a “Verify Configuration” Utility, Add “restore defaults” button. • Automate CST Configuration Setup • Fix Shutdown Problems 21. System State Control (SSC) • Task Status and Control 22. System Mode Control (SMC) • Transition Fixes

25. Missile Management Group • Missile Management (MSL) • Upgrade Cell Preselection • Add Preselection for SSN and UK Submarine platforms • Operator should not be allowed to override tasking by cell/tail/etc. • Upgrade SSN Interface • Terminate LTA processing at Assign Engagement and use LTA results provided by CCS • Display and use the inventory data provided by CCS • Display TTWCS alerts in CCS • Incorporate design enhancements • Reduce the TTWCS-VLS block data spacing (baseline dependent) • Upgrade the TTWCS HCI/Alerts • Upgrade VLS launcher interface • Improve GPS Crypto key rollover processing

26. The next couple hundred slides take each functional area and provide the following information: • Functional Area being addressed • High level description of the functional area • Topics for improvements • Technical Description of each improvement, Fleet Impact, Complexity, and interdependicies • At the end each functional area, a Summary of of how many problems will be fixed and the number of tech bulletins or tech notes can be eliminated. • Following the summary, is supporting documentation and can be used to convey a better understanding of the problem and how the solution may be implemented • Feedback on any information is this presentation is welcomed.

27. TTWCS SSA v5 Enhancement RecommendationforPerformance and Stability (PFS) Candidate 1

28. Category Description • Performance and Stability (PFS) • System Performance • The manner in which the system functions in terms of execution, efficiency, responsiveness, and effectiveness. • System Stability • The reliability and dependability of the system to consistently perform to expectations under normal and adverse operating conditions.

29. Recommended Areas for Improvement • Correct Software Deficiencies • Post Launch Execution (PLE) Rearchitecture • Improved IPC for Stability and Cost-Reduction • Improved Threading and Concurrency • Common Framework for Fault-Detection • Proactive Software Analysis Denotes Software Only Denotes areas for Fleet Evaluation

30. Software Deficiency Corrections • Technical description • Eliminate software defects that exist due to implementation error. For example: • Corrective software problems • Post Launch Execution (PLE) Rearchitecture needed to improve operations – high priority • Fleet Benefit • Increased system availability. • Reduces deficiencies and produces a more stable system. • Fleet Importance: • Effort: Medium • Size: Medium to High • Complexity: Medium • External Dependencies: None • Risk: Medium • Addresses 35candidates Eliminates 10 TIP entries

31. IPC Layer Improvements • Technical description • Improve IPC layer for increased stability, maintainability, performance, and cost-reduction. • Replace Orbix with TAO. • Replace IIM, P2PAPI, CLAPI, and SLAPI with CORBA • Analyze CORBA IDL and reduce the number of blocking two-way invocations with one-way invocations, asynchronous responses, and response timers. • Fleet Benefit • Reduces cost by avoiding runtime licenses. • Improves system reliability and performance. • Fleet Importance: • Effort: Medium to High • Size: High • Complexity: Medium • External Dependencies: None • Risk: Medium • Addresses 7candidates Eliminates 0 TIP entries

32. Threading & Concurrency Improvements • Technical description • Enhance threading to improve stability by allowing for more reliable interaction with fewer deadlocks, and exploit a program’s natural concurrency to improve performance. • Investigate existing thread models for commonality and create a generic thread framework for creating, destroying, synchronizing, and controlling threads as well as improving the ability to debug threaded programs. • Apply the framework to TcTh, TcAh, TcPle and TcC. • Convert slow serialized software functions to faster multi-threaded functions. • Fleet Benefit • Improved stability of components and ability to diagnose new problems. • Faster system responses and improved performance • Fleet Importance: Medium • Effort: Medium • Size: Medium • Complexity: Medium to High • External Dependencies: None • Risk: Medium • Addresses 5candidates Eliminates 1 TIP entries

33. Common Fault-Detection Framework • Technical description • Create a common framework for monitoring application health and providing fault notification. • Implement a reliable means to detect applications that are hung. • Improve the CORBA Framework to timely detect when a registered CORBA object no longer exists and reliably notify all of its availability listeners. • Add event timeouts to detect application non-response. • Fleet Benefit • System is more tolerant to faults/errors and more capable of automatically recovering from a failure. • Fleet Importance: • Effort: Medium • Size: Medium • Complexity: Medium • External Dependencies: None • Risk: Low to Medium • Addresses 4candidates Eliminates 1 TIP entries

34. Proactive Software Analysis • Technical description • Perform software analysis across TTWCS components to proactively find and eliminate latent problems. • Reduce coupling and increase cohesion between objects • Eliminate unneeded complexities in software design and code • Fleet Benefit • Improves both performance and stability of the system by proactively fixing potential problem areas. • Fleet Importance: • Effort: Medium • Size: Medium • Complexity: Medium • External Dependencies: None • Risk: Medium • Addresses 1candidates Eliminates 0 TIP entries

35. PFS Summary • These recommendations cover 52 of 69 candidates assigned to this category. • If all recommendations are followed 0 TTBs and 14 of 14 TIPs would be eliminated.

36. TTWCS SSA v5 Enhancement RecommendationforSoftware Supportability and PortabilityCandidate 2

37. Category Description • Items that relate to maintainability of the system operational software • Items to promote and facilitate the portability of the operational Software Supportability and Portability (SSP) software to accommodate technology refresh migrations as as well as the ability to support the TTWCS • SW development tool enhancements

38. Recommended Areas for Improvement • Software Enhancements for COE Compliance - v5 • Software Enhancements - v5 • Memory Leak Evaluation Denotes Software Only Denotes areas for Fleet Evaluation

39. Software Enhancements for COE Compliance - v5 • Technical description • SW that doesn’t meet COE IR&TS compliance. These items will enable TTWCS to meet level 5 compliance, such as consistent use of naming conventions, use of only public APIs, etc. • Fleet Benefit • SW code cleanups that would eliminate potential discrepancies and error conditions. Provide ability to maintain the system, migrate SW to newer releases thus enabling being more responsive to the Fleet. • Fleet Importance: • Effort: Medium • Size:MediumComplexity:Medium • External Dependencies: Potential COE impacts • Risk: Medium • Addresses 9 candidates Eliminates 0 TIP entries

40. Software Enhancements v5 • Technical description • In some instances, SW structure and process launching can be modified enhancing SW supportability, maintenance, and portability. Very minor operator impact. • Minor SW code cleanups to minimize future SW supportability and maintenance. Very minor operator impact. • Fleet Benefit • SW code cleanups would eliminate potential discrepancies and error conditions and reduce operator interventions. • Improves responsiveness to Fleet requirements. • Facilitates portability to accommodate processor platform migrations. • Fleet Importance: • Effort: Low • Size:LowComplexity:Low • External Dependencies: None • Risk: Low • Addresses 9 candidates Eliminates 0 TIP entries

41. Memory Leak • Technical description • Improve memory utilization by analyzing and evaluating memory leaks that may occur when SW segments are running. • Fleet Benefit • Improve process efficiency. • Eliminate potential process failure resulting from a possible cumulative effect of the memory leak. • Fleet Importance: • Effort: Low • Size:MediumComplexity:Low • External Dependencies: None • Risk: Low • Addresses 2 candidates Eliminates 0 TIP entries

42. SSP Summary • These recommendations cover 49 of 51 candidates assigned to this category • 15 COE compliance deferred: related to tools enhancements which should be worked at the same time as the technology refresh in v7 • Minor COE Compliance that can wait until tech refresh, Note: Adds risk to v7. • 14 deferred SW enhancements – minor operator impacts • 2 to be Closed: OBE due to changes in CS since PR written or not worth fixing to minor • If all recommendations are followed 0 TTBs and 0 of 0 TIPs would be eliminated

43. TTWCS SSA v5 Enhancement RecommendationforHardwareCandidate 3 POC: Disch

44. Category Description • Hardware (HWD) • Obsolete TEC, MTC, and Printer components • Required TTWCS components that are no longer available from the Original Equipment Manufacturer (OEM) or after market sources • Automated salvo alarm and ship vent closure enhancement • Availability & Status Window always displays up arrow for crypto status

45. Recommended Areas for Improvement • Software Updates for Replacement of Obsolete Hardware • Note: TTWCS hardware ECP being finalized to Baseline the hardware design. • Memory was added • Larger hard drives expected • COTS obsolescence will reviewed and appropriate action taken to support the deployment of v5

46. SW Updates forReplacement HW • Technical description • SW changes need to be made to accommodate replacement components. • Includes new driver installation, configuration file changes, disk partitioning and Diagnostics- BIT/FIT changes • Fleet Benefit • Changes are necessary in order to deploy and maintain TTWCS • Fleet Importance: • Effort: Low • Size: Low Complexity:Low • External Dependencies: None • Risk:Medium • Addresses 10 candidates Eliminates 0 TIP entries

47. HWD Summary • These recommendations cover 10 of 25 candidates assigned to this category • 13 candidates for obsolete hardware replacement do not require SW changes • 1 candidate (PR 7991 – Salvo Alarm should be automatic) will be closed as out of scope • Ship’s air intake vents are closed automatically by AEGIS upon VLS firing imminent • Plan execution software was modified to include an information display that clearly reminds operators to sound the Salvo Alarm prior to execution • Automating the Salvo Alarm is not cost effective • If all recommendations are followed 0 TTBs and 0 of 0 TIPs would be eliminated

48. TTWCS SSA v5 Enhancement RecommendationforBuilt In TestCandidate 4

49. Category Description • Built In Test (BIT) • GUI/Diagnostics and GUI/Diagnostics/NT • Change to operator interface for reliability/predictability/usability • GUI/OE Utility • Change to OE utility operation • LRU Test • Change to test algorithm • New LRU Test • New test capability • Startup Test Reporting • Corrective change to startup status reporting • System Setup/Installation • Corrective change to UPS interface

50. Recommended Areas for BIT Improvement • Diagnostics/Utilities Improvements • Add Fiber Optic cable test • Fix Temperature sensor reports • Improve operator feedback (PASS/FAIL status, timeout explanation/conclusion)