Architecture

Iotellect SCADA/HMI is heavily based on Iotellect. Most of its functions are derived from the underlying framework.

Technically, the SCADA/HMI solution is a set of device drivers and plugins extending Iotellect.

Below is the list of Iotellect manual sections that are highly relevant to the SCADA/HMI solution:

Projects vs Applications

Traditional SCADA systems often organize resources into projects, providing a structured way to manage all elements of an industrial automation solution.

Iotellect does not have a dedicated "project" object type. Instead, any context, such as a device, dashboard, or model, is treated as a resource which can be added to an application. Applications, thus, supersede projects and provide numerous advantages including:

  • Version Control: Applications can be used with a version control system such as Git, allowing changes to resources to be tracked, managed, and restored as needed.

  • Modular Design: Each application comprises a collection of reusable resources, promoting a modular design approach where different parts of a system can be developed and tested independently, then combined as needed.

  • Simplified Deployment: Applications can be packaged as plugins or exported as plugins, ZIP archives or server folders, simplifying deployment to multiple Iotellect servers.

  • Centralized Management: All the resources associated with a project (application) are grouped and managed together, providing a centralized view of the project structure.

Unified Development and Runtime Environments

Unlike traditional SCADA systems, Iotellect SCADA/HMI has unified environment used for development, debugging, testing and normal operation. There are no separate "development" and "runtime" modules to install.

The core of the system is Iotellect Server. The server maintains connection with the database that is used for storing system configuration, HMI templates, properties of PLCs, cached channel/tag values, and historical trend data.

The server communicates with controllers, sensors and actuators via dedicated device drivers. While present-day controllers tend to perform the near-real-time operations according to their own logic, Iotellect SCADA/HMI allow the server to initiate some control operations that may be guided by custom scripts or actions.

Deployment and Application Lifecycle

According to its primary concept, Iotellect SCADA/HMI can be deployed and configured in a single "primary" server at the production facility.

During the initial phase of deployment, system engineers can connect to the server locally or remotely to build HMIs, create PLC accounts, set up data storage, etc. These resources are added to Applications, which can be deployed to any number of other servers. (See Getting Started and Managing Applications for more information.) In short, if a certain system change is required during normal operation, it's very easy to:

  • Create or update system components (e.g. HMIs, Alerts, reports)

  • Compare and test the changes

  • Update the application’s version

  • Add the updated components to the new version of the application

  • Deploy the new version of the application.

The whole Iotellect SCADA/HMI database may be backed up and restored at any time.

I/O Channels and Tags

In Iotellect SCADA/HMI, I/O Channels (Tags) are represented as Device Settings (or Device Variables). These settings may be either scalar or array/tabular.

Due to the data normalization technology used by Iotellect's unified data model, the value of every I/O channel (tag), including scalar values, is represented by a so-called Data Table. This technology greatly increases flexibility of Iotellect SCADA/HMI by allowing any kind of data (both raw device data and pre-processed data) to be handled by any system component. It also helps build multi-level data processing chains and allow external systems to access data flowing through the system.

In the Iotellect SCADA/HMI architecture, Digital Twins act as the central data model that connects external devices, data processing, and visualization.

Controllers, sensors, and other external devices are connected to the platform via drivers and connectors. These devices provide raw data streams that are received by Iotellect SCADA/HMI.

This data is mapped to Digital Twin variables using Iotellect SCADA/HMI tags and bindings. Digital Twins represent logical objects of the system (e.g., factories, areas, devices) and store their state in a structured and unified way.

HMI screens (see Creating HMIs) are built on top of Digital Twins and use their variables for visualization and control. UI components read and write Digital Twin variables rather than addressing devices directly, and when a tag is configured for writing, Iotellect SCADA/HMI delivers the written values to the equipment.

In this context, a device tag is a source-specific value received from a device, controller, gateway, or device account. A Digital Twin variable used as a SCADA process value can be treated as a digital twin tag. Several device tags can be bound to one digital twin tag when they represent the same process value.

This approach is especially useful in fault-tolerant architectures. The operator interface can use one digital twin tag, while individual device tags remain available for diagnostics and maintenance. The active device tag can be selected according to configured quality, availability, and priority rules; for writable tags, these rules also define which device receives the written values.

Was this page helpful?