Every status a technical issue can be in, and the steps the workflow allows between them. The status this tissue is in now is the box drawn in bold.

Hide the workflow

TissueDB status workflow back to Discussion Batch Triage Accepted Discussion Drafting Implementation Verify Draft Implementation Analysis Of Compatibility Conformance Test Preparation Conformance Test Verification Ballot Period Solution Accepted Must Implement In Force Approval (N/A) Approval (Duplicate) Approval (Editorial) Approval (Future Improvement) Not Applicable Duplicate Future Improvement Editorial Must Implement (Editorial) In Force (Editorial) Legend normal route of a technical solution accepted or released → in force classification branch (working group approval) back to Discussion for rework (lines are bundled) reaching the final state
The route a technical solution takes from Triage to In Force, the working group approvals that close an issue instead, and the ways back to Discussion for rework. Opens full size in a new tab.

2019 Table 50 needs clarification regarding IED=y

Created
16 Jan 2026
Status
TriageNew, and not yet classified. The working group decides whether to take it forward as a technical issue or to close it. Hide the workflow
Part
Part 6 (2025; Edition 2.2)
Links
None
Page
103
Clause
9.3.2 The IED, Services and Access Point
Paragraph
24

Issue

The paragraph preceding Table 50 states:
"Table 50 shows which service capabilities can be defined at which level. The IED column declares if only at IED (y) or also at access point level (n), and the Server / ServerAt column, which one can be different to the referred server at a ServerAt element."

This paragraph indicates that some capabilities can be unique to an AccessPoint, while other capabilities must be specified for the entire IED. It does not explicitly state that some SCL elements or attributes can only be present in the IED/Services.

But SCD files from past IOP events indicate that this paragraph has been widely interpreted to mean that an element or attribute is not allowed to be present in AccessPoint/Services if the IED column has 'y'.

An earlier paragraph states that AccessPoint/Services "... shall not contain IED general configuration or engineering-related capabilities like ConfLNs, ConfLdName or ValueHandling -- these shall be defined at the IED level." So, at least for those elements it is clear that they can only be specified in IED/Services.

But, following XML schema rules, if nameLength is omitted from AccessPoint/Services, then nameLength gets its default value of 32. So, if IED/Services has nameLength=64 and nameLength is omitted from AccessPoint/Services the definitions would differ.

This tissue was entered at the request of the WG 10 OCL Task Force which is working on an OCL rule to verify that IED/Services and AccessPoint/Services are consistent with Table 50.

Proposal

I propose adding a clarification that nameLength shall be ignored for AccessPoint/Services.

Additional clarification of the paragraph preceding Table 50 may also be helpful.

DiscussionCreated