Differences

This shows you the differences between two versions of the page.

--- finding_an_intermittent_fault_from_sampled_values [2026/09/07 19:01] – [Getting started without a substation] wikiadmin
+++ finding_an_intermittent_fault_from_sampled_values [2026/09/09 14:31] (current) – wikiadmin
@@ Line 1: / Line 1: @@
-====== Application note: finding an intermittent fault from Sampled Values ======
+====== Application note: finding intermittent faults from Sampled Values ======
-===== The problem =====
+===== The challenge =====
-A feeder trips every few weeks. Nobody knows why.
+A feeder trips every few weeks, but the cause is unclear.
-The relay's own disturbance record shows the trip and the half-second around it, which is enough to
+The protection relay's disturbance record captures the trip and the short interval around it. That is usually enough to confirm that the relay operated as configured, but it may provide little insight into **what caused the event in the first place**.
-confirm that the relay did what it was set to do and nothing at all about what caused the event.
-Worse, the interesting behaviour usually does **not** trip: the plant reports flickering lights, a
-drive faulting out, a contactor that chatters, and by the time anyone looks there is nothing to
-look at. The evidence exists for a few milliseconds somewhere on the bus and then it is gone.
-What is needed is a recorder that is always listening, that keeps the cycles from **before** the
+Even more difficult are disturbances that never cause a trip. Operators may report flickering lights, a drive shutting down, or a contactor chattering, but by the time an engineer investigates, the event is over. The evidence may have existed for only a few milliseconds and then disappeared.
-event as well as after it, that writes what it caught in a format a protection engineer can open,
-and that can say something useful about several hundred captures without a person opening each one.
-This note describes that application, built from the IEC 61850 beans and the waveform beans
+To diagnose these problems effectively, the system needs to do more than record the moment of a trip. It needs to continuously watch the waveform, retain the period before the event, capture relevant disturbances automatically, and make the resulting data easy to analyze.
-together. The same diagram runs against a merging unit on a live bus and against a folder of
-COMTRADE files on a laptop, which is what makes it possible to develop with confidence.
 ===== The approach =====
