HULO reads the sensors, models and operational context a utility already owns, and turns them into one live understanding of the network. What follows is how that is put together, and then what it actually gets you, described as work rather than as features.
Every capability on this page runs on the instrumentation you already have. If your network is too sparsely instrumented for a given claim, we tell you that in the feasibility scan, before you sign, not after.
A utility's knowledge of its own network is spread across six systems that were never meant to talk to each other, and the joining up happens in somebody's head. HULO does that joining once, as a model: your pipes, your valves, your sensors and your history as one set of objects that know about each other. Everything on this page is built on it.
Joined once, so nobody joins them again at the moment a crew is waiting. An event knows the main it sits on; the main knows the valve that isolates it; the valve knows which streets go dry when it is turned.
Most leak software hands you a coordinate and wishes you luck. HULO renders the network itself: the mains, the valve that isolates this section, and the point where the hydraulics stop agreeing with the model.
Pipes, pumps, valves, tanks and sensors on one map, in their real positions, coloured by what they are doing right now. Not a dashboard of charts, the network itself. You can move through time: back into history, and roughly a day ahead.
A leak moves through detection, desktop analysis, survey, classification, dispatch, repair and resolution, as one tracked workflow, not a chain of emails. Investigation is kept separate from repair, because they are different jobs measured in different ways.
Most of what a network does wrong is not a leak. A pump schedule conflicts, a valve is left in the wrong position, demand shifts. These get their own queue, so they neither clog the leak workflow nor get quietly dismissed.
Reliable decisions start with reliable data. Every sensor is checked continuously, and the difference between a broken sensor, a dead pipe and a communications outage is made explicit, because those three demand three different responses. This is also where the honest answer about sensors lives: HULO works on what you already own, and where the network is thin it says so and shows you which sensor would buy the most. Most utilities do add some. None of them start by adding any.
Close a valve, stop a pump, alter the network, in a simulation that never touches live operations. Then see what would actually happen before anyone turns anything.
Operations produce evidence. Evidence produces budget. The reporting layer turns what happened in the network into something a board, a regulator or a rate-payer can be shown.
A new utility starts in setup mode. Sections stay locked until the data behind them is real, because an empty queue that looks like "all clear" is worse than no queue at all.
HULO does not write to your SCADA and cannot operate a valve, a pump or a setpoint. It is read-only by design. That is a real limitation, and it is also the single biggest reduction in the risk you take on by adding us as a supplier. A compromised HULO account cannot turn anything in your network.
What we found, on which network, and what it cost to find it. Roughly monthly, and never a figure we cannot show you the working for.







HULO’s project Lekker (tegen lekken) is co-financed by the European Union, by SNN and by the Dutch Ministry of Economic Affairs.