Gas Gathering System

An upstream gas field, over Enron Modbus. Four well pads, a compressor station, a tank battery and a custody transfer meter run, 121 registers across eight flow computers.

Four scenarios at once, each on a different part of the field, with healthy neighbours beside it so the comparison is on screen rather than remembered.

A loading well does not flow smoothly, it slugs. Those slugs arrive at the tank battery two miles downstream as liquid the level controller did not plan for, so the separator floods and carries over with no fault injected there at all. Nothing links the two in the model; the well pad produces slugs and the separator has to deal with what arrives.

Enron Modbus is the gas measurement dialect of Modbus, and its defining feature is that the address block declares the type. A real flow computer lays itself out this way and a real polling host relies on it:

So 7011 is a flow rate because it is a float in the 7000 block, and every reading on the operator view is labelled with the register it arrived as. What is on screen and what is in DeviceHub are the same address.

One listener serves all eight stations and Litmus Edge tells them apart by RTU station id, which is how a gathering system is really polled: one host, many outstations on one line.

Eight DeviceHub devices on the Enron Modbus driver, 121 registers. Four Digital Twin models across eight instances, which is a better account of this field than one would be: the four pads share a WellPad model, the sales and check meters share a MeterRun because they are the same measurement made twice, and a separator is not a well pad. Four Analytics groups:

The solution ships two ways. Use the registry if the host can reach Google Artifact Registry, and the downloaded archive if it cannot.

Requires a read-only registry credential, supplied by Litmus separately.

Save this as docker-compose.yml:

Or, without Docker Compose, run the same image with the same .env:

Flags given with -e take precedence over .env, so change APPLY_ON_START or EDGE_VERIFY_TLS on the command line rather than in the file.

Open http://localhost:4019.

Download oil-gas-production-demo-0.6.1-amd64.tar.gz from the solution's page on portal.litmus.io. The archive is the container image, not a source bundle, and needs no registry access.

docker load prints the image it added:

That reference is the one the compose file above already names, so the same docker-compose.yml and .env, or the docker run command above, now work offline with no docker login:

To run it without Compose, pass the same three values on the command line:

This solution can also publish its 8 Digital Twins into Litmus Unify, one message per asset under northern-basin/sand-draw/.... It stays off until two things are true: the UNIFY_ values above are set, and the Litmus Edge has a Litmus UNS connector, which the Solutions provisioner can pair in one click. The next apply then publishes the twins, the page header shows how many are arriving, and removing the solution from the Edge removes its branch from Unify as well. Leave the values empty to keep Unify out of it.

Across the top: the field rate, and then three costs stated as a run rate per day rather than a running total. That is deliberate. A total is worth pennies in the first minute of a scenario and reads as "nothing is wrong" while gas is actively venting; a rate is visible the moment something breaks, and "$509 a day" is the number that decides whether to send somebody tonight. The amount accumulated so far sits underneath as the evidence.

Below, the gathering system left to right: the four pads with their wellbores drawn, so the liquid standing in the tubing is something you watch rise; then compression, the separator with its level and dump valve, the flare with a flame that is there or is not, and the two meter runs in series with the difference between them printed underneath.

Faults are the four scenarios above, injected per station, each with a card naming the DataHub topics to watch and what changes about them.

The header carries both controls. Apply to Edge pushes the devices, twins and analytics; it greys out once the solution is on the Edge. Remove from Edge previews first, listing exactly what would be removed and from which Edge, and only then offers to remove it.

The solution removes only what it created. It also records which Edge its apply landed on and removes from that one, so repointing at a different Edge in between cannot leave the first one carrying a solution nobody can see.

The operator view stays on its waiting panel until Litmus Edge is verified to be carrying the field. Every value on the page is read back from the Edge, so a page showing data is itself evidence the chain is working.

Export report produces one self-contained HTML file: the shift's money figures, production by pad against each well's own baseline, the sales meter against the check meter, the separator and the flare. No scripts and no external requests, so it opens offline and prints.

Use Remove from Edge on the operator view, or Clean up in the Solutions provisioner, to remove what it created on the Edge.

[email protected]