-<code>
+The basic approach is straightforward:
-  ┌─ the substation ──────────────┐      ┌─ the application ───────────────────────────────────┐
-  │                               │      │                                                     │
-  │   merging unit ──── SV 9-2 LE ────▶  Iec61850SvSubscriber ──▶ TimeSeriesWindowBuffer       │
-  │   (CT/VT, 4000 frames/s)      │      │        │                        │                   │
-  │                               │      │        └─ RMS ──▶ display       ▼                   │
-  │   protection relay ── GOOSE ─────▶   Iec61850GooseSubscriber ──▶ DisturbanceRecorder        │
-  │   (trip, in 4 ms)             │      │                                 │                   │
-  └───────────────────────────────┘      │                                 ▼                   │
-                                         │                          ComtradeWriter             │
-                                         │                                 │                   │
-                                         │                        .cfg / .dat on disk          │
-                                         │                                 │                   │
-                                         │                                 ▼                   │
-                                         │   ComtradeParser ──▶ FeatureExtractor ──▶ per-cycle  │
-                                         │                                 │        features   │
-                                         │                                 ▼                   │
-                                         │                       detector ──▶ LLMPrompt ──▶ a  │
-                                         │                                        screen       │
-                                         └─────────────────────────────────────────────────────┘
-</code>
-The left half is IEC 61850 and the right half has never heard of it. That separation is the design,
+  *  continuously monitor high-speed current and voltage waveforms,
-not an accident of packaging: ''DisturbanceRecorder'', ''ComtradeWriter'', ''ComtradeParser'' and
+  *  maintain a rolling pre-event buffer,
-the feature beans take records, and a record is a record whether it arrived from a merging unit or
+  *  trigger a capture from a relay trip or another abnormal condition,
-from a file. Build the right half against a folder of captures, then put a subscriber in front of
+  *  continue recording for a short period after the event,
-it.
+  *  save the result in a standard disturbance-record format, and
+  *  automatically analyze each capture to identify the events most worth reviewing.
-===== The pieces =====
+This allows engineers to see not just **that** something happened, but what the system was doing immediately before, during, and after the event.
-==== GOOSE is the trigger, not the data ====
+The trigger does not need to come only from protection equipment. It can also come from analytics, equipment status, a power-quality threshold, or another condition of interest. This is especially useful for disturbances that affect plant operation without ever causing a protection trip.
-''Iec61850GooseSubscriber'' follows one publisher, normally the protection relay, and republishes
+===== Why the pre-trigger data matters =====
-its data set members as data sources. The trip signal is the obvious trigger for a capture, and it
-arrives within the 4 ms GOOSE is engineered for, which is well inside the window the buffer is
-already holding.
-Two properties of the subscription matter more than they look.
+For intermittent faults, the most valuable evidence is often found in the cycles leading up to the event.
-  * **A subscription going quiet is data.** Every frame carries the publisher's ''timeAllowedToLive''; when it expires with no successor the subscriber marks its values bad rather than holding the last good one. A trigger that silently stopped arriving is the failure mode this design most needs to not have.
+A recorder that starts when the trigger arrives may capture the relay action perfectly while missing the behavior that caused it.
-  * **//ConfRev// is worth setting.** A publisher whose data set is re-engineered increments it, and a mismatch is refused rather than decoded into the wrong members.
-The trigger does not have to be GOOSE. A detector's flag or an operator's button reaches the same
+A rolling waveform buffer solves that problem. When a trigger occurs, the system retains both:
-inport, and the interesting configurations usually have both: the relay's opinion, and a threshold
-of your own for the events that never trip.
-==== Sampled Values are the waveform ====
+  * the waveform leading up to the event, and
+  * the system response afterward.
-A merging unit sends four thousand frames a second. Nothing in an application wants four thousand
+This makes it possible to investigate questions such as:
-values a second and no connector should carry them, so ''Iec61850SvSubscriber'' emits **one record
-every ''ChunkCycles'' cycles** — a time column and the channel columns, in amps and volts — and
-publishes the RMS of each channel beside it for the screen. One value per cycle crosses one
-connector instead of four thousand.
-==== The window comes before the recorder ====
+  * Was the current already becoming unstable?
+  * Did one phase begin behaving differently?
+  * Was there evidence of arcing or switching before the trip?
+  * Did the disturbance begin before the protection system reacted?
+  * Did the system recover normally afterward?
-''TimeSeriesWindowBuffer'' holds the last ''MaxAge'' of waveform, continuously, whether anything is
+===== Using Sampled Values as the waveform source =====
-happening or not. This is the part that is easy to leave out and impossible to add later: **the
-half of a disturbance record that matters most is the half from before the trigger.** What the
-current was doing in the cycles leading up to the trip is what says whether the relay was right, and
-a recorder that began collecting when something happened would have missed exactly that.
-''DisturbanceRecorder'' then takes the window on a trigger, keeps collecting for
+IEC 61850 Sampled Values provide the high-speed current and voltage data needed for this kind of analysis.
-''PostTriggerSeconds'', and emits one record. ''RetriggerHoldOff'' stops a chattering source from
-producing a hundred captures of one event.
-==== COMTRADE is the deliverable ====
+Rather than treating the data as a stream of isolated samples, the waveform can be grouped into short time windows or electrical cycles and processed as a time-series record.
-''ComtradeWriter'' writes an IEEE C37.111 ''.cfg''/''.dat'' pair. This is not an implementation
+That makes the same captured waveform useful for several purposes:
-detail, it is the reason the application is worth building. A protection engineer opens COMTRADE
-in the tool they already own, the utility's own analysis suite reads it, and it can be sent to the
-relay vendor with a fault report. A capture in a proprietary format is an argument; a capture in
-COMTRADE is evidence.
-''ComtradeParser'' reads them back, which is what lets the analytics and the whole right-hand half
+  * disturbance recording,
-of the diagram be developed and regression-tested against captures nobody has to reproduce.
+  * RMS and power-quality monitoring,
+  * spectral analysis,
+  * automated anomaly detection, and
+  * later offline review.
-==== One number per cycle ====
+The high-resolution data is retained where it is useful, without requiring every downstream application to process thousands of individual samples per second.
-Several hundred captures is too many to open by hand, so the analytics reduce each one to something
+===== Using GOOSE or analytics as the trigger =====
-sortable. ''FeatureExtractor'' is asked for a feature vector **per cycle**, one 20 ms window at
-Hz, and the metric that carries the most information for the least explanation is the share of
+A relay trip delivered over GOOSE is a natural trigger for disturbance recording, but it should not be the only one.
-each cycle's energy that is **not** at the fundamental:
+Many of the most useful captures are events that never result in a trip.
+Additional triggers can therefore be based on:
+  * waveform distortion,
+  * RMS excursions,
+  * rate-of-change,
+  * equipment state,
+  * operator input, or
+  * application-specific rules.
+This makes the recorder useful for both protection events and less obvious operational disturbances.
+===== COMTRADE as the common record format =====
+Captured waveforms can be stored as IEEE C37.111 COMTRADE records.
+This is important because COMTRADE is already widely used in protection and power-system engineering. The same capture can be:
+  * opened in existing engineering tools,
+  * archived with other disturbance records,
+  * shared with a relay or equipment vendor,
+  * analyzed by another application, or
+  * replayed later for testing.
+A standard record format also separates the live data source from the analysis. The same analytics can be developed against historical COMTRADE files and then applied to live Sampled Values when the system is deployed.
+===== Reducing the waveform to useful evidence =====
+A single event may contain thousands of waveform samples, and a site may accumulate hundreds of events over time.
+Opening every capture manually is not practical.
+The more useful approach is to first reduce each waveform to a set of meaningful measurements that can be sorted, compared, and screened automatically.
+One useful example is **spectral impurity**: the proportion of each electrical cycle's energy that lies outside the expected fundamental-frequency band.
+For a 50 Hz system:
 <code>
