JFORCES Satellite-Based Sensor Tasking Algorithm
Purpose: This document describes the JFORCES algorithm for assigning space-based sensors to surveying specified points and regions. As described in this figure, the resultant detections from these assignments (also called tasks) are marshaled into sensor reports. If communications exist, these reports are then provided (with appropriate time delays) to both the C2 module and any participating human operators for evaluation and response.
The focus of this paper is limited to describing the first part of this ISR thread, that is the determination of tasks for space-based sensors given both preplanned surveillance requests and dynamically inserted requests resulting from scenario execution and the requirements of C2 to have additional detailed information on regions and points of interest. Note that this algorithm currently runs independently of similar tasking algorithms for non-space based ISR assets also incorporated in the JFORCES model (or, alternately, outside JFORCES when confederated with other models or real-world inputs). Interfaces to algorithms for these other assets could be made at a later time but this approach appeared most consistent with current and near-term real-world operations. Besides which, this approach clarifies the algorithm description.
Note: For brevity from this point the space-based sensors will simply be referred to as sensors. However the reader is cautioned that this algorithm is pertinent only to satellite-based sensors; alternate tasking algorithms exist within JFORCES for non-satellite based sensors that evaluate their alternate capabilities and needs, including the requirement to travel to survey regions.
The satellite-based sensor tasking algorithm evaluates both dynamically inserted and preplanned surveillance requests against the capabilities of satellite-based ISR assets to create an optimal task stack to be executed for each sensor. This figure lists the task attributes required for both preplanned and dynamically requested tasks.
JFORCES processes all preplanned tasks at the beginning of the scenario to form a tasking baseline and then repeatedly reprocesses the tasking stack throughout the scenario on a user-specified update rate. The purpose to processing all preplanned tasks initially is to form a baseline for comparison to identify those preplanned missions that were not executed as a result of dynamic requests being inserted with greater priority during the scenario’s execution. This information is maintained for post-processing analysis. The retasking update rate is user-definable and represents the flexibility of future epochs to accommodate tactical requests.
This list of tasks is first sorted according to priority and divided into appropriate collection windows, as indicated in this figure.
Some important points about this figure:
Based on the collection specifications, multiple collection windows can be specified for any task.
The colors in this figure indicate the collection type (e.g. EO versus IR). This and other task attribute data will be used to map the collection request to appropriate sensors.
Note that a single target (e.g. target 1 in this example) can be the subject of multiple tasks. These tasks can be differentiated according to collection type, as indicated in this example, or other attributes as desired. Thus a single target can readily be designated for multi-source investigation, which will then be mapped to the different sensors (possibly on the same satellite) at possibly different time periods and/or collection priorities according to the input stack.
The last column shows that collection attempts are tracked internally according to the target, the task, and finally the collection window within the task. This information is maintained for all collection windows, not just those in the last column. Drawing each of these windows just got tedious, so it’s hoped the point in made by highlighting it in this column. This tri-level identification is maintained throughout task assignment so assignment success data can be collected for different architectures for each collection window.
While collection windows are shown as solid blocks in this diagram, the window field of the ISR task permits users to specify that collections should be centered in the collection window instead of collected at any time in the window.
These collection requests are then compared to the ability of scenario assets to collect the desired type and quality of data. The figure below is a typical example of JFORCES evaluations of satellite access over time against a specified task. While this chart is used by interactively by analysts during scenario setup, the same data is used internally by the sensor tasking algorithm (albeit without displays)
The sensors included in this availability evaluation are appropriately limited according to the tasking requirements. These limitations include:
Considering only sensor types appropriate to the specified collection type
Considering only sensors capable of achieving the requested detection quality
Considering sensors only when within their collection limitations (e.g. far enough above the horizon for a quality detection and the sensor field of regard)
Considering collection limitations by each candidate sensor according to the time of day (i.e. the expected light conditions), the expected weather
The task is compared for the best assignment across all appropriate sensors. These sensors can be on different satellites or collocated. As assignments are made, the specific tasked sensors are flagged as unavailable for further assignments for a period of time corresponding to the collection itself and a retasking delay based upon reorienting and settling the sensor. This inter-tasking delay is defined according to each sensor family and can be reduced to 0 when appropriate. Each sensor is limited to a single collection at a time, but different sensors on the same satellite can simultaneously be tasked to perform multiple collections. These sensors can be of different or the same type as specified by the analyst in scenario setup.
Because the tasking stack is ordered by priority this system guarantees that high-priority tasks will be performed regardless of tasking timing within the tasking evaluation window. This window is set to the entire scenario duration for the initial cut to fully order the preplanned tasks. But then tasks are reevaluated at an analyst-specified period to consider tasking changes resulting from the dynamic injection of ISR tasking requests resulting from scenario execution. Altogether, this algorithm balances the available sensor coverages and capabilities against the combined preplanned and dynamic tasking requests as shown in the figure on the following page.
It might be worth repeating that this algorithm is sensor-specific, not satellite specific. There can be several sensors of different types on a single satellite. Moreover, there can be many instances of a specific sensor family on this satellite. Thus, while this algorithm restricts each sensor to performing only one task at a time, a single satellite using different on-board sensors can simultaneously prosecute multiple tasks. This algorithm thereby allows modeling resource-constrained collection systems without severely limiting the system to collecting a single point at a time.