The Advanced Research Collaboration and Application Development Environment (ARCADE) is a collaboration project between the ASTRIA Research Group at the University of Texas at Austin, the IBM Space Tech team, and other partners. The goal of this repository is to provide a unified and coherent API for accessing, analyzing, and extending a diverse set of derived data points concerning an anthropogenic space object (ASO). Note: this repository currently represents a small proof of concept and is in a very alpha state of development, so APIs (internal and external) may change greatly.
The ARCADE platform ingests data from multiple raw and preprocessed sources including telescopes, radar arrays, and TLE data from different providers and fuses it into a coherent view of each ASO. This data fusion is done in ASTRIAGraph with the data being stored in the graph database or IBM's cloud object storage (COS) depending on the data type. A RESTful API is then used to provide access to this rich data to developers and client applications.
Interactive documentation for the API where you can try it out in a web browser is available here. The currently provided endpoints that you can programmatically test via the base URI https://arcade.spacetech-ibm.com are:
| Endpoint | Description |
|---|---|
| /asos | Returns basic information on all the ASOs that ARCADE knows about like its name and various identifiers |
| /aso | Returns the basic information for a single ASO |
| /ephemeris | Provides the most up-to-date ephemeris data for an ASO |
| /interpolate | Uses UT's orbdetpy library to interpolate the ephemeris data for the ASO to the specified temporal frequency |
| /compliance | Returns whether or not the ASO is compliant in registering with UNOSSA |
The conjunction search demo of the space situational awareness project now uses the /ephemeris ARCADE API endpoint to gather the up-to-date orbit state vector data and then determine the nearest conjunctions of each satellite. 
Daniel Kucharski of the University of Texas at Austin has developed a C++ library for determining how much light pollution a terrestrial based astronomical observatory will experience over a given time period due to ASOs passing overhead. This demo utilizes ARCADE's /interpolate endpoint and the satellite light pollution library to show the brightness of ASOs currently above the New Mexico skys. Redder objects are brighter while bluer objects are more dim. 
In this demo we combine ASTRIAGraph and the \compliance ARCADE endpoint to show what ASOs are in compliance with UNOSSA's registration requirements. 
The ARCADE PoC is developed using Python 3.8 with the FastAPI framework. We utilize docker and docker-compose to develop, test, and deploy the API. The PoC API and all of the demos mentioned above are deployed on Red Hat's OpenShift platform on IBM Cloud. A makefile is provided to run most of the common development tasks like:
| Command | Description |
|---|---|
make build |
Builds a docker image |
make clean |
Removes all built docker images |
make type_check |
Uses mypy to type check the code base |
make test |
Runs the test suite |
make run |
Runs the API locally at http://localhost:8080 |
The ARCADE project is meant to be extended by allowing community members to add new data sources, algorithms, and API endpoints.
The ARCADE PoC utilizes the neo4j graph database as the operational data store. The current schema has the following entity-relationship diagram.
The SpaceObject node type is used to store data about an ASO that does not frequently change like various catalog IDs and the object's name. When adding new data nodes, they should be linked from the specific SpaceObject node. The DataSource, COSBucket, and COSObject node types are used to track the provenance of imported data into the graph. The User node type is used to store information used in the authentication and authorization process. The has_access relationship is used to determine if a User has the permission to access the data provided by the DataSource. If a DataSource node has the public property set to True then every User node in the database will have access to all data provided by the DataSource. The accessed relationship is used to keep track of when and through what API endpoint the User accessed a data node. We use the neomodel object graph mapper (OGM) in the graph module to define the properties and relationships between the various nodes in the graph. Node type models that provide data for a SpaceObject from a DataSource should inherit from the BaseAccess class, which adds the necessary relationships for managing User access to the data. The FindMixin class provides useful functions for querying the various node types in the graph.
The importers package is where scripts are kept that import data into the graph. An importer class should implement a run method that takes no arguments. The run function should be idempotent with regards to the state of the graph and should keep track of what data needs to be imported. See the UT OEM, Starlink OEM, and UN Compliance importers as examples.
The API models module implements pydantic models that are served by the API. The API models are used to validate that the data is valid and the model's Config is used to make turning a graph model into an api model seamless. The API model is the place to implement new algorithms atop of existing data models. See the interpolate method of the OrbitEphemerisMessage class as an example.
The FastAPI endpoints can be found in the API module. When exposing data from a DataSource, the endpoint should check that the User has the appropriate permissions using the can_access method on the User instance, and then add an accessed relationship in the graph containing the endpoint used. See the /ephemeris, /interpolate, and /compliance endpoints as examples.
We very much encourage anyone and everyone to join and contribute to this project. Please see the contributing file for more details.
ARCADE is licensed under the Apache 2.0 license. Full license text is available at LICENSE.