Back to home

Platform architecture

The overall architecture makes it possible to technically implement and achieve the platform's key ideas.

Core ideas

The foundational ideas built into the platform

User convenience

  • Intuitive modern UI
  • Adapts to the user's needs
  • Easy migration from other platforms

Fast development

  • Clear project logic
  • Convenient data management
  • Interoperability

Resource efficiency

  • Get the most out of the hardware
  • Linear scaling
  • Pay for software, save on hardware

Core architecture principles

These principles define the technical capabilities of the system

Real-time core

The real-time core is responsible for all time-critical system components and their interaction. The real-time core provides fault tolerance, reliability and availability. It delivers the key critical functionality.

Learn more

Model architecture

Abstract models are complex nested data structures that describe a domain object. Such models make it possible to create many object instances that the system interacts with.

Learn more

Reactive architecture

Reactivity here means an event-driven architecture. Each object is assigned a lightweight thread responsible for reactivity. The principles of reactive architecture are set out in the Reactive Manifesto.

Learn more

Cluster architecture

Critical functions are assembled into service monoliths and combined into a cluster. Running in Symmetric Active-Active mode, the cluster serves many pluggable (micro)services — for example, protocol drivers and compute modules.

Learn more

Service architecture

System components interact via a service model. Service monoliths and microservices interact according to unified principles. This approach enables efficient interaction with a wide range of data sources.

Learn more

Compute model

A multi-level compute model makes it possible to detail the project logic. Closer to the core, simple calculator scripts are available — for computing dynamic setpoints and simple logical operations. For complex scenarios there is a full-featured language.

Learn more

Architecture features

The technical implementation of these principles enables the following capabilities

On-the-fly configuration

Changing the system and data configuration without interrupting or stopping running processes, or with such downtime minimized. Collaborative development is supported.

Redundancy

Supports an active multi-node configuration. It is this option that ensures minimal downtime even during failures (0-RTO). If a node needs to be taken out of service, others always remain available.

Large data volumes

Handling significant data volumes, including under high load. Millions of objects, tens of millions of variables, billions of values.

Graceful degradation

If the load exceeds the available resources, the system drops the least significant data. In some cases the data is not lost but kept in queues — for later processing once the load decreases.

Linear scaling

Additional nodes can be added to scale the system. All services that are not close to the core can be decentralized. Services close to the core run in SAA mode.

Multi-tenancy

The ability to isolate a space (objects, services) for different subsystems and users. It is based on a mature role-based access control system.

Platform structure

Structurally, the platform consists of three environments: the core environment, where all key functions and the API are concentrated, the runtime environment and the development environment.

Platform core

  • Contains the core functionality
  • Responsible for working with data
  • Service interaction mechanics
  • Implements the reactive architecture
  • Implements the security system

Runtime environment

  • Key operator tools
  • HMI screens and widgets
  • Trends
  • Events, alarms and acknowledgement
  • Convenient UI/UX

Development environment

  • Key developer tools
  • Mature development environment
  • Vector editor support
  • Change synchronization
  • Scripts

Platform core

Delivers the key critical functionality.

Operational data

  • Dynamic tags (variables)
  • Served in RAM
  • Operational archive (cache)
  • Load and burst management
  • Up to 10,000,000 tags per node

Metadata

  • Non-time-critical data
  • Weakly dynamic
  • Configurations, structures, hierarchies
  • Isolated from operational data
  • Stored in relational databases

Data archive

  • Long-term data storage
  • Time-series format (TSDB)
  • Stored in columnar databases
  • Compression, downsampling, cyclic records
  • Slower access than operational data

Core data structure

Data types

  • Discrete — boolean
  • Integer — integer
  • Analog — float
  • String — string

Models

  • Abstract structures
  • Complex nested hierarchy
  • Models are composed of models
  • Core OOP principles

Objects

  • Based on models
  • Many instances
  • Structurally depend on the model
  • Support cascading changes
Changing a model triggers a cascading change to every object created from it. Deleting variables used in the system logic can lead to unpredictable consequences — such changes must be carefully planned, and the configuration should be saved beforehand via backup or export.

Model architecture

Data is described through models and objects: a model is an abstraction, an object is its instance. Each object works as an independent reactive entity.

How models and objects work

  • A model is an abstract entity made of simple-type variables and nested models.
  • Nesting of any depth.
  • An object is created strictly from a model and fully replicates its structure.
  • You cannot change an object's structure without changing the model.
