COMTRADE records for model validation: what makes one usable
A record is not evidence because it captured an event. It is evidence when it excited the behavior you are claiming, at a rate that can resolve it, with channels a reviewer can trust.
A COMTRADE record becomes evidence when it has the channels the model needs, a sample rate that can resolve the behavior being claimed, scaling and timing a reviewer can verify, and, above all, excitation in the directions you intend to fit. A perfectly clean record of an event that never provoked the behavior supports nothing.
What COMTRADE actually is
COMTRADE, the Common Format for Transient Data Exchange, is the IEEE C37.111 standard for exchanging disturbance records between devices and software. It is a container, not a measurement quality guarantee, and that distinction is the source of most trouble.
A classic record is a set of files sharing a base name: a .CFG configuration file
listing the analog and digital channels with their units, scaling factors, sample rates and
time base; a .DAT file holding the samples in ASCII or binary; and optional .HDR and .INF files carrying human-readable context. Later editions
also define a single-file .CFF container.
Everything a validator needs in order to interpret the samples correctly lives in the configuration file. A record delivered without it, or with one that disagrees with the data, is not a record yet.
The channels you need
For validating an aggregated data-center load model at the point of interconnection, the working minimum is:
- Three-phase voltage at the metering point, so terminal voltage can be computed rather than assumed.
- Three-phase current at the same point and with the same time base.
- Frequency, or enough voltage resolution to derive it credibly.
- Active and reactive power, either recorded directly or derivable from the above with stated conventions.
- Relevant digital channels: breaker and transfer-scheme status, so a step in the trace can be attributed to a switching action rather than to load dynamics.
That last item is the one most often missing and most often decisive. Without status channels, a sudden drop is ambiguous: it may be the load responding, or a breaker opening. A model fitted across that ambiguity will absorb a switching event into a continuous-response parameter, and the resulting number will be confidently wrong.
State the polarity and direction convention explicitly. A reactive power sign flip is easy to introduce, hard to spot in a plot, and changes the conclusion of a fit.
Sample rate decides what is resolvable
Sample rate is not a quality score, it is a ceiling on what can be recovered. Protection acting on a cycle-scale timer cannot be characterized by a record that reports a few dozen times per second, no matter how long it runs.
This is measurable rather than theoretical. In our own synthetic testing, decimating a deep-sag record from 200 samples per second to 30, roughly the difference between a disturbance recorder and typical PMU reporting, dropped the rank of the sensitivity matrix from six of six to four of six. The event was unchanged. The record simply stopped resolving two of the directions.
Method and full matrices: what a data-center dynamic model can be identified from.
Excitation decides what is identifiable
This is the part that inverts most people’s intuition, so it is worth stating plainly: the question a record answers is not how severe the disturbance was. It is which distinguishable directions the disturbance excited.
Two consequences follow, and both are counterintuitive:
- A record where frequency never leaves nominal cannot support a droop claim. A droop gain multiplied by zero deviation leaves no trace in the output, so no amount of clean data in that record makes the parameter identifiable.
- A sag that trips the load can be worse than one that does not. Once the load disconnects it reports nothing about its own continuous response. The severe event spends most of its duration telling you about protection settings you already locked, and comparatively little about the dynamics you are trying to fit.
The practical rule is to prefer the disturbance that excites without disconnecting, which is the opposite of how records are usually triaged.
Making a record a reviewer can trust
- Keep the original. Archive the untouched files and hash them. Do all work on copies, and record the hash in the submission.
- Verify scaling against a known quantity. Check that pre-event power matches the facility’s known operating point. A scaling error usually announces itself here.
- Confirm the time base. Absolute timestamps, sample rate, and trigger position all have to agree. A record whose trigger sits at the wrong offset will misalign against a simulation in a way that looks like a modeling error.
- Keep enough pre-event data. Steady state before the disturbance is what establishes the operating point the fit starts from.
- Keep enough post-event data. Reconnection and restoration can take far longer than the fault. A record that stops at voltage recovery cannot support any reconnect or ramp claim.
- Record what was running. The IT and mechanical load at the time of the event is part of the measurement, and without it the aggregate cannot be scaled to other operating states.
Triaging the records you already have
Most facilities do not get to choose their disturbance. If you have a pile of records and need to know which are useful, sort them by excitation before you sort them by severity.
For each record, ask which channels moved and by how much, whether the load stayed connected, whether the sample rate can resolve the transitions you intend to claim, and whether enough post-event data exists to see restoration. A short, shallow, well-instrumented sag where the facility stayed up is frequently the most valuable file in the archive, and it is frequently the one nobody kept.
Where the archive cannot support a claim, the deliverable is the gap and the test that would close it. The commissioning test guide covers how to specify that so the resulting record is usable the first time.
Frequently asked questions
What files make up a COMTRADE record?
A configuration file (.CFG) describing channels, scaling, sample rates and timing, and a data file (.DAT) holding the samples in ASCII or binary. Optional header (.HDR) and information (.INF) files carry human-readable context. Later editions also allow a combined .CFF container.
Is PMU data good enough to validate a dynamic model?
Sometimes, and it depends on what you are claiming. Typical PMU reporting rates can resolve slower continuous response but will not resolve fast protection action. In our own testing, decimating a deep-sag record from 200 samples per second to 30 dropped the identifiable parameter count from six of six to four of six on an otherwise unchanged event.
We have one record. Is that enough?
It can be, for the parameters that record actually excited. One record cannot support a claim about a behavior it never provoked. The useful question is not how many records you have but which distinguishable directions they excited between them.