Technical specifications

DataPortia™ is installed on the plant's own Windows or Linux server. It connects to the automation system as an OPC UA client, stores the time series in a PostgreSQL 18 + TimescaleDB database and serves the user interface from its own Kestrel server over HTTPS. No cloud service is needed at any point.

What parts does DataPortia consist of?

There are four layers: OPC UA data acquisition, an ASP.NET Core 10.0 application server with its own Kestrel server, a PostgreSQL 18 + TimescaleDB time series database and a Vue 3 browser user interface. AI analysis is a separate add-on that runs a local language model with Ollama. Every part runs on the same customer server.

In detail: what these choices mean in practice

TimescaleDB is a PostgreSQL extension, so the database is ordinary PostgreSQL. It is backed up, replicated and monitored with the same tools as the plant's other PostgreSQL databases, and no separate database expertise has to be acquired.

Its own Kestrel server means that no separate IIS or nginx installation is needed. A reverse proxy can still be placed in front of it if the plant's policy requires it.

What are the system requirements?

The minimum requirements are 8 GB of memory and a 100 GB SSD. The practical recommendation is 16–32 GB of memory, because time series queries and report generation benefit from caching. The operating system can be Windows 10 or 11, Windows Server 2016 or newer, or Linux (Debian, Ubuntu). No internet connection is required.

The disk space needed depends on the number of points collected and on the retention period. Automatic compression starts after two days and saves over 90 % of the disk space, so long retention does not cost as much as the first few days would suggest.

How much data can DataPortia handle?

Throughput is over 2 000 values per second, which is about 172 million rows per day. Automatic compression starts after two days and saves over 90 % of the disk space. The retention period is adjustable and defaults to 24 months. Compression does not restrict the time range the data can be queried over — only the retention period does.

2 000+

values / s Write throughput to the time series database

172

million rows / day The same throughput over a day

90 %

disk space saved Compression after two days

In detail: retention, compression and history import

The retention period determines how far back the data goes. The default is 24 months, and the value is adjusted to the plant's needs — regulatory reporting, for example, may require a longer period than operational monitoring.

Older data can be imported from the OPC UA server's history store. The import reads gap-based and skips periods already imported, so the same period can be run again without duplicates. Acquisition and storage are described in more detail on the OPC UA data acquisition page.

How is the data protected?

All traffic runs over HTTPS with certificates handled automatically. Users authenticate either with local accounts or with Azure AD / Microsoft Entra ID, in which case permissions are managed from the organisation's own directory. The API is read-only and nothing is written from it to the automation system. Process data never leaves the plant network at any point — not in AI analysis either.

In detail: which way the traffic runs

In the automation network DataPortia acts as a read-only client: it reads values and alarms from the OPC UA server but writes nothing back to it. Setpoints and acknowledgements still travel by the automation system's own route.

Outbound, the data moves in two ways: the REST API answers queries with an API key, and webhooks push events signed with HMAC. Neither includes write operations to the automation system. See REST API and webhooks.

How does the system prepare for faults?

Preparation is on three levels. An OPC UA connection can be given a primary and a standby server, so acquisition moves to the standby server. At the database level, PostgreSQL physical streaming replication is used; the failover is automated either by DataPortia's own DPFC controller (Windows and Linux) or by pg_auto_failover or Patroni (Linux only). At the application level there is an active-passive pair, which requires a separate HA add-on licence.

An application-level failover takes about 15–30 seconds when the process crashes but the machine stays up. If the whole machine dies, PostgreSQL only notices the dead session through the TCP keepalive mechanism — with default settings that takes longer, so keepalive has to be tuned. The database failover time depends on the failover tool used. The full picture is on the Redundancy and high availability page.

Which automation systems does DataPortia connect to?

DataPortia connects as an OPC UA client to any server that follows the standard. In practice that means Siemens, ABB, Valmet, Beckhoff, Schneider Electric, Honeywell and Rockwell Automation — and equally any other OPC UA compatible system. No changes are made to the automation system.

These are compatibility statements, not partnerships. DataPortia is not the product of any equipment supplier, nor certified by one. The compatibility rests on the data transfer using the OPC UA protocol, which these systems support.

In detail: what the connection requires at the automation end

The automation system must have an OPC UA server enabled and credentials that grant read access to it. No new software is installed on the automation side and the control program is not touched. If historical data is wanted retrospectively, the server must also have its history store enabled.

Frequently asked questions

Below are the technical questions that come up most often during procurement: virtualisation, languages, database maintenance, network connections and the requirements of the AI module. If the procurement needs a more detailed technical statement, put together a list of questions and send it — I will answer it in writing.

Can DataPortia run in a virtual machine?

It can. The software does not require physical hardware. Size the virtual machine with at least the memory and disk the requirements state, and make sure the disk is SSD-class — time series writing is disk-driven, and a slow disk shows up directly in throughput.

What languages is the user interface available in?

Finnish, English, Swedish and German. The language is chosen per user, and the choice affects neither the licence nor the price. Support is available in Finnish and English.

Does PostgreSQL have to be installed separately?

The database is part of the installation. If the plant already has a PostgreSQL environment with its maintenance arranged, the database can be placed there — TimescaleDB is a PostgreSQL extension, so this is an ordinary PostgreSQL database. Tell me the situation at installation and we will agree which way makes more sense.

Does the server need an internet connection?

It does not. Data acquisition, storage, reporting and AI analysis all work locally. The language model runs with Ollama on the same server, so AI queries do not leave the network either. An internet connection is needed only if updates are to be fetched from the network.

What does the AI module require from the server?

The language model runs locally, so it needs more memory and computing power than the other parts. The sizing depends on the model chosen — Qwen, Gemma, DeepSeek and Llama differ greatly in size. Tell me what server is available and I will assess a suitable model. See local AI analysis.

How do I test this in my own environment?

The trial version is 30 days, all features apart from the HA add-on, and no commitment. Install it on your own server and connect it to a real automation system — that is when you find out what a specification does not show: how much data the plant actually produces and whether the server is sized for it. I deliver the installation package and the trial licence.

Request a 30-day trial Get in touch