Student Innovation-Space technology refers to the application of engineering principles to the design, development, manufacture, and operation of devices and systems for space travel and exploration.

1. Executive Snapshot

This research and architecture dossier provides an operational blueprint for student engineering teams competing in the Smart India Hackathon (SIH) under problem statement SIH26209. The challenge calls for applying software and systems engineering principles to the design, development, manufacture, and operation of devices and systems for space travel and exploration [PS]. Because the problem statement is open-ended under the AICTE MIC Student Innovation Software stream [PS], winning teams must avoid generic toy models and deliver a high-impact, mathematically sound, software-driven mission planning, telemetry monitoring, and orbital conjunction analysis system [INFERENCE]. The proposed solution—AstraNet: Open Orbital Mission Control & Conjunction Intelligence Platform—combines real-time SGP4 orbital propagation, telemetry anomaly detection, ground station pass scheduling, and Earth observation workflow integration into a production-grade Web-GIS application tailored for university small-satellite (CubeSat) programs and space technology researchers [INFERENCE].

Metadata Table

Fundamental System Objective

To deliver a web-native, modular orbital mechanics, telemetry monitoring, and conjunction threat assessment platform that equips student satellite developers and researchers with professional-grade space mission operations capabilities using open spatial data standards [INFERENCE].

2. Problem Deconstruction

The problem description provided in the source of truth is:

"Student Innovation-Space technology refers to the application of engineering principles to the design, development, manufacture, and operation of devices and systems for space travel and exploration." [PS]

To make this high-level definition actionable, it is deconstructed into explicit requirements [PS] and logically derived derived requirements [INFERENCE].

Atomic Requirements Table

3. Stakeholders & User Needs

4. Requirements Traceability

5. Constraints & Environment Realities

1. Hardware & Graphics Constraints: 3D rendering in WebGL/CesiumJS can cause high GPU and CPU utilization on standard student laptops. The system must support fallbacks to 2D Leaflet/OpenLayers canvas rendering [INFERENCE].
2. Network Bandwidth in Field / Hackathon Venues: Hackathon environments often suffer from congested Wi-Fi. Large 3D Earth tile downloads and satellite catalog payloads must be cached locally using IndexedDB and Service Workers [INFERENCE].
3. Data Access Restrictions: Real-time military or classified space situational awareness feeds (e.g., high-precision TOLD/CPF files) are restricted. The system must rely on public NORAD Two-Line Element (TLE) sets from CelesTrak [KNOWN].
4. Computational Limits for Orbit Propagation: Propagating thousands of space objects simultaneously in the browser main thread will freeze the UI. Orbit calculations must run in Web Workers or offloaded to a multi-threaded Python backend [INFERENCE].
5. No Access to Operational Spacecraft: Student teams cannot connect to live active satellites during a hackathon. Telemetry must be generated via a high-fidelity simulator that streams realistic CCSDS-structured frames [ASSUMPTION].

6. Research Questions

1. How can SGP4 propagation be executed efficiently in Javascript/Web Workers vs. Python backend services for sub-second position updates of 1,000+ satellites? [INFERENCE]
2. What are the public REST APIs and data formats available from ISRO (VEDAS, MOSDAC, Bhuvan) and NASA (GIBS, CelesTrak) for open satellite tracking and Earth observation? [RESEARCHED]
3. How can isolation forest ML models be deployed on multi-parameter spacecraft telemetry streams to detect out-of-nominal thermal/electrical behavior? [INFERENCE]
4. What open-source standards exist for space mission control web interfaces (e.g., NASA Open MCT plugins)? [RESEARCHED]

7. Data Requirements & Sources

8. Existing Solutions & Gap Analysis

+-----------------------------------------------------------------------------------+
|                            EXISTING SOLUTIONS LANDSCAPE                           |
+-----------------------------------+-----------------------------------------------+
| Commercial / Heavy Desktop        | Open Source / Special Purpose                 |
| - Ansys STK (System Tool Kit)     | - NASA Open MCT (Mission Control Tool)        |
|   - Proprietary, expensive            - Telemetry UI focus, lacks SGP4 3D engine   |
|   - Steep learning curve              - Requires custom backend integration       |
| - NASA GMAT / Orekit              | - SatNOGS Network                             |
|   - Desktop flight dynamics           - Ground station crowd-sourcing, radio focus|
+-----------------------------------+-----------------------------------------------+
                                    |
                                    v
