← Back to the project archiveBaca dalam Bahasa Indonesia

Edge-to-Cloud case study

RoRo Alert — Edge-to-Cloud Case Study

Resilient vessel-operations monitoring when the cloud internet connection is unstable.

Designed and built independently from the ground up by Riski Afendi, with no other developer. AI was used as a development aid.

  • Flutter
  • Dart
  • BLoC
  • Drift/SQLite
  • PHP
  • JavaScript
  • Laravel
  • MySQL/MariaDB
  • Reverb/WebSocket
  • REST API
Open the interactive modal experienceBack to the project archive

01

Operational problem

Operations need consistent berth status; Sandar/ATA, Kendala/Pause, and Berangkat/ATD records; Turnaround Time calculation; photo/GPS evidence; and central reporting without making cloud internet the only work path.

02

My role

As a Software Engineer Intern, Riski Afendi independently designed and built RoRo Alert from the ground up, covering system analysis, Edge-to-Cloud architecture, and mobile, edge, and cloud flow integration. AI was used as a development aid.

03

Edge-first, multi-path architecture

Three pillars divide authority and work paths so cloud connectivity is not the operation's only dependency.

  1. Primary LAN pathFlutter reaches the local PC over Wi-Fi/LAN, then the local PC synchronizes changes to Cloud.
  2. Cloud fallbackFlutter uses 4G/Cloud, then events and catch-up return to the local PC.
  3. Acknowledgement loopWeb Admin sends a command through Cloud; Edge executes it and returns an acknowledgement to Cloud.
Mobile Field App
Field input, photo/GPS, drafts/cache, and route selection.
Local Edge & HMI
Normal-operation authority, timer/TRT, buffer, and sync queue.
Cloud Command Center
Auth, master data, persistence, dashboard, realtime, and reports.
Web Admin
Commands through Cloud that must be acknowledged by Edge.

Component responsibilities

Mobile Field App
Field input, photo/GPS, drafts/cache, and route selection.
Local Edge & HMI
Normal-operation authority, timer/TRT, buffer, and sync queue.
Cloud Command Center
Auth, master data, persistence, dashboard, realtime, and reports.
Web Admin
Commands through Cloud that must be acknowledged by Edge.

04

Approved public evidence

These three surfaces use original screenshots that were reviewed and approved for public use.

Cloud Command Center

Web Admin

The central dashboard for authentication and master data, persistence, realtime monitoring, fallback, KPI/reporting, and remote commands.

  • Laravel
  • MySQL
  • Reverb/WebSocket
  • REST API
RoRo Alert Web Admin dashboard for berth monitoring.
Original RoRo Alert Web Admin interface.Operational data and infrastructure details are obscured.

Local Edge & HMI

Local Edge HMI

The normal-operation authority for status, timer/TRT, alerts/audio, buffering, and the synchronization queue.

  • PHP
  • JavaScript
  • MySQL/MariaDB
RoRo Alert Local Edge HMI with an operation timer and synchronization status.
Original RoRo Alert Local Edge HMI interface.Operational data and infrastructure details are obscured.

Mobile Field App

Flutter Mobile

The field application for operational input, photo/GPS, drafts/cache, and choosing the LAN or Cloud fallback path.

  • Flutter
  • Dart
  • BLoC
  • Drift/SQLite
Two RoRo Alert Flutter home states for berth selection and an active operation.
Original RoRo Alert Flutter application interface.Operational data and infrastructure details are obscured.

05

Engineering decisions

  1. UUID v4 for idempotent retries

    The same UUID is reused during retries so an operation is not duplicated across paths.

  2. The local PC owns authority

    On the normal path, the local PC is the source of operational status and TRT calculation.

  3. Realtime plus reconciliation

    Realtime events are paired with catch-up to recover changes that were missed.

  4. Acknowledged remote commands

    Cloud does not write operational state directly. Edge executes the command and returns an acknowledgement.

  5. Active-conflict guards

    The system guards active vessel or berth conflicts before a change proceeds.

  6. Metadata before media

    Metadata synchronizes first so core records stay consistent if media transfer is interrupted.

06

Safe public outcomes

Safe public outcomes

  • Supports the primary LAN path and a Cloud fallback.
  • Keeps retries idempotent by reusing the same UUID.
  • Produces Gross TRT, Net TRT, issue duration, KPIs, historical reports, and exports.
  • Supports photo/GPS audits and staff attribution.
  • Recovers missed changes through reconciliation.

Constraints

  • Offline-capable does not mean operating without every network. When both LAN and Cloud are unavailable, new operations cannot be sent.
  • There are no unsupported claims about efficiency, uptime, user count, operational volume, or business impact.
  • No public demo or deployment URL is currently available.

Lessons

  • Distributed workflows need explicit authority, stable identifiers, and reconciliation. Realtime events alone are not enough.
  • Failure boundaries should be explained as honestly as the fallback capability itself.