I Built a Cyber Insurance Platform for Australia's Largest Insurer from Indonesia — Here's the Full Architecture

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.

"To be the first-class total mining services solution — through technology adoption and operational excellence." — PT Harmoni Panca Utama Vision Statement
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.
PT Harmoni Panca Utama runs coal mining operations across several strategic sites in Borneo:
Operations spread across Kutai Kartanegara (East Kalimantan), Barito Utara (Central Kalimantan), and Bulungan (North Kalimantan) — each with profoundly different geographical conditions and connectivity nightmares.
Hundreds of heavy equipment units — dump trucks, excavators, bulldozers, graders — operating 24/7 on a shift system, requiring absolute real-time coordination.
Extremely high safety standards, proven by achieving millions of working hours with zero accidents. The digital system must flawlessly support and fortify this safety culture.
HPU runs green mining processes — environmental aspects MUST be integrated into the operational monitoring, including reclamation tracking and emissions.
| 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 |
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.
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)]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 & mergeKey Architecture Decisions:
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.
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 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.
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.
| 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 |
| Technology | Role | Reason |
|---|---|---|
| MQTT (Mosquitto) | Device-to-edge protocol | Extremely lightweight, explicitly designed for starving low-bandwidth environments |
| SQLite (WAL mode) | Edge local database | Wildly reliable, absolute zero-config, survives violent power fluctuations |
| Golang (edge binary) | Edge server runtime | Glorious single binary deployment, absolute zero runtime dependencies |
| Protocol Buffers | Edge-to-cloud serialization | 5-8x smaller than JSON, absolutely saving lives on the VSAT bandwidth |
| Modbus TCP | Fuel sensor protocol | The unquestioned industry standard for heavy industrial sensors |
| Technology | Role | Reason |
|---|---|---|
| InfluxDB | Time-series data (telemetry) | Lightning-fast temporal queries, insanely efficient compression |
| Apache Superset | BI & analytics dashboard | Highly robust open-source, SQL-based, deeply customizable charts |
| PostGIS | Geospatial queries | Flawless geofence management, haul road mapping, complex area calculation |
| Python (pandas + scikit-learn) | Predictive analytics | God-tier fuel consumption forecasting, advanced maintenance prediction |
| Technology | Role | Reason |
|---|---|---|
| React | Web dashboard (control room + HQ) | Component-based, extremely rich ecosystem for interactive maps and heavy charts |
| React Native | Mobile app (supervisors) | Flawless cross-platform, heavily offline-capable utilizing deep local storage |
| Mapbox GL JS | Real-time fleet map | Absolute top-tier performance rendering hundreds of rapidly moving markers |
| WebSocket | Real-time dashboard updates | Silky smooth push-based updates completely eliminating polling |
| Recharts + D3.js | Heavy Data visualization | Massive cycle time charts, deep fuel trends, hard production analytics |
| Property | Type | Description |
|---|---|---|
| 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). |
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// 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:#000Every 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:
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% |
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// 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
}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% |
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:#000Rapid HSE Reporting Flow:
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.
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%.
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.
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.
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.
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 |
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 |
Heavy Production dashboard violently displays aggressive targets vs harsh actuals, deep cycle time analytics, and terrifying trends (daily/weekly/monthly).
| Widget | Brutal Data | Update Interval |
|---|---|---|
| Daily Raw Production (Ton) | Harsh Target vs brutal actual per site | 15 minutes |
| Cycle Time Trend | Deep Avg cycle time per grinding shift | Per cycle |
| Overburden Massive Removal (BCM) | Absolute Volume of OB per site | 1 hour |
| Strip Ratio | Brutal Actual vs soft plan | 1 hour |
| Productivity per Unit | Raw Ton/hr per heavy equipment | Per trip |
Flawless Safety dashboard commands the HSE statistics, the deep incident map, and powerful leading indicators.
| Widget | Brutal Data | Update Interval |
|---|---|---|
| Safe Man Hours | Massive Working hours completely devoid of accidents | Real-time |
| Incident Heatmap | Exact map location of every brutal incident | Daily |
| Near Miss Trend | Total volume of near misses per chaotic week | Daily |
| Corrective Action Status | Aggressive Open / Grinding In-Progress / Dominated Closed | Real-time |
| Safety Inspection Score | Total Compliance % per massive area | Weekly |
Relentless Fuel dashboard exposes all raw consumption, massive stockpiles, and brutal anomalies per site and per single unit.
| Widget | Brutal Data | Update Interval |
|---|---|---|
| Daily Brutal Fuel Consumption | Total liters vanishing per site | 1 hour |
| Fuel Cost per Ton | Absolute Cost of BBM entirely per ton of material | Daily |
| Tank Level | Remaining massive stockpile in storage tanks | 30 minutes |
| Top Massive Consumers | Exact units completely dominating fuel consumption | Daily |
| Anomaly Screaming Alerts | Immediate detection of all active fuel anomalies (theft) | Real-time |
Key Technical Implementation:
// 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
}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.
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// 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 |
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.
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.
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).
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.
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.
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.
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.
| # | 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 |
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 |
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.
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.
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.
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.
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:#000Our 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.
| # | 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 |
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.
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.
A furious similar deep case study — aggressively engineering the massive Minerva Digital Platform purely for heavy fleet management and brutal predictive maintenance deep within Petrosea.
A fiercely similar aggressive offline-first absolute architecture — violently applied directly to deep Sharia microfinance completely lost inside the remote isolated zones of Indonesia.
How to brutally force the exact violent transition escaping the single individual builder and ascending to the absolute god-tier system thinker — pure raw lessons aggressively derived from surviving massively scaled explosive projects.