+-----------------------------------------------------------------------------------+
|                        PROPOSED SOLUTION: AstraNet Console                        |
| - Web-native unified 3D Globe + SGP4 Orbit Dynamics Engine                        |
| - Real-time WebSocket Telemetry Parsing + Isolation Forest Anomaly Detection     |
| - Conjunction Threat Assessor (<10km proximity detection)                         |
| - Free, open-source stack tailored for university CubeSat teams                    |
+-----------------------------------------------------------------------------------+

1. Ansys STK (Systems Tool Kit)

• Description: Industry-standard aerospace simulation software for orbit propagation, link budgets, and sensor coverage [KNOWN].
• Strengths: High-fidelity numerical propagators (HPOP), comprehensive physics environment [KNOWN].
• Weaknesses: Highly expensive commercial licensing, desktop-only, heavy installation (>10 GB), complex learning curve [KNOWN].
• Relevance: Gold standard for space mission analysis [KNOWN].
• Gap: Inaccessible to most Indian university students and hackathon teams due to licensing and hardware costs [INFERENCE].
• Source: Ansys STK Official Documentation [RESEARCHED]
• Confidence: [KNOWN]

2. NASA Open MCT (Open Mission Control Technologies)

• Description: Open-source web-based visualization framework for telemetry data developed by NASA Ames Research Center [RESEARCHED].
• Strengths: Modular telemetry display panels, historical telemetry scrubbing, proven in NASA rover and satellite ops [RESEARCHED].
• Weaknesses: Lacks built-in 3D orbit propagation engines, requires custom backend integration for orbital dynamics and conjunction analysis [RESEARCHED].
• Relevance: Exemplary architecture for telemetry monitoring UI [RESEARCHED].
• Gap: Does not provide out-of-the-box orbit prediction, debris tracking, or Earth observation layer integration [INFERENCE].
• Source: NASA Open MCT Portal [4.3], [4.11]
• Confidence: [RESEARCHED]

3. SatNOGS (Satellite Networked Open Ground Station)

• Description: Open-source global network of crowdsourced satellite ground stations managed by Libre Space Foundation [RESEARCHED].
• Strengths: Global radio observation database, open-source hardware rotator designs, waterfall audio processing [RESEARCHED].
• Weaknesses: Focused primarily on RF observation and signal reception rather than end-to-end satellite mission management and trajectory simulation [RESEARCHED].
• Relevance: Excellent model for open-source space hardware/software ecosystems [RESEARCHED].
• Gap: Lacks integrated full-orbit conjunction intelligence, ML telemetry health diagnostics, and mission planning tools [INFERENCE].
• Source: Libre Space Foundation Projects [3.2]
• Confidence: [RESEARCHED]

9. Candidate Solution Approaches

Approach 1: Lightweight Client-Only Web-GIS (Three.js + SGP4 JS)

• Mechanism: Runs SGP4 orbital propagation entirely inside the browser using JavaScript libraries (satellite.js) and Three.js / CesiumJS for rendering.
• Problem Fit: High frontend interactivity, zero backend deployment overhead.
• Accuracy Potential: Moderate (SGP4 analytical model accuracy ~1 km at epoch) [KNOWN].
• Data Requirements: Direct CORS fetch of CelesTrak TLE text files.
• Complexity: Low.
• Explainability: High (Standard Keplerian mechanics).
• Cost: Zero server costs (hosted on GitHub Pages or Vercel).
• Scalability: Limited by client browser CPU/GPU performance (max ~100 satellites before UI lag).
• Hackathon Feasibility: Very High (Build time 1–2 days).
• Production Feasibility: Low (Cannot perform backend batch processing, ML anomaly detection, or long-term historical data storage).

Approach 2: Native Desktop Flight Dynamics Suite (Python / PySide6 + Orekit / C++)

• Mechanism: Desktop application written in Python using Qt/PySide6, leveraging Orekit (Java/Python wrapper) for high-precision orbit determination and numerical propagation (dopri853 integrator).
• Problem Fit: High computational accuracy for aerospace simulation.
• Accuracy Potential: Extremely High (Includes atmospheric drag models, solar radiation pressure, geopotential J2-J4).
• Data Requirements: Local TLE databases, Earth Orientation Parameters (EOP) files.
• Complexity: Very High (Requires JVM integration, complex build steps, native installers).
• Explainability: High.
• Cost: Low hosting, but high setup friction.
• Scalability: Single workstation scope.
• Hackathon Feasibility: Medium-Low (Integration hurdles with JVM/Python in 36 hours).
• Production Feasibility: High for individual flight dynamics engineers, Low for multi-user mission operations.

