1885 sAddr length
- Created
- 22 Aug 2023
- Status
- In Force (green)Closed: the solution is part of the standard. No further comments are taken. Show the workflow
- Batch
- 57/2673/INFThis tissue went out with this batch, which was closed on 01 Apr 2024.
- Part
- Part 6 (2019; Edition 2.1)
- Links
- None
- Page
- 126
- Clause
- 9.5.4.3
- Paragraph
- 1
Issue
sAddr is defined as a short address for efficiency. The semantic here requires that the sAddr be shorter than the 61850 path to the referenced object. However, there is no explicit limit leading to issues with parsing.
Proposal
define max length of sAddr to 128, or possibly 256 at most.
| Discussion | Created |
|---|---|
| Must Implement in force - batch 2 | 01 Apr 25 |
| Solution Accepted solution accepted | 22 Apr 24 |
| Ballot Period Tests proposal accepted | 22 Apr 24 |
| Conformance Test Verification https://redmine.ucaiug.org/issues/6750 | 16 Apr 24 |
| In Force (green) Batch '57/2673/INF' (2) closed | 01 Apr 24 |
|
Conformance Test Preparation
All edition 2.1 ICTs shall restrict the length of sAddr attribute to 255 characters. All edition 2.1 SCTs shall accept an sAddr with length greater than 255 characters from ed1 and edition 2 devices representation, but remove the value when exporting an edition 2.1 SCD/SED |
12 Mar 24 |
| Analysis Of Compatibility no objection to the proposed solution | 12 Mar 24 |
| Verify Draft Implementation Agree on last draft to be implemented | 19 Feb 24 |
|
Drafting Implementation
I agree with _V3 implementation.
A tissue in force for Ed2.1 does not mean necessarily a change in the schema, but a "shall statement" to enforce the implementation in the ICT export and SCT Export. The next version (Ed2.2) can implement a dedicated pattern in the schema. |
13 Sep 23 |
|
Drafting Implementation
Bruce, current definition is still valid, so I propose to not indicates any thing regarding SCSM in the tissue itself.
But we can think of the removal of the SCSM usage in sAddr definition and reserve it for IED specific implementation. This can be done in amendment 2 if agree. But this is out of scope of the tissue itself. This can be treated in future improvement TF |
13 Sep 23 |
|
Drafting Implementation
updated proposal
One file is attached to this tissue. Sign in to open it. |
13 Sep 23 |
|
Drafting Implementation
Should we note in the TISSSUE that none of the SCSM up to now have specified sAddr in any way?
Therefore, the actual use of sAddr is exactly “used by a specific IED as an internal identifier”. My thought is that no future SCSM will ever specify usage of sAddr because too many existing devices already use this as a private internal identifier. |
13 Sep 23 |
| Drafting Implementation The new proposal is intended to split the proposal into interop tissue resolution and amendement 2 implementation | 13 Sep 23 |
|
Discussion (red)
To the most recent comment "any device in the field which requires unreasonably short sAddr attribute lengths (such as max length < 255) do not meet the standard (because 61850-6 does not constrain the length
To the penultimate comment, removal of the sAddr attribute would probably cause the originating device to fail because a common use of sAddr is to define mapping between 61850 and the device-internal database address. Therefore any downgrading rules will likely cause interoperabilty issues. |
28 Aug 23 |
| Discussion (red) This is an interop issue in that most devices in the field have fixed limits and will not process SCL with sAddr that are unreasonably long. | 28 Aug 23 |
|
Discussion (red)
Actually, the size limit is only a concern of the ICT which set it, and an SCT is only supposed to keep it and put it back. Any other tool may just ignore it.
Then, adding a constraint will bring a backward compatibility issue. Any device for previous edition which are not following the new constraint will not be able to be imported into a system in the newer edition. To address that, we need to have a new upgrading/downgrading rule for SCTs: - In SCD in newer edition, the non conform sAddr shall be removed (no need to try to keep it partially, as the ICT in newer edition do not need it, they are not the ICT which produce it) - In SCD iof the previous edition, the SCT needs to keep the value, to be able to give it back to the ICT in the SCD in its edition, otherwise the ICT will refuse the SCD as the sAddr will have been removed, even if the SCT knows the newest XSD with restriction This needs to be agreed to do this evolution. Then is it an interop tissue? Does it have in impact on the interoperability which need to make ed2.1 devices not conform if they are not following this limit? |
28 Aug 23 |
| Accepted to be discussed | 28 Aug 23 |
|
Triage
61850-6 9.5.4.3 states "... Otherwise, the short address value scope and syntax is private to the IED. Tools which do not handle short addresses shall also preserve imported contents in exported SCL files."
Because neither 61850-8-1 nor 61850-9-2 declare sAddr, then sAddr is private to the ICT (except that it must be processed by the SCT) Note that an ICT which imports sAddr attributes corresponding to other IED does not need to process sAddr in any way (and thus the length of sAddr is irrelevant.) The real issue here is "what is the maximum length sAddr which a SCT is required to process?" (because it is required to export sAddr from ICD/IID files) I agree with previous commenter that anything shorter than 255 could break some existing SCL configuration systems. |
24 Aug 23 |
|
Triage
For discussion:
"sAddr" and "intAddr" are having a kind of similar meaning (Manufacturer-specific internal address) and "intAddr" is already represented in the cdc = ORG with a length of 255 (VisString255), thus I would propose to have the same length of 255. Check for "sAddr" and "intAddr": - IEC 61850-6:2009+AMD1:2018 CSV clause 9.5.4.3 - IEC 61850-6:2009+AMD1:2018 CSV Table 33 - IEC 61850-7-3:2010+AMD1:2020 CSV Table 60 |
24 Aug 23 |
|
Triage
The terms "short" and "efficiency" stand out.
The maximum length of sAddr should be just enough for the purpose. The content will mostly be an identifier of a data point within a device in a vendor/device specific format. The length of an IEC 61850 object reference should probably not be a guideline. 128 should be plenty, maybe even less will do it. |
24 Aug 23 |