Platform · Historian

Keep the history, and be able to answer for it.

Telemetry and operational logs are stored in a columnar store built for volume, with retention you set and query access for the people who need to look further back than the last shift.

Book a demo Size your history

Screen recording: thirty days of one compressor in the trend workspace, its health falling since the last maintenance and its vibration rising, then the last seven days.

Stores: Modelled telemetry, alarms and operational logs
Retention: Set per deployment for telemetry and logs; telemetry is kept until you set a limit
Query access: Read-only, single-statement queries from the product, plus reporting sources
Stays: Inside your infrastructure, history does not move to a vendor cloud

From a reading to an answer

Every value is kept, in one place, for everyone who reads it.

The gateway reads it, the hub stores it with its time, and every screen and query reads the same rows.

Reading MFB_RTM_COMPRESSOR_1 · HealthIndex 71.7 % With the time it was read
Stored Time · device · tag · value · unit One row per value in a columnar store
Kept Until you set a limit One retention setting per deployment
Read by Trends, dashboards, reports, SQL The same numbers everywhere

In the product

Look back, see what changed, take it elsewhere.

The history, with what changed in it

Beside the chart, the changes recorded in the same range: a gateway edited, a pipeline published, a note someone left.

Compare with the previous period, yesterday or last week
Up to eight signals on one chart, exported to CSV or Excel

The data platform command center: volume per day, history per plant and the data dictionary.

What the history holds

Values stored per day and plant, how far each plant’s history reaches, and every signal name with its unit and range.

Signals stored with mixed units flagged
Built as a dashboard, so you can change it

Telemetry API · thirty days of health

POST /api/Telemetry/execute?maxRows=1000
Authorization: Bearer <token>
Content-Type: application/json

{"query": "SELECT toDate(Time) AS day, round(avg(NumericValue), 1) AS health FROM DeviceRawData WHERE DeviceName = 'MFB_RTM_COMPRESSOR_1' AND Key = 'HealthIndex' AND Time >= now() - INTERVAL 30 DAY GROUP BY day ORDER BY day"}

SQL for the systems you trust

An administrator token runs one read-only SELECT over the stored values and gets the rows back as JSON.

One statement, write keywords refused
Up to 50,000 rows per call

Real Proxus screens; the machine data shown is simulated.

Want to see your own history like this? Size your history

Technical details Problems it solves, every capability and the full protocol table

What it solves

What teams run into without it.

History lives in five places

A SCADA archive, a spreadsheet export and a cloud bucket that each cover a different period and disagree at the edges.
Analysis blocked by access

The data team cannot get to production history without asking someone to run an export by hand.
Storage that grows without a plan

Nobody set a retention policy, so the cost curve is discovered rather than decided.

What you get

Built in, not bolted on.

Columnar telemetry store

Built for high-volume time series, with bulk ingestion and compression suited to plant data rates.
Retention policies

Set how long telemetry and logs are kept, per deployment. Telemetry is kept until you set a limit.
Trend Workspace

Any tag’s recorded history with last, average, minimum and maximum for the range, exported to CSV or Excel. Read-only SQL for dashboards and reports: one statement, write keywords refused.
Reporting sources

Reports and dashboards read from the same store, so an operational view and a monthly report read the same numbers.
Operational logs

Operational logs per gateway and an audit trail of configuration changes: the evidence behind a number.
Export when needed

Send results to spreadsheets or downstream tools without opening database credentials to everyone.

What this enables

What the capabilities add up to, in practice.

Answer questions that reach further back than the last shift
Set retention deliberately instead of discovering the cost curve
Let the data team investigate without a hand-run export
Recalculate a derived figure from raw history when a model changes

Detail

What gets stored

Telemetry: Modelled tag values with timestamp, quality and source
Alarms and events: Rule and anomaly outcomes with the context that triggered them
Operational logs: Collection, transformation and delivery activity per gateway
Configuration history: Pipeline revisions you can compare, and an audit trail of every other configuration change

Questions

What teams ask before the first call.

Ask something else

Where is the history stored?

In your deployment. Telemetry and operational logs go to a columnar store built for time-series volume; configuration and asset objects live in a transactional store. Neither requires a vendor cloud.

How long is data kept?

For as long as your retention policy says. Retention is set per deployment for telemetry and logs; telemetry is kept until you set a limit.

Can our data team query it directly?

Yes. The Trend Workspace charts stored values of several devices on one time axis, and read-only SQL (in dashboards and through the Telemetry API) runs one statement at a time under the same role model as everything else, so investigation does not become an outage risk.

Do we still need a separate historian?

Many plants keep an existing historian for regulatory or legacy reasons, and Proxus feeds it. If you do not have one, the built-in store covers the same job without another licence.

Can we reprocess history if a model changes?

Raw values are kept at the resolution you collected them, so recalculating a derived figure later is a matter of reading history back rather than re-collecting it.

Continue

Two numbers set your price: the gateways you run and the data rate they carry. See pricing

Keep the history, and be able to answer for it.

Every value is kept, in one place, for everyone who reads it.

Look back, see what changed, take it elsewhere.

The history, with what changed in it

What the history holds

SQL for the systems you trust

What teams run into without it.

History lives in five places

Analysis blocked by access

Storage that grows without a plan

Built in, not bolted on.

Columnar telemetry store

Retention policies

Trend Workspace

Reporting sources

Operational logs

Export when needed

What the capabilities add up to, in practice.

What gets stored

Holding history for plants that have to answer for it.

What teams ask before the first call.

How much history will you keep?