Skip to content

Three-Tier Overview

Consystence operates across three tiers. Each tier runs independently and continues to function during network outages between tiers.

graph LR
    subgraph Cloud["Cloud Tier"]
        direction TB
        C1[Fleet Analytics]
        C2[AI Model Training]
        C3[Type Marketplace]
        C4[Identity & Licensing]
    end

    subgraph Site["Site Server"]
        direction TB
        S1[Process Control UI]
        S2[Scene Graph Rendering]
        S3[Alarm Processing]
        S4[Local LLM Inference]
    end

    subgraph Edge["Edge Devices"]
        direction TB
        E1[PLC Communication]
        E2[Edge ML Inference]
        E3[Store-and-Forward]
    end

    Cloud <-->|"gRPC + SignalR"| Site
    Site <-->|"gRPC-over-HTTP/3"| Edge

Cloud tier — Azure

The cloud tier handles enterprise-wide concerns that span multiple sites.

Responsibility Detail
Fleet analytics Cross-site reporting, equipment comparison, KPI dashboards
AI model training Frontier LLM APIs for GUI generation, fleet ML model retraining
Type marketplace Publishing, versioning, and distribution of device types
Identity & licensing Account management, JWT issuance, licence validation

The cloud runs a multi-tenant Orleans cluster serving all organisations. It does not process real-time PLC data — that stays on-site.

Domains:

  • *.consystence.app — production marketplace and fleet dashboards
  • *.consystence.dev — development and staging environments

Site server — on-premises

The site server is the operational heart of each site. It runs on-premises, connected to the plant network, and serves operator interfaces directly.

Responsibility Detail
Process control UI GUI DSL page rendering, scene graph SVG rendering
Alarm processing Real-time alarm evaluation, acknowledgement, escalation
Historian Tag value storage in PostgreSQL
Local LLM inference Qwen3-32B on RTX 5090, with cloud API fallback

The site server runs a single-tenant Orleans cluster — one cluster per site, fully isolated.

Air-gap ready

Site servers are designed for mining environments where data sovereignty is paramount. A site can operate entirely disconnected from the cloud. Local LLM inference means AI features work without an internet connection.

Local AI

The site server runs a local LLM (Qwen3-32B on an RTX 5090 GPU) for AI-assisted features: generating operator screen layouts, explaining alarm patterns, and summarising shift logs. If no local GPU is available, the server falls back to cloud LLM APIs.

Edge devices — Nvidia Orin

Edge devices sit at the physical boundary between the digital platform and industrial equipment.

Responsibility Detail
PLC communication EtherNet/IP via libplctag, Modbus, OPC-UA
Edge ML inference TensorRT autoencoders for anomaly detection
Store-and-forward SQLite buffer for intermittent connectivity

Edge devices communicate with the site server over gRPC-over-HTTP/3. When the connection drops, the edge device buffers tag data and events in a local SQLite database and forwards them when connectivity is restored.

Connectivity model

Edge devices handle three connectivity states:

State Behaviour
Connected Stream tag data to site server in real-time via gRPC
Intermittent Buffer locally, flush on reconnection, prioritise alarms
Air-gapped Full local buffering, manual data export via USB

Design philosophy: AI-assisted, not AI-controlled

A key architectural decision: AI explains what the PLC is doing — it never changes control.

AI in Consystence is advisory and diagnostic only:

  • AI generates operator screen layouts from device type metadata.
  • AI explains alarm patterns and suggests root causes.
  • Edge ML models detect anomalies and flag them for operator attention.
  • AI summarises shift logs and equipment history.

AI never writes to PLC registers, never changes setpoints, and never overrides interlocks. The PLC program — authored and tested by control engineers — remains the sole authority over the physical process.

Warning

This is a deliberate safety boundary. Industrial control systems must be deterministic and auditable. AI models can hallucinate; PLCs cannot.

Fleet learning

Fleet learning allows edge ML models to improve across the entire fleet of deployed devices.

sequenceDiagram
    participant A as Site A — Edge
    participant S as Site A — Server
    participant C as Cloud
    participant B as Site B — Edge

    A->>S: Pump 1 bearing failure detected
    S->>C: Failure pattern + equipment type
    C->>C: Aggregate patterns across fleet
    C->>C: Retrain autoencoder for pump type
    C->>S: Updated model for pump type X
    C->>B: Updated model for pump type X
    S->>A: Deploy updated model
  1. Site A — a pump fails. The edge device's autoencoder detected an anomaly pattern in the vibration data before failure.
  2. Cloud — the failure pattern is uploaded, tagged with the equipment type, and aggregated with patterns from other sites running the same equipment.
  3. Retrain — the cloud retrains the autoencoder for that equipment type using the combined dataset.
  4. Deploy — the updated model is pushed to all sites running that equipment type, improving early detection everywhere.

This works because device types standardise the tag schema. A "centrifugal pump" has the same tags everywhere, so training data from one site is directly applicable to another.