Skip to main content

General

Platform Architecture

Conceptual overview of the Proxus architecture: Central Management, Edge Execution, and the Actor Model.

Proxus uses a two-tier architecture designed for resilience and massive scalability. Unlike traditional SCADA systems that poll devices from a central server, Proxus pushes intelligence to the edge while keeping management centralized.


High-Level Topology

The system consists of two main software components connected by a resilient message bus.

System Data Flow
router

Edge Runtime

Field Deployment

Telemetry
hub

NATS Jetstream

Transport Layer

Ingestion
dns

Central Core

Cloud / On-Prem

Central Management Core

Hosted in the cloud or on-premise data center.

  • Role: Configuration management, licensing, long-term data storage, and user interface.
  • Key Services:
    • System Orchestrator: Manages global state and health monitoring.
    • Real-time Data Cache: Provides sub-millisecond data access for the UI.
    • Configuration Transport: Securely pushes changes to edge nodes.

Edge Runtime

Deployed on field devices (Industrial PCs, Raspberry Pis, Servers).

  • Role: Protocol translation, data buffering, rule execution, and C# scripting.
  • Stateless Design: Does not store config on disk. Fetches it from Central on boot.
  • Key Services:
    • Protocol Manager: Handles drivers for Modbus, OPC UA, and Siemens.
    • Logic Engine: Executes local rules and scripts with low latency.
    • Data Router: Buffers and transmits normalized data to the central core.

The Actor Model

Proxus utilizes the Actor Model to handle concurrency. This allows the system to process millions of data points in parallel without the stability issues common in traditional multi-threaded applications.

info
Why Actors?

In traditional systems, handling thousands of concurrent devices leads to complex locking and deadlocks. The Actor Model allows Proxus to treat every device, rule, and connection as an isolated unit, ensuring that a failure in one driver never crashes the whole system.

Conceptual Hierarchy

  • folder System Orchestrator Central: Manages the fleet
  • folder Edge Runtime
    • draft Bootstrapper Connects to Central
    • folder Protocol Drivers Modbus, OPC UA, etc.
    • draft Logic Engine Real-time processing

Detailed Data Pipeline

The journey of a data point from a sensor to the dashboard involves several optimized steps.

Telemetry Pipeline
sensors

PLC / Sensor

Source

settings_ethernet

Protocol Driver

Acquisition

memory

Logic Engine

Normalization

hub

Message Bus

Transmission

Central Processing
hub

Message Bus

Reception

database

Time-Series DB

Persistence

dashboard

User Interface

Visualization

  1. Acquisition: The Protocol Manager reads raw data from PLCs/Sensors.
  2. Normalization: Data is converted to a standardized internal format.
  3. Processing: The Logic Engine checks for alarms or runs scripts.
  4. Transmission: Data is published to the message bus (guaranteed delivery).
  5. Ingestion: The Central Core receives and validates the message.
  6. Persistence: Data is written to the Time-Series Database.
  7. Visualization: Live dashboards update immediately via WebSocket.