Nuclear Refueling Outage Software: Why the Schedule Slips at 2am on Day Nine

Why the outage schedule is not really a schedule

Day nine of a refueling outage, 2am. The published schedule says a valve overhaul in a contaminated area starts now. In practice it cannot, because the clearance order that isolates it has a conflicting tag from another job that ran long, the radiation work permit for the area was written for a different scope than the one that actually got discovered when the insulation came off, and two of the four craft qualified for that specific procedure are three hours into a shift on a different job in another building. None of that is in the schedule. All of it is in four people's heads, and they resolve it in the 5am meeting.

The tooling is usually a scheduling product holding tens of thousands of activities, a work management system of record holding the work orders, a clearance and tagging system, a radiation protection system holding permits and dose tracking, an access and qualification system for the contract workforce, and a printed schedule that goes stale the moment it leaves the printer. Each system is doing its job. What no system holds is the actual constraint graph, which is the reason the schedule and reality diverge from about day three onward.

The financial shape of this is brutally simple. Every day the unit is offline costs seven figures in replacement power, and the outage duration is decided by the accumulation of small sequencing failures rather than by any single event. A station that recovers half a day per outage through better sequencing has paid for a software program several times over, and everyone in the room knows it, which is why outage software conversations happen at director level.

Problem 1: the scheduler levels resources, the plant obeys the licensing basis

Oracle Primavera P6 is a serious scheduling tool and most stations use it well. What it models is activities, durations, logic and resources. What governs a nuclear outage is a different set of objects: technical specification limiting conditions with allowed completion times, shutdown safety function availability, clearance orders and their tag conflicts, contamination and radiation zone access, fire protection compensatory measures, and configuration control on systems that are partly disassembled. Those constraints do not exist in the scheduling model, so they are enforced by experienced people in meetings.

Hitachi Energy Asset Suite is the work management backbone at many stations and it holds the work orders properly, but work management and constraint-aware sequencing are separate concerns and it was built for the first. IBM Maximo is a strong maintenance management system with an asset and work order constraint model rather than a licensing basis one. None of these products is deficient. They were simply built for a world where the binding constraint is resources, and in a refueling outage the binding constraint is permission.

A custom layer makes the constraint graph explicit alongside the schedule. A work order carries the clearance it requires, the radiation work permit scope it falls under, the zone it occupies, the qualifications the craft need, and the plant configuration state it depends on. Then the sequencing engine can answer, at 2am, which of the fourteen ready jobs can actually start right now, in what order, and which single clearance release unlocks the most downstream work. That question is currently answered by the best-informed person awake.

Problem 2: emergent work reorders everything and the field is reading yesterday's print

Insulation comes off and the scope changes. A valve that was a repack becomes a replacement. An inspection finds indications that add a work package nobody planned. In a large outage this happens continuously, and each occurrence ripples through the sequence in ways the daily republished schedule captures partially and late.

The consequence is not that the schedule is wrong, everyone expects that. The consequence is that the field is working from a document that was true at 4am, so craft arrive at jobs that cannot start, wait for clearances that were reassigned, and burn hours in a radiological area for no product. Those hours are also dose, which makes it a radiation protection issue and not only a productivity one.

A custom layer treats emergent work as a first class event with a triage path: scope captured where it was found, constraint requirements identified immediately, impact on the critical path computed rather than estimated, and the affected crews notified on a device rather than in the next meeting. The measurable win in the stations we have worked with is not schedule optimisation, it is the reduction in crews standing at a job they cannot start. That is the cheapest half day a station will ever recover.

Problem 3: thousands of contract workers, and the constraint is qualification, not headcount

An outage brings in a temporary workforce many times the size of the permanent staff. Each person has a set of qualifications, medical and respiratory clearances, radiation worker training with expiry dates, unescorted access authorisation, and site-specific procedure qualifications. The schedule shows craft counts. The reality is that a specific job needs a specific qualification combination and there may be six people on site who hold it.

When schedulers plan against headcount and the field discovers a qualification gap at shift turnover, the job slips, and it slips at the worst possible time because everything downstream was planned around it. Qualification and access data lives in a separate system, so the scheduler simply cannot see the constraint they are violating.

