Procedures

M&TA Daily Procedures

This is a first cut at daily procedures for responsible (and other) scientists interested in AXAF subsystems.

  1. Start at the SOT HOME PAGE
  2. Go to Latest AXAF telemetry. (in general this will link to the last 24 hours worth of data)
  3. Go to Lastest AXAF photons -click to see the latest processed data.
  4. Click on your favorite highlighted subsystem and check the results.
    All should be green or blue = ok or unchecked
    nominally - you would then go an finish that paper you meant to do 6 months ago.
  5. in the case of event data, no automated errors get reported. To report an error email the following to mtadude@head-cfa.harvard.edu, cc swolk 
    *************************************** 
Problem ID:                   9XXXX
System ID:                      YOUR SYSTEM
Status:                         new   
Responsible Scientist: Dr. YOUR NAME 
Priority:                          3

text

**************************************
    or visit the problem tracking web site.
  6. If there were a detected anomoly follow the generic anomaly solving procedures. (long form)
  7. Anomaly procedures (short form):
    1. Call The flight con on the FOT and inform them of the problem 6-7041 PRIMARY POINT OF CONTATCT other contact numbers are listed here .
    2. Go to the OPS LAN look at the file using your favorite tool. Once you have done your preliminary analysis
    3. Rope others into helping
    4. Go to the problem tracker (via the SOT home page) fill in the appropriate boxes
      (P.S. this software is still under development I have a few pages of comments on it, your comments are welcome)
      (P.P.S. The problem tracker IS THE method for logging all SOT (ops) anomaly actions)
      • other assignees (entered by R.S)
      • analysis - (from assignees or RS)
      • proposed actions - (from assignees or RS)
      • comments on proposed actions- (from assignees or RS)
      • final action - (from assignees or RS)
      • date closed

GOT data request procedure:

  1. All requests should be made via email to ASCDSops, cc the GOT (account got, not to an individual account).

    The request will specify the following (ASCDSops will create a web page to facilitate):

  2. ASCDSops will verify that this request is unique (i.e. not one of 100 requests for the first 10 hours)
  3. ASCDSops will assess the availability of the data within the ascds archive and report to the requester (not to the GOT)
  4. ASCDSops will notify the request within 1 hour if the data are currently available.
  5. If delivery is not expected within 4 hours GOT will notify requester and ASCDSops of the ETA of data.
  6. Upon delivery GOT will notify ASCDSops and requester that data special request by "XXXX" has been sent to ascds and is in location /data/tlm/SR
  7. GOT will send All information required to recreate the data to ASCDSops.
  8. Upon reciept ASCDSops will confirm delivery via email to the GOT and the requester and will log the additional information for reproducability.

Change Control Board: (Proposed)

  • REQUIREMENTS:
    1. The ASCDS CCB is consituted to handle change requests to the OCC ODB, ASCDS telemetry decom and analysis reference data used in pipeline processing. To be effective, it is essentialy that information regarding what changes need to be requested through the ASCDS CCB be disseminated to all relevant persons, so that anybody who may need to request a change knows where to send the request. A standardized request form, including time priority, is required.
    2. The ASCDS CCB should receive/review all requests for changes to CCB configuration controlled components.
    3. The ASCDS CCB should receive/review copies of all Flight Director Board ODB changes from the OCC and determines whether corresponding changes are needed for ASCDS.
    4. The ASCDS CCB must be capable of handling requests on a range of time scales. Right now the CCWG meets every 2 weeks which is completely inadequate for the CCB. CCB must be capable of responding same day (within 24 hours) if necessary, and in critical cases within 3 hours. The latter may occur via CCB director (or designee) approval with report to next full CCB meeting.
    5. The change control board is used to implement changes To Analysis reference data or similar template data. This panel DOES NOT direct software development.
    6. SCIENCE APPROVAL IS REQUIRED BEFORE SUBMISSION
  • PROCESS:
    This is intended to follow a condensed version of flow through OCC CM

    1 - Request
    2 - Tracking
    3 - CCB APPROVAL
    4 - creation of altered file - by development or Science
    5 - Approval by science
    6 - implementation

    Possible membership:
    ASCDS JDP (software manager), and JSN (ops manager) and one CM representative
    ASC Science One member

    1. Request is made to committee via web (maintained by ascds) or via email to the whole committee:
      The email includes (following ddts) SOFTWARE TO BE CHANGED VERSION SHOWSTOPPER yes no ENHANCEMNET REQUEST yes no PROBLEM: IMPACT: REQUESTED TIMESCALE FOR IMPLIMENTATION: 24 hours, 3 days, 1 week, next patch
    2. ASCDS problem tracking logs this request on a web site similar to, but separate from bug, tracking. A Request # is assigned.
      1. The chair (or designate) can summarily approve the request and inform ASCDS to change the ARD as soon as possible. This is only meant to be used for the most urgent requests. In this case the chair will email the committee of this decision. and the committee must still approve the decision post facto.
        or
      2. If the chair chooses not to summarily approve the request then the chair calls for a meeting of the committee plus others as appropriate to make a decision (including group leaders, Scientists and flight ops staff), within the time frame requested.
    3. Result of CCB (Approved, denied (with justification) or returned for further information) is reported to requester and logged.
    4. If the request is approved The CCB will also indicate responsibility and time scale for implementation.
    5. Request status must be maintained (current!) from request until completion of action.
    6. The responsible party will report (to the logger and the requester) when the adjustment is in place on the OPS NET. The responsible party will also report any change of schedule to the logger and the requester. 
    
request matrix
 input - NAME                    output- APPROVAL 
         EMAIL                           TIMESCALE FOR IMPLEMENTATION
	 DATA TO BE CHANGED              RESPONSIBLE FOR IMPLEMENTATION
	 REASON FOR CHANGE               STATUS UPDATES
	 TIMESCALE OF REQUEST            CLOSURE DATE