@@ Line 109: / Line 108: @@
 </code>
-which is ''band_power_ratio'' over two named bands. A clean 50 Hz cycle scores near zero however
+A clean waveform remains close to zero even if its amplitude changes.
-large its amplitude. Arcing, switching transients, converter misbehavior and partial discharge all
-move energy away from the fundamental and score high.
-Two numbers per record then say most of what is worth knowing:
+Arcing, switching transients, converter problems, contact operation, and other distorted events move energy away from the fundamental and produce a larger value.
-  * the **median** impurity across every cycle and channel, which is the steady state, and
+Two summary values can then describe a large part of each capture:
-  * the **worst** cycle, with the channel and the time it occurred on.
-A record whose median is low and whose worst is high had a brief event. A record whose median is
+  * the **median impurity**, representing the normal background condition, and
-already high has a sustained harmonic problem and a different fault with a different report.
+  * the **worst cycle**, including the affected channel and time.
-==== The diagnosis ====
+A low median with a short, large excursion suggests a transient disturbance. A consistently elevated median suggests a sustained waveform-quality problem.
-''LLMPrompt'' is given the feature vectors and the two summary numbers, not the waveform, and asked
+This turns a large waveform into a small amount of evidence that can be searched, ranked, and compared.
-what they are consistent with. The value is not that it is clever; it is that it writes the same
-paragraph for the four hundredth record as for the first, and names the evidence it used so that a
-person can disagree with it.
-===== A worked example =====
+===== AI-assisted interpretation =====
-The screen below is one record from an RTE digital fault recorder, 6400 Hz, 50 Hz nominal, one
+Once the waveform has been reduced to meaningful features, AI can help interpret the results.
-ms cycle per feature vector — a file, played through the same beans that would be fed by a
-merging unit.
+The important point is that the AI does not need to inspect thousands of raw samples directly.
+Instead, analytics first identify the significant measurements, trends, frequencies, and event characteristics. The AI then reasons over that much smaller and more meaningful representation.
+This has several benefits:
+  * less data must be presented to the model,
+  * the important evidence is already identified,
+  * results are easier for an engineer to verify,
+  * smaller or local models become more practical, and
+  * the same diagnostic process can be applied consistently across large numbers of captures.
+The AI can describe what the event is consistent with and identify the evidence behind that interpretation. The engineer remains responsible for the final diagnosis.
+===== Worked example =====
+The screen below shows one disturbance record from an RTE digital fault recorder. The original waveform is sampled at 6400 Hz with a nominal frequency of 50 Hz.
 {{ :pasted:microgridweb.png?600 |Waveform anomaly screening: raw waveform, per-cycle spectral purity, and the diagnosis}}