A custom layer joins qualification and access state to the sequencing model, so a job cannot be scheduled into a window where no qualified and cleared person is available, and so an expiring training qualification surfaces as a schedule risk days before it becomes a stoppage. It also makes shift turnover a data handoff rather than a verbal one, which matters when the incoming shift supervisor has to reconstruct why the previous twelve hours went the way they did.

What a custom outage build has to include

• A constraint model per work order covering clearances, radiation work permit scope, zone access, required qualifications and plant configuration dependencies, sourced from the systems that own each.
• Read integration with the work management system of record and the scheduling product, with the custom layer sequencing rather than replacing them.
• A ready-to-work engine answering which jobs can start now and which single constraint release unlocks the most downstream work.
• Emergent work capture in the field, with constraint identification and critical path impact computed at the point of discovery.
• A field-facing current view on a device, replacing the printed schedule, designed for a plant environment with poor connectivity and gloved hands.
• Qualification, training expiry and access state joined to the sequencing model for the full contract workforce.
• Post-outage forensics: an immutable record of what was planned, what changed, when and why, so the next outage plan is built from evidence rather than recollection.

What it costs and how long it takes

From the industrial scheduling and asset work Digital Heroes has delivered, this is the shape. A first release covering the constraint model, integration with work management and scheduling, the ready-to-work engine and a field view runs $120,000 to $250,000 and ships in 16 to 24 weeks. A full platform adding workforce qualification integration, live critical path recalculation, milestone and window management and post-outage forensics runs $350,000 to $800,000 phased over 12 to 18 months.

Nuclear specific cost drivers, and these are larger than in any adjacent industry. Software quality assurance expectations, because a station applies controls that commercial software projects do not, and even non-safety-related applications carry documentation, verification and configuration management obligations your quality organisation will define. Cyber security and network segmentation, since anything reading plant systems has an architecture review with real duration. Integration access, because the clearance, radiation protection and access authorisation systems are each owned by a different organisation with its own change process. And the licensing question, which is not ours to answer: whether any part of the scope touches the licensing basis is a determination your licensing organisation makes, and it changes the project fundamentally if the answer is yes.

What keeps cost down: scoping strictly to the non-safety-related sequencing and information layer, reading from systems of record rather than writing to them in the first release, and piloting on one outage window with one department before station-wide rollout.

Build versus buy, and where the line sits

Do not build if your station runs short outages with a stable, largely permanent workforce and your existing scheduling discipline is producing outcomes you are satisfied with. Do not build a replacement for your work management system of record under any circumstances, and be sceptical of anyone who suggests it. Asset Suite and Maximo hold the work order record for good reasons and the migration risk is disproportionate to any benefit.

Build the layer when two or more of these are true. Your outages routinely lose time to crews arriving at jobs that cannot start. Emergent work reordering is managed verbally and the field is working from printed schedules. Qualification and access constraints are discovered at shift turnover rather than during planning. Nobody can explain, after an outage, where the duration actually went, so each outage plan is built from the last one plus optimism. Or you are a multi-unit fleet and cannot compare outage performance across stations on a common basis.

Our position: in nuclear, the value is in the information layer and the constraint model, not in replacing anything. The systems of record stay. What gets built is the thing that answers, continuously and correctly, what can start right now.

How to choose a developer for outage management software

Ask them what they would do if a clearance order and a radiation work permit disagree about a job's readiness. A developer who has worked in this environment will say the system surfaces the conflict to a named human and does not resolve it automatically. A developer who describes an automatic resolution rule has not understood where authority sits in a nuclear station.

Ask how they will work with your quality assurance organisation. The right answer includes asking, early and directly, what software quality requirements apply to a non-safety-related application at your station and building the documentation and verification approach around that answer rather than discovering it in month six.

Ask what they will read and what they will write. In a first release the answer should be read-heavy: read the work orders, read the clearances, read the permits, write only within the custom layer. A vendor eager to write back into plant systems on day one is optimising for a demo, not for your change control process.

Ask who owns the code, the infrastructure and the integration configurations, and settle it in writing before kickoff. At Digital Heroes the client owns the repository from the first commit, and in a regulated environment that ownership is what allows your own organisation to audit and control what is running. A concrete first step: take the last outage and count the crew hours spent at jobs that could not start when the schedule said they could. Most stations have never measured it, and the number is the business case.