Skip to main content

MockFM

MockFM is a ground-side service Spire can provide its Space Services customers. As the name implies, it involves the deployment of one or more virtual satellites (mock Flight Models) so that customers can familiarize themselves with the Tasking API and the process of interacting with space assets without requiring any flight hardware to be ready.

In the background, Spire systems treat MockFMs as if they were assets deployed in orbit, making them available for tasking and management through the Tasking API and providing them with a realistic (not necessarily representative of any real mission) contact schedule.

Available Tasking API endpoints​

The following Tasking API endpoints are supported by MockFMs:

  • GET /satellites - Find out which satellites and which payload window types you are authorized to task.
  • GET /availability - Find out when the satellite is available to execute a payload window.
  • POST /window - Request that a payload window be added to the schedule of a satellite.
  • GET /windows - List the windows that have been requested and their synchronization status.
  • DELETE /window - Request the deletion of a window from the satellite's schedule.

Details about each Tasking API endpoint can be found on the API Endpoints page.

Using GET /satellites with MockFMs​

It is useful to begin testing with the GET /satellites endpoint to check access to the API. This endpoint also reports the NORAD ID of satellites. The NORAD ID can be used with Spire's TLE server to obtain the latest orbit characteristics of the satellite in the form of a TLE file, e.g. https://sea-public.spire.sh/40044. The TLE file can then be used with a library such as pypredict to propagate the orbit.

Using GET /availability with MockFMs​

Customers should use this endpoint to check which periods are available for scheduling payload windows. The Mock FM will have periods of its schedule that are unavailable for tasking, the same as a real satellite. Spire recommends posting windows as far ahead of their start time as possible in order to guarantee availability. Additionally, just as in the case of a real satellite, the immediate future (normally a period of 0-6 hours) will be unavailable for tasking, since it does not contain any opportunity to update the schedule on board the satellite.

Using POST /window with MockFMs​

Customers can use this endpoint to request payload windows of the type allowed by Spire on their MockFMs (see Using /GET satellites above). For production operations another window type may be required (details of this will be made available in your Customer Information Pack) but the general methodology of window management will not change. See the POST /window API Endpoint page for details.

NOTE: MockFMs only simulate the process of synchronizing a scheduled payload window with a satellite, and not the actual operation of the payload window. No payload window logic will be executed and no output will be produced. Spire provides other means of payload window testing.

Using GET /windows with MockFMs​

The primary use of GET /windows is to check on the synchronization status of windows that have been added to the schedule. As on a real satellite, the MockFM's windows will initially be in the PENDING_SYNC state which indicates that they have not yet been communicated to the satellite. After a period normally around 0-6 hours, the window should transition to the SYNCED state which indicates that the satellite on-board schedule has been updated with the window. For real satellites, it cannot be guaranteed that this synchronization happens before the window start time, which means that the window will not run. The GET /windows endpoint can also be used to check whether window deletion requests (see below) have been enacted on the satellite.

Using DELETE /window with MockFMs​

Customers can use this endpoint to request the deletion of a window from the schedule, as long as there will be an opportunity to update the satellite. This request will immediately free up the window's period in the schedule, so that a new window can be posted in its place, e.g. with revised parameters. Initially the deleted window will be in the PENDING_DELETION state. Once the request has been communicated to the satellite, the window will no longer appear in the response to GET /windows and the window will not be run. It is possible that desynchronization does not complete before the window start time, in which case the window will run.

Uploads​

While the Tasking API does accept uploads to MockFMs through the POST /upload endpoint, the MockFM service currently does not support simulating upload progress, so uploads will not advance.

NORAD IDs​

In order to simulate a satellite orbiting Earth, Spire will assign MockFMs a NORAD ID from an existing orbital asset. If you have questions or particular requirements regarding which NORAD IDs are assigned to your MockFMs, please contact your Spire representative.

Limitations of MockFMs​

MockFMs serve a specific purpose in a Spire Space Services customer's journey: familiarization with the Tasking API ahead of any satellite hardware being available, as such, the system does not provide any means of:

  • Processing file uploads - As mentioned above, uploads to MockFMs are not currently used in any way
  • Executing payload window logic - As no satellite hardware or emulation is being employed, MockFMs do not execute any payload window logic
  • Generating output - No output is being generated for any payload window scheduled on a MockFM
  • Simulating failure modes - In a real environment a number of factors can influence the likelihood of a payload window being successfully synchronized and executed, these factors are not replicated in MockFMs