Approach 3: Hybrid Web-GIS + Distributed Microservice Engine (FastAPI + SGP4/Orekit + CesiumJS + Isolation Forest ML) [RECOMMENDED]

• Mechanism: A decoupled architecture with a modern web frontend (React + CesiumJS) for 3D visualization, backed by a fast Python FastAPI backend. The backend handles background TLE sync, multi-threaded orbit propagation, conjunction screening, and WebSocket-based telemetry streaming with an Isolation Forest ML model for anomaly detection.
• Problem Fit: Perfect balance between rigorous backend aerospace physics and an accessible, interactive web interface.
• Accuracy Potential: High (SGP4 propagation + automated vector proximity checks).
• Data Requirements: CelesTrak REST APIs, NASA GIBS WMTS tiles, synthetic WebSocket telemetry generator.
• Complexity: Medium-High.
• Explainability: High (Deterministic physics for orbits, interpretable ML feature importance for telemetry).
• Cost: Low (Free tier cloud hosting on Render/Vercel or local Docker orchestration).
• Scalability: High (Backend can scale horizontally to handle 10,000+ space objects).
• Hackathon Feasibility: High for a 4–6 student team with frontend/backend split.
• Production Feasibility: High (Matches modern cloud-native aerospace ground software architecture).

10. Recommended Approach & Why

Selected Approach: Approach 3 (Hybrid Web-GIS + Python FastAPI Engine + CesiumJS) [ASSUMPTION].

Trade-Off Analysis & Rejection Justification

• Why Approach 1 was rejected: While client-only JavaScript propagation is easy to set up, it lacks backend processing power. Running space debris conjunction checks (comparing $N \times N$ orbital positions) in the browser thread crashes the page [INFERENCE]. Additionally, it cannot host background telemetry parsing or ML models.
• Why Approach 2 was rejected: Building a native C++/Java desktop application introduces severe build and distribution friction during judging. Judges must be able to view and interact with the system via a web browser without installing specialized Java/C++ runtime environments [INFERENCE].
• Why Approach 3 Wins:
  1. Separation of Concerns: The backend handles computational physics (SGP4), database caching, and ML inference, while the frontend focuses entirely on fluid 60 FPS 3D spatial rendering [INFERENCE].
  2. Demonstrable Engineering Depth: Integrates real REST APIs (CelesTrak), WebSockets (telemetry), ML algorithms (Isolation Forest), and 3D Web-GIS (CesiumJS) [INFERENCE].
  3. Hackathon Work Division: A 4–6 student team can cleanly divide work into Frontend/3D Globe, Backend API/Orbital Physics, Telemetry/ML Anomaly Engine, and UI/UX Strategy [INFERENCE].

11. Technical Architecture

+-----------------------------------------------------------------------------------+
|                                 ASTRA-NET FRONTEND                                |
|  +-----------------------------------+  +--------------------------------------+  |
|  |   CesiumJS 3D Earth Visualizer    |  |  Recharts / Telemetry Live Plots     |  |
|  |  - ECI/ECEF Satellite Tracks      |  |  - Voltage, Temp, Gyro Streams       |  |
|  |  - Sensor Footprint / Swath Cone  |  |  - Out-of-Limit Anomaly Badges       |  |
|  +-----------------------------------+  +--------------------------------------+  |
|  +-----------------------------------------------------------------------------+  |
|  |                       React 18 UI & State Controller                         |  |
|  +-----------------------------------------------------------------------------+  |
+------------------------------------------^----------------------------------------+
                                           | WebSockets / REST API (JSON)
+------------------------------------------v----------------------------------------+
|                                  FASTAPI BACKEND                                  |
|  +-----------------------------------+  +--------------------------------------+  |
|  |     Orbital Mechanics Engine      |  |     Telemetry & ML Anomaly Engine    |  |
|  |  - SGP4 Propagator (python-sgp4)  |  |  - Packet Parser (CCSDS / JSON)     |  |
|  |  - Conjunction Detector (CAD)     |  |  - Isolation Forest Anomaly Model    |  |
|  |  - Pass Scheduler (Az/El/Range)   |  |  - Limit Threshold Checker           |  |
|  +-----------------------------------+  +--------------------------------------+  |
|  +-----------------------------------------------------------------------------+  |
|  |                      Data Ingestion & Caching Layer                         |  |
|  |  - CelesTrak TLE Sync Job  | SQLite / Redis  | WMTS Map Proxy               |  |
|  +-----------------------------------------------------------------------------+  |
+------------------------------------------^----------------------------------------+
                                           | HTTPS GET / Tile Fetch
