INTERNAL CALIBRATION PLANNING PROCEDURE

1. Add Calibration visits to the INTERNAL_CAL plan

   $ DO CREATE_CAL_LRP <cycle number>

   This tool identifies internal cal visits for the specified cycle which are not currently in the INTERNAL_CAL plan and creates a record in PLAN_WINDOW_STATUS.

   It also outputs the file INTERNAL_SUS.DAT which contains a list of all of the visits which are "notplanned" in LRP INTERNAL_CAL. The file includes a template for specifying the plan window begin/end times for each visit. This will be used in the next step of this procedure.

   Note:
   
   • Visits will not be selected if they already exist in the INTERNAL_CAL LRP or if su_track.lrp_state = "not_lrp_candidate".
   • By default, plan_window_status su_track history fields are set to the current values in su_track and plan_window_status.status is set to "notplanned".
   • To add new visits after the initial INTERNAL_CAL LRP is created, rerun the tool using the appropriate cycle #. Visits with existing records in INTERNAL_CAL are ignored.

2. Assign or update plan windows for Calibration visits in the INTERNAL_CAL plan
   

   Edit INTERNAL_SUS.DAT
   

   $ DO UPDATE_CAL_LRP
   

   This tool assigns plan windows for each visit which is listed in INTERNAL_SUS.DAT.
   Edit this file to:

   • remove entries for visits which you do not want to insert or update plan windows in ASSIST
     and to
   • specify the desired plan window start and end times for those visits which you do wish to insert or update in ASSIST.

   Example of the INTERNAL_SUS.DAT file produced in the previous step:
   0763508 yyyy.ddd:hh:mm:ss yyyy.ddd:hh:mm:ss
   0763509 yyyy.ddd:hh:mm:ss yyyy.ddd:hh:mm:ss
   

   Note:
   

   • Only one continuous plan window is allowed per visit.
   • the removal of visits from the plan will be controlled via the lrp_state flag for that visit. This ensures consistency between su_track and the LRP at least as often as the baseline LRP is updated.
   • This can be run at any time for a visit which has been put into the INTERNAL_CAL LRP using CREATE_CAL_LRP.

     	$ DO MERGE_CAL_LRP 
     
     	  Function: 
               - Visits in proposals which are "completed", "failed" or "withdrawn" or 
     	    have their su_track.status = "not_lrp_candidate" are deleted from 
                 LRP INTERNAL_CAL.
     	  - Statuses and execution time for visits are updated in LRP INTERNAL_CAL. 
     	  - LRP INTERNAL_CAL plan_window_status and plan_windows records are copied 
     	    to the current baseline LRP. 
     	  - This tool is normally run by the LRPG during the baseline process; 
     	    You may need to use this if the current baseline LRP absolutely must be 
     	    changed; i.e. - you can't wait until the next baseline LRP is created. 
     
     	  Inputs: none. 
     
     	  Output: DB update.
     	  .........................................................
     
     
     	Procedurally these tools are to be used in the order given above
     	with the following NOTES: 
     
     	1. You must set the su_track.lrp_state = "not_lrp_candidate" if you do not 
     	   want a visit to be included in the INTERNAL_CAL LRP. 
     
     	2. You must edit the INTERNAL_SUS.DAT file produced by CREATE_CAL_LRP to 
     	   update the begin/end times before running UPDATE_CAL_LRP. 
     	   FORMAT IS IMPORTANT! 
     
     	3. If a visit appears in this list which you do not want to be in the plan, 
     	   then you should set the lrp_state field to "not_lrp_candidate" and rerun
     	   CREATE_CAL_LRP. 
     
     	4. UPDATE_CAL_LRP updates the INTERNAL_CAL LRP. All plan window management
     	   will be done via this LRP which will conatin no history of changes. 
     	   However, the baseline LRP will contain a record of the status and 
     	   PW changes over time. 
     
     	5. The baseline LRP is created from the current RELEASED LRP ~once per week; 
     	   usually Friday afternoon or Monday morning depending on the calendar 
     	   building progress for that week. However, on occasion, such as holiday 
     	   weeks or unusual calendar building schedules, e.g. SMOV!, baselining can 
     	   occur earlier in the week. 
     
     	   Since the LRP baselining event is the signal to the calendar team that
     	   the LRP has been updated and candidate selection can begin for the next 
     	   week, it is important that PWs and statuses of all visits in the plan be 
     	   accurate at that time. You will be added to the distribution list for the
     	   baseline notification so that at least you will know when the baselining
     	   DID occur. 
     
     	   For the sake of simplifying the baseline process and interface to the 
     	   calibration LRP, we will assume that the INTERNAL_CAL LRP is current and 
     	   ready to be merged into the new baseline LRP. 
     
     	   This means that nominally any changes to the INTERNAL_CAL LRP should be
     	   completed by Friday morning. If for some reason you anticipate that changes 
     	   which absolutely must be included in the baseline for the next calendar
     	   week will not be implemented in the INTERNAL_CAL LRP by Friday, please inform 
     	   the LRPG via Email. 
     	   NOTE: I do not expect this to occur very often if at all. Once the CAL 
     	         plan has been created at the beginning of the cycle it usually does not 
     		 need to change so quickly that the baseline must be delayed to 
     		 acommodate it. 
     
     	6. If for some reason you must change the operational LRP AFTER it has been 
     	   baselined, please do the following:
     
     	   a. If the update will affect the calendar which is currently being built, 
     	      confer with that calendar team. Since they have probably already done 
     	      the candidate selection for that week, they will need to verify that 
     	      they can accomodate the change to the candidate list for that week. 
     
     	   b. For INTERNALs, $DO MERGE_CAL_LRP 
     
     	      This will update the current baseline LRP with any changes in LRP 
     	      INTERNAL_CAL. 
     
     	7. You will also have to keep an eye on the EXTERNAL CALs which are always 
     	   in the RELEASED and baselined LRP's. If their PWs must be changed in the 
     	   current baseline LRP then you or the PC must see the LRPG member assigned 
     	   to that proposal's PC to get the PW's updated in the baseline LRP as well
     	   as the appropriate calendar team. 
     
     	8. And finally the hardest part of the job! Identifying all the requirements 
     	   for each SI's calibration program as a whole as well as the individual 
     	   proposals in the program. Like we talked, it helps to have one PC 
     	   if possible to keep track of a particular SI's calibration program. But
     	   if that's not possible, then you'll have to have a handle on the BIG picture
     	   for each SI. Have the PC's put good concise scheduling requirements in the 
     	   SOGS history SCHED REQS if possible, especially for the proposal 
     	   interdependencies like in occurs frequently for WFII. This helps the 
     	   calendar builders tremendously. And of course, making sure the visits are 
     	   flight ready when they need to be. Again, the PC's should be on top of this, 
     	   but you'll need to monitor the situation from time to time. You'll need
     	   some reports to help with this. Maybe you, Michelle and I should get together
     	   to see what the LRPG has before you go to DBSA. No sense in duplicating effort.
     
     
     	For the LRPG, Merle says that there are no changes needed to the selection tools 
     	to handle the transition from QSCHED_POOL to the LRP for the internal calibrations.
     	As soon as we decide to proceed, I will talk to Dave about letting the builders
     	know that they'll find the internals in the LRP at that point. 
     
     
     	Everyone please review this document and the tools and let me know if you see any
     	problems.
     	
     	Thanks, 
     
     	Bill