Back to News/Case Study: Digital Mining Platform — PT Harmoni Panca Utama

Case Study: Digital Mining Platform — PT Harmoni Panca Utama

Faisal Affan
2/23/2026
Case Study: Digital Mining Platform — PT Harmoni Panca Utama — 1 / 2
1 / 2

Engineering Case Study: HPU Digital Mining Platform

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

Context

PT Harmoni Panca Utama (HPU) adalah salah satu perusahaan mining services terbesar di Indonesia, beroperasi di multi-site Kalimantan (Timur, Tengah, dan Utara) dengan 1,000-5,000+ karyawan dan armada alat berat yang masif. Saya berkontribusi dalam perancangan dan pengembangan digital platform yang mengintegrasikan Fleet Management, HSE monitoring, dan mine operations analytics untuk mendukung visi Operational Excellence HPU.

Proyek ini mentransformasi operasional tambang HPU dari proses yang sebagian besar manual — pencatatan kertas, komunikasi radio, spreadsheet Excel — menjadi platform digital terintegrasi yang memberikan visibility end-to-end ke seluruh operasi lintas site.

Artikel ini membedah tantangan teknis, arsitektur, dan keputusan engineering di balik pembangunan platform ini.


🏔️ 1. The Challenge

Profil Operasional HPU

PT Harmoni Panca Utama menjalankan operasi tambang batu bara di beberapa site strategis di Kalimantan:

Multi-Site Operations

Operasi tersebar di Kutai Kartanegara (Kaltim), Barito Utara (Kalteng), dan Bulungan (Kaltara) — masing-masing dengan kondisi geografis dan tantangan konektivitas berbeda.

Armada Masif

Ratusan unit alat berat — dump truck, excavator, bulldozer, grader — beroperasi 24/7 dengan shift system, membutuhkan koordinasi real-time.

HSE Excellence

Standar keselamatan HPU sangat tinggi, dibuktikan dengan pencapaian jutaan jam kerja tanpa kecelakaan. Sistem digital harus mendukung dan memperkuat budaya safety ini.

Green Mining Commitment

HPU menjalankan proses green mining — aspek lingkungan harus terintegrasi dalam monitoring operasional, termasuk tracking reklamasi dan emisi.

Kondisi Sebelum Digitalisasi

AspekKondisi LamaDampak
Fleet TrackingRadio HT + pengawas visualDispatcher tidak tahu posisi semua unit secara real-time
Cycle TimeCatat manual di kertas oleh checkerData terlambat masuk, sering tidak akurat, sulit dianalisis
HSE ReportingForm kertas → input manual ke ExcelIncident report memakan waktu berjam-jam, analytics terbatas
Fuel ManagementCatat manual di SPBU siteEstimasi konsumsi tidak akurat, rawan kebocoran/penyalahgunaan
Mine PlanningSoftware di PC kantor, tidak terintegrasiGap antara planning dan eksekusi di lapangan
Multi-Site VisibilityLaporan mingguan via emailManagement di Jakarta tidak punya real-time visibility

The Cost of Manual Operations

Estimasi konservatif: 8-12% potensi produktivitas hilang karena information lag — dispatcher mengalokasikan truk berdasarkan informasi yang sudah telat 10-15 menit, cycle time tercatat tidak akurat, dan keputusan maintenance bersifat reaktif (rusak baru perbaiki) bukan proaktif. Dalam skala operasi HPU, ini bernilai miliaran rupiah per bulan.

Tantangan Engineering

  1. Multi-Site Architecture: Platform harus melayani beberapa site sekaligus, dengan masing-masing memiliki koneksi internet yang berbeda-beda kualitasnya — dari VSAT hingga 4G.
  2. Offline-First di Remote Site: Site di Kalimantan Utara (Kelubir-Bulungan) sangat terpencil — sistem harus tetap berjalan saat koneksi putus.
  3. Real-Time Fleet Tracking: Ratusan unit bergerak simultan, memerlukan update posisi setiap beberapa detik tanpa membanjiri bandwidth yang terbatas.
  4. Role-Based Access Multi-Level: Dari operator di lapangan, supervisor site, hingga manajemen di kantor pusat Jakarta — setiap level butuh view yang berbeda.
  5. Integration Complexity: Menyatukan data dari GPS tracker, fuel sensor, weighbridge, dan sistem mine planning yang sudah ada.
  6. Regulatory Compliance: Data operasional harus sesuai dengan regulasi Kementerian ESDM dan standar lingkungan untuk green mining.

