File Transfer in IEC 61850: GetFile and Fault Records

Short answer

IEC 61850 defines a simple file store in each server and four services: read a file, write it, delete it and query its attributes. It is used mainly to download fault records in COMTRADE format and, to a lesser extent, to upload configurations. The standard fixes names, directories and suffixes, but leaves it to the parties to agree on what each file contains.

What the IEC 61850 file model is

Short answer. Each server can offer a file store that a client accesses with four services: read (GetFile), write (SetFile), delete (DeleteFile) and query the attributes of a file. It is the standard way to download the fault records of an IED over the substation network.

Part 7-2 makes clear that the store and the services are intentionally limited, so that devices with few resources can implement them. Only one format exists: unstructured sequential binary, which can contain programs, data or both. What the bytes mean is agreed by the communicating systems; the standard does not interpret them.

Each file has three attributes: name (up to 255 characters), size in octets (optional) and date of last modification. The standard suggests structuring the names to tell types apart, such as disturbance records, programs and parameter or configuration data.

The four services

Service	Who requests it	What it does
Read file	Client	Transfers the content of a file from the server to the client
Write file	Client	Transfers a file from the client to the server
Delete file	Client	Removes a file from the server’s store
Query attributes	Client	Returns the name, size and modification date of a file

In addition, the client can request the file directory of the server with the directory service defined in part 7-2. The conformance test of part 10 checks those services: it walks the directory, requests each file and its attributes, verifies deletion, writing of small and large files and reading from several clients at once when the device supports more than one connection.

How it maps to MMS

Part 8-1 assigns the model to the MMS file object. If a device declares that it supports file transfer, it must implement the MMS file services; offering FTP as well is a local decision and its conformance is outside the standard.

Read. It is translated into a sequence of open, successive reads and close. The server indicates with a flag whether more fragments remain; the client repeats the read until there are no more and then closes.
Write. It is translated into a file-get request: the server receives the name of the file on the client and fetches it itself with a read. That is why the source name is mandatory.
Delete. It is translated into the MMS file delete.
Query attributes. It is translated into the MMS file directory service.

Downloading a file with GetFile over MMS

Client requests the file. With the full name, which cannot be null
Server opens the file. Initial position 0
Successive reads. Each response indicates whether more fragments follow
Close. When there are no more fragments
Response to the client. The complete content; if any step fails, a negative response

Names, directories and suffixes

Part 8-1 sets rules so that content can be found without asking:

The name optionally includes a directory path. Each directory name can have up to 32 characters and the separator is declared by the manufacturer.
If the server contains logical devices, one of its roots is a directory called “LD”, and below it are directories named after each logical device. Files specific to a device live in its own. Those that belong to none, such as the image of the server itself, are placed according to local criteria.
The file name allows at least 12 characters; it is recommended that the full specification not exceed 64. The real maximum is declared by the manufacturer in its PIXIT, along with whether it is case sensitive.
Suffixes of up to three characters indicate the format. These are reserved: bin (binary), dtd, gif, htm, pqd (power quality data interchange), txt (text), xml, xsd and zip (compressed).

Fault records. COMTRADE files go in a directory called “COMTRADE”, inside the logical device directory or at the root. Their names and suffixes follow the COMTRADE standard (IEEE C37.111 / IEC 60255-24): the header, the configuration and the data, as three files with the same name. If the directory has a zip file of the same name, it compresses the content of the three. To read those files, see COMTRADE files and the COMTRADE viewer tool.

What it has to do with logical nodes

The logical node standard (part 7-4) defines the disturbance record handling node, normally located at station level, with two optional controls: automatic upload and deletion of the record. Automatic upload is related to automatic collection of oscillography; the download of the files is still done with the services of this model.

To transfer configuration, part 6 recognizes remote file transfer using the method of part 7-2 as one way of delivering the configuration to the IED, and leaves the format open (SCL is a natural option). Engineering files are explained in SCL files.

Limits worth knowing

Content. The standard does not define what each file contains, only how it is named and moved. A device can deliver the record in whatever format is agreed.
Size. The size reported is an estimate and can be 0 if unknown.
Bandwidth. A large record shares the network with reports and GOOSE. Schedule bulk downloads outside of events and confirm that the device keeps up its reports while it serves files.
Security. The write and delete services allow the device to be altered. Part 5 asks for access control on the remote file request; restrict by role and log the operations; see role-based access control IEC 62351-8.
Evidence. If the file will be used for a fault analysis, keep the original unmodified, with its date and source, and work on a copy.

Trip analysis from IED records

Do you have the IED records but are not sure what happened in the event? At Tiza Group we analyze oscillography and sequences of events from relays and recorders, remotely and worldwide; we can quote you a relay trip analysis and, if you need it, leave automatic record download configured as part of your IEC 61850 engineering, at medium, high and extra-high voltage, in substations and industry. How a value is replaced by a manual one (subEna, subVal) and what the quality flags is covered in Data Substitution in IEC 61850.

References

IEC 61850-7-2 (edition 1, 2003): clause 20, file transfer model and services.
IEC 61850-8-1 (edition 1, 2004): clause 23, mapping to the MMS file services.
IEC 61850-7-4 (edition 1, 2003): disturbance record handling node (RDRS).
IEC 61850-6 (edition 1, 2004): remote transfer of configuration files.
IEC 61850-10 (edition 1, 2005): test cases for the file transfer model.
IEC 61850-5 (edition 1, 2003): clause 13.7.5, file messages, with access control for the remote request.
IEEE C37.111 (COMTRADE).

Frequently asked questions

Where are the oscillography records of an IED that uses IEC 61850?

Part 8-1 reserves a directory called COMTRADE for fault records; it can be inside the logical device directory or at the root. There the files appear with the COMTRADE format suffixes and, if the device allows it, a compressed file with the same name that gathers the three.

Is the size reported by the server exact?

Not necessarily. The standard states that the size is to be interpreted as an estimate and that a value of 0 may mean unknown size; for example, a COMTRADE record generated at the moment it is requested may have a size that cannot be determined beforehand.

Is writing and deleting files on an IED over IEC 61850 safe?

Part 5 requires that the remote file transfer request have access control, that is, some form of authorization. The specific mechanisms are left to the project: restrict by role who can download, upload and delete, and log every operation. IEC 62351-8 deals with role-based access control.