Content uploaded by Allan Shtofenmakher
Author content
All content in this area was uploaded by Allan Shtofenmakher on May 30, 2024
Content may be subject to copyright.
Adaptation of ISO 23247 to Aerospace Digital Twin Applications:
On-Orbit Collision Avoidance and Space-Based Debris Detection
Allan Shtofenmakher∗
Massachusetts Institute of Technology, Cambridge, MA 02139, USA
Guodong Shao†
National Institute of Standards and Technology, Gaithersburg, MD 20877, USA
As interest in digital engineering within a variety of technical domains begins to accelerate,
industries continue to encounter obstacles with regard to implementing—and benefiting
from—digital twin technologies. One key challenge facing digital twin adoption in the aerospace
industry, in particular, is a lack of standardized digital twin frameworks (DTFs). Adapting
existing DTF standards intended for use in other domains towards aerospace applications may
offer a path forward for overcoming this obstacle. To demonstrate the feasibility of this approach,
the recently published ISO 23247 standard, Digital Twin Framework for Manufacturing, is
adapted for the first time for use in a non-manufacturing aerospace application—collision
avoidance (COLA) in low Earth orbit (LEO) for resident space objects (RSOs) greater than
10 cm in characteristic length. The result is the first known formal representation in a
standardized digital twin framework of this well-established prescriptive COLA process. To
further demonstrate the value of establishing a standard aerospace DTF, this framework is,
in turn, adapted into a novel descriptive digital twin architecture for space-based detection
of sub-10-cm-class orbital debris, which can later be integrated with the existing collision
avoidance framework to improve overall space situational awareness (SSA). The paper concludes
with recommendations for future work on the development of increasingly sophisticated digital
twins of the LEO space environment, leveraging these frameworks as a baseline.
I. Introduction
The
term “digital twin” refers to an emergent technology that seeks to represent a physical system or environment
in a virtual form. Moreover, digital twin frameworks (DTFs) expand upon this concept by integrating the virtual
systems or environments and their physical counterparts to capture the relevant cyber-physical elements and their
interrelationships in a formal, multi-layer system definition. In particular, in an earlier work, Shao et al. define the five
categories of digital twins, in order of increasing complexity and value [1]:
1)
Descriptive digital twins, which seek to represent or describe the system or environment using available data
from observations;
2) Diagnostic digital twins, which seek to explain why the system or environment is in its current state;
3)
Predictive digital twins, which seek to predict the future state of the system or environment using analytic and
propagative tools;
4)
Prescriptive digital twins, which seek to optimally realize (or avert) the prediction by commanding entities
within the physical system, often with human-in-the-loop intervention; and
5)
Intelligent digital twins, which seek to minimize or eliminate human-in-the-loop intervention with additional
layers of autonomy and artificial intelligence.
Although the modern definition of digital twins only received widespread recognition in the early 2000s, several
industries have benefited from digital twins in various forms for decades [
2
]. The aerospace industry, in particular,
has a rich history involving digital twin technologies and philosophies, dating at least as far back as the National
Aeronautics and Space Administration’s (NASA’s) historic rescue of Apollo 13 in April of 1970 [
2
]. More recently,
the U.S. Department of Defense (DoD) has awarded a number of contracts encouraging the development of digital
engineering tools to support satellite constellation design, active space debris monitoring and remediation efforts, and
other space operations, which indicates the U.S. government’s continued interest in promoting and leveraging digital
∗Ph.D. Candidate, Department of Aeronautics and Astronautics
†Computer Scientist, Systems Integration Division, Engineering Laboratory
1
twin technologies in this domain [
3
,
4
]. In spite of these facts, the American Institute of Aeronautics and Astronautics
(AIAA) Digital Engineering Integration Committee recently published a unified implementation paper identifying
a number of challenges—including lack of standardization—that are preventing the widespread adoption of digital
twins in aerospace and identified a need for general, standardized digital twin reference models that can be adapted for
particular aerospace applications [5].
One approach towards the development of standardized digital twin frameworks for aerospace applications involves
the adaptation of existing, published digital twin standards intended for applications within other domains. For example,
Ref. [
5
] offers a case study in which the recently published ISO 23247 standard [
6
] for digital twins in manufacturing is
successfully applied to three distinct aerospace manufacturing test cases. A close inspection of this standard suggests
that the ISO 23247 digital twin architecture can be readily adapted into other domains, such as non-manufacturing
aerospace. To demonstrate this flexibility, this paper presents a case study that adapts the ISO 23247 framework to a
topical aerospace application—on-orbit collision avoidance.
The recent proliferation of satellites in low Earth orbit (LEO) as part of the burgeoning space economy poses a
number of challenges in the form of space debris mitigation and collision avoidance (COLA) [
7
]. As the number of
resident space objects (RSOs) in LEO grows, the risk of collision between RSOs increases dramatically, threatening the
sustainability of Earth’s local space environment [
7
]. Frequent monitoring and cataloging of RSOs is necessary to
prevent the disruption of space-based communication networks, global navigation systems, and other critical services
that benefit hundreds of millions of U.S. residents on a daily basis. The U.S. Space Surveillance Network (SSN)
currently tracks over 23,000 RSOs in LEO, including functional and decommissioned satellites and debris, focusing on
objects with characteristic length greater than 10 cm due to ground-based sensing limitations [8].
The process for detecting conjunctions—or close approaches—and avoiding collisions between these larger RSOs
is facilitated by a de facto prescriptive digital twin of the (partial) LEO space environment. In particular, the SSN
updates a High-Accuracy Catalog (HAC) of position and velocity estimates at least once per day using ground-based
sensor measurements [
9
]. The 18th Space Defense Squadron (18 SDS) then propagates these estimates several days
into the future and updates the HAC accordingly, while the 19th Space Defense Squadron (19 SDS) screens the HAC
to assess collision risk for each RSO. If an active spacecraft (S/C) is at sufficiently high risk of collision, the 19
SDS uses a web-based application known as Space-Track to send a conjunction data message (CDM) or collision
avoidance notification (CAN) to the satellite’s owner/operator (O/O) (e.g., NASA), which may (or may not) manually or
automatically correct the satellite’s trajectory based on available information to mitigate the risk [
9
]. The SSN then
obtains a new set of measurements using its suite of sensors, and the cycle repeats. Fig. 1 below depicts this overall
process at a high level. Section III discusses the various operations depicted in Fig. 1, as well as additional activities
and functionalities, in greater detail.
Fig. 1 Concept of operations for collision avoidance using ground-based sensor measurements of LEO RSOs.
Image in Box 1 courtesy of European Space Agency (ESA) via National Geographic [10].
The above process has been depicted in a number of forms throughout the years [
9
,
11
,
12
] but has rarely, if ever,
been depicted as a digital twin in a formal sense. In light of this fact, this paper applies and adapts the recently developed
2
ISO 23247 standard [
6
] to capture the process in a standardized prescriptive digital twin framework. Although the ISO
23247 standard is defined for digital twins in manufacturing, the components defined in the standard User, core Digital
Twin, Data Collection and Device Control, and Cross-System Entities, as well as the observable elements, are broadly
applicable to human-in-the-loop satellite operations. Consequently, with some level of tailoring of these components, a
prescriptive digital twin architecture for detection and avoidance of LEO RSOs greater than 10 cm in characteristic
length can likewise be developed, as is discussed in Section III. This ultimately offers an intermediary step towards
meeting the AIAA Digital Engineering Integration Committee’s call to improve standardization for digital twins in
aerospace [5].
In particular, the formal representation of an existing space situational awareness (SSA) system within a digital
twin framework encourages investigation into the establishment of novel DTFs for similar aerospace processes that are
forthcoming or in development. For instance, at the time of this writing, no such formal DTF exists for space-based
detection of debris and other RSOs using sensors external to the SSN, in spite of recent publications exploring the
feasibility and value of such an approach [
11
,
13
–
19
]. As an example, recent work by Shtofenmakher and Balakrishnan
indicates that commercial optical sensors available onboard most active satellites can, under appropriate lighting
conditions, be used to detect sub-10-cm-class debris in LEO [
17
,
18
]. These space-based measurements could be
transmitted to the ground through radio frequency or optical communication methods and received by a corresponding
ground station [
20
]. These data can be processed by ground software and ingested into a database accessible by the SSN
and other interested stakeholders. End users can then visualize the LEO space debris environment with appropriate
front-end simulation software.
The above paragraph describes, at a high level, a descriptive process for orbital debris detection by on-orbit satellites
using in-space sensors, which can likewise be captured in a novel digital twin framework. Section IV explores this
DTF, including its constituent elements and their interrelationships, in greater detail. In contrast to the architecture
presented in Section III—which captures an existing process that primarily leverages ground-based sensors within the
SSN to track larger RSOs—the framework presented in Section IV offers a baseline for the development of digital twins
designed to virtually represent smaller RSOs in the LEO environment using data collected from space-based sensors.
Although any descriptive digital twin derived from this DTF could operate independently from the existing prescriptive
process for collision avoidance, in the ideal case, the two digital twins would cooperate to provide improved SSA and
COLA capabilities. With additional development, an initially descriptive digital twin for space-based orbital debris
detection can evolve to have diagnostic, predictive, prescriptive, and even intelligent capabilities for collision avoidance
within satellite networks. This is presented as future work in Section V.
In summary, this paper claims the following contributions to the digital engineering literature:
1) The first known adaptation of the ISO 23247 standard [6] to a non-manufacturing aerospace application;
2)
The first known formal representation in a standardized digital twin framework of the existing prescriptive
process for detecting and avoiding collisions between RSOs in LEO; and
3)
A novel descriptive digital twin framework for sub-10-cm-class orbital debris detection by on-orbit satellites, to
be used in augmenting the existing collision avoidance process—which does not typically account for debris
particles of this size class—and as a baseline for the development of a series of increasingly sophisticated digital
twins for space-based debris detection and collision avoidance within satellite networks.
II. ISO 23247 Standard Architecture for Digital Twins in Manufacturing
The recently published ISO 23247 standard, Digital Twin Framework for Manufacturing, offers a generic digital twin
reference architecture intended to be adapted for specific applications within the manufacturing domain [
21
]. Although
the standard contains four parts at the time of this writing, the present discussion will focus on Part 2: Reference
Architecture [6].
Figure 2 depicts the ISO 23247 standard architecture for digital twins in manufacturing [6].
In this framework, the physical entities intended to be represented by their virtual counterparts are collectively
termed Observable Manufacturing Elements (OMEs). An OME is defined in ISO 23247 as “an entity that has an
observable physical presence or operation in manufacturing” [
6
]. In Fig. 2, these are captured within the gray box at the
bottom of the figure. The remaining entities are enclosed within an overall Digital Twin Framework, represented by
the dashed box.
The DTF is resolved into four major entities (depicted in Fig. 2 as darker blue boxes), each of which is defined
primarily by its main function or functions, which are represented by functional entities (FEs, depicted as white boxes).
The User Entity (UE), which includes humans directly involved in the operation and management of the digital
3
twin, provides user interfaces to interact with the core digital twin entity [21].
The Digital Twin Entity (DTE), also known as the Core Entity (CE), serves to digitally represent and manage the
observable physical elements (i.e., OMEs) with a number of sub-entities (depicted in 2 as lighter blue boxes), each of
which is likewise defined by its major functions [21]:
1)
The Operation and Management Sub-Entity, which manages the digital model and its maintenance, synchro-
nization, and visualization;
2)
The Application and Service Sub-Entity, which manages simulations, data analysis, and report generation; and
3)
The Resource Access and Interchange Sub-Entity, which manages interoperability among and access to the
digital twin elements.
The Data Collection and Device Control Entity (DCDCE) links the observable physical elements to their virtual
counterparts via two sub-entities [21]:
1)
The Data Collection Sub-Entity, which collects data from the observable physical elements using sensors and
communicates those data to the DTE via networks; and
2)
The Device Control Sub-Entity, which controls and actuates the observable physical elements based on inputs
from the UE, the DTE, or both, depending on the specific application.
The Cross-System Entity (CSE) resides across domains, typically interacting with the other entities at multiple
levels with functions like data translation and assurance and cybersecurity [21].
The major entities, including the observable physical elements, and the sub-entities within them are connected to
one another via a series of defined networks [21]:
1) The user network, which connects the UE and the DTE;
2) The service network, which connects the various sub-entities within the DTE;
3) The access network, which connects the DCDCE to the DTE and the UE; and
4) The proximity network, which connects the DCDCE to the observable physical elements.
In Fig. 2, the color of each network connection matches the color of the frame of one or both of the boxes to which
it connects. It is worth noting that the original ISO 23247 standard architecture in Ref. [
6
] allows for—but does not
explicitly depict—the access network connection between the UE and the DTE [
21
]. For maximum fidelity to the source
material, the replication presented in Fig. 2 likewise omits this connection.
Although ISO 23247 is defined for digital twins in manufacturing, the reference architecture is ultimately presented
at a relatively high level, with lower-level details regarding individual FEs and networks omitted in favor of increased
generality. The result is an adaptable framework that, with some effort, can be tailored to applications both within
manufacturing (e.g., drilling and filling holes in airframe wings [
5
]) and beyond (e.g., collision avoidance in LEO). With
regards to the latter, the challenge arises in translating each of the entities and elements from the ISO 23247 architecture
into their counterparts in a particular aerospace application, as well as identifying superfluous elements that can be
eliminated and supplemental elements that need to be added for a more complete digital representation. This adaptable
nature and its corresponding challenges are explored in Section III and Section IV.
III. Prescriptive Digital Twin Architecture for On-Orbit Collision Avoidance
As discussed in Section I, the current process for detecting conjunctions and avoiding collisions between RSOs
tracked by the U.S. SSN can be captured within a prescriptive digital twin framework, in which the core digital twin
seeks to represent, at least in part, the LEO RSO environment. To harness this potential, this section adapts the ISO
23247 digital twin reference architecture towards this aerospace application, presenting both higher-level and lower-level
functional representations and offering associated discussions [
6
]. Much like the ISO 23247 standard, this section begins
by defining terminologies that will be used in the remainder of the text, then presents a high-level digital twin reference
architecture for on-orbit collision avoidance, and ends with lower-level details regarding the individual elements within
that architecture and their corresponding interrelationships [6].
A. Relevant Terminology
Several key terms briefly mentioned in Section I are formally defined here:
1)
Space situational awareness, or SSA, refers to “the ability to accurately characterize the space environment and
activities in space” and generally involves acquiring knowledge regarding the current and future positions of
space objects of interest [19].
2)
Conjunction data messages, or CDMs, are messages sent to spacecraft O/Os by the 19 SDS informing them of
upcoming conjunctions over the next few days [9].
5
3)
Collision avoidance notifications, or CANs, are notifications sent to spacecraft O/Os by the 19 SDS indicating
that one of their space assets has met emergency close approach conditions, with probability of collision roughly
1000 times greater than that required to issue a CDM [9].
The 18 SDS and 19 SDS also offer the following definitions in their Spaceflight Safety Handbook for Satellite
Operators [9]:
1)
The state of an RSO, in the context of this framework, refers to the concatenated position and velocity vectors of
that RSO at a given moment in time.
2)
An ephemeris (plural: ephemerides) for an RSO refers to a series of state (i.e., position and velocity) vectors for
that RSO presented sequentially in time.
For brevity, the description of the collision avoidance process presented in Section I focused on position and velocity
estimates generated by the U.S. SSN. However, certain O/Os may choose to contribute to the 18 SDS & 19 SDS RSO
databases by willingly sharing the SSA information available to them [
9
]. The following definitions serve to distinguish
O/O and S/C types based on their respective levels of cooperation and collaboration, wherein the former is generally
considered a prerequisite for the latter:
1)
These Collaborative O/Os may provide onboard-sensor-based position and velocity data and predictive ephemeris
data for their own S/C and will consider maneuvering their spacecraft and providing associated maneuver
notifications in response to a relevant CDM.
2) Accordingly, Collaborative S/C are those S/C under the purview of Collaborative O/Os.
3)
Strictly Cooperative O/Os, on the other hand, will consider maneuvering their spacecraft in response to a CDM
but will generally not provide maneuver notifications or share SSA information concerning their own spacecraft
willingly.
4)
Since cooperation is generally a prerequisite for collaboration, Cooperative S/C are those that can be maneuvered
by Collaborative O/Os or strictly Cooperative O/Os.
5)
Uncooperative O/Os, in contrast, will not consider maneuvering their spacecraft in response to a CDM and will
not generally share SSA information willingly. This may include O/Os of inactive or otherwise non-maneuverable
spacecraft as well as adversarial nation-states with S/C involved in CDMs [8].
6)
Uncooperative S/C are, therefore, those that cannot be maneuvered by Collaborative O/Os or strictly Cooperative
O/Os.
These O/O and S/C categorizations are loosely derived from similar terminology in Ref. [
8
], intended for cooperative
spacecraft maneuvering applications, wherein the second actor in a(n):
1) Collaborative COLA situation actively shares information and is willing to maneuver;
2)
Cooperative COLA situation is willing to maneuver but does not necessarily coordinate with the first actor; and
3) Uncooperative COLA situation neither shares information nor maneuvers.
With the necessary key terms defined, the following sub-section will present a high-level functional representation
of the on-orbit collision avoidance digital twin reference architecture.
B. High-Level Digital Twin Architecture
Figure 3 seeks to capture the existing process for on-orbit collision avoidance in the form of a high-level prescriptive
digital twin architecture. The emphasis in this figure is on the major entities, their sub-entities, and the information
exchanged among them through the various digital twin networks. Additional details regarding the individual functional
entities captured within the major entities and sub-entities are provided in the next subsection.
The color scheme in Fig. 3 is similar to that of Fig. 2, with two key differences:
1) Lighter gray boxes representing observable physical sub-entities are now embedded within the darker gray box
representing observable physical entities; and
2) The color of each network connection matches the color of the frame of the box from which it is sourced.
Although the emergent behavior of this particular application is on-orbit collision avoidance, this digital twin
ultimately seeks to represent, in virtual form, the LEO RSO environment encapsulating the observable physical elements.
These Observable LEO Resident Space Objects are resolved into two categories: Uncontrollable and Controllable.
The set of Uncontrollable LEO Resident Space Objects includes uncooperative spacecraft and debris of characteristic
length greater than 10 cm, whereas the set of Controllable LEO Resident Space Objects includes both cooperative
and collaborative spacecraft. In this application, debris of characteristic length smaller than 10 cm is not considered
observable and is therefore not included.
Each of these Observable LEO RSOs, Controllable or Uncontrollable, is tracked by ground-based radar and optical
6
Fig. 3 A higher-level prescriptive digital twin architecture for on-orbit collision avoidance, with a focus on the
information exchanged among major entities, sub-entities, and functional entities.
7
sensors—as well as a few space-based sensors, such as those on the Space-Based Surveillance System (SBSS)—within
the U.S. SSN based on sensor tasking commands received by 18 SDS and partnered SSN sensor operators [
9
,
19
].
The collection of these data is represented in Fig. 3 as measured RSO position and velocity data being received by
the Observable RSO Data Collection Sub-Entity within the Data Collection and Spacecraft Control Entity, an
application-specific variant of the DCDCE from ISO 23247. Once these data are processed, they are passed into the
Digital Twin Entity’s Operation and Management Sub-Entity, which synchronizes the data, determines the orbit
of each observable LEO RSO, and outputs orbital simulation parameters [
9
]. These are ingested by the Application
and Service Sub-Entity, which simulates and propagates the RSO orbits, analyzes the data, and detects conjunctions
[
9
]. The Resource Access Sub-Entity manages access controls throughout the DTE, which ultimately makes reports,
CDMs, and additional SSA information available to users via the Space-Track application [9].
Within the User Entity, users of Space-Track—and, by extension, the overall digital twin of the LEO RSO
environment—include 18 SDS & 19 SDS,Public Users such as Dr. T.S. Kelso and his publicly available Satellite
Orbital Conjunction Reports Assessing Threatening Encounters in Space (SOCRATES) tool [
22
], Cooperative O/Os,
and Collaborative O/Os. 18 SDS & 19 SDS may upload various files to Space-Track, while Collaborative O/Os
may upload their spacecraft ephemerides and maneuver notifications [
9
]. Collaborative O/Os determine spacecraft
ephemerides based on processed spacecraft position and velocity data received from their own spacecraft via the
Collaborative S/C Data Collection Sub-Entity, which collects, stores, and processes spacecraft data.
In the event of a CDM or CAN, both Collaborative O/Os and strictly Cooperative O/Os may send control commands
to the Cooperative S/C Control Sub-Entity, which controls individual Controllable LEO RSOs through collision
avoidance maneuvers executed via spacecraft actuators such as thrusters.
Throughout this process, the Cross-System Entity ensures that any data received by an FE are properly formatted,
trustworthy, and secure.
C. Mapping of Functional Entities
Figure 4 expands on the higher-level architecture depicted in Fig. 3 by providing additional detail regarding the
embedded functional entities. The color scheme in Fig. 4 is similar to that of Fig. 2, with the addition of the lighter gray
boxes representing observable physical sub-entities within the darker gray box representing observable physical entities.
This section seeks to offer an approximate mapping of the ISO 23247 functional elements depicted in Fig. 2 to those
identified in Fig. 4. Given the differences between the two applications—manufacturing vs. collision avoidance in
LEO—the overall mapping is not one to one; however, many FEs translate from one application to the other in an exact
or approximate manner.
For example, the Resource-Specific FEs categorized under Observable Manufacturing Elements in Fig. 2 map
to a different set of observable entities: Large Debris (> 10 cm) and Uncooperative O/O Spacecraft within the
Uncontrollable LEO RSOs Sub-Entity and Cooperative O/O Spacecraft and Collaborative O/O Spacecraft within
the Controllable LEO RSOs Sub-Entity. These differences arise naturally from the difference in application, but the
observable nature of the elements is shared.
Similarly, the DCDCE from the ISO 23247 standard is re-envisioned in Fig. 4 as a Data Collection and Spacecraft
Control Entity with three sub-entities, rather than two, due to application-specific nuances. In particular, the Observable
RSO Data Collection Sub-Entity receives commands from the 18 SDS & 19 SDS FE, collects data on both Controllable
and Uncontrollable LEO RSOs, and outputs processed data to the DTE. In contrast, the Collaborative S/C Data
Collection Sub-Entity receives data only from Collaborative O/O Spacecraft and outputs this information directly to
Collaborative O/Os, which can then upload O/O S/C ephemerides to the DTE via Space-Track [
9
]. Combining these two
data collection sub-entities into a single Data Collection Sub-Entity, as in Fig. 2, would simplify the prescriptive digital
twin architecture for on-orbit collision avoidance at the expense of valuable nuance. Thus, Fig. 3 and Fig. 4 separate
data collection on the part of the SSN from spacecraft control and data collection on the part of O/Os for additional
clarity.
In each case, the mapping of FEs is straightforward. For the Observable RSO Data Collection Sub-Entity, the
Data Collecting FE is resolved into the suite of sensors and related hardware—that is, the U.S. Space Surveillance
Network—used to collect SSA data for the HAC and a Data Collection and Storage FE. The Data Pre-processing
FE from ISO 23247 corresponds directly to the Data Processing element in Fig. 4. This FE reflects the process by
which sensor readings are weighted and filtered to increase the accuracy of the information received over multiple points
in time, using methods like weighted least squares regression, based on parameters that contribute to measurement
uncertainty, like weather conditions, time tracked, geometric constraints, power constraints, and technical difficulties
8
Fig. 4 A lower-level prescriptive digital twin architecture for on-orbit collision avoidance, with a focus on
enumerating the functional elements constituting the entities and sub-entities.
9
[
23
,
24
]. The Identification FE maps to the RSO Identification & Track Correlation system used by the SSN and the
18 SDS. In particular, the sensor tasking commands received by the SSN typically include a set of known RSOs and
their expected locations [
24
,
25
]. For each such already identified RSO, the SSN scans the corresponding region of
space and correlates the associated tracking data to estimates generated from catalog propagation [
26
]. For tracks that
do not correlate to any known space objects—e.g., uncatalogued RSOs—a state estimate is generated and assigned
to the object [
23
]. After several (typically, three or four) consistent track associations, the RSO is assigned a unique
identifier and added to the catalog [23, 26].
Likewise, for the Collaborative S/C Data Collection Sub-Entity, S/C Position & Velocity Sensors take the place of
the Data Collecting FE.Unique S/C Identifiers, which O/Os use to uniquely identify their spacecraft and to correlate
received position and velocity readings with their corresponding vehicles, replace the generic Identification FE from
Fig. 2 [
27
]. For example, the Consultative Committee for Space Data Systems (CCSDS) 320.0-M-7 standard, “CCSDS
Spacecraft Identification Field Code Assignment Control Procedures,” offers recommended practices for such unique
spacecraft identifiers [
27
]. Onboard spacecraft Data Collection, Storage, and Processing is derived from the Data
Collecting FE and the Data Pre-processing FE from the ISO standard.
The FEs of the Cooperative S/C Control Sub-Entity in Fig. 4 map nearly directly to those of the Device Control
Sub-Entity in Fig. 2. As before, Unique S/C Identifiers, which O/Os also use to ensure that commands are being sent
to the correct vehicle, replace the generic Identification FE from the ISO 23247 standard [
27
]. CCSDS 320.0-M-7
once again provides recommended practices on this topic [
27
]. Likewise, the generic Controlling FE is replaced by
S/C Controller(s), which is (are) often proprietary control algorithms used to convert O/O commands into actuator
operations [
20
], and Actuation FE is replaced by S/C Actuator(s), which, for the purposes of collision avoidance
maneuvers, are typically thrusters [24].
Within the DTE, the roles of the three sub-entities are largely similar between the ISO 23247 standard and the
formalized prescriptive framework, with the individual FEs tailored for the on-orbit collision avoidance application.
Within the Operation and Management Sub-Entity, the Digital Modeling & Orbit Determination FE, derived
from the Digital Modeling FE of ISO 23247, ingests processed position and velocity data from the Observable RSO
Data Collection Sub-Entity and O/O S/C ephemerides from the User Entity (via Space-Track) and determines the
orbit for each tracked RSO using minimum variance differential correction methods [
9
]. This digital model includes
the High-Accuracy Catalog (HAC) of the 18 SDS, which is updated multiple times daily as the orbit determination
process proceeds [
9
]. The Data & Epoch Synchronization FE, derived from the Synchronization FE, ensures
that RSO state estimates are well aligned in time and interpolates between ephemeris points to align epochs for the
purposes of conjunction assessment [9]. The Mission Control Visualization FE, derived from the Presentation and
Representation FE, enables 18 SDS & 19 SDS operators to visualize the LEO RSO environment in mission control
rooms within the Combined Space Operations Center (CSpOC) in the Vandenberg Space Force Base in California,
where 18 SDS is located, and within the Naval Support Facility Dahlgren in Virginia, where 19 SDS is located [
28
–
30
].
Lastly, the Software & Catalog Maintenance FE, derived from the Maintenance FE, represents the various processes
used to maintain the various software elements in the DTE, including the Space-Track application and the HAC.
The updated HAC provides the necessary inputs for the Simulation & Orbit Propagation FE, derived from the
Simulation FE within the Application and Service Sub-Entity, in which the 18 SDS uses the Simplified General
Perturbations Model 4 (SGP4) analytical model and the Special Perturbations (SP) numerical method to propagate
the orbits of its tracked RSOs [
31
]. The predicted RSO trajectories are then screened against one another by the 19
SDS in the Data Analysis & Conjunction Detection FE, derived from the Analytic Service FE [
9
]. The Super
Computation of Miss Between Orbits (COMBO) software identifies potential conjunctions and generates CDMs as part
of the SuperCOMBO Report & CDM Generator FE, which is itself derived from the Reporting FE of ISO 23247
[
9
]. These reports are uploaded to the Space-Track Application, which serves as the service-providing Application
Support FE, automatically making SSA info, CDMs, and CANs available to the relevant users within the UE.
The Resource Access and Interchange Sub-Entity of Fig. 2 is abbreviated in both name and capability as the
Resource Access Sub-Entity in Fig. 4. The Access Control FE is resolved into an Account Credentials Access
Control System, used to ensure that only authorized users are accessing Space-Track and operating the digital twin, and
aClassified Access Control System, to ensure that classified information is shared only through secure communication
channels among individuals with appropriate clearances [
9
]. However, the other three FEs of the Resource Access and
Interchange Sub-Entity are either unimplemented or nonessential for this application (for now). The Interoperability
Support FE is used to ensure that the various blocks within the digital twin are mutually cohesive, especially in
applications involving diverse commercial-off-the-shelf FEs [
6
]. Since the existing on-orbit collision avoidance process
was developed outside of an explicit digital twin framework over the course of decades, many of the tools being used in
10
this process were developed specifically for this application, with interoperability built in as a feature [
9
,
24
,
25
]. Similar
logic applies for the Plug-and-Play Support FE, which is useful for applications in which individual FEs may be
swapped in and out in a modular fashion to increase the versatility of the digital twin [
6
]. The Peer Interface FE, on the
other hand, enables the digital twin to interface with other digital twins in related applications [6]. As the intersection
between on-orbit collision avoidance systems and standardized digital twins is still nascent, no such interface is present
at the time of this writing. However, this may be implemented at a future date if additional processes—and associated
digital twins—for space situational awareness are developed and matured over the coming years. This possibility is
explored in more detail in Section IV.
The generic User Interface FE in the ISO 23247 standard architecture is resolved into four distinct FEs, each
with a distinct role, in Fig. 4. Although their roles are distinct in practice, 18 SDS & 19 SDS are represented by a
single FE for simplicity. Of the two, 18 SDS is generally responsible for maintaining space situational awareness,
maintaining the HAC, and tasking the SSN sensors under its purview, among other activities not discussed in this report
for brevity [
9
]. The 19 SDS is generally responsible for performing conjunction assessments using the 18 SDS HAC
and O/O-provided ephemerides and uploading related files to the Space-Track application, among other tasks [
9
]. Many
of these processes are automated and, accordingly, captured within the DTE [
9
]. In addition, Collaborative O/Os may
provide S/C ephemerides and maneuver notifications to 18 SDS & 19 SDS through the Space-Track application [
9
].
Both Collaborative O/Os and strictly Cooperative O/Os may send control commands to their respective spacecraft
upon receipt of a CDM or CAN [
9
]. Public Users may also take advantage of this publicly available information for
various reasons, including scientific research and general interest [22].
As with the DTE, the mapping of the CSE FEs across application domains is reasonably straightforward. For the
on-orbit collision avoidance application, the Data Translation FE of ISO 23247, which translates data exchanged
between entities [
21
], maps to the 19 SDS Conversion Utility Software, which converts O/O-provided ephemerides
into formats that are compatible with one another, the HAC, and SuperCOMBO [
9
]. The Data Assurance FE, which
verifies data integrity and accuracy [
21
], maps to the Data Assurance & Formatting FE. The function of this entity is
primarily supported through rigorous data formatting standards supplied in Ref. [
9
]. If files are improperly formatted or
named incorrectly, or if data within the files have incorrect notation or units, then Space-Track will reject the inputs and
return error messages accordingly [
9
]. Finally, the Security Support FE, which ensures access authentication, integrity,
authorization, and confidentiality [
21
], maps to the Cybersecurity & Network Protection FE, which represents the
data and access security functionalities distributed throughout the digital twin.
Now that this prescriptive aerospace process has been formally represented in a DTF, the resulting framework can
be adapted to other, related aerospace applications, effectively functioning as a bridge between the ad hoc approaches
historically used in the aerospace industry and the more standardized and consistent approaches recommended by the
AIAA Digital Engineering Integration Committee to increase widespread adoption of digital twins in the field [
5
].
Frameworks for novel or nascent processes and applications are especially valuable, as they can be used to guide the
development of those processes and their functional elements from an early stage, as will be discussed in Section IV.
IV. Descriptive Digital Twin Framework for Space-Based Orbital Debris Detection
As mentioned in Section I, recent advancements in space-based RSO sensing and state estimation capabilities
have promoted discussions regarding leveraging on-orbit satellites for improving overall space situational awareness
[
11
,
13
–
18
]. Ref. [
17
], in particular, suggests that existing commercial optical sensors onboard thousands of active
satellites have the potential to enable opportunistic detection of sub-10-cm-class orbital debris on a massive scale.
The capability of individual spacecraft to use optical sensors to track anthropogenic RSOs—traditionally, those larger
than 10 cm in characteristic length—was first demonstrated on orbit by the Midcourse Space Experiment (MSX) via
the Space-Based Visible (SBV) sensor [
32
]. Although the MSX was retired in 2008 [
33
], since then, the SSN has
augmented its space-based RSO-tracking capabilities with assets like the SBSS system [
34
] and the Canadian Sapphire
satellite [19].
Thus, precedence for space-based space surveillance for larger RSOs has been established; however, in order
to detect, catalog, and track the estimated hundreds of thousands of 1-cm to 10-cm RSOs in LEO [
8
], a more
standardized process—and a more formal framework—will be required. Accordingly, this section seeks to establish a
space-based debris detection digital twin framework with descriptive functionality, seeking to represent the current
state of sub-10-cm-class RSOs in the LEO space environment. This will serve as the foundation for the development
of space-based debris detection digital twins with progressively more advanced functionalities—namely, diagnostic,
predictive, prescriptive, and intelligent.
11
A. High-Level Digital Twin Framework
Figure 5 seeks to capture the proposed descriptive process for space-based detection of sub-10-cm-class debris in a
high-level digital twin architecture that emphasizes, as in Fig. 3, the major entities, their sub-entities, and the information
exchanged among them through the various digital twin networks. As before, additional information concerning the FEs
is provided in the next subsection.
Of particular note is the fact that the major entities and sub-entities—as well as the color scheme—are shared across
Fig. 3 and Fig. 5. However, the role of each entity and the information exchanged among the entities have evolved in
the adaptation process. For example, in this framework, the Controllable LEO Resident Space Objects would receive
scanning maneuver schedules from the Cooperative S/C Control Sub-Entity, based on sensor tasking commands sent by
Collaborative O/Os, and leverage these maneuvers to collect debris scan data from the Uncontrollable LEO Resident
Space Objects. The Controllable LEO RSOs would transmit the collected RSO position and velocity data, as well as
their own position and velocity data, to the Collaborative S/C Data Collection Sub-Entity using radio frequency or
optical communication transmitters in contact with ground station terminals [
20
]. Collaborative O/Os would receive
these data and upload corresponding ephemerides for both their S/C and their observed RSOs to the DTE, the roles of
which are discussed in greater detail in the next subsection.
With regards to the UE, it is assumed that Collaborative O/Os, in the interest of preserving their own space assets
and the LEO space environment in general, are willing to share their S/C and RSO ephemerides with the same set of
collision avoidance stakeholders participating in or benefiting from the existing prescriptive process. Thus, 18 SDS
& 19 SDS, Public Users, Cooperative O/Os, and other Collaborative O/Os would all have access to the SSA info and
reports that are generated by the DTE. The 18 SDS & 19 SDS may also use the DTE to upload files and exchange
information with the other DTE users in the UE.
It is likewise worth noting that some network arrows from Fig. 3 are not relevant to Fig. 5. For example, in honor
of the focus on space-based debris detection by sensors outside the purview of the SSN, the Observable RSO Data
Collection Sub-Entity in Fig. 5 does not receive sensor tasking commands from the 18 SDS & 19 SDS, collect RSO
position and velocity data from the Observable LEO RSOs, or transmit processed RSO position and velocity data to the
Operation and Management Sub-Entity. As this strictly descriptive digital twin architecture does not include predictive
or prescriptive functionalities, the DTE would not generate CDMs or CANs for relevant users, and O/Os would not send
commands for COLA maneuvers to the Controllable LEO RSOs through the Cooperative S/C Control Sub-Entity or
provide the associated maneuver notifications through the DTE.
Finally, the CSE in this architecture operates in a capacity similar to the CSE from the prescriptive architecture
discussed in Section III.
B. Mapping of Functional Entities
Figure 6 offers a lower-level visualization of the individual FEs embedded within the major entities and sub-entities
in Fig. 5. Given that Fig. 6 is effectively derived from—and shares a color scheme with—Fig. 4, the goal of this section
is to identify key formal and functional differences among the FEs embedded within the two frameworks.
To begin, since a large-scale process for space-based debris detection is yet to be developed, many of the FEs in Fig.
6 are genericized from their counterparts in Fig. 4. For example, within the DTE, the Mission Control Visualization
and Space-Track Application FEs specific to 18 SDS & 19 SDS are replaced with the more generic Visualization
Software and Web-Based SSA Application FEs, respectively, that would offer very similar functionalities. Likewise,
within the CSE, the 19 SDS Conversion Utility Software and Data Assurance & Formatting FEs are replaced with
Data Translation FE and Data Assurance FE, respectively.
Since the focus of the application is space-based detection of sub-10-cm-class RSOs, the FEs within the Observable
LEO RSOs entity have been updated accordingly. The Uncontrollable LEO RSOs sub-entity includes only Small
Debris (< 10 cm), and the Controllable LEO RSOs sub-entity emphasizes Collaborative O/O Spacecraft. As defined
in Section III, strictly Cooperative O/O Spacecraft would not be expected to collect or share information on their local
RSOs or to maneuver in response to a CDM or CAN in a strictly descriptive digital twin. However, the Collaborative S/C
Data Collection Sub-Entity now includes a Space-Based Sensors FE to account for the Collaborative O/O Spacecraft
sensors collecting data on Small Debris (< 10 cm).
Similarly, for this application, the functionality of the Observable RSO Data Collection Sub-Entity is significantly
reduced, with the U.S. Space Surveillance Network FE and corresponding Data Collection and Storage and Data
Processing FEs having no counterparts in Fig. 6. The RSO Identification & Track Correlation FE, which is required
for identifying the individual debris objects and correlating tracks from thousands of S/C sensors [
17
,
25
,
26
,
35
], could
12
Fig. 5 A higher-level descriptive digital twin architecture for space-based orbital debris detection, with a focus
on the information exchanged among major entities, sub-entities, and functional entities.
13
Fig. 6 A lower-level descriptive digital twin architecture for space-based orbital debris detection, with a focus
on enumerating the functional elements constituting the entities and sub-entities.
14
have reasonably been placed within the DTE without loss of generality or function. However, to maximize consistency
with Fig. 4, the RSO Identification & Track Correlation FE is captured within the Observable RSO Data Collection
Sub-Entity. Consequently, the Operation and Management Sub-Entity, after receiving O/O RSO Ephemerides from
Collaborative O/Os, passes them to the Observable RSO Data Collection Sub-Entity, wherein the RSO Identification &
Track Correlation FE processes the provided data and returns unique RSO IDs to the DTE.
Beyond this, the outputs of the Operation and Management Sub-Entity—that is, the required inputs for an orbital
simulation—are largely the same in both cases. However, due to the absence of any propagation and prediction
functionalities in a strictly descriptive digital twin, the Simulation & Orbit Propagation and Data Analysis & Conjunction
Detection FEs from Fig. 4 have no counterparts in Fig. 6. Likewise, the SuperCOMBO Report & CDM Generator
of Fig. 3 is reduced in scope to a generic Report Generator, which would upload reports to the Web-Based SSA
Application to make SSA info available to authorized users. However, the Digital Modeling & Orbit Determination
FE persists, as it is essential for determining the current state of sub-10-cm-class RSOs in the LEO space environment
[
9
]. Since the scope of this DTF is intentionally limited to descriptive functionality, the adaptation of any FEs from Fig.
4 that offer higher functionality is relegated as future work.
Finally, the Resource Access Sub-Entity now includes a Peer Interface FE, which previously appeared in the
ISO 23247 architecture of Fig. 2 but was not included in the prescriptive architecture of Fig. 4. As mentioned in
Section III, the Peer Interface FE enables interactions with other digital twins. For this application, this would allow a
digital twin derived from the descriptive DTF for space-based orbital debris detection, as described in this section, to
share information with a digital twin derived from the prescriptive DTF for on-orbit collision avoidance, as described
in Section III, enabling further improvement of overall space situational awareness and on-orbit collision avoidance
systems.
Although the scope of the descriptive DTF presented in this section appears limited in comparison to the prescriptive
DTF presented in Section III, it is important to note that the former is novel, whereas the latter describes a process that
has existed in various forms for many years [
9
]. As the space-based debris detection DTF matures and encapsulates
additional functionalities over the years, the scope of the two frameworks presented in this report will grow to be
comparable.
C. Representative Use-Case
As mentioned in Section I, the number of active satellites in LEO has increased dramatically in recent years [
7
].
A significant source of this proliferation is mega-constellations of spacecraft providing satellite internet services [
7
].
Suppose that a particular satellite internet provider—one of the Collaborative O/Os—has hundreds or thousands of
microsatellites—Collaborative O/O Spacecraft—distributed across a variety of orbits between 500 km and 600 km in
altitude above Earth’s surface. By design, each of these satellites has at least two optical Space-Based Sensors known as
star trackers, which are nominally used to determine the attitude of the spacecraft by capturing images of distant stars
and comparing them to onboard star catalogs [
13
]. Incidentally, these images also often capture adequately illuminated
RSOs that are nearby and within the star tracker’s field of view [
13
,
17
]. In particular, when the star trackers are not
actively being used for attitude determination, they can be used to passively collect SSA data on sub-10-cm-class RSOs
within 50 km of the satellite [
17
]. Consequently, the constellation as a whole can collect SSA data for RSOs in this size
regime for altitudes between 450 km and 650 km above Earth’s surface.
Several times per day, these spacecraft can use radio frequency waves (e.g., UHF-band, S-band, X-band, etc.) [
20
]
to transmit collected star tracker images (and associated time, position, velocity, attitude, and angular velocity data
[
35
]) to compatible commercial radio frequency antennas on Earth’s surface [
20
]. The amount of data satellites can
transmit along space-to-ground links is often limited by technical capabilities, licensing regulations, and environmental
conditions [
20
], so their respective O/Os may choose to downlink only a subset of the collected star tracker images,
informed possibly by requests from the 18 SDS & 19 SDS, during a given ground contact opportunity. In any case, the
downlinked images are then processed on ground-based computers using techniques such as those described in [
36
] for
streak detection, [37] for light modeling and space object classification, and [14] and [15] for RSO state estimation.
The development and deployment of these and other data processing algorithms for star tracker images of incident
RSOs are areas of ongoing research. In fact, recent advances in onboard RSO state estimation suggest that, in the near
future, spacecraft may be able to use their onboard computer(s) to efficiently estimate the position and velocity of RSOs
captured in their star tracker images [
35
]. If this is realized, instead of transmitting a small number of comparatively
large image files, spacecraft with such capabilities would be able to transmit smaller sets of pre-processed RSO SSA
data for a larger number of RSOs, further increasing the value provided by space-based space surveillance [35].
15
Once processed, these data are ingested into the Digital Twin Entity for modeling and visualization of the partial
LEO RSO environment, as it pertains to sub-10-cm-class RSOs. As users of this digital twin, the 18 SDS & 19 SDS can
access and ingest these SSA data through the Web-Based SSA Application and, per the existing prescriptive collision
avoidance process, provide CDMs and CANs to Cooperative O/Os and Collaborative O/Os, as required [
9
]. This cycle
continues indefinitely, substantially improving the U.S. government’s awareness of the space domain in this region of
LEO and its corresponding ability to prevent in-space collisions with small debris particles therein.
V. Conclusion
In response to recommendations by the AIAA Digital Engineering Integration Committee encouraging the
development of standard digital twin reference models for aerospace applications [
5
], this paper has proposed—and
demonstrated the feasibility of—adapting existing digital twin standard frameworks from other application domains
for aerospace applications. In particular, the ISO 23247 standard for digital twins in manufacturing has been adapted
for the first time to a non-manufacturing aerospace application—on-orbit collision avoidance. The well-established
process involving the U.S. SSN, 18 SDS, and 19 SDS for on-orbit collision avoidance in LEO has been captured within
a prescriptive digital twin framework that seeks to represent the LEO RSO space environment.
This architecture for an established process is, in turn, adapted for a similar, novel application involving sub-10-cm-
class orbital debris detection by on-orbit satellites, which continues to be an active area of research [
17
,
18
]. Although
the focus is on sub-10-cm-class debris, the (currently) descriptive digital twin framework can be expanded to include
space-based measurements for RSOs of any size or class and can even be combined with ground-based frameworks to
be used in generating a more comprehensive digital twin of the LEO space environment. It is worth noting that the
number of sub-10-cm-class debris in LEO is estimated to be in the millions [
8
] and that the techniques for processing
space-based sensor images for RSO data can be computationally expensive [
14
,
15
,
35
–
37
], so a digital twin seeking to
represent this many RSOs may encounter computational limitations. However, if sensing capabilities and computational
power allow, digital twins derived from this framework can even be extended beyond LEO to geosynchronous altitudes
or higher.
This work offers a novel approach for the standardization of digital twins in the aerospace industry based on
already-published standards and serves as a foundation for the development of formal digital twins with applications in
space-based orbital debris detection and collision avoidance. A digital twin derived from the descriptive framework
presented in this paper can be augmented over time to offer increasingly sophisticated functionalities—diagnostic,
predictive, prescriptive, and intelligent—through the integration of additional digital and physical elements. For example,
integration of the sub-10-cm-class debris data offered by a descriptive debris detection digital twin with the baseline
data in the SSN RSO catalog would augment the capabilities and value of the existing prescriptive collision avoidance
process. With additional effort, a layer of artificial intelligence could be added to enable a satellite within a cooperative
network of satellites to autonomously correct its trajectory to avoid a debris particle detected by another satellite within
the same network.
The result is a roadmap from a basic (but useful) descriptive model that focuses primarily on sub-10-cm-class debris
detection and monitoring to an intelligent system that enables autonomous collision avoidance within a satellite network.
Moreover, encoding these architectures into formal standards is expected to promote top-down adoption of digital
twin technologies in the satellite industry, encourage informed space traffic management policy efforts, and reduce the
labor burden on the SSN, 18 SDS, 19 SDS, and other relevant U.S. government agencies. Thus, the development and
standardization of each of these frameworks is the subject of future work.
Acknowledgments
Allan Shtofenmakher would like to thank the Graduate Fellowships for STEM Diversity (GFSD) and the National
Institute of Standards and Technology (NIST) Graduate Student Measurement Science and Engineering (GMSE)
fellowship program for the partial financial support enabling him to pursue his degree. He would also like to thank
Sydney Dolan for technical discussions regarding existing processes in the field of space traffic management, as well as
for overall manuscript feedback.
References
[1]
Shao, G., Shin, S.-J., and Jain, S., “Data analytics using simulation for smart manufacturing,” Proceedings of the Winter
Simulation Conference 2014, Savannah, GA, 2014, p. 2192–2203. URL
https://doi.org/10.1109/WSC.2014.7020063
.
16
[2]
Miskinis, C., “The history and creation of the digital twin concept,” Online, March 2019. URL
https://www.challenge.
org/insights/digital-twin- history/, accessed: 2023-05-24.
[3]
Erwin, S., “Digital twins gaining traction in military satellite programs,” Online, June 2023. URL
https://spacenews.com/
digital-twins- gaining-traction- in-military- satellite-programs/, accessed: 2023-11-27.
[4]
Holt, B., “SpaceWERX awards 124 Orbital Prime contracts,” Online, November 2022. URL
https://www.afrl.af.mil/
News/Article-Display/Article/3210527/spacewerx- awards-124- orbital-prime- contracts/
, accessed: 2023-
11-27.
[5]
AIAA Digital Engineering Integration Committee, “Digital Twin: Reference Model, Realizations & Recommendations,” AIAA
Science and Technology Forum and Exposition, National Harbor, MD, 2023. URL
https://www.aia-aerospace.org//wp-
content/uploads/Digital-Twin- Implementation-Paper_Dec_2022.pdf.
[6]
ISO 23247:2021, “Automation systems and integration — Digital twin framework for manufacturing,” Standard, International
Organization for Standardization, Geneva, Switzerland, October 2021. URL https://www.ap238.org/iso23247/.
[7]
Hiles, R., Alexander, A., Herzer, N., McKissock, D., Mitchell, A., and Sapinoso, J., “Report on 2020 Mega-Constellation
Deployments and Impacts to Space Domain Awareness,” Advanced Maui Optical and Space Surveillance Technologies
Conference, Maui, HI, 2021. URL https://amostech.com/TechnicalPapers/2021/SSA-SDA/Hiles.pdf.
[8]
Hobbs, K. L., Collins, A. R., and Feron, E. M., “Towards a Taxonomy for Automatic and Autonomous Cooperative Spacecraft
Maneuvering in a Space Traffic Management Framework,” AIAA ASCEND, 2020. URL
https://doi.org/10.2514/6.2020-
4240.
[9]
18th Space Control Squadron, Spaceflight Safety Handbook for Satellite Operators, United States Space Force, Vandenberg
Space Force Base, CA, ver. 1.5 ed., August 2020. URL
https://www.space-track.org/documents/Spaceflight_
Safety_Handbook_for_Operators.pdf, accessed: 2023-04-25.
[10]
Wei-Haas, M., “Space junk is a huge problem—and it’s only getting bigger,” Online, May 2021. URL
https://www.
nationalgeographic.com/science/article/space-junk, accessed: 2023-08-15.
[11]
Lal, B., Balakrishnan, A., Caldwell, B. M., Buenconsejo, R. S., and Carioscia, S. A., “Global Trends in Space Situational
Awareness (SSA) and Space Traffic Management (STM),” Tech. Rep. D-9074, Log H 18-000179, Institute for Defense
Analyses Science and Technology Policy Institute, Washington, DC, April 2018. URL
https://apps.dtic.mil/sti/pdfs/
AD1123106.pdf.
[12]
Hobbs, K. L., “Elicitation and Formal Specification of Run Time Assurance Requirements for Aerospace Collision Avoidance
Systems,” PhD dissertation, Georgia Institute of Technology, Atlanta, GA, May 2020. URL
http://hdl.handle.net/1853/
62788.
[13]
Liu, M., Wang, H., Yi, H., Xue, Y., Wen, D., Wang, F., Shen, Y., and Pan, Y., “Space Debris Detection and Positioning Technology
Based on Multiple Star Trackers,” Applied Sciences, Vol. 12, No. 7, 2022. URL
https://doi.org/10.3390/app12073593
.
[14]
Clemens, S., Lee, R., Harrison, P., and Soh, W., “Feasibility of Using Commercial Star Trackers for On-Orbit Resident
Space Object Detection,” Advanced Maui Optical and Space Surveillance Technologies Conference, Maui, HI, 2018. URL
https://amostech.com/TechnicalPapers/2018/Space-Based_Assets/Clemens.pdf.
[15]
Dave, S., Clark, R., Chianelli, G., and Lee, R., “Machine learning implementation for in-orbit RSO orbit estimation using
star tracker cameras,” Advanced Maui Optical and Space Surveillance Technologies Conference, Maui, HI, 2022. URL
https://amostech.com/TechnicalPapers/2020/Machine-Learning- Applications-of- SSA/Dave.pdf.
[16]
Dave, S., and Lee, R., “RSO position and velocity estimation using Convolutional Neural Networks from in-orbit star tracker
images,” 43rd Committee on Space Research Scientific Assembly, 2021.
[17]
Shtofenmakher, A., and Balakrishnan, H., “Feasibility Analysis of On-Orbit Debris Detection Using Commercial Star
Trackers,” IAA Space Traffic Management Conference, Austin, TX, 2023. URL
https://web.tresorit.com/l/b2cgc#
8T1h86yuZ2SdwScwfc_vtA&viewer=PRWRtmo2rg8agY3sFb9x0QCirmMkiMKV.
[18]
Shtofenmakher, A., and Balakrishnan, H., “Effects of Phase Angle and Sensor Properties on On-Orbit Debris Detection Using
Commercial Star Trackers,” IAF International Astronautical Congress, Baku, Azerbaijan, 2023.
[19]
Weeden, B., “Space Situational Awareness Fact Sheet,” Online, May 2017. URL
https://swfound.org/media/205874/
swf_ssa_fact_sheet.pdf, accessed: 2023-07-20.
17
[20]
Wertz, J. R., Everett, D. F., and Puschell, J. J., Space Mission Engineering: The New SMAD, Space Technology Library; v. 28,
Microcosm Press, Hawthorne, CA, 2011.
[21]
Shao, G., “Use Case Scenarios for Digital Twin Implementation Based on ISO 23247,” Tech. rep., Advanced Manufacturing
Series (NIST AMS) 400-2, National Institute of Standards and Technology, Gaithersburg, MD, May 2021. https://doi.org/10.
6028/NIST.AMS.400-2, URL https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=932269.
[22] Kelso, T. S., “SOCRATES Plus,” Online, July 2023. URL https://celestrak.org/SOCRATES/, accessed: 2023-07-24.
[23]
Fossà, A., Losacco, M., and Armellin, R., “Perturbed Initial Orbit Determination,” arXiv:2306.09699, July 2023. URL
https://arxiv.org/pdf/2306.09699.pdf, accessed: 2023-08-07.
[24]
NASA Spacecraft Conjunction Assessment and Collision Avoidance Best Practices Handbook, NASA, Washington, DC,
December 2020. URL https://nodis3.gsfc.nasa.gov/OCE_docs/OCE_50.pdf, accessed: 2023-08-07.
[25]
Berger, J. M., Moles, J. B., and Wilsey, D. G., “An Analysis of USSPACECOM’s Space Surveillance Network Sensor Tasking
Methodology,” MS thesis, Air Force Institute of Technology, Wright-Patterson Air Force Base, OH, November 1992. URL
https://apps.dtic.mil/sti/tr/pdf/ADA258971.pdf.
[26]
Hill, K., Sabol, C., and Alfriend, K. T., “Comparison of Covariance-Based Track Association Approaches Using Simulated Radar
Data,” The Journal of the Astronautical Sciences, Vol. 59, No. 1–2, 2012, pp. 287–306. URL https://doi.org/10.1007/s40295-
013-0018-1.
[27]
CCSDS 320.0-M-7, “CCSDS Spacecraft Identification Field Code Assignment Control Procedures,” Recommended Practice,
The Consultative Committee for Space Data Systems (CCSDS), Washington, DC, July 2019. URL https://public.ccsds.org/
Pubs/320x0m7c1.pdf.
[28]
Kitterman, L., “French Delegation visits CSpOC during CFSCC immersion,” Online, April 2022. URL https://www.safia.hq.af.
mil/IA-News/Article/3006896/french-delegation-visits-cspoc-during-cfscc- immersion/, accessed: 2023-07-24.
[29]
United States Space Force, “Combined Space Operations Center / Space Delta 5 Fact Sheet,” Online, August 2021.
URL https://www.vandenberg.spaceforce.mil/Portals/18/documents/CFSCC/CSpOC_DEL5_FactSheet_6Aug21.pdf?ver=
z3kgshJ87XDdNvYA0Ak61A%3D%3D, accessed: 2023-07-24.
[30]
United States Space Force, “19th Space Defense Squadron,” Online, January 2023. URL https://www.spacebasedelta1.
spaceforce.mil/About-Us/Fact-Sheets/Display/Article/1060278/19th- space-defense-squadron/, accessed: 2023-07-24.
[31]
18th Space Control Squadron, Launch Conjunction Assessment Handbook, United States Space Force, Vandenberg Space
Force Base, CA, ver. 1.0 ed., December 2018. URL https://www.space-track.org/documents/LCA_Handbook.pdf, accessed:
2023-04-25.
[32]
Sharma, J., Stokes, G. H., von Braun, C., Zollinger, G., and Wiseman, A. J., “Toward Operational Space-Based Space
Surveillance,” Lincoln Laboratory Journal, Vol. 13, No. 2, 2002, pp. 309–334. URL https://archive.ll.mit.edu/publications/
journal/pdf/vol13_no2/13_2spacesurveillance.pdf.
[33]
The Johns Hopkins University Applied Physics Laboratory, “Mission Complete: APL-Operated Midcourse Space Experiment
Ends,” Online, July 2008. URL https://www.jhuapl.edu/news/news-releases/080716_2-mission- complete-apl-operated-
midcourse-space-experiment-ends, accessed: 2023-07-26.
[34]
Air Force Space Command, “Space Based Space Surveillance,” Online, July 2019. URL https://www.afspc.af.mil/About-
Us/Fact-Sheets/Article/249017/space- based-space-surveillance/, accessed: 2023-07-20.
[35]
Spiller, D., Magionami, E., Schiattarella, V., Curti, F., Facchinetti, C., Ansalone, L., and Tuozzi, A., “On-Orbit Recognition of
Resident Space Objects by Using Star Trackers,” Acta Astronautica, Vol. 177, 2020, pp. 478–496. URL https://doi.org/10.1016/
j.actaastro.2020.08.009.
[36]
Varela, L., Boucheron, L., Malone, N., and Spurlock, N., “Streak Detection in Wide Field of View Images Using Convolutional
Neural Networks (CNNs),” Advanced Maui Optical and Space Surveillance Technologies Conference, Maui, HI, 2019. URL
https://amostech.com/TechnicalPapers/2019/Machine-Learning- for-SSA-Applications/Varela.pdf.
[37]
Linares, R., and Furfaro, R., “Space Object Classification Using Deep Convolutional Neural Networks,” 19th International
Conference on Information Fusion, Heidelberg, Germany, 2016. URL https://ieeexplore.ieee.org/document/7528013.
18
