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 RFAs
• 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
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
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 RFAs 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
• OM 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,
  SPM, GLAST)
• Raytheon, CO (NPOESS Aura)
• Stanford University, CA (GP-B)
• WSC, NM (OM Operations)
• Meetings with other Programs
• GMSEC, IONet, TKUP, SNIS
• RFAs
• Original SRR, and Delta-SRR on April 28, 2005
• PDR, September 12, 100 400

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
Current SWSI System Architecture
20
Proposed SNAS System Architecture
21
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 OM 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
  OM 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
51
Client Level 1
52
Client Level 2 Graphical User Interface
53
Client Level 2EPS Interface
54
Client Level 2 Transaction Processor
55
Client Level 3 Single Transaction Processor
56
Client Level 3 Bulk Transaction Processor
57
Client Level 3 Recurrent Transaction Processor
58
Client Level 2 Client Data Manager
59
Client Level 3Connection to Server
60
Client Level 2 Workspace Saver / Restorer
61
SNAS Graphical User Interface

• Presented By
• Damon Smith

62
GUI Prototype Design Principles

• Assumptions
• SWSI used as the development base
• Selecting inherited features from SWSI or UPS
• Maximize code reuse for logic
• Minimize development cost while providing full
  feature functions
• UPS Recurrent Schedule logic specifically cited
  for reuse to provide expected SAR results
• Report functions support current MOC systems
• SNAS retains UPS EU reporting functions,
  (request/response protocol file naming)

• Methodology
• SNAS Main Menu illustrates the multi-stage
  development, arriving at the current solution
• Main Menu - SWSI with SNAS Overlay
• Main Menu - SWSI/SNAS with UPS Overlay
• Main Menu - SNAS Fully Combined
• Main Menu - SNAS Optimized
• SWSI GUI Flow Illustrated
• UPS GUI Flow Illustrated
• SNAS Fully Combined GUI Flow
• Revisit Main Menu - SNAS Optimized

63
Proposed MOC Client Main Menu
Proposed Main Menu with Traceability to SWSI and
UPS Functions
64
Prototype Demo Preface

• The OM client is separate from MOC client
• Provides electronic client interface between
  OM-MOC
• OM and MOC Client electronic interactions for
  Mission Data
• SSC data
• Mission User Lists
• Prototype Events
• OM functions are not distributed for security
  reasons
• SNAS OM Positions are System Administrator,
  Database Administrator
• OM Client Functional Segments
• SNAS User Data
• Static Mission Data
• System Maintenance
• System Monitor

65
Proposed OM Client Main Menu
Proposed Main Menu with Traceability to SWSI and
UPS Functions
66
Prototype Demo Preface

• Prototype demonstrated at CIM 3, August 25, 2005
• Currently collecting feedback
• All GUIs will include the following capabilities
  as a standard Execute/Transmit/OK/Submit, Print,
  Save, Duplicate/Clone, Cancel
• The distinction for Simulated or Operational
  environment is established at login
• A Simulation or Operational label will appear
  in a status indicator Main Menu panel
• The Main Menu shown in the prototype includes
  selections for all MOC positions
• SNAS User positions are Mission Manager, Mission
  Scheduler/Planner, Mission Controller, Mission
  Support, Mission Observer

67
Advanced Workspace and Scheduling Concepts

• 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
• Graphics pane will include both DAS and NCC
  schedule data for visual inspection

• Visually support combined scheduling for GN and
  SN resources, with a concept for GN schedules
  imported as orbital constraint data
• The combined tabular and graphical scheduling
  concept supports drag/drop features between
  panels
• The current graphical scheduling concept contains
  20 timelines, so all lines can be viewed in a
  single pane
• Ability to overlay user selected timelines in the
  graphics pane

68
SNAS GUI Prototype Download

• Download the Prototype
• Via the WWW at swsi.gsfc.nasa.gov/hoai
• Request the download password from the SNAS
  Website
• Provide Feedback
• Via the WWW at snas.gsfc.nasa.gov/
• Enter the Customer Input section
• Email at snascusinput_at_class.gsfc.nasa.gov

69
SNAS GUI Prototype
70
Security
Presented By Joe Clark
71
Outline

• System Description
• Purpose, status, etc.
• Responsible organization(s) and individuals
• System Architecture
• boundaries
• Interconnections and information sharing and
• Preliminary Risk Assessment
• Technical Controls

72
System Description

• The Space Network Access System (SNAS) is
  considered a General Support System (GSS)
• Acquisition and Development Phase
• The purpose of the SNAS is to provide a
  standards-based customer interface for performing
  Tracking and Data Relay Satellite (TDRS)
  scheduling and real-time service monitoring and
  control. The intent of the SNAS is to replace
  existing scheduling and real-time systems (i.e.
  SWSI and UPS) for SN customers.