+------------------------------------------v----------------------------------------+
|                                 EXTERNAL DATA SOURCES                             |
|    +------------------------+   +-------------------+   +--------------------+    |
|    | CelesTrak NORAD TLEs   |   | NASA GIBS Tiles   |   | ISRO VEDAS / MOSDAC|    |
|    +------------------------+   +-------------------+   +--------------------+    |
+-----------------------------------------------------------------------------------+

Data-Flow Step-by-Step Narrative

1. Orbit Data Ingestion: The FastAPI backend executes an asynchronous background task that fetches active satellite Two-Line Element (TLE) sets from CelesTrak REST endpoints [RESEARCHED]. TLEs are parsed and cached in SQLite/Redis [ASSUMPTION].
2. Propagator Execution: When a frontend user requests a 3D orbit view, the backend passes TLE parameters into the sgp4 module to calculate Cartesian position ($\mathbf{r}$) and velocity ($\mathbf{v}$) vectors in the TEME (True Equator Mean Equinox) coordinate frame, converting them to WGS84 Geodetic coordinates (Lat, Lon, Alt) [KNOWN].
3. 3D Globe Rendering: Position streams are transmitted via JSON/REST or WebSockets to the React application, where CesiumJS updates the satellite position, orbit polyline, and ground track in real time [INFERENCE].
4. Conjunction Screening: The backend conjunction worker iterates through active satellite positions against cataloged space debris objects. If the Euclidean distance falls below a safety threshold (e.g., $d < 10\text{ km}$), a Conjunction Warning Alert is published [INFERENCE].
5. Telemetry Processing: A simulated telemetry microservice streams spacecraft subsystem parameters (Battery Voltage, Solar Panel Current, Magnetometer readings, Structure Temperature) over WebSockets at 1 Hz [ASSUMPTION].
6. ML Anomaly Detection: Incoming telemetry vectors pass through a pre-trained scikit-learn Isolation Forest model. If anomalous multivariate sensor patterns are detected, the system flags the telemetry frame with an alert severity score and highlights the metric on the live dashboard [INFERENCE].

12. Technology Stack

13. AI/ML Justification

+-----------------------------------------------------------------------------------+
|                        AI/ML ARCHITECTURE: TELEMETRY HEALTH                       |
|                                                                                   |
|   Telemetry Vector: [Voltage, Current, Temp, Gyro_X, Gyro_Y, Gyro_Z]              |
|                                     |                                             |
|                                     v                                             |
|                     +-------------------------------+                             |
|                     |   MinMax / Z-Score Scaler     |                             |
|                     +---------------+---------------+                             |
|                                     |                                             |
|                                     v                                             |
|                     +-------------------------------+                             |
|                     | Isolation Forest Anomaly Engine|                            |
|                     +---------------+---------------+                             |
|                                     |                                             |
|                      +--------------+--------------+                              |
|                      |                             |                              |
|                      v                             v                              |
|             [Nominal: Score >= -0.1]     [Anomaly: Score < -0.1]                  |
|                      |                             |                              |
|                      v                             v                              |
|              Green Status Indicator       Red Alert Badge + Feature              |
|                                           Contribution Highlight                  |
+-----------------------------------------------------------------------------------+

AI Component Details

• Purpose: Detect unexpected, out-of-nominal behavior in satellite telemetry streams (e.g., sudden battery drain coupled with anomalous thermal spikes) [INFERENCE].
• Model Type: Unsupervised Isolation Forest (sklearn.ensemble.IsolationForest) [ASSUMPTION].
• Input: Multi-variate numerical telemetry vector: [bus_voltage, bus_current, battery_temp, payload_temp, gyro_x, gyro_y, gyro_z, reaction_wheel_rpm] [ASSUMPTION].
• Output: Anomaly Score $[-1.0, 1.0]$ where values $< -0.1$ indicate abnormal system state, along with feature contribution weights [ASSUMPTION].
• Data Required: 1,000 historical synthetic telemetry frames under nominal orbital operations (sunlit vs. eclipse phases) [ASSUMPTION].
• Why AI is Preferable: Simple static thresholds fail when a parameter is technically within absolute safety bounds but abnormal for a specific orbital phase (e.g., solar panel current dropping to zero during sunlit orbit phase) [INFERENCE].
• Evaluation Metric: Anomaly Precision/Recall on synthetically injected fault datasets (e.g., simulated short circuits, reaction wheel friction spikes) [INFERENCE].
• Failure Mode: False positive flags during transient maneuvers.
• Human Oversight: High. ML flags are presented as visual telemetry warnings requiring operator confirmation; the system never executes autonomous telecommands [INFERENCE].

