Collection system

A regional wastewater collection system: eight unmanned lift stations feeding one water reclamation facility, on DNP3. Nine devices and 274 tags, and the largest tag count of the set.

Litmus Edge Manager manages Edges rather than devices, so a fleet of RTUs behind a single Edge is invisible to it. This solution is therefore designed to be split across two Litmus Edges managed from one Litmus Edge Manager, one per district, with a shared lift station Digital Twin model authored in LEM and pushed to both.

It also runs against a single Edge, which is the simpler setup and what the compose file below does. The two-district arrangement is worth showing when the question is fleet management rather than a single plant.

Nine DeviceHub devices, eight lift stations and the treatment works, with 274 tags over DNP3. A shared lift station twin model with an instance per station. Analytics groups behind pump efficiency, overflow risk and permit compliance.

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:4012.

The page stays on its waiting panel until the Edge carries this solution's devices. That is deliberate: the simulation does not tick and no value is shown until Litmus Edge is verified to hold the devices and poll them, so nothing on screen can be mistaken for data that never made the trip. With APPLY_ON_START at its default of 1 the solution configures the Edge itself on startup, which takes 30 to 60 seconds. If you set it to 0, or the apply failed, press Apply to Edge in the page header.

Download water-wastewater-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:

All nine outstations answer on the one DNP3 port, addressed 1 to 9, which is how a real collection system is usually polled.

This solution can also publish its 9 Digital Twins into Litmus Unify, one message per asset under litmus/water-utility-01/.... 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 fleet: worst station energy, overflow events, permit compliance and stations at risk.

Below, the collection system itself. Each lift station shows its wet well level against the lag, on and off setpoints, which pumps are running, and the flow down the trunk main to the treatment works.

Because the clock runs at 60x, the diurnal flow pattern is visible in a few minutes: the morning peak fills the wells, the pumps cycle harder, and the energy per million gallons moves with it.

Faults include a pump losing efficiency, a blockage, a wet well level sensor drifting and a storm inflow.

Use Clean up in the Solutions provisioner to remove what it created on the Edge. In the two-district arrangement, cleaning is scoped per site so one district can be removed without touching the other.

[email protected]