Offshore‑Wind Maintenance Lens (Hornsea Two demo)

Synthetic weather. Edits are temporary in this tab; refreshing restores the preset. Export downloads a result file; importing accepts weather only, not a saved plan.

Inputs

What you do here: pick a weather scenario + an O&M “blueprint” (tasks with allowed date ranges), then compute when each task becomes visible (a safe 3‑hour window).

Sea‑state scenario

Seed

Forecast start (UTC)

Days

Window (hrs)

Step (hrs)

Scheduling policy

Doping constraints

Doping adds a discrete “materials/effort” label to each task that changes what transitions are allowed. Here it tweaks wave‑height limits + cooldown.

Interpretation for O&M: higher doping = more delicate/heavy operations → stricter sea‑state threshold + longer setup/stand‑down.

Level	Meaning	Hs max (m)	Cooldown (h)

CT note: operation classes and running state

Each task has a fixed operation-class label. The running state would track time, completed tasks and crew-ready time. The label changes the weather threshold and the cooldown applied after that visit; it is not itself a continuous dimension.

O&M blueprint (editable)

Each row is a task with an allowed interval. The model will pick a 3‑hour safe slot inside the interval.

Preset is based on a Hornsea Two “Notice to Mariners” (non‑routine ops). Routine maintenance is typically not public in this format.

Task	Earliest start (UTC)	Latest end (UTC)	Doping

What the blueprint supplies

The editable rows supply release times, inclusive completion deadlines and operation classes. The program searches sampled start times under the stated visit-duration and single-crew rules. This is a batch scheduling illustration, not a construction of a project state space.

Outputs

–

Tasks scheduled within their allowed intervals

–

Average delay from earliest start (hours)

–

Crew visit occupancy of forecast horizon (excluding cooldown)

Sea‑state forecast (Hs)

Line = wave height. Shading = feasible 3‑hour start times for the selected doping level. Markers = task windows.

Visualise doping

Zoom (days shown)

Scroll start (day offset)

Hs (significant wave height) feasible 3‑hour start task window

Schedule result

For each task: earliest feasible 3‑hour slot inside its interval, given its doping constraints and the chosen policy.

Task	Status	Chosen start (UTC)	Delay (h)	Notes

Progress trajectories

This chart shows the “building going up”: cumulative tasks completed over time.

These are the two computed policy trajectories, not all feasible trajectories or a proof of optimality. Each step occurs when a whole visit finishes.

FIFO policy Opportunistic policy

Tip: Edit the doping thresholds and watch the feasible windows change. Then swap the policy to see alternate trajectories.

Lens statement

Interface idea: separate the context a running system exposes from the forecast and action supplied to its update. This page implements a batch forecast filter and two scheduling heuristics. The interface below explains a possible running-system interpretation; it is not an executable composition engine.

What actually runs here

Fixed parameters: task intervals, operation classes, visit duration and cooldown rules.
Batch input: a complete sampled forecast over a declared horizon.
Batch output: feasible starts and a schedule under the selected heuristic.
“Visibility” means weather eligibility, not observation of a hidden turbine state.

Myers convention: a discrete running-system interface

Write inputs above outputs. For a prospective stepwise version, let S contain current time, completed tasks and crew-ready time. Tasks and rules are fixed parameters. The readout O is the current time, remaining task identifiers and crew-ready time. At o, I(o) supplies a forecast valid for that context together with a proposed wait or visit.

(u, r) : (S / S) → (I / O) r : S → O u : S ×_O I → S r(s) exposes current scheduling context. u(s, forecast, action) validates the proposed action: a valid visit advances to its finish and records crew-ready time; wait advances to the next sample time; an invalid proposal is rejected without changing s.

This is the dependent deterministic convention, not a smooth tangent bundle. Weather eligibility is computed from the supplied forecast and rules; it is not falsely declared to be a readout of a state that excludes the weather. The batch functions below implement the two whole-schedule heuristics directly rather than exposing these maps as reusable components.

Spivak alignment

With a constant input type, the same discrete interface uses a state-only readout S → O and an update S × I → S. The dependent formulation records that forecast/action data are indexed by the currently exposed context. Neither notation by itself proves that the scheduler completes the project or is optimal.

Wiring diagram

