Overview Documentation Partners

Home / Documentation / System Architecture

System Architecture

Full-stack block diagram — sensor layer, ESP32 edge processing, wireless uplink, cloud ingestion, supervisor dashboard, and the multi-modal alert pipeline.

DocumentDOC-03
Layers4 (Sensor → Cloud)
ProtocolsI2C · WiFi · MQTT · BLE
StatusAvailable

System Overview

The Apex Security system is a four-layer IoT stack: a physical sensing layer embedded in the jacket, an edge processing layer on the ESP32, a wireless uplink layer (WiFi/BLE/LoRa), and a cloud layer with a supervisor dashboard. Each layer has well-defined interfaces and fail-safes to ensure local safety functions remain fully operational even without network connectivity.

Design Principle: Local-First Safety

All critical alerts — fall detection, E-field proximity, vital sign anomalies — fire locally (buzzer, haptic, LED) within 22 ms of detection. Network transmission is a secondary reporting channel and its failure never suppresses a physical alert.

Four Layers

Layer 1 — Sensing: MPU6050, MAX30102, MLX90614, IR, LDR, E-field probe.
Layer 2 — Edge (ESP32): Sensor fusion, FSM, alert output, BLE GATT server.
Layer 3 — Wireless: WiFi + MQTT to broker, BLE to wrist cuff, optional LoRaWAN to gateway.
Layer 4 — Cloud: MQTT broker, time-series DB, supervisor dashboard, SMS/push alerts.

Layer 1 — Sensor Layer

Five sensing subsystems feed into the ESP32 via I2C and GPIO. The sensor layer is physically distributed across the jacket: IMU at the back collar, PPG sensor at the wrist cuff, IR thermometer at the chest collar, IR proximity at the sleeve, and the E-field antenna at the shoulder.

SensorInterfaceLocationSample RateData
MPU6050I2C 0x68Back collar100 HzAccel XYZ, Gyro XYZ
MAX30102I2C 0x57Wrist cuff25 HzIR / Red PPG waveforms
MLX90614I2C 0x5AChest collar10 HzSkin temp, ambient temp
IR ProximityGPIO 34Sleeve edge20 HzDigital presence signal
LDRADC GPIO35Shoulder20 Hz12-bit light level
E-Field ProbeADC via CA3140Shoulder50 HzAmplified displacement

I2C Bus Topology

All three I2C sensors share SDA (GPIO 21) and SCL (GPIO 22) with 4.7 kΩ pull-ups. Unique addresses eliminate bus contention. Flexible ribbon cables route through jacket seams with reinforced stress-relief at shoulder and cuff junctions.

Layer 2 — Edge Processing

The ESP32-WROOM-32 performs all safety-critical decisions locally, with a sensor fusion pipeline that runs on Core 0 at deterministic intervals. The edge layer is intentionally designed to be self-sufficient — no cloud dependency for any alert function.

Sensor Fusion Pipeline

Raw sensor samples are placed into typed FreeRTOS queues. The alertTask reads from these queues and runs: (1) SVM calculation for fall detection, (2) threshold comparison for vital signs, (3) ADC voltage comparison for E-field level. All three evaluations happen within a single 10 ms tick loop.

Alert Output Hierarchy

Three hardware outputs are driven directly from GPIO: buzzer (GPIO 26, PWM tone), haptic motor (GPIO 27, PWM strength), and status LED RGB (GPIO 12/13/14). A three-level severity system (INFO / WARNING / CRITICAL) maps to distinct patterns for each output channel.

Decision Latency

From sensor read to GPIO alert output: 22 ms typical at 10% system load, up to 57 ms at 100% load. WiFi transmission adds an additional 180 ms average over a stable LAN connection. Local alerts always fire before wireless transmission begins.

Layer 3 — Wireless Uplink

Three radio technologies are used in complementary roles. WiFi handles high-bandwidth cloud sync, BLE handles low-latency wrist-cuff pairing, and LoRaWAN (optional module) handles long-range transmission in sites without WiFi infrastructure.

WiFi (802.11n / 2.4 GHz)

Connects to site WiFi AP. Used for MQTT broker communication, OTA firmware updates, and periodic health data sync. Transmission is event-driven to minimize radio-on time. Not suitable as the sole uplink in substations due to metallic shielding — LoRa is preferred in such environments.

BLE 5.0 (GATT Profile)

Pairs with wrist cuff (a secondary ESP32 BLE peripheral) and optionally with a supervisor's smartphone. Notifies heart rate, SpO₂, and alert events at 500 ms intervals when a client is subscribed. Range: ~10 m typical in industrial environment.

LoRaWAN SX1278 (Optional)

Slot for optional LoRa module on SPI bus. Targets large sites (substations, solar farms, construction zones) where WiFi is unavailable. Range: 5–15 km open field. Transmit power: 20 dBm. Data rate: 250–5500 bps (SF7–SF12). Low duty cycle (1%) ensures compliance with regional radio regulations.

Layer 4 — Cloud & Dashboard

The cloud layer provides persistent storage, fleet monitoring, and supervisor alerting. The reference architecture uses Mosquitto MQTT broker → InfluxDB time-series database → Grafana dashboard, all deployable on a single VPS or on-premise server.

Data Pipeline

MQTT broker receives all jacket publishes. A Node.js bridge subscribes to all apex/# topics and writes to InfluxDB with device ID, timestamp, and measurement tags. Grafana queries InfluxDB for real-time and historical dashboards.

Supervisor Alerts

A Node-RED or custom webhook handler monitors apex/+/alert topics and dispatches SMS (Twilio), push notification (FCM), or email alerts to supervisors within 2 s of the event timestamp. Alert payloads include device ID, event type, GPS coordinates if available, and sensor values at time of event.

Retention & Privacy

Health data is stored with configurable retention (default: 90 days). Device IDs are pseudonymous — mapping to workers is controlled by the site operator. All MQTT connections use TLS 1.2. InfluxDB access is restricted to the local network or VPN.

Alert Pipeline

Alert events flow from sensor detection through local output and then to wireless notification in a defined sequence. The pipeline is designed so that each stage can operate independently — local alerts never wait for network confirmation.

Stage 1 — Detection (0 ms)

alertTask detects threshold breach or FSM transition. Sets corresponding bit in xAlertEventGroup.

Stage 2 — Local Output (< 22 ms)

GPIO outputs activate: buzzer tone pattern, haptic motor vibration, LED color/flash rate. Worker receives immediate tactile and auditory feedback.

Stage 3 — BLE Notify (< 50 ms)

commTask reads event bit and pushes BLE notification to connected wrist cuff and smartphone. Wrist cuff mirrors local alert pattern.

Stage 4 — MQTT Publish (< 250 ms)

MQTT alert message published to broker. If WiFi is unavailable, message is queued in RAM (max 10 events) and flushed on reconnection.

Stage 5 — Supervisor Notification (< 2 s)

Cloud webhook triggers SMS/push/email to supervisor. Grafana alert panel marks the event on the timeline. Supervisor can acknowledge via dashboard to silence repeat notifications.

LoRaWAN Extension

For deployment sites without reliable WiFi — electrical substations, remote transmission lines, underground cable tunnels, large construction sites — LoRaWAN replaces WiFi as the primary uplink. WiFi is then used only for local diagnostics and OTA updates when the jacket is in the maintenance zone.

Gateway Architecture

A RAK7268 or similar LoRaWAN gateway is installed at the site control room. All jackets register as end-devices. The gateway forwards packets to a TTN (The Things Network) or ChirpStack network server, which routes to the same MQTT broker used for WiFi devices — the cloud layer is protocol-agnostic.

Packet Structure

LoRa payloads are binary-encoded to fit within the duty-cycle budget. A 12-byte health packet carries: device ID (2 B), heart rate (1 B), SpO₂ (1 B), skin temp × 10 (2 B), alert flags bitmask (1 B), battery % (1 B), sequence number (2 B), CRC (2 B).

Why LoRa for Substations

High-voltage yards generate intense electromagnetic interference that degrades 2.4 GHz WiFi reliability. LoRa's 433/868/915 MHz bands are less affected by metallic enclosures and EMI. Additionally, LoRa's star topology with a single gateway simplifies infrastructure deployment in sites where running Ethernet is impractical.