1951   I35 modification of data model doesn't accomodate dual role (ICT + SCT) tools

Created: 07 Jan 2025

Status: Discussion (red)

Part: Part 6 (2025; Edition 2.2)

Links:

Page: 241

Clause: Annex G

Paragraph: Table G.1 Row I35

Issue

This regards the detailed discussion found in this Redmine item that was recently resolved to address this topic: https://redmine.ucaiug.org/issues/6617

Some tools fill the role of both ICT and SCT, but the issue is that the wording of I35 and subsequent part 10 items are currently too restrictive and would prevent effective use of a tool in both roles.

Proposal

It was concluded to revise the wording of requirements/test cases in 61850-6 and 61850-10.

New wording can be found in the attached proposal document, note that it proposes specific wording changes to four items:

61850-6 I35
61850-10 tIieN1
61850-10 tIieN2
61850-10 tIieN3

Discussion Created Status
I may have another proposal radically different to accommodate both vision.

I propose to make IID export mandatory and tested only for ICT modifying the IED and exchanging with an external SCT. 		03 Mar 26 Discussion (red)
In response: when configuring a single-vendor system, it creates unnecessary burden/complexity for the user to have to switch "modes" of the application repeatedly during their engineering process.

Also, any engineering process requires the user to understand what they are doing. Even if a tool has separate modes, the user can still switch modes and delete something disruptive. They could even switch back to ICT mode and export the (now incorrect) IID, creating the exact same problem.

The mode switch does not make up for the user needing to understand the engineering process steps. As a matter of principle we need to remain light-weight on limitations the standard imposes on what the user is allowed to do; otherwise it will start to delve into mandating user experience and user interfaces.

Recall this principle stated in 61850-6:

"NOTE It is not in the scope of this standard to define any details of concrete software tools, which support an engineer in doing the intended engineering process with SCL as described above...Each manufacturer is completely free to find the best way to support engineers by a specific software tool." 		13 Oct 25 Discussion (red)
I disagree with the proposal because it allows the tool to generate an invalid IID file (albeit after warning the user). What is the SCT supposed to do upon attempt to import this IID file? If the SCT rejects the file, then the user has no way to recover from this error because the dataset/control blocks have already been permanently removed from the IED model (and the IED has presumably already been updated to reflect this invalid IID). In this case there SHALL be a requirement of the ICT to have infinite levels of *undo* capabilities to recover from this error.

I think the better approach (detailed in https://redmine.ucaiug.org/issues/6617) is to require a mode switch for dual role ICT/SCT tools where ICT role generates the (always valid) IID file and SCT role consumes the (now always valid) IID file 		10 Oct 25 Discussion (red)
review proposal 10 Oct 25 Discussion (red)
accepted 10 Oct 25 Accepted

 

Privacy | Contact | Disclaimer

Tissue DB v. 26.3.9.1