Research — Generation · Precomputed (draft, unvalidated)

One fault, three categories

One voltage dip, three Categories of distributed energy resource. Drop the voltage to 0.65 pu and hold it: for the first seconds all three are required to ride through, then Category I is permitted to disconnect, then II, and III is still required to stay on. A playhead crosses each Category's required seconds on a log time axis and the marker sits exactly there. Then the post-event cards: cease-to-energize, return-to-service delay, restore time and reactive support. Seven stories, or switch to free play and set frequency, rate of change, phase jump and unbalance events on the exported values.

Mode

Story plays a prepared disturbance step by step. Free play is yours: every control snaps to an exported value.

Story

Free play · pick a disturbance, then set it on an exported value

Every control sits on a value the harness was run at; the page looks that cell up and never estimates between two. On the voltage chart, press on a dot or drag with a mouse: the event snaps to the nearest exported dot. The Category column is part of every view, but only the voltage and the ROCOF floors differ by Category in the harness; frequency, phase jump, unbalance, cease-to-energize, return-to-service and restore-output are the same for all three.

One disturbance, three Categories · each DER is either required to ride through or permitted to disconnect

required to ride throughpermitted to disconnectno zone breachedWaveform and DER symbol: illustrative, not a harness outputDraft, unvalidated harnessCategory ICategory IICategory IIIdarker shading = more Categories required to ride through

What the harness floors say at this event · permission, not a prediction

Check being read · click a unit or card on the drawing, or a row below

Actual

Required

Margin

How the harness read it · its own words, verbatim

    Every check at this step · the highlighted row is the one this step changed

    Click a row to read that check. Event rows show the outcome (and what the function answered); post-event rows show the real verdict and margin. There is deliberately no overall verdict.

    Notes on every result · shown even when nothing is close to a floor

    Every check · before, after, and after the fix

    Event cards are coloured by outcome (required to ride through, permitted to disconnect, no zone breached), never as pass or fail. Post-event cards carry the function's own pass, fail, incomplete or not-applicable verdict; incomplete is never a pass. The 'What changed' column compares the exported results across the three columns; the page does not decide anything.

    Precomputed results:every verdict, required value and margin on this page was computed by the real Python harness at export time and is played back from a data file. The page runs no harness logic and holds no standards tables, and it never interpolates between exported values. Not a live API call. Precomputed from the Python harness: ugm-agent-harness (recorded commit a1507b2), a draft with no subject-matter-expert sign-off. Nothing here is a compliance determination. What the eight functions do: each compares a DER's demonstrated capability to a floor or ceiling; none takes a grid event and decides whether a DER disconnects. For each event the export asks every function one question, "if a DER disconnected at this point, would that be compliant?", and the answer is the card. A function result of fail means the floor requires riding through; pass means a disconnection is permitted. That is permission, not a prediction. Which zone or tier an event falls in, and where the timeline marker sits (the zone's required seconds, the earliest permitted disconnection), is the demo's own reading of the harness table (tagged demo logic), and a level that breaches no zone calls no function. The waveform and the DER symbol are drawn here and are not a harness output. The measured values on the post-event cards (cease time, return-to-service delay, restore time, reactive-support duration) are illustrative scenario inputs; the verdicts are the functions'. The harness's utility-override tables for cease-to-energize and return-to-service are empty: any override on this page is synthetic and labelled "demo override (illustrative)". Only the voltage and the ROCOF floors differ by Category in the harness; frequency, phase jump, unbalance, cease, return-to-service and restore output are the same for all three. The Category III voltage ride-through times were corrected after sources disagreed and are the harness's highest-priority item awaiting human review. IEEE 1547-2018 is paywalled: the ride-through ingestion is secondary-source and the subclause numbers are single-source.Real functions this maps to:check_der_voltage_ride_through_zone, check_der_frequency_ride_through_zone, check_der_rocof_ride_through, check_der_voltage_phase_jump_ride_through, check_der_voltage_unbalance_ride_through, check_der_cease_to_energize_time, check_der_return_to_service_delay, check_der_restore_output_timing.Not modeled: a DER model or any prediction of whether a real inverter disconnects (the floors give permission, not behaviour), grid dynamics, protection and anti-islanding detection, voltage zones above nominal in the events (the overvoltage zones are in the chart table but this demo drives dips only), a utility or jurisdiction override of any floor (the override tables are empty), the cause or location of the fault, and any real device or site. Waveforms and symbols are illustrative.See also:One fault, three categories, hands-off · Fast-track screens walk · Ride-through zones · Cease-to-energize