🏗️ 2. Architecture Overview

High-Level System Architecture

Platform dibangun dengan arsitektur Hub-and-Spoke — setiap site memiliki edge server lokal yang memproses data secara mandiri, kemudian disinkronisasi ke central hub di cloud.

Data Flow: Field to Management

Key Architecture Decisions:


🛠️ 3. Technology Stack

TechnologyPeranAlasan
GolangCore backend services, API gatewayHigh-concurrency, low memory footprint, cocok untuk handle ribuan koneksi telemetri
PostgreSQLPrimary database (central)ACID compliance, PostGIS untuk spatial queries, mature ecosystem
Apache KafkaEvent streaming (central hub)Durable event log, replay capability, multi-consumer support
RedisReal-time state cacheFleet current state, session management, rate limiting
gRPCInter-service communicationLow-latency, strongly-typed, efficient untuk internal services
TechnologyPeranAlasan
MQTT (Mosquitto)Device-to-edge protocolLightweight, designed untuk low-bandwidth environments
SQLite (WAL mode)Edge local databaseReliable, zero-config, tahan power fluctuation
Golang (edge binary)Edge server runtimeSingle binary deployment, no runtime dependencies
Protocol BuffersEdge-to-cloud serialization5-8x lebih kecil dari JSON, hemat bandwidth VSAT
Modbus TCPFuel sensor protocolStandard industri untuk sensor industrial
TechnologyPeranAlasan
InfluxDBTime-series data (telemetri)Query temporal cepat, kompresi efisien
Apache SupersetBI & analytics dashboardOpen-source, SQL-based, customizable charts
PostGISGeospatial queriesGeofence management, haul road mapping, area calculation
Python (pandas + scikit-learn)Predictive analyticsFuel consumption forecasting, maintenance prediction
TechnologyPeranAlasan
ReactWeb dashboard (control room + HQ)Component-based, rich ecosystem untuk maps dan charts
React NativeMobile app (supervisor)Cross-platform, offline-capable dengan local storage
Mapbox GL JSReal-time fleet mapHigh-performance rendering ratusan marker bergerak
WebSocketReal-time dashboard updatesPush-based updates tanpa polling
Recharts + D3.jsData visualizationCycle time charts, fuel trends, production analytics

Core Data Schema: Fleet Telemetry

Prop

Type


📁 4. Project Structure

main.go
telemetry_handler.go
dispatch_optimizer.go
geofence_evaluator.go
cycle_time_calculator.go
main.go
consumption_tracker.go
anomaly_detector.go
refueling_validator.go
main.go
incident_handler.go
safety_rules.go
inspection_scheduler.go
main.go
mqtt_ingestion.go
local_rule_engine.go
sync_manager.go
fuel_reader.go

🔍 5. Feature Deep Dives

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

Problem: Dispatcher di control room mengandalkan radio HT untuk mengarahkan armada. Dengan puluhan unit dump truck dan beberapa excavator beroperasi simultan, dispatcher tidak memiliki gambaran real-time posisi dan status setiap unit. Akibatnya, truk sering mengantre di satu loading point sementara loading point lain idle.

Solution: Fleet Management System real-time dengan dispatch optimization berbasis posisi, antrean, dan cycle time historis.

services/fleet-service/dispatch_optimizer.go
// Multi-Factor 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. Get current truck state from Redis
    truck, err := d.cache.GetFleetState(ctx, truckID)
    if err != nil {
        return nil, fmt.Errorf("truck state not found: %w", err)
    }

    // 2. Get all active excavators and their queue lengths
    excavators, err := d.getActiveExcavators(ctx, truck.SiteID)
    if err != nil {
        return nil, err
    }

    // 3. Score each 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. Publish dispatch decision
    d.kafka.Publish("dispatch.decision", best)
    return best, nil
}

Cycle Time Tracking:

Setiap fase cycle time terdeteksi otomatis via geofence (masuk/keluar loading area, dumping area) dan ignition status (moving vs stationary). Data ini digunakan untuk menghitung:

  • Effective Working Time (EWT): Total waktu produktif vs idle
  • Truck Factor: Rasio jumlah truk optimal per excavator
  • Match Factor: Efisiensi pasangan truk-excavator

Results:

MetricSebelum (Manual)Sesudah (FMS)Improvement
Avg cycle time35 menit26 menit↓ 26%
Queue time at loading10-15 menit3-5 menit↓ 65%
Truck utilization (PA × MA × UA)65%79%↑ 22%
Dispatch decision time2-3 menit (radio)< 5 detik (auto)↓ 97%
Cycle time data accuracy~60% (manual)99%+ (auto)↑ 65%

Feature #2: Fuel Management & Anomaly Detection

Problem: Bahan bakar adalah biaya operasional terbesar kedua setelah sewa alat (bisa mencapai 25-30% total opex). Pencatatan manual di SPBU site rawan ketidakakuratan, dan deteksi fuel theft atau abnormal consumption hampir mustahil dilakukan secara real-time.

Solution: End-to-end fuel tracking dari tangki penyimpanan, proses pengisian, hingga konsumsi per unit — dengan anomaly detection otomatis.

services/fuel-service/anomaly_detector.go
// 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: Consumption rate vs 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 konsumsi %.1f L/jam vs baseline %.1f L/jam (%.0f%% di atas normal)",
                    event.UnitCode, event.ConsumptionRate, baseline.AvgRate, (ratio-1)*100),
                FuelDelta:   event.ConsumptionRate - baseline.AvgRate,
                Expected:    baseline.AvgRate,
            })
        }

    case "level_change":
        // Rule 2: Sudden fuel level drop (potential 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 turun %.0f liter tanpa record refueling — investigasi diperlukan",
                    event.UnitCode, -event.FuelDelta),
                FuelDelta:   event.FuelDelta,
            })
        }

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

    return anomalies
}

Real Impact: Fuel Theft Detection

Dalam bulan pertama deployment, sistem mendeteksi 3 insiden sudden fuel drop di malam hari pada unit yang seharusnya parkir — total ~650 liter solar (~Rp 10 juta). Investigasi mengkonfirmasi fuel theft. Sebelum sistem ini, anomali semacam ini tidak pernah terdeteksi karena pencatatan manual hanya dilakukan per shift (setiap 12 jam).

Results:

MetricSebelum (Manual)Sesudah (Digital)Improvement
Fuel tracking accuracy~85% (manual log)98%+ (sensor)↑ 15%
Fuel anomaly detection time1-7 hari (audit)< 5 menit (real-time)↓ 99%+
Fuel cost savingsBaseline↓ 8-12% per tahunSignificant
Reconciliation gap~5-8%< 1%↓ 87%

Feature #3: HSE Digital Management

Problem: HPU memiliki standar HSE yang sangat tinggi (dibuktikan dengan pencapaian 5.7+ juta jam kerja tanpa kecelakaan di salah satu site). Namun, proses pencatatan HSE masih berbasis form kertas — near miss reporting lambat, safety inspection sulit di-track, dan analytics untuk trend identification terbatas.

Solution: HSE management module terintegrasi dalam platform — dari incident reporting, safety inspection, hingga predictive safety analytics.

HSE Reporting Flow:

Pelapor membuka mobile app

Supervisor atau operator membuka HSE module di aplikasi mobile. Form incident report dirancang offline-first — bisa diisi lengkap tanpa koneksi internet, termasuk foto dan koordinat GPS otomatis.

Isi form terstruktur

Form menggunakan guided flow berdasarkan tipe insiden (near miss, first aid, medical treatment, lost time injury). Setiap tipe memiliki field mandatory yang berbeda, mengurangi incomplete report dari ~25% menjadi < 3%.

Auto-classification & routing

Berdasarkan severity dan tipe insiden, sistem otomatis me-route report ke pihak yang tepat: HSE Officer, Site Manager, atau langsung ke HQ jika severity critical. Tidak perlu lagi forward email manual.

Investigation & root cause analysis

HSE team melakukan investigasi menggunakan template 5-Why Analysis atau Fishbone Diagram yang sudah tersedia di sistem. Temuan dan corrective action tercatat dan trackable.

Corrective action tracking

Setiap corrective action memiliki PIC, deadline, dan status tracking. Sistem mengirim reminder otomatis jika mendekati atau melewati deadline. Management bisa monitor completion rate secara real-time.

Analytics & trend prevention

Data historis dianalisis untuk mengidentifikasi pattern — area mana yang sering terjadi near miss, jam berapa insiden paling sering terjadi, tipe equipment apa yang paling berisiko. Ini mengubah HSE dari reaktif (investigasi setelah kejadian) menjadi proaktif (cegah sebelum terjadi).

Results:

MetricSebelum (Paper-based)Sesudah (Digital)Improvement
Near miss reporting time24-48 jam< 30 menit↓ 96%
Incomplete HSE report~25%< 3%↓ 88%
Corrective action completion rate~65%92%↑ 42%
Time to generate HSE report (monthly)3-5 hariReal-time (auto)↓ 100%
Safety trend identificationManual (retrospective)Proactive (pattern-based)Paradigm shift

Feature #4: Multi-Site Command Center Dashboard

Problem: Manajemen HPU di Jakarta Head Office tidak memiliki real-time visibility ke operasi di seluruh site. Laporan datang mingguan via email dalam format spreadsheet — sudah stale saat dibaca. Perbandingan performa antar-site sulit dilakukan secara apples-to-apples.

Solution: Centralized command center dashboard yang menampilkan KPI operasional seluruh site dalam satu layar, terupdate secara real-time.

Real-time fleet map menampilkan posisi semua unit di semua site pada satu peta. Filter by site, equipment type, atau status (active/idle/maintenance).

WidgetDataUpdate Interval
Live Fleet MapPosisi semua unit (multi-site)5 detik
Active Units CountUnit beroperasi vs total fleet30 detik
Idle AlertUnit idle > 15 menitReal-time
Equipment AvailabilityPA / MA / UA per site5 menit
Dispatch QueueAntrean per loading pointReal-time

Production dashboard menampilkan target vs actual, cycle time analytics, dan trend harian/mingguan/bulanan.

WidgetDataUpdate Interval
Daily Production (Ton)Target vs actual per site15 menit
Cycle Time TrendAvg cycle time per shiftPer cycle
Overburden Removal (BCM)Volume OB per site1 jam
Strip RatioAktual vs plan1 jam
Productivity per UnitTon/jam per equipmentPer trip

Safety dashboard menampilkan HSE statistics, incident map, dan leading indicators.

WidgetDataUpdate Interval
Safe Man HoursJam kerja tanpa kecelakaanReal-time
Incident HeatmapLokasi insiden di peta siteDaily
Near Miss TrendJumlah near miss per mingguDaily
Corrective Action StatusOpen / In-Progress / ClosedReal-time
Safety Inspection ScoreCompliance % per areaWeekly

Fuel dashboard menampilkan konsumsi, stok, dan anomali per site dan per unit.

WidgetDataUpdate Interval
Daily Fuel ConsumptionLiter per site1 jam
Fuel Cost per TonBiaya BBM per ton materialDaily
Tank LevelStok tangki penyimpanan30 menit
Top ConsumersUnit dengan konsumsi tertinggiDaily
Anomaly AlertsDeteksi anomali aktifReal-time

Key Technical Implementation:

services/fleet-service/multi_site_aggregator.go
// Multi-Site KPI Aggregator — runs 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 {
        // Parallel fetch from different 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,
        })
    }

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

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

    return results, nil
}

From Weekly Email to Real-Time Visibility

Sebelumnya, manajemen di Jakarta baru mendapat laporan operasional setiap Senin pagi (untuk minggu sebelumnya) dalam format Excel yang dikirim via email. Sekarang, mereka membuka dashboard dan melihat seluruh operasi multi-site secara real-time. Keputusan yang dulunya membutuhkan waktu berhari-hari (misal: realokasi alat antar-site) sekarang bisa diambil dalam hitungan jam.


Feature #5: Edge-to-Cloud Sync Pipeline

Problem: Konektivitas di setiap site berbeda drastis — Site Kaltim memiliki 4G yang cukup stabil, Site Kalteng via radio link, dan Site Kaltara (KMO Bulungan) hanya mengandalkan VSAT 512 kbps shared. Platform harus tetap berjalan normal di semua kondisi.

Solution: Adaptive sync pipeline dengan prioritization dan compression yang disesuaikan per bandwidth tier.

edge-server/sync_manager.go
// Adaptive Sync Manager — adjusts behavior based on bandwidth
type SyncMode string
const (
    SyncFull      SyncMode = "full"       // > 5 Mbps
    SyncOptimized SyncMode = "optimized"  // 1-5 Mbps
    SyncMinimal   SyncMode = "minimal"    // < 1 Mbps
    SyncBuffer    SyncMode = "buffer"     // No connection
)

func (s *SyncManager) detectMode(ctx context.Context) SyncMode {
    bandwidth := s.bandwidthProbe.Measure(ctx) // 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 again in 10s
            continue
        }
    }
}

