A namespace indicates in which document the meaning of a logical node, a data object or a data class is defined. Names from the standard are interpreted with the meaning of IEC 61850-7-4; anything added is marked with its own attributes (ldNs, lnNs, dataNs and cdcNs). The standard asks you to reuse what exists first, add data only if needed, and create new nodes as a last resort, always with documentation.
What the standard says and what it is for
Every class defined in IEC 61850 has a name and a meaning: XCBR is a circuit breaker (part 7-4), DPS is a “double point status” (part 7-3) and BRCB is a buffered report control block (part 7-2). If only classes from the standard are used, the meaning is the one the standard defines. But some applications need additional nodes, data objects or classes, and then a risk appears: the same name with different meanings.
Part 7-1 (edition 1, 2003) illustrates it with an example: the data object Pos on a circuit breaker is a status with four possible values; on the nacelle of a wind turbine it is a measured angle, from 0 to 360 degrees. Two data objects with the same name in different contexts need a way to be told apart. That way is the namespace: a reference to the technical document that defines the meaning of the instance.
Basic concept: a namespace is a repository of classes. A logical device is built with instances of the classes of one or several repositories, and each instance is marked with the repository that defines it, so that it can be interpreted without ambiguity.
The three namespaces of the standard
Part 7-1 defines three, which must be technical specifications:
| Namespace | What it contains | In the IEC 61850 series |
|---|---|---|
| Logical node | The node classes (and their underlying classes and services) of an application domain | IEC 61850-7-4, with 7-3 and 7-2 by reference, including the edition year |
| Data | The data classes of the domain, with the common data class used to create their attributes | IEC 61850-7-4, with 7-3 and 7-2 by reference |
| Common data class | The common data classes of the domain | IEC 61850-7-3 |
If a definition is a specialization of another, the name of the namespace is written chained with the symbol ”>”, which indicates specialization: name of the new namespace > name of the base namespace.
The four attributes that point to a namespace
| Attribute | What it applies to | Where it is | When it must appear |
|---|---|---|---|
| ldNs | The whole logical device | Name plate of the LLN0 node | Always, in every LLN0 |
| lnNs | A logical node | Name plate of the node | Only if it differs from the one declared in ldNs |
| dataNs | A data object | In the data object itself | Only if it differs from that of its node |
| cdcNs | The common data class of the data object | In the data object itself | Only if it differs from the one declared in its node |
Object references are, for example, LDName/LLN0.NamPlt.ldNs for the logical device and LDName/LNName.DataName.dataNs for a data object. The ldNs acts as a substitute for the lnNs in all or many of the underlying nodes. When edition 1 is applied as the main namespace, the value is “IEC 61850-7-4:2003”; for the common data classes of edition 1, “IEC 61850-7-3:2003”. Part 7-4 of edition 2 (2010) keeps, in an annex, the obsolete nodes of edition 1 “for backward compatibility with the namespace indication of edition 1”.
Part 7-1 illustrates the case with a standard logical device to which a data object from another namespace is added: only two marks are needed to interpret it without ambiguity: the ldNs of the device and the dataNs of the extended data object. The common data class used does not need to be marked if it is implicit in the definition of that namespace.
When to reuse, extend or create
Part 7-1 (figure 77) and part 7-4 (annex A) give the extension rules. The rules are these:
- Break down the required function to the level of detail of the existing nodes.
- If a standard node covers it, use it with all its mandatory data. If there are dedicated versions of the same function (ground and phase, zones A and B), separate instances of that node are used.
- If the node covers the essentials but some data is missing, add it: first an optional data object that fits; then one of the standard data objects of clause 6 of 7-4; and only if none serves, a new data object.
- If no node covers the function, define a new node, which can reuse data already defined in other nodes or carry new data.
- Assign, if needed, a prefix and an instance identifier of your own.
- Does a standard logical node cover the function?
- Yes: Use the node as is and configure it (several instances if there are dedicated versions)
- No: Is it enough to add data to an existing node?
- Yes: Are there standard data objects that fit?
- Yes: Use the node and add those existing data objects
- No: Use the node and define the new data object, marked with its namespace
- No: Are there standard data objects that fit?
- Yes: Define a new node with existing data objects
- No: Define a new node with new data objects, marked with their namespace
- Yes: Are there standard data objects that fit?
Additional rules from annex A of part 7-4:
- Other forms of extension are not allowed in substation automation.
- A data object needed several times is repeated with a numeric extension (HPTmp1, HPTmp2 and so on), with the semantics of each in its description.
- The name of a new node starts with the letter of the corresponding group, the remaining characters are formed from the English name, and it must be consistent with the standard names and unique in the system. Examples from the standard: ADEC, automatic door entry control, and ZFPT, transformer fire protection.
- A new data object uses the abbreviations of clause 4 if they apply, is assigned to a single common data class and is marked with its namespace attribute.
- A new common data class is created only if no existing one serves; it is governed by part 7-3 and is also marked.
- The creator must guarantee uniqueness and consistency, and document and publish the definition together with the system or project.
The standard insists on using these options “with care” to keep interoperability simple.
Three approaches to new semantics
Part 7-1 (clause 15) compares three ways to define a new data object, with an example of the average outdoor temperature at a substation, over one hour and over ten minutes:
| Approach | How it is defined | Advantage and limit |
|---|---|---|
| 1. Fixed semantics | Two data objects with names that fix the meaning (TmpMean60 and TmpMean10), both of the “measured value” class | Simple, but the meaning cannot be changed |
| 2. Flexible semantics | Two data objects (TmpMean1 and TmpMean2) and four setting data objects that fix the interval and the start of each | Configurable, but requires declaring more data in the node |
| 3. Reusable flexible semantics | A new common data class (MVStat) that includes the value, the interval and the start | Simplifies the node table, keeps the configuration inside it and is reusable in any data object with the same attributes |
How it is implemented, in general terms
In a project, the decision to extend is made in writing and before configuring: which function is not covered, which standard options were ruled out, and how the new element will be named, defined and documented. In the device, the extended elements are declared with their namespace attributes and, in SCL, with type templates and extensions as described in DataTypeTemplates in SCL and SCL files.
The risk of a custom extension is interoperability: other devices and the SCADA do not know its meaning unless they receive the documentation. That is why, before extending, it is worth evaluating whether the client or the integrator can receive that data as a standard attribute with another instance. For the context between editions, see IEC 61850 editions 1, 2 and 2.1.
We help you with your data model
If your project needs to represent a function that the standard does not cover, or if some devices have their own data objects that the SCADA does not interpret, at Tiza Group we evaluate the best way to model it within the standard, through our remote relay configuration. For system design, see our IEC 61850 engineering.
Related guides
- IEC 61850 information model: LD, LN, DO and DA
- Logical node names in SCL: prefix and class
- IEC 61850: what it is, parts of the standard and data model
- IEC 61850 editions 1, 2 and 2.1
References
- IEC 61850-7-1, edition 1 (2003): clauses 14 (namespaces) and 15 (approaches to new semantics).
- IEC 61850-7-4, edition 1 (2003): annex A (extension rules); edition 2 (2010), annex C (obsolete nodes).
- IEC 61850-7-3, edition 1 (2003): attributes ldNs, lnNs, dataNs and cdcNs and their presence conditions.
Frequently asked questions
What happens if a manufacturer uses the name of a standard data object with a different meaning?
That is exactly what namespaces prevent. The same name, such as Pos, can mean the position of a circuit breaker in one context and the angle of a wind turbine nacelle in another. Without a reference to the namespace, the meaning of the instance would be ambiguous to whoever receives it.
When is it mandatory to indicate the namespace of a data object?
Only when it differs from the one already declared at a higher level. The logical device declares the main one in the LLN0 node; a node indicates it only if it departs from that, and a data object only if its namespace departs from that of its node. If everything is standard, there is no need to repeat it.
Can you add your own data objects to a standard logical node?
Yes, but with rules: first a standard data object that fits is used; if data objects repeat, numeric extensions are used; only if nothing covers the need is a new data object created, assigned to a common data class and marked with its namespace. In substation automation no other kinds of extension are allowed.