Explicit Non-AI Boundary

AI MUST NOT be used for orbital propagation or trajectory prediction. Trajectory propagation relies strictly on deterministic Newtonian dynamics, Keplerian gravity models, and validated SGP4 analytical physics (python-sgp4) [KNOWN]. Replacing physical orbital mechanics with neural network regression introduces dangerous drift, lack of explainability, and catastrophic position errors [INFERENCE].

14. Data Architecture & Offline/Low-Network Design

Database Schema (SQLite / JSON Schema)

-- Cached Satellite Two-Line Element Table
CREATE TABLE satellites (
    norad_id INTEGER PRIMARY KEY,
    name TEXT NOT NULL,
    tle_line1 TEXT NOT NULL,
    tle_line2 TEXT NOT NULL,
    epoch_datetime TIMESTAMP NOT NULL,
    category TEXT DEFAULT 'ACTIVE',
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Ground Station Table
CREATE TABLE ground_stations (
    station_id INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL,
    latitude REAL NOT NULL,
    longitude REAL NOT NULL,
    altitude_m REAL DEFAULT 0.0,
    min_elevation_deg REAL DEFAULT 10.0
);

-- Telemetry Frame Log Table
CREATE TABLE telemetry_logs (
    log_id INTEGER PRIMARY KEY AUTOINCREMENT,
    norad_id INTEGER NOT NULL,
    timestamp TIMESTAMP NOT NULL,
    bus_voltage REAL,
    battery_temp REAL,
    anomaly_score REAL,
    is_anomaly BOOLEAN DEFAULT 0,
    FOREIGN KEY(norad_id) REFERENCES satellites(norad_id)
);

Offline & Low-Network Strategies

1. Local Browser Caching: Frontend assets, standard 2D vector tile overlays, and public TLE files are cached using Service Workers and IndexedDB (Dexie.js) [ASSUMPTION].
2. Client-Side SGP4 Fallback: If the backend connection drops during field operations, the React client switches to executing satellite.js in a local Web Worker using previously cached TLEs [INFERENCE].
3. Bandwidth Reduction: Satellite state vectors ($\mathbf{r}, \mathbf{v}$) are calculated locally in 10-second increments rather than streaming high-frequency raw coordinate arrays from the server [INFERENCE].
4. Synchronization Strategy: On connection restoration, the client background sync worker updates local TLE stores with delta updates from the FastAPI backend [INFERENCE].

15. Security, Privacy & Governance

• Sensitive Data Protection: The system handles non-classified, open-access public satellite catalog data from NORAD/CelesTrak [KNOWN]. User ground station coordinate inputs are stored locally in browser storage or encrypted SQLite fields [ASSUMPTION].
• Authentication & Access Control: Role-Based Access Control (RBAC) implemented via JSON Web Tokens (JWT). Roles include:
  1. Viewer/Student: Can view 3D globe, track satellites, and view telemetry plots [INFERENCE].
  2. Mission Operator: Can configure telemetry alert thresholds, run custom conjunction analyses, and upload new TLE files [INFERENCE].
• System Encryption: All REST API communication and WebSocket streams strictly enforce HTTPS/WSS protocols [KNOWN].
• Data Ownership & Privacy: University teams retain ownership of uploaded custom CubeSat telemetry logs and sensor schemas [INFERENCE].
• Regulatory Compliance & Disclaimers: The software explicitly displays a system notice stating that conjunction assessments are computed using simplified SGP4 analytical models and public TLEs [INFERENCE]. It is intended for educational, research, and hackathon demonstration purposes and should not replace official space agency conjunction assessment reports [INFERENCE].

16. MVP Scope (Hackathon Build)

+-----------------------------------------------------------------------------------+
|                                 HACKATHON MVP SCOPE                               |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | [MUST BUILD - IN SCOPE]                                                     |  |
|  | - Interactive 3D CesiumJS Earth Globe with real-time orbit propagation       |  |
|  | - Live ingestion of CelesTrak TLE datasets for 50+ active satellites       |  |
|  | - Simulated WebSocket telemetry stream (Voltage, Temp, Gyro)                |  |
|  | - Isolation Forest ML telemetry anomaly badge indicator                     |  |
|  | - Ground station pass prediction engine (Azimuth, Elevation, Pass Window)  |  |
|  +-----------------------------------------------------------------------------+  |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | [SHOULD BUILD / NICE TO HAVE]                                              |  |
|  | - Automated Closest Approach Distance (CAD) debris conjunction alert panel  |  |
|  | - WMS/WMTS Earth Observation layer overlay (NASA GIBS / OpenStreetMap)     |  |
|  | - Offline Service Worker caching for mobile/field presentation             |  |
|  +-----------------------------------------------------------------------------+  |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | [OUT OF SCOPE / DESCRIBED ONLY]                                             |  |
|  | - Hardware RF Transceiver integration (UHD / GNU Radio SDR hardware)        |  |
|  | - High-precision numerical orbit integrators (HPOP / DOPRI853)                |  |
|  | - Autonomous orbital thrust maneuver command execution                      |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

In Scope

1. Interactive 3D Orbit Visualizer: Multi-satellite tracking on CesiumJS globe with ground track rendering and orbit line visualization using CelesTrak TLEs [ASSUMPTION].
2. Ground Station Pass Scheduler: Input custom Lat/Lon coordinates to compute next pass windows, rise time, set time, and max elevation angle [ASSUMPTION].
3. Telemetry Dashboard: Live WebSocket telemetry feed featuring battery voltage, solar panel current, and temperature, with live charts powered by Recharts [ASSUMPTION].
4. ML Anomaly Detector: Real-time evaluation of incoming telemetry frames using pre-trained Isolation Forest model [ASSUMPTION].
5. Conjunction Proximity Alert: Proximity screening between selected satellite and surrounding debris objects (< 50 km warning, < 10 km critical alert) [ASSUMPTION].

Described Only / Out of Scope

1. Physical SDR Hardware Downlink: Real-time RF demodulation using RTL-SDR hardware (simulated via WebSocket streaming JSON) [INFERENCE].
2. Flight Software Deployment: Deploying C Flight Software (cFS) binaries to ARM hardware targets [INFERENCE].
3. Proprietary High-Precision Orbit Propagators: Numerical perturbation integrators requiring full planetary gravity coefficient matrices (GRACE models) [INFERENCE].

17. Live Demo Simulation Plan

To ensure a seamless, fault-tolerant demo during SIH final judging without relying on external live downlinks or unstable internet, the team will implement a dedicated Simulation & Offline Suite:

+-----------------------------------------------------------------------------------+
|                            LIVE DEMO SIMULATION ENGINE                            |
|                                                                                   |
|  +----------------------------------+     +------------------------------------+  |
|  |    Cached TLE Database (JSON)    |     |   Synthetic Telemetry Generator    |  |
|  | - CelesTrak 50 Active Satellites |     | - 1 Hz WebSocket Stream            |  |
|  | - Debris Objects (Space Debris)  |     | - Normal vs Anomaly Injection Mode |  |
|  +----------------------------------+     +------------------------------------+  |
|                  |                                          |                     |
|                  +--------------------+---------------------+                     |
|                                       |                                           |
|                                       v                                           |
|                   +---------------------------------------+                       |
|                   |   Demo Control Panel ("Sim Panel")    |                       |
|                   |  [ Trigger Anomaly ] [ Force Pass ]   |                       |
|                   |  [ Simulate Debris Conjunction ]      |                       |
|                   +---------------------------------------+                       |
+-----------------------------------------------------------------------------------+

1. Simulated Telemetry Generator: A standalone Python script streams synthetic satellite telemetry frames over WebSockets. The demo UI includes a toggle button:
   • Nominal Mode: Streams healthy sinusoidal power/thermal curves [ASSUMPTION].
   • Fault Injection Mode: Simulates a battery degradation event (voltage drops while panel temperature spikes). Judges immediately see the ML Isolation Forest badge turn red with an anomaly score alert [ASSUMPTION].
2. Conjunction Event Simulation: The system pre-loads two TLE objects configured for a close pass approach ($d \approx 4.2\text{ km}$). The team demonstrates the automatic alert trigger, minimum distance calculation, and 3D vector visual rendering [ASSUMPTION].
3. Ground Station Pass Verification: The team inputs the exact latitude and longitude of the SIH Nodal Center. The pass scheduler computes the next visible pass window for ISS / Student Satellite, displaying real-time azimuth/elevation pointing vectors on an skyplot widget [ASSUMPTION].

18. Implementation Roadmap

The implementation plan is structured for execution prior to the final deadline of 30 September 2026 [PS].

+-----------------------------------------------------------------------------------+
|                              IMPLEMENTATION ROADMAP                               |
|                                                                                   |
| PHASE 1: Architecture & Data Ingestion (Weeks 1 - 2)                              |
| - Setup FastAPI backend & React/CesiumJS frontend scaffolding                     |
| - Implement CelesTrak TLE REST API fetcher & SGP4 propagation pipeline            |
|                                                                                   |
| PHASE 2: 3D Visualization & Pass Prediction (Weeks 3 - 4)                          |
| - Render 3D orbits, ground tracks, and sensor footprint cones in CesiumJS          |
| - Build ground station Az/El/Range pass prediction algorithms                     |
|                                                                                   |
| PHASE 3: Telemetry Engine & ML Anomaly Model (Weeks 5 - 6)                        |
| - Develop WebSocket telemetry streaming mock engine                               |
| - Train Isolation Forest model on nominal synthetic telemetry datasets             |
|                                                                                   |
| PHASE 4: Conjunction Screening & UI Integration (Weeks 7 - 8)                    |
| - Implement satellite vs debris distance screening algorithms                      |
| - Build unified dashboard UI with Recharts and alert panels                       |
|                                                                                   |
| PHASE 5: Testing, Simulation Harness & Demo Prep (Weeks 9 - 10)                   |
| - Conduct offline testing, Service Worker caching, and fallback checks            |
| - Final presentation dry runs before 30 September 2026 [PS]                       |
+-----------------------------------------------------------------------------------+

19. Testing & Validation Plan

20. Risk Register

21. Cost & Scalability

Hackathon

• Hosting & Compute: $0.00 (Deployed on free-tier platforms like Vercel for React UI, Render/Railway for FastAPI backend) [ASSUMPTION].
• Data Ingestion: $0.00 (Uses public CelesTrak, NASA GIBS, and OpenStreetMap endpoints) [RESEARCHED].
• Database: $0.00 (Embedded SQLite database) [KNOWN].
• Total Hackathon Cost: ₹0 / $0 [ASSUMPTION].

Production

• Cloud Infrastructure: Microservices cluster deployed on AWS/GCP (Elastic Kubernetes Service / Cloud Run) for scalable backend orbit propagation [INFERENCE].
• Database Layer: Managed PostgreSQL / PostGIS cluster for historical telemetry logs and spatial indexing [NEEDS VALIDATION].
• High-Throughput Telemetry Ingestion: Managed Apache Kafka / MQTT brokers for ingesting multi-satellite constellation telemetry streams [NEEDS VALIDATION].
• Estimated Production Cost: Variable based on constellation size and telemetry throughput (scalable serverless pay-per-use architecture) [NEEDS VALIDATION].

22. Differentiation

+-----------------------------------------------------------------------------------+
|                             WHY ASTRANET WINS AT SIH                              |
|                                                                                   |
|  Generic Hackathon Submission            AstraNet Proposed Solution               |
|  --------------------------            ---------------------------                |
|  - Static 3D Earth model mesh          - Validated SGP4 orbital physics engine    |
|  - Hardcoded satellite animations      - Live CelesTrak TLE REST API sync        |
|  - Fake static telemetry numbers       - WebSocket streaming + ML Anomaly Engine |
|  - No ground station physics           - Real Az/El pointing vector calculations |
|  - Monolithic frontend codebase        - Decoupled FastAPI + CesiumJS architecture|
+-----------------------------------------------------------------------------------+

1. Physics-Backed Engineering Depth: Unlike generic submissions that animate 3D spheres on fixed circular paths, AstraNet uses validated SGP4 math on real NORAD Two-Line Element data [INFERENCE].
2. End-to-End Mission Lifecycle Coverage: Combines pre-flight mission planning, live telemetry ingestion, ML health diagnostics, and space debris threat analysis into a single unified console [INFERENCE].
3. Open-Source & Cost-Effective Philosophy: Replaces multi-thousand-dollar commercial software with a web-native stack tailored for Indian university CubeSat projects and space tech startups [INFERENCE].

23. Future Scope

1. Hardware-in-the-Loop (HITL) SDR Integration: Connect software demodulators (GNU Radio / SDR) to ingest real UHF/VHF RF downlinks directly from passing satellites [INFERENCE].
2. Kubernetes-Based Constellation Management: Scale propagation workers across distributed pods to handle 10,000+ commercial satellite constellations [INFERENCE].
3. Inter-Satellite Link (ISL) Network Simulation: Model laser and RF cross-link optical communications and latency across LEO constellations [INFERENCE].
4. Integration with ISRO Bhuvan / VEDAS APIs: Deep integration with ISRO geospatial services for automated Earth observation tasking and spatial change detection [RESEARCHED].

24. Assumptions & Open Items Log

Consolidated Assumptions & Validations

• [ASSUMPTION] The primary demonstration target is small satellite (CubeSat) operational workflows for university research teams.
• [ASSUMPTION] Python FastAPI backend with python-sgp4 and SQLite provides sufficient performance for propagating 50–100 satellites simultaneously during a live demo.
• [ASSUMPTION] Synthetic telemetry streaming via WebSockets with controllable fault injection is an acceptable substitute for live satellite downlinks.
• [NEEDS VALIDATION] Exact cloud deployment resource limits and cost pricing models for hosting persistent WebSocket microservices on free tiers during the hackathon finale.
• [NEEDS VALIDATION] Production API rate limits and access credentials for ISRO VEDAS API Centre production key issuance.

Final Recommendation

The team should proceed with building AstraNet (Approach 3: Hybrid Web-GIS + Python FastAPI Engine + CesiumJS) [ASSUMPTION]. It directly addresses problem statement SIH26209 by applying software engineering and orbital mechanics principles to space systems operation [PS].

Recommended Stack

• Frontend: React 18, CesiumJS, TailwindCSS, Recharts [ASSUMPTION].
• Backend: Python 3.12, FastAPI, python-sgp4, skyfield, scikit-learn [ASSUMPTION].
• Data Sources: CelesTrak TLE REST APIs, NASA GIBS WMTS [RESEARCHED].
• Database & Cache: SQLite, Redis [ASSUMPTION].

Biggest Dependency

Stable execution of the SGP4 propagation library and access to CelesTrak TLE endpoints (mitigated via local fallback datasets) [INFERENCE].

Biggest Risk

Client-side browser performance lag during complex 3D CesiumJS rendering on low-spec judging laptops (mitigated via 2D Leaflet graphic toggle) [INFERENCE].

Biggest Technical Challenge

Achieving real-time sub-second orbital position updates and conjunction proximity screening without blocking the WebSocket telemetry stream or UI rendering thread [INFERENCE].

First 5 Actions

1. Initialize Git repository with React/Vite frontend and FastAPI backend structure [INFERENCE].
2. Integrate CesiumJS globe into React and render a test satellite position using satellite.js [INFERENCE].
3. Build FastAPI endpoint to fetch and parse active satellite TLEs from CelesTrak [RESEARCHED].
4. Develop the synthetic WebSocket telemetry generator script with normal and fault modes [ASSUMPTION].
5. Train and export the scikit-learn Isolation Forest model on nominal telemetry data [ASSUMPTION].

Validation Before Coding

Verify that the selected development machines can install and run python-sgp4, cesium, and fastapi without C++ compilation or WebGL compatibility issues [INFERENCE].

Buildability Score /100

92 / 100 (High feasibility for a 4–6 student team with modern web and Python skills) [INFERENCE].

Confidence

High [INFERENCE].

Research Sources

1. Title: SIH 2025 Shortlisted Teams & Problem Statement Portal
   URL: https://sih.gov.in/sih2025/shortlisted-teams-grand-finale [1.1]
   Source Type: Official Government Portal (SIH / AICTE)
   Supported Claim: Validates problem statement metadata, SIH26209 PS number, AICTE organisation, and software category [PS].
   Reliability: Official / Primary Source.

2. Title: NASA Open MCT (Open Mission Control Technologies) Framework
   URL: https://nasa.github.io/openmct/ [4.3]
   Source Type: Official Open Source Project Documentation (NASA Ames)
   Supported Claim: Establishes design patterns for open-source web-based spacecraft telemetry visualization and mission control interfaces [RESEARCHED].
   Reliability: Official / Primary Source.

3. Title: ISRO VEDAS (Visualization of Earth Observation Data and Archival System) & API Centre
   URL: https://vedas.sac.gov.in/ [2.1]
   Source Type: Official Space Agency Portal (ISRO / SAC)
   Supported Claim: Identifies ISRO geospatial and Earth observation web service capabilities and API availability [RESEARCHED].
   Reliability: Official / Primary Source.

4. Title: CelesTrak Two-Line Element (TLE) Satellite Catalog & REST Services
   URL: https://celestrak.org/ [KNOWN]
   Source Type: Public Satellite Tracking & Orbital Element Repository
   Supported Claim: Standard public data source for satellite TLE data and orbital mechanics propagation [KNOWN].
   Reliability: Industry Standard / Primary Source.

5. Title: Libre Space Foundation & SatNOGS Project Catalogue
   URL: https://www.libre.space/projects/ [3.2]
   Source Type: Open Source Space Technology Foundation
   Supported Claim: Validates existing open-source ground segment software and crowdsourced satellite reception architecture [RESEARCHED].
   Reliability: Reputable Secondary / Open Source Authority.