// Priority: alerts > fleet state > fuel > production > HSE (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: safety alerts + fleet current position + 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 ModeIntervalAvg Payload/syncMonthly Est.Use Case
Full5 sec12 KB~6 GBSite dengan fiber/4G
Optimized30 sec3 KB (Protobuf)~260 MBSite dengan radio link
Minimal5 min800 bytes~7 MBSite VSAT (Kaltara KMO)
Buffer0 (local only)0Koneksi putus total

VSAT Reality Check

Di Site KMO Bulungan, bandwidth VSAT 512 kbps di-share oleh seluruh camp — office, mess, dan operasional. Platform hanya mendapat alokasi ~100 kbps. Dengan mode Minimal Sync menggunakan Protocol Buffers + Zstd compression, kami berhasil mengirim data fleet tracking untuk 40+ unit hanya dengan ~7 MB per bulan. Tanpa optimasi ini, JSON mentah akan membutuhkan ~50 MB — mustahil di bandwidth tersebut.


🚢 6. Implementation & Rollout

Phase 1: Pilot Site — Kutai Kartanegara (Kaltim)

Site terbesar HPU dengan konektivitas terbaik dipilih sebagai pilot. Deploy edge server, pasang GPS tracker di 60 unit, dan launch Fleet Management + basic dashboard. Validasi data accuracy dan user acceptance selama 2 bulan.

Phase 2: Fuel Management Module

Setelah fleet tracking stabil, integrasikan fuel sensor dan flow meter di SPBU site. Deploy anomaly detection rules. Kalibrasi threshold per tipe equipment karena konsumsi HD785 (40-ton) berbeda dengan PC2000 (excavator).

Phase 3: HSE Digital Module

Launch HSE reporting via mobile app untuk supervisor. Migrasi data historis insiden dari Excel ke platform. Training seluruh tim HSE di site untuk menggunakan digital workflow.

Phase 4: Expand ke Site Kalteng (Barito Utara)

Deploy edge server dan GPS tracker. Adaptasi untuk koneksi radio link (optimized sync mode). Penyesuaian mine plan area dan geofence sesuai topografi site.

Phase 5: Expand ke Site Kaltara (KMO Bulungan)

Site paling menantang — VSAT only. Deploy dengan minimal sync mode. Validasi bahwa operasional tetap berjalan normal saat koneksi terputus. Edge server harus 100% reliable secara mandiri.

Phase 6: Central Command Center (Jakarta HQ)

Launch multi-site dashboard di kantor pusat. Training untuk management team. Setup automated daily/weekly report generation menggantikan spreadsheet manual.


🚀 7. Overall Business Impact

Key Numbers

  • Cycle time: turun 26% (35 min → 26 min) — ratusan trip tambahan per hari
  • Truck utilization: naik 22% (65% → 79%) — ROI langsung ke produktivitas
  • Fuel cost: turun 8-12% per tahun melalui anomaly detection dan optimasi idle time
  • HSE reporting time: turun 96% — dari 24-48 jam menjadi < 30 menit
  • Management visibility: dari laporan mingguan via email → real-time multi-site dashboard
  • Fuel theft detected: 3 insiden di bulan pertama (~650 liter, ~Rp 10 juta)
  • Safe man hours: tracking otomatis dan akurat untuk compliance reporting

ROI Summary per Module

#ModuleBeforeAfterEstimated Annual Value
1Fleet Management35 min cycle, 65% utilization26 min, 79%+15-20% production volume
2Fuel Management5-8% reconciliation gap< 1% gap + theft detectionRp 2-4 miliar/tahun savings
3HSE DigitalPaper-based, reactiveDigital, proactivePriceless (nyawa manusia) + compliance
4Multi-Site DashboardWeekly email reportsReal-time command centerFaster decision making → revenue impact
5Edge-to-Cloud SyncN/A (no remote site support)Works on 100 kbps VSATEnabler untuk operasi di remote site

🏢 8. Post-Launch: Tantangan & Evolusi

8.1 GPS Tracker Reliability di Lingkungan Tambang

Tantangan terbesar post-launch adalah hardware reliability:

ProblemPenyebabFrekuensiSolusi
GPS driftDebu tebal menutupi antena~5% unit/hariAuto-detect drift > 50m dalam 1 detik → filter out
Tracker offlineGetaran melepas konektor~3% unit/hariIndustrial connector + vibration-dampened mounting
Fuel sensor noiseGetaran di jalan tambangKonstanMoving average filter (window 30 detik)
Power spikeEngine start/stopSetiap ignitionWide-voltage regulator (9-36V DC) + surge protector

