View Source

1. The Problem

TBD

2. The Solution

2.1 Overview

Edge: FrameworX EdgeConnect.
Central: FrameworX Enterprise with UI.
DataHub: TagProvider for distributed engineering and close to zero downtime Edge additions.
Protocols: DNP3 (master/slave), Modbus.
Scale: 5 Edges × 25k tags = 125k tags publishing; overall 250k points (125k Modbus reads + 125k DNP3 writes).
Modules: Alarms and Historian (Postgres + TimescaleDB).
Sizing: 48 vCPU and 128 GB RAM (including redundancy).
Redundancy: One pair of full-project redundancy; store-and-forward enabled.

2.2 Logical Diagram (high level)

[ DataHub (TapProvider)/UI ]
?
?
?
??????????????????
? ?
? reads historical + alarms ? reads live device values
? ?
[ Postgres + TimescaleDB ] ? ???? [ Edge Sites ×5 ]
Historian + Alarms FrameworX EdgeConnect
• Collects Modbus (read)
• Publishes to DNP3 (write)
• Exposes device values (read)
• Sends timeseries/alarms → Historian

Expanded flow:

5 EdgeConnect collecting data with Modbus and creating datasets + alarms
→ Postgres + TimescaleDB (Historian + Alarms)
→ FrameworX Enterprise showing data in the UI (UI Server).

2.3 Architecture Summary

Edges: 5 units; 25k tags each.
Central Services: Historian + Alarms; UI served by FrameworX Enterprise.
Point Directionality: 125k reads (Modbus) + 125k writes (DNP3) = 250k.
Operations: Distributed engineering via TagProvider; hot-add new Edge without downtime.

2.4 Redundancy & Store-and-Forward

Redundancy: 1 pair of full project redundancy.
Continuity: Store-and-forward for resilient ingestion.

3. Key Enablers

DataHub “TapProvider” enabling distributed engineering.
Redundancy (full-project pair) with store-and-forward.
Electrical protocols such as DNP3 (plus Modbus).

4. The Results

TBD