• The SNAS servers and database will be housed with
  the NCCDS at the White Sands Complex (WSC).
  Customer access will be through an application
  running on a customer-provided workstation, which
  will normally be housed at the Customers Mission
  Operations Center (MOC). Approved mobile
  workstations, e.g. notebooks, will be used by
  Customers in an uncontrolled environment in some
  cases.
• SNAS falls under the WSC security plan

73
SNAS Security Architecture
74
SNAS System Boundaries
75
SNAS Server Interconnectivity

• SNAS Servers and Database
• SNAS Closed IONet Server and Database
• SNAS Database only interconnects with the SNAS
  Closed IONet Server
• SNAS Closed IONet Server interconnects with
• SNAS Database (directly)
• NCCDS and ANCC through the Closed IONet
• DAS through the Closed IONet
• SNAS Open IONet Server through the NISN Secure
  Gateway
• SNAS Clients in Customer MOCs through the Closed
  IONet
• SNAS Open IONet Server
• SNAS Open IONet Server interconnects with
• SNAS Closed IONet Server through the NISN Secure
  Gateway
• SNAS Clients in Customer MOCs through the Open
  IONet
• SNAS Clients in Customer MOCs through the Public
  Internet

Note Some SNAS Clients may be under the
control of a Customer MOC but not physically
present in the MOC
76
SNAS Client Interconnectivity

• SNAS Clients
• SNAS Clients on the Closed IONet interconnect
  with the SNAS Closed IONet server through the
  Closed IONet
• SNAS Clients on the Open IONet interconnect with
  the SNAS Open IONet server through the Open IONet
• SNAS Clients on the public Internet interconnect
  with the SNAS Open IONet server through the
  public Internet and the Open IONet
• SNAS Clients may interconnect with a MOC EPS

Note the SNAS Client application is a software
module that runs on a customer supplied computing
platform Note Some SNAS Clients may be under
the control of a Customer MOC but not physically
present in the MOC
77
Constraints on Information Sharing

• The SNAS servers are constrained by
• Rules for interconnecting with the IONet
• Rules for interconnecting through the NISN Secure
  Gateway
• Limitations of the NCCDS/ANCC interface
• Limitations of the DAS interface
• The SNAS clients are constrained by
• The Customer MOC security program
• Rules for interconnecting with the IONet
• This includes accessing the Open IONet through
  the public Internet

78
Preliminary Risk Assessment

• SNAS carries the same information as SWSI
• SNAS has the same vulnerabilities as SWSI
• SNAS faces the same threat environment as SWSI
• The SNAS approach to security will be very much
  like the SWSI approach
• The SNAS servers and database will be housed at
  WSC
• WSC management policies will apply
• WSC operational policies will apply
• The SNAS clients will be under MOC management
• MOC management policies will apply
• MOC operational policies will apply
• The Technical control provided by SNAS will be
  the focus of this presentation

79
Technical Controls

• Identification and Authentication
• Logical Access Controls
• Audit Trails
• System and Communication Protection

80
Identification and Authentication

• All SNAS users will have an established User ID
• Provided to SN OM personnel by project official
• Determines roles and privileges
• Determines which SIC or SICs can be accessed
• All SNAS users will have a password
• Meets common minimum standards
• Must be changed at least every 90 days
• All SNAS sessions require a passphrase
• Meet common minimum standards for passphrases
• Must be changed at least every year
• All SNAS Client workstations will have a known
  fixed IP address
• MOC Mission Manager and SNAS Database
  Administrator will coordinate to maintain
  currency of SNAS user IDs

81
Logical Access Controls

• Server OS (Linux/UNIX) limits user access to
  server and/or database resources
• SNAS defined user roles will support least
  privilege and separation of responsibilities
• MOC will be responsible for determining how roles
  are applied
• Attempted unauthorized transactions will not be
  monitored except for failed login attempts
• User Inactivity will not be monitored by SNAS
• Lights out operation requires that a SNAS
  terminal be left with an active, unattended
  session for extended periods of time
• All actions will be logged to an unique User ID
• MOC must ensure
• SNAS workstation is protected when left
  unattended
• Automatic transactions are safe
• SNAS will provide the MOC with the option of
  encrypting SNAS files stored locally to the SNAS
  Client

82
Audit Trails

• SNAS will log
• All message that transit the servers
• Records pertaining to
• Establishment and termination of communications
• System alerts
• Database alerts
• Successful login and logout including Switch User
• Failed login including Switch User
• SN OM personnel will be able to selectively
  control logging of messages and records
• SN OM personnel will be able to selectively
  delog all logged data
• SNAS will display a 24-hour alert history for
• SNAS clients
• SNAS Database Administrators
• SNAS System Administrators
• Automated tools for monitoring logs will be
  investigated

83
System and Communication Protection

• Data on the SNAS servers and the SNAS database is
  protected by access restrictions
• The SNAS system administrator has access to all
  data on the SNAS servers and database
