1 / 64

Space Network (SN) Access System (SNAS) Customer Interface Meeting #12

Space Network (SN) Access System (SNAS) Customer Interface Meeting #12. March 10, 2011. Agenda. Project Status Release 4 Summary MOC Client Changes Common User Issues O&M Client Changes Backup Slides – Release 4 Details (W/L, DR, IDR, Bug). Project Status. Milestones. SNAS Release 4

eze
Télécharger la présentation

Space Network (SN) Access System (SNAS) Customer Interface Meeting #12

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Space Network (SN)Access System (SNAS) Customer Interface Meeting #12 March 10, 2011

  2. Agenda • Project Status • Release 4 Summary • MOC Client Changes • Common User Issues • O&M Client Changes Backup Slides – Release 4 Details (W/L, DR, IDR, Bug)

  3. Project Status

  4. Milestones • SNAS Release 4 • System / Beta Testing 6/10 – 11/29/10 • TRR 08/10/10 • Acceptance Testing 08/16/10 - 01/10/11 • Customer Interface Meeting #12 today • ORR 03/03/11 • Transition to operations 03/10/11 1900-2400Z • SNAS Release 5 • SNAS transitioning from NENS to SCNS support at GSFC & WSC • ITT has had involvement with the SNAS project since its inception

  5. Documentation • System Requirements Doc. (DCN 004) CCB approved (12/22/10) • Operations Concept Doc. (DCN 003)CCB approved (2/18/09) • ICD between DAS/SNAS CCB approved (6/03/06) • ICD between EPS/SNAS (DCN 002) CCB approved (12/22/10) • ICD between SN/CSM (DCN 003) CCB approved (3/04/10) • Security Documentation 452 approved (10/29/07) • Acceptance Test Plan (Release 4) Final, 10/20/10 • MOC Client Users Guide Rel. 4 Client (12/16/10) • O&M Client Users Guide Rel. 4 Client (12/26/10) • Server Operators Guide 2/15/11

  6. Current Beta and WSC Versions • Release 4.0 (10.2) • Resident on • WSC OPS servers connected to NCC & DAS – 03/10/11 • WSC EIF servers connected to ANCC (& HMD DAS) – 12/06/10 • Beta OPS servers connected to ANCC –(after WSC OPS update) • Beta EIF servers connected to ANCC - 12/03/10 • 10.2.1 to be available for RXTE/TRMM MOC Client • Release 4 has been tested on Redhat Linux, Windows XP, Mac OS (Snow Leopard 64b)

  7. Current WSC Configuration

  8. Customer Community Status • Operational Projects using SNAS • 33 Projects (39 SICs) registered on WSC Operational (OPS) server • NCC users • AIM, ALOS, ATV, EO-1, GALEX, GLORY, HST, HTV, ISS, LSAT, NPOESS, OCO, RBSP, SDO, SORCE, SPTR-2, THEMIS, TIMED, WISE • DAS users • 1K-ETE, DAS test • NCC & DAS users • CNOFS, ETE / SHADOW, FGST, LDBP, SWIFT • Interim missions (launch vehicles) • ATLAS, Delta, DRAGON, H-IIA, Minotaur, P3, SeaLaunch • Beta Testing • 39 Projects (45 SICs, 173 users) configured on EIF server • Most active projects: TRMM, RXTE, GPM, HST, JSC

  9. Release 4 Summary

  10. Release 4 Stats (1 of 2) • Candidate.0 (installed on Beta EIF on 7/06) • 9 Wishlist enhancements (21,49,66,67,69,70,81,82,84) • 13 Operational Discrepancy fixes on Release 3 reported problems • 4 Interim Discrepancy fixes reported during final Release 3 AT • 59 Bugs • Candidate.1 (installed on Beta EIF on 8/04 and WSC EIF on 8/16) • 3 Wishlist enhancements (35,64,85) • 6 Operational Discrepancy fixes on Release 3 reported problems • 15 Bugs • Candidate.2 (installed on Beta and WSC EIF on 9/02) • 2 Wishlist enhancements (64,77) • 3 Operational Discrepancy fixes on Release 3 reported problems • 12 Interim Discrepancy fixes from candidate.1 Beta & WSC testing • 18 Bugs

  11. Release 4 Stats (2 of 2) • Candidate.3 (installed on Beta EIF on 10/11 and WSC EIF on 10/12) • 3 Wishlist enhancements (62,72,87) • 2 Operational Discrepancy fixes on Release 3 reported problems • 15 Interim Discrepancy fixes from candidate.2 Beta & WSC testing • 16 Bugs • Candidate.4 (installed on Beta EIF on 11/11 and WSC EIF on 11/12) • 3 Operational Discrepancy fixes on Release 3 reported problems • 12 Interim Discrepancy fixes from candidate.3 Beta & WSC testing • 5 Bugs • Candidate.5 (installed on Beta EIF on 12/03 and WSC EIF on 12/06) • 5 Interim Discrepancy fixes from candidate.4 WSC Acceptance Testing • 4 Bugs

  12. MOC Client Changes client.prop file Orbital Data Prep TSW Processing TUTs, TSWs and Graphical Timeline Bulk SAR Control and Change Recreate USMs Reports and Queries EPS Processing TCP/IP Processing

  13. client.prop file changes (1 of 3) • Determines If, When and Where TUT files are updated #################################### ## Hourly TUT Retrieval Properties## #################################### HourlyTutActivated : true HourlyTutDirName : ./hourlyTut HourlyTutFilePrefix : tut HourlyTutFileExt : tut #time (in seconds) delay in between checking the property value for HourlyTutActivated HourlyTutActCheckInterv : 360

  14. client.prop file changes (2 of 3) • #################################### • ## Auto Recreate USM Properties## • #################################### • # AutoUsm - Turns on/off the auto feature for recreating USMs. • # Note:EPS FTP should also be enabled for this to be turned on. • # AutoUsmDur - The duration of time period for which USMs will be recreated. • # The duration will be subtracted from the stop time of the latest USM found in DB to • # get the start time of the time period. Stop time of the time period is the stop time • # of the latest USM found in DB. Units are seconds. (21 days is 1814400 seconds) • # AutoUsmDirName - The dir in which the files containing the USMs will be written • #AutoUsmFilePrefix - the prefix for the file name containing USMs. File name will consist of • # prefix plus time stamp plus file extension • #AutoUsmFileExt - The extension for the file name containing USMs. • #AutoUsmSic - the SIC for which the USMs will be re-created. • AutoUsm : true • AutoUsmDirName : ./autoUsm • AutoUsmFilePrefix : usm • AutoUsmFileExt : cfm • AutoUsmDur : 1814400 • AutoUsmSic : 0000

  15. client.prop file changes (3 of 3) • ########################################################################### • ## EPS (TCP Alternative) Properties (total: 13 parameters only) ## • ########################################################################### • # EnableEpsTcpIp - enable the EPS TCP/IP option • EnableEpsTcpIp : false • # MocLocalHostName - the host name that EPS TCP node uses to connect to MOC client • MocLocalHostName : localhost • # EnableSchedulingServices - enable the NCC scheduling service connections on ports: • # {SchReqSvcPort, SchStatusSvcPort, AcqStoreSvcPort, TswStoreSvcPort}. • EnableSchedulingServices : false • # EnableRealtimeServices - enable the NCC realtime service connections on ports: {PmDataSvcPort, ReconfigSvcPort}. • EnableRealtimeServices : false • # SchReqSvcPort - NCC SchReq Service port that EPS TCP node uses to connect to MOC client • SchReqSvcPort : 35101 • # SchStatusSvcPort - NCC SchStatus Service port that EPS TCP node uses to connect to MOC client • SchStatusSvcPort : 35102 • # PmDataSvcPort - NCC PmData Service port that EPS TCP node uses to connect to MOC client • PmDataSvcPort : 35103 • # ReconfigSvcPort - NCC Reconfig Service port that EPS TCP node uses to connect to MOC client • ReconfigSvcPort : 35104 • # AcqStoreSvcPort - NCC AcqStore Service port that EPS TCP node uses to connect to MOC client • AcqStoreSvcPort : 35105 • # TswStoreSvcPort - NCC TswStore Service port that EPS TCP node uses to connect to MOC client • TswStoreSvcPort : 35106 • # ReportPort - Report Service port that EPS TCP node uses to connect to MOC client • ReportPort : 35107

  16. MOC Managers need to setup initial data used by other panels – Orbital Data Processing, Recurrent Scheduling, SAR creation Orbital Data Processing - S/C Characteristics

  17. Orbital Data Processing - Default Sched Parms Default parameters are used during interactive scheduling Times set on SAR panel for plus/minus tolerances, freeze interval, etc. Flags for time types, use of TSWs, Day/night shading on Timeline, etc.

  18. Orbital Data processing can use PSATs only,  or both PSATs and UAVs to create TSWs Orbital products also include Day/Night Shading for the Graphical timeline Orbital Data Processing

  19. TSWs that are imported manually will not be automatically transmitted after ingestion TSW Processing (1 of 3)

  20. TSWs are saved to the SNAS DB, allowing user to verify them in the TSW Summary panel prior to transmission or deletion TSW Processing (2 of 3)

  21. After transmitting TSWs, the user can view what was submitted TSW Processing (3 of 3)

  22. TUTs, TSWs & Graphical Timeline (1 of 7) • Bringing up the Graphical Timeline, the User enters the start and stop times and selects the TDRSs, SUPIDENs, and TUT services and type of SAR status to display

  23. Identifying the TUT services around TSWs the user can start building SARs Note new Tolerance removal button added (on Active Event Summary SAR panel also) TUTs, TSWs & Graphical Timeline (2 of 7)

  24. All SAR panels now have an option to set the event stop time thus ‘clipping’ the service times extending beyond the new event stop time TUTs, TSWs & Graphical Timeline (3 of 7)

  25. Or to truncate the durations of all services for the SAR TUTs, TSWs & Graphical Timeline (4 of 7)

  26. TUTs, TSWs & Graphical Timeline (5 of 7) • SAR coloring results in their state changes • initial SAR state was Timeline Saved, but after transmission NCC rejected SAR as seen in the Alert Stream panel

  27. TUTs, TSWs & Graphical Timeline (6 of 7) • After Cloning the rejected SAR and removing the MA services (thus fixing out-of-order SSAF service), try resending

  28. TUTs, TSWs & Graphical Timeline (7 of 7) • After Cloning the rejected SARs a couple of times the Timeline shows that multiple (rejected) SARs for the same period exist (this one will be rejected for incorrect nominal start time of initial service)

  29. SAR Panel Display • The SAR panel has been standardized across all instances in the MOC Client application (i.e. Schedule Request and Active Event Summary panels, Graphical Timeline, etc.) • Users are now able to display the maximum (16) number of services without having to scroll up and down

  30. If you find that all SARs are in error during an import of a Bulk SAR file, first try the other option Bulk SAR Control & Change (1 of 6)

  31. Selecting Save to DB, SARs will be stored only to SNAS DB and are not transmitted to the NCC Bulk SAR Control & Change (2 of 6)

  32. Activating the Bulk Modify panel will display the SUPIDENs and TDRSs of available SARs for the specified time period SARs will be filtered based on the SUPIDEN / TDRS selection Selecting a Modification Criteria tab and then a group of SARs, the SARs will change when the Modify button is clicked Bulk SAR Control & Change (3 of 6)

  33. Using the Multiple Stored Only option, the user can submit a selection of SARs to transmit to the NCC Bulk SAR Control & Change (4 of 6)

  34. Activating the Schedule Request Summary panel using the filter, the user can review the status of any generated SAR (be mindful that an SDR, WLR, RADR, PBKR, PBKMR, or PBKDR might not be displayed based on the Time Criteria selected on the filter) Bulk SAR Control & Change (5 of 6)

  35. Using the Active Events Summary panel, the user can now Clone events and use the same time modifications Also the stop time for events no longer include any tolerances Bulk SAR Control & Change (6 of 6)

  36. With the Recreate USM option, the user can regenerate a confirmed events message file for the time period selected and its destination to the EPS export folders Recreate USMs

  37. A Confirmed Events Listing and Report can be generated and printed using the resulting display panel the font size selection is the first option s part of the print enhancements Reports and Queries (1 of 3)

  38. Additional print options are now available through the system’s Printer capability Reports and Queries (2 of 3)

  39. After choosing selections from the previous Print options and designating a file location, name and type, the report file is generated and saved (if no printer is available) Reports and Queries (3 of 3)

  40. watch folder sizes and keep them to a minimum because system will possibly lock up until files are deleted Files to watch : Client log files (~10M each), alert logs (70K each), Hourly TUT files, UPDs (7K), USMs Export files if Nodes are setup to receive files (UPDs (4K), USMs, SRMs (1K), etc) EPS Processing

  41. TCP/IP Processing (1 of 5) • Basic info • 7 Ports: 6 of them match NCC ports (see slide • Report port is new for Release 4 • Users can connect to any port multiple times simultaneously • Users don’t need to run multiple MOC Clients • Data encoding • Data sent by EPS application to a port must be XDR-encoded, and returning data must be XDR-decoded by the EPS application • XDR encoding is vaguely defined in the ICD SN/CSM • Check Alert Stream and/or client log for error messages and possible exceptions if things don’t work (e.g., if doesn’t look like message got sent) • Not all errors are sent to the alert stream, but will show in the log • Some validation of messages through EPS TCP/IP - some message types have more validation than others

  42. TCP/IP Processing (2 of 5) • Procedure for basic scheduling • Connect to SchStatus port, send SRR for SUPIDENs that you want SRMs and USMs for • Connect to SchReq port, send SARs, RRs, ASARs or SDRs • Wait for SRMs and USMs on SchStatus port • SchStatus, PmData, Reconfig, and Report are two-way ports - for sent data, responses will come back on the same port • SchReq, AcqStore, TswStore are one-way ports - if data is sent on these ports, nothing is sent back (except CTM which can be sent on any port and will be echoed). • SRR/UPDR • SRR and UPDR username/password and SRR logical destination are ignored • For SRR, user can specify ‘000’ to use “all SUPIDENs for logged-in SICs”, or can specify individual SUPIDENs • A user can send SUPIDENs for different SICs at the same time, and don’t have to use all SUPIDENs for a SIC (a user can choose only A0372MS, and ignore A0372EE). • For UPDR, a single SUPIDEN is equivalent to all SUPIDENs for the same SIC • User can disable receipt of UPDs (and AFN/TTM/RCTDM) using the last character of the message (see ICD), without disconnecting from port • for SRRs, there is no “enable”/“disable” in the ICD format, so users must completely disconnect from the SchStatus port to disable receipt of SRMs/USMs

  43. TCP/IP Processing (3 of 5) • TCP/IP Messages all start with “[EPS-TCP]” • [EPS-TCP] Sent to server: details of message (SAR or other Schedule Request, StateVector, TSW) sent to SAM • [EPS-TCP] Status Notification: equivalent of Return Receipt. • [EPS-TCP] DBStatus: when there is a database conflict because the user chose a duplicate ID. • Depending on data type, SvE may or may not delete the old data and replace it with new data. • Client-side [EPS-TCP] warnings: • user uses the same ID in the same session • these relate to duplicate keys in the table that EPS TCP uses to track whether a return receipt has been received, so that it can re-send the data if it doesn’t receive a response. • Client-side [EPS TCP] error messages: • when a message validation fails

  44. TCP/IP Processing (4 of 5)

  45. TCP/IP Processing (5 of 5) • Alert Stream • 22:21:23 Sent a SAR #5222222 • 22:21:34 Sent a State Vector #188877 • 22:21:50 Sent the same SAR twice (same ID) • Message at 22:21:49 shows first copy was SAVED. Yellow message shows that client couldn’t keep track of second copy (duplicate ID)—so, if no response were received, client wouldn’t resend the second copy • 22:21:51 Red message warning that second copy was a duplicate of a Transmitted SAR, so SvE couldn’t save the second copy (it was dropped). For duplicate of Invalid SAR, for example, SvE would remove the old one and send the new one. SvE can also delete old state vectors or TSW messages, depending on status • 22:21:51 Yellow message warning that response was received that didn’t match tracking (this was response for second copy) • 22:22:09 Sent TSW message #1236655 • 22:22:51 Sent TSW message that was truncated. Client didn’t send to SAM. • 22:24:34 Sent SAR message with wrong number of keywords (specified 3, but only included 2). Client didn’t send to SAM

  46. MOC Client – TDRSS Payload Status

  47. Each failed attempt will up the failure count for Userid and IP address just like logins MOC Client – Switch User Notification

  48. O&M Client Changes Delete User / Add AllSicUser HA Control IP Addresses and Activity Logging TDRSS Status

  49. O&M Client – Delete User & All SIC user Adding an AllSIC user is strictly for SN operations to view customers and take action or alert support to fix issue Saves O&M DBA multiple steps and time Deletion User by O&M DBA expedites process when users no longer active and when a mission is terminated

  50. O&M Client – HA control New HA control allows O&M personnel to remotely view and reset any of the SNAS processes / servers when not physically in area

More Related