Structure composition
Composite model «Unit»
Model «Pump»
State · boolSpeed · floatPressure · float
+
Model «Valve»
Open · boolPosition · float

Variables → model → composite model.

Object derivation
Object inheritance
Model «Pump»
abstract entity
Pump #1
instance
Pump #2
instance
Pump #3
instance

Objects replicate the model's structure.

Cascading change: a change to the model is automatically applied to every object created from it.

Reactive architecture

  • Each object is served by its own lightweight thread
  • These threads are the basis of reactivity (N threads, M CPU cores)
  • Objects react to changes independently and in parallel
  • Such threads have minimal overhead
  • Scales to millions of objects per node
  • Control of cascading changes and protection against loops
Object
served by a lightweight thread
Millions of objects
in parallel per node
Go · goroutines
lightweight threads, minimal overhead

Reactive architecture

Event-driven architecture (EDA)

Events

  • Events are dynamic platform objects
  • Created in reaction to changes in variable values
  • An event stays active while its creation conditions hold
  • Conditions are defined by the calculator
  • Occur when the state of a discrete object changes
  • For example, an object monitors temperature
  • When the setpoint is exceeded, it changes state
  • An event of the specified type occurs
Set of attributes:
objectclasscreation timemessage textclass priorityactive flagacknowledgement flagacknowledged by

Alarms and acknowledgement

  • An alarm is an event class at the top of the priority scale (the most critical events)
  • You can define several alarm classes of different criticality
  • Alarms can trigger audiovisual effects to draw operators' attention
  • By acknowledging, the operator confirms receipt of the event information
  • The platform records exactly who acknowledged it

Event prioritization

  • Priority is a numeric value, for example from 1 to 10
  • Set for an event class and defines its importance and criticality
  • The higher the value, the more critical the event
  • Alarms are assigned the highest priorities
Ranking and sorting

Priority affects the order of events. Classes can be sorted by priority, acknowledgement ability and sound.

Audible notification

The sound is played for the event with the highest priority — sequentially, at a set interval.

Until acknowledgement

The signal repeats until an event with a higher priority arrives or the current one is acknowledged.

Priorities
low
1234567
messages
8910
alarms
high

Service model

Service-oriented architecture (SOA)

The core can serve services of three classes

1234

Core services

  • Data processing close to the core
  • Operate on cache data
  • Basic services
eventscomputationarchiving

Interfacing drivers (edge)

  • Data collection and preprocessing
  • Postprocessing and preparation
  • Transfer of data and control commands
EdgeETL/ELT

Interfaces (API)

  • Full access to the API
  • REST protocol
  • WebSocket for reactivity and real time
APIRESTWebSocket

Process control protocols

  • Support for open protocols
  • Support for proprietary protocols
  • Support for special protocols
NTPSNMPOPC UAModbusProfinet
BACnetMQTTIEC-60870IEC-61850

Interfacing with IT systems

  • Interfacing with open APIs
  • Interfacing with proprietary APIs
  • Interfacing over a bus
ZabbixTrassirPercoFindFace
AsteriskOrionProSyslog

The full list of drivers and open protocols is on the home page.

Compute model

The platform includes several compute tools

Calculator

  • Runs within reactive logic
  • On a change of the linked object
  • Limited functionality
  • Runs at the core level

Cluster scripts

  • Complex algorithmic computation
  • Computation based on variables
  • Extensible functionality
  • Ability to work with data outside the core

Signal simulator

  • Signal generation
  • By a defined law
  • Reference signal for computation
  • For testing and diagnostics

Calculator

Where the calculator is used

  • Tracking variable changes
  • Arithmetic, comparisons, integration, conditional operations
  • Logical computation
  • Computing floating setpoints

How the calculator is invoked

  • The calculator is invoked from a logical variable where the target formula is defined
  • As soon as the defined condition is met, the variable switches to the required state
  • The state defines the target event (including an alarm)

Calculator operations

+−×÷x²∫
><=≥≤≠
NOTIFIFS

Floating setpoint

t →
ProcessSetpoints (upper / lower)

Cluster scripts

For complex tasks that the calculator does not cover.

Complex logic

  • Arbitrary control logic
  • Modern Lua language
  • Compilation to bytecode
  • Large volume of code
  • Any complexity

Algorithm libraries

  • Ability to create libraries
  • Code reuse
  • Managed from scripts
  • Functional-group control
  • Interfacing with DCS

API availability

  • Access to the entire platform API
  • External APIs available
  • Decentralization
  • Interoperability
  • Security

Why Lua

