Preventive maintenance for mission critical, from plan to evidence

Each plan links an asset to a checklist template and to one or more triggers: time (every N days), usage (every X hour meter hours, with the projected date calculated from average consumption) and condition (when a metric reading crosses its limit, with the option to require N days in a row out of range). Whichever comes due first wins. Once a day H2O recalculates the next date and, within the lead time you set, opens the work order with checklist, technician and group, by default only for assets in operation. When the work order is solved or closed, the plan restarts the count. Usage and condition triggers need a metric set up on the asset, such as the hour meter, and readings for it.

A plan follows one asset and opens one work order at a time, when the trigger that comes due first is getting close. It works well for a generator by hour meter or a CRAC by reading. The schedule generates all the work orders for a period at once for several assets, using the checklist template's frequency, from daily to yearly or every N days, with dates moved to the nearest business day and estimated hours. It fits the annual schedule you present to the client. Both show up on the Maintenance Calendar, and the next preventive job of each plan appears there before the work order exists.

On the Maintenance tab of the Dashboard: active plans, plans due in the next 7 days broken down by trigger type, late plans and plan work orders completed this month. Below that, the list of what is due in 30 days and what is already late, with plan, asset, checklist, trigger type and technician, the work orders generated by trigger type over the last 90 days, the top 10 assets with preventive and corrective work, and the conditions already past the limit that have not yet reached the required number of days. The dashboard shows only the sites the user's profile can see.

Per asset, from the work orders linked to it and the modality of each one. On the web, MTBF is the average interval between the openings of corrective work orders, and MTTR is the average time between their opening and their solution. Availability subtracts the downtime of corrective work from the time since the asset was registered. The same tab shows MTTF and downtime, with a timeline of preventive and corrective work. For the numbers to be right, each work order has to be linked to the asset and have the right modality, preventive or corrective. An automation rule can set the modality when the work order is opened, including work orders generated by plans. The reliability report brings these KPIs together for all assets by period, in PDF.

Each component is linked to the asset, with an installation date and a lifespan by time, by usage (hours entered on the component) or whichever comes first. The asset shows whether the component is on time, due soon or expired, and keeps the history of every replacement. Component status also appears on the RAT (service report), the checklist and the technical report. A replacement restarts the count, and H2O emails the people you choose when the component becomes due soon or expired.

No. ATG has no partnership with Uptime Institute, and H2O is not certified or endorsed by it. H2O was born inside mission-critical data centers and was used as the maintenance management tool in Uptime Institute® Operational Sustainability audit processes. What it keeps are the records the operation uses to show its maintenance program: the plan, the completed work orders with checklist, photos and signature, and the history of each asset. Using H2O does not guarantee certification or any audit result.

It helps bring the evidence together in one place: maintenance plans and schedules, completed work orders with checklists, required photo per item, GPS on each answer from the app, technician and client signatures on screen, a PDF of each execution, asset history, a log of who changed what and when, instruments with their calibration certificate attached, and checklist audits where a non-compliant item can become an NCR with a ticket linked to the work order. The audit criteria and preparation remain with your team.

You create the patrol from a checklist template where each item points to an asset, with daily, weekly, monthly or on-demand frequency, technician and time. The patrol work order is opened by the daily routine or on the spot with the Execute button. In the app or on the web, the technician marks Done, Not done or NA and enters the readings for each piece of equipment, such as the three-phase voltage of the main switchboard. An out-of-range reading is flagged in the asset history and evaluated by the condition trigger of any plan that uses that metric. For patrols per shift, set up one patrol for each shift.

The reading is classified as low, high, critical low or critical high and is highlighted on the asset chart, with the limit lines. On the Monitoring dashboard, the asset moves to Attention or Critical, and anything without a reading on time shows as Late. If a plan has a condition trigger on that metric, it counts toward opening the preventive job at the daily check. In a checklist, a numeric item outside the tolerance becomes non-compliant and, if the template is set to generate non-conformances, becomes an NCR with a ticket linked to the work order.

Yes. Field work runs offline: tickets, preventive checklists, patrols, switchboard, UPS and thermography inspections, readings, annotated photos, signatures, opening the asset by QR code and the checklist PDF on the device. When the connection comes back, everything syncs. Login and the first sync need a network connection. Plans, schedules, diagrams, dashboards and the full technical report are set up on the web.

Each piece of equipment is an asset with its own fields. For the UPS: kVA, input and output voltages, runtime, number of batteries, battery replacement date and topology. For the generator: voltage, current, power, frequency, phases and engine data. The battery bank is set up as a component with a lifespan by time or by usage. The generator test is a configurable checklist, with a tolerance range on each measurement, photos and signature, and it can have its own plan by date or by hour meter. Transfer time, if you want to record it, goes in as a numeric item in the template. On the web, the generator technical report in PDF includes the diagram of the ATS automatic transfer sequence.

It measures the ticket service SLA: response deadline and resolution deadline, with a business hours calendar. The SLA is set on the ticket manually, by rule or by the site's active contract, with deadlines by priority. Waiting statuses, such as waiting for parts, can pause the resolution deadline. SLA reports show a summary and trends, and a filter lists tickets with a breached SLA. Availability is calculated per asset from the work orders, and the reliability report brings these numbers together by period.

There is a REST API for readings: a gateway, SCADA system or script sends the values identifying the asset (by id or by an external reference registered on it) and the metric. Authentication uses a user's token, and the metric must be set up on the asset. Readings go through the same range classification and feed charts, the dashboard and the plans' condition triggers. Each SCADA system is connected through an integration project with this API.