Space Network Access System (SNAS) Preliminary Design Review

1. Space Network Access System (SNAS) Preliminary Design Review September 12, 2005 NASA Code 452 Space Network (SN) Project

2. PDR Agenda • Opening Remarks Rose Pajerski • SNAS Design Approach Damon Smith • SNAS Overview Dave Warren • Data Server Design Dave Warren • Closed/Open Server Design Hoai Vo • Client Design Helly Maghsoudlou • Graphical User Interface Design Damon Smith • Security Joe Clark • Architecture Recommendation & Scott Robinson Development Environment • Software and Effort Estimates Chii-der Luo • Risks & Mitigation Dave Warren • Closing Remarks Rose Pajerski

3. Welcome/Purpose of Review • Review System Requirements adjusted from Delta-SRR due to RFA’s • Updated SRD • Updated OCD • Baselined documents 08/31 • Review High Level System Design • Review GUI Prototyping Effort • Approval for Detailed Design

4. Review Board • Jon Walker (chair), NASA Code 452 • Merri Benjamin, WSC Operations • John Bristow, NASA Code 583 – GMSEC • Tim Rykowski, NASA Code 581 – GPM • Steve Tompkins, NASA Code 581

5. Originator accepts or rejects response Originator writes RFA SRR Chair assesses and assigns Assignee prepares response Accepts SRR Chair Disposition Actions assigned and executed Assignee feels rejection is warranted and reworks response Assignee feels response is valid and appropriate Rejects Review Process • Request for Action (RFA) items may be written by any party and are to be submitted to the review Chair • Forms are available at this review or via the SNAS website: http://snas.gsfc.nasa.gov • RFAs are due Friday, September 16, 2005 • The Chair will assess RFA validity, combine similar ones if necessary, and assign them to appropriate personnel • RFA responses will be prepared by the assignee and forwarded to the originator for their acceptance or rejection • The RFA assignee will notify the Chair after working the RFA response with the originator • RFA responses will be approved/disapproved by the SRR Chair at a meeting to be scheduled by the Chair

6. SN Project Manager Code 452 Keiji Tasaki SNAS Deputy Product Development Lead Rose Pajerski/ Frank Herman Resource/Business Manager Paula Tidwell IT Security Curtis Emerson Code 451 GSFC Customer Commitment Manager S. Greatorex / NENS Systems Engineering Contractor ITT Implementation Contractor NENS Product ManagementContractor PAAC-II NASA Contractor Organizational Chart

7. SNAS Team • Product Development Lead (Code 452) • Fraunhofer USA: Rose Pajerski / Frank Herman • System Engineering Support • ITT: Denise Gilliland, Joe Clark • Customer Liaison Lead • BAH: Farrokh Jahandari • Core Implementation Team • BAH: Damon Smith • HTSI: Chii-der Luo, Dave Warren, Helly Maghsoudlou, Hoai Vo, Scott Robinson, Yuen-Han Kan, Dave Smith, Marcelo Reynolds

8. System Requirements Status • Delta-SRR RFAs • 28 RFA’s submitted and responded to • Automation (3, 9, 12, 15) • Certification & encryption (1, 8, 11, 21) • Client Capability (5, 16, 20, 27) • Configuration and Specs (4, 7, 9, 13, 23) • Report and Data Access (2, 6, 10, 17, 18, 24, 25, 26, 28) • Schedule Planning (14, 22) • SNAS Interface with DAS (14) withdrawn • Additionally, 3 RFAs from the 2003 SRR (62, 65 and 83) were Closed

9. System Requirements Status (cont) • Decomposition of the 337 SNAS System (software) Requirements • 282 are partially applicable to Client • 13 fully applicable to Client • 247 are partially applicable to GUI • 8 fully applicable to GUI • 202 are partially applicable to Open/Closed Server • 22 fully applicable to Open/Closed Server • 138 are partially applicable to Data Server • 2 fully applicable to Data Server

10. Documentation • System Requirements Document CCB approved • System Operations Concept Document CCB approved • Security Plan 2nd draft in development • System Test Document 1st draft in development • Acceptance Test Document 1st draft in development • Customer Liaison Plan in NENS Review • ICD between DAS/SNAS derived from DAS/SWSI for CDR • ICD between EPS/SNAS derived from UPS/EU for CDR

