6.1. SEL

There are many Schweitzer Engineering Laboratories (SEL) devices supported by PEAT, including Real Time Automation Controllers (RTACs), the SEL-3620 security gateway, and many types of protection relays. These are implemented by the PEAT modules SELRTAC, SEL3620, and SELRelay, respectfully.

See also

SEL Technical Papers

SEL products page

SEL-351S documentation

SELRelay

PEAT DeviceModule implementation for protection relays and other SEL devices

SEL3620

PEAT DeviceModule implementation for SEL-3620 security gateways

SELRTAC

PEAT DeviceModule implementation for SEL RTACs

6.1.1. Terminology

  • Substation Configuration Language (SCL)

  • Configured IED Description (CID)

6.1.2. File types

  • IED Capability Description file (.ICD)

  • System Specification Description (.SSD) file

  • Substation Configuration Description file (.SCD)

  • Configured IED Description file (.CID)

6.1.3. Data Collected

  • Full device configuration file

  • Firmware version and release date

  • Firmware ID

  • Part number

  • Relay ID

  • Protection schemes

  • Trip logic

  • Modbus and DNP3 register maps

6.1.4. Relays

6.1.4.1. Relay communications

There are several methods PEAT can interact with a SEL relay: FTP, Telnet, HTTP/HTTPS, and directly connected via serial (currently, EIA-232/RS-232 is supported for serial communications). Device verification and commands (such as relay restart) can be performed via Telnet or Serial, and pulling/pushing of device configuration via FTP or serial.

6.1.4.2. File output

While the files generated by PEAT may vary by model and device, they roughly follow the following structure:

  • <device-address>/

    • formatted-logic.txt : The logic sections of the configuration.

    • parsed-config.json : The parsed configuration in JSON format.

    • device-data-full.json : All data pulled from the device, including the parsed configuration, telnet data, IP and MAC address, and other information.

    • relay_files/

      • CFG.TXT

      • SET_ALL.TXT

      • SETTINGS/

        • ... SET_*.TXT ...

6.1.4.3. Settings files

The files recovered and/or generated vary by model and device. They may include the following:

  • CFG.TXT: basic device data (firmware, model) and a list of the configuration files on the device. Every relay has this.

  • CFG.XML: similar to the above, in XML format. Seen on the 700G, 710, and 751.

  • SET_ALL.TXT: the complete device configuration. This is essentially all of the individual configuration files merged into a single file. The file structure is roughly equivalent to INI with some eccentricities. Every relay has this.

  • SETTINGS/: directory containing the individual configuration files (SET_1.TXT, etc.). Each file contains an identical [1] section at the beginning with the device relaytype, FID, BFID, and part number.

The SEL configuration is stored in a single file called SET_ALL.TXT. This file is broken up into multiple sub files representing sections of the configuration, e.g. SET_1.TXT for the section [SET_1] in the full configuration. PEAT pulls this file and the individual files from a device via FTP and parses it into useful information. To change the device configuration, the individual files are uploaded via FTP, then the relay is restarted via a command sent over Telnet. The individual files must be sent due to SET_ALL.TXT being read-only.

Refer to section 10.26 Virtual File Interface in the SEL-351S Protection System Instruction Manual for detailed descriptions of files present on the relay.

6.1.4.4. Configuration details

  • RID: Relay Identifier. The Relay Identifier is typically used to identify the relay or the type of protection scheme. The relay tags each report (event report, meter report, etc.) with the Relay Identifier and Terminal Identifier. RID and TID settings may include the following characters: 0-9, A-Z, -, /, ., space. These two settings cannot be made via the front-panel interface. (source: SEL-351S Protection System Instruction Manual). The factory default RID for most relays is FEEDER 1.

  • TID: Terminal Identifier. Typical Terminal Identifiers include an abbreviation of the substation name and line terminal. The factory default TID for most relays is STATION A.

  • SID: Station ID

  • FID: Firmware ID (refer to the Firmware IDs section below)

  • BFID: Boot firmware ID (refer to the Firmware IDs section below)

  • CT: Current Transformer

  • PT: Potential Transformer

