Engineering

Disturbance files over IEC 61850: file transfer that survives real networks

2026-10-29 · 8 min read

A protection relay records a fault, produces a disturbance file, and the master is supposed to collect it. That last step is where a surprising number of systems quietly fail: the file is large, the transfer is chunked, the association is shared with reporting, and the network is the same one carrying GOOSE-adjacent traffic. Done carelessly, collecting one 200 MB record costs you every report for the duration.

The service, briefly

File transfer is a separate MMS service with its own object model: a file store, a directory listing, file attributes, and a read operation that returns the file in chunks. A client asks for the directory, decides what to fetch, opens the file, and reads until it has the whole thing.

The important consequence: a file transfer is a series of request/response exchanges on the same association that carries your reports. It is not a background stream, and it is not free.

Why big files fail at the master

Almost never because the protocol cannot do it. Almost always one of these:

• A fixed chunk size tuned for a small file, producing thousands of round trips and a timeout in the middle.
• No resumability. A transfer that fails at 90% starts again from zero, and on a marginal link it never finishes.
• Fetching everything the directory lists. A device with two years of records will offer thousands of files; a master that enumerates and then downloads them saturates the link and the disk.
• Blocking the indication loop. Reading a file on the same thread that handles reports means the peer's buffers fill and, if they are bounded, events are lost.

COMTRADE is two files, and they must stay a pair

A disturbance record is a configuration file describing the channels and a data file holding the samples. They are separate files with related names, and treating them independently is how archives end up with orphaned halves that cannot be read.

• Fetch the pair as a unit and verify both arrived before marking the record complete.
• Check the configured sample count against the data file size before publishing it — a truncated data file opens without error in some tools.
• Keep the original names. Renaming on ingest breaks the cross-references that scripts and older tools depend on.

Rules that keep reporting alive

• One transfer at a time per association, with a byte budget per second. The report stream must not starve.
• Never transfer on a link that is already at its bandwidth limit; schedule collection for quiet periods, or use a second association for bulk data if the device supports it.
• Implement resumption: remember the offset and continue, rather than restarting.
• Bound the queue. If 40 records are waiting and the link can carry 2 per hour, dropping the oldest with a log entry is a decision; silently falling further behind is not.
• Verify the stored file — size, and if the format allows it, a checksum — before deleting from the device.

Questions that come up

Can the device push a file to the master instead?

The standard service is pull-oriented; your device may offer a non-standard push or an FTP/HTTP alternative. Treat push mechanisms as product-specific and document them, because a customer tool will not find them.

What timeout is reasonable for a large file?

Size-dependent and link-dependent: derive it from the measured throughput and the file size, with margin, rather than using one global value. A fixed 30-second timeout on a 200 MB file guarantees failure.

Should the master poll the directory often?

Poll on a schedule tied to expected record production, not continuously. A directory listing on a device with thousands of files is a measurable load, and it grows over time.

Keep reading