Blue Aqua Platform Architecture

Sensor Integration & Data Platform
Vision & Problem
Overview
Data Platform
Edge Hardware
OxyGuard Questions

Technical Vision

AquaPilot is a single platform that delivers continuous pond intelligence to every farm, regardless of connectivity, infrastructure, or budget. One app, one data platform, multiple deployment models. Sensors feed data to AI that runs where it can: on the farmer's phone, on an edge device at the pond, or in the cloud. The architecture adapts to what's available on-site.

Technical Challenge

Connectivity varies wildly
Farms range from fiber-connected hatcheries to remote jungle ponds with no cellular coverage. The architecture can't assume internet.
Sensors don't speak phone
Industrial sensors use Modbus TCP over Ethernet. Phones use WiFi and BLE. Bridging this gap may require intermediate hardware.
Real-time vs. ad-hoc data
Some farms need 24/7 alerting, others only need data when a technician visits. Whether sensors buffer data and how it syncs to the phone determines what's possible.
AI needs compute
Image recognition and LLM inference require real compute. Can a phone handle it, or do we need dedicated edge devices at every pond?

Business Challenges

Cost-sensitive customers
Most aquaculture operations run on thin margins. Per-pond hardware cost is a hard barrier to adoption. The solution must scale from $0 entry to premium tiers.
Farmers don't configure probes
On-site technical expertise is minimal. Sensor setup, network configuration, and device provisioning must be zero-touch or handled by Blue Aqua technicians.
Every farm is different
Indoor hatcheries, open grow-out ponds, offshore cages, remote jungle sites. No single deployment model fits all. The product must offer tiers that match the farm's reality.

Deployment Decision Tree

Three questions determine the hardware architecture at each pond. The answers define which deployment scenario applies.

Pond has sensors? NO YES Phone connects to sensor? NO YES Sensor buffers data? NO YES Edge Device Needed Bridge or AI box Phone Only With or without sensors Phone runs Edge AI? YES Phone: Visualization + AI Edge device = data source only. Scenario C. NO Edge Device runs AI Phone = viz + sync. On-site AI ($$$). Scenario D. Phone runs Edge AI? YES Phone: Visualization + AI On-site diagnostics via phone. Scenario B. NO Phone: Visualization + Sync No on-site diagnostics. Cloud only. Scenario A.
EXTERNAL DATA PHONE ONLY (ALL SCENARIOS) Forms Camera GPS APPLICATION AquaPilot AquaPilot BLUE AQUA DATA PLATFORM API Layer REST Webhook AI / Business Layer AI Models Rules Workflows Data Layer DB Stream Blob Vector Integration Layer REST HTTPS Flatfile Webhook Compute K8s MOBILE DEVICE AquaPilot HTTPS POND LEVEL B: PHONE + WiFi Pacific WiFi direct WiFi C: LOW-SPEC EDGE Low-Spec Edge D: HIGH-SPEC EDGE AI High-Spec Edge AI BLE BLE Network Switch Modbus TCP Modbus TCP Pacific Master Box up to 20 probes DO Temp Sal pH Pacific DO + Temp DO Temp Pacific Salinity Sal Pacific pH + ORP pH ORP

Scenario Comparison

A: Cloud Only B: Phone AI C: Low-Spec Edge D: High-Spec Edge AI
Data source Camera, forms, GPS Same as A + Sensors via WiFi Same as A + Sensors via Edge HW Same as A + Sensors via Edge HW
Edge hardware cost None None Medium High
AI location Cloud only On phone On phone On edge device
On-site diagnostics No Yes (on visit) Yes (on visit) Yes (on visit & 24/7 with SIM)
Real-time alerts No No No No / Yes (with SIM)
Internet required For AI & sync For sync only For sync only For sync / Yes (with SIM)
Best for Entry-level, validation WiFi-capable sensors Cost-sensitive farms High-value stock, hatcheries

Data Platform Architecture

Five layers. Every data point accessible via API. The phone is both consumer (AquaPilot app) and producer (camera-based water testing). Extensible to any future data source.

RESTMQTTFileHook

Integration Layer

Data-source-facing. The technician's phone is the primary uplink. Edge devices have no internet connection. They buffer readings locally and transfer via BLE when the technician walks past. The phone also captures its own data (camera-based water testing). Everything uploads to the platform when the phone reaches WiFi.

Data Layer

All data resides here. Sensor readings, model results, business logic outcomes, manual input. Validated, transformed, and stored. Time-series database, streaming ingestion, blob storage, vector DB.

AI / Business Layer

Blue Aqua's proprietary aquaculture domain models. AI model deployment and management. Vector databases for knowledge retrieval. Business rules, alert logic, escalation workflows. This is where Blue Aqua's IP lives.

REST

API Layer

