SCL IED Section: Server and Logical Devices

Short answer

The SCL IED section describes a device: its unique name, its access points, the server and its logical devices, the logical nodes with their data and values, the datasets and control blocks for reports, GOOSE and sampled values, the inputs it takes from other IEDs and the services it supports. In an ICD file the IED is named TEMPLATE and declares the capabilities of the device.

What the standard says and what it is for

The IED section of an SCL file (clause 9.3 of IEC 61850-6, edition 1) describes the preconfiguration of a device: its access points, and the logical devices and logical nodes it has instantiated. It also defines its capabilities: the communication services it offers, the data it instantiates (together with their node type) and their default or configuration values. How the origin and integrity of SCL files are protected is explained in IEC 62351-11: Securing XML and SCL Files.

There is one IED section per device, and its name must be unique within the file. If the file only contains descriptions of preconfigured devices, the name is TEMPLATE, a sign that the IED has no place in a project yet and that the system tool must treat it as a type from which it can produce several instances. That is the basis of the ICD file. To see how it fits into the whole, read the SCL object model.

Hierarchy of the section

Level	What it is
IED	The device. Attributes: name, description, product type, manufacturer and configuration base version (configVersion)
Services	List of services the device supports
AccessPoint	Access point to a subnet
Server	Communication entity that gives access to the logical devices
LDevice	Logical device (must contain LN0 and at least one node)
LN0 / LN	Logical nodes, with their data, datasets and control blocks

The configuration base version identifies only what the manufacturer delivers, not the individual configuration of the device in a project: the latter lives in the configRev data object of the LLN0 node (NamPlt) and must appear in the file.

Access points and server

An access point has a name (unique within the IED) and can be declared as a router or as a master clock. Combining the IED name and the access point name gives a unique reference in the system.

The cases the standard covers:

Point with a server: gives access to the logical devices and nodes. The nodes of the device, as clients, may use any access point of the IED, not only that of their server.
Point with no server, router or clock: used only by the client nodes of the IED itself. This is typical of the process bus port of a bay unit: what it obtains there is not visible on the station bus unless the device has a router function.
IED with only a node list (no server): these are clients only and cannot be supervised, because no server offers their data. The standard recommends that an IED have at least one server.
Router or clock only: an IED can be just a router, with no logical devices, and is then managed by a network management system outside the scope of the standard. Synchronization messages, GOOSE and sampled values do not cross a router.

The server element carries a timeout: if a started transaction, such as the selection of a setting group, does not finish in time, it is cancelled. It also includes authentication, with the methods “none”, password, weak, strong and certificate, whose exact meaning is defined by each stack mapping (in practice, IEC 61850-8-1). If the element is missing, no authentication is assumed.

Logical devices and nodes

Each logical device has an identifier (inst) that is unique within the IED and not empty; it must contain the LN0 node and at least one other node. The full name of the logical device is built following the rules in logical node names and must be unique in the file.

LN0 (class LLN0, empty instance) is the only one that can hold the control blocks for GOOSE, sampled values and setting groups, as well as reports and logs. The other nodes may carry datasets, report and log blocks, data instances (DOI) and inputs. Within a logical device (or within the IED, if there is no server), the combination of prefix, class and instance must be unique.

A node points to a type template (lnType) and, through data instances, can override a specific value of that template, for example changing the pulse duration of a command from 100 ms to 300 ms for that data object. What it cannot do is create data or attributes that the template does not contain (see DataTypeTemplates in SCL).

Datasets and control blocks

Datasets (DataSet): a sequence of elements pointing to data objects or attributes with their functional constraint. The order of the elements defines the order of the values in the messages, unless the stack states another rule.
Report and log blocks: say which dataset they publish and under which trigger and integrity conditions.
GSE block (GOOSE): only in LLN0. It carries the dataset it sends, the configuration revision (confRev) and, optionally, the IEDs that must subscribe. In an ICD file the dataset may be empty.
Sampled values block: also only in LLN0; it includes message options and, optionally, the destination IEDs.
Setting group block: only in LLN0.

External inputs

The Inputs section lists the external signals a node needs to perform its function. Each external reference (ExtRef) indicates the source IED, logical device, node and data object, and can be linked to an internal address of the device, which only the tool of the IED concerned should use; all other tools must preserve it. If the same data can arrive by report and by GOOSE, the device or its tool decides which to take. This is how an interlock that uses positions from another bay is modeled, as explained in GOOSE interlocking.

Services the device declares

The Services part is the “capability catalog”. Among other things, the device declares whether it supports:

Capability	What it indicates
Directories and data definition	That the client can browse devices, nodes and data
Reading and writing of data and datasets	Basic access services
Configurable or dynamic datasets	How many can be created and how many attributes they admit
Configurable report and log blocks	How many can be instantiated by configuration
Online settings of reports, GOOSE, sampled values	Which attributes of each block a client can change
Setting groups	Online selection, editing and confirmation
GOOSE and GSSE	Whether the device publishes, or only subscribes (maximum number of blocks equal to zero)
Time-activated control, file handling	Optional services

The standard establishes that the declared maximums must be guaranteed: that number of elements must be instantiable under any circumstances, even if dynamic memory would allow more of one type at the expense of another. There is also an element that states what can be changed in the nodes of an ICD file, such as prefixes or instance numbers.

Preconfigured associations

A preconfigured association defines a relationship between the server and a client node. It can be predefined (it exists but the client must open it) or pre-established (it is considered open when the device starts). It is identified by an identifier whose range and uniqueness are set by the stack. It is useful when one end cannot create dynamic associations. The standard recommends keeping authorization and access control inside the device itself and not in SCL.

How it is implemented, in general terms

The manufacturer delivers the ICD file with each product, or a tool able to generate it. The integrator imports those capabilities into a system tool, instantiates the IEDs and builds the connections between them. On export, each device receives only the part of the configuration it needs. For that reason, in a project it pays to check:

That every IED has a unique name and that no ICD is left with the name TEMPLATE in the system file.
That the GOOSE datasets do not exceed the maximum the device declares.
That every IED with a supervision function has a server.

With our IEC 61850 SCL viewer you can review the IEDs, datasets and subscribers of a file without uploading it to any server.

We can help with the configuration of your IEDs

If you need to validate a device file, integrate IEDs from several brands or find out why a subscription does not arrive, at Tiza Group we do it through our remote relay configuration. For the design and commissioning of the communication system, see our IEC 61850 engineering.

References

IEC 61850-6, edition 1 (2004): clauses 6.3 and 9.3.
IEC 61850-7-2: services whose capability SCL declares.
IEC 61850-8-1: meaning of the authentication methods and of the associations.

Frequently asked questions

Why does an ICD file have an IED called TEMPLATE?

Because it describes a type of device, not a specific one in the project. The system tool treats that IED as a preconfigured type from which it can create as many instances as it needs, giving each a unique name when it brings them in.

What is the difference between an IED with a server and one without a server?

With a server, the device offers its logical devices and nodes to others and can be supervised, because the LLN0 and LPHD nodes allow it to be monitored and controlled. Without a server, its nodes only act as clients and the device cannot be supervised over the network.

Does the IED section include the protection settings?

Not as such. It describes which data exist, with their default or configuration values, and which services the device supports. Manufacturer-internal parameters, such as how a data object relates to the terminals of a card, fall outside the standard and are handled by the vendor's own tool.