A schematic data-flow diagram for the batch implementation. Arrows show dependency, not verified lens composition.

What can be swapped

Synthetic and imported forecasts enter the same declared sampled-data format. Policies and thresholds can be changed while holding imported evidence fixed. These are implemented substitution points; no general lens-composition laws are implemented or claimed here.

Data paths (Met Office + schedules)

Important: the legacy Met Office DataPoint API is retired. If you want Met Office data programmatically, use newer channels like the Met Office Weather DataHub (for many atmos variables) or Met Office marine products / ASDI open data for wave/ocean NetCDF.

What this demo expects

The batch input is a time series Hs(t) on a regular grid with a declared step length. If you have wave NetCDF, convert a single regular-grid series to the JSON format below. CSV is not accepted.

Paste/import your own Hs time series

Import replaces active weather only after validation; rejected data leave the prior result unchanged.

Python helper snippet (xarray) — converts NetCDF to this demo format

Why bundle‑over‑orientation matters for real data

In the prospective running-system interface, inputs live over the exposed scheduling context. A forecast must cover the visit interval at that context. This batch app instead imports one complete series, validates its uniform time grid and reuses it for both policies.

Schedule ingestion notes

The preset “Hornsea Two” tasks are taken from a Notice to Mariners (non‑routine operations). These notices often give: a start date, an estimated duration (or end date), safety zone notes, and sometimes coordinates.

Suggested next step if you want richer schedules

A richer schema could add assets, resource pools and constraints. A future implementation would need explicit interface maps and tests before claiming that CMMS, vessel and forecast components compose correctly.

Scope of the current model

The blueprint is supplied, not derived. This program computes two schedules from it; it does not enumerate the full reachable state space or generate every valid completion policy. An unscheduled task means this heuristic did not allocate it, not a proof that no feasible full schedule exists.

Export format

The “Export output JSON” button writes:

Assumptions & caveats

This is a toy model for concept validation, not an operational safety tool.
Weather here is synthetic unless you paste real data.
Sea‑state constraint is simplified to a single threshold on significant wave height Hs.
Tasks are simplified to “needs one 3‑hour visit sometime inside an allowed interval.”
One crew is occupied for the whole visit and its following cooldown. These are invented toy rules, not operational Hornsea limits.
Each Hs sample is held constant over its following step interval. Every sample interval touched by a visit must be present and below the limit; no between-sample weather inference or safety assurance is made.
Completion at the stated latest end is allowed. Starts are restricted to the forecast grid.

Extending to a richer open system

Add inputs: wind gusts, visibility, daylight, vessel class, crew limits. Add outputs: cost, risk, expected downtime. Then change the doctrine from deterministic to monadic (stochastic) to represent uncertainty, as in Myers’ discussion of monadic doctrines.

What’s “visibility through a 3‑hour window”?

Imagine a sliding 3‑hour slot over the forecast. When the sea state stays under your limit for the whole slot, the task is “visible” / feasible.

Practically: crew transfer or a delicate lift can require sustained conditions, not just a momentary lull. The forecast filter computes sampled start times whose whole selected window meets the limit.

Formal output type

The derived batch output is a Boolean flag per sampled start. It is true only when the entire selected visit window is covered by consecutive forecast intervals and every touched interval has Hs ≤ the task threshold. This is a function of forecast plus rules, not the state-only readout in the interface sketch.

Quick glossary

Hs: significant wave height (meters).
Lens: a pair of maps organising “expose” and “update”.
Open dynamical system: has internal state and an interface (inputs/outputs) to its environment.
Doping (here): a discrete constraint level that changes allowable transitions.

Sources used for the demo preset (links)

Hornsea Two wind farm headline facts (turbine count, rating, location): Siemens Gamesa press release (2018) — link
Hornsea Two non‑routine O&M activities (blade replacement, cable repair, drone ops): Hornsea Two Notice to Mariners (June 2025) — link
Met Office DataPoint retirement notice: link
Met Office marine wave data products (AMM15 WAV) via UKMCAS FTP/SFTP: link
Met Office NWS Wave model open data (AWS/ASDI listing): link
AMM15 wave product sheet (file format / naming): link

Lens theory framing follows Spivak (lenses) and Myers ((Bun,T)-dynamical systems).