6.1.4.5. Firmware IDs

  • FID: Firmware ID
    • Example: SEL-351-5-R510-V0-Z103103-D20110429

      • Model: SEL-351

      • Variant (??) : 5 (some devices may not have this portion)

      • Release: R510 (major release, generally new or changed features)

      • Point release: V0 (minor release, usually fixes or minor changes)

      • Settings version: Z103103 (indicates what version of SEL ACSELERATOR software to use)

      • Firmware release date: D20110429

  • BFID: Boot firmware ID

    • Similar to FID, but for the boot firmware

Per SEL’s documentation: “The firmware version will be either a standard release or a point release. A standard release adds new functionality to the firmware beyond the specifications of the existing version. A point release is reserved for modifying firmware functionality to conform to the specifications of the existing version.”

6.1.4.6. Setting categories (configuration sections)

  • SET (X): Group settings (where X := [1, 2, 3, 4])

  • SEL L(X): Logic settings (where X := [1, 2, 3, 4])

  • SET G: Global settings

  • SET P(X): Port settings (where X := [1, 2, 3, 4, 5, F]). “F” is the front port, usually RS-232 serial. The port numberings vary by device.

  • SET F: Front-Panel settings

  • SET R: Report settings

  • SET M: Modbus settings

  • SET D: DNP3 settings

6.1.4.7. SEL software: RDB Project Files

SEL configuration software stores device configurations in project files with a .rdb file extension. The .rdb SEL project files use a file structure called Compound File Binary Format, or Microsoft OLE2 File. PEAT uses the olefile method isOleFile() to check the file for the magic number at the start of the header to determine if it is the correct format. If it is, the SET_ALL configuration for the device is extracted and parsed (with the same parsing code used for configurations pulled form devies).

6.1.4.8. Configured IED Description (.CID) Files

.CID files are zlib-compressed text data. This may be XML data, or it could be other data. The only file we’ve seen so far is SET_61850.CID, and it decompresses to XML. The schema for the XML is (I think) standardized by IEC 61850-6. If you are willing to pay for a copy of the standard, then maybe you can make some use out of the XML. It’s only relevant if IEC61850 or GOOSE is enabled.

If any .CID files are found during a PEAT pull, PEAT will attempt to decompress them and put the results in the device output directory with the name of decompressed_<filename>.xml (or .txt if non-XML data was extracted from the file). They can also be parsed directly with peat parse -d selrelay <filename> (e.g. peat parse -d selrelay ./SET_61850.CID).

To manually extract them without using PEAT:

sudo apt update
sudo apt install qpdf
zlib-flate -uncompress < ./SET_61850.CID > SET_61850.xml

6.1.5. Example inputs

6.1.5.1. SET_1.TXT

6.1.5.2. SET_P5.TXT

6.1.5.3. SET_ALL.TXT

6.1.6. Developer notes on SEL communications

SEL relays can communicate over Telnet, serial connection (e.g. RS-232), or a “engineering tunnel” through a SEL 3530 RTAC (I’m not aware of any relays that support SSH yet, but there might be some newer ones that do). The messages sent are part of what they call “SEL ASCII” commands, and those commands are transport-agnostic, which means the “id” command sent over Telnet will have the same response as one sent over serial or an engineering tunnel. The commands and responses are basic ASCII text, except in certain cases, where it’s “Compressed ASCII” (this is rare).

In addition to “SEL ASCII” interfaces, relays also typically have FTP and a web interface (using HTTP and/or HTTPS), dependent on the configuration. FTP is typically disabled by default, but can be enabled. Since files can be transferred over “ASCII” or FTP, and the commands are very similar, the file transfer code has been generalized in peat/modules/sel/sel_comms.py.

