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 operator view on 4012 , dnp3 on 5022 what it demonstrates pump efficiency as it degrades energy per million gallons drifts up long before anything alarms the fleet view makes the worst station obvious, and the comparison against the others is what turns it into a work order a sanitary sewer overflow, before it is reportable wet well level, pump availability and inflow together say an overflow is coming seeing it while there is still freeboard is the difference between a callout and a fine the compliance report an npdes style report assembled from what was actually measured, rather than transcribed at the end of the month a fleet is why this one is interesting 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 what it puts on litmus edge 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 deploy services water wastewater image us docker pkg dev/litmus customer facing/litmus solutions/water wastewater demo 0 1 0 container name water wastewater demo restart unless stopped ports \ target 4012 published 4012 protocol tcp \ target 5022 published 5022 protocol tcp environment \# fill these in edge url "${edge url }" edge api token "${edge api token }" sim host "${sim host auto}" apply on start "${apply on start 1}" edge verify tls "${edge verify tls 0}" http port "4012" dnp3 port "5022" time scale "60" start hour "5 0" log level "info" edge url=https //10 0 0 5 edge api token=your token sim host=10 0 0 9 docker compose up d open http //localhost 4012 configuration variable default what it does edge url the docker host litmus edge to configure edge api token unset token for that edge or a username and password, or a client id and secret sim host auto address the edge polls to reach this solution apply on start 1 configure the edge on startup edge verify tls 0 1 checks the edge's certificate time scale 60 one real second is a simulated minute, so a full day of diurnal flow passes in 24 minutes start hour 5 0 hour of the day the simulation starts at all nine outstations answer on the one dnp3 port, addressed 1 to 9, which is how a real collection system is usually polled what you see 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 removing it docker compose down 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 support support\@litmus io mailto\ support\@litmus io