← Kembali ke arsip proyekRead in English

Studi kasus Edge-to-Cloud

RoRo Alert — Studi Kasus Edge-to-Cloud

Monitoring operasional kapal yang tetap tangguh ketika koneksi internet ke cloud tidak stabil.

Dirancang dan dibangun dari awal secara mandiri oleh Riski Afendi, tanpa pengembang lain. AI digunakan sebagai alat bantu pengembangan.

  • Flutter
  • Dart
  • BLoC
  • Drift/SQLite
  • PHP
  • JavaScript
  • Laravel
  • MySQL/MariaDB
  • Reverb/WebSocket
  • REST API

01

Masalah operasional

Operasional membutuhkan status dermaga yang konsisten, pencatatan Sandar/ATA, Kendala/Pause, Berangkat/ATD, perhitungan Turnaround Time, bukti foto/GPS, serta pelaporan pusat tanpa menjadikan internet cloud sebagai satu-satunya jalur kerja.

02

Peran saya

Sebagai Software Engineer Intern, Riski Afendi merancang dan membangun RoRo Alert dari awal secara mandiri, mencakup analisis sistem, arsitektur Edge-to-Cloud, serta integrasi alur mobile, edge, dan cloud. AI digunakan sebagai alat bantu pengembangan.

03

Arsitektur edge-first dan multi-path

Tiga pilar membagi authority dan jalur kerja agar koneksi cloud bukan satu-satunya ketergantungan operasional.

  1. Jalur LAN utamaFlutter ke Wi-Fi/LAN, lalu PC lokal menyinkronkan perubahan ke Cloud.
  2. Fallback CloudFlutter memakai 4G/Cloud, lalu event dan catch-up kembali ke PC lokal.
  3. Loop acknowledgementWeb Admin mengirim perintah melalui Cloud; Edge mengeksekusi dan mengirim acknowledgement ke Cloud.
Mobile Field App
Input lapangan, foto/GPS, draft/cache, dan pemilihan rute.
Local Edge & HMI
Authority operasi normal, timer/TRT, buffer, dan sync queue.
Cloud Command Center
Auth, master data, persistensi, dashboard, realtime, dan laporan.
Web Admin
Perintah melalui Cloud yang wajib dikonfirmasi oleh Edge.

Tanggung jawab setiap komponen

Mobile Field App
Input lapangan, foto/GPS, draft/cache, dan pemilihan rute.
Local Edge & HMI
Authority operasi normal, timer/TRT, buffer, dan sync queue.
Cloud Command Center
Auth, master data, persistensi, dashboard, realtime, dan laporan.
Web Admin
Perintah melalui Cloud yang wajib dikonfirmasi oleh Edge.

04

Evidence publik yang disetujui

Tiga surface berikut memakai tangkapan layar asli yang telah direview dan berstatus approved-public.

Cloud Command Center

Web Admin

Dashboard pusat untuk autentikasi dan master data, persistensi, monitoring realtime, fallback, KPI/report, serta remote command.

  • Laravel
  • MySQL
  • Reverb/WebSocket
  • REST API
Dashboard Web Admin RoRo Alert untuk pemantauan dermaga.
Tampilan asli Web Admin RoRo Alert.Data operasional dan detail infrastruktur disamarkan.

Local Edge & HMI

Local Edge HMI

Otoritas operasi normal untuk status, timer/TRT, peringatan/audio, buffer, dan antrean sinkronisasi.

  • PHP
  • JavaScript
  • MySQL/MariaDB
Local Edge HMI RoRo Alert dengan timer operasi dan status sinkronisasi.
Tampilan asli Local Edge HMI RoRo Alert.Data operasional dan detail infrastruktur disamarkan.

Mobile Field App

Flutter Mobile

Aplikasi lapangan untuk input operasional, foto/GPS, draft/cache, serta pemilihan jalur LAN atau fallback Cloud.

  • Flutter
  • Dart
  • BLoC
  • Drift/SQLite
Dua keadaan beranda Flutter RoRo Alert untuk pemilihan dermaga dan operasi aktif.
Tampilan asli aplikasi Flutter RoRo Alert.Data operasional dan detail infrastruktur disamarkan.

05

Keputusan engineering

  1. UUID v4 untuk retry idempoten

    UUID yang sama digunakan ulang pada retry agar operasi lintas jalur tidak terduplikasi.

  2. PC lokal sebagai authority

    Pada jalur normal, PC lokal menjadi sumber status operasi dan perhitungan TRT.

  3. Realtime dengan reconciliation

    Event realtime dilengkapi catch-up untuk memulihkan perubahan yang terlewat.

  4. Remote command dengan acknowledgement

    Cloud tidak langsung menulis state operasional. Edge mengeksekusi perintah dan mengirim acknowledgement.

  5. Guard konflik aktif

    Sistem menjaga konflik kapal atau dermaga aktif sebelum perubahan dilanjutkan.

  6. Metadata sebelum media

    Metadata disinkronkan lebih dulu agar data inti tetap konsisten ketika transfer media terganggu.

06

Outcome yang aman dipublikasikan

Outcome yang aman dipublikasikan

  • Mendukung jalur LAN utama dan fallback Cloud.
  • Menjaga retry idempoten dengan UUID yang sama.
  • Menghasilkan Gross TRT, Net TRT, durasi kendala, KPI, laporan historis, dan export.
  • Mendukung audit foto/GPS dan atribusi petugas.
  • Memulihkan perubahan terlewat melalui reconciliation.

Batasan

  • Offline-capable tidak berarti berjalan tanpa semua jaringan. Ketika LAN dan Cloud sama-sama tidak tersedia, operasi baru tidak dapat dikirim.
  • Tidak ada klaim efisiensi, uptime, jumlah pengguna, volume operasional, atau dampak bisnis tanpa bukti.
  • URL demo atau deployment publik belum tersedia.

Pembelajaran

  • Workflow terdistribusi memerlukan authority yang eksplisit, identifier stabil, dan reconciliation. Realtime saja tidak cukup.
  • Batas kegagalan harus dijelaskan sejujur kemampuan fallback yang dibangun.