1983   Configuration data-attributes(FC=CF) and there default values

Created: 07 Jul 2025

Status: Discussion (red)

Part: Part 6 (2025; Edition 2.2)

Links:

Page: 167

Clause: 9.5.4.4

Paragraph: 9.5.4.4

Issue

Enum have a default value in the DataTypeTemplate section if there is a <Val/> element, and/or there is a specific value with a <Val> element in the DOI/DAI section.

Without <Val/> there is no value in SCL.

The only specification is that values in the SCL shall match the values in the SCL. And that all ctlModel shall have a value in SCL (but not for example operTimeout/sboTimeout/Unit.multiplier/...).

Proposal

We should extend that to all CF attributes: e.g. All CF attributes need a value in SCL (either in DTT or DOI/DAI section).

Discussion Created Status
TISSUE suggests that all CF/SP values are exposed as literals in the SCL file.
However, 61850-80-5 exposes only the MAPPING of the value to a (Modbus) protocol value and does not expose its actual VALUE.
Note that the mapping is done via a *Private* element (which is to be ignored by other IEDs).

Two thoughts about this:
1. Allow the *Val* element to be replaced by any *Private* element (or perhaps only "standardized" private elements)
2. Require a change to 61850-80-5 to insert a *Val* element in parallel with the existing *Private* element to declare the default value 		01 Apr 26 Discussion (red)
valKind="RO" and "Set" does not seem to express the range of use cases.
I think valKind="Set" means that it is readable/writable over the 61850 communication channel and therefore must be read each time it is used (or else the parameter version number means to be consulted).
valKind="RO" means that the value in the SCL file can be taken as the current value (and it implies that unless a new SCD is created then the value has not changed).

This leaves the use case "not writable over 61850 but is writable by other means" which might require another value for valKind other than Set or RO. 		20 Mar 26 Discussion (red)
There is always an initial value for any setting available somewhere.
According to 7-2 initial value shall be as configured.
How can users be satisfied with setting values that cannot be documented?

A function uses the setting initial value to work, and the impact of the change of the setting value (offline or online) need to be tested during functional testing.

Valkind Set mean that the value can change over time, and that the read value from the device may deviate from the initially configured value. Changes of setting values are visible in service tracking (GenTrk), paramRev and valueRev.

In other word, the presence of the element Val in an SCL file for documenting the value of the setting (SG,SE,SP) or CF shouldn't be depending on the valKind of the attribute.


18 Mar 26 Discussion (red)
Note that valKind="Set" is understood to mean the value could be changed after IED configuration via a request from a client.
While valKind="RO" is understood to mean the value can only be set at configuration time.
Another possibility that cannot be conveyed via the valKind enumeration is that the value is set after IED configuration via "local" means such as an HMI. In this scenario, it may not make sense to expect a value to be present in the SCL and match the online value.
03 Mar 26 Discussion (red)
Please clarify whether this applies to SE/SG as well. 17 Feb 26 Discussion (red)
Decision from the WG10
- We mandate to have a value in CF and SP when valKind is Conf or RO (either at type or instance level). In addition, the value written in the SCL shall be the same as in the IED (conformance testable)
- We allow to have a default value for Set which has to be used on IED loading, but with warning that it may not be the same as in IED and recommend to read it instead of trust SCL
- When user change SetToRO, the value become mandatory
- This applies only to configured devices (not templates) 		13 Feb 26 Discussion (red)
TPWG:

Probably should be discussed in WG10 as this is likely a large impact to implementors. 		11 Nov 25 Discussion (red)
ensure statement in part 6 to mandate without ambiguity the configuration of a value for CF/SP in SCD.

Will need an update of the SICS 		10 Oct 25 Discussion (red)
accepted 10 Oct 25 Accepted

TPWG agrees that all CF,SP, should have initial values recorded in the SCL file.

Note: this applies only to a fully configured device, i.e. not ICD or intermediate files.


Settings Groups seem to have details that need to be investigated further. It's not clear whether the complete number of SGs the device supports must be configured. Consider restricting activation to Groups that have been described in the SCL. 		02 Sep 25 Triage
In my opinion, a certification test-case should check this circumstance! 04 Aug 25 Triage
Please note the definition of FC=CF in IEC 61850 - Table 4.
"Initial value shall be as configured; value shall be non-volatile".
Therefore, per 7-2, there shall be a <Val> in the SCL file for each CF attributes.

23 Jul 25 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 26.5.15.1