UCAIug Issue Tracking System: Issueshttps://redmine.ucaiug.org/https://redmine.ucaiug.org/favicon.ico?15861924492024-02-07T10:55:45ZUCAIug Issue Tracking System
Redmine 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6699 (New): Behavior of a function while being dynamica...https://redmine.ucaiug.org/issues/66992024-02-07T10:55:45ZKeith Gray
<p>LN.blk is active.<br />What happens with the functionality such as timers and outputs?</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6606 (New): CPU monitoringhttps://redmine.ucaiug.org/issues/66062023-11-21T14:40:37ZVladan Cvejic
<p>Add a LN allowing to monitor CPU state of an IED (CPU load, temperature, available RAM and disc space, ...).<br />These informations could be used in client as local / remote HMI to monitor the substation.</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6555 (New): Behaviour of output contacts when LN is in ...https://redmine.ucaiug.org/issues/65552023-10-26T07:52:10ZKeith Gray61850-7-5 and 61850-7-500 - IEC61850-7-5 #6408 (New): Clarification of addCausehttps://redmine.ucaiug.org/issues/64082023-06-20T13:37:59ZVladan Cvejic
<p>1. The standard identifies addCause, but its use should be explicitly defined by requirements associated to the application. The use and the expected behavior may be different for CB or disconnectors and also depend on other criteria.<br />example: "invalidPosition": depending on the object, a rejection of the command may be wished for a disconnector, but not for an opening command of a CB.</p>
<p>2. Besides, some cases has to be clarified:<br />25 "none" : why is this addCause necessary, normally they are associated at a refusal. Clarify use?<br />23 "abortion by communication loss": this addCause cannot be sent in case of loss of communication. Clarify use. Log?<br />26 "inconsistent parameter" conform if used for test of parameters of command or for sequence number of command (cybersecurity)<br />20 "non access authority" -> which are the associated controls?<br />=> Associated controls need to be explicitly specified for each addCause for interoperability reasons. Specially important for 20 and 26.</p>
<p>3. At least, how to access to addCause for other functions than the client and server concerned. Proposal : creation of attribute ENUM associated to addCause ?</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6394 (In Progress): Clarifications on the local/remote ...https://redmine.ucaiug.org/issues/63942023-06-14T13:23:03ZVladan Cvejic
<p>Annex B, Table B.1 states that "Manual Control at switch (process)" was always allowed. Isn't it the status of a control switch modelled as XCBR.LocKey="true" which releases the manual control at the switchgear? As long as this control switch is not activated, manual control is not possible. To prevent from switchgear controls other than local during this time, as long as XCBR.LocKey="true", no control issued by the IED is accepted.</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6393 (In Progress): Clarifications on the local/remote ...https://redmine.ucaiug.org/issues/63932023-06-14T13:22:48ZVladan Cvejic
<p>Add a statement in the description text of 'MltLev' that this setting effects all contained LN instances of that LD.<br />Is the dependency of 'MltLev' limited to contained LN instances of that LD or, in the case of nested LD, including also subordinate levels?</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6392 (In Progress): Clarifications on the local/remote ...https://redmine.ucaiug.org/issues/63922023-06-14T13:22:18ZVladan Cvejic
<p>Add a statement in the description text of 'SwModKey' that this setting effects all contained CSWI LN instances of that LD.<br />Is the dependency of 'SwModKey' limited to contained CSWI LN instances of that LD or, in the case of nested LD, including also subordinate levels?</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6391 (In Progress): Clarifications on the local/remote ...https://redmine.ucaiug.org/issues/63912023-06-14T13:21:58ZVladan Cvejic
<p>Add a statement about the dependency of 'LN.Loc' contained in LD from LD/LLN0.Loc (and LocSta, as applicable). Is this dependency limited to contained LN instances of that LD or, in the case of nested LD, including also subordinate levels? (see Tissue 1778)</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6390 (In Progress): Clarifications on the local/remote ...https://redmine.ucaiug.org/issues/63902023-06-14T13:21:41ZVladan Cvejic
<p>Add a statement about the dependency of LD contained LN.LocSta from LD/LLN0.LocSta . Part 7-1 clause 6.4.2.1, Figure 14 states "for complete LD". Is the statement in the figure applicable for 'MtlLev' only or for both 'MltLev' and 'LocSta'?</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6389 (In Progress): Clarifications on the local/remote ...https://redmine.ucaiug.org/issues/63892023-06-14T13:21:22ZVladan Cvejic
<p>Add a statement about the use of XCBR.Loc (and similar LN classes). Assume XCBR.Loc="true". Will protection trips and switchgear controls by GAPC be rejected?</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6388 (In Progress): Clarifications on the local/remote ...https://redmine.ucaiug.org/issues/63882023-06-14T13:21:03ZVladan Cvejic
<p>Add a statement about the intention of the L/R concept. Specify whether the L/R concept is applicable for operator controls exclusively, not for switchgear controls in general.<br />Assume LD/LLN0.Loc="false". Will a switchgear control by GAPC (orCat="automatic-bay") be executed?</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6382 (New): Clarification on the ctlModel 1/3https://redmine.ucaiug.org/issues/63822023-06-14T13:18:49ZVladan Cvejic
<p>What is the purpose of 'ctlModel' at X group level, Y group level respectively? Operator switchgear controls are managed by CSWI LN, so a Select to allow the operator to think twice before Operate is not needed on X group level.</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6380 (New): Clarification on the ctlModel 2/3https://redmine.ucaiug.org/issues/63802023-06-14T13:18:12ZVladan Cvejic
<p>Add a statement about the relation between the 'ctlModel' of the controller LN and the 'ctlModel' of the proxy LN, e.g. CSWI.Pos--XCBR.Pos or ATCC.TapPos--YLTC.TapPos .The ctlModels can be different/must be the same?</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6379 (New): Clarification on the ctlModel 3/3https://redmine.ucaiug.org/issues/63792023-06-14T13:17:56ZVladan Cvejic
<p>Add a statement about the use of the 'ctlModel' that it is applicable for XCBR.Pos when subscribing to CSWI.Sel* and CSWI.Op*, but is bypassed when subscribing to PTRC.Tr . Note that both the Operate and the trip are of CDC ACT.</p> 61850-7-5 and 61850-7-500 - IEC61850-7-5 #6378 (In Progress): Clarifications on the local/remote ...https://redmine.ucaiug.org/issues/63782023-06-14T13:17:34ZVladan Cvejic
<p>Add a statement about the intention of the L/R concept. Specify whether the L/R concept is applicable for the control of switchgear exclusively, not for controls in general. Note the saying "if the LN class includes 'Loc' and 'LocSta' data, then this LN class falls under L/R". Applicable for
{ANCR, ARIS, ATCC, AVCO, CCGR, CSWI, CSYN, FSPT, GAPC, GGIO, IHMI, ITCI, KFAN, KFIL, KPMP, KVLV, LLN0, RSYN, XCBR, XSWI, YEFN, YLTC, YPSH, ZRRC}<br />Within such an LN class, clarify/list the controllable objects which fall under the L/R concept, e.g. 'XCBR.Pos' - yes, 'XCBR.OpCntRs' - no</p>