IED editor: Allow editing and instantiation of all values

[ca-d]

Some end users have expressed the desire to change IED configuration settings in the IED editor, but were unable to do so, because some of the "edit" and "add" icon buttons appear to be grayed out. With the discussion below I want to find out whether this is a bug or working as intended.

If it's a bug I propose to fix it. If it's working as intended I propose to enhance the IED editor by letting the user choose to be able to edit and instantiate all DAs, or at least to tell the user why the uneditable ones remain uneditable.

Discussed in https://github.com/openscd/open-scd/discussions/1283

^{Originally posted by ca-d July 28, 2023}
When trying to edit a LLN0.GrRef.getScrRef instantiated value which refers to an LDevice which is no longer existent, the "edit" icon is disabled and cannot be clicked.

Why are some "edit" and "add" icon buttons disabled in the IED editor? Is there a way we could enable them all?

[jarradraumati]

DAs under GrRef are of bType ObjRef, which isn't currently implemented in daiFieldTypes.

I believe ObjRef is a StringField, with a maximum length of 129 characters as per Edition 2.1. IEC 61850-7-2 is the place to look, but ObjRef from IEC 61850-6 is referred to as ObjectReference.

ObjectReference does have a syntax for the string, namely it begins with an @ character. I don't think this is correct, it appears to be only in certain scopes.

Note that Edition 1 defined ObjectReference as a VisString65.

I've tested fix locally. Happy to do a pull request.

[jarradraumati]

It looks like IEC 61850-6 has a few more attribute types that are not implemented as well:

<xs:simpleType name="tPredefinedBasicTypeEnum">
	<xs:restriction base="xs:Name">
		<xs:enumeration value="BOOLEAN"/>
		<xs:enumeration value="INT8"/>
		<xs:enumeration value="INT16"/>
		<xs:enumeration value="INT24"/>
		<xs:enumeration value="INT32"/>
		<xs:enumeration value="INT64"/>
		<xs:enumeration value="INT128"/>
		<xs:enumeration value="INT8U"/>
		<xs:enumeration value="INT16U"/>
		<xs:enumeration value="INT24U"/>
		<xs:enumeration value="INT32U"/>
		<xs:enumeration value="FLOAT32"/>
		<xs:enumeration value="FLOAT64"/>
		<xs:enumeration value="Enum"/>
		<xs:enumeration value="Dbpos"/>
		<xs:enumeration value="Tcmd"/>
		<xs:enumeration value="Quality"/>
		<xs:enumeration value="Timestamp"/>
		<xs:enumeration value="VisString32"/>
		<xs:enumeration value="VisString64"/>
		<xs:enumeration value="VisString65"/>
		<xs:enumeration value="VisString129"/>
		<xs:enumeration value="VisString255"/>
		<xs:enumeration value="Octet64"/>
		<xs:enumeration value="Unicode255"/>
		<xs:enumeration value="Struct"/>
		<xs:enumeration value="EntryTime"/>
		<xs:enumeration value="Check"/>
		<xs:enumeration value="ObjRef"/>
		<xs:enumeration value="Currency"/>
		<xs:enumeration value="PhyComAddr"/>
		<xs:enumeration value="TrgOps"/>
		<xs:enumeration value="OptFlds"/>
		<xs:enumeration value="SvOptFlds"/>
		<xs:enumeration value="LogOptFlds"/>
		<xs:enumeration value="EntryID"/>
		<!-- for 61850-8-1 Edition 2.1 -->
		<xs:enumeration value="Octet6"/>
		<xs:enumeration value="Octet16"/>
	</xs:restriction>
</xs:simpleType>

If we wanted to address all values, we'd need to implement some of these bTypes also if they are used in DAs.

[ca-d]

@jarradraumati thanks for your research on this issue, much appreciated! I'd love to see a pull request for this, if you have the time to prepare one! Would you include all missing attribute bTypes in that pull request? If not, do you think a "fallback" for missing types, which just allows me to edit the raw string content without any validation, would be a possibility?

@trusz I'd love to have this feature in open-scd; is there a good reason for the current behaviour or something speaking against supporting all bTypes in the editor?

[trusz]

I cannot asses from the engineering side. If there is a concrete pull request I am happy to take a look!

[jarradraumati]

I have done some further research. Some of these bTypes were intended to be "opaque" (IEC 61850-6 states that no values are required in SCL). I think that means that they are not intended to be instantiated within the data object as a DAI. The ones they list are:

• Quality
• Check
• Dbpos
• Tcmd
• PhyComAddr
• SvOptFlds
• OptFlds
• LogOptFlds
• TrgOps

I recommend we don't allow for editing of these bTypes, since it could lead to instability within the IED, or some rejection of the SCL file when it is send to the IED.

Therefore the only bTypes I think should be added are ObjRef, Currency and the three Octets (Octet64, Octet6, Octet16).

Currency is simply the three letter code as per ISO 4217. We could maintain a list of valid codes, but I'd rather leave it as a string with a maximum of three characters to avoid making another field function (unless someone is happy to create one). I have not seen this bType used in any of the IEDs I have encountered, but that does not mean it isn't used somewhere.

The octets are interesting. The IEC 61850 standard alludes to them being octet strings. There are several ways these can be represented:

1. In decimal (8-bit integer separated by spaces e.g. ddfsdfgghgjfse becomes 144 144 146 163 144 146 147 147 150 147 152 146 163 145)
2. In hexadecimal (64 64 66 73 64 66 67 67 68 67 6a 66 73 65)
3. In binary (01100100 01100100 01100110 01110011 01100100 01100110 01100111 01100111 01101000 01100111 01101010 01100110 01110011 01100101)

I'm unsure how to proceed. For now, I've made it a stringField, assuming the editor enters an octet string of hexadecimal values, with no zero padding, and no spaces. This is probably incorrect, but I don't have any example SCL files to look at to see how it's actually implemented in practice.

@ca-d I will create a pull request.