Digital Platform for efficient remote management of Indian Antarctic Research Stations

1. Executive Snapshot

Summary

The Ministry of Earth Sciences (MoES) and National Centre for Polar and Ocean Research (NCPOR) operate two active, year-round research stations in Antarctica: Maitri (commissioned 1989 in Schirmacher Oasis) and Bharati (commissioned 2012 in Larsemann Hills, ~3,000 km apart) [KNOWN]. Remote management of these polar habitats is critically constrained by harsh weather, extreme isolation, strict fuel budgets, and severely limited satellite bandwidth (~4 MHz SATCOM links) [RESEARCHED]. This dossier proposes PolarTwin, an edge-native, hybrid cloud-edge Digital Twin framework designed specifically for Maitri and Bharati [INFERENCE]. PolarTwin combines an offline-autonomous Edge Twin Gateway at each station with an interactive 3D WebGL (Three.js/glTF) spatial visualizer at NCPOR Headquarters (Vasco da Gama, Goa) [ASSUMPTION]. Using protocol buffers (Protobuf) over compressed MQTT/HTTP store-and-forward sync, the framework unifies four core pillars: facility infrastructure, Combined Heat and Power (CHP) microgrid energy, seasonal ship/air cargo logistics, and external environmental feeds [INFERENCE]. A 4–6 student hackathon team can realistically deliver a functional WebGL 3D spatial twin, simulated IoT telemetry stream, offline sync engine, and predictive anomaly model within the SIH timeframe [ASSUMPTION].

Metadata Table

Fundamental System Objective

To deliver a resilient, edge-autonomous 3D Digital Twin platform that provides real-time spatial telemetry, microgrid energy optimization, inventory and supply chain tracking, and environmental risk awareness for Maitri and Bharati stations over constrained satellite links [INFERENCE].

2. Problem Deconstruction

The explicit problem statement description reads:

"Develop a Digital Twin framework for Maitri and Bharati stations integrating infrastructure, energy, logistics and environmental monitoring for efficient remote management." [PS]

Atomic Requirements Analysis

1. Requirement 1: Digital Twin Framework

   • Source Text: "Develop a Digital Twin framework..." [PS]
   • Interpretation: Construct a dynamic, digital representation of physical station assets, incorporating 3D CAD/BIM geometric models synced with temporal telemetry streams [INFERENCE].
   • Implementation Implication: Requires a browser-based 3D renderer (Three.js / WebGL) mapped to asset ID tags, state machines, and spatial coordinate layers [INFERENCE].
   • Confidence Tag: [PS]

2. Requirement 2: Multi-Station Coverage (Maitri & Bharati)

   • Source Text: "...for Maitri and Bharati stations..." [PS]
   • Interpretation: The platform must natively support and distinguish two geographic locations separated by ~3,000 km in Antarctica, each with distinct structural and operational profiles [RESEARCHED].
   • Implementation Implication: Multi-site tenant architecture; unified GIS dashboard with drill-down capability into individual station layouts (Maitri container/living modules and Bharati 3-tier container block) [INFERENCE].
   • Confidence Tag: [PS]

3. Requirement 3: Infrastructure Monitoring Integration

   • Source Text: "...integrating infrastructure..." [PS]
   • Interpretation: Track structural health, indoor climate (HVAC), fire suppression, water production (desalination/snow melters), and waste treatment systems [INFERENCE].
   • Implementation Implication: Ingest telemetry from ambient sensors, pipe pressure/flow meters, and structural strain sensors via OPC UA / Modbus / MQTT bridges [INFERENCE].
   • Confidence Tag: [PS]

4. Requirement 4: Energy Monitoring & Management Integration

   • Source Text: "...energy..." [PS]
   • Interpretation: Monitor power generation from Combined Heat & Power (CHP) diesel units, fuel consumption (Aviation Turbine Fuel / Jet A-1), battery storage/UPS, and microgrid distribution [RESEARCHED].
   • Implementation Implication: Real-time power telemetry tracking (kVA, kW, fuel flow rate), automated efficiency calculations, and predictive fuel depletion modeling [INFERENCE].
   • Confidence Tag: [PS]

5. Requirement 5: Logistics Integration

   • Source Text: "...logistics..." [PS]
   • Interpretation: Monitor supply inventory (spare parts, food, medical supplies, fuel farm reserves) and track resupply missions via ice-class cargo vessels (e.g., MV Vasiliy Golovnin) and DROMLAN air cargo flights [RESEARCHED].
   • Implementation Implication: Database module for cargo manifests, fuel tank volume tracking, consumption burn-down forecasting, and resupply shipment location tracking [INFERENCE].
   • Confidence Tag: [PS]

