Baselining an LRP
1. Check that latest calendar is in the LRP
2. In “weekly” directory, create difference and
main reports for analysis.
3. Resolve issues with changes using the diff
report. Items to look for include:
Proposals dropped between LRPs
PCs need to know this
After the LRP is baselined
Need it in an email
SUs dropped between LRPs
No one needs to know this
Redundant
SUs that lost PWs between LRPs
LRP needs to know only if ready and schedulable
Between Baselines
Need in a report
SUs picked up between LRPs
(Don’t have PWs)
PCs will be informed through the ANT tool
Should be included in the “sched & ready without
PW” report
(Do have PWs)
No one
Should all be schedulable and ready
SUs that gained PWs between LRPs
LRP needs to know
Between Baselines
Needs in a report (chronological order)
PCs will be informed through the ANT tool
Differences between statuses
PCs should get an email to inform them immediately
of any unorthodox changes.
SUs with changed flight ready dates
LRP needs to know
Should get a daily alert that Spike has moved a PW
(>~56 days)
PCs will be informed through the ANT tool
Difference between PWs
If needed, could be sent through the daily LRP alert
4. Resolve issues with resource levels and other
general items about the newly released lrp using
the main report. Items to look for include:
SUs with zero second PWs
LRP needs to know
Daily alert sent by email
SUs with pws.status=constraint or dropout
No one
SUs lrp ‘ready’ without PWs
LRP needs to know
Should be included in the “sched & ready without
PW” report
SUs with conflicting USCs
No one - PCs can investigate as unschedulables
SUs that do no have CWVs but are set to scheduling
No one - obsolete
SUs set to scheduling whose cwv.window_end <
pw.window_end
No one - obsolete
SUs with expired PWs
Stays in baselining as part of resource evaluation
5. Check on next building calendar.
Ensure there are an acceptable number of
mustgos. Check for conflicts such as overlapping small windows or too many SUs in a given
timeframe. Pay specific attention to MAMAs as
they are restricted to SAA-free orbits.
Should also check there are a sufficient
number of candidates available to the calendar
builders. The number should be in the mid-200s
(orbits) at least. Ensure a relatively useful mix of
visit types (short alignments, SAA-hiders, short/
long orbit visits).
Stays in baselining
6. SuperSNAP pool should be checked on.
PCs should be responsible for this.
Monthly email or SuperSNAP button.
7. If everything is fine with the LRP and you are
happy with changes, resource levels, etc, baseline the LRP.
8. Inform the calendar builders that the LRP has
been baselined and they can begin building the
calendar. Could also include in this email a list
of mustgos as well as any other warnings.
Automated in baselining
9. Baseline reports should be submitted to batch.
Some before and some after
10. Run ANT to inform PCs and PIs of major
changes to PWs. This tool does not need to be
run right away and could run the following day.
Should be automatic - run after baselining
11. Generate the OPM reports the following day.
LRP issue