-Three panes, top to bottom.
+The display contains three views.
+* **Raw waveform** — six channels representing three currents and three voltages. A disturbance begins just before 17:27:41, current collapses, and approximately one second later the system recovers. The waveform clearly shows that an event occurred, but does not by itself explain its character.
+* **Per-cycle spectral purity** — during normal operation the waveform contains very little energy outside the 50 Hz fundamental. During the event the impurity rises sharply for several cycles, showing that much of the signal energy has moved away from the fundamental.
+* **Diagnosis** — the steady-state waveform is clean, followed by a short, highly distorted event. Energy is distributed across a much wider frequency range rather than remaining concentrated at 50 Hz. That is evidence consistent with arcing, contact operation, switching, or another transient disturbance rather than a simple clean fundamental-frequency fault.
+The analysis also identifies what should be checked next. RMS and peak current, for example, can help distinguish between remaining possibilities.
+That combination of **automated screening and explicit supporting evidence** is more useful than simply assigning a fault label.
+===== Important limitations =====
+No single analytic identifies every electrical fault, so practical monitoring combines several measurements.
+* **Spectral impurity does not detect every fault.** A high-amplitude fault that remains almost entirely at the fundamental frequency may still have very low spectral impurity. Amplitude, RMS, peak, and other tests should therefore be used alongside spectral analysis.
+* **A failed measurement channel may appear artificially clean.** A channel stuck at zero has no out-of-band energy. A liveness or RMS check should therefore be used before classifying a low impurity value as healthy operation.
+* **This is not a protection system.** The relay remains responsible for protecting the plant. The recorder and analytics provide additional evidence to explain what happened.
+* **Accurate timing matters.** If records from multiple devices or applications are to be compared, appropriate time synchronization is required.
+===== Developing without a live substation =====
+The analysis does not need to begin with live IEC 61850 equipment.
+Existing COMTRADE records can be used to develop and validate the disturbance analysis, event screening, visualization, and AI-assisted interpretation.
+Those records may come from:
+  * protection relays,
+  * digital fault recorders,
+  * laboratory tests,
+  * archived plant events, or
+  * public disturbance data sets.
+Once the analysis is working as expected, a live Sampled Values source can be connected to the same processing chain.
+Waveforms can also be replayed in a laboratory environment, allowing the complete workflow to be tested repeatedly without waiting for the next real intermittent event.
+===== Implementing the solution with MIStudio =====
+MIStudio provides the building blocks needed to assemble this workflow in a single application.
-  * **Raw waveform** — six channels, three currents and three voltages. Something happens just before 17:27:41, the currents collapse, and roughly a second later everything comes back. That is a fault, a breaker opening, and a successful reclose. It is also about as much as the raw trace will tell you.
+For live IEC 61850 systems, MIStudio can subscribe to Sampled Values for waveform acquisition and to GOOSE for relay or equipment events.
-  * **Per-cycle spectral purity** — the impurity of every cycle of every channel. The steady state sits on the floor at 0.033 and below. During the event it goes to nearly 1: for a cluster of cycles, almost none of the energy is at 50 Hz.
-  * **Diagnosis** — median 0.00217, worst 0.96135 on I3. The steady state was clean, so this is not a harmonic load; the excursion is a factor of several hundred over a short cluster of cycles; within those cycles the fundamental is nearly gone and the energy is spread over 400–3150 Hz. That signature is arcing or contact operation, not a clean high-amplitude 50 Hz fault current.
-The last sentence of the diagnosis is the important one, and it is a limitation stated rather than
+A rolling time-series buffer retains the pre-trigger waveform. When a trip, anomaly, or other condition occurs, the disturbance recorder combines that history with the post-trigger data and creates a complete event record.
-hidden: to remove the remaining ambiguity, check where rms and peak maximised across the record. A
-clean high-amplitude fault current is **pure** — it would score near zero on this metric and the
-screening would pass it. See below.
-===== What to build =====
+MIStudio's COMTRADE support can then write the capture to disk or read existing records back for analysis and testing.
-^ Bean ^ Role ^
+The analytics layer can extract per-cycle or per-window measurements such as:
-| ''Iec61850SvSubscriber'' | the waveform, chunked one record per ''ChunkCycles'' cycles |
-| ''Iec61850GooseSubscriber'' | the relay's trip, as the trigger |
-| ''TimeSeriesWindowBuffer'' | the rolling pre-trigger window |
-| ''DisturbanceRecorder'' | pre-trigger window plus ''PostTriggerSeconds'', on a trigger |
-| ''ComtradeWriter'' | the ''.cfg''/''.dat'' pair |
-| ''ComtradeParser'' | reads captures back for the analytics |
-| ''FeatureExtractor'' | per-cycle features, including ''band_power_ratio'' |
-| ''LLMPrompt'' | the written diagnosis |
-Set ''PollPeriod'' to -1 on anything fed by a report or a subscription so nothing is asked for
+  * RMS,
-twice. See **IEC 61850** for the subscriber beans, **Disturbance recording** for the recorder and
+  * minimum and maximum,
-the writer, and **FeatureExtractor** for the metric vocabulary and the request format.
+  * spectral energy,
+  * frequency-band ratios,
+  * rate of change,
+  * peaks, and
+  * other waveform features.
-===== What this does not do =====
+Those analytics can be used directly for rules and anomaly detection, or passed to an AI model for higher-level interpretation.
-  * **The impurity metric does not see a clean fault.** A high-amplitude fault current at the fundamental is spectrally pure and scores near zero. This screening finds events with a distorted signature, arcing, switching, converter faults, and must be paired with an amplitude test to find the rest. Neither test subsumes the other.
+The resulting application can therefore combine:
-  * **A dead channel looks perfectly clean.** A channel reading zero, or a stuck value, has no out-of-band energy at all. A liveness gate on RMS belongs in front of any threshold set on this metric, or an instrument failure will be reported as a healthy bus.
-  * **Nothing here is protection.** This is a recorder and an analysis of what it recorded. The relay protects the plant, the application explains it afterwards.
-  * **A capture is only as good as its clock.** Sampled Values are timestamped from the kernel's receive time of the frame that begins the cycle; comparing captures from two applications means both need real time synchronisation.
-===== Getting started without a substation =====
+  * IEC 61850 connectivity,
+  * continuous high-speed waveform acquisition,
+  * pre- and post-event disturbance recording,
+  * COMTRADE interoperability,
+  * waveform analytics,
+  * automated event screening,
+  * visualization, and
+  * AI-assisted diagnosis.
-The right-hand half of the diagram needs no IEC 61850 at all. Point ''ComtradeParser'' at a folder
+Because MIStudio treats the waveform analysis separately from the live protocol source, the same application can be developed using historical COMTRADE files, validated in the laboratory, and then connected to live IEC 61850 equipment without redesigning the analytics.
-of existing captures, a relay's own records, or a public fault-recorder set, and build the
-extraction, the detector and the screen against files. When it works, put ''Iec61850SvSubscriber''
-in front of it.
-To go the other way, ''Iec61850SvPublisher'' plays a record back onto the wire as 9-2 LE, so a
+That provides a practical path from **historical fault analysis to continuous field monitoring and automated diagnosis**.
-relay on the same segment sees a fault it cannot tell from the one that happened. That is how
-protection settings are proved before they are trusted, and it is also how this pipeline gets
-tested end to end without waiting weeks for the feeder to trip again.