6. Requirement 6: Environmental Monitoring Integration

   • Source Text: "...and environmental monitoring..." [PS]
   • Interpretation: Ingest micro-climate weather data (ambient temperature, wind speed/direction, blizzard warnings) and surrounding cryospheric conditions (ice shelf movement, sea ice extent) [RESEARCHED].
   • Implementation Implication: Integration with station weather sensors (AWS), geomagnetic observatory streams, and external satellite sea-ice data feeds [INFERENCE].
   • Confidence Tag: [PS]

7. Requirement 7: Remote Management Capability

   • Source Text: "...for efficient remote management." [PS]
   • Interpretation: Enable NCPOR officers in Goa, India, to remotely observe, diagnose, simulate, and send advisory directives or non-safety-critical control commands back to stations [INFERENCE].
   • Implementation Implication: Low-bandwidth bi-directional messaging protocol, role-based access control (RBAC), and audit logging [INFERENCE].
   • Confidence Tag: [PS]

3. Stakeholders & User Needs

4. Requirements Traceability

5. Constraints & Environment Realities

1. Satellite Connectivity & Bandwidth Limits:

   • Stations rely on C-band / VSAT dedicated satellite channels (~4 MHz bandwidth) established via SAC/ISRO [RESEARCHED].
   • Round-trip latency ranges from 600ms to over 1200ms; solar blackouts and severe geomagnetic storms cause complete connection drops lasting hours or days [RESEARCHED].
   • Constraint: Raw streaming of high-frequency telemetry or live 3D mesh rendering over the network is impossible. All 3D models must be client-side cached; data sync must be compressed and delta-only [INFERENCE].

2. Physical Infrastructure & Power:

   • Bharati is powered by 3 CHP units (100 kVA each) running on Aviation Turbine Fuel (Jet A-1/ATF) with a ~300,000L fuel farm [RESEARCHED].
   • Maitri relies on diesel power units in Schirmacher Oasis [RESEARCHED].
   • Constraint: Power loss in winter (-40°C to -80°C wind chill) causes life-support failure within hours. Edge gateways must run on low-power, uninterruptible power circuits (UPS backed) [INFERENCE].

3. Logistics & Resupply Window:

   • Sea resupply occurs once per year (Dec–March navigation window) via chartered icebreakers [RESEARCHED]. Air resupply occurs via DROMLAN IL-76 flights landing on blue ice runways [RESEARCHED].
   • Constraint: Spare parts and hardware replacements take up to 12 months to arrive if missing from inventory [INFERENCE].

4. Operating Personnel & On-Site Skill:

   • Wintering crew (~24–40 staff per station) includes technical staff from contractors (OMRC) and scientists [RESEARCHED].
   • Constraint: UX must be simple, low-overhead, and functional without requiring deep software engineering expertise on-site [INFERENCE].

6. Research Questions

1. Telemetry Protocol Selection: How to minimize payload size for 1,000+ spatial sensor data points over a 64 kbps shared uplink?
2. CAD/BIM Model Optimization: How to convert complex station architectural drawings (Bharati 134-container layout) into web-optimized 3D glTF/glb models under 15 MB total load size?
3. Edge Storage & Resiliency: How should local edge databases handle multi-day satellite outages without losing temporal telemetry ordering or crashing due to disk overflow?
4. Predictive Maintenance Accuracy: What machine learning models can accurately predict CHP generator fuel injector failure or thermal drop with minimal training datasets?
5. Security in Polar SATCOM: How to implement secure, tamper-proof command transmission without adding overhead to high-latency satellite connections?

7. Data Requirements & Sources

Data Categories

• A. Explicitly Mentioned: Station infrastructure state, energy metrics, logistics inventory, environmental telemetry [PS].
• B. Required by Inference: CAD/BIM 3D models, sensor geographic coordinates, satellite link performance logs [INFERENCE].
• C. Must be Collected: On-site sensor telemetry (PLC outputs, Modbus register reads, AWS weather feeds) [ASSUMPTION].
• D. Synthetically Generated: Simulated 24-hour winter storm telemetry (for hackathon testing) [ASSUMPTION].
• E. Needs Validation: Live API endpoint structures of NCPOR's internal SCADA network [NEEDS VALIDATION].

Data Requirements Table

8. Existing Solutions & Gap Analysis

9. Candidate Solution Approaches

Comparison Table

10. Recommended Approach & Why

Selected Solution

Approach 2: Edge-Native Hybrid Digital Twin with Lightweight Binary Delta Synchronization (PolarTwin) [INFERENCE].

