Wind-Turbine Alarm Calls: Restart or Hold?
“The alarm is cleared, the SCADA is green, and production is screaming for megawatts. Restart or hold?”
A decision simulator where every scenario has a real economic cost to the safe answer — and the feedback scores the pattern (rising-with-no-inspection vs cleared-with-inspection), not whether production got its megawatts. The HUD keeps wind, temperature, vibration and lost production visible, because that's the desk.
The Audience
Offshore wind control-room technicians and onshore O&M staff making remote restart decisions — plus shift leads calibrating the escalation boundary with the production desk.
Responsibilities
Alarm-pattern analysis · scenario economics (making the wrong call tempting) · feedback design · pressure simulation — decision discipline made playable.
The Build
Pattern-based scenario design · HUD instrumentation · economic tension crafting · AI-assisted drafting (disclosed)
How I used AI in this case
AI drafted alarm-log and production-desk dialogue variants; the pattern taxonomy, scenario economics and scoring logic were authored by me. Edited, verified and disclosed.
The build itself, not a video about it — open it, make the calls, and read what each one costs.
Turbine 7 — Primary Build
The full simulator: four patterns, production-desk voice, pattern-scoring debrief
3D control room and turbine at sea
Start at the operator’s desk, fly out to T-07 at real scale among its string, open the roof or the hub to find the evidence the day crew left, make the call, then watch the consequence: a gearbox that fails, a blade that drifts out of pitch, a jack-up vessel or a crew boat.
Storyboard: 16 frames from the build
Desk to consequence in rendered frames, the eight-case bank, production-desk pushback and the scoring rules.
Why conventional training failed the operational reality
The incident reviews read like the same story with different turbines: a cleared alarm, a production call, a restart — and then the gearbox cascade nobody ordered:
Training taught alarm thresholds. It didn't practice resisting the economic argument when the data is genuinely ambiguous — which is the actual job.
Core diagnostic finding
In the brief, every technician involved could recite the alarm thresholds. The failure was the moment an ambiguous trend met a production call. So the practice has to put money on the screen and score the pattern behind the call, not whether production got its megawatts.
Make safe expensive
Illustrative premise: main-gearbox replacement — crane lead time dominates the bill
Design Constraint → Build Rule: Every scenario prices the safe answer in lost megawatts. If the temptation is not real, the discipline is not either — scenario economics was the core design problem.
Score the pattern, not the outcome
Illustrative premise: cases are holds, and in both the trend or the recurrence decides, not the alarm name
Design Constraint → Build Rule: Rising-with-no-inspection vs cleared-with-inspection: the scoring rewards the decision pattern even when production suffers, because luck is not a skill.
The HUD is the desk
Illustrative premise: is all it takes in the fictional incident pattern: production pressure turns a rising trend into a restart
Design Constraint → Build Rule: Wind, temperature, vibration and lost production stay visible because that is the real decision surface. Removing them would fake the job the trainer exists to build.
A judgment problem under production pressure, not a knowledge gap
Performance problem
Remote restart calls after turbine alarms. In this fictional brief, several incidents followed the same path: an alarm that was cleared or reset, a production desk asking for output, and a restart into a trend nobody had inspected. The technicians knew the thresholds.
Learners and context
Onshore control-room technicians and O&M staff with 1–10 years’ experience who already know SCADA and the alarm bands. Night shifts, so practice has to fit about 15 minutes. Mixed Dutch and English crews, so the build uses plain English.
Is training the answer? Not on its own
- Alarm presentation. SCADA shows the alarm state, but the 20-minute trend is one screen away. Recommendation: put the trend on the alarm card. That is a SCADA configuration change, not a course.
- Escalation boundary. Shift leads disagree on which calls go up. Recommendation: agree a one-page boundary with them before rollout; the trainer then teaches that boundary rather than inventing one.
- Production incentives. If the production desk is judged only on hourly output, pressure will beat any training. This is flagged to the operations manager as a risk. It is outside what L&D can fix.
Alignment: every objective has practice, evidence, feedback and a route back to the job
| Objective | Practice | Assessment | Feedback | Transfer |
|---|---|---|---|---|
| LO1 Decide restart, derate, hold or escalate from the trend and the inspection record | Four alarm cases per shift (one per pattern, from a bank of eight) in random order, with the production at stake on screen | Call scored 2 / 1 / 0. A restart into a rising trend or a recurring fault is a critical error and fails the shift | Immediate and specific to the chosen response. In 3D the consequence plays out on the machine | Shift-handover prompt: name the pattern before any restart |
| LO2 Name the pattern that decided the call | A pattern question after every call. The evidence has to be opened on the part (or the string) before the call unlocks | 1 point per case, scored separately, so a lucky call does not count as competence | Shows the deciding pattern when it is missed | Alarm-pattern card for the control-room wall (job aid in the kit) |
| LO3 Defend a safe call to the production desk with the number, the risk and the next step | Production-desk pushback on the two hold cases, then a written handover note at the end of every shift | Reply scored 1 / 0 (conceding undoes the hold). Note scored 0–6 against a three-part rubric, formative | Explains why rule-only or conceding replies fail; the note is shown against the rubric and a model note | Monthly shift huddle (facilitator guide in the kit); the shift lead marks one real handover note a month with the same rubric |
Evidence register: what is real, what is invented
- Fictional premise The incident pattern (cleared alarm → pressure → restart) and the T-07 string.
- Illustrative values €/day figures, alarm bands and the 8–12 week vessel wait. Chosen to make the trade-off realistic; not field data.
- Design decision The 12 / 14 pass mark and the critical-error rule.
- Not measured Learner scores, reactions, restart behaviour or incident rates. Nobody has used this build in a real control room.
Measurable Performance Objectives
Three objectives. Each produces its own evidence in the build, and the pass rule needs 12 of 14 points with no critical error.
Choose restart, restart derated, hold for inspection or escalate for an alarm case, using the trend and the inspection record rather than the alarm name.
Evidence in the build: the call in each of four cases (2 / 1 / 0), with two critical-error responses.
Name the pattern that decided the call: cleared with a logged inspection, rising trend with no inspection, fault back after a reset, or external cause with the turbine nominal.
Evidence in the build: a separate pattern question after every call (1 point each).
Defend a safe call that costs production, giving the number, the risk and the next step.
Evidence in the build: the reply to production-desk pushback on the two hold cases (1 point each), and a handover note marked against a rubric (formative).
Why This Modality Won (Trade-Off Analysis)
Before committing to the final architecture, we evaluated and rejected lower-transfer alternatives against the workplace constraints:
Cheap, trackable, familiar. Rejected because thresholds were never the failure — every technician in the incidents could recite them. The module would re-teach what the control room already knows and leave the decision moment untouched.
Valuable and honest. Rejected as the core format because hindsight flattens pressure: everyone knows how the story ends, so nobody practices the ambiguity. The simulator restores the uncertainty and the production-desk voice; the reviews remain as the debrief material.
A decision simulator where every scenario has a real economic cost to the safe answer — and the feedback scores the pattern (rising-with-no-inspection vs cleared-with-inspection), not whether production got its megawatts. The HUD keeps wind, temperature, vibration and lost production visible, because that's the desk.
Why scenarios, not thresholds
Practise the conflict, not the recall
The technicians already know the bands, so recall practice adds nothing. Practice has to recreate the conflict: ambiguous data, a price on the safe answer and a person asking for the unsafe one.
Why score the pattern
Separate the call from luck
A restart that turns out fine is not evidence of judgment. Scoring the named pattern separately means four lucky guesses cannot pass, and the debrief can tell a guesser from someone who read the evidence.
Why 3D here
The evidence has a location
The alarm says where to look; the inspection card, the reset log, the pitch mark and the sister turbines decide the call. The 3D scene puts that evidence where it would be on a real machine, makes opening it a required step, and shows what a wrong call does to the turbine and the vessels.
Production Sequence & Traceable Artifacts
The stages below show how the artifacts depend on each other. In this fictional case one designer produced all of them.
What would tell us it worked
A proposed plan, written before any pilot. Nothing below has been measured: the build exists, the learners do not.
| Question | Measure / instrument | When | What we would do with the answer |
|---|---|---|---|
| Can technicians make the call? | In-build score and critical errors per case (the build already computes both) | Pilot with 8–10 technicians | If any case gets more than 30% wrong calls, rewrite its evidence or feedback before rollout |
| Do they name the pattern, or guess? | Pattern accuracy compared with call accuracy | Same pilot | Right calls with wrong patterns means guessing: add a worked example per pattern |
| Does it change restarts on shift? | Sample of restart log entries: share that name a pattern in the handover note | 3 months after rollout | Agree the sampling with shift leads before launch so it is not seen as policing |
| Is production pressure still winning? | Restarts into rising trends, from the incident log | 12 months | Too rare to credit to training alone. Review with the operations manager as an operations measure, not a training KPI |
Instructional Design Takeaway
“Why this form wins: the problem is judgment under pressure with money on the screen, so the solution is a simulator where every safe answer has a price tag — scored on the decision pattern, never on luck.”
Incident reviews kept telling the same story: a cleared alarm, a production manager pushing for megawatts, a restart, a gearbox cascade. The technicians knew every threshold. What they had never practiced was resisting the economic argument under genuine ambiguity. The proposal was a SCADA-style restart/hold simulator: live wind, temperature, vibration and lost-production readouts, four alarm patterns — cleared, rising, recurring, external-cause — and a production desk voice that argues, convincingly, for the wrong call.
Transparent Portfolio Scope
Honest limitation: simplified physics and eight cases, not yet reviewed by a wind O&M expert (the review checklist is in the kit). Real decision support belongs to the OEM’s diagnostic systems; this trainer only rehearses the human call that sits on top of them. Figures are illustrative.