Faisalaffan Blog
|
🇬🇧
Faisalaffan Blog
Product38 min read

Truck Utilization 65% → 79%, Fuel Theft Detected in Month One: The Digital Mining Architecture I BUILT

How I engineered a hub-and-spoke platform for 3 massive mining sites in Borneo — real-time fleet management, automated HSE monitoring, and mine planning analytics that instantly caught fuel thieves in the very first month of deployment.

Faisal Affan
Faisal Affan
Published
Truck Utilization 65% → 79%, Fuel Theft Detected in Month One: The Digital Mining Architecture I BUILT

Engineering Case Study: HPU Digital Mining Platform

"To be the first-class total mining services solution — through technology adoption and operational excellence." — PT Harmoni Panca Utama Vision Statement

Context

PT Harmoni Panca Utama (HPU) is one of the largest mining services companies in Indonesia, operating across multi-site locations in Borneo (East, Central, and North Kalimantan) with 1,000-5,000+ employees and a massive heavy equipment fleet. I contributed to the architectural design and development of a digital platform integrating Fleet Management, HSE monitoring, and mine operations analytics to directly support HPU's vision of Operational Excellence.

This project completely transformed HPU's mining operations from highly manual processes — paper logs, radio communication, scattered Excel spreadsheets — into a fully integrated digital platform providing end-to-end visibility across all cross-site operations.

This article severely dissects the technical challenges, architecture, and engineering decisions behind building this massive platform.


🏔️ 1. The Challenge

HPU Operational Profile

PT Harmoni Panca Utama runs coal mining operations across several strategic sites in Borneo:

Conditions Before Digitalization

Aspect Legacy Condition Fatal Impact
Fleet Tracking Radio HT + visual supervisors Dispatchers literally blind to real-time unit positions
Cycle Time Hand-written paper logs by checkers Data severely delayed, incredibly inaccurate, unanalyzable
HSE Reporting Paper forms → manual Excel input Incident reports taking hours, analytics virtually non-existent
Fuel Management Manual logs at site gas stations Highly inaccurate consumption estimates, prone to severe theft
Mine Planning Desktop software, entirely isolated Massive gap between office planning and field execution
Multi-Site Visibility Weekly email reports Jakarta HQ management completely lacked real-time visibility
The Cost of Manual Operations

A conservative estimate: 8-12% of potential productivity was lost strictly due to information lag — dispatchers allocating trucks based on 10-15 minute old information, cycle times recorded inaccurately, and maintenance decisions being purely reactive (fix when broken) rather than proactive. At HPU's scale, this equals billions of Rupiah lost per month.

Engineering Challenges

  1. Multi-Site Architecture: The platform must serve multiple sites simultaneously, with each site having vastly different internet qualities — from spotty VSAT to 4G.
  2. Offline-First at Remote Sites: The North Kalimantan site (Kelubir-Bulungan) is wildly remote — the system MUST continue running when the connection inevitably drops.
  3. Real-Time Fleet Tracking: Hundreds of units moving simultaneously, requiring position updates every few seconds without drowning the heavily restricted bandwidth.
  4. Multi-Level Role-Based Access: From field operators, site supervisors, to Jakarta HQ management — every level requires a tightly controlled, distinct view.
  5. Integration Complexity: Merging data from GPS trackers, fuel sensors, weighbridges, and existing legacy mine planning systems.
  6. Regulatory Compliance: Operational data must strictly comply with the Ministry of Energy and Mineral Resources (ESDM) regulations and green mining environmental standards.

🏗️ 2. Architecture Overview

High-Level System Architecture

The platform was built using a robust Hub-and-Spoke architecture — each site has a local edge server processing data independently, which then painstakingly synchronizes to the central hub in the cloud.

graph TD
    subgraph "Site East Kalimantan - Kutai Kartanegara"
        A1[GPS Tracker Fleet] -->|MQTT| B1[Edge Server Kaltim]
        A2[Fuel Sensor] -->|Modbus/TCP| B1
        A3[Weighbridge] -->|API| B1
        B1 -->|Local Dashboard| C1[Site Control Room]
    end

    subgraph "Site Central Kalimantan - Barito Utara"
        A4[GPS Tracker Fleet] -->|MQTT| B2[Edge Server Kalteng]
        A5[Fuel Sensor] -->|Modbus/TCP| B2
        B2 -->|Local Dashboard| C2[Site Control Room]
    end

    subgraph "Site North Kalimantan - Bulungan KMO"
        A6[GPS Tracker Fleet] -->|MQTT| B3[Edge Server Kaltara]
        A7[Fuel Sensor] -->|Modbus/TCP| B3
        B3 -->|Local Dashboard| C3[Site Control Room]
    end

    B1 -->|Sync via HTTPS| D[Central Platform - Cloud]
    B2 -->|Sync via HTTPS| D
    B3 -->|Sync via HTTPS/VSAT| D

    D --> E[Central Dashboard - Jakarta HQ]
    D --> F[Analytics & BI Engine]
    D --> G[HSE Management Module]
    D --> H[Mine Planning Integration]
    D --> I[(Central Database)]

Data Flow: Field to Management

sequenceDiagram
    participant F as Fleet (GPS/Sensor)
    participant E as Edge Server (Site)
    participant DB as Local DB
    participant C as Central Cloud
    participant D as Dashboard (HQ)
    participant M as Management App

    F->>E: Raw telemetry (MQTT, 5-sec interval)
    E->>E: Normalize, validate, buffer
    E->>DB: Store locally (always available)
    E->>E: Process rules (geofence, speed, idle)

    alt Cloud Connection Available
        E->>C: Batch sync (compressed, delta)
        C->>C: Aggregate multi-site data
        C->>D: Push real-time update (WebSocket)
        C->>M: API for mobile app
    else Connection Dead
        E->>DB: Continue buffering
        Note over E,DB: Site continues operating 100% normally
    end

    Note over E,C: Upon Connection Restore
    DB->>E: Read buffered data
    E->>C: Bulk sync (catch-up)
    C->>C: Deduplicate & merge