In PEAT, the “SEL ASCII” commands are implemented as a transport-agnostic class, SELAscii. The sub-classes for specific transports are SELTelnet and SELSerial. We don’t have support for engineering tunnels through an RTAC (yet). The code for scraping and parsing web pages is implemented by SELHTTP. Some of the web pages literally run ASCII interface commands internally and just display the results, while other pages pull data in other ways, so there is some overlap in parsing functionality between SELHTTP and SELAscii. The FTP interface isn’t terribly special, except for a few quirks. The FTP functionality is implemented in peat/modules/sel/sel_comms.py with functions that call PEAT’s generic FTP class and handle a few quirks (like changing directories on older relays).

The code gets called from SELRelay class, in the various pull_* and _verify_* methods. The pull_* methods get called by pull_project, which is the function that gets called by PEAT when peat pull happens, and is defined in the Device base class.

6.1.6.1. YMODEM notes

YMODEM is required for relays that don’t have the file show command. PySerial doesn’t support YMODEM, and the Python modem package hasn’t been updated in over 11 years, so we’re forced to subprocess and call the rz / sz commands from the lrzsz project. This is not available on Windows, but is available on Linux (sudo apt install lrzsz) and MacOS (sudo brew install lrzsz).

  • show supported: 700G, 351S, 351

  • read: 451, 2032 (Requires Ymodem to transfer the file)

Things that don’t require YMODEM and use fil show - 351S doesn’t require YMODEM and uses fil show. - 351S was tested on peat rack (port F, front serial, 9600 baud) - 351 on peat rack tested (port F, front serial, 57600 baud) - 700G on peat rack tested (port 3, rear serial, 9600 baud) - 751 should work with fil show according to the documentation. - 710 should also work according to the docs - 311C-1 has file show, according to docs.

Things that DO require YMODEM for file transfer - 451 DOES require YMODEM for file transfer. It uses fil read <file> instead of fil show. - 451. YMODEM with “file read”. - 487E. YMODEM with “file read”. - 2030 (and 2032?): YMODEM with “file read”.

XMODEM devices - NOTE: XMODEM only works for SELboot, doesn’t work during normal operations, according to docs. basically lets you upload and download firmware updates. - 300G. According to docs it doesn’t have any “fil” commands, and also requires XMODEM for transfers. - 311A. Same as above, according to docs. - 311L-0-6. Same as above. - 311L-1-7. Same as above. - 387. same as above. - 387A. same as above. - 587Z. same as above.

Others - 387L. Not even xmodem… - 587. not even xmodem.

6.1.6.2. Telnet notes

Full list of Telnet commands is in the instruction manual.

From the docs:

“A command transmitted to the relay consists of the command followed by either a CR (carriage return) or a CRLF (carriage return and line feed). You can truncate commands to the first three characters. For example, EVENT 1 <Enter> becomes EVE 1 <Enter>. Use upper- and lowercase characters without distinction, except in passwords.

Each message begins with the start-of-transmission character (ASCII 02) and ends with the end-of-transmission character (ASCII 03). Each line of the message ends with a carriage return and line feed.”

What PEAT sees (note the 0x03 and 0x02 characters):

['id', '\x02', '"FID=SEL-700G-R200-V0-Z006003-D20180629","08F0"', '"BFID=BOOTLDR-R501-V0-Z000000-D20140224","0947"', '"CID=59A0","025C"', '"DEVID=SEL-700G","0408"', '"DEVCODE=74","0312"', '"PARTNO=0700G12B1B1B7281A230","06C2"', '"CONFIG=112222010","041E"', '"SEL DISPLAY PACKAGE=1.0.50700.2000","087C"', '"CUSTOMER DISPLAY PACKAGE=1.574871567","09A2"', '"iedName=","0360"', '"type=","026F"', '"configVersion=","0609"', '"LIB61850ID=5C9A14CB","04F1"', '\x03\x02', '=>>\x03']