Scheduling inspections when the clock is fired hours, not the calendar
In a gas or combined-cycle plant, most inspection intervals are not measured in months. They are measured in equivalent operating hours, factored fired starts and thermal cycles — counters that live in the historian, not in the maintenance system. A scheduling module has to consume those counters, take the earliest of several competing due dates, and hold that logic intact through a migration off the legacy system.
The scheduling problem in a combined-cycle plant is that three clocks run at once and none of them is the wall clock. The gas turbine accumulates fired hours and factored starts, and OEM intervals for combustion, hot gas path and major inspections are written against both — typical tables sit near 8,000 to 12,000 equivalent operating hours or roughly 400 to 450 factored starts for a combustion inspection, whichever arrives first. The HRSG accumulates thermal cycles the turbine counter does not see. Balance-of-plant vessels and relief devices run on jurisdictional calendar dates under NBIC NB-23 and state boiler law. A plant that moved from baseload to two-shifting to follow renewables burns through the starts-based interval years before the hours-based one, and a legacy system that stored only a calendar due date will never show it. Migration is where that defect becomes visible, because you have to state the basis out loud to move it.
Source: Written against ASME Boiler and Pressure Vessel Code Section I for HRSG and power boiler pressure parts, ASME B31.1 for power piping, API 510 and NBIC NB-23 for balance-of-plant pressure vessels and in-service repair, ASME Section V for examination method requirements, and ASNT SNT-TC-1A for personnel qualification — with OEM equivalent-operating-hour interval tables, EPRI flow-accelerated corrosion program guidance, and RTO/ISO planned-outage coordination timetables treated as the scheduling drivers.
| Asset or scope | Interval basis in the source system | Driver the new system must read | What the migration usually loses |
|---|---|---|---|
| Gas turbine combustion inspection | Equivalent operating hours OR factored fired starts, whichever comes first | Live fired-hours and starts counters from the DCS historian, with maintenance factors applied | The starts counter entirely — legacy record kept only the hours-derived date |
| Gas turbine hot gas path / major | EOH and factored starts, with trip, peak-fire and fuel-switch factors | Same counters plus the trip log that inflates counted starts | The maintenance factors, so the recomputed date is optimistic by a full season |
| HRSG HP superheater and reheater stub welds | Thermal cycles and start type (cold, warm, hot) | Cycle counter and start classification, not turbine EOH | Any cycle basis at all; the HRSG inherits the turbine's date and is under-inspected |
| HRSG LP evaporator and economizer (FAC) | Condition-driven: chemistry, dissolved oxygen, velocity, geometry | Prior UT thickness history at fixed CMLs, plus water chemistry excursions | CML identity and reading history, which resets every remaining-life calculation |
| Balance-of-plant pressure vessels | Calendar interval under API 510 / NBIC NB-23 and state boiler law | Jurisdictional certificate dates and the last internal or on-stream date | The distinction between a jurisdictional date and an OEM date — both become 'due' |
| Pressure relief devices | Calendar interval set by jurisdiction and service severity | Certificate expiry and last bench-test date per valve serial | Valve serial identity when devices were rotated between spares |
Why the wall clock is the wrong primary key
A planner arriving from refining expects an inspection plan keyed to dates, because API 510 and API 570 express intervals in years with a half-remaining-life ceiling. A combined-cycle plant does not work that way. The gas turbine's OEM maintenance schedule is written against equivalent operating hours and factored fired starts, and the governing interval is whichever counter reaches its limit first. The steam turbine carries its own hours-based major. Only the balance-of-plant vessels, the relief devices and the jurisdictional boiler certificate genuinely run on the calendar. A schedule holding dates alone has discarded the thing that generates the dates.
The distinction stops being academic the moment dispatch changes. A unit commissioned for baseload in 2012 that now two-shifts to firm a renewable-heavy grid accumulates starts several times faster than its design case while accumulating fired hours more slowly. Every maintenance factor in the OEM table — trips from load, peak firing, fuel switching, water or steam injection — inflates counted starts further, so a single trip can be charged as the equivalent of several normal starts. The hot gas path inspection the legacy system places four years out may in fact be due next spring, and nothing in the record says so.
This is why the migration question and the scheduling question are the same question. To move a due date correctly you have to move the rule that produced it: the counter it reads, the limit, the maintenance factors applied, the completion event that last reset it, and the authority for any approved deviation. If the new system can only accept a date, you have not migrated a program. You have migrated a photograph of one, and it begins decaying on the day you go live.
Three counters, one due date, and the exam that governs
The scheduling engine has to hold several concurrent interval rules against a single asset and resolve them to one governing date. That means an interval is a record with a basis (hours, starts, cycles, calendar), a limit, an accumulation source, a factor set and a reset event — not a number of months. It also means the user interface has to say which basis is governing today, because that is the piece of information a plant manager needs when deciding whether to pull a combustion inspection forward into an approved window rather than take an unapproved outage six weeks later.
The HRSG is where this most often fails, because the HRSG is not on the turbine's counter and is routinely treated as one line item. It is not one item. The finishing superheater accumulates creep damage on hours at temperature. The HP superheater and reheater tube-to-header stub welds accumulate thermal fatigue on cycles, and a cold start damages them far more than a hot restart. The LP evaporator and economizer thin by flow-accelerated corrosion on a chemistry-and-geometry basis that no counter sees at all. Three mechanisms, three bases, one asset tag in the legacy system.
There is a straightforward way to test a vendor on this. Ask them to configure one asset with three concurrent bases, then change the projected annual start count from 80 to 300 and show you which examinations move and by how much. If the answer requires a consultant to rewrite the data, the product is a calendar with an asset register bolted to it, and it will not survive the first year of a changed dispatch profile.
What a legacy migration actually has to carry across
A defensible migration moves nine things per inspection task, not one. The last completed date and its result. The interval rule with its basis and limit. The counter reading at the moment of completion, which is what makes the next date reproducible. The procedure identifier and revision used. The technicians and their certification status on that date. The instrument and its calibration status. The finding and its disposition. Any approved deviation, extension or exemption, with the name of the person who approved it. And a provenance marker recording which legacy extract the record came from.
The arithmetic trap sits in the sixth of those. If you import only the next-due date, you freeze a wrong number. If you import only the last-completed date and recompute, every date shifts unless the new system reproduces the same maintenance factors the old one applied — and legacy systems frequently applied them by hand in a spreadsheet that was never migrated at all. The correct approach is to import both, recompute, and reconcile the difference. Do not resolve the disagreements in bulk. Each one is a finding about the old program.
Keep the legacy extract immutable. Hash it, store it, and point every migrated record at its source row. Two years later a jurisdictional inspector or an insurer will ask how you know a particular vessel's last internal was performed when you say it was, and the answer needs to be a retrievable record with a chain back to the system that produced it. Plants that skip this step spend the following audit reconstructing history from personal recollection and archived email.
Thickness histories are the part that migrates worst
Legacy systems in power plants habitually store thickness readings inside work-order text fields, in attached PDFs, or in per-outage spreadsheets that live on a network drive under the contractor's name. The consequence is that condition monitoring locations lose their identity. A CML is only useful if the same physical spot can be re-measured, which requires a stable identifier, a nominal thickness, a minimum required thickness, the grid position and the full reading history. Without that identity, every remaining-life clock in the plant restarts at zero on migration day.
Two arithmetic traps follow. First, if only the most recent reading survives, the long-term corrosion rate is gone and the system falls back to a conservative default interval, so you over-inspect assets that were stable and under-inspect the one that was moving. Second, if two surviving readings were taken with different probes, couplant conditions or a different surface preparation, the computed rate can come out negative. Most systems discard negative rates silently, which drops the CML out of the due-date engine entirely — an asset that appears clean because it has vanished from the calculation.
What to demand from the new system is that CMLs are first-class records with a full reading history including date, technician, instrument, temperature compensation and a repeatability flag for readings whose comparability is not established. Then run the remaining-life calculation in both systems on the same sample of fifty CMLs, and do not cut over until the two agree or until every disagreement is explained. This is a two-day exercise that prevents a two-year credibility problem.
Outage windows you do not control
A refinery decides its own turnaround dates within commercial constraints. A merchant power plant does not. Planned outages generally have to be submitted to the market operator and approved, lead times for major work run months ahead, and an approved window can be moved for grid reliability reasons after crews, cranes and long-lead parts are already committed. Capacity obligations add a second constraint, because taking the unit down in the wrong period carries a commercial penalty that dwarfs the cost of the inspection scope being scheduled.
This means the outage window is an object in the schedule, not a date range typed into a task. It has a status — requested, approved, revised, cancelled — an owner, and a dependency graph hanging off it. When the operator shifts the window three weeks, every examination bound to that window shifts with it, and the module must immediately flag the subset that now exceeds a jurisdictional or code interval rather than letting them follow along quietly. That flag is the difference between a managed extension with documented approval and an expired certificate.
The same structure supports the decision that actually saves money. If the counter forecast says the hot gas path inspection lands eleven weeks after the next approved window closes, the plant has a real choice: pull it forward and lose some residual life, or run to the limit and seek a window that may not be granted. Software that shows counter trajectories plotted against approved windows turns that into an analysis. Software that shows a list of dates turns it into an argument.
Crews, access and the predecessor chain
Time on tools is a small fraction of an outage window. Before a technician touches a stub weld, someone has erected scaffold, removed and later reinstated insulation and lagging, cooled and isolated the system, hung locks, issued a confined space permit for drum or duct entry, and arranged lighting and ventilation. Where the exam is on the HRSG's high-temperature headers, weld preparation and surface conditioning add more. A scheduling module that books the examination without modelling those predecessors produces a plan that is wrong by days and a crew that stands idle at cost.
Crew qualification is the second constraint and it is stricter than most modules assume. Under ASNT SNT-TC-1A, certification is granted by the employer under the employer's own written practice, so a contractor's Level II is certified by the contractor, not by you, and the record needs to name the certifying employer. Method alone is insufficient: phased array and TOFD require demonstrated qualification against the specific procedure and the specific configuration, and the near-vision and colour-contrast examinations carry their own expiry dates independent of the certification itself.
The evaluation question here is blunt: ask the vendor to assign an expired Level II to a scheduled examination in front of you. A module that accepts the assignment and only complains when the report is filed is not a control, it is a log. What you want is a hard block at assignment, an override that requires a named approver and a reason, and a report that lists every override taken in the last twelve months. That report is the one an auditor will ask for.
Evaluating a scheduling module while you are mid-migration
Five demands separate a system that will hold from one that will not. It must store an interval as a rule with an explicit basis rather than as a number of months. It must recompute a due date as of an arbitrary past date, so you can answer what the schedule said on the day a decision was taken. It must carry provenance from the legacy extract. It must maintain an exception queue rather than resolving migration conflicts silently. And it must keep jurisdictional intervals and OEM intervals as separate, separately reportable classes, because they answer to different authorities.
The acceptance test is not the demo. Run both systems in parallel through one full outage cycle and treat the reconciliation report as the deliverable: every asset where the two disagreed, why, and which one was right. Plants that do this find between five and fifteen percent of their inspection tasks carried a defective basis in the legacy system — usually a starts-based interval recorded as an hours-based one, or a jurisdictional date confused with an OEM date. Finding those is the return on the migration, independent of the software.
Atlantis builds inspection scheduling on an Odoo ERP foundation configured for NDT organisations, with interval rules, counter integration, crew certification control, CML history and outage-window dependencies as native objects rather than custom fields. It is affordable, accessible and fully customizable, and the migration reconciliation described above is how we prefer to start. For a demo against your own legacy extract, contact info@atlantisndt.com.
Why can a combined-cycle plant not just schedule inspections by date?
Because the events that consume asset life are fired hours, factored starts and thermal cycles, not elapsed months. A unit that ran 4,000 hours as baseload and a unit that ran 4,000 hours across 600 two-shift starts are in completely different maintenance positions. Date-based scheduling averages those two cases into one wrong answer, and the error grows every time dispatch changes.
What is the min() problem in turbine inspection scheduling?
Each major turbine inspection has at least two competing limits — an hours limit and a starts limit — and the exam is due when the first of them is reached. The schedule must evaluate every basis, take the earliest result, and display which basis is governing. Systems that store one due date per task cannot express this, so they quietly track whichever basis was entered first.
What breaks when you import due dates instead of interval rules?
You freeze a snapshot. The imported date stops responding to the counter that produced it, so a change in dispatch, a run of trips or a fuel switch never moves it. Six months after go-live the schedule is confidently wrong and nobody can tell, because the record no longer contains the basis, the limit, the maintenance factors or the completion event that reset the clock.
How should a migration handle disagreement between old and new due dates?
Import both the legacy next-due date and the recomputed next-due date, compare them, and route every asset whose values differ by more than a stated tolerance into an exception queue for engineering review. On a two-unit plant that queue is usually a few hundred rows. It is the single most valuable output of the migration, because each row is a place where the old program was already wrong.
Does an RTO or ISO outage approval belong in the inspection schedule?
Yes, as a first-class object. A planned outage generally has to be submitted to and approved by the market operator, and it can be moved for grid reasons after you have booked crews. Model the outage window as a container with a status, bind exams to it, and cascade every date when the window moves — flagging any exam that then exceeds a jurisdictional interval.
Is API 510, 570 or 653 inspector training part of this offer?
No. Atlantis supplies inspection management software, reporting software, digital twins, ASNT Level III consulting, report validation, and NDT training to ASNT SNT-TC-1A and ISO 9712 across UT, RT, MT, PT, ET, VT, PAUT and TOFD. API inspector certification is administered by API through its own providers. The scheduling module tracks the validity of certifications your team already holds and blocks assignment when one lapses.
Built for any business that runs on operations
Most companies do not fail at their craft. They lose time, margin and goodwill in the gaps between the tools they use to run the place — a quoting spreadsheet that does not talk to the job sheet, a job sheet that does not reach accounts, and a compliance folder nobody can search when a client asks. Atlantis closes those gaps by putting the whole operation on one platform, so information is entered once and everything downstream stays in step.
What you can run on it
- Sales and CRM — leads, quotes, follow-ups and the pipeline that tells you what next month looks like.
- Projects and job costing — plan the work, track the hours and materials against it, and see the margin while the job is still live rather than at final account.
- Field and service teams — dispatch, schedules, mobile capture that works with no signal, and sign-off from site.
- Inventory and purchasing — stock, suppliers, reorder points and goods receipt, joined to the jobs that consume them.
- People — records, qualifications and licences with renewal reminders, timesheets, leave and payroll.
- Quality and documents — procedures and forms under revision control, with the audit trail an inspection or accreditation body actually asks for.
- Accounts — invoicing, expenses, multi-currency and the reporting your accountant stops chasing you for.
Affordable, accessible, fully customizable — and we mean each word
Affordable because the whole suite is included rather than sold to you a module at a time, and because implementation is done by people who have run operations rather than by a chain of subcontractors. Accessible because it runs in a browser and on a phone, works for a small team on day one, and does not need a specialist on staff to keep it alive. Fully customizable because your process is the thing that makes you competitive — the software should bend to it, not the other way round.
Industries we configure for
Service businesses and contractors, manufacturing and fabrication, trading and distribution, laboratories and testing houses, engineering consultancies, construction and facilities, and asset owners across energy, marine, aerospace and infrastructure. Inspection and testing is where we started, and it remains the sector we go deepest in — but the platform underneath is general-purpose, and most of what it does has nothing to do with inspection at all.
What happens when you get in touch
A short conversation, not a sales sequence. We ask how the business runs today and where it hurts, show you the platform doing that work, and send a written quote shaped to your region, your team size and the scope you actually need. No obligation, nothing to install first, and no pressure to decide on the call. Reach out and tell us what you are trying to fix.
Related: business management platform · inspection management software · choosing the right category of software · modules · by industry · asset integrity platform. Book a free consultation.