Key Architecture Decisions:

Hub-and-Spoke vs Full Cloud

Ah, initially we considered a full cloud architecture — absolutely all data piped directly to the cloud. But the connectivity at the North Kalimantan site (KMO Bulungan) relies purely on a shared 512 kbps VSAT. The hub-and-spoke architecture guarantees every site is operationally independent even if the cloud connection is completely severed.

Edge Processing for Real-Time Alerting

Critical alerts (geofence breaches, extreme overspeeding, severe engine anomalies) are processed strictly at the edge server, not in the cloud. Latency to the cloud can be 1-3 seconds, but safety alerts MUST be sub-second. The edge server rocks a local rule engine that instantly pushes to the control room.

MQTT for Field-to-Edge, HTTPS for Edge-to-Cloud

MQTT is absolutely mandatory between the GPS trackers and the edge server because it is delightfully lightweight and flawlessly reliable on highly flaky connections. However, for the edge-to-cloud sync, we chose HTTPS because it's significantly easier to manage through aggressive corporate firewalls and proxies, and bandwidth is fine since data is heavily batched and brutally compressed.

Multi-Tenant with Site Isolation

Despite being a single unified platform, every site possesses brutal data isolation. A supervisor at the East Kalimantan site is physically incapable of seeing operational data from the North Kalimantan site unless they hold the exact high-level management role. This is critical for data security involving drastically different client contracts across sites.


🛠️ 3. Technology Stack

Technology Role Reason
Golang Core backend services, API gateway High-concurrency, stunningly low memory footprint, perfect for thousands of telemetry connections
PostgreSQL Primary database (central) Complete ACID compliance, PostGIS for hyper-fast spatial queries, incredibly mature ecosystem
Apache Kafka Event streaming (central hub) Bulletproof durable event log, replay capability, heavy multi-consumer support
Redis Real-time state cache Fleet current state tracking, session management, brutal rate limiting
gRPC Inter-service communication Ultra-low latency, strongly-typed, insanely efficient for internal microservices

Core Data Schema: Fleet Telemetry