Client-facing. Every data point and feature on the platform is accessible via REST APIs. Sensor readings, AI predictions, farm status, alerts, device health. AquaPilot and any future consumer (partner integrations, reporting tools) consumes data through this layer. No direct database access.

Compute Layer

Container orchestration. Auto-scaling. Manages deployments, load balancing, and infrastructure.

Why this matters: The phone is already a data source (camera-based water testing). When Blue Aqua adds more sources (underwater cameras, satellite imagery, weather APIs, feed tracking), they flow through the same pipeline. No new architecture needed.

Ingestion Protocols

ProtocolSourcePattern
HTTPS POSTAquaPilot phone app (primary)Phone uploads buffered edge data + camera data on WiFi. Compressed JSON batch.
BLEEdge gateway → technician phone~10KB/day per device. Full transfer in <1 sec. Clock sync on handshake.
Phone cameraTest strips, spectrophotometer clip, visual inspectionImage capture, on-device processing, structured reading submitted with edge data.
WebhookExternal services, partner integrationsEvent-driven, real-time
Flat fileLab results, CSV exports, manual dataBatch upload, validated on arrival

Edge Gateway

Every pond gets an edge device. No SIM, no internet at pond level. The device buffers locally and syncs to the technician's phone via BLE on daily rounds. The phone uploads to the platform when it reaches WiFi.

Blue Aqua Edge Runtime Connect Sensors Modbus TCP, RS-485, MQTT Business Rules Thresholds, alerts, triggers Compress Data Batch, gzip, optimize Buffer & Store RTC-stamped, days of capacity BLE Sync Technician phone uploads on WiFi. No SIM needed. Local Clock Timestamps every reading Local AI Models Inference without cloud Tier 3

Hardware & Software Requirements

Non-negotiable requirements for any edge device we deploy at pond level.

CategoryRequirement
DeploymentProprietary software pre-loaded. Standard provisioning process (warehouse flash).
OperationHeadless (no screen, no keyboard). IP65 enclosure for outdoor deployment.
ConnectivityBLE to technician phone (primary uplink). Phone uploads on WiFi. Optional SIM/2G fallback. No per-pond SIM required.
ClockReal-time clock (RTC) on device. Every reading timestamped locally. Clock sync on BLE handshake.
SecurityFull disk encryption. TLS for all communication. Per-device certificates. Remote wipe.
UpdatesOTA software updates. Signed updates only. Auto-rollback on failure.
ManagementRemotely accessible. Central fleet control. SSH via VPN only.

Questions for OxyGuard

Two architecture scenarios under evaluation. The answers below determine which path we take.

Scenario A: Phone as Edge Device (preferred)

The AquaPilot app on the technician's phone connects directly to Pacific units via local WiFi (no internet). Phone pulls sensor data, runs on-device AI, and syncs to the platform later.

#QuestionWhy we need it
1WiFi connectivity on Pacific unitsDoes the Pacific expose any data interface (Modbus TCP, HTTP, or other) over WiFi, or only over the wired Ethernet port? The fish transport example (page 8, Example 2) shows an Access Point connected to the Pacific. What protocols are accessible over that wireless link?
2Programmatic data access via WiFiThe Pacific Web Interface allows viewing readings in a browser over WiFi. Can a third-party app also pull readings programmatically (Modbus TCP, REST API, raw TCP) over the same WiFi connection? Or is it browser-only?
3Modbus TCP over WiFiIf we connect a phone to the same local WiFi network as the Pacific unit, can the phone send Modbus TCP requests to the Pacific's IP address and receive sensor data? Any firewall or protocol restrictions?
4Auto-discovery / mDNSIs there a way to discover Pacific units on the local network automatically (mDNS, SSDP, broadcast)? Or do we need to know the IP address in advance?
5Connection limitsHow many simultaneous TCP/Modbus connections does a Pacific unit support? Can the Pacific Web Interface and a Modbus TCP client run at the same time?

Scenario B: Local Edge Device as Bridge

If the Pacific only exposes Modbus TCP on the wired Ethernet port, we need a small device on the wired network that bridges data to the phone via WiFi or BLE.

#QuestionWhy we need it
1Modbus TCP register map for Pacific Main ModuleRequired to read sensor values (DO, temp, salinity, pH, ORP) from our bridge device. Without this we cannot integrate.
2Register data types and scaling factorsInteger vs float, scaling (e.g. value / 100 = actual reading), byte order (big/little endian).
3Polling frequency limitsHow often can we poll registers without impacting Pacific performance? Target: every 10-30 seconds.
4Master Box aggregation via ModbusWhen using a Pacific Master Box (up to 20 probes), are all probe values accessible via the same Modbus TCP connection?
5Alarm/relay status registersCan we read alarm thresholds and relay states via Modbus?
6Simultaneous connectionsCan our bridge device and a local HMI both connect via Modbus TCP at the same time?