User Guide
Last updated
Last updated
This guide supports those directly working within the Antaris Cloud Platform (ACP) to develop and operate satellites. Please use this document to learn about core platform concepts and workflows.
If you have any questions or comments, please contact the Antaris support team via email at .
ACP
Acronym for “Antaris Cloud Platform”
Design Studio
Section of ACP used to configure missions, satellites, and other resources
Tenant
Isolated space within ACP, typically scoped to a real world organization
User
Auth context used to represent a real person within ACP, scoped to a Tenant
Mission
Specific set of objectives for a satellite, including system scope and operational goals
Ground Station
Earth-based communications node that facilitates satellite operation
Satellite
Space vehicle that can be designed, tested, and operated within ACP
Bus
Set of satellite system components that support foundational operations, such as guidance, navigation, and power management
Bus Design
Template object in ACP representing a complete Bus and its individual components
Payload
Mission-specific device installed in a satellite along with its control software
SatOS™
Onboard software responsible for orchestrating satellite activities (i.e. the “operating system” of the satellite)
TrueTwin™
Technology that supports virtual satellite testing and simulation, as well as operator training
Task
Meaningful unit of work that a satellite may execute
Task Plan
Reusable template of satellite tasks, along with requirements such as geography and repetition
Scenario
Virtual sandbox constructed to test a satellite in a fully simulated space environment
This section describes the core satellite design process, which focuses primarily on satellite system architecture. Operational configuration and planning are addressed elsewhere.
From the DESIGN dashboard, simply click on the Create Satellite action. Give the Satellite a unique name and proceed on to the next step:
Unique Satellites may be created for many reasons, and users should feel free to use them to explore alternate design decisions. Each operational space vehicle in a constellation is represented by a unique Satellite object.
A satellite is defined primarily by the set of payloads intended to operate within it. This is critical input, as it defines the “load” to be supported by core satellite systems.
Iterate through the “Add Payload” process once for each desired payload. Components that support core system functions such as RF communication or power management are included in the satellite bus, which will come later in this process.
Selection of a payload category and subcategory allows ACP to provide more contextual filters that help identify the most appropriate Payload Device from the catalog.
The “Average Active Duration per Orbit” field helps calculate the power demand during a representative orbit. Similarly, the “Average Data Generated per Orbit” informs onboard data buffering and downlink bandwidth requirements.
If an appropriate Payload Device does not yet exist in the catalog, it may be defined using the “Add Payload Device” action:
By the end of this process, a summary of the load to be supported by the satellite will be presented in the form of “Size”, “Mass” and “Power” meters:
These requirements feed directly into the upcoming Bus Design selection process.
Payloads may access a nominal amount of onboard CPU, memory, and persistent storage. Satellites may optionally include Edge Devices to provide additional compute capacity to resident payloads. Edge Devices commonly contain GPUs or other hardware accelerators for specialized data processing.
To configure an Edge Device, choose from the supported components, indicate an average amount of time per orbit it will be active, and choose a quantity of SSDs to attach to it:
When arriving at this stage, ACP will have gathered enough input about the satellite such that an appropriate Bus Design can be recommended:
As soon as you click on a Bus Design at this stage of the workflow, the load meters at the top will indicate how utilized the chosen Bus will be in each dimension. This feedback can be used to help understand how “full” the bus will be.
After making your selection, click “Save & Continue” and the Satellite is now ready to be used!
The following diagram represents the high-level relationship between TrueTwin in ACP and the elements operating outside of ACP:
The remainder of this section focuses on the ACP portion of the payload development process described above. It is vital that developers review the SatOS Payload Developer Guide before continuing.
Each Payload object contains a discrete set of Payload Sequences. Sequences represent individual requests that may be handled by Payload Application software. Individual sequences typically maps to a logical mode of operation.
Payload Sequences may also receive parameters. The “Default Sequence Params” field is used to set the default value sent to Payload Applications when executing a sequence. These parameters may be overridden later, as needed.
The “Power Requirement” represents an estimated power value that will be observed while handling the sequence. This helps in initial power modeling of the full satellite system and will be improved once representative values can be measured.
To manage Payload Sequences, first start at the DESIGN dashboard. Click on a Satellite, then choose one of its Payloads. Use the "Add New Sequence" action to add a new sequence, or use individual actions on each existing Sequence to edit/destroy them.
To test a Payload Sequence, begin by deploying a TrueTwin instance for the target Satellite. Trigger this action from the Satellite card in the DESIGN dashboard. Be sure to configure the required payload as “remote” and enable the “Quick Deploy” option:
Once your payload application is successfully connected, the screen will advance to the TrueTwin Console. Choose the target Payload and a Payload Sequence to test. Default parameters will be set, but they may be overridden. The “Duration” represents a maximum amount of time granted to the payload application to handle the sequence before timing out. After deciding on this input, click “Submit”:
The sequence will be encoded using an appropriate telecommand and sent to the TrueTwin instance for processing. If the request is accepted by the TrueTwin, the telecommand will be acknowledged and logged in the output pane. The sequence will be forwarded by the TrueTwin to the connected payload application for processing.
Any data that is staged for downlink by the payload application is automatically downloaded into ACP for review:
Note that the remote payload application may be restarted while the TrueTwin is running, which can help to quickly develop application software.
Within ACP, an operator may configure both the network of ground stations used for a mission as well as the radios employed onboard their satellites. ACP will automatically schedule ground contacts for Satellites operating on the platform, including both onboard scheduling as well as API-based scheduling via ground station provider APIs.
A mission’s ground station network plays a critical role in facilitating communication between satellites and ground-based services. Identify which ground stations will support a mission through the “Ground Stations” element of the DESIGN dashboard:
Manage the set of ground stations used in a mission with the “Add Ground Stations” action. Select individual ground stations that will be active or deselect them if they will not support the mission:
Add a custom ground station via the “Add New” action, or clone and modify an existing ground station via the icon in each row to extend the built-in options.
Ground Links are defined within the scope of a Satellite object. This informs ACP how radios should be used. A Satellite should always contain at least a “TT&C” and a “Teledata” Ground Link since these are two critical methods of satellite communication. To define a Ground Link, simply choose an appropriate radio and save the configuration:
It is wise to choose a backup radio for each Ground Link so that ACP can automate fallback in the event that a primary radio cannot be used. This can happen due to onboard or terrestrial failures, or simply due to ground station scheduling congestion.
Operational scheduling of a satellite begins with a Task Plan, which contains a prioritized set of Tasks. Each Task describes some desired activity with optional repetition and geographic requirements. Task Plans are considered generally reusable and tend to represent the “concept of operations” (ConOps) of a given satellite.
A Task Schedule is generated from a Task Plan for a desired period of time, which spans anywhere from a single orbit up to a few days. The operational state of the satellite (e.g. power level, physical location, previous activity, etc) is also considered during the scheduling process. The schedule will contain an optimized set of Tasks that will be executed onboard at specific times.
Once generated, a Task Schedule can be deployed to a target satellite during a ground station contact. Task Schedules can also be used within a Scenario to simulate mission operations, which is discussed later in this document.
Tasks must be defined before a Task Plan can be constructed. Navigate to DESIGN, choose a Satellite, then click on "Tasks":
Each Task represents a logical unit of work that can be scheduled. Each Task is defined by a single Payload Sequence, parametric overrides, and any relevant timing requirements.
The minimum duration field defines the minimal amount of time required for the scheduler to consider the Task for execution. An optional maximum duration will prevent scheduling of the Task longer than the indicated amount of time.
Task Plans are templates of prioritized Tasks that can be used to repeatedly generate schedules for a Satellite:
It is common to define multiple Task Plans for each Satellite, typically modeling the nominal operations as well as one or more alternate plans.
When creating Task Plan, you are constructing a prioritized set of Tasks and their respective scheduling requirements.
Tasks are created ahead of time, then added to a Task Plan with additional scheduling requirements.
Several controls are available to influence when a Payload Task may be executed. The following screenshot demonstrates a "Geofence" geo-trigger.
The "Geo-Trigger" options are described below in detail:
Use None when the task has no ground-based requirements.
Use the Target Track option to require the satellite point towards a specific location on the ground during Task execution. Locations are defined using WGS84 latitude and longitude (decimal degrees) along with an altitude (km). The minimum elevation will limit which ground passes are considered, ensuring that Tasks are only scheduled when the satellite maintains the required elevation above the horizon as measured from the target location.
The Geofence option limits Task execution to time periods when the satellite passes through some geographic area. A bounding box is used to define the area, represented by two WGS84 coordinates (the upper left and lower right points of the box).
In certain cases, an “Attitude Control Mode” must be selected:
The Ground Track mode causes the satellite to maintain a stable orientation with respect to the earth. This can be useful for payloads that scan the ground such as IoT receivers or push-broom imaging sensors. An optional Euler angle offset may be provided (i.e. a custom “roll”, “pitch” and “yaw”), which is defined with respect to the satellite orbital frame.
The Sun Track mode allows the satellite to maintain a solar-oriented attitude during the Task. This can be useful for Tasks that are not sensitive to earth-relative orientation.
Use the “Frequency” controls to define the preferred number of times the Task should be scheduled within a given period of time.
TrueTwin Scenarios allow satellite developers and operators to explore a variety of real world scenarios and test how a given satellite will act.
Starting with an existing TrueTwin instance, click the “Deploy” action on the TrueTwin card and choose “Create a New Scenario”.
The first “Scenario Details” step prompts the user for a Scenario Title. This is a human-readable name that can be referenced later. Typically, this describes the purpose or scope of the Scenario:
The “Orbital Details” step allows users to override the initial orbital position of the spacecraft using a timestamp and Keplerian elements. This input can be used to precisely place the satellite in orbit such that very specific Tasks may be executed and observed.
The “Physical Characteristics” step allows for some further customization of the space vehicle:
The Mass represents the entire spacecraft, including chosen payloads and edge devices as well as the bus design components. The default value should typically be used.
The Moment of Inertia is provided based on a typical satellite’s properties matching the scale of the chosen bus design. These values can be overridden once more detailed mechanical design of a satellite has occurred.
The Dimensions input allows the overall size of the satellite to be configured. This does not include deployable solar panels, if present.
The Current Orientation values allow an initial spacecraft attitude to be provided. Provide input here using Euler angles offset relative to the satellite orbital frame. This control can be helpful when testing how initial orientation could affect lead-in to Task execution.
Next, a user may configure the set of available Ground Stations for the Scenario. The Ground Stations listed in the interface are those that have been pre-configured for the mission. While the scheduler will automatically choose the best ground contacts, it is useful to enable or disable access to certain ground stations to facilitate specific operational testing.
The final stage enables users to construct a relevant “Task Schedule” to execute within the Scenario. Choose a pre-existing Task Plan and a desired amount of simulated time:
ACP will generate a schedule, then snap the scenario (i.e. advance the simulation epoch) to the first scheduled Task to minimize unnecessary time spent ahead of executing something specific to the mission. Drag or resize the time slider on the bottom of the screen to align it to a desired time period. In the example below, the slider has been shifted to match the two later tasks in the schedule rather than running for a large period of time between tasks:
Prior to deployment, review the Tasks in more detail using the "View details" action on the right side of the Task timeline:
Once all inputs are set, proceed to deploy the TrueTwin and begin execution of the Scenario.
Monitor an active Scenario through a dashboard accessible via the TrueTwin card. Navigate to the TrueTwin via the SIMULATE dashboard, if required.
In the Overview pane, the dashboard displays the current position of the simulated satellite on its orbital track. All enabled ground stations are plotted on the map, along with all ground targets and geofences included in the active Task Plan:
Interact with the map by clicking and dragging, or zooming in and out. The view may be switched to a 3d globe using the view controls located in the upper right corner.
The “Task Queue” to the left holds the current status of each Task. As Tasks are executed, the Task entry in the queue is highlighted and any relevant ground interactions are displayed on the map:
The timer in the bottom right of the dashboard represents the amount of time remaining within the simulation. You may end the Scenario early using the “End Simulation” button located next to the timer.
Explore satellite metrics generated during the simulation via the "Telemetry" pane:
Prior to physical satellite integration, application software must be developed to connect the SatOS™ control services to each payload. This development process utilizes TrueTwin within ACP along with the . It is important that application developers review the , as it describes the technical architecture and interfaces used to conduct this development activity.
When prompted, click the "Download Remote Config" button to retrieve the required config bundle. Use this file locally with the to run your payload application software. The SDK will automate connecting the payload application to the TrueTwin instance in ACP:
