How it works

A folder of exports, one PC inside the fence, one command and an afternoon with someone who knows the plant. What it reads, what it touches, and what it never does.

A folder, a laptop, one command, and an afternoon of someone who knows the plant.

No project to set up first. The first result comes on the first day, and it comes with the list of things it did not understand, which is the only configuration there is.

  1. Day one

    Copy the exports into a folder

    Whoever already pulls reports out of the historian or the control system saves a few weeks of it as CSV files, one per system, in whatever clock format that system writes. If there is an instrument index as a PDF, it goes in the same folder. That is the whole data preparation.

  2. Day one

    Put the folder on one machine you own

    A PC or a laptop on your side of the fence. Measured on our simulated aluminium works scaled to 9,511 tags, with its raw meters decoded by physical law, the hardest case we have: it compiles in 449 seconds at a peak of 4.1 GB. A plant whose meters already read in engineering units is far quicker. The language model is 3.0 GB on disk, so a 16 GB laptop holds both at once. No graphics card, no internet connection.

  3. Day one

    Run one command

    On Windows that is one zip, unpacked into a folder and started with a double-click: it carries its own Python, installs nothing, needs no admin rights and no internet, and is removed by deleting the folder. It finds the clocks, picks the connector that reads the most of your tags, reads the PDF if there is one, and writes back a plant model, a shift handover and the list of tags it refused to guess at, with the reason next to each.

  4. The first afternoon

    Answer the refusal list

    An engineer who knows the plant goes through the refused tags. On the published test rig further down this page, with no connector written for it, that was 91 of 173 tags, each with its reason. The answers go into a plain text file next to the exports, which the plant owns and can read without us, and one answer can place more than the tag it is about.

  5. Within a fortnight

    A plant model you can argue with

    An operator checks it against the plant they know and signs it off. From then on the historian's scheduled export lands in the same folder, each new file is read as it arrives, and a renamed or silent tag is reported instead of lost.

What you need

  • A folder of CSV exports the plant already knows how to make
  • One PC or laptop you own, inside the fence
  • An engineer who knows the plant, for an afternoon
  • An operator to sign the model off

What you do not need

  • A connection to the control system
  • A firewall rule or a new network path
  • An account, a cloud tenancy or a licence server
  • Anything installed on a PLC, a SCADA server or a historian
  • An asset register or a data model drawn in advance
  • A data engineer, or an IT department to run it
  • A graphics card
  • Admin rights, or anything installed on the PC

The fortnight does not include your procurement, the supplier security assessment, the NDA or the operator's sign off. We do not control those and the clock does not pretend to cover them.

It reads copies. It writes nothing to the plant. Nothing leaves.

The least invasive way to learn what a plant's data means is to never touch the plant. Each answer below is a property of how the product is built, and where it can be checked, the right hand column says how.

Your control system

Never connected and never touched. It reads copies of files that somebody exported.

There is no industrial protocol driver anywhere in the product: no code in it speaks to a PLC, a DCS or a SCADA server.

Writing to the plant

Never. An agent may propose a work order for a person. Writing a setpoint is refused, and the refusal is written down beside the proposal.

The site policy, enforced in code, and a role can only narrow it. python -m auge_plant.roles checks every role against it.

The network

Nothing leaves. The only address the product opens is the machine it runs on, where the language model is.

A sealed run blocks every other address, proves the block works, then runs a full working day on two plants inside it.

What gets installed

Nothing is installed. On Windows it is one folder, unpacked from a zip, with its own Python inside, and an optional local model. Nothing on the plant's own servers.

The whole product runs on numpy and the Python standard library. The Windows zip is built and started on a clean Windows machine for every change we make.

What it leaves behind

Two files in the export folder: the result, and a state file that lets the next run spot renames.

The state file keeps fingerprints of each tag and not the readings, and it is plain JSON, so it can never carry code.

Your security review

Still happens, and anyone who says it does not is wrong. It has much less to cover: no new conduit, no remote access, no data leaving.

In IEC 62443 terms there is no new zone crossing to assess.

Taking it out

Delete the program and the folder. There is nothing on the plant to roll back, because nothing on the plant was changed.

How current it is

As current as the last file in the folder. Point your historian's scheduled export at the folder and the console reads each new file as it lands, within half a minute. New readings on tags it already understands are added without working the plant out again, in milliseconds; it is worked out in full when the tags change and at least every hour. That is live enough for a shift, and it opens no connection. For plants that want live readings there is a read only OPC UA reader: it opens one outbound session to the server the plant already runs, writes into the same folder, and is the one part of this that needs a conduit review.

The watcher checks the folder every 30 seconds; files with the same columns are read as one system, however many of them arrive. The OPC UA reader can only read, by construction.

Moving industrial data is solved. Understanding it is not.

Four layers stand between a machine and anything useful. Other people are good at the second one and we have no intention of competing with them. The third is the one everybody leaves to a person.

THE MACHINESPLCs, sensors, historians, forty years of themMOVING THE DATAOPC UA, Modbus, a PI historian, Litmus, HighByte, a unified namespacesolved, and not by usWHAT ANY OF IT MEANSwhich machine, which quantity, which unit, and what is simply wrongleft to a person. this is usUSING ITagents, models, dashboards, reports, the whole industrial AI shelfwaiting on the layer above

We have no drivers and no plans to write any. The meaning layer is narrow enough that one person can be the best in the world at it, and it is the layer every agent, model and dashboard above it is quietly waiting for.

The best tools in the layer below will match your tags to an asset register. They assume you have one.

Most plants do not. So we work it out instead, from the plant's own naming, and the trick is that a different system knows it in every plant and it is never the one with the most tags. Here a historian writes AL1.ELE.POT003 while the control system writes 31TT0102 for six times as many points. Because the compiler has already decided those are the same machine, the system that knows can tell the ones that do not. A broker carrying all five into one namespace cannot do that, because nothing in it has made the join.

Measured on plants it had never seen: 0.95 and 0.65 against 0.73 and 0.49 for the best you get without it. It over-splits and never wrongly merged two areas. Where no system knows, it says so instead of guessing, and the experiment that tried to fill that gap from the data was falsified and published too.

Back to the front page