Concept of Operations
Introduction
Planning, scheduling and sequencing are common needs across many space missions, yet a common solution does not yet exist. Many space missions clone and own legacy solutions inherited from a similar, previous mission. AMMOS is dedicated to providing solutions shared across missions, liberating them from re-inventing the wheel and major cost of maintenance. Aerie is the new generation AMMOS product, not only providing a powerful simulation framework like its predecessors, it also addresses the crucial need of enabling less expert users to input their planning requests, trigger simulations, automate scheduling and similar through a collaborative web application.
Aerie is designed to address the following capability gaps:
- Simplify mission modeling experience by adopting a common programming language instead of a domain specific language (DSL)
- Simplify mission modeling experience by reducing interdependencies in the mission model code base
- Allow missions to make use of existing libraries for modeling, and write custom code in their mission model as they see fit
- Allow missions to provide a web deployment of a planning tool such that operators with limited programming skills can create valid activity plans and run simulations
- Support real time collaboration and and parallel hypothesis testing such that many more iterations of an activity plan can be tested within the same time frame
- Allow automation and manual modifications to coexist throughout the planning process
- Provide a low-code constraint checking mechanism to validate simulation outputs which can be largely automated
- Provide a low-code scheduling mechanism that can scaffold parts of or generate complete activity plans according to goal snippets
- Support an easy-to-use and verified translation from activities to sequences of commands that are recognized by the flight system
Note that none of the capabilities above are completely new. Other software solutions have offered pieces of the listed capabilities in different or more limited flavors. Aerie's mission is to cover as many key steps in the whole activity planning and sequencing workflow in one deployed tool with dedicated components.
Although Aerie does not aim to be a complete solution for every mission, it has a strong emphasis on extensibility, customization and 3rd party tool integrations.
Design Tenets of Aerie
Enhance automation
Mission operations may involve labour intensive, error prone tasks such as authoring sequences that implement activities or creating a valid activity plan that does not violate flight rules. Aerie supports automation for key areas including scheduling, constraint checking and translation into commands, which we refer to as command expansion. Aerie is designed to simplify these automations and improve their accessibility and usability for mission operators with diverse skill sets.
Design for customization and configurability
Aerie tools and services allow systems and services to be customized to meet different mission and user needs. For instance, Aerie simulations can be configured to run at different fidelity levels depending on the planners' need at different steps of the planning process. Or an Aerie deployment can be customized to accommodate many parallel simulation and scheduling requests scaled for usage. Similarly Aerie UI can be customized by the mission system or by the users interactively to display data relevant for different contexts.
Design for usability
An integral design guideline for Aerie is to improve user experience for all users. Note that the experience of mission modelers creating a mission model with Aerie framework is highly different than the experience of scientists performing activity planning through a web application, or the experience of an engineer deploying Aerie for all mission users. The Aerie mission modeling framework is striking a tough balance between expressibility and ease of learning. One of the key advantages of using Aerie for modeling is the discrete event simulation engine that takes care of integrating resources for the modelers, handling concurrency of events. This allows mission modelers to model unit behaviors independent from one another. Similarly Aerie web application enables scientists and engineers to trigger simulation with a no-code approach, and perform automated scheduling and simulation analysis with a low-code approach.
Design for many contexts
Aerie can be used in many different contexts other than mission operations where planning and scheduling generally follows strict processes. Aerie can be used to model and simulate any discrete events that affect shared resources. These resources can be on board the spacecraft or on the ground. Aerie can be effectively used in mission planning to generate and evaluate long-term schedules for the purposes of validating high-level mission requirements, and to derive low-level requirements. Similarly Aerie can be used in even earlier phases to develop mission concepts. By design Aerie does not implement mission business logic or dictate workflows.
Eliminate duality in planning and sequencing
Traditionally planning and sequencing are independent, serial processes where operators are responsible for accurately translating activities into spacecraft commands. This duality reduces efficiency, leads to redundant validations at the activity planning and sequencing steps, and can be error prone. Aerie aims to eliminate this duality by using the same simulation engine for activity and command simulations, which can provide an option for missions to do one simulation where abstracted activities decompose into actual commands.
Design for customization
Aerie tools and services should be extendable and customizable to answer the needs of missions with different levels of complexity. In the following sections, we describe how Aerie can be used at its full capacity by a highly complex and automated mission. On the other end of the spectrum, a mission may choose manual activity planning, basically not utilizing modeling, simulation or scheduling capabilities, while leveraging command expansion to automate sequence generation based on planning inputs. The mission can utilize its flight software simulator to simulate commands, upload resulting resource profiles back to Aerie for visualization and analysis. We provide a few examples of such different mission operations in Section 4.14.
Scope
Aerie is an extensible framework designed to cover as many key steps in the planning and sequencing process of ground operations all the way up to the sequence products generation. The long-term goal for Aerie is to cover more steps in the planning and sequencing ground operations especially in the areas of i) command level simulations that mimic the onboard command execution behavior more closely, ii) downlink data (telemetry) analysis along with simulation data to close the loop between uplink and downlink, often referred to as predicts versus actuals. The current focus of the product extends until sequence generation. The diagram below summarizes current Aerie capabilities.
While Aerie does not support observation (science) planning it can be easily integrated with tools that provide specialized features for target selection or surface coverage analysis through its powerful API. Such tools can import a scaffolded schedule, modify observation activities and feed them back to Aerie.
Similarly Aerie is not a workflow manager, but its API allows missions to orchestrate events and requests across multiple tools that they utilize during their ground operations. You can read more about subscriptions at the API documentation page to learn more about integrating Aerie in complex workflows.
Conceptual View
Aerie is a planning and simulation tool powered by a discrete event simulation engine. Running your first simulation in Aerie requires having a mission model that defines activity types, which are units for planning, and resources that will be tracked over the course of the simulation. A mission model simply defines how activities will affect these resources as they execute. Modelers can define additional dynamic behavior for these activities, expose configuration parameters to modulate simulation behavior and utilize any library or custom code during these calculations.
An activity type is a planning unit comprised of parameters that modulate its behavior and an effect model that can query and affect resources. A simple example of an activity is taking an image with an instrument, where the activity increases data volume on board, and the amount of data it will generate depends on the resolution and image size arguments. Similarly, required power can be modeled based on resources like spacecraft orientation. Activities can invoke other activities in their effect model. Aerie allows arbitrary, dynamic hierarchies which we refer to as decomposition. Finally, activities can return values computed during their execution which we refer to as computed attributes.
Once a mission model is available, creating plans and running simulations can be accessible to a larger operations team through the Aerie UI. The diagram below summarizes steps to run your first simulation through Aerie. The moment that an Aerie installation and a mission model jar is accessible to the operators, they can upload the model to Aerie, create and validate a plan, configure and run simulations and view the results all through the Aerie UI in a no-code manner.
Note that a single Aerie instance can work with multiple models, such that planners can make use of different activity sets in different plans. This allows testing and iterating models and activity type definitions much faster in early mission phases. It is also possible to restrict one or few models to one venue for more strict operation workflows.
Scenarios for Using Aerie
As noted earlier, different missions can utilize Aerie to meet different needs. In this section we will provide several scenarios for using Aerie in realistic contexts. The examples will range from highly complex missions leveraging all Aerie capabilities, to missions interested in a narrower set of capabilities potentially in different phases.
Complex mission ground operations with large teams and high automation
Below is an operations scenario for a complex deep space mission operations team that needs to create a long-term activity plan for the next planing period. The planning period can range from a week to 6 months.
The first step is to create a scaffold plan built around a notional DSN schedule. To do so, a DSN schedule can be input to an Aerie simulation, translated into a resource. Various scheduling goals can be written to place telecom activities into the viewing periods that satisfy the selection criteria. Engineering calibration and turns can be placed relative to these telecom activities via scheduling goals, to ensure correct spacecraft orientation.
Second, science team members get together to formulate a skeleton science plan. Here team members collectively modify the same plan while discussing their options. At this stage they manually add placeholder activities to the plan that simply allocate resources rather than representing spacecraft behavior more closely. The resulting plan is shared with all subsystem operators in a read-only mode.
At this stage each subsystem creates a branch of the skeleton plan. They replace placeholder activities with actuals, refine parameters and run higher fidelity simulations. When ready, subsystems can submit their merge requests (change requests) to the main plan. The main plan owner can review these modifications and approve or reject the requests.
Meanwhile an instrument team is utilizing a dedicated observation planning software to optimize surface coverage for the instrument. They can do so by querying the current state of the main Aerie plan and get observation windows that are represented by placeholder activities. The software generates specific observation activities, and replaces the placeholder ones. All such activities are then submitted to the Aerie plan through the API. Here there are options to submit the changes to the main plan or a branch for a more controlled modification workflow. The instrument team also wants to share the surface coverage that they computed in their tool with the rest of the operations team. To do so, they upload the surface coverage over time as an external resource profile, such that other planners can view this information along with the other Aerie simulated resources.
As higher fidelity inputs are received, the Aerie main plan gets simulated occasionally, and constraints are checked. When constraint violations are caught, collaborators are asked to modify their activities either directly on the main plan, or following the branch/merge processes. As planning inputs get more refined, planners can increase fidelity of the Aerie simulations that they run through the simulation configuration mechanism. Adjusting simulation fidelity allows rejecting bad plans earlier in the process and more quickly.
As an anomaly condition, the DSN schedule gets updated close to the uplink deadline. A script can process the modifications to determine how to shift existing telecom activities, or which ones to delete and re-create based on changes. Once these changes are done, operators check constraints to detect any violations such as an observation overlapping a telecom activity. Depending on the density of violations, operators can chose to address them by manually by modifying some activities, or deleting and rescheduling a bunch of them according to the updated telecom schedule.
Once all the constraint violations are resolved and a satisfactory plan is formulated, the operators can generate commands for activities by pressing a button during the operations process. Note that we are assuming that the command expansion logic for activities have been created ahead of time. The resulting sequences can be queried through Aerie API, and transferred to a mission uplink store for further processing and integration with other uplink products.
Mission concept design and mission planning
In this scenario, mission planners are interested in generating very long term plans to validate high-level mission requirements against the current design. They may be interested in understanding the effects of different orbit insertion scenarios on total observation durations per instrument over the course of the mission. Mission modelers can create low-fidelity activities that capture instrument behavior, and then use Aerie API to run Monte Carlo simulations that slightly vary orbit insertion inputs as well as scheduling logic. Mission planners may only utilize the Aerie web application to share outputs in read-only mode with the rest of their team.
Multiple spacecraft sharing ground resources
Now imagine a scenario where a swarm of Earth-orbiting cubesats share a ground antenna. The antenna can only support few concurrent communications, and a has limited range of view and mobility. The orbit of each cubesat is given and the antenna operations team has to schedule activities for the ground antenna to rotate it into different configurations and set communication parameters to listen to the cubesats in its view period.
This can be achieved by importing geometric conditions for each spacecraft into Aerie, and translating them into internal resources. Next, the turn behavior of the antenna needs to be modeled, such as the constraints on range of motion, or time it takes to switch from one configuration to another. The mission model can compute optimal viewing geometry for the antenna given all of the spacecraft geometric configurations. A scheduling goal can create communication activities for the antenna, placing them in the computed view periods. The parameters for the communication activities can be set at the scheduling stage, based on specific settings of each spacecraft in view. A constraint checking mechanism can be utilized to ensure each spacecraft has allocated a minimum communication duration within the planning period. Once a satisfactory activity plan is generated for the antenna, operators can refine parameters. Finally, the resulting activity specifications can be captured through the Aerie API to generate inputs for the downstream tool or process.
Aerie with 3rd Party Tools
As a multi-mission framework, Aerie is designed to be as agnostic as possible to the complex ecosystems that it can live within. There are many different data sources in a wide range of formats that are necessary inputs for planning. These can include downlink telemetry, ground antenna schedule and inputs from other simulation tools. Mission modelers can import, parse and utilize arbitrary data in their mission model, reading the data from a file or fetching it from a REST end point. This makes the Aerie framework agnostic to input data formats and date exchange mechanisms. Once such data parsing utilities are implemented by one mission, it can be shared across all Aerie customers in an inner-source or open-source manner.
For planners to view additional data along with simulation data, Aerie provides an external resource profiles mechanism. Since the Aerie web application and constraint checking service has to recognize this input, it has to adhere to a structure dictated by Aerie.
Aerie API is a GraphQL API, which is very powerful and expressive. GraphQL allows users to define a custom query that minimizes the over-fetching and under-fetching issues that REST APIs are prone to. Any action that can be taken in the Aerie UI can also be done through the API. This allows missions to automate Aerie actions further or replace certain capabilities with custom counterparts. For instance, it is easy to imagine a mission developing a custom scheduling algorithm that utilizes Aerie simulation data, and inserts activities that it schedules through the API.
Finally, Aerie API provides subscriptions which allow incorporating Aerie in complex workflows. Missions need to utilize a workflow manager to orchestrate dependencies across their tool chain. For instance, operators may need to trigger a process to generate inputs for Aerie simulation, and trigger a simulation when inputs are available. A subscription can notify workflow manager when the simulation is complete, which can then trigger a process to feed the results to a post-processing stage. When that completes, results can be uploaded back to Aerie for planners to view all of the data together. Note that Aerie framework will not subscribe to any mission-specific process, nor can it be used as a workflow manager.