Lua is a lightweight and fast language, syntactically very close to ST (Structured Text), familiar to process control engineers.

LightweightFastSimilar to STFamiliar to process control engineers
The same pump control algorithm:
ST (Structured Text)
PROGRAM Control_Pump_Prog
VAR
    // Variable initialization (like local in Lua)
    waterLevel : REAL := 5.5;   // Current water level
    tankMax    : REAL := 10.0;  // Maximum level
    tankMin    : REAL := 2.0;   // Minimum level
    pump       : BOOL := FALSE; // Pump state
    alarm      : BOOL := FALSE; // Alarm state
END_VAR
 
// Pump control function
 
IF waterLevel > tankMax THEN
    pump  := FALSE;    // Turn the pump off
    alarm := TRUE;     // Raise the alarm signal
ELSIF waterLevel < tankMin THEN
    pump  := TRUE;     // Turn the pump on
    alarm := FALSE;    // Clear the alarm
END_IF;
 
END_PROGRAM
Lua
 
 
-- Variable initialization (like the VAR block)
local waterLevel = 5.5   -- Current water level
local tankMax    = 10.0  -- Maximum level
local tankMin    = 2.0   -- Minimum level
local pump       = false -- Pump state
local alarm      = false -- Alarm state
 
 
-- Pump control function
local function controlPump()
    if waterLevel > tankMax then
        pump  = false    -- Turn the pump off
        alarm = true     -- Raise the alarm signal
    elseif waterLevel < tankMin then
        pump  = true     -- Turn the pump on
        alarm = false    -- Clear the alarm
    end
 
end

The comparison is shown using pump control as an example: the cursor runs synchronously across both blocks, highlighting the corresponding lines. Hover over a line to match them manually.

With a properly prepared environment, Lua lets you write almost in ST syntax. In general, scripts developed in ST or FBD are easily ported to Lua using modern specialized tools.

Simulator signals

The simulator generates variable values according to a specified law.

  • Amplitude and frequency are configurable
  • For analog and discrete variables
  • Can be used as a reference signal for computations
  • Used for diagnostics
Analog
Constant
Sinusoidal
Triangular
Sawtooth
Square
Random
Discrete
State change
Constant

Cluster model

Fault-tolerant high-availability cluster

Cluster node

  • Symmetric Active-Active cluster
  • Hot standby
  • Coherent in-memory cache
  • Dedicated interconnect
  • Load balancer
  • Up to 10,000,000 tags per node

Interconnect

  • Bidirectional exchange between nodes
  • Channel redundancy
  • Secure exchange protocol
  • High throughput
  • Low latency and jitter
  • Graceful degradation

Cluster client

  • Active-Passive mode
  • Active redundant connection
  • Automatic failover
  • For gateways, including the API gateway
  • For serving drivers (RRW)
  • For serving WebSocket (WS)

Interconnect scheme of the core cluster model

Cores
8
Hosts
16
Cluster IC
2
Host IC
2
Segmentation
IC 01IC 02IC 03IC 04IC 05IC 06R01R02R03R04R05R06R07R08C01C02C03C04C05C06C07C08C09C10C11C12C13C14C15C16
Learn more about the core architecture

Cybersecurity

The platform includes a powerful access control system.

Access control

  • Role-based access control (RBAC)
  • Limited-scope tokens (TBAC)
  • Support for IAM access management systems (LDAP, Keycloak)
  • Multi-tenancy at the object level

Access control objects

  • Models and objects
  • Drivers and services
  • Scripts
  • Components and HMI screens

Identification and access

Built-in access management at all platform levels, with no external dependencies

Built-in

Proprietary authentication mechanism and role-based access model with no external dependencies. Temporary tokens.

RBACTBAC
LDAP

Integration with corporate directories for unified account management

LDAPActive Directory
Keycloak

External identity provider with single sign-on and federation support

SSOOAuth 2.0OpenIDFederation

Import, export and backup

Enables efficient exchange of project data in different formats

Data export

  • Models and objects
  • Events and alarms
  • Scripts
  • Drivers and services
  • Components and HMI screens
  • Variable bindings
  • Roles and users

Data import

  • Simplifies project creation
  • Requires a consistent format
  • For example, tabular (xlsx, csv) or xml
  • Can import from a third-party API
  • Full or partial import
  • Takes versioning into account
  • Requires some care

Backup

  • Performed on request
  • Can be reactive or on a timer
  • Can be invoked by a script
  • Immediately portable
  • A recovery method for failures that should not happen
  • Support for third-party backup systems