Skip to content

03_Architecture.md

Latest commit

 

History

History
103 lines (84 loc) · 3.94 KB

03_Architecture.md

File metadata and controls

103 lines (84 loc) · 3.94 KB
title System Architecture (HLD)
project Solar-Doctor
phase 03 - System Architecture (HLD)
status LOCKED
tags
Architecture
Mermaid
TinyML
ESP32
IoT
SystemDesign
aliases
Phase 3 Architecture
HLD
System Design
date 2025-11-21
owner mr.princetheprogrammerbtw

PHASE 3: SYSTEM ARCHITECTURE (HLD)

Designing the Nervous System: How AI, Hardware & Cloud Talk.

3.1 The "TinyML" Strategy

The primary advantage of the AI model is its ability to differentiate contextual voltage drops from genuine faults.

Scenario: At 6:30 PM, the sun sets, and voltage drops naturally across all panels.

  • A simple if-then approach: Sees low voltage → Assumes a fault → Incorrectly activates the bypass.
  • The TinyML approach:
    • Input: Reads Voltage of Panel A (Va) and Neighbor Panel B (Vb).
    • Logic:
      • If Va is Low AND Vb is Low → Conclusion: It's Night. Do Nothing.
      • If Va is Low BUT Vb is High → Conclusion: It's Shade/Fault. Initiate Bypass.
    • Result: This contextual awareness eliminates false alarms.

3.2 The High-Level Architecture (HLD)

This diagram provides a comprehensive overview of the entire system.

graph TD
    %% STYLING
    classDef device fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#0d47a1;
    classDef edge fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:#e65100;
    classDef cloud fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#4a148c;

    %% --- LAYER 1: THE FIELD (Hardware) ---
    subgraph FIELD ["SOLAR FARM LAYER"]
        direction TB
        Panel[PV Panel Cluster]:::device
        
        subgraph NODE ["Solar-Doctor Device (ESP32)"]
            Sensors(Voltage & Current Data):::device
            TinyML(AI Model: Anomaly Detection):::device
            Switch(MOSFET Bypass Switch):::device
        end
        
        Panel --> Sensors
        Sensors --> TinyML
        TinyML -- "Fault Confirmed?" --> Switch
        Switch -- "Bypass Logic" --> Panel
    end

    %% --- LAYER 2: THE EDGE (Local Network) ---
    subgraph EDGE ["EDGE GATEWAY LAYER"]
        Mesh((ESP-NOW Mesh Network)):::edge
        Gateway[Raspberry Pi / Master Node]:::edge
        LocalDB[(Local Logs)]:::edge
        
        NODE -.-> |"Wireless Data"| Mesh
        Mesh -.-> Gateway
        Gateway <--> LocalDB
    end

    %% --- LAYER 3: THE CLOUD (Internet) ---
    subgraph CLOUD ["CLOUD & APP LAYER"]
        MQTT(MQTT Broker - AWS/HiveMQ):::cloud
        API(Backend API):::cloud
        App(Flutter Mobile App):::cloud
        
        Gateway ==> |"4G/Wi-Fi"| MQTT
        MQTT --> API
        API --> App
    end
Loading

3.3 Communication Protocols

  • Node-to-Node (Mesh): ESP-NOW
    • Why: Enables direct device-to-device communication without requiring a Wi-Fi router, which is ideal for large, open-field deployments. Range is up to 200 meters line-of-sight.
  • Gateway-to-Cloud: MQTT
    • Why: A lightweight protocol that ensures reliable message delivery even with weak or intermittent 4G signals, where standard HTTP requests might fail. This also minimizes data consumption costs.

3.4 Data Strategy: "Report by Exception"

This strategy minimizes server load and data usage.

  • Standard Mode:
    • Sensors read every 100ms.
    • TinyML checks for anomalies every 1 second.
    • A "heartbeat" signal ("I am alive") is uploaded to the cloud once every 15 minutes.
  • Emergency Mode (Fault Detected):
    • Data is uploaded to the cloud instantly.
    • A notification is pushed to the mobile app: "CRITICAL ALERT: Panel 4 Shaded."

Phase 3 Checklist (Re-Verified)

  • AI Logic Defined: Smart distinction between Night vs. Fault.
  • Architecture Mapped: Field -> Edge -> Cloud flow is clear.
  • Protocol Selected: ESP-NOW for local, MQTT for cloud.
  • Data Policy: Report by Exception (Save bandwidth).

This architecture is robust, handling network failures, saving power, and using AI intelligently.

[[04_BOM]]