11. SNAS Design Approach Presented By: Damon Smith

12. Customer Centric Design • Requirements: Involved end users early to address customer requirements while supporting: • MOC operations • Legacy MOC components • Various MOC configurations • O&M Operations • Design: Presented the SNAS prototype to illustrate and negotiate design features • Solicited design options during customer demonstrations • Testing: Planning Involvement of selected customers in beta testing

13. Customer Centric Design (cont) • Group Customer Interface Meetings • CIM #1, April 13, 2005 • CIM #2, June 14, 2005 • CIM #3, August 25, 2005 • CIM #4 (tentative), January 2006 • Meetings with Individual Missions • JSC, TX (HSF, Shuttle, ISS) • GSFC & APL (GPM, R-XTE, EOS, TRMM, HST & STSCI, SP&M, GLAST) • Raytheon, CO (NPOESS & Aura) • Stanford University, CA (GP-B) • WSC, NM (O&M Operations) • Meetings with other Programs • GMSEC, IONet, TKUP, SNIS • RFAs • Original SRR, and Delta-SRR on April 28, 2005 • PDR, September 12, 1:00 – 4:00

14. Functional Wish List (1 of 4) • Majority of customer requests already included in the current requirements (wish list features are not in the current requirements) • Workspace concept for scheduling • The Workspace is envisioned as a bulk schedule builder and compatible with UPS RS. A Workspace is saved locally for a multi-day building period. Local file sharing for (Orbital Data, Schedule Data, and Reports) supports collective group scheduling. Degraded mode of operations and local off-line building are supported by the Workspace. • Auto processing for various file types (GCMR, TSW, TCW, PSAT/UAV) • SWSI and UPS contain functionality to pass TSW files automatically. Importing PSAT/UAV is only available in UPS and requires manual processing. • UPS Queries • UPS canned queries are easy to implement and satisfy customer requests for access to mission data in the database.

15. Functional Wish List (2 of 4) • Show 24 hour UPD history in the UPD panel & Alert history in the Alert panel • These features are currently in the concept to support lights-out MOC operations. Unattended operations can show a selectable 24 hours of event information. • Drag/Drop & Point/Click features in the graphical scheduling mode • The Java development environment allows for advanced user interactions with the graphics. In line comparisons and overlaying user selected data types (e.g. TUT with orbital data and schedule requests). • Performance Statistics (active) reporting • Currently in the concept to provide counters for input/output file transfers. Ensures that the message counts for “sent” and “received” match.

16. Functional Wish List (3 of 4) • UPD summary panel • Currently in the SNAS concept, triggered off the current UPD stream panel for user specified services. Provides a high level summary for active services (concept currently used at JSC). • User configurable alert threshold settings • In addition to configurable color coding, users would possess the ability to adjust thresholds for alert settings and UPD settings (audibles, confirmation dialog) • Combine NCC and DAS scheduling • DAS and NCC schedules are presented together in the graphical scheduling mode, the user must resolve schedule conflicts. • Schedule SN and GN resources • The SNAS graphical mode can display GN resource in the scheduling mode, when it is loaded as orbital data exclusion periods.

17. Functional Wish List (4 of 4) • User ability to change SIC after login • This function does not currently exist in SWSI or UPS. SNAS incorporation of this function would support SNIS when platforms can uniquely (IP) address science instruments. • GMSEC configurable support in the SNAS client • A SNAS interface with GMSEC would enhance the support for lights-out MOC operations. GMSEC could allow SNAS to utilize the pager feature for critical alerts. SNAS could also interface with the system status reporting on the GMSEC bus. • Display the current values and acceptable values for each reconfigurable parameter • Current values are available – bound range values are not.

18. System Overview Presented By: David Warren

19. NISN Secure Gateway MOC Clients DAS MOC Clients MOC Clients Operational Firewall NCCDS Internet Closed IONet Open IONet Auxiliary NCCDS Firewall NISN/CNE SNAS Open Server SNAS Open Server SNAS Closed Server SNAS Closed Server RAID (Prime) (Backup) (Prime) (Backup) Data Current SWSI System Architecture

