Emergency Power for Data Centres: Fuel and Urea Autonomy Designed to LOD 450

When the grid fails, a data centre has seconds of battery and then whatever its generators can do. Everyone designs the generators. The system that decides whether they keep running for eight, twenty-four, or seventy-two hours is the one behind them: fuel storage, fuel transfer, urea supply, buried pipework, filling access, and a documentation set that describes one coherent system rather than a collection of vendor packages. This article explains how that system is designed, using five data centre projects TEBIN delivered in Germany and the Netherlands as design partner to lead engineering firms.
What does autonomy actually depend on?
Autonomy is a number of hours, and it is fixed by four things: how much fuel is stored, how many generators draw on it, what each consumes at the facility’s design load, and what requirement the operator or a standard sets. A design starts by proving that number. On a data centre in the Netherlands, the fuel storage was developed to meet the autonomy required under KIWA BRL-K903, the Dutch assessment guideline for fuel storage installations: 16 diesel tanks with secondary containment and foundations, 8 pump rooms, and 4 filling cabinets, carried from concept to As-Built documentation at RIBA Stage 5.
Sixteen tanks are not one decision made sixteen times. Each tank needs containment volume, a foundation, filling access, and clearances that work with the site’s fire-safety strategy and with the distribution network it feeds. The design pushed toward repeatable arrangements so that sixteen sets of connections behave identically in operation and can be maintained the same way.
Why is the urea system designed like the fuel system?
A modern diesel generator meets its emission limits with selective catalytic reduction, and that process consumes a urea solution, known as diesel exhaust fluid or DEF. When the urea runs out, the engine derates or stops, which makes urea autonomy part of power autonomy. On a data centre in Germany with vertically stacked generators, the LOD 450 detailed design covered 3 × 100 m³ fuel tanks and 4 × 10 m³ DEF tanks with combined pump rooms, so both media share one transfer logic and one maintenance regime.
Urea has properties fuel does not. It crystallises, it is sensitive to temperature, and it is corrosive to some materials that fuel systems use without a second thought. On a separate German project, the execution design placed one 50 m³ urea storage tank with tanker offload and two independent filling points, feeding a modular pump skid that distributes to 22 generator sets. Two filling points are a redundancy decision, not a convenience: a single blocked offload during a long grid outage would cap the facility’s runtime at whatever urea is already in the day tanks.
How does an expansion tie into a live fuel system?
Data centres grow in zones, and each zone arrives with its own generators but not always with its own storage. For an expansion zone in Germany, the LOD 450 design placed 5 × 100 m³ underground fuel tanks and 3 × 10 m³ indoor DEF tanks, and routed a cross-zone urea tie-in that serves 4 generators from storage that belongs to a different zone. A tie-in is where the design discipline shows: the existing system must keep its autonomy and its isolation logic while a new branch is added, and the boundary between zones has to be documented so that operations staff know which valves belong to which system.
Underground storage brings a second discipline into the fuel design. Buried tanks and pipework are exposed to corrosion for decades, so the Dutch project’s scope included cathodic protection for all buried metallic elements and a complete pipe support and bracket system. Supports are part of the system design, not an installer’s assumption: their positions decide pipe alignment, loads, and the sequence in which the network can be installed and maintained.
What does LOD 450 change in practice?
At LOD 450, every pipe, support, valve, and tank is modelled at its real geometry and position. That level of development has a purpose beyond coordination. Repeating pipeline assemblies on the Dutch project were developed as modular prefabrication blocks, fabricated away from the installation area, and prefabrication only works when the design information is stable: dimensions, interfaces, and connection points known in advance. The same coordinated model then served the piping and instrumentation diagrams, general arrangement drawings, isometrics, support drawings, and equipment schedules through every stage to As-Built.
The alternative, resolving routing on site, costs more than time. A fuel system that is improvised during installation is a fuel system whose isolation, bypass, and drainage logic was never designed, and those are precisely the behaviours a facility depends on under failure conditions.
Why does the design have to survive a live facility?
Emergency power systems are not finished when the building opens. They are tested, maintained, extended, and replaced while the facility carries customer load, and that is where the documentation set proves its value. On a data centre in full operation in Germany, TEBIN developed a permanent load bank strategy through HOAI stages LP1 to LP4: a testing concept, integration across redundant electrical paths, load bank locations and busbar routing that minimise the impact on operational space, and updated single-line diagrams. Testing a generator system needs real load, and designing that load in permanently turns testing from a recurring intrusion into a built-in capability.
The same discipline applies to the fuel side. A tank that is filled by tanker every few years, a pump room that is inspected under an operator’s regime, a buried line whose cathodic protection is measured annually: each depends on the As-Built record describing what was actually built. A record that stops at the design stage leaves the next engineer starting from a false picture.
What TEBIN designs, and what it does not
Across these projects TEBIN’s scope ran from concept through LOD 450 detailed design to As-Built documentation, covering fuel and urea storage, transfer and distribution, pump rooms and filling points, cathodic protection, pipe supports, prefabrication engineering, and the full documentation package. Installation, commissioning, and certification against the applicable standards remained with the contractors and certification bodies holding those scopes. The role in every case was design partner to the lead engineering firm, which is how large data centre programmes in Germany and the Netherlands are delivered.
Autonomy is a promise the operator makes to its customers. The fuel and urea system is where that promise is engineered, and it deserves the same level of design as the generators it feeds.
Frequently asked questions
What is fuel autonomy in a data centre?
The number of hours the standby generators can run on the fuel stored on site, at the facility’s design load, without a delivery. It is set by tank volume, the number of generators, their consumption at load, and the requirement the operator or a standard imposes; the fuel system design has to prove it, not assume it.
Why do data centre generators need urea?
Modern diesel generators meet emission limits with selective catalytic reduction, which consumes a urea solution (diesel exhaust fluid, DEF). If the urea runs out, the engine derates or stops. Urea storage and distribution therefore need the same autonomy logic, filling access, and redundancy as the fuel itself.
What does LOD 450 mean for a fuel system design?
A level of development at which every pipe, support, valve, and tank is modelled at its real geometry and position, so that fabrication, prefabrication, and installation can be checked against the model rather than resolved on site.
Does TEBIN install or commission these systems?
No. TEBIN designs them, from concept through detailed design to As-Built documentation where that stage is in scope. Installation, commissioning, and certification are held by the contractors and bodies responsible for them.