1 / 29

Gamma-ray Large Area Space Telescope

Gamma-ray Large Area Space Telescope. GLAST Large Area Telescope: Instrument Science Operations Center CDR Section 7 RFA Status Lori Bator ONE-SLAC lbator@slac.stanford.edu 650-926-5352. RFA 1 – Management Plan, Documentation, Schedule. Specific Request – Part 1

matthias-xylon
Download Presentation

Gamma-ray Large Area Space Telescope

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. Gamma-ray Large Area Space Telescope GLAST Large Area Telescope: Instrument Science Operations Center CDR Section 7 RFA Status Lori Bator ONE-SLAC lbator@slac.stanford.edu 650-926-5352

  2. RFA 1 – Management Plan, Documentation, Schedule • Specific Request – Part 1 • Need to provide more information on the overall ISOC Management Plan and Approach • Response – Part 1 • Completed ISOC Management and Development Plan • Specific Request – Part 2 • What is the complete ISOC Documentation Set and associate schedules • Response – Part 2 • List of all ISOC documentation is on ISOC website as well as included in section 8 • Schedule is provided in section 8 • Status • Closed

  3. RFA 2 – Functional Block Diagram (1/6) • Specific Request: • Need an overall functional block diagram illustrating the functional capabilities and a data flow diagram showing the various data flows, with the differences among the I&T (pre-launch w/GSE) phase, L&EO phase, and nominal on-orbit phase configurations specified • Diagrams for each phase might be needed • Response • See the following slides • Status • Closed

  4. RFA 2 –Functional Block Diagram (2/6) ISOC Dataflow During I&T Single Tower Testing • Obtain data during I&T EM2 testing • Goal is to read housekeeping data off flat file produced by Online • Database development and maintenance is shared between I&T and ISOC

  5. RFA 2 – Functional Block Diagram (3/6) ISOC Dataflow During I&T Multi-Tower Testing • Obtain data during I&T testing • Increase ISOC functionality

  6. RFA 2 – Functional Block Diagram (4/6) ISOC Dataflow with TestBed - Direct to SIU • Direct interface with SIU for CCSDS command and telemetry packets • Obtain testbed simulated data via SIU • Demonstration of ISOC capability increases as functionality is developed

  7. RFA 2 – Functional Block Diagram (5/6) ISOC Dataflow with TestBed - With SIIS • Interface with SIIS for telemetry packets and commanding • Obtain testbed simulated data via SIU and SIIS • Demonstration of ISOC capability increases as functionality is developed

  8. RFA 2 – Functional Block Diagram (6/6) ISOC Dataflow During GRTs, L&EO and On-orbit • Shows full ISOC capability for L&EO and On-orbit • GRTs will test capabilities as they are available

  9. RFA 3 – Risk Analysis • Specific Request • Recommend a Risk Analysis be performed for the ISOC (development/test oriented). • A Risk Analysis exercise would greatly assist all elements in understanding major issues, concerns, and problems • Response • Process • Discussion with I&T personnel on risks • Internal discussion performed in concert with RFA’s from peer review • Review and approval by ISOC stakeholders • Follow up • Entry into LAT risk management database by 06/01/04 • Weekly tracking, updating by ISOC management • Status • Closed

  10. RFA 4 – Date of ISOC CDR • Specific Request • The current CDR date of May 2004 is not realistic, particularly given the shortage of key personnel on the ISOC development/design team and the lack of a defined telemetry and command system. • Be sure to coordinate with the rest of the ground system team to work around other element design reviews that will be occurring prior to the GSDR. • Response • ISOC CDR scheduled for August 4, 2004, which is after the MOC and GSSC detailed design reviews and before the GSDR. • Status • Closed

  11. RFA 5 – Level III Requirements • Specific Request • The detailed (Level III) requirements for the LOF and SOG are not yet completed. These are critical to getting the ISOC detailed design done. And it will not be possible to properly evaluate the design without these being mature. Need to get these done ASAP. • Response • ISOC Subsystem Specification (LAT-SS-00021) updated and reviewed by GSFC • Status • Closed

  12. RFA 6 – Staffing Plan and Profile (1/3) • Specific Request • Need to provide more information on the planned and actual staffing profiles • Identify which areas that are needed now are not filled, what is being done to fill them, and their role in being able to prepare for the ISOC CDR • The ground software engineer for example would seem to be a prerequisite for preparing for the CDR, let alone actually conducting it • Would also seem to need a test engineer • Response • Staffing plan as shown in section 8 • Status • Closed

  13. RFA 7 – Report Generation and Usage (1/2) • Specific Request • Better define and document the types of reports that will be generated by the ISOC for both internal use and for use by external systems (like the MOC and GSSC) • Include those needed to document instrument performance, status, & analysis (probably covered in an MOA), and those needed to report status, quality, etc. of data processing/transmission (covered in the Data Products ICDs) • Also be sure to address reports you expect to get from the GSSC and MOC and if they are read by people or processed by software • Response • Reports defined in Section 5 • Status • Closed

  14. RFA 8 – Command & Control System Definition • RFA 8 Specific Request: • ISOC does not yet know what system it is using to process Observatory Housekeeping Data or perform the commanding • Response • ISOC command and control system will be a hybrid of ITOS and software developed at SLAC • Covered in section 3.1 of this CDR presentation • Status • Closed

  15. RFA 9 – Lessons Learned • Specific Request • Need to describe results of Lessons Learned efforts at the ISOC CDR. Recommend focus be on using these efforts to analyze comparative ISOC complexity and staffing approach/profile • Response • Members of the ad hoc planning group for the definition of the LAT IOC (now ISOC) made visits to the operations centers for GP- B, RHESSI, and Chandra • LAT ISOC can learn from others but there are no direct models • Co-location important to maximize science • Testbed important for flight software updates • Co-location important to keep all science members in the loop • Status • Closed

  16. RFA 10 – ISOC Validation with LAT • Specific Request • Not clear that the ISOC plans to interact with the instrument during Instrument I&T • ISOC should have verification milestones with LAT instrument, at least, during environmental tests. • ISOC should have significant participation in S/C integration activities at Spectrum Astro • Response • We will be working with I&T during instrument integration and expect to do testing with the instrument during instrument level environmental testing at NRL in advance of our operational readiness at observatory level I&T. • As the I&T schedule is necessarily constrained, most of the developmental testing will be done with the LAT testbed which provides an accurate, and available, surrogate. • Development schedule in section 8 shows • Verification milestones • Test activity at NRL • Participation in integration activities at Spectrum • Status • Closed

  17. RFA 11- LAT Modes (1/2) • Specific Request • The LAT Operations Team and Spectrum Astro should work together to verify if any interactions between LAT modes and spacecraft modes need to occur. For example, if a LAT mode change requires the spacecraft to change spacecraft mode and/or configuration. • Response • Identified and confirmed LAT modes with FSW • Except for autonomous repoint requests, LAT mode changes do not drive spacecraft changes • Status • Submitted

  18. RFA 11 – LAT Modes (2/2)

  19. RFA 12 – EEPROM Write Cycles • Specific Request • EEPROMs have a limited number of write cycles before they become unreliable. It is not clear that the operations concept/plan factors in this limitation. Understand the number of writes to EEPROM on LAT from all sources • Response • The number of EEPROM writes is not an issue using the TrueFlash File System (TFFS) overlay • TFFS counts the writes to each sector of the file system underneath and will move files around to even the wear across all sectors • At 100 kByte a day, 5Gbyte would last 50,000 days or approximately 150 years • If TFFS is not used, ISOC will work with FSW to develop an operations plan to manage EEPROM writes • Status • Closed

  20. RFA 13 – Detailed Development Schedule • Specific Request • No development schedules were provided (at Peer Review) to enable the Review Board to determine overall “maturity” of LIOC design and whether it can meet its scheduled CDR date (late May 2004) • Provide detailed ISOC development/test schedules and solicit Review Board feedback • Response • Prepared development schedule • Covered in section 8 of this review • Status • Closed

  21. RFA 14 – Data Storage Agreements • Specific Request • LAT should enter a more formal agreement with SLAC management on required data storage and processing requirements • LAT should clearly identify its average and peak needs • SLAC management should commit a base capability • Response • Estimate of processing and data storage requirements performed for SAS by R. DuBois • Cost determined and built into ISOC out-year funding plan and accepted by SLAC Director of Research • Database costs still being evaluated by database working group but now expected to be minimal or covered completely by SLAC central computing services due to small size (~ 1Tb) of database • Status • Closed

  22. RFA 15 – ISOC Org. and Comm. (1/2) • Specific Request • What problem are you solving by separating the ISOC into two organizations, LOF & SOG? • Recommendation: merge these two organizations into a single group with an experienced manager. • Also need to ensure that the ISOC ground/operations team and the Flight Software Team are coordinating and communicating where needed. It is critical that these two teams work together to ensure that the FSW design is consistent with the ISOC design and operations concepts. • Describe how this coordination is occurring, or if it’s not occurring adequately, describe and implement a plan ASAP for making it happen. Also, ensure that the relationship between the SOG and SAS is clear, understood, and documented.

  23. RFA 15 – ISOC Org. and Comm. (2/2) • Response • The current ISOC organization eliminates the LOF/SOG/SAS distinction • All requirements for monitoring housekeeping and on monitoring science data are on the ISOC as a group, not on individual functional units • The ISOC manager is ultimately responsible for all ISOC functions; he may choose to designate a manager to oversee some subset of these functions • The team leads of each of the functional units within the ISOC meet daily and are jointly responsible for successful operation of the instrument and the production of science data • The coordination between the ISOC and FSW has been improved significantly by scheduling weekly meetings between the ISOC and the FSW team to ensure that requirements are consistent and that assumptions about scenarios, modes and anomaly resolution are shared between the two teams • Status • Closed

  24. RFA 16 – Requirements on I&T and SAS (1/2) • Specific Request • The mechanism for ISOC requirements being placed on I&T and SAS is not obvious. • How do ISOC requirements get levied on I&T and SAS? • Does ISOC sign off on I&T and SAS specs and functional designs? • Response • Potential requirements are discussed at the regular working meetings now held between the staff of these two subsystems. If requirements are found that are not currently covered within the existing documents, a change is jointly proposed and the relevant documents are modified.

  25. RFA 16 – Requirements on I&T and SAS (2/2) • Response, continued • Where joint requirements were found, we have agreed to share personnel to execute them. Specific examples include: • We required I&T to fully document their calibration procedures for use during operations and we are now sharing a technical writer who is working with I&T and ISOC to ensure that the resultant documents meet requirements for both subsystems. • The ISOC also required that I&T data be consistent with ISOC needs. The ISOC is providing the database programmer needed by I&T and will thus ensure that the resultant database meets of the ISOC. • ISOC is involved in the development of all LAT Specs and functional designs. The ISOC manager is a signatory on all plans from the I&T and SAS subsystems. • Status • Closed

  26. RFA 17 – ISOC Tools • Specific Request • The tools needed to run the LOF/SOG need to be specified. • Which HK and science parameters will be monitored and in what way? • What actions would be taken based on the results seen with these tools? • How does the ISOC team know from a design perspective that the collection of the described I&T tools will function in the operations environment as an integrated system? • Need lists of which software tools are required to achieve the ISOC’s requirements are needed. • Response • ISOC tools have been identified – covered in section 5 • Status • Closed

  27. RFA 18 – Automation of Operations Software • Specific Request • Specify plans and requirements for automation of operations software, and describe the software design for how the automation needs will be met • Response • Level 3 requirements for autonomous operation have been specified (LAT-SS-0021-8) and these have been mapped to software elements. • Primary software components and data flows for autonomous operation of the ISOC discussed in section 5 • Status • Closed

  28. RFA 19 – Robustness of Operations Software • Specific Request • Specify plans and requirements to ensure that software, particularly that “inherited” from I&T, will be of sufficient robustness for operations use. • Response • Using ITOS for LAT health and safety operations • Other software tools • Using existing software where possible – identified in section 5 • Complete verification and validation process • Automated notification software tools • Status • Closed

  29. RFA 20 – Ground Element Involvement in LAT Operations • Specific Request • Specify what other ground system elements will be involved in LAT operations and what their roles and responsibilities will be • Response • Responsibilities of other ground elements in LAT operations are identified in the ISOC Operations Plan (LAT-SS-1378) and will also be documented in an Operations Agreement (to be written by the MOC) • MOC will be responsible for monitoring real-time and playback LAT housekeeping data against limits supplied by the ISOC and will notify ISOC of out-of-limit conditions and perform contingency procedures at the direction of the ISOC • MOC will notify ISOC when an Instrument Alert message is received that involves the LAT • Status • Closed

More Related