20. NISN Secure Gateway Operational NCCDS MOC Clients Firewall DAS MOC Clients MOC Clients Internet Closed IONet Auxiliary NCCDS Firewall Open IONet NISN/CNE SNAS Closed Server (Prime) SNAS Closed Server (Backup) SNAS Open Server SNAS Open Server (Prime) (Backup) SNAS Data Server (Backup) SNAS Data Server (Prime) RAID Data Proposed SNAS System Architecture

21. Open IONET Internet Closed IONET SNAS SNAS SNAS SNAS SNAS SNAS CLIENT CLIENT CLIENT CLIENT CLIENT CLIENT SNAS Closed Server Connection Manager Connection Manager NISN Secure Gateway SNAS Open Server Message Router Message Router Message Router Message Router Connection Manager TUT Connection Webserver Manager Open Closed IONET IONET SNAS- DAS IF SNAS-DAS Interface SNAS- NCCDS IF SNAS-NCCDS Interface Data Interface SNAS Data Server Data Manager NCCDS DAS SNAS Data SNAS Notional Reference Architecture

22. Key Design Concepts • Reuse of Applications with Modifications • Maximize code reuse: • 25% UPS (of 305K SLOC) • 75% SWSI (of 200K SLOC) • Reuse of “logic” for all UPS C code assimilated into SNAS • Design Features • Framework provided by current SWSI system for stability and security • Enhance GUI functionality while providing combined SWSI/UPS menu functionality • Incorporate UPS functionality for orbital data processing & recurrent scheduling for automated SAR generation • Include External Processing System (EPS) interface for MOC data exchanges, which enables “lights-out” MOC operations • Provide Scheduling Workspace for users working “what if” forecast schedules • Separate O&M client application (better security, remote admin control) • SNAS/NCCDS interface (SNIF) process rewritten in Java • New common alert logging package for use by all processes in Client and Servers • New common data message logging package for use by Client, SNIF and SNAS/DAS interface (SDIF)

23. SNAS Context Diagram

24. SNAS Context - Internal

25. SNAS Data Transfers – NCCDS Scheduling (Ref. 1) * from 452 ICD SN/CSM

26. SNAS Data Transfers – NCCDS Real-time (Ref. 2) * from 452 ICD SN/CSM

27. SNAS Data Transfers – DAS Scheduling (Ref. 3) * from 452 ICD DAS/SNAS

28. SNAS Data Transfers – DAS Real-time (Ref. 4) * from 452 ICD DAS/SNAS

29. SNAS Data Transfers – External Processing System (Ref. 5) * future 452 ICD EPS/SNAS

30. System Data Flow

31. Diagramming Conventions

32. SNAS Data Server Presented By: David Warren

33. Data Server Context

34. Data Server Level 1

35. Data Server Level 2

36. Database Components - SWSI • SNAS database starting with current SWSI Schema • Adding UPS tables to support orbital, recurrent scheduling, and EPS

37. Database Components - UPS

38. SNAS Closed Server Presented By: Hoai Vo

39. SNAS Server Key Points • Maximize SWSI Server code reuse • Move Database Server Process to separate (3-tier) system • Rewrite SNIF in Java • Communications with NCCDS uses XDR protocol • Log NCCDS input messages after XDR decoding • Log NCCDS output messages before XDR encoding • Create and use common alert logging package for all processes, including the client application • Create and use common NCCDS/DAS message logging package for all processes, including the client application • Replace SWSI custom HA package • System Administration functions moved to separate O&M client • TUT data resident on the Open IONET web server & MOC client

40. SNAS Server Level 1

41. Server Context Connection Manager

42. Server Level 2 Connection Manager

43. Server Context Message Router

44. Server Level 2 Message Router

45. Server Context SNAS-DAS Interface (SDIF)

46. Server Level 2 SNAS-DAS Interface (SDIF)

47. Server Context SNAS-NCCDS Interface (SNIF)

48. Server Level 2 SNAS-NCCDS Interface

49. SNAS Client Presented By: Helly Maghsoudlou

50. Client Context