Any satellite mission analysis and design activity requires a deep understanding of the requirements and a detailed modeling of the environmental conditions. One of most interesting support requests I’ve got was about a LEO satellite that, accordingly with the mission requirements, had to perform two kind of maneuvers:
- A Semi-Major Axis raising maneuver when its mean value falls below the minimum value (the satellite had to stay within a well-defined SMA interval) and
- An attitude change maneuver when the satellite is under ground station visibility for communication purposes
Even if those requirements went from different design areas (payload and communications) both of them have in common that they cannot be foreseen in advance. SMA decay depends from the atmospheric and solar flux models used and the ground station visibility intervals are even more ambiguous to calculate. This seems to be the classical chicken-egg problem: you need the access times to tell the MCS (Mission Control Sequence) to plan the attitude change sequence, but you cannot get the correct access times until you propagate all the attitude changes, since any time we change the satellite attitude we are going to change the force field acting on the satellite and, in turns, its position over time.
Requirement 1) can easily implemented just using Astrogator autosequences. An Autosequence is fired any time a particular condition is met, passing back the control to the main sequence when it run all segments in it. In this case we can create a Hohmann like transfer to raise the SMA as soon as it reached the minimum allowable value:
Requirement 2) needs a help from the Analysis Workbench to be implemented. The Workbench allows to create additional analytical components is STK that can be used in Astrogator. In particular we can create a scalar component that tells us when the satellite have access to the facility and we can use this condition to tell Astrogator when to fire the attitude change procedure, which has been implemented as Autosequence as well:
Here the steps followed to correctly solve for the attitude change during access:
- Start by propagating the satellite with its nominal attitude to get an ephemeris file that does not contain any attitude change;
- Perform an access calculation between the Facility and the Satellite and create the relevant scalar component whose value is 0 (no access) or 1 (access);
- Use this scalar component as data provider for a User Defined stopping condition. The trip value is set to 0.5 (between 0 and 1) – any time this threshold is reached (i.e. when the access starts/stops) the Attitude Change autosequence is launched;
- Enable the Attitude Change Autosequence and run the MCS again. This is triggered accordingly with the previously calculated access times (no attitude change), so in this run the attitude changes do not happen exactly during the access start/stop, since the satellite is now propagated by changing its cross sectional area. In a 60 days long scenario the access time mismatch is within 2 seconds, anyway.
- By having a new ephemeris set (with the attitude changes) it is now possible to update the access calculation made at step 2 and run the MCS again.
By iterating those steps a couple of time we can finally get the correct access times with attitude changes.