Histenco
An industrial historian that stores every change and never guesses
A data historian for plant signals, written in Rust and run as one program on a site server or an edge box. It collects from Modbus, OPC UA, MQTT and an existing GE historian, stores only changes, keeps every doubtful reading flagged rather than dropped, and answers in SQL, Parquet, an HTTP API and a terminal.
Built around one idea
Most plants have a historian that is either expensive per tag, trapped in one vendor's formats, or a general database straining under plant data rates. Histenco is built around a smaller idea: store every change and nothing else, validate every setting and every reading at the door, and keep the data in open formats so it is never trapped.
It is one program. Collectors poll devices on a clock-aligned grid, convert each reading to an on-change event at the edge, and record a lost device as bad-quality data rather than a silent gap. The storage engine writes a log before it acknowledges anything, then compresses into immutable time-partitioned files at about three bytes an event. The same query service answers the command line, the HTTP API and SQL, so they cannot disagree.
A plant engineer configures it in one file, with every error reported in one pass with its line number, and can change tags while it runs. A data team reads it with SQL or exports Parquet. An edge site forwards everything to a central historian through a queue that survives any outage.
What it does
Collectors
Modbus TCP and RTU, OPC UA with signed and encrypted channels, MQTT with JSON and Sparkplug B, Netdata system metrics, and a GE Proficy Historian read through its REST interface with gaps filled. Each source runs on its own thread; a fault on one never stops the others.
Tag rules
Type, resolution, range, deadband, heartbeat and a plausible rate of change, applied to every write. Out-of-range and spiked readings are stored and flagged uncertain, never discarded. A tag's id and type are permanent, so history can never be reinterpreted by a config edit.
Storage engine
Write-ahead log, then compressed immutable segments partitioned by time, with checksums everywhere. A crash at any point loses nothing. Retention deletes whole files, and backups are safe while it runs.
Queries
Raw, value at a time, interpolated, time-weighted averages, totals, state durations for delay accounting, and trend reduction for a screen. One implementation behind the command line, the API and SQL.
SQL and Parquet
Standard SQL over an events table and the tag catalogue, reading only the tags and times a query names. Parquet export that opens in DuckDB, pandas, Power BI or Spark.
Calculated tags
Spreadsheet-style formulas with time windows and quality tests, checked when the config loads, computed on a grid and back-filled over history. Nothing can loop, hang or escape.
Store-and-forward
An edge historian sends everything it stores to a central one through a durable queue. An outage of any length costs disk space on the edge and nothing else, and any time range can be re-sent.
Operations
Runs as a systemd, launchd or Windows service. Tags change without a restart, in the config, in a spreadsheet loadsheet or in the terminal interface. Every problem is reported in plain words with its line or row.
What it looks like
How it is built
- Written in Rust with unsafe code forbidden in every crate. The storage engine has no dependencies at all, so there is nothing to audit under it and the build is identical on every platform.
- On-change storage from the edge. Polled readings are stamped on the poll grid and stored only when they change, with a heartbeat proving a flat signal is alive, which is why a second of data costs about a bit per timestamp.
- Faults are data. A lost device records its tags as bad quality once, holding the last value, so a trend shows where the data stopped being trustworthy instead of a gap that looks like a flat line.
- Nothing is quietly guessed. Unknown settings are errors, every problem is reported in one pass, and a reading the rules refuse is counted and logged with its reason rather than dropped.
- Open formats out. CSV and Parquet, SQL in, documented on-disk formats. The data is never trapped in the product.
- A historian on a network without a token is a configuration error, not a surprise. Without tokens the API serves loopback only.
Integrations
A historian is only as useful as what reads from it and what feeds it. Histenco connects to the plant with the protocols it already speaks, and gives the data out in the formats the rest of the business already uses.
What connects today
Plant protocols
Modbus TCP and RTU, including RTU over serial-to-Ethernet gateways and buses with many units; OPC UA by polling or subscription, with Basic256Sha256 security; MQTT with JSON payloads read by path and Sparkplug B by metric or alias.
An existing GE historian
Tags copied from a GE Proficy Historian through its REST interface, with history back-filled and outages read back, or streamed through MQTT with the REST source filling what the stream missed. Nothing is installed on the GE side.
HTTP API
Query, write, SQL, health, sources, log and the forward link, as JSON or CSV, with bearer tokens for read and write roles. The same routes the terminal interface uses.
SQL, Parquet and CSV
Read-only SQL over the data for any tool that speaks it, Parquet files for data platforms, and CSV import for history from spreadsheets or an old system.
Edge to central
Store-and-forward from any number of edge historians to a central one, matched by tag name, with every event's quality carried through.
What we could add
- EtherNet/IP for Allen-Bradley, S7 for Siemens and DNP3, on the roadmap and built when a site needs them.
- A browser trend screen served by the historian, the next piece of work after the terminal interface.
- Production reporting, delay accounting and condition monitoring alarms built on the API, which is the software work Enco does.
- An archive tier that moves old partitions to cheaper storage as Parquet, still queryable.
How you can run it
- Installed on a site server or an edge box as a single binary with no runtime to manage, running as a service, with the data directory on local disk. A static Linux build needs no libraries on the target.
- A central historian hosted by Enco or in your environment, receiving from any number of edge sites through the store-and-forward link.
- Configured from one file and a tag loadsheet, with the first tags validated and collecting on the day it is installed.
- Supported by the engineers who wrote it. The storage engine, the collectors, the API and the SQL layer carry 190 automated tests, and an hour at 100,000 tags against simulators ran with no losses.
See it working, then decide
The quickest way to judge it is a walkthrough on real workflows. Tell us what your team runs today and we will show you where this fits, or where a custom build fits better.