Justification

1. Satellite Autonomy: Antarctic stations frequently experience multi-day satellite blackouts due to severe weather or solar storms [RESEARCHED]. Approach 2 deploys an Edge Twin Gateway on-site at Maitri and Bharati that stores all high-frequency IoT data locally in a time-series database (TimescaleDB / SQLite) and maintains the station's local operational twin independently of internet connectivity [INFERENCE].
2. Bandwidth Efficiency: Rather than streaming raw JSON strings over the limited 4 MHz C-band SATCOM link, the Edge Sync Gateway serializes state changes using Protocol Buffers (Protobuf) and Zstandard compression [INFERENCE]. Data updates are sent in small batch updates (every 30–60 seconds, ~2–5 KB payload size), reducing satellite bandwidth consumption by up to 90% [INFERENCE].
3. Spatial Context & User Experience: By using client-side WebGL (Three.js) loaded with low-polygon glTF 3D models of Maitri and Bharati, the 3D rendering happens locally in the user's browser [INFERENCE]. Telemetry updates dynamically alter 3D object properties (e.g., generator color changes to red during heat anomaly, thermal gradients mapped on pipe meshes), offering immediate visual diagnostics for both local engineers and HQ leadership in Goa [INFERENCE].

Why Alternatives Were Rejected

• Approach 1 (Cloud-Centric WebGL Twin) was rejected because streaming continuous raw telemetry directly to the cloud relies on uninterrupted broadband, which does not exist in Antarctica [RESEARCHED]. Satellite link drops would leave local operators blind [INFERENCE].
• Approach 3 (Minimalist 2D SCADA Dashboard) was rejected because it fails to deliver a true Digital Twin framework as explicitly required by the problem statement [PS]. Textual/2D charts lack spatial awareness—making it difficult to locate physical assets (e.g., identifying which specific container module or HVAC duct is failing inside Bharati's 3-story complex) [INFERENCE].

11. Technical Architecture

Layered Architecture Diagram

+-----------------------------------------------------------------------------------+
|                            VISUALIZATION & USER LAYER                             |
|  [NCPOR Goa HQ Command Center]              [Station Operator Console (Local)]     |
|  +-------------------------------------+    +----------------------------------+  |
|  | WebGL 3D Spatial Twin (Three.js)    |    | Local Station 3D Twin (PWA)      |  |
|  | Multi-Station GIS (Cesium.js/Leaflet)|    | Emergency SCADA View             |  |
|  +-------------------------------------+    +----------------------------------+  |
+------------------------------------------^----------------------------------------+
                                           | HTTPS / WebSockets (Local & Cloud)
+------------------------------------------v----------------------------------------+
|                                APPLICATION & API LAYER                            |
|  [Central Cloud Server - NCPOR Goa]         [Edge Server - Maitri / Bharati]      |
|  +-------------------------------------+    +----------------------------------+  |
|  | Node.js / FastAPI REST & WS Server  |    | Local FastAPI Edge Service       |  |
|  | Multi-Tenant Station Manager        |    | Rule Engine & Anomaly Detector   |  |
|  | Logistics Burndown Engine           |    | Local Alarm Dispatcher           |  |
|  +-------------------------------------+    +----------------------------------+  |
+------------------------------------------^----------------------------------------+
                                           | Compressed Binary Delta Sync (Protobuf)
                                           | over SATCOM (C-band / VSAT)
+------------------------------------------v----------------------------------------+
|                        DATA STORAGE & SYNCHRONIZATION LAYER                       |
|  [Cloud DB]                             [Edge Store-and-Forward]                  |
|  +-------------------------------------+    +----------------------------------+  |
|  | PostgreSQL + TimescaleDB (Central)  |    | SQLite / Embedded TimescaleDB    |  |
|  | MinIO Object Storage (3D Assets)    |    | Protobuf Sync Queue & Compressed |  |
|  | Redis Cache (Live State)            |    | Ring Buffer (30-day offline retention)|
|  +-------------------------------------+    +----------------------------------+  |
+------------------------------------------^----------------------------------------+
|                                INGESTION & PROTOCOL LAYER                         |
|  +-----------------------------------------------------------------------------+  |
|  | EMQX Edge MQTT Broker / Modbus TCP / OPC UA Client / Serial RS-485          |  |
|  +-----------------------------------------------------------------------------+  |
+------------------------------------------^----------------------------------------+
|                                PHYSICAL SENSOR LAYER                              |
|  +-------------------+  +-------------------+  +------------------+  +---------+  |
|  | CHP Power Units   |  | HVAC & Pipe Temps |  | Fuel Farm Sensors|  | AWS     |  |
|  | (100 kVA x3)      |  | (Modbus/OPC UA)   |  | (Ultrasonic Level|  | Weather |  |
|  +-------------------+  +-------------------+  +------------------+  +---------+  |
+-----------------------------------------------------------------------------------+

Data Flow Narrative

1. Ingestion Step: Physical sensors across Bharati (e.g., CHP generator thermocouples, fuel level transmitters, HVAC airflow sensors) broadcast readings via Modbus TCP / OPC UA to the local station EMQX Edge MQTT Broker [INFERENCE].
2. Edge Processing & Local Storage: The local station Edge Gateway ingests MQTT messages, validates sanity bounds, writes raw high-frequency records (1 Hz) into the local SQLite / TimescaleDB, and evaluates local safety rules [INFERENCE].
3. Local Twin Rendering: Local station engineers access the station PWA dashboard over LAN; Three.js renders the 3D model, binding local telemetry directly to 3D meshes without touching the internet [INFERENCE].
4. Binary Compression & Sync: The Edge Sync Engine aggregates 1-minute averaged telemetry, serializes it into Protocol Buffer (Protobuf) packets, compresses the payload using Zstandard, and queues it in a store-and-forward SQLite ring buffer [INFERENCE].
5. Satellite Transmission: When SATCOM connection is active, the queue flushes compressed packets over HTTPS/MQTT to the NCPOR Central Cloud Server in Goa [INFERENCE]. If the link drops, packets safely accumulate on the edge gateway for up to 30 days [INFERENCE].
6. Central Twin Visualization: The cloud server deserializes updates, updates the PostgreSQL/TimescaleDB master store, and pushes state deltas to HQ browser consoles via WebSockets, instantly updating the 3D Digital Twin model in Goa [INFERENCE].

12. Technology Stack

13. AI/ML Justification

AI Component 1: Anomaly Detection for CHP Power & HVAC Systems

1. Purpose: Detect subtle mechanical degradation (e.g., fuel injector clogging, coolant leaks, bearing wear) in Bharati's 3x 100 kVA CHP units before physical breakdown occurs [RESEARCHED].
2. Model Type: Isolation Forest / Autoencoder (Unsupervised Anomaly Detection) [INFERENCE].
3. Input: Exhaust gas temperature, oil pressure, vibration levels, kVA output load, fuel flow rate [RESEARCHED].
4. Output: Anomaly risk score (0.0 to 1.0) and identified contributing sensor features [INFERENCE].
5. Data Required: Historical 1-minute sensor telemetry from generator runs (or simulated baseline specs) [ASSUMPTION].
6. Why AI is Preferable: Fixed threshold rules miss complex multi-variable drift (e.g., normal temperature at high load is abnormal at low load) [INFERENCE].
7. Evaluation: Precision-Recall AUC on historical test datasets containing injected fault patterns [INFERENCE].
8. Failure Mode: False positives trigger unnecessary inspections; false negatives lead to equipment breakdown [INFERENCE].
9. Human Oversight: High-risk alerts prompt station engineers to conduct physical checks; no automated shutdown is triggered by AI alone [INFERENCE].

AI Component 2: Fuel Consumption & Stock Depletion Forecaster

1. Purpose: Forecast Jet A-1 / ATF fuel reserve burn-down rates based on predicted winter ambient temperatures and station heat load [RESEARCHED].
2. Model Type: Ridge Regression / XGBoost Time-Series Forecaster [INFERENCE].
3. Input: Forecasted ambient temperature, wind chill index, station occupancy count, active CHP unit state [RESEARCHED].
4. Output: Predicted daily fuel consumption (liters/day) and estimated days until critical fuel threshold [INFERENCE].
5. Data Required: Weather forecast feeds, historical daily fuel usage logs [ASSUMPTION].
6. Why AI is Preferable: Fuel usage varies non-linearly with external blizzard conditions and thermal losses [INFERENCE].
7. Evaluation: Mean Absolute Error (MAE in liters/day) against actual fuel tank drop readings [INFERENCE].
8. Failure Mode: Underestimating fuel consumption could risk winter fuel depletion [INFERENCE].
9. Human Oversight: Logistics team uses predictions to plan annual ship cargo volumes; actual tank levels are verified manually via DIP stick / float sensors weekly [RESEARCHED].

Explicit Non-AI Boundaries

• Safety Interlocks & Emergency Tripping: Circuit breaker trips, fire suppression release, and engine emergency stops MUST rely exclusively on hardcoded, deterministic PLC rules (IEC 61131-3) and physical hardware relays. AI/ML shall NOT have direct write access to safety shutdown controls. [INFERENCE]

14. Data Architecture & Offline/Low-Network Design

Database Schema (Simplified SQL Blueprint)

-- Stations Table
CREATE TABLE stations (
    station_id VARCHAR(16) PRIMARY KEY, -- 'MAITRI', 'BHARATI'
    name VARCHAR(64) NOT NULL,
    latitude DOUBLE PRECISION NOT NULL,
    longitude DOUBLE PRECISION NOT NULL,
    elevation_m REAL,
    status VARCHAR(32) DEFAULT 'OPERATIONAL'
);

-- Assets (Digital Twin Components)
CREATE TABLE assets (
    asset_id VARCHAR(32) PRIMARY KEY, -- e.g., 'BHR-CHP-01', 'MTR-HVAC-02'
    station_id VARCHAR(16) REFERENCES stations(station_id),
    asset_name VARCHAR(64) NOT NULL,
    category VARCHAR(32) NOT NULL, -- 'ENERGY', 'INFRASTRUCTURE', 'LOGISTICS'
    mesh_node_name VARCHAR(64), -- Target 3D Object ID in glTF model
    location_description TEXT
);

-- Time-Series Telemetry Table (TimescaleDB Hypertable)
CREATE TABLE telemetry (
    time TIMESTAMPTZ NOT NULL,
    asset_id VARCHAR(32) REFERENCES assets(asset_id),
    metric_name VARCHAR(32) NOT NULL, -- 'temperature', 'power_kw', 'fuel_flow'
    val DOUBLE PRECISION NOT NULL,
    quality_code INT DEFAULT 1 -- 1=Good, 0=Degraded/Simulated
);
SELECT create_hypertable('telemetry', 'time');

-- Store-and-Forward Sync Queue (Edge Only)
CREATE TABLE sync_queue (
    queue_id BIGSERIAL PRIMARY KEY,
    created_at TIMESTAMPTZ DEFAULT CURRENT_TIMESTAMP,
    payload_protobuf BYTEA NOT NULL,
    retry_count INT DEFAULT 0,
    synced BOOLEAN DEFAULT FALSE
);

Offline & Low-Network Synchronization Strategy

  Station Local Network (LAN)              SATCOM Uplink               NCPOR Cloud (Goa)
+-----------------------------+        +-------------------+        +---------------------+
| Local Sensors -> MQTT Broker|        |  4 MHz C-Band Link|        | Central Cloud Sync  |
|              |              |        |   High Latency    |        |       Receiver      |
|              v              |        |  Periodic Drops   |        +----------+----------+
|      Local Edge Gateway     |        +---------+---------+                   |
|  (SQLite Store-and-Forward) |                  |                             v
|              |              |  Protobuf Batch  |                   Central TimescaleDB
|    [Queue Pending Records]  +----------------->+                   & WebSocket Server
+-----------------------------+ (When Link Up)   +-----------------------------+

1. Local Ring Buffer: The edge gateway writes all high-frequency telemetry into SQLite. Disk storage is managed via a rolling ring buffer (retaining 30 days of raw data) [INFERENCE].
2. Delta Encoding & Compression: Telemetry records are grouped into 1-minute averaged bundles. Floating point values are delta-encoded (transmitting differences between consecutive readings) and serialized into binary Protobuf payloads [INFERENCE].
3. Store-and-Forward Queue: Packets enter the sync_queue table. A background daemon attempts transmission to the cloud endpoint [INFERENCE].
4. Exponential Backoff & Chunking: If the SATCOM link is down, packets accumulate safely. Upon reconnect, the engine sends historical chunks in chronological batches, capping bandwidth consumption to 15 kbps so essential station voice/data communications are not degraded [INFERENCE].

15. Security, Privacy & Governance

1. Data Classification:
   • Public: General station coordinates, public meteorological data, public scientific research highlights [KNOWN].
   • Restricted / Sensitive: Detailed 3D interior layouts, exact fuel farm balances, satellite ground station frequency settings, security camera feeds, crew health logs [INFERENCE].
2. Authentication & Access Control:
   • Role-Based Access Control (RBAC) with 3 tiers:
     • Viewer (Public/MoES Officials): Read-only view of high-level 3D spatial twins and aggregated energy metrics [INFERENCE].
     • Station Operator (On-site Engineers): Full access to granular local SCADA controls, maintenance logs, and local configuration [INFERENCE].
     • HQ Administrator (NCPOR Operations Directors): Authorize inventory updates, send remote advisories, and manage user permissions [INFERENCE].
   • Hardware-backed Mutual TLS (mTLS) with x509 client certificates for Edge-to-Cloud server authentication [INFERENCE].
3. Encryption Standards:
   • AES-256 encryption for local SQLite databases at rest on edge gateways [INFERENCE].
   • TLS 1.3 encryption for all data in transit across the SATCOM link [INFERENCE].
4. Audit & Governance:
   • Immutable write-once audit log recording all remote advisory messages, login attempts, and configuration changes [INFERENCE].
   • Compliance with the Indian Antarctic Act, 2022 and Antarctic Treaty System environmental protocols regarding waste management and station operations monitoring [RESEARCHED].

16. MVP Scope (Hackathon Build)

In Scope

• Interactive 3D WebGL Digital Twin: Fully rendered interactive 3D models of Bharati (main building complex) and Maitri (container layout) in Three.js with orbit controls, zoom, and spatial asset selection [ASSUMPTION].
• Live Spatial Sensor Telemetry: Color-coded mesh overlays (e.g., thermal heatmaps on HVAC ducts, status colors on CHP units) fed by live simulated IoT data streams [ASSUMPTION].
• Microgrid & Fuel Management Module: Dashboard displaying simulated CHP power generation (kVA), fuel tank levels (liters), and battery storage health [ASSUMPTION].
• Logistics Inventory Burndown Tracker: Fuel reserve burndown calculator and spare part inventory tracker with low-stock alerts [ASSUMPTION].
• Simulated Satellite Disconnect & Offline Sync Engine: Interactive toggle on UI to simulate satellite link drop, demonstrating offline local edge caching and automatic Protobuf catch-up sync upon reconnection [ASSUMPTION].
• AI Anomaly Detection Model: Scikit-learn model detecting injected thermal/vibration anomalies in CHP telemetry during live demo [ASSUMPTION].

Described Only / Out of Scope

• Direct physical hardware wiring into live Siemens/Schneider PLCs at Antarctica [INFERENCE].
• Real-time satellite video streaming from station cameras [INFERENCE].
• Classified military satellite telemetry links [INFERENCE].
• Full automated physical actuator control (remote valve turning or generator startup) [INFERENCE].

17. Live Demo Simulation Plan

To convince SIH judges without requiring live hardware in Antarctica, the team will run a multi-node local simulation:

+-----------------------------------------------------------------------------------+
|                            LIVE DEMO ENVIRONMENT SETUP                            |
|                                                                                   |
|  [Node-RED Telemetry Generator] -----> [Local Edge Gateway Engine]                |
|  * Simulates 50+ station sensors       * Runs SQLite & Protobuf Encoder           |
|  * Injects generator fault at t=60s    * Includes "Network Drop" Toggle Switch    |
|                                                      |                            |
|                                                      v (Simulated SATCOM Link:    |
|                                                         600ms Delay + 64kbps Limit)
|                                                      |                            |
|  [NCPOR Goa HQ Dashboard] <--------------------------+                            |
|  * Three.js 3D Spatial Twin showing live spatial telemetry updates                |
|  * Demonstrates instant visual alarm when AI detects CHP heat anomaly              |
|  * Demonstrates catch-up sync after unchecking "Network Drop" switch              |
+-----------------------------------------------------------------------------------+

Step-by-Step Demo Script for Judges

1. Introduction & Dual-Station Overview: Show CesiumJS polar globe with Maitri and Bharati. Click Bharati to seamlessly zoom into the 3D WebGL model [ASSUMPTION].
2. Spatial Telemetry Overlay: Click on Level 2 CHP Generator module. Show real-time kVA, exhaust temp, and fuel flow updating every second via WebSockets [ASSUMPTION].
3. Simulated Anomaly Injection: Trigger a simulated "Coolant Leak / Overheat Fault" on Node-RED. Show the 3D generator mesh turn pulsing red, and the AI Anomaly panel highlight the root cause [ASSUMPTION].
4. SATCOM Outage Demonstration: Click the "Simulate Satellite Outage" button. Show that local station operations continue uninterrupted. Show telemetry queueing up in the Edge Store-and-Forward panel. Wait 15 seconds, uncheck the outage button, and watch the catch-up sync rapidly process buffered packets into the HQ cloud view [ASSUMPTION].
5. Logistics & Fuel Burndown: Display the 300,000L fuel tank burndown chart with projected depletion date under winter storm conditions [ASSUMPTION].

18. Implementation Roadmap

Target Deadline: 30 September 2026 [PS]

Phase 1: Architecture & Data Specs (Months 1-2) | Deadline: Nov 2025
├── Requirements locking & CAD 3D asset modeling (Blender glTF export)
└── Protobuf schema definition & DB schema design

Phase 2: Edge Ingestion & 3D WebGL Core (Months 3-5) | Deadline: Feb 2026
├── Development of Three.js spatial twin viewer & mesh binding
└── Node-RED telemetry simulator & SQLite store-and-forward engine

Phase 3: AI Models & Sync Protocol (Months 6-8) | Deadline: May 2026
├── Implementation of Isolation Forest anomaly detection model
└── Binary Protobuf over MQTT/HTTP compression & catch-up sync logic

Phase 4: HQ Dashboard & Integration (Months 9-10) | Deadline: Jul 2026
├── CesiumJS multi-station GIS integration & logistics inventory module
└── End-to-end integration of Edge, Cloud, and Frontend

Phase 5: Testing, Hardening & SIH Demo Prep (Months 11-12) | Deadline: Sep 2026
├── Network outage stress testing, latency injection, security review
└── Live demo dry-runs, presentation deck, and dossier finalization

19. Testing & Validation Plan

20. Risk Register

21. Cost & Scalability

Hackathon Phase

• Infrastructure Cost: ₹0 (Zero) [ASSUMPTION].
• Tech Stack: Open-source libraries (Three.js, React, Python FastAPI, SQLite, EMQX Edge, Docker) [ASSUMPTION].
• Hosting: Local laptop development environment + free tier cloud deployment (Render / Vercel / Supabase) [ASSUMPTION].

Production System

• Edge Hardware per Station: Dual industrial edge gateways (e.g., Advantech / Siemens Microbox IPCs) with UPS backup: ~₹3,00,000 to ₹5,00,000 per station [INFERENCE].
• Cloud Infrastructure (NCPOR HQ): On-premise enterprise server at NCPOR Goa or Dedicated MeitY-empaneled Cloud (NIC / AWS India): ~₹5,00,000 per year [INFERENCE].
• Satellite Bandwidth Egress: Utilizing existing NCPOR C-band SATCOM channels; zero additional satellite bandwidth cost due to ultra-low Protobuf footprint [INFERENCE].
• Scalability: Architecture seamlessly scales to integrate Maitri II (proposed ₹2,150 crore station) [RESEARCHED], Arctic base Himadri, and oceanographic research vessel ORV Sagar Kanya [RESEARCHED].

22. Differentiation

23. Future Scope

1. AR Field Maintenance Guidance: Augmented Reality (AR) mobile app for station engineers using wearable headsets (e.g., HoloLens/webAR) to overlay maintenance instructions directly onto physical CHP units [INFERENCE].
2. Maitri II Digital Twin Native Integration: Pre-construction BIM Digital Twin integration for the upcoming ₹2,150 crore Maitri II research station planned for 2032 completion [RESEARCHED].
3. Autonomous Drone Inspection Feeds: Ingesting thermal drone camera logs to automatically detect heat loss along external fuel pipelines and building envelopes [INFERENCE].
4. Integration with LEO Satellite Constellations: Future integration with emerging Antarctic Starlink / OneWeb polar LEO satellite links for selective high-bandwidth synchronization [RESEARCHED].

24. Assumptions & Open Items Log

Consolidated Assumptions

• [ASSUMPTION 1]: Blender low-polygon glTF models created from public architectural blueprints are sufficient representations of Bharati and Maitri for spatial twin visualization.
• [ASSUMPTION 2]: A simulated Node-RED telemetry generator accurately reflects physical Modbus/OPC UA register values during the hackathon evaluation.
• [ASSUMPTION 3]: The 4–6 student team has web development proficiency (React/Three.js) and basic Python backend skills.

Consolidated Open Items & Validation Required

• [NEEDS VALIDATION 1]: Exact internal IP schema and SCADA register maps currently in use by NCPOR's OMRC contractors at Bharati station.
• [NEEDS VALIDATION 2]: Specific firewall rules and SATCOM security policies governing remote access to NCPOR's internal network in Goa.

Final Recommendation

Adopt Approach 2 (Edge-Native Hybrid Digital Twin with Protobuf Delta Synchronization). It is the only architecture that satisfies the strict Digital Twin requirement while remaining resilient to Antarctic satellite blackouts [INFERENCE].

Recommended Stack

• Frontend: React + Three.js (React Three Fiber) + CesiumJS + Tailwind CSS.
• Backend: Python (FastAPI) + Node.js WebSockets.
• Data & Ingestion: SQLite (Edge), PostgreSQL + TimescaleDB (Cloud), EMQX Edge (MQTT), Protocol Buffers (Protobuf).
• AI/ML: Python scikit-learn (Isolation Forest for Anomaly Detection, XGBoost for Fuel Forecaster).

Biggest Dependency

Obtaining or constructing accurate 3D CAD/glTF models of Maitri and Bharati station layouts suitable for browser WebGL rendering [ASSUMPTION].

Biggest Risk

Satellite link drop during a remote cloud demonstration (mitigated by local edge fallback architecture) [INFERENCE].

Biggest Technical Challenge

Implementing seamless store-and-forward binary delta synchronization between SQLite edge database and TimescaleDB cloud database over intermittent, high-latency connections [INFERENCE].

First 5 Actions

1. Action 1: Download public architectural floor plans and photos of Bharati and Maitri stations from NCPOR portals [RESEARCHED].
2. Action 2: Create low-polygon 3D glTF structural models in Blender and tag key asset nodes (e.g., CHP_01, HVAC_MAIN, FUEL_TANK_A) [ASSUMPTION].
3. Action 3: Define the Protobuf schema (telemetry.proto) for compact sensor payload encoding [INFERENCE].
4. Action 4: Set up local EMQX Edge MQTT broker and write Python telemetry simulation scripts for station sensors [ASSUMPTION].
5. Action 5: Build the Three.js canvas in React and bind incoming MQTT telemetry to change 3D mesh colors dynamically [ASSUMPTION].

Validation Before Coding

Verify that Three.js can smoothly render the exported 3D glTF model at >50 FPS while processing 100 WebSockets telemetry updates per second on standard laptop hardware [ASSUMPTION].

Buildability Score /100

88/100 — Highly feasible for a skilled student team using open-source web technologies, simulated IoT data pipelines, and client-side WebGL [ASSUMPTION].

Confidence

High Confidence (85%) — Grounded in official NCPOR operational publications, Antarctic logistics constraints, and standard industrial IoT/Digital Twin design patterns [RESEARCHED].

Research Sources

1. National Centre for Polar and Ocean Research (NCPOR) - Station Achievements & Specs

   • URL: https://ncpor.res.in/antarcticas/display/369-significant-achievements- [1.1]
   • Type: Official Government Portal
   • Supported Claim: Confirms SATCOM 4 MHz bandwidth link at Maitri, Bharati station dimensions (30m x 50m, 2,162 sq m), 3x 100 kVA CHP units, 300,000L fuel farm, and NRSC Earth Station details.
   • Reliability: High (Official MoES/NCPOR source).

2. NCPOR Bharati Operations & OMRC Tender Document

   • URL: https://www.ncaor.gov.in/upload/tenders/tender_AL-11019_1_2025.PDF [1.3]
   • Type: Official Government Document
   • Supported Claim: Details Bharati life-support systems, 3x 100 kVA Combined Heat & Power (CHP) units running on ATF/Jet A-1 fuel, MLVD power distribution, and ~296 kilolitres ATF storage.
   • Reliability: High (Official Government Tender).

3. India's Fourth Antarctic Station (Maitri II) Nod - Times of India

   • URL: https://timesofindia.indiatimes.com/city/goa/indias-fourth-and-largest-antarctic-research-base-gets-in-principle-nod/articleshow/124613550.cms [1.7]
   • Type: Reputable News Publication
   • Supported Claim: Confirms financial approval for ₹2,150 crore Maitri II station project to replace original Maitri base by 2032.
   • Reliability: High.

4. British Antarctic Survey - PolarDT Project

   • URL: https://www.bas.ac.uk/project/digital-twins-of-the-polar-regions/ [1.1]
   • Type: Research Organization Portal
   • Supported Claim: Validates global research focus on Digital Twins for Antarctic research stations, ships, and polar environment monitoring.
   • Reliability: High.

5. Southeast University (SEU) - Polar Energy Digital Twin

   • URL: https://www.seu.edu.cn/english/2026/0413/c297a561895/page.htm [1.4]
   • Type: Academic Institution News
   • Supported Claim: Demonstrates real-world application of Digital Twins for remote monitoring and fault early warning of Antarctic station microgrids.
   • Reliability: High.

6. NCPOR Air Cargo Mission to Antarctica - PIB Release

   • URL: https://www.pib.gov.in/PressReleasePage.aspx?PRID=2174442 [4.2]
   • Type: Press Information Bureau (Government of India)
   • Supported Claim: Confirms direct air cargo logistics from Goa to Antarctica via DROMLAN IL-76 aircraft carrying 18 tons of provisions and equipment.
   • Reliability: High.