• The SNAS database administrator has access to all
  information in the SNAS database
• SNAS users can only access data
• Using predefined queries and
• Only data related to the specific SIC(s) for
  which they are authorized
• Unauthorized access is prevented by the
  Identification and Authentication provisions
• Data stored locally on the SNAS Client is
  protected by the MOC security plan
• SNAS will provide an encryption option
• Data transported between the SNAS Client and the
  SNAS Servers will be encrypted

• NOTE Encryption is required for data that is
  sensitive, requires confidentiality, has a high
  value, or would expose NASA to legal liability,
  criminal sanction, or embarrassment in any way if
  the information were compromised.

84
Architecture Recommendation Development
Environment
Presented By Scott Robinson
85
Architecture Recommendation
Open Server
Closed Server
Data Server
RAID
Switch
Switch
Heartbeat LANs
Heartbeat LANs
Heartbeat LANs
Open IONET
Closed IONET
RAID
Open Server
Closed Server
Data Server
RAID Network
Inter-segment Network
86
Architecture Recommendation (cont)

• Rack mountable servers and peripherals
• Shared monitors, mice, and keyboards with KVM
  switches
• Dual 64-bit processor capability for each server
• 10/100 Mbps Ethernet for external and heartbeat
  LANs
• Gigabit Ethernet for Inter-segment Network
• RAID Network (TBD) either Fiber Channel or iSCSI
  (Copper)
• Tape drives (TBD) either one drive per server or
  shared network tape drives
• Supports active/passive and active/active
  clustering

87
Development Environment - Hardware

• 3 HP Server Systems
• Configurable-HP ProLiant DL145 AMD Opteron -
  SCSI Rack Model Server
• AMD Opteron Model 242 (1.6GHz/1MB) processor
• 1GB of Advanced ECC PC2700 DDR SDRAM DIMM Memory
  Kit (2 x 512 MB)
• Dual Channel Ultra 320 SCSI HBA
• HP 36.4GB Ultra320 Non-Hot Plug 15,000 rpm (1")
  Hard Drive
• 16X DVD-ROM Drive
• Two (2) integrated Broadcom 5704 10/100/1000
  Ethernet NICs w/WOL and PXE support
• 500W power supply (non-hot plug, auto-switching)
• 6 HP Workstations
• Same as above except in Tower Model

88
Development Environment - Software

• UPS and SWSI Code analyzers for mapping current
  logic and reverse engineering
• Understand for C
• Understand for Java
• With Class 2000 Professional
• GUI Builders and Code outline generators
• JBuilder
• Eclipse
• With Class 2000 Professional
• Configuration Management
• Concurrent Versioning System (TBR)
• Red Hat Enterprise Linux AS Standard (AMD64/Intel
  EM64T)

89
SNAS Software Size Estimate
Presented By Chii-der Luo
90
SWSI Software Reuse Analysis

• Client
• All SWSI Client code written in Java
• Over 92 of SWSI Client code reusable
• About 3,260 lines of new DSI to be developed for
  SNAS Client
• Server
• SNIF logic will be reused and code implemented in
  Java for SNAS
• Remaining SWSI Server code is written in Java
  language
• Reuse percentage 70
• About 39,130 lines of new DSI necessary for SNAS
  Servers, including SNIF rewrite

91
UPS Software Reuse Analysis

• UPS GUI was developed with TAE and will not be
  reused
• Majority of remaining UPS code is in C
  programming language
• Major subsystem logic reuse
• Recurrent Scheduling
• Orbital Data Processing
• Electronic User
• User Input Validation
• About 67,910 lines of new Java DSI to be written
  for implementing select UPS functions on SNAS

92
SNAS Software Size Estimate

• SNAS GUI will be written in Java with an
  estimated size of about 64,020 DSI
• Software tools such as Eclipse and JBuilder will
  be used to build GUI graphics
• Estimated SNAS software size
• 3,260 from SWSI Client (SNAS Client)
• 39,130 from SWSI Server (SNAS Servers)
• 67,910 from UPS (SNAS Client Servers)
• 64,020 SNAS GUI
• 95,130 Reused SWSI code
• --------------------------------------------------
  ----------
• 269,450 SNAS Software DSI

New Code
93
Development Resource Estimate

• Estimation COCOMO II Post-Architecture model
• Software size used in the calculation 142,310
  lines of new DSI
• Range of effort in person-month (PM) 223 to 349

Transition
FTE
Code
CDR
Design
Test
94
Risks Mitigation
Presented By Dave Warren
95
Risks Mitigation (1 of 6)

• SNAS Risk Type Risks Severity Range
• Customer Support Related 6 Low - High
• DAS 2 Med - High
• Mgmt 1 Low
• Security 2 Low
• System 3 Low

96
Risks Mitigation (2 of 6)
SNAS Risk Classification Chart
3
6
11
5
Note