8.2 User Adoption: Dari Radio ke Digital

8.3 Evolusi Konektivitas

Konektivitas terus membaik seiring investasi infrastruktur:

Arsitektur adaptive sync yang kami bangun sejak awal terbukti future-proof — saat bandwidth meningkat, platform otomatis memanfaatkan kapasitas tambahan tanpa perubahan kode. Site yang dulunya hanya bisa minimal sync sekarang bisa full sync dengan latency minimal.


🎓 9. Lessons Learned

  • Hub-and-spoke architecture membuktikan bahwa edge independence adalah kunci sukses di operasi tambang terpencil. Tidak ada satu pun site yang berhenti beroperasi karena masalah koneksi ke cloud. - Adaptive sync yang menyesuaikan bandwidth otomatis menghemat biaya VSAT signifikan dan memungkinkan operasi di site ultra-remote. - Golang terbukti ideal untuk edge server: single binary deployment, low memory, high concurrency — edge server berjalan di industrial PC dengan RAM hanya 2GB. - Fuel anomaly detection memberikan ROI tercepat — theft detection di bulan pertama langsung menjustifikasi investasi. - Multi-tenant site isolation memastikan data sensitif kontrak klien tetap aman meski dalam satu platform.
  • HSE digitalization mendapat pujian dari management karena membuat achievement safe man hours lebih terukur dan auditable.
  • Gunakan LoRaWAN sebagai alternatif MQTT untuk area dengan jarak jauh antar unit dan edge server — coverage lebih luas dengan power consumption rendah. - Invest lebih awal di automated integration testing untuk edge-to-cloud pipeline — bug yang hanya muncul saat koneksi flaky sulit direproduksi di lab. - Standardisasi GPS tracker hardware lebih agresif sejak awal — terlalu banyak vendor tracker dengan firmware berbeda mempersulit maintenance. - Bangun driver behavior scoring sejak awal (harsh braking, overspeed frequency, idle habit) — ini sangat diminta oleh HSE team setelah launch. - Implementasi digital twin mine site menggunakan data survey dan telemetri untuk visualisasi 3D operasi — ini akan sangat membantu mine planning team. - Offline-capable mobile app sejak awal — awalnya mobile app memerlukan koneksi, yang menyulitkan supervisor di area lapangan yang jauh dari camp.

Technical Debt yang Masih Ada

#DebtImpactPriority
1Predictive maintenance model belum terintegrasiMaintenance masih time-based, belum condition-basedHigh
2Mine planning integration masih one-wayPlan di-push ke platform, tapi aktual belum auto-feedback ke plannerHigh
3Dashboard belum support dark mode untuk control room malamOperator night shift complain silauMedium
4Alert fatigue — terlalu banyak low-priority alertsSupervisor mulai ignore non-critical alertsHigh
5Data retention policy belum otomatis di InfluxDBStorage cost naik linear, perlu tiered storageMedium
6Mobile app belum fully offline-capableHSE report di area jauh dari camp harus buffer manualMedium

🎉 Conclusion

Membangun platform digital untuk operasi tambang HPU adalah tentang memecahkan masalah di dua dunia yang bertabrakan — dunia digital yang menuntut konektivitas dan data real-time, versus dunia tambang yang beroperasi di pedalaman Kalimantan dengan debu, getaran, dan sinyal yang kadang ada, kadang tidak.

Keberhasilan platform ini bukan diukur dari secanggih apa teknologinya, tapi dari seberapa transparan teknologi itu bagi penggunanya. Dispatcher tetap fokus pada dispatching, bukan pada debugging. HSE officer tetap fokus pada keselamatan, bukan pada troubleshooting app.

The HPU Way in Digital

HPU memiliki core values: Integrity, Hard Work, Smart Work, Complete Work, and Sincerity. Platform digital ini adalah manifestasi Smart Work — bukan menggantikan kerja keras tim tambang, tapi memperkuat mereka dengan informasi yang tepat, di waktu yang tepat, agar keputusan yang diambil semakin presisi.

Pada akhirnya, setiap baris kode yang ditulis untuk platform ini memiliki satu tujuan: membantu setiap pekerja tambang HPU pulang dengan selamat dan produktif setiap hari.


Related Articles

Case Study: Digital Mining Platform — PT Harmoni Panca Utama | Faisal Affan