PropertyTypeDescription
device_id string Unique incredibly specific identifier for the GPS tracker (format: SITE-TYPE-NNN, e.g. KTM-DT-042 = Kaltim Dump Truck #42).
unit_code string Heavy equipment unit code exactly matching the HPU register (e.g. HD785-007).
timestamp time.Time Exact UTC timestamp precisely when data was captured by the GPS tracker.
latitude float64 GPS latitude coordinate (WGS84).
longitude float64 GPS longitude coordinate (WGS84).
speed float64 Current vehicle speed locked in km/h.
heading float64 Vehicle directional heading strictly in degrees (0-360).
ignition boolean Raw ignition on/off status — absolutely critical for meticulously calculating idle vs productive time.
fuel_level float64 Current fuel level mapped in liters (direct from analog fuel sensor).
payload_ton float64 Dump truck massive payload weight in tons (direct from payload monitoring system or weighbridge).
engine_hours float64 Total brutal operational engine hours (hour meter) — the hardcore baseline for maintenance scheduling.
site_id string Hardcoded site identifier: 'KTM' (East Kaltim), 'KTG' (Central Kalteng), 'KTR' (North Kaltara).

📁 4. Project Structure

  • hpu-mining-platform
    • services
      • fleet-service
        • main.go
        • telemetry_handler.go
        • dispatch_optimizer.go
        • geofence_evaluator.go
        • cycle_time_calculator.go
      • fuel-service
        • main.go
        • consumption_tracker.go
        • anomaly_detector.go
        • refueling_validator.go
      • hse-service
        • main.go
        • incident_handler.go
        • safety_rules.go
        • inspection_scheduler.go
      • sync-service
        • main.go
        • edge_sync.go
        • conflict_resolver.go
        • compressor.go
      • auth-service
        • main.go
        • rbac.go
        • site_isolation.go
    • edge-server
      • main.go
      • mqtt_ingestion.go
      • local_rule_engine.go
      • sync_manager.go
      • fuel_reader.go
    • proto
      • telemetry.proto
      • fleet.proto
      • hse.proto
      • fuel.proto
    • dashboard
      • src
        • pages/
        • components/
        • hooks/
      • package.json
    • mobile-app
      • src/
      • package.json
    • infra
      • docker-compose.yml
      • terraform/
      • monitoring/

🔍 5. Feature Deep Dives

Feature #1: Fleet Management System (FMS) & Real-Time Dispatch

The Brutal Problem: Dispatchers in the control room were blindly relying on cracking radio HTs to desperately direct the fleet. With dozens of massive dump trucks and several excavators operating simultaneously, the dispatcher possessed absolutely zero real-time visibility on positions or status. The catastrophic result: Trucks constantly queuing helplessly at one loading point while another loading point sat completely idle.

The God-Tier Solution: A fully automated real-time Fleet Management System with aggressive dispatch optimization driven by exact positions, queue lengths, and deep historical cycle times.

graph TD
    A[GPS Tracker on Every Unit] -->|MQTT 5-sec| B[Edge Server]
    B -->|Process| C[Fleet State Manager]
    C -->|Update| D[(Redis - Current State)]
    D -->|Feed| E[Dispatch Optimizer]
    F[Queue Monitor per Loading Point] -->|Feed| E
    G[Cycle Time History - InfluxDB] -->|Feed| E
    E --> H{Assignment Decision}
    H -->|Shortest Queue| I[Assign to Excavator A]
    H -->|Nearest Unit| J[Assign to Excavator B]
    H -->|Balanced Load| K[Assign to Excavator C]
    I --> L[Push deeply to Driver Display / Radio]
    J --> L
    K --> L
    L --> M[Driver Strictly Follows Route]
    M --> N[Arrival Flawlessly Detected via Geofence]
    N --> O[Instantly Update Queue Counter]

    style E fill:#dbeafe,stroke:#3b82f6,color:#000
    style H fill:#fef3c7,stroke:#f59e0b,color:#000
services/fleet-service/dispatch_optimizer.go
// Multi-Factor Brutal Dispatch Optimizer
type DispatchDecision struct {
    TruckID       string  `json:"truck_id"`
    UnitCode      string  `json:"unit_code"`
    ExcavatorID   string  `json:"excavator_id"`
    LoadingPoint  string  `json:"loading_point"`
    EstimatedETA  float64 `json:"eta_minutes"`
    QueuePosition int     `json:"queue_position"`
    Score         float64 `json:"score"`
}

func (d *DispatchService) OptimizeAssignment(ctx context.Context, truckID string) (*DispatchDecision, error) {
    // 1. Instantly pull current truck state from Redis
    truck, err := d.cache.GetFleetState(ctx, truckID)
    if err != nil {
        return nil, fmt.Errorf("crushing failure: truck state not found: %w", err)
    }

    // 2. Fetch ALL active excavators and strictly monitor queue lengths
    excavators, err := d.getActiveExcavators(ctx, truck.SiteID)
    if err != nil {
        return nil, err
    }

    // 3. Score every single excavator: distance (40%) + queue (35%) + avg cycle (25%)
    var best *DispatchDecision
    var bestScore float64

    for _, exc := range excavators {
        distance := haversineKm(truck.Location, exc.Location)
        avgCycle := d.getCycleTimeAvg(ctx, truckID, exc.ID)

        distScore := 1.0 / (1.0 + distance)
        queueScore := 1.0 / (1.0 + float64(exc.QueueLength))
        cycleScore := 1.0 / (1.0 + avgCycle)

        score := (distScore * 0.40) + (queueScore * 0.35) + (cycleScore * 0.25)

        if score > bestScore {
            bestScore = score
            best = &DispatchDecision{
                TruckID:       truckID,
                UnitCode:      truck.UnitCode,
                ExcavatorID:   exc.ID,
                LoadingPoint:  exc.LoadingPoint,
                EstimatedETA:  distance / avgSpeedKmPerMin(truck.UnitType),
                QueuePosition: exc.QueueLength + 1,
                Score:         score,
            }
        }
    }

    // 4. Forcefully publish dispatch decision
    d.kafka.Publish("dispatch.decision", best)
    return best, nil
}

Cycle Time Tracking (Automated Perfection):

graph LR
    A["🟢 LOADING<br/>Excavator fills the heavy payload"] --> B["🔵 HAULING (Loaded)<br/>Massive truck heads to dumping zone"]
    B --> C["🟡 DUMPING<br/>Vigorously unloading material"]
    C --> D["🔵 HAULING (Empty)<br/>Racing back to load"]
    D --> E["🟠 QUEUING<br/>Waiting aggressively for next load"]
    E --> A

    style A fill:#d1fae5,stroke:#10b981,color:#000
    style B fill:#dbeafe,stroke:#3b82f6,color:#000
    style C fill:#fef3c7,stroke:#f59e0b,color:#000
    style D fill:#dbeafe,stroke:#3b82f6,color:#000
    style E fill:#fed7aa,stroke:#f97316,color:#000

Every single phase of the cycle time is detected with massive automation via geofences (entering/exiting loading zones, dumping zones) and ignition status (moving vs stationary). This deeply granular data instantly computes:

  • Effective Working Time (EWT): Total productive time vs completely wasted idle time
  • Truck Factor: The mathematically perfect ratio of trucks per excavator
  • Match Factor: The raw efficiency of that specific truck-excavator pairing

Insane Results:

Metric Before (Pathetic Manual) After (FMS God-Mode) Brutal Improvement
Avg cycle time 35 minutes 26 minutes ↓ 26%
Queue time at loading 10-15 minutes 3-5 minutes ↓ 65%
Truck utilization (PA × MA × UA) 65% 79% ↑ 22%
Dispatch decision time 2-3 minutes (screaming on radio) < 5 seconds (auto logic) ↓ 97%
Cycle time data accuracy ~60% (lazy manual) 99%+ (flawless auto) ↑ 65%

Feature #2: Fuel Management & Anomaly Detection

The Brutal Problem: Fuel is unequivocally the second-largest operational cost right after equipment rentals (easily devouring 25-30% of total OPEX). Manual recording at site fuel stations is violently inaccurate, and detecting fuel theft or abnormal consumption was previously completely impossible in real-time.

The God-Tier Solution: End-to-end ruthless fuel tracking from the massive storage tanks, through the dispenser pumps, straight into the exact consumption per unit — heavily armed with automated anomaly detection.

graph TD
    A[Fuel Storage Tank] -->|Level Sensor| B[Edge Server]
    C[Fuel Dispenser / Site Gas Station] -->|Flow Meter| B
    D[Massive Vehicle Fuel Sensor] -->|MQTT| B
    B --> E[Hyper-Aggressive Fuel Reconciliation Engine]
    E --> F{Total Anomaly Check}
    F -->|Normal| G[Log & Clean Dashboard]
    F -->|Sudden Drop > Threshold| H[Alert: CRITICAL POSSIBLE THEFT]
    F -->|Consumption > 130% Baseline| I[Alert: Disgustingly Inefficient Unit]
    F -->|Refuel vs Dispense Mismatch| J[Alert: Reconciliation Mismatch]
    H --> K[Instantly Notify Security & Top Supervisor]
    I --> L[Notify Heavy Maintenance Team]
    J --> M[Notify Logistics Fuel Coordinator]

    style F fill:#fef3c7,stroke:#f59e0b,color:#000
    style H fill:#fee2e2,stroke:#ef4444,color:#000
    style I fill:#fef3c7,stroke:#f59e0b,color:#000
    style J fill:#fef3c7,stroke:#f59e0b,color:#000
services/fuel-service/anomaly_detector.go
// Hyper-Aggressive Fuel Anomaly Detection Rules
type FuelAnomaly struct {
    UnitCode    string    `json:"unit_code"`
    Type        string    `json:"type"`
    Severity    string    `json:"severity"`
    Description string    `json:"description"`
    DetectedAt  time.Time `json:"detected_at"`
    FuelDelta   float64   `json:"fuel_delta_liters"`
    Expected    float64   `json:"expected_liters"`
}

func (d *AnomalyDetector) Evaluate(ctx context.Context, event FuelEvent) []FuelAnomaly {
    var anomalies []FuelAnomaly
    unit := d.getUnitProfile(ctx, event.UnitCode)

    switch event.Type {
    case "consumption":
        // Rule 1: Horrible Consumption rate vs clean baseline
        baseline := d.getBaselineConsumption(ctx, event.UnitCode, event.ActivityType)
        ratio := event.ConsumptionRate / baseline.AvgRate

        if ratio > 1.30 {
            anomalies = append(anomalies, FuelAnomaly{
                UnitCode:    event.UnitCode,
                Type:        "HIGH_CONSUMPTION",
                Severity:    "WARNING",
                Description: fmt.Sprintf("%s monstrous consumption %.1f L/hr vs baseline %.1f L/hr (%.0f%% insanely above normal)",
                    event.UnitCode, event.ConsumptionRate, baseline.AvgRate, (ratio-1)*100),
                FuelDelta:   event.ConsumptionRate - baseline.AvgRate,
                Expected:    baseline.AvgRate,
            })
        }

    case "level_change":
        // Rule 2: Sudden violent fuel level drop (GUARANTEED theft)
        if event.FuelDelta < -50 && !d.hasRecentRefuelRecord(ctx, event.UnitCode) {
            anomalies = append(anomalies, FuelAnomaly{
                UnitCode:    event.UnitCode,
                Type:        "SUDDEN_DROP",
                Severity:    "CRITICAL",
                Description: fmt.Sprintf("%s fuel level violently dropped by %.0f liters with ZERO refuel record — ACTIVATE IMMEDIATE INVESTIGATION",
                    event.UnitCode, -event.FuelDelta),
                FuelDelta:   event.FuelDelta,
            })
        }

    case "refueling":
        // Rule 3: Refuel amount vs dispenser record heavy mismatch
        dispenserRecord := d.getDispenserRecord(ctx, event.UnitCode, event.Timestamp)
        if dispenserRecord != nil {
            gap := math.Abs(event.FuelDelta - dispenserRecord.Volume)
            tolerance := dispenserRecord.Volume * 0.05 // Tiny 5% tolerance
            if gap > tolerance {
                anomalies = append(anomalies, FuelAnomaly{
                    UnitCode:    event.UnitCode,
                    Type:        "RECONCILIATION_GAP",
                    Severity:    "WARNING",
                    Description: fmt.Sprintf("%s massive refuel discrepancy: sensor showed %.0f L vs pump recorded %.0f L (fatal gap: %.0f L)",
                        event.UnitCode, event.FuelDelta, dispenserRecord.Volume, gap),
                    FuelDelta:   gap,
                    Expected:    dispenserRecord.Volume,
                })
            }
        }
    }

    return anomalies
}
Real Impact: Exposing Fuel Theft Instantly

In the very first month of deployment, the hyper-aggressive system detected 3 full-blown incidents of sudden fuel drops in the dead of night on massive units that were supposed to be completely parked. The total vanished? ~650 liters of diesel (~Rp 10 million). Immediate brutal investigation 100% confirmed fuel theft. Before this god-tier system existed, these massive anomalies went completely undetected because lazy manual recording was only ever done per 12-hour shift.

Insane Results:

Metric Before (Pathetic Manual) After (God-Mode Digital) Impact
Fuel tracking accuracy ~85% (fake manual logs) 98%+ (hard sensors) ↑ 15%
Fuel anomaly detection 1-7 days (slow manual audit) < 5 minutes (instant real-time) ↓ 99%+
Massive Fuel cost savings Terrible Baseline ↓ 8-12% per year Gigantic
Reconciliation gap ~5-8% chaos < 1% flawless ↓ 87%

Feature #3: HSE Digital Management

The Brutal Problem: HPU rightfully boasts insane safety standards (proven by hitting 5.7+ million working hours with zero accidents at one master site). However, the HSE recording process was a pathetic joke of paper forms — near miss reporting took agonizing days, safety inspections were impossible to track globally, and deep analytics for trend identification were completely missing.

The God-Tier Solution: We fused a massive HSE management module straight into the platform — obliterating everything from incident reporting, safety inspections, straight up to predictive safety analytics.

graph TD
    A["📱 Field Mobile App<br/>(Supervisor/Operator)"] --> B{HSE Mega-Module}
    B --> C["🚨 Instant Incident Report<br/>Near Miss / Hard Accident"]
    B --> D["📋 Ruthless Safety Inspection<br/>Daily / Weekly Checklists"]
    B --> E["🎓 Rapid Safety Training<br/>Log & Hard Certification"]
    B --> F["⚡ SWA / JSA<br/>Aggressive Safe Work Analysis"]

    C --> G[HSE Dashboard - Site Level Dominance]
    D --> G
    E --> G
    F --> G

    G --> H[Deep Trend Analytics Engine]
    H --> I{Pattern Recognition}
    I -->|High near-miss death zone| J["🟡 CRITICAL Warning: Hotspot Area"]
    I -->|Equipment type failure trend| K["🟡 FATAL Warning: Equipment Risk"]
    I -->|Time pattern collapse trend| L["🟡 DANGER Warning: Shift Fatigue"]
    J --> M[Digital Safety Bulletin Board]
    K --> M
    L --> M

    G --> N[Elite HSE Summary - HQ Jakarta]

    style C fill:#fee2e2,stroke:#ef4444,color:#000
    style J fill:#fef3c7,stroke:#f59e0b,color:#000
    style K fill:#fef3c7,stroke:#f59e0b,color:#000
    style L fill:#fef3c7,stroke:#f59e0b,color:#000

Rapid HSE Reporting Flow:

Reporter smashes open the mobile app

Supervisors or operators rip open the HSE module right on the mobile app. The furious incident report form is explicitly built offline-first — filled completely flawlessly without a single bar of internet, automatically slamming in photos and hard GPS coordinates.

Fill out the strict structured form

The form violently utilizes a guided flow ruthlessly based on the incident type (near miss, first aid, medical treatment, lost time injury). Every single type aggressively forces different mandatory fields, obliterating incomplete reports from a pathetic ~25% down to an absolute < 3%.

Auto-classification & brutal routing

Based entirely on severity and incident type, the relentless system immediately auto-routes the report to the exact necessary parties: Elite HSE Officers, Site Managers, or instantly bypasses everyone straight to HQ if the severity is a massive critical. Never manually forward a pathetic email again.

Hard Investigation & root cause analysis

The HSE team goes absolutely nuclear on investigations using heavily built-in templates like 5-Why Analysis or Fishbone Diagrams fully available in the system. Every single finding and corrective action is permanently recorded and aggressively trackable.

Corrective action tracking dominance

Every single corrective action is chained to a PIC, a hard deadline, and brutal status tracking. The ruthless system fires automated screaming reminders if they get close to or completely blow past a deadline. Top management stares directly at the completion rates in pure real-time.

Deep Analytics & massive trend prevention

Massive historical data gets sliced and diced to expose terrifying patterns — exactly which zone is spawning near-misses, the exact hour incidents detonate the most, which specific equipment is a ticking time bomb. This brutally forced shift turns HSE from a pathetic reactive (investigating after chaos) state into an incredibly powerful proactive (killing incidents before they spawn) God-mode.

Insane Results:

Metric Before (Pathetic Paper) After (God-Mode Digital) Impact
Near miss reporting time 24-48 agonizing hours < 30 minutes ↓ 96%
Incomplete HSE report trash ~25% < 3% ↓ 88%
Corrective action completion rate ~65% mediocre 92% massive ↑ 42%
Time to generate lazy HSE report (monthly) 3-5 wasted days Real-time (instant auto) ↓ 100%
Safety trend identification Pathetic Manual (retrospective) Proactive (deep pattern-based) Absolute Paradigm shift

Feature #4: Multi-Site Command Center Dashboard

The Brutal Problem: The elite management sitting in HPU Jakarta Head Office had absolutely zero real-time visibility into the massive operations bleeding across all their sites. Reports dragged in weekly via pathetic emails choked with excel spreadsheets — the data was totally stale the second they looked at it. Comparing raw performance across sites apples-to-apples was a nightmare.

The God-Tier Solution: We built a heavily centralized Command Center Dashboard. It visually dominates all raw operational KPIs across every single site locked onto a single screen, updating with terrifying real-time perfection.

Pure Real-time fleet map flawlessly exposes the exact position of every massive unit across every single site on one ultra-map. Brutally filter by site, equipment type, or live status (active/idle/dead maintenance).

Widget Brutal Data Update Interval
Live Fleet Map Absolute position of every unit (multi-site) 5 seconds
Active Units Count Grinding units vs totally dead fleet 30 seconds
Idle Screaming Alert Units pathetically idle > 15 minutes Real-time
Equipment Availability Hard PA / MA / UA per site 5 minutes
Dispatch Queue Immediate queues crushing each loading point Real-time

Key Technical Implementation:

services/fleet-service/multi_site_aggregator.go
// Massive Multi-Site KPI Aggregator — fires endlessly every 5 minutes
type SiteKPI struct {
    SiteID            string  `json:"site_id"`
    SiteName          string  `json:"site_name"`
    ActiveUnits       int     `json:"active_units"`
    TotalUnits        int     `json:"total_units"`
    AvgCycleTime      float64 `json:"avg_cycle_time_min"`
    ProductionTons    float64 `json:"production_tons_today"`
    TargetTons        float64 `json:"target_tons_today"`
    FuelConsumption   float64 `json:"fuel_liters_today"`
    SafeManHours      int64   `json:"safe_man_hours"`
    OpenIncidents     int     `json:"open_incidents"`
    TruckUtilization  float64 `json:"truck_utilization_pct"`
}

func (a *Aggregator) ComputeMultiSiteKPI(ctx context.Context) ([]SiteKPI, error) {
    sites := []string{"KTM", "KTG", "KTR"}
    var results []SiteKPI

    for _, siteID := range sites {
        // Brutal Parallel fetch violently grabbing from multiple data sources
        var wg sync.WaitGroup
        var fleet FleetSummary
        var production ProductionSummary
        var fuel FuelSummary
        var hse HSESummary

        wg.Add(4)
        go func() { defer wg.Done(); fleet = a.fleetService.GetSiteSummary(ctx, siteID) }()
        go func() { defer wg.Done(); production = a.productionService.GetDailySummary(ctx, siteID) }()
        go func() { defer wg.Done(); fuel = a.fuelService.GetDailySummary(ctx, siteID) }()
        go func() { defer wg.Done(); hse = a.hseService.GetSiteSummary(ctx, siteID) }()
        wg.Wait()

        results = append(results, SiteKPI{
            SiteID:           siteID,
            SiteName:         getSiteName(siteID),
            ActiveUnits:      fleet.ActiveCount,
            TotalUnits:       fleet.TotalCount,
            AvgCycleTime:     fleet.AvgCycleTime,
            ProductionTons:   production.ActualTons,
            TargetTons:       production.TargetTons,
            FuelConsumption:  fuel.TotalLiters,
            SafeManHours:     hse.SafeManHours,
            OpenIncidents:    hse.OpenIncidents,
            TruckUtilization: fleet.Utilization,
        })
    }

    // Violently Cache massive aggregated KPI
    a.cache.Set(ctx, "kpi:multi_site", results, 5*time.Minute)

    // Instantly Push to all connected dashboards via WebSocket
    a.wsHub.Broadcast("kpi.update", results)

    return results, nil
}
From Pathetic Weekly Email to Absolute Real-Time Visibility

Historically, the top management in Jakarta merely received operational reports sadly every single Monday morning (reporting on the dead previous week) wrapped in a pathetic Excel file sent via slow email. Now? They smash open the dashboard and flawlessly look at the entire multi-site operation blazing in pure real-time. Brutal operational decisions that used to drag on for days (like physically reallocating heavy equipment across wildly different sites) are now aggressively executed in mere hours.


Feature #5: Edge-to-Cloud Sync Pipeline

The Brutal Problem: The raw connectivity at every single site was a chaotic nightmare — Site Kaltim boasted a decent 4G connection, Site Kalteng fought through a radio link, and Site Kaltara (KMO Bulungan) was absolutely strangled relying purely on a shared 512 kbps VSAT. The entire massive platform had to flawlessly survive all conditions.

The God-Tier Solution: We built a highly aggressive adaptive sync pipeline deeply armed with intelligent prioritization and extremely brutal data compression explicitly tailored per available bandwidth tier.

graph TD
    A[Massive Edge Server] --> B{Aggressive Bandwidth Detection}
    B -->|"4G / Strong Fiber (> 5 Mbps)"| C[Total Full Sync Mode]
    B -->|"Medium Radio Link (1-5 Mbps)"| D[Heavily Optimized Sync Mode]
    B -->|"Garbage VSAT (< 1 Mbps)"| E[Brutally Minimal Sync Mode]
    B -->|"Dead No Connection"| F[Pure Buffer Mode]

    C --> G["Sync massive data, 5-sec fast interval<br/>JSON + gzip"]
    D --> H["Sync core essential data, 30-sec interval<br/>Protobuf + zstd"]
    E --> I["Sync CRITICAL only, 5-min interval<br/>Protobuf + zstd + delta"]
    F --> J["Strict Buffer straight to SQLite<br/>Massive Sync upon connection restore"]

    G --> K[Central Cloud HQ]
    H --> K
    I --> K
    J -.->|"Instantly when connection recovers"| K

    style C fill:#d1fae5,stroke:#10b981,color:#000
    style D fill:#fef3c7,stroke:#f59e0b,color:#000
    style E fill:#fed7aa,stroke:#f97316,color:#000
    style F fill:#fee2e2,stroke:#ef4444,color:#000
edge-server/sync_manager.go
// Hyper-Adaptive Sync Manager — brutally adjusts behavior entirely based on active bandwidth
type SyncMode string
const (
    SyncFull      SyncMode = "full"       // > 5 Mbps
    SyncOptimized SyncMode = "optimized"  // 1-5 Mbps
    SyncMinimal   SyncMode = "minimal"    // < 1 Mbps
    SyncBuffer    SyncMode = "buffer"     // Dead connection
)

func (s *SyncManager) detectMode(ctx context.Context) SyncMode {
    bandwidth := s.bandwidthProbe.Measure(ctx) // Aggressive Periodic bandwidth test
    switch {
    case bandwidth == 0:
        return SyncBuffer
    case bandwidth < 1_000_000: // < 1 Mbps
        return SyncMinimal
    case bandwidth < 5_000_000: // < 5 Mbps
        return SyncOptimized
    default:
        return SyncFull
    }
}

func (s *SyncManager) SyncLoop(ctx context.Context) {
    for {
        mode := s.detectMode(ctx)
        switch mode {
        case SyncFull:
            s.syncAll(ctx, 5*time.Second, EncodingJSON, CompressionGzip)
        case SyncOptimized:
            s.syncEssential(ctx, 30*time.Second, EncodingProtobuf, CompressionZstd)
        case SyncMinimal:
            s.syncCriticalOnly(ctx, 5*time.Minute, EncodingProtobuf, CompressionZstd)
        case SyncBuffer:
            time.Sleep(10 * time.Second) // Check nervously again in 10s
            continue
        }
    }
}

// Brutal Priority: alerts > fleet state > fuel > production > HSE (lazy non-urgent)
func (s *SyncManager) syncCriticalOnly(ctx context.Context, interval time.Duration, enc Encoding, comp Compression) {
    ticker := time.NewTicker(interval)
    defer ticker.Stop()

    for range ticker.C {
        // ONLY sync: screaming safety alerts + absolute fleet current position + massive fuel anomalies
        alerts := s.buffer.GetUnsynced(ctx, PriorityCritical, 50)
        if len(alerts) > 0 {
            payload := encode(alerts, enc, comp)
            s.httpClient.Post(ctx, "/api/v1/sync/critical", payload)
            s.buffer.MarkSynced(ctx, alerts)
        }
    }
}

Bandwidth Usage per Sync Mode:

Sync Mode Interval Avg Payload/sync Monthly Est. Extreme Use Case
Total Full 5 sec 12 KB ~6 GB God-mode Site on fiber/4G
Optimized 30 sec 3 KB (Protobuf) ~260 MB Mid Site struggling with radio link
Minimal 5 min 800 bytes ~7 MB Garbage Site VSAT (Kaltara KMO)
Dead Buffer — 0 (all local) 0 Total connectivity blackout
VSAT Total Reality Check

At Site KMO Bulungan, the disgustingly slow 512 kbps VSAT was intensely shared across the entire camp — office, mess halls, and operational fields. Our massive platform was starved to a pathetic ~100 kbps. But by deploying the genius Minimal Sync mode heavily armed with Protocol Buffers + Zstd compression, we gloriously succeeded in firing the complete fleet tracking data for over 40 heavy units burning a mind-blowing ~7 MB per month. Completely without this extreme optimization, raw JSON would have horrifically demanded ~50 MB — flat out impossible on that garbage bandwidth.


🚢 6. Implementation & Massive Rollout

Phase 1: The Pilot Site — Kutai Kartanegara (East Kaltim)

The undisputed biggest site in HPU armed with the absolute best connectivity was flawlessly chosen as the pilot. We deployed the massive edge server, ruthlessly installed GPS trackers deep into 60 massive units, and aggressively launched the Fleet Management + basic dashboard. Fought to completely validate data accuracy and crush user acceptance for 2 brutal months.

Phase 2: The God-Mode Fuel Management Module

Once the fleet tracking was completely rock solid, we aggressively integrated fuel sensors and heavy flow meters deep into the SPBU sites. We deployed the terrifying anomaly detection rules. We brutally calibrated thresholds specifically per equipment type because the extreme consumption of an HD785 (massive 40-ton beast) is wildly different than a PC2000 (excavator).

Phase 3: The Flawless HSE Digital Module

We aggressively launched the massive HSE reporting via the elite mobile app straight to supervisors. We painstakingly migrated thousands of historical incident reports from garbage Excel spreadsheets into the pristine platform. We fiercely trained the entire elite HSE team right on site to totally dominate the new digital workflow.

Phase 4: Extreme Expansion to Site Kalteng (Barito Utara)

Furious deployment of massive edge servers and deep GPS trackers. Brutally adapted the platform to survive the flaky radio link connection (deploying optimized sync mode). Rapidly adjusted mine plan geofences and huge areas perfectly matching the local site's crazy topography.

Phase 5: Absolute Nightmare Expansion to Site Kaltara (KMO Bulungan)

The absolute hardest, most insanely challenging site — surviving on pathetic VSAT only. We viciously deployed the brutal minimal sync mode. We rigorously validated that massive operations continued completely 100% normal when the connection inevitably detonated. The edge server was forced to be 100% reliable surviving entirely independently.

Phase 6: The Central Command Center (HQ Jakarta)

Aggressive launch of the massive multi-site dashboard straight into the heart of the head office. We deeply trained the entire high-level management team. We deployed the fully automated daily/weekly massive report generation, completely annihilating the pathetic era of manual spreadsheets forever.


🚀 7. Overall Massive Business Impact

The Brutal Key Numbers
  • Massive Cycle time: violently down by 26% (from 35 min → 26 min) — forcing hundreds of extra trips per day - Heavy Truck utilization: exploded upward 22% (from 65% → 79%) — massive ROI hitting raw productivity - Huge Fuel cost: deeply reduced by 8-12% annually exclusively via the brutal anomaly detection and killing idle limits - HSE screaming reporting time: collapsed by an insane 96% — dropping from an agonizing 24-48 hours heavily down to under 30 minutes - Top Management visibility: upgraded from pathetic weekly emails → true real-time multi-site absolute command center - Caught Fuel theft: 3 incidents exposed in month one (~650 liters, ~Rp 10 million trapped) - Flawless Safe man hours: automated and laser accurate tracking for intense compliance reporting

Massive ROI Summary per Deep Module

# Heavy Module Bleak Before God-Tier After Massive Estimated Annual Value
1 Fleet God Management 35 min cycle, terrible 65% utilization 26 min, raging 79% +15-20% massive production volume jump
2 Fuel Surveillance 5-8% ugly reconciliation gap < 1% flawless gap + catching theft instantly Rp 2-4 massive billion/year heavy savings
3 HSE Total Digital Pathetic Paper-based, reactive tragedy Fully Digital, proactive domination Absolutely Priceless (saves real human lives) + total compliance
4 Multi-Site Mega Dashboard Slow Weekly email reports Complete Real-time god command center Lightning Faster decision making → direct massive revenue impact
5 Edge-to-Cloud Sync Beast N/A (no chance remote site survived) Survives perfectly on garbage 100 kbps VSAT Massive Enabler powering operations deep in remote chaos

🏢 8. Post-Launch: Harsh Challenges & Ultimate Evolution

8.1 GPS Tracker Absolute Reliability in the Brutal Mining Environment

The undisputed hardest challenge post-launch was fighting the hardware reliability nightmare:

Heavy Problem Furious Root Cause Endless Frequency Absolute Solution
Crazy GPS drift Thick toxic dust totally blinding antenna ~5% units/day Aggressive Auto-detect drift > 50m under 1 sec → brutally filter out
Tracker completely offline Violent vibrations shattering connectors ~3% units/day Hardcore Industrial connectors + heavily vibration-dampened absolute mounting
Fuel sensor static noise Endless vibrations over destroyed mining roads Always Constant Heavy Moving average filter (deep 30-sec window)
Fatal Power spike Massive Engine start/stop detonations Every single ignition Ultimate Wide-voltage regulator (spanning 9-36V DC) + brutal surge protector

8.2 User Adoption: Forcing the Shift from Radio to Pure Digital

Heavy Dispatcher Resistance

The old dispatchers who ruled for 10+ grueling years screaming on crackling radio HTs viciously rejected the digital shift. The master strategy that ultimately broke them: we didn't eliminate the radio, we added a massive information God-layer. The radio survived just for pure voice commands, but dispatch assignments were heavily guided by the screaming real-time data on the screens. After a brutal 2-3 weeks, the dispatchers themselves violently refused to go backward because the massive dashboard information was completely addictive.

Field Supervisors vs The Strange Mobile App

Tough field supervisors were completely wedded to archaic clipboards and massive paper forms. Many severely lacked basic smartphone skills. The brutal solution: creating forms of pure idiocy. Huge massive buttons, zero typing (endless dropdowns and massive radio targets), and forcing heavy photo support to completely replace writing long endless descriptions.

Top Management Expectation vs Dark Data Reality

When the massive dashboard finally blasted live, top management was absolutely horrified to see screaming high idle time numbers and much slower cycle times compared to the manual reports they used to read. This was absolutely NOT because performance dropped — it was because the massive manual data from before was totally faked and completely inaccurate. It took multiple brutal intense sessions to drill into their heads that the terrifying digital numbers were the harsh dark reality that had been heavily covered up by ridiculously optimistic manual estimates.

Shift Handover & Extreme Data Continuity

The absolutely unique nightmare challenge: frantic operators swap endless shifts every 12 brutal hours, but the GPS tracker remains bolted to the massive unit. The hyper-system needed to perfectly chain telemetry data exactly to whoever was currently driving, not just the dumb machine itself. The absolute solution: requiring a hard NFC card scan in the heavy cabin perfectly logging shift start/end to aggressively register exactly which operator was active.

8.3 The Massive Connectivity Evolution

Harsh connectivity endlessly improved as heavy infrastructure investments landed:

graph LR
    A["2024 Q1<br/>🔴 Garbage VSAT Only<br/>512 kbps"] --> B["2024 Q3<br/>🟡 Medium VSAT + Radio Link<br/>2 Mbps"]
    B --> C["2025 Q1<br/>🟢 Clean 4G Tower<br/>10+ Mbps"]
    C --> D["2025 Q3<br/>🟢 God-Tier Fiber Backhaul<br/>50+ Mbps"]

    style A fill:#fee2e2,stroke:#ef4444,color:#000
    style B fill:#fef3c7,stroke:#f59e0b,color:#000
    style C fill:#d1fae5,stroke:#10b981,color:#000
    style D fill:#d1fae5,stroke:#10b981,color:#000

Our aggressive adaptive sync architecture that was built from day one turned out to be flawlessly future-proof — as the raw bandwidth exploded, the platform instantly gorged on the extra capacity with absolutely zero code changes. Sites that were trapped heavily using minimal sync now blast totally full sync with barely existing absolute minimal latency.


🎓 9. Deep Lessons Learned

  • Brutal Hub-and-spoke architecture completely proved that absolute edge independence is the total god-tier key to surviving in deeply remote mining chaos. Not a single site dropped dead simply because the cloud got isolated. - Our Adaptive sync that intelligently mutates to available bandwidth fiercely saved massive VSAT costs and totally enabled operation in the most savage ultra-remote sites. - Golang proved completely unstoppable on the edge server: an absolute single binary deployment, microscopically low memory, deeply high concurrency — the edge server viciously screaming on a tiny industrial PC with just 2GB of trash RAM. - The massive Fuel anomaly detection delivered the fastest ROI hit of all time — perfectly exposing pure theft in month one immediately justifying the entire heavy investment. - Multi-tenant brutal site isolation flawlessly guaranteed ultra-sensitive client contract data survived perfectly sealed inside the single massive platform. - Total HSE digitalization secured massive praise from top management because it finally meant hitting massive safe man hour records became mathematically perfect and deeply auditable.

The Dark Technical Debt Left Behind

# The Heavy Debt The Brutal Impact Urgency
1 The deep Predictive maintenance model is still disconnected Elite maintenance is still pathetically time-based, completely failing to be condition-based Massive
2 The massive Mine planning integration is pathetically one-way The massive plan gets violently pushed to the platform, but absolutely no auto-feedback flows back to the planners Extreme
3 The huge Dashboard completely lacks massive dark mode for night shift control rooms Cranky night shift operators viciously complain about aggressive screen glare Medium
4 Intense Alert fatigue — horribly spamming too many weak low-priority alerts Hardcore supervisors are dangerously starting to aggressively ignore completely non-critical alerts Massive
5 Massive Data retention policy still violently manual inside InfluxDB Storage costs are furiously scaling linearly, desperately requiring deep tiered storage Medium
6 The crucial Mobile app remains stubbornly lacking full flawless offline-capability HSE reporting deep in absolutely dead zones forces desperate manual buffering Medium

🎉 The Ultimate Conclusion

Engineering the massive digital platform for the raging HPU mining operations was entirely about surviving the violent collision between two diametrically opposed worlds — the pristine digital realm intensely demanding absolute connectivity and massive real-time data, versus the savage reality of the absolute deep Borneo mining fields completely suffocated in thick dust, violent vibrations, and internet connections that ghost out constantly.

Because the ultimate brutal truth is that the explosive success of this huge platform wasn't strictly judged by how insanely advanced our heavy tech was, but perfectly isolated to how totally invisible that tech vanished from the users. The dispatchers violently focused on pure dispatching, never on pathetic debugging. The HSE officers focused solely on absolute safety, completely ignoring any software troubleshooting nightmare.

The Dominant HPU Way in Pure Digital

PT Harmoni Panca Utama fiercely lives by brutal core values: Intense Integrity, Hard Work, Massive Smart Work, Complete Work, and Sincerity. Building this god-tier digital platform was the absolute manifestation of pure Smart Work — it completely refused to replace the incredibly hard work of the elite mining team, but existed solely to aggressively fortify them with the flawlessly correct information, at the exact perfect second, ensuring their brutal decisions evolved into pure extreme precision.

In the absolute end, every single furious line of code blasted into this massive platform answered strictly to one god-tier demand: securing the flawless guarantee that every single rugged HPU miner gets to proudly walk back home alive and supremely productive, every single blazing day.

Related stories

Product