ITS platform modules — one system, many functional layers.

Twelve modules across four layers plus the platform's system environment.

The ITS modules are grouped by subject: from management and supervision, through data collection and flow, to automation, visualisation and analytics. The system environment is described separately, meaning the way data is made available to tools running outside the platform.

Administrator panel — central configuration of modules and access rights.

The administrator panel is where the ITS platform modules and their configuration are managed. It is used to set the main operating parameters of the instance, the network settings, the configuration of individual modules and the access settings: users, roles and permission levels.

Module configuration is maintained in one place and propagates from there to the platform modules.

Data monitoring — thresholds, alarms and deviations in the data.

Data monitoring watches the measurements arriving at the platform and compares them against defined thresholds. Six threshold levels are available per metric — three on the low side and three on the high side — which makes it possible to distinguish a mild deviation from a state that calls for immediate action.

The levels are labelled 3Low, LowLow and Low on the low side, and Hi, HiHi and 3Hi on the high side. Low and Hi mark the edge of the normal operating range, LowLow and HiHi correspond to a deviation that needs attention, and 3Low and 3Hi to a critical excursion. The levels are defined separately for each metric, so temperature and pressure need not share the same scale.

Graded thresholds have a practical purpose: they let notifications be separated. Entering the Low or Hi band can go no further than the operator's dashboard, LowLow and HiHi can trigger a message to the maintenance team, and 3Low and 3Hi a top-priority alarm. Recipients are therefore not buried under low-significance events.

When a value crosses a defined threshold, the module records an alarm event, which the dashboard module can visualise and the automation module can use to trigger a further response.

An alarm event is not a single point in time. If the value reaches the next threshold while the event is open, the module records a change of significance — a move from Hi to HiHi, for instance — without closing the event and opening a new one. A trace that shifts level several times produces one entry, not a series of unrelated alarms.

Two pieces of information about significance are stored: the level at which the alarm began, and the highest level reached over the whole duration of the alarm state. That distinction matters during analysis, because it shows both the moment the process started leaving its range and how far it drifted before returning.

For each metric, the alarm history therefore holds the moment of the first excursion together with its level, the highest level recorded, the moment of return to range, and the total duration of the alarm state.

Thresholds are not a configuration detached from the data. The thresholds in force at the moment of writing are attached to the metric's history records, so the configuration of a given period stays in the history alongside the readings.

A change of thresholds takes effect from the moment it is made, for current data and subsequent events. The history nevertheless stays readable: entries from before the change show the thresholds that applied then. That makes it possible to reconstruct why a given reading raised an alarm, or why it did not, even though the same value would be judged differently today.

This matters for retrospective analysis and for audits. Without stored thresholds, judging an event from several months ago would mean remembering which configuration applied at the time, and with several hundred metrics that is not feasible.

Replication — replication of the full state between instances.

The replication module is responsible for moving data between ITS platform instances. The full state is replicated: telemetry, alarms, thresholds and events, not only raw readings.

The direction of replication is not imposed. A source instance can pass data to many target instances, but the reverse arrangement is equally possible: many local instances replicating to a single upstream instance. That second model is the basis of consolidation, bringing scattered plants, facilities or sites into one picture without building a separate integration for each of them.

A replicated entry carries metadata about its origin: a unique identifier, an exact timestamp and information about the source instance. Data from many sites can therefore be combined into one coherent picture while retaining the full history of where it came from.

Replication is not limited to one kind of data. It covers the platform modules that gather information about the installation, from infrastructure status through measurements and alarms to traceability and production indicators. The scope of replication depends on which modules are running in the source instance.

Replication brings a separate question with it: the single point of failure, or SPOF. This is an element of the architecture whose stoppage interrupts either data collection or access to the data. In measurement systems that has a consequence which is hard to make good: a measurement that was not written during the outage does not exist and cannot be reconstructed later.

In an arrangement where one instance collects data from the whole installation, that instance is the point in question. A stopped service, a host failure or a broken link to the site means a gap in the time-series data for the entire duration of the interruption. The risk grows with the number of facilities connected to the same instance.

Replication redistributes that risk. Recording is carried out by a local instance placed close to the source, on an ITS Edge Box at the site or on a separate virtual machine. The data is created and stays on site, so a failure of the upstream instance or of the link does not stop recording. Once the connection returns, the outstanding records are replicated upward and the consolidated picture fills in the period of the interruption.

MQTT broker — several brokers within a single instance.

The module makes it possible to create and manage several independent MQTT brokers within a single ITS instance. The brokers operate in isolation from one another, which allows data traffic to be separated by application, by customer or by part of the installation.

Users and their access permissions are managed separately for each broker, as are its listeners, meaning the IP address and port on which the broker accepts incoming connections. A broker can run with or without TLS encryption. This makes it possible to build mutually isolated communication channels within one platform.

Brokers and user accounts are defined for the whole infrastructure from the platform level. That gives full control over the communication passing through the system: it is clear who connects, over which channel and with which permissions.

Low-code automation and integrations — data flows without programming.

The module allows data flows and integrations between systems to be built visually, from ready-made blocks joined into a diagram. A flow brings together a data source, a transformation, a condition and a destination, and how it works is visible directly in the drawing.

Flows start automatically in response to events from the platform — an alarm recorded by the Data monitoring module or a new entry in Traceability, for instance — and can lead to actions in external systems.

The environment is not a closed configurator. Function blocks are programmed in JavaScript, so custom logic sits alongside the ready-made elements: converting and normalising values, filtering, merging several sources into one record, handling non-standard formats or exposing a custom API. A simple flow is built from blocks alone; where more is needed, code is written in the same place.

This approach makes it possible to build a custom application area within the platform: a set of flows implementing logic specific to a given installation, without standing a separate system next to ITS and without maintaining an extra integration between the two.

A broad set of ready-made communication blocks is available. It covers protocols found in industrial automation, standard network protocols, file and database exchange, notifications, and blocks connecting a flow directly to the platform modules — writing to IDC or registering an entry in Traceability takes a single element, with no intermediate layer to build.

The scale of this catalogue is far greater than the lists above suggest. The public component library for this environment holds over five thousand blocks and ready-made flows contributed by the community, from industrial protocols through cloud services and databases to helper tools. The lists above indicate what is most often used in industrial installations, not the limit of what is possible.

A large and active community stands behind the environment. Extensive documentation, forums, courses and thousands of ready-made flows are available online to download and adapt, so solutions to typical problems have usually already been written up. That genuinely shortens the time needed to build a flow and lowers the barrier for someone who does not program day to day.

AI models help here too. Because function blocks are written in JavaScript and the flows themselves are stored as JSON, language models handle the preparation of function code fragments, data transformations or the skeleton of a whole flow well. The resulting code only needs pasting into a block and adjusting to your own metric names, which is one reason why building integrations in this module is within reach of teams without a development background.

Below are several typical areas of use, shown as flow diagrams. Input blocks are marked in cyan, ITS module blocks in indigo, while transformation and action blocks remain neutral.

The flows shown are examples of arrangements, not a closed list. The order of blocks follows the logic of the process and can be arranged freely, and once built, a flow can be copied and reused in the next installation.

Traceability — the full history of the process, set within the structure of the installation.

Traceability records data tied to specific objects in the installation: products, their sub-assemblies, measurement points, test results and so on. Object types are defined, along with the individual objects of each type, and the module records the values assigned to them together with an exact timestamp.

For more complex uses the module offers Custom Data Blocks: the ability to record a multi-value set of data of differing types under one shared timestamp, shaped to the structure of a given installation. A whole set of measurements gathered while a particular part was being made — a temperature trace, a pressure trace or that of another process parameter — can therefore be attached to it. The traceability history then holds not only an information record with property values, but also the corresponding body of measurement data. Traceability uses the platform's Replication mechanism, so the full history of the process is available on several ITS instances at once, with information about the origin of the entries retained.

The descriptive structure is built on object properties, prop for short. The object type determines which properties objects of that kind have: their names and data types, for instance text for a serial number, a number for a measurement result, a boolean for a test outcome. An individual object holds the values of those properties.

A property can be written once, like a serial number assigned when the object is created, or recorded repeatedly when the value changes at successive stages of the process. In both cases the record carries an exact timestamp, so not only the object's current state is visible but also the path by which it got there.

Traceability rarely stops at one workstation. In practice the record is created where the operation happens — at a production cell, on a line, at a particular site — while the overall picture is needed a level up. Traceability in ITS is built so that these two levels can be joined without moving data by hand.

At workstation level the recording is done by a local instance, most often on an ITS Edge Box. The data is created and stays at the place of production, so recording works even when the link to the central location is temporarily unavailable. The records are then replicated upward, to an upstream instance such as an ITS VM, where the Consolidator module brings them into one picture. Origin metadata stays with the entries, so at system level it is still clear which cell and which instance each record came from.

The second dimension of this structure is product genealogy. A traceability record is not a flat list of events; it can refer to other records. When an assembled product is made from two components, the new trace holds references to the records of the parts it was built from.

An example follows. An elbow is produced at one cell and its trace is created there; a tee is produced at another with a record of its own. Both arrive at the assembly station, where a new product number is created along with a new record, and that record contains references to both component records. From the finished product this leads back to the specific batches of components and the conditions under which they were made. From the component's side, it leads forward to the products in which it was used.

This structure has as many levels as needed. An assembled product can itself be a component of the next product, and its trace then becomes a subordinate record one level up. Traceability therefore runs from a single component all the way to a shipping batch, even when successive stages take place at different cells or different sites.