Helveticore IoT · Edge · GreenTech
Project 1 of the triptych

EdgeStream-GW

An ultra-lightweight industrial software gateway: an intelligent, resilient bridge between physical perception nodes (sensors, meters, PLCs) and the Cloud. It intercepts real-time streams, processes them locally and prevents bottlenecks in harsh industrial environments.

Phase: design / definition — code not started

Project card

  • Developed by — Helveticore OÜ (Estonia)
  • Hardware target — Puzhi ZU2CG / ZU3EG (Zynq UltraScale+), PS/PL partitioning
  • Maturity — CMMI Level 3 “Defined”
  • Source document — SDD IEEE 1016 (document register)

Positioning

Energy efficiency and bandwidth optimization for smart metering networks (Smart Grid). Positioned in the “hero layer” of a three-layer Edge ecosystem.

Impact KPIs

−75 %
of data volume transmitted to the Cloud
< 50 ms
local actuation latency (fast path, no Cloud round-trip)

Modular pipeline

Collection → Normalization → Analytics → Publication, decoupled into layers:

south-driversCollection (REUSE)
→
protocol-adaptersNormalization (BUILD)
→
edge-analyticsPS/PL reduction
→
ingestion-coreCentral broker
→
northbound-publishersMQTT / OPC UA

The eight sub-projects

  • south-drivers/ — Modbus RTU/TCP, DLMS/COSEM collection REUSE
  • protocol-adapters/ — normalization into the Frame object (Fail-Fast) BUILD
  • edge-analytics/ — hardware filtering (PL) + software aggregation (PS)
  • ingestion-core/ — central asynchronous broker routing Frames
  • northbound-publishers/ — MQTT (Sparkplug B) / OPC UA to Cloud and SCADA
  • local-action-engine/ — < 50 ms local loop (PL threshold detection + PS dispatch)
  • store-and-forward/ — offline resilience (SQLite) and replay REUSE
  • deployment/ — Docker “zero-configuration” containerization and OTA

Fast path & safety queue

Alongside the main flow, two lateral loops guarantee reactivity and resilience:

  • Fast path — local-action-engine triggers an ActionCommand in < 50 ms with no Cloud dependency.
  • Northbound safety queue — store-and-forward buffers locally in SQLite when offline, then replays sequentially with throttling.

PS/PL partitioning detail

edge-analytics

  • PL (pl/) — digital noise filtering + FFT on the FPGA fabric, continuously; AXI stream/memory-mapped towards the PS. Planned: Verilog / SystemVerilog RTL and/or Vitis HLS.
  • PS (ps/) — containerized Python microservice applying time-window aggregation (RMS, min/max, deduplication), built with TDD.

local-action-engine

  • PL (pl/) — continuous hardware threshold evaluation in real time; triggers a hardware interrupt on critical breach (sub-millisecond, deterministic).
  • PS (ps/) — receives the interrupt and routes the pre-configured ActionCommand to the southbound actuator driver in < 50 ms, with action logging.

Requirements

Consolidated extracts from the IEEE 1016 SDD (RDM area). IDs stay aligned with the source document.

Core requirements

  • REQ-001a — hardware data reduction (PL): noise filtering and FFT on the FPGA fabric, continuously.
  • REQ-001b — software data reduction (PS): time-window aggregation (RMS, min/max, deduplication).
  • REQ-002 — offline resilience: SQLite buffering + sequential, throttled replay on reconnection.
  • REQ-003 — actuation < 50 ms: local PS/PL loop with no Cloud dependency.

Derived requirements

  • REQ-004 — Fail-Fast: corrupted payload rejected (CorruptedPayloadError), never silently “repaired”.
  • REQ-005 — zero-configuration deployment (Docker stack).
  • REQ-006 — secure OTA updates, without stopping collection.
  • REQ-007 — northbound interoperability: MQTT + Sparkplug B (Protobuf) and OPC UA (client-server + PubSub).
  • REQ-008 — embedded footprint compatible with Zynq UltraScale+ (lightweight RAM / storage).

Out of scope: Cloud / back-office management, and development of proprietary Modbus/DLMS stacks (reused, cf. decision 1).

Architecture decisions (DAR)

Decision 1 — Protocol collection (South Drivers)

Verdict
REUSE — pymodbus, Gurux DLMS
Rationale
Rebuilding compliant Modbus/DLMS stacks brings no strategic value and risks non-compliance.
Requirement
REQ-004, REQ-008

Decision 2 — Data normalization (Protocol Adapters)

Verdict
BUILD FROM SCRATCH
Rationale
Open-source parsers silently fix bad data or let incomplete arrays through; in-house adapters raise CorruptedPayloadError and guarantee CMMI L3 quality.
Requirement
REQ-004

Decision 3 — Store-and-Forward database

Verdict
REUSE SQLite
Rationale
MongoDB is too heavy for the PS RAM limits; binary files risk corruption on power loss; SQLite is serverless, ACID and edge-appropriate.
Requirement
REQ-002, REQ-008

Decision 4 — HW/SW partitioning boundary (Zynq UltraScale+)

Verdict
PS/PL SPLIT
Rationale
Routing high-frequency signals through Linux (PS) introduces non-deterministic OS latency; the PL guarantees sub-millisecond detection, leaving the PS to route only the asynchronous ActionCommand.
Requirement
REQ-003

Requirements traceability matrix (RTM)

RequirementDesign (§ SDD)Component (src/)VerificationKPI
REQ-001a§4 Edge Analytics PLedge-analytics/pl/RTL / HLS simulation (FFT + filter)−75% volume
REQ-001b§4 Edge Analytics PSedge-analytics/ps/aggregation tests (TDD)−75% volume
REQ-002§5.2 Store-and-Forwardstore-and-forward/simulated outage + replayresilience
REQ-003§3.4 & §5.1 Action Enginelocal-action-engine/{pl,ps}/< 50 ms latency bench< 50 ms
REQ-004§4 Protocol Adaptersprotocol-adapters/corrupted payloads (TDD)quality
REQ-005§3.1 Containerizationdeployment/docker-compose deploymentzero-config
REQ-006§3.1 Containerizationdeployment/OTA update testcontinuity
REQ-007§3.2 North boundarynorthbound-publishers/Mosquitto + OPC UA clientIT/OT interop
REQ-008§6 Decision 3store-and-forward/RAM / storage measurementfootprint

Each row must be verified and checked off in the performance report before any release.

Milestones & risks

Milestones

  • 1 · Virtual test bench: emulation of 50 energy meters (testbench/).
  • 2 · Adapters + Edge Analytics PS: proof of the volume-reduction KPI.
  • 3 · Local Action Engine: proof of < 50 ms latency.
  • 4 · PL (FPGA) partitioning + PS/PL integration on the Puzhi board.

Key risks (RSK)

  • PS/PL latency determinism — mitigated by hardware partitioning (decision 4).
  • Data corruption during power outages — mitigated by SQLite ACID (decision 3).
  • Modbus/DLMS protocol compliance — mitigated by reusing proven stacks (decision 1).

Virtual test bench (VV)

Emulation

  • 50 simultaneous Modbus meters simulated locally (realistic cadence, telemetry + noise).
  • Mocked PS/PL interfaces: AXI contract + mocked interrupts (TDD of the software layers).
  • Local MQTT broker (Eclipse Mosquitto) and OPC UA client for the north boundary.

Planned tooling

pytest, hypothesis, docker-compose, Modbus/DLMS simulators, Mosquitto, OPC UA client.

Metrics: latency (< 50 ms), reduction rate (≥ 75%), container RAM/CPU/storage — feeding performance/.

Current state: all design artifacts are drafted (requirements, SDD, 4 decisions, RTM, milestones), including the PS/PL split of edge-analytics and local-action-engine. No source code is versioned yet — the next step in the plan is the virtual test bench (milestone 1).