IEC 61850 User Feedback Task Force

n?;Source;Unique ID;Subject;Priority;Tracker;RM Status;Description;Category of issue;Severity;Who handles the issue?;Part;Short Proposal;IEC TC57  WG10 proposal;Estimated completion date;Status;Suggestion;Modified

1;ENTSO-E;1 # ENTSO-E;"There may be problems by exchanging SCL files between tools.

In this particular case, this may be associated with TISSUE 425.

A";High;Bug;Closed;"There may be problems by exchanging SCL files between tools.

In this particular case, this may be associated with TISSUE 425.

As an example, we've experienced problems with importing SCL files (CID file for exemple with SBO function) from one vendor to another. We had to make small adaptations in the SCD file (add manually SBO, although SBO was mentioned in the CID) in order to make it work. When bringing this to the attention of the concerned manufacturers, they replied that their IED (and therefore the SCL file) is certified and therefore not the source of the problem.";;serious;WG10;;"We will get the files and analyse the issues; will be handled between Diederik Moers and Thierry Dufaure";"The issue came from ENTSO-E and  in particular from ELIA. 

Because there is no action. It is decided to close the issue.";June 2014 WG 10 Meeting;Closed;;

2,1;ENTSO-E;2,1 # ENTSO-E;Selection of mandatory/optional fields in DA and DO in class definition of LN. So far there is restriction to Vendor opinion wha;Medium;Feature;Closed;Selection of mandatory/optional fields in DA and DO in class definition of LN. So far there is restriction to Vendor opinion what is needed and what is not. Also, the standard gives no restrictions for using optional features, as well as proprietary extensions. At the same time, no guidelines for handling such features are given. Meaning of ?optional? keyword is not clear in the context of data exchange: is the receiver of information required to be able to process any number and combination of optional elements, or the provider of information is required to be able to tailor the information to the specific client. Issue is not related to the functionality (thus the Data itself) requested by the user and not supported by IED, but to the problem where Vendor impose gathering of Data that are not requested by user (not needed). Each Vendor can expand structure of elements and that definitively has impact on the interpretation of the rest of structure. There could be a problem that will manifest as induction of specialized processing of each Data on the receiver side even though the Data are of same type but they come from IEDs of different Vendors.;Standard clarification required;usage;WG10;;"There is obviously some confusion, what ""optional"" means.";"Improve the description in part 1 and/or 4 and/or 7-1 of the standard, what optional data / data attributes means.

A user may specify that he requires certain optional data, but the user then has to verify with the vendor, if the vendor supports the optional information.

In many cases, the presence of optional data depends as well on the functionality.

Closed because it is written into the 7-1 and available for comment.";Ed 2.1 or Ed 3;Closed;;

2,2;ENTSO-E;2,2 # ENTSO-E;Optionality of DO/DA from the point of view of users;Medium;Feature;Closed;;Requirement Spec of user;usage;User;;If a user requires a particular DO/DA that is optional (and hence the functionality behind), this needs to be specified as a functional requirement by the user.;The user shall include in the requirement specification for a project, what optional information is needed.;;Closed;;

2,3;ENTSO-E;2,3 # ENTSO-E;Configuration of datasets by users;High;Bug;Closed;;Requirement Spec of user;serious;User;;To avoid data beeing transmited to the client that is not needed (reporting, GOOSE), datasets should be configurable by user within the IEDs ;User configurability of datasets for reporting and GOOSE should be required for multifunctional IEDs;;Closed;;

3,1;ENTSO-E;3,1 # ENTSO-E;"""Vendor/User? and ?Vendor/Vendor? Interoperability list (structure of User ?mandatory? fields, an agreement between two parties";Medium;Feature;Closed;"""Vendor/User? and ?Vendor/Vendor? Interoperability list (structure of User ?mandatory? fields, an agreement between two parties what is required and fulfilled (Data types, LNs, services, modeling, comm. requirements, etc)) as in IEC 60870-5-101/104. This is not fulfilled by PICS (Protocol Implementation Conformance Statements that contain information (could typically be optional parts, specific restrictions, or add-ons) regarding the ACSI). PICS are Vendor statements of what IED is capable of.

There should be User document to correlate to Vendors specifications and mitigate implementation problems.

These types of lists/tables latter allow describing the communication between subsystems.

";Solved / Missunderstanding;usage;User;;(1) To my knowledge, the PICS in 60870-5-101 / -104 are more or les the same like the pics in 61850. A vendor can use that list to declare what his device is supporting, and a user can include that list in his requirement specification.;"PICS can be used as part of requirements specification as well as the services section of an SCL file as described in Part 6, Table 11.

A user neeeds to make sure that they receive ICD files that include the service section.";;Closed;;

3,2;ENTSO-E;3,2 # ENTSO-E;Also PICS, MICS and other statements should be formally defined in such a way to ease the detection of potential interoperabilit;High;Bug;Closed;Also PICS, MICS and other statements should be formally defined in such a way to ease the detection of potential interoperability issues by the end users.;Standard extension required;serious;WG10;;"(2) In the SCL / Service element the PICS as well as additional information about limitations is already provided in a formal way. In addition, PIXIT are defined today in the context of conformance testing; Some PIXIT are today not  formally described in SCL. Proposal to extend the service element of  the IED to cover 100%";"Make sure that all information that is in PICS or in PIXIT and relevant for engineering capability / functionality is included in the service element of SCL

Meeting June 2014: the only PIXIT to transfer to SCL was about configuration of some addresses (PSEL, etc); conclusion was that the parameters shall be declared by servers in the communication section of ICD/IID files.";Will be put in Ed 2.1 of part 6;Closed;;

4,1;ENTSO-E;4,1 # ENTSO-E;Too loose or non existing guideline for organization of structure tree (construction of each LD, LN etc). Manufacturer is fillin;Medium;Feature;In Progress;Too loose or non existing guideline for organization of structure tree (construction of each LD, LN etc). Manufacturer is filling with their own private parts. Usage of GGIO to cover more then signaling part (wide range of protection function parameters are not covered with predefined LN's). Continuous standardization work is required to standardise commonly used data and data attributes such as protection parameters that are found in most IEDS developed for our domain. ;Standard extension required;usage;WG10;;"These are a couple of different issues

(1) The requirement to standardise logical devices was not idientified so far and goes beyond the interoperability requirement. However, it would help to the end user to understand the functionality of an IED and to harmonise between projects from multiple vendors. With the new concept introduced in part 6, to describe functions / subfunctions, it was as well the idea that the standardisation domains shall define types for functions and subfunctions. This can be a first step. It needs to be discussed if functions / subfunctions shall correlate to logical device hierarchies";"WG to define types for functions / subfunctions and possible correlation of logical device hierarchy

to be adressed to the 61850-6-100 (need a realistic date)

";"Will be solved with extension of SCL to define function types and subtypes. Input will as well be coming from ENTSO-E

DC1 should be soon, but we do not know. Let's see the plenary report";Assigned;;Virtual-06-20

4,2;ENTSO-E;4,2 # ENTSO-E;Data models using GGIO too much;High;Bug;Closed;;Implementation - improve conformance testing;serious;WG10;;"(2)Use of GGIO, when a standardized object is available, is not confrom to the standard. We need to find a way to do ""modelling assesment""  - but that is not that easy since modeling may always be an issue of interpretation.";"Today, we have a draft 7-500 that describes the correct usage of LNs for a certain application. This can help the user for the discussion with the vendor about the data model as well as a basis for a specification of the required data model.

As long as we do not have standardised basic application profiles, we can however not do a formal conformance test on that.

The TF UF shall in a first step develop a guideline on how such a BAP shall be defined and what is the process to develop these BAP in close cooperation with the users.

Closed because taken into account by another BAP-TF (7-6).";"First step to develop guideline / process for BAP

First Draft by June 2014 (Wolfgang Brodt / supported by Patrick Lhuillier)

Expected completion by End of 2014";Closed;;

4,3;ENTSO-E;4,3 # ENTSO-E;Protection parameters not defined in P logical nodes;Medium;Feature;Closed;;Profile or Guideline;usage;User;;(3) Protection parameters are today optional and not all of them are defined. Work is ongoing to define more. At the end, the user needs to specify the requirement to have the protection parameters available in IEC 61850 format;A users group may require in a profile or guideline for protection IEDs, that all configuration parameters shall be exposed to IEC 61850 - either using standardized ones or doing model extensions;;Closed;;

5;ENTSO-E;5 # ENTSO-E;There is a general issue that when we have signals connected to generic inputs, typically it is not possible to associate these;Low;Support;Closed;There is a general issue that when we have signals connected to generic inputs, typically it is not possible to associate these signals to a LN other than GGIO in the vendor tools.;;;WG10;;"It would be recommended, that the IED configuration tool allows to the user to reconfigure the data model to match the semantic of the connected input.

There are two cases to differentiate:

- the signal is coming from an external equipment (e.g. a fan or a transducer)

- the signal is a proxy of a function in a legacy device (e.g. an external gas density monitor or a conventional protection device)

While the first case is not critical, we just would expect the IED configuration tool to allow reconfiguration of the signal name, for the second case it must somehow be possible to dientify, that the functionality associated with the LN is not realised in the device itself. This can e.g. be handled by putting all these logical nodes in a dedicated logical device that declares to be a proxy.

It needs as well consideration, if it shall be possible that the user can create his own namespace. And finally, we need to make sure that the resulting models are correct (i.e. mandatory data are present.";"June 2014: First draft of a recommendation has been provided by Pierre; need to continue work including a recommendation.

May 2015: ENTSO-E Issue #5:

There is a general issue that when we have signals connected to generic inputs, typically it is not possible to associate these signals to a LN other than GGIO in the vendor tools.

Recommendation:

The IED configuration tool should allow the user to reconfigure the data model to match the semantic of the connected input.

The resulting models shall be correct (e.g. mandatory data are present).

The implementation of this functionality is facilitated thanks to the machine processable format (IEC 61850-7-7). 

Use case 1: the signal is coming from an external equipment (e.g. a fan or a transducer)

NSD files contain the IEC 61850 object models in an XML format. They are published by the IEC and are classified by their namespace identifiers, version and revision numbers.

They can be used by an IED configuration tool to create the IED data model. It is assured then that the implementation of the data model follows the rules from the standard definitions of IEC 61850-7-2, IEC 61850-7-3, IEC 61850-7-4 or any other application domains (like IEC 61850-420, DER).

Thus by means of the IED configuration tool, the user can create/modify the data model of the device. The only limitations are the name spaces and their content supported by the device, in particular the CDCs. It is even possible for the user to create its own name space provided that the naming conventions from IEC 61850-7-2 and the strict use of IEC 61850-7-3 (i-e no extension of CDCs) are followed by the user. It is recommended that these rules be enforced by the IED configuration tool.

Use case 2: the signal is a proxy of a function in a legacy device (e.g. an external gas density monitor or a conventional protection device) 

This can be handled by grouping the signals in logical nodes whose definitions come from the NSD files (similar to use case 1).

It must also be possible to identify that the functionality associated with the LN is not realised in the device itself. This can be handled by grouping the LNs in dedicated logical devices that declare to be proxies (ref. IEC 61850-7-1).";"in a first step, WG10 shall prepare a recommendation considering all the consequences; we then will have to decide what goes where

(lead: Pierre; support Thierry, Chris, Christoph, Rogerio, Nicolas, Camille) by November 2014 Meeting";Closed;;

6;ENTSO-E;6 # ENTSO-E;Substation part in SCL is mostly non existing in manufacturers scd export files and in form that is defined as in Standard. Subs;Low;Support;Closed;Substation part in SCL is mostly non existing in manufacturers scd export files and in form that is defined as in Standard. Substation part in ?configured? SCLs should not be optional as this is the only way to link certain function to a part of substation Manufacturers tool for this feature.;Standard clarification required;;WG10;;According to IEC 61850-6, it is intended that the substation section is mandatory for an SCD file. But the SICS for System Tools say that the production of a substation section is optional.;"This needs to be harmonised in the standard. 

The minimum production of the substation section  to be discussed further,  (which detail in this section) creation of a new issue.

Closed because it is done";Ed 2.1 FDIS of part 6 in order to be mandatory;Closed;;

6,2;ENTSO-E;6,2 # ENTSO-E;SCD from system integrator not containing comprehensive substation section;Low;Support;Closed;;Requirement Spec of user;;User;;During system configuration, a valid and comprehesive substation section shall be produced;Require a comprehensive substation section as part of the SCD file delivered by the system integrator;;Closed;;

7,1;ENTSO-E;7,1 # ENTSO-E;Standard is written in general opinion that Ethernet is fully capable to carry all its tasks. Too often huge amount of data are;Low;Support;Closed;"Standard is written in general opinion that Ethernet is fully capable to carry all its tasks. Too often huge amount of data are transferred to the MMS client because the information that is needed cannot be separated in the model. Typical example is sending entire DO structure for measurements when only measurement value and quality are needed. Guidelines for data modeling are needed. 

This is not solved by support of DataSets with FCDA because in Standard Ed1 (page 86, 7-2) is defined that if elements of DataSet are stVal, q and t (as attributes!), on change of stVal report will be sent only with stVal (without q and t). So, even if device support DataSet with FCDA, it won?t send all elements of the structure that are requested/required.

IEDs shall support each variant of FCDs and FCDAs in their DataSet configuration. For example FCD with only first part of the Data Object Name, as well as FCDs and FCDAs with more levels.";Implementation - improve conformance testing;;UCA Testing committee;;"Some devices do not support to configure FCDA, but this is not conform to the standard and should be identified by conformance testing. 

In ed2 it is intended to make it mandatory to support all levels (MMXU.PhV, MMXU.PhV.phsA, MMXU.PhV.phsA.mag). ";"7-2Ed2 ? 13.2.2.3 already declares all mandatory. Conformance testing for Ed2 must be extended to verify that based on tissue that needs to be created for part 10.

Closed because it is done";"(41579)

Conformance tests : SDS15, SRP15, SGOPxx";Closed;;

8;ENTSO-E;8 # ENTSO-E;Implementation and integration software of different manufacturers should have same mandatory tasks in order to be used as tools;Low;Support;Closed;Implementation and integration software of different manufacturers should have same mandatory tasks in order to be used as tools for all types of IED's.;Solved / Missunderstanding;;;;Ed 2 of SCL (SICS) defines mandatory and optional features of tools.;;;Closed;;

9;ENTSO-E;9 # ENTSO-E;There is no mechanism proposed by the Standard to positively identify data points in the data model. For instance PTOC can refer;Low;Support;In Progress;There is no mechanism proposed by the Standard to positively identify data points in the data model. For instance PTOC can refer to any number of protection events related to current. Does User have to ask Vendor to make indexing and prefix arrangement as he (User) would specify for each generic LN that covers functionality segregated to several instances(for example definite time OC Dt1EftPTOC1, Dt1PhsPTOC2,.) ? And how will software that will import/communicate model recognize which DO has semantics that is required? Should description be mandatory part of import process during configuration of Client and how it should be integrated (rules)? More precise LN modeling rules required.;Standard extension required;;WG10;6-100;"(1) Standardising function / subfunction types as mentioned in Issue 4 will help to support the semantic identification of vendor instantiated LNs

(2) Modeling guidelines / agreements may further help";"SCL of IEC 61850-6, Ed. 2.1 will support the possibility to relate logical node instances to function / subfunctions / eqfunction / eqsubfunction. There is a new task force in WG10 that will specifiy Function / Subfunction types. Once Function / Subfunction types are defined and used in SCL, this will allow to link a LN Instance to the particular Subfunction.

It is recommanded in addition to use an approriate description attribute of the LN data model.

aAddressed in the 61850-6-100

6-100 and Osmose are not enforcing directly additional semantics to the IED data model, but the definition of the ISD file together with the data exchange and Power System Resource Reference allow the user to specify semantics in a much more formalized way:

1.	SourceRef and ControlRef allow to add semantic information by:

a.	Providing naming fields for the user to add some meaning

b.	Create references to co-operating LNodes, e.g. CSWI and XCBR can be linked via SourceRef

2.	Power System Resource References create a link between a Function/SubFunction and any element of the Substation/Process section. With this the user can express e.g. 

a.	Association of MMXU and CT or VT

b.	Circuit Breaker which is tripped by a PTRC

c.	Line which is protected by a PDIS 

d.	etc.

3.	Applications are introduces in the Substation/Process section. They relate Functions and in this way also Logical Nodes to a common semantic. E.g. if an RBRF and a PTOC belong to the same Application, it is obvious that it provides the initiation of the RBRF

All these semantic refinements take place in the Substation/Process section. 6-100 also gives guidelines how to create an ISD file out of this specification and allows in this way to transfer this semantic to the relay  selection/procurement.

6-100 has improved the modeling, but has not yet standardized the Function sand Applications.";"Draft sent for comments: IEC 57/2237/DC.

Comments deadline: 2020-07-31";Assigned;;Virtual-Oct-2020

10,1;ENTSO-E;10,1 # ENTSO-E;DataSets for GOOSE messaging - modeling with: only DA, only DO or both? Standard is not forbidding any combination (7-2, Ed.1 Me;Low;Support;Closed;DataSets for GOOSE messaging - modeling with: only DA, only DO or both? Standard is not forbidding any combination (7-2, Ed.1 Member of GoCB is DataSet with MemberReference of FCD OR FCDA) but it will be implementation problem if Vendors are supporting only DA or only DO and system integrator has to decide to use one type of DataSet modeling. ;Implementation - improve conformance testing;;UCA Testing committee;;(1) as mentioned earlier, devices should support all possible options to configure datasets. If notyet already mandatory, this should be clarified in the standard and verified with conformance testing.;It is already solved on Ed2 (see issue 7.1);;Closed;;

10,2;ENTSO-E;10,2 # ENTSO-E;Also many other features of GOOSE messaging are left to the manufacturer to choose.;Low;Support;In Progress;Also many other features of GOOSE messaging are left to the manufacturer to choose.;Standard options reduction required;;WG10;7-2;Some of the GOOSE options maynot be required;"some Options may be eliminated; will be analysed by WG10. 

Example PIXIT_GS4: the behaviour should probably be defined in the standard.

To review all PIXIT with regard to (a) eliminate them by making the standard stronger or (b) transfer them to the PICS/service section of SCL file to make them machine processable.

(20180613)

WG 10 (completion date Ed 3), standard 7-2, for example PIXIT Gs4 should be defined in standard? To review complete PIXIT with regards:

a) eliminate them by making the standard stronger or 

b) transfer them to the PICS/service section of SCL to make them machine processable

c) If a lower value StNum is received and it is not the case of rollover and there is no communication loss then the older/lesser StNum shall be ignored. ? to update 7-2. (Thierry D., Herb F.). To check 8-1 in case that there Is a need for a change (Herb F.).";ED3 (Tasl leader to inform editors 7-2);Assigned;;

11;ENTSO-E;11 # ENTSO-E;Procedures to establish client / server communications should be defined or at least some guidelines how to perform basic tasks;Low;Support;Closed;"Procedures to establish client / server communications should be defined or at least some guidelines how to perform basic tasks need to be given.  As an example, part 7-2 provides on page 78 a state machine for RptEna, but there is no state machine of these processes in general (for URCB and BRCB).

In general, clarifications are required, how to handle configuration of report control blocks.

There should be recommended way of initialization and use of buffered and unbuffered report control blocks (with regards of different approaches to multiple instances, reaction of Resv in different states of communication, how will Client react/be prepared for Server side that is not supporting some of OptFields etc).";Profile or Guideline;;WG10;;"TISSUE 453 adds some clarification.

It needs to be investigated if further clarification is needed.";"A guideline how to use reporting has been prepared by Bruce in the UCA testing committee for review - once completed it will be reviewed by the WG10

Closed because has been solved into the 7-2/ed2.1 FDIS (Thierry in charge)";"Bruce to send to WG10 for review end of June 2014; comments by WG10 by end of August 2014; closing the issue at Nov 2014 meeting";Closed;;

12;ENTSO-E;12 # ENTSO-E;Project management as proposed by IEC61850-4 is not supported by commercially available tools. This document states Quality assu;Low;Support;Closed;"Project management as proposed by IEC61850-4 is not supported by commercially available tools. This document states Quality assurance and test stages as well as basic engineering and life- cycle requirements that are important to oblige. Yet in its current state it is more a ""good practise"" description than requirement document. It is not sufficiently clear what is implied by requiring that this part is followed. Neither is it clear what defined compliance to this part by a system implementer means in practise";Standard clarification required;;WG10;;"Write an Edition 3 of the standard in a way to be able to distinct between:

- strong requirements that can be verified

- recommendations for ""best practices"" as an informative Annex";Closed because adressed in the part 4 parts are already in the future part 4 (backward compatibilty, SCL tools exchanges). To be clarified!;Ed 3 of 61850-4;Closed;;

13;ENTSO-E;13 # ENTSO-E;There should be some guidance for the user, how to map his existing signals into IEC 61850 signals for a specification. In addi;Low;Support;Closed;There should be some guidance for the user, how to map his existing signals into IEC 61850 signals  for a specification. In addition, more general guidance for the user that wants to apply IEC 61850 should be provided e.g. in part 4.;Requirement Spec of user;;UCA IEC61850 group;;Start up guide for IEC 61850 user would be required;"The UCA 61850 users group shall produce  a guide for IEC 61850 starting users.

Closed because, it is too varied per user. We also have 7-500, 7-1, part 5, 7-5, 7-6 and 7-7 to help user. They just have to read it.";tbd;Closed;;

14;ENTSO-E;14 # ENTSO-E;Tools need to follow rules what they are allowed/intended to change in an SCL file in each stage of the engineering process. Th;Low;Support;Closed;Tools need to follow rules what they are allowed/intended to change in an SCL file in each stage of the engineering process.  These rules are defined in Edition 2 but not implemented.;Implementation - improve conformance testing;;UCA Testing committee;;"make sure that conformance tests for tools verify the behavior of the tools.

On the other side, it may be questionable to what level conformance tests for tools can be developped to produce good results. An alternate approach may be to define some interoperability tests for tools.";"The UCA testing committee shall finalize the test procedures and then try to validate them. At the same time, the UCA testing committee shall investigate to what level conformance testing of tools is sufficient to create results that enable interoperability.

Closed because tool conformance testing has been released and certification of tools is possible.";2015;Closed;;

15;ENTSO-E;15 # ENTSO-E;Vendor Tools shall allow (vendor independant) Integration tools doing engineering based on ICD Files, thus allowing them to in;Low;Support;In Progress;"Vendor Tools shall allow  (vendor independant) Integration tools doing engineering based on  ICD Files, thus allowing them to instantiate IEDs. 

Ability to import SCD and create devices in ICT without having exported ICD file.";Standard extension required;;WG10;6;SICS I21 needs to be clarified and a new SICS needs to be added preferrably as mandatory. Otherwise, the support needs to be required in a ENTSO-E requirement specification;"The Standard shall be extended to support the proposal

The ICT should be able to create an instance from an SCD file (put this optional) Camille in charge (2019.01.23- already created - waiting for new Ed/revision to be published)";Will be included in next version of IEC 61850-6: Amd2 or Ed3;Assigned;;

16;ENTSO-E;16 # ENTSO-E;Restrictions in the configuration (GOOSE, REPORTS, DATASET) shall be described in the ICD Service section and explained complete;Low;Support;Closed;Restrictions in the configuration (GOOSE, REPORTS, DATASET) shall be described in the ICD Service section and explained completely in the PIXIT. This will allow (vendor independant) tools to configure the communication via SCD file.;Standard clarification required;;WG10;;"some of these restrictions have been added in Ed 2 or Ed 2.1; the remaining ones need to be addes to SCL. See item 3 (2).  PIXIT shall be fully covered by IED service element

WG10 Discussion:

Discussion WG10 in Houston: Identify from the PIXITs what is relevant for interoperability / engineering of the system and verify if all that is available in SCL

Besides that, there may be the case that devices allow the creation of datasets or report control blocks, but not necessarily within any LN. This is a restriction not currently supported by the standard but exists in devices.";"We shall extend the standard to declare the restriction.

We may as well have to create recommendations to vendors.

But we may further consider that the standard in the future provides already the restrictions (e.g. mandate all control blocks in LLN0)

June 2014: Basic idea not to add new restrictions; IED vendors shall follow the standard. 

A recommendation can be created that provides recommendation to the IED manufacturer about reasonable and not reasonable restrictions. Need as well verify that test cases are good to verify all this.

Closed because already included in Ed 2.1 of part 6";"Ed 2.1 or Ed 3 of part 6

by November 2014 prepare draft recommendation (J?rg (lead), Bruce, Pierre, Chris)";Closed;;

17;ENTSO-E;17 # ENTSO-E;System Configuration Tools must analyze the ICD Service Section and follow the vendors PIXIT documentation;Low;Support;Closed;System Configuration Tools must analyze the ICD Service Section and follow the vendors PIXIT documentation;Standard extension required;;WG10;;"As already decided, everything that impacts engineering capabilities from PIXITs has to be moved into the service section.

Then, a system configuration tool can provide the capability to adopt the configuration to the capabilities of the IED tool / IED.";"SICS of the SCT for that behavior is specified in S56 (optional in Ed 2; mandatory with InterOp TISSUE 788)";;Closed;;

18;ENTSO-E;18 # ENTSO-E;Functional constrained data shall be possible to include all levels of a hierarchy in the data model in particular as well for d;Low;Support;Closed;Functional constrained data shall be possible to include all levels of a hierarchy in the data model in particular as well for data of data.;Implementation - improve conformance testing;;UCA Testing committee;;"The standard never allowed limitations; in Edition 2 this is made more clear.

A new conformance test has already been added";;;Closed;;

19;ENTSO-E;19 # ENTSO-E;If the point above (item 11) is not supported, vendors shall describe in the PIXIT document what they support;Low;Support;Closed;If the point above (item 11) is not supported, vendors shall describe in the PIXIT document what they support;Standard extension required;;WG10;;by previous issue done for Edition 2. For Edition 1 it has to be in a PIXIT of course;;;Closed;;

20;ENTSO-E;20 # ENTSO-E;Input configuration: IEDs shall support ExtRef entries pointing to Data Objects as well as to DataAttribute with all possible le;Low;Support;Closed;Input configuration: IEDs shall support ExtRef entries pointing to Data Objects as well as to DataAttribute with all possible levels.;Standard extension required;;WG10;;"We assume that this is mandatory. The use of it being optional in the schema (because we may not want to refer to a DA) does not mean that it is optional to support the usage (if we want to refeetr to DA). This should be clarified and verified by conformance testing. 

Herb and Christoph to prepare proposal based on the following IOP conclusion: There are several different mechanisms that could be used in 61850-6 to subscribe to a GOOSE.  However, the IOP group decided to use ExtRef. 

The standard should be revised to make this the only mechanism.";"Discussion June 2014:

Suggest to use ExtRef as mechanism for Engineering, but extend with some capabilities (e.g. to differentiate between Blocking, Input or unknown signal). Further work needed:

- do we need to standardize inputs with semantic?

- how does an ID declare how many ExtRef are needed per  LN?

- do we need to put ExtRef on all LNs or can we assume if ExtRefs are on LLN0 they are valid for all underlying LNs?

- consider removal of ConfSigRef in service section

The ExtRef issue have been solved by many IOP 2013 and IOP 2015 issues. And by 7-1 Ed. 2.1 and annex H of part 6 Ed. 2.1 ";Nov 2014 prepare a draft proposal (Herb - lead, Nicolas - reminder, Chris, Christoph, Thierry);Closed;;

21;ENTSO-E;21 # ENTSO-E;IED certification needs to include tool interoprability validation;Low;Support;Closed;IED certification needs to include tool interoprability validation;Standard clarification required;;UCA Testing committee;;With Edition 2, IED certification shall include conformance testing for tools - for that purpose, the conformance test specifications need to be finalized (assigned to UCA testing committee). Interoperability tests are not foreseen as part of certification, but UCA will continue to perform IOP tests on a regular basis to help improving interoperability betwen tools;"Standard clarification / conformance testing

Closed because the test procedure for tools is released. ";01/12/2014;Closed;;

22;ENTSO-E;22 # ENTSO-E;Today, there is no single way to describe subscriptions such that various tools understand it the same way. This needs to be im;Low;Support;Closed;Today, there is no single way to describe subscriptions such that various tools understand it the same way. This needs to  be improved;;;;;Refer to 20th issue;;;Closed;;

23;ENTSO-E;23 # ENTSO-E;There are interoperability problems between client and server IEDs due to product implementation. For example, some IEDs does no;Low;Support;Closed;"There are interoperability problems between client and server IEDs due to product implementation. For example, some IEDs does not allow to change the ""OptFlds"" of a report by means of ACSI services even when the ServiceSection defines the ReportSettings->optFields to ""dyn"". Conformance testing on SCL file should take care about these issues and confirm that SCL is totally conform to the product implementation.";Implementation - improve conformance testing;;;;"agreed - this is a conformance testing issue since that behavior is not correct.

It was confirmed that there is already a test verifying the behavior as declared in the SCL service section versus the behavior of the device with ACSI services

";Conformance testing;;Closed;;

24;ENTSO-E;24 # ENTSO-E;It seems that there is a certification for client implementations similar to the certification of IED servers, but there is no w;Low;Support;Closed;It seems that there is a certification for client implementations similar to the certification of IED servers, but there is no written standard (IS, TS, TR) about client functionality. From the utility side, we do not know what tests are done to a client and what is this certification about? We think there should be a standard for client specification.;Solved / Missunderstanding;;;;Note 2 in section 1 of 61850-10 Ed1 is stating that client test are beyond the scope for that part and intended to be defined during the maintenance. However, the UCA users group has specified conformance tests - so from the utility side you can know what is tested. But we suggest to make sure that client test have been added to Ed 2 of Part 10 or will be added to a new part;Confirmed - Part 10 ed2 already includes clients conformance test procedures. Therefore user can verify what was tested. ;;Closed;;

25;ENTSO-E;25 # ENTSO-E;Freedom of choice what IEC 61850 services are to be tested seem too open. The vendor can select exactly what UCA accredited test;Low;Support;In Progress;"Freedom of choice what IEC 61850 services are to be tested seem too open. The vendor can select exactly what UCA accredited test center shall test and the report is limited to those details. If IED doesn't pass one of the tested services regarding interoperability, the vendor can leave out this particular service from the list of tested services and the end user won't know that it didn't pass the test. Also, PIXIT & PICS, TICS, SICS are too detailed and it is not in the scope of the end users for checking their validity and suitability for their own applications.

There are two issues that are adressed here:

- mismatch between PICS/PIXITs used for conformance testing, manuals and marketing documents

- the easyness of the interpretation of PICS/PIXITs";Profile or Guideline;;UCA IEC61850 group;;"As part of the UCA conformance testing process, PICS, PIXIT, SICS and TICS are integral part of the documentation for a certificate to precisely describe what was tested.

To help the end user to compare these elements with its own specification, some guidance shall be provided. Such a guidance can be provided with details by a guideline produced by the UCA users group. In addition, we may consider in further revisions of IEC 61850 what additional information can be provided in e.g. part 1 of the standard.";"UCA TF (testing committee) in charge. To be checked regularly by the UFTF leader 

19-01-23: PICS template is in Excel format (for Conformance testind defined by UCA TF) - PICS template in different format is defined by standard part 10 - PART 10 has to be updated (contact R. Schimmel); PIXIT is not yet in machine readable format (UCA TF will investigate the options)

Final solution by WG10 is not started, maybe in Ed. 3";Contact Richard Schimmel to find out when will it start 10 ed2.1;Assigned;;Virtual-06-20

26;ENTSO-E;26 # ENTSO-E;Interoperability to other vendors products is today not verified by UCA accredited test centers, is it up to the end users or sy;Low;Support;Closed;Interoperability to other vendors products is today not verified by UCA accredited test centers, is it up to the end users or system integrators to prove the interoperability for each services that each end user is requiring? Then, there will be a confusing lot of partially tested combinations of products and services but no-one has the full list of these? How can this be handled neatly?;Out of Scope;;User;;As it is stated, interoperability testing by ist nature results in a confusing lot of partially tested combinations? I do not think that this can be systematically handled. What can be done is, to organise regularly interoperability test events were typical use cases are tested and then a report is produced (as it has been done once by the UCA users group. However, this creates costs that at the end will have an impact on the product price.;"Perform regular IOP based on real use cases will help to collect information about interoperability. It is recommended to the users, to participate at such IOPs.

";;Closed;;

27;ENTSO-E;27 # ENTSO-E;There are too many options in the standard. An analysis should be done in order to define which option could become mandatory,;Low;Support;Closed;There are too many options in the standard.  An analysis should be done in order to define which option could become mandatory, this in order to reinforce the interoperability of the standard.;Standard options reduction required;;WG10;;agreed - however, we will have to deal with backwards compatibility issues;Ref. to 2.1;;Closed;;

28;ENTSO-E;28 # ENTSO-E;IEC 61850-6 defines the use of the Inputs Section, ExtRef tags, to create bindings between Logical Nodes. From the point of view;Low;Support;Closed;"IEC 61850-6 defines the use of the Inputs Section, ExtRef tags, to create bindings between Logical Nodes. From the point of view of the engineering tool and users, this option cannot be used in most of the IEC 61850 conformance IED's in the market.

(1) It is not defined as mandatory but it should be.

(2) It is not defined the capacity of bindings between logical nodes for a given IED.

(3) It is not defined how many bindings a logical node can support.

(4) It is not tested in the conformance test";Standard clarification required;;WG10;;"see as well 20 and 22 above

I think, somewhere it is indicated how many bindings are supported (I recently had a discussion about this, but I think it is a rather hidden requirement so should be clarified); but I agree it should be made mandatory and conformance tested";According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue should be closed. (ref. to issue 18/IOP2013);;Closed;;

1;Vattenfall;1 # Vattenfall;The engineering-processen is well defined for a green field / new IEC 61850 substation but needs clarification for refurbishment;Medium;Feature;In Progress;"The engineering-processen is well defined for a green field / new IEC 61850 substation but needs clarification for refurbishment and extensions. In a green field project Vattefall starts by defining the SSD and hands it over to supplier as part of the bid for tender. Clarification of the process for an existing substation is required. Here utility needs to start by extending or modifying an existing SCD substation from original supplier. How are the modified parts of substation section handled? Can a SSD be created that maintains links to existing communication and IED structures, into which a new supplier can continue work? (61850-6:2009 clause 10 needs to define also ""specification tool"" besides system configurator. Can data flow engineering rights and SED files that be used for this use case?) ";Standard clarification required;usage;WG10;;Add Part 6 a use case for extension to existing system from existing SCD. Add SICS for specification tool;"Answer from Joerg regarding 6-100:

For the brown field engineering, as well as for discussions about IED specification, the understanding of SSD and SCD file needs to be clarified. These files are not defined by their content, but by their role in the Engineering process.

Some examples: 

?	A Utility delivers as part of a specification an SCL file with only a Substation Section, even no Data Types: This is an SSD

?	The System Integrator is lazy and returns a file with only  ?as built? IEDs, Data Types  and Communication Section: This is an SCD

?	A Utility adds a new bay to an existing SCD (brown field). And uses this as specification for the extension of the existing station: This is an SSD

?	A Utility creates a specification with Substation Section and Virtual IEDs. The Virtual IEDs are completely engineered (GOOSE, Reports, etc.) : This is an SSD

?	The System Integrator return an identical file, but ?as built?: This is an SCD

Up to now  (SCL ED2 )the user has to know the meaning of the file. It cannot be derived from the content. 6-100 however is adding some semantics to the File:

?	An SCL file can have a GUID and a Semantic Version

?	An SCD can have a reference to the SSD that it implements

?	Each IED in an SCD can have 

o	a reference to the ISD file, that was specifying it

o	a reference to the ICD, IID or CID file it is based on

?	Each virtual IED in an SSD can reference the ISD file it was specified with.

";Ed 3 ;Assigned;;Virtual-Oct-2020

2;Vattenfall;2 # Vattenfall;Currently SCL has poor support for handling gateway/RTU-funktions where signal names are translated for remote communication. Th;High;Bug;In Progress;"Currently SCL has poor support for handling gateway/RTU-funktions where signal names are translated for remote communication. The specified sigal has a utility process name independent of used protcol. E.g. ""start of distance protection"". This needs to be associated with its IEC 61850 implementation (xxPDIS1.Str.general, xxPDIS2.Str.general etc.). The 80-1 part describes how 104 addresses can be added to SCL but also other utility fields are important to be able to include in SCL for specification and documentation purposes. Desired solution by Vattenfall is to have vendors use DA description to add utility process name. ";Standard clarification required;serious;WG10;;"To use nsdoc files as holders of DO,DA standard descriptions (7-4, 7-3)

If DO descriptions are to be changed, that should be done in SCL.";19-01-23: Camille to distribute proposal for review (if accepted, will be implemented in next Revision/Ed);Ed 3;Assigned;;

3;Vattenfall;3 # Vattenfall;"The specified sigal has a utility process name independent of used protcol. E.g. ""start of distance protection"". Also link to a";Low;Support;Closed;"The specified sigal has a utility process name independent of used protcol. E.g. ""start of distance protection"". Also link to a 61850 signals Vattenfall function is required using Functions and Subfunctions in the substation model. These options are not support by most vendors. Currently an extra Excel is required to link delivered Logical Nodes in IED to LNodes in SSD. ";Requirement Spec of user;;WG10;;The problem can be solved by flexible use of device data model supported by IED tool.;;;Closed;;

4;Vattenfall;4 # Vattenfall;"The Standard requires a one to one mapping between LNode and LN. This creates serious limitations. Examples:

1. Let us assume ve";High;Bug;In Progress;"The Standard requires a one to one mapping between LNode and LN. This creates serious limitations. Examples:

1. Let us assume vendor makes use of GGIO and represent a 32 bit BI/O Interface Card in the IED with  the LN  BIO32GGIO1.  Now in my Substation section I define two Functions with  Fun1/BIOGGIO1,    Fun2/BIOGGIO2.  Fun1 and Fun2 are two very different functions, but I have only one BIO card in my IED. Now I would like to map the LNode Fun1/BIOGGIO1 to  LN  BIO32GGIO1 and  Fun2/BIOGGIO2 also to LN  BIO32GGIO1.  Naturally they use distinct Data Attributes.

2. It is easy to find a similar example for MMXU. Power Measurement and Current/ Voltage Measurement can be used in different Functions in the Single Line, but are using the same LN MMXU.";Standard clarification required;serious;WG10;;Discussed with TF SCL function modelling.;"to be adressed to the 61850-6-100 (need a realistic date)

6-100 states that n:1 relationship between LNodes and LNs is allowed and supported. No need to change the SCL scheme for this.

";Ed 3;Assigned;;Virtual-Oct-2020

5;Vattenfall;5 # Vattenfall;A specified signal in substaion section uses a LNode that is mapped to a Logical Node in the IED section. Is it permitted to hav;High;Bug;In Progress;A specified signal in substaion section uses a LNode that is mapped to a Logical Node in the IED section. Is it permitted to have LNodes like CALH, CCGR,  ISAF, SIML, STMP in substation section mapped to other Logical Node classes (e.g. GGIO) in the IED section? (In a 70/20 kV Smart Grid pilot a major vendor used 15 LN classes, delivering 171 out of 397 signals to dispatch center as GGIO, despite utilities detailed modelling using 35 LN classes and requiring only 8 GGIO for 162 specified signals.);Standard clarification required;serious;WG10;;Discussed with TF SCL function modelling.;"to be adressed to the 61850-6-100 (need a realistic date)

If a System Integrator delivers an SCD with Substation section, this documents the System ?as built?. So if he uses a GGIO instead of an CALH, than he has to replace the CALH of the specification by a GGIO and then let the GGIO point to the implementation in the IED. However this completely breaks the relation to the original SSD file. The Customer has a hard time to validate the delivered SCD against the specification.

6-100 helps in this situation. In addition to the attributes linking the LNode to the LN we now have a set of ?Specification Attributes? that maintain the original specified values of the LNode. So, if the Utility specifies a CALH and the System Integrator provides a GGIO, both Logical Node classes are available in the Substation Section of the returned ?as built? SCD. ";Ed 3;Assigned;;Virtual-Oct-2020

6;Vattenfall;6 # Vattenfall;Common vendor practice is to have generic interfacing logical nodes for outputs and inputs. This destroys the semantic meaning o;Medium;Feature;Closed;Common vendor practice is to have generic interfacing logical nodes for outputs and inputs. This destroys the semantic meaning of signals. Likewise the use of inputs to generic LN (e.g. LDO) rather than the LN actually using the input makes documentation of information flow from SCL difficult. In order for the information flow to be recreated from SCL (without refering to propritey configuration information in vendior tools) it is required that Ed2 srcLN attributes are used in Input/ExtRef elements and that relevent placement of Inputs is enforced (according to part 6?9.3.13). We see this as an issue for both profiling and description in guidelines within the standard. Guideline for using SCL as documentation is specificly needed. ;Profile or Guideline;usage;UCA IEC61850 group;;Ed 2 partly solves this issue. The guideline should describe the prefered way.;Closed because solved with 7-1 (part ExtRef), part 6 ED 2.1 annex H  and by issue#5 ENTSO-E (generic interface LN).;;Closed;;

1;IOP_2013;1 # IOP_2013;"There is currently no mechanism available to mix ED.1 and ED.2 DataModels in an Ed.2 SCL file.

The use of a static set of CDCs i";High;Bug;Closed;"There is currently no mechanism available to mix ED.1 and ED.2 DataModels in an Ed.2 SCL file.

The use of a static set of CDCs in the ED.2 schema prevents ED.1 data models from being used in an ED.2 SCL file. Additionally, there is no mandatory mechanism provided to allows an indication if an IED is ED.1 or ED.2 in behavior after import into an SCT/SCT.";Standard clarification required;serious;WG10;;Wg10 is currently working on identifying and solving the issues of mixed versions;According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;WG10 June 2015 Meeting;Closed;;

2;IOP_2013;2 # IOP_2013;"The actual format required for an ExtRef is not specified fully or in an understandable way.

Tools configured different combinat";High;Bug;Closed;"The actual format required for an ExtRef is not specified fully or in an understandable way.

Tools configured different combinations of values to create ExtRef.

A single unique mechanism, that is unambiguous, needs to be documented.";Standard clarification required;serious;WG10;;"WG 10 shall come up with a selection and a specification of the preferred method to specify signal flow between IEDs from a system specification tool. 

This shall include the description what has to be included in an ICD / IID file (the input on the SCT) as well as what has to be added by the SCT to be included in the SCD.

It shall as well include a discussion of the relation between ExtRefs at the engineering stage (SCL file) and InRefs/BlkRef later in the real time model.";TISSUE 1400;WG10 June 2015 Meeting;Closed;;

3;IOP_2013;3 # IOP_2013;The actual format required for an ClientLN (used for ReportControl Block reservation) is not specified fully or in an understand;High;Bug;Closed;"The actual format required for an ClientLN (used for ReportControl Block reservation) is not specified fully or in an understandable way.

LDInst is required, but for Client only IEDs, there is no LD. The standard indicates to select a random LDInst and provides some guidance. However, in order to insure that there is interoperability and that importers understand that there is NO LDInst, the value to indicate this needs to be standardized. Recommend the use of ?none?.";Standard clarification required;serious;WG10;;"Change in part 6 from arbitrary value and recommended LD0 to ""shall be LD0"".";According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;Ed2.1 part6;Closed;;

4;IOP_2013;4 # IOP_2013;The standard is clear about the need to rename duplicate DataTypeTemplates. However, the IEDType attribute is optional for the I;Medium;Feature;Closed;"The standard is clear about the need to rename duplicate DataTypeTemplates. However, the IEDType attribute is optional for the IED and DataTemplateTypes. Making this mandatory may help with efficient management of the DataTypeTemplate section.

Discuss the usage of IEDType and making of it mandatory";Standard clarification required;usage;WG10;;WG10 shall make a proposal;According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;;Closed;;

5;IOP_2013;5 # IOP_2013;"An ICT provided a file that had a destination MAC address of 00:00:00:00:00. The schema validated this address.

The address of 0";Medium;Feature;Closed;"An ICT provided a file that had a destination MAC address of 00:00:00:00:00. The schema validated this address.

The address of 00:00:00:00:00 is not a multicast address which means it can?t be used officially for GOOSE or SV. The question is should the schema validate that the MAC addresses are multicast addresses. The IOP group felt that validation could help prevent unintended errors.";Standard extension required;usage;WG10;;Extend schema to perform that additional checks;According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;;Closed;;

6;IOP_2013;6 # IOP_2013;An SCL file was attempted to be imported that had TMAX and TMIN missing. The expected behavior for this case is not specified. A;High;Bug;Closed;"An SCL file was attempted to be imported that had TMAX and TMIN missing. The expected behavior for this case is not specified. And the file import was rejected.

61850-6 defines TMAX and TMIN as optional in order to provide backward compatibility with ED.1 schema. However, in ED.2 the fact that these are needed to control the expected behavior creates a need to define the default behavior or to develop a ED.2 profile that can be applied in addition to the XSD for validation.

Submit the concept of profiling to WG10";Standard clarification required;serious;WG10;;Suggest that WG10 defines default behavior if these values are missing or declare them as mandatory for ED.2.;According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;;Closed;;

7;IOP_2013;7 # IOP_2013;There was an SCL file that had a Logical Device namespace (LDNs) specified as ?2007?. This file did not import due to the expect;High;Bug;Closed;"There was an SCL file that had a Logical Device namespace (LDNs) specified as ?2007?. This file did not import due to the expectation by the importer that the value would be ?2007A?.

61850-6 ED.2 implies that the namespace should be ?2007A?. The text reads:

?starting with A for the first released version revision?.

For clarity, the text could read: ?starting with A for the first released version?.";Standard clarification required;serious;WG10;;"Clarify that either

- ""A"" is mandatory

- in the case of the first revision, to supply ""A"" is optional";According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;WG10 June 2015 Meeting;Closed;;

8;IOP_2013;8 # IOP_2013;A ICD was generated for a Client Only IED. It had an LN defined (e.g. IHMI). The ICD had no definition for IHMI in the DataTypeT;High;Bug;Closed;"A ICD was generated for a Client Only IED. It had an LN defined (e.g. IHMI). The ICD had no definition for IHMI in the DataTypeTemplate section. Upon import, the file did not validate.

61850-6 has text that specifies that a Client Only IED may define a LN and not have any entry (could not find the text) defining the LN in the DataTypeTemplate section. However, the XSDs do not allow this";Standard clarification required;serious;WG10;;WG10 shall agree, if for Client only LNs a Data Type Template entry is required or not and make the whole part 6 and XSD consistent based on that decision;According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;;Closed;;

9;IOP_2013;9 # IOP_2013;"A question was raised about what is the meaning of RptEna max=0.

It was the discussion of the group that 0 should not be allowed";Medium;Feature;Closed;"A question was raised about what is the meaning of RptEna max=0.

It was the discussion of the group that 0 should not be allowed if interpreted as having no instances of the RCB. In that case, the entire RCB should be missing from the SCL file.";Standard clarification required;usage;WG10;;Clarify in the standard that RptEna max=0 is not a valid value.;According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;;Closed;;

10;IOP_2013;10 # IOP_2013;Although 61850-6 allows the standardized expression of an ExtRef, the IntAddr typically associated with it is a proprietary vend;High;Bug;Closed;"Although 61850-6 allows the standardized expression of an ExtRef, the IntAddr typically associated with it is a proprietary vendor format. Therefore, there is no easy mechanism to express, in a standard way, the semantics expectation of what the ExtRef is to provide or the IntAddr.

The use/specification of ExtRef is not 100% defined.

One SCL tool expects it to be initialized as part of a DOI, others require it to be a DAI.";Standard clarification required;serious;WG10;;see ISSUE  #36. This should be addressed as well wth the clarification provided by WG10;refer to 1402 TISSUE (related to the 1257);;Closed;;

11;IOP_2013;11 # IOP_2013;An SCL file was produced that instantiated a new DO within a LN. The DO was from the same 61850-7-4 Namespace. The question that;High;Bug;Closed;"An SCL file was produced that instantiated a new DO within a LN. The DO was from the same 61850-7-4 Namespace. The question that arose was what should be the Logical Node Namespace or Data Namespace.

After discussion, the group tended to lean towards the use of DataNS to indicate this type of LN. However, clarification is needed within the standards.";Standard clarification required;serious;WG10;;The complete handling of name space attribute is currently under clarification in WG10.;According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;June 2015 WG10 Meeting;Closed;;

12;IOP_2013;12 # IOP_2013;During the SCL testing, a question was raised in regards to how does a SCT know the maximum number of instantiated RCBs allowed;Medium;Feature;Closed;"During the SCL testing, a question was raised in regards to how does a SCT know the maximum number of instantiated RCBs allowed in an IED and what the allowed distribution per RCB. Without this information, it is possible for an SCT to configure more resources than the IED can support.

The ability to specify either constraint appears to be missing in ED.2.

An analysis of GOOSE and SV control blocks show that the maximum allowed is specified. A possible solution might be that each RCB is described in the ICD might be required to use RptEnabled max.";Standard extension required;usage;WG10;;"""max ? maximum number of instantiable report control blocks"" is to be added to ReportSettings in Part6, table 11, p 64. (Annex A (p.132) type=""tReportSettings"" need not change.)";According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;;Closed;;

13;IOP_2013;13 # IOP_2013;A client only ICD did not have a ClientServices section. An SCT imported the file and assigned used the IED to reserve a RCB wit;Low;Support;Closed;"A client only ICD did not have a ClientServices section. An SCT imported the file and assigned used the IED to reserve a RCB without validation.

In ED.1, there was no ClientServices. Ed.2 added this to the SCL. Therefore, this could be an issue to resolve in ED.1 and ED.2 co-residence in a single SCD (see SCL issue 1).

Within the context of ED.2, the ClientServices should be present ,although marked as not being required for backward compatibility. In this case an interoperability profile needs to be developed.";;;;;"[Issue is restricted to Ed1 device in edition 2 SCL files and should not be resolved in isolation to other issues related to ED.1 and ED.2 co-residence in a single (Ed.2) SCD file.]

Wait for Regina meeting.";Verify in the -4 document there is a recommendation.;;Closed;;

14;IOP_2013;14 # IOP_2013;A SCL file was created that did not have the maxAttributes attribute defined. What does it mean semantically if the attribute is;Medium;Feature;Closed;"A SCL file was created that did not have the maxAttributes attribute defined. What does it mean semantically if the attribute is missing.

61850-6 should define the semantic meaning of maxAttributes not being present. It is optional in both ED.1 and ED.2.";Standard extension required;usage;WG10;;"Standard should clarify that a missing maxAttributes attribute means that there is not constraint of the number of attributes of a dataset in the ICT/IED.

However, there may be other constraints like the negociated MMS Pdu size.";According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;;Closed;;

15;IOP_2013;15 # IOP_2013;During discussions, a question arose in regards to if there is a RCB with cBName=?fix? and the maximum number of RCBs has not be;High;Bug;Closed;"During discussions, a question arose in regards to if there is a RCB with cBName=?fix? and the maximum number of RCBs has not been reached, is it legal to create new RCBs.

61850-6 does not answer this question.";Standard extension required;serious;WG10;;Vendor ICD with CBname = fix should declare all RCBs;According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;;Closed;;

16;IOP_2013;16 # IOP_2013;There was an ICT/IED combination that only allowed RCBs and ExtRefs to be defined in a certain LD/LN. It did not allow any RCBs/;High;Bug;Closed;"There was an ICT/IED combination that only allowed RCBs and ExtRefs to be defined in a certain LD/LN. It did not allow any RCBs/ExtRefs to be defined for any other LD/LN combination. The SCT attempted to define RCBs/ExtRefs in other logical nodes through and SCD. The import of the SCD was refused.

61850 allows ExtRefs/RCBs to be defined in any logical node. However, there is no mechanism in SCL for an ICT to declare where it is legal to do so or what the semantics required for ExtRef are.";Standard extension required;serious;WG10;;"61850 allows ExtRefs to be defined in any logical node. No clarifications needed, but UCA needs to improve conformance testing to fail devices violating this. Possibly clarification in  part 6 ?9.3.13  to be considered.

For RCBs on the other hand it makes sense to have them (like for GoCB ) only on LN0. however this is not a restriction in the standard. This is task for vendor guideline from UCA, not WG10.";refer to 1402 TISSUE (related to the 1257);;Closed;;

17;IOP_2013;17 # IOP_2013;"The usage of ClientLN in RptEna is optional. What does this mean.

61850-6 made this option for backward compatibility with ED.1.";Low;Support;Closed;"The usage of ClientLN in RptEna is optional. What does this mean.

61850-6 made this option for backward compatibility with ED.1. However, in order to standardize reservation mechanisms, it needs to be made mandatory. This means some type of a profile for turning optional into mandatory for ED.2. Additionally, this impacts SCL Issue 1. From an IOP perspective there is agreement that ClientLN should be the only mechanism for reserving a RCB. Proprietary mechanisms should not be allowed.";Solved / Missunderstanding;;;;Please refer to sentence 2 page 78 part 6 Ed.2 (page 60 Ed.1).;According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;;Closed;;

18;IOP_2013;18 # IOP_2013;"The use of ExtRef to subscribe to a GOOSE was questioned.

There are several different mechanisms that could be used in 61850-6 t";Urgent;Bug;Closed;"The use of ExtRef to subscribe to a GOOSE was questioned.

There are several different mechanisms that could be used in 61850-6 to subscribe to a GOOSE. However, the IOP group decided to use ExtRef. The standard should be revised to make this the only mechanism.";Standard clarification required;critical;WG10;;"It should be stated in Ed.3 ?9.3.13 for what services ExtRef are used to configure subscription. It should also be stated (see item 16) that binding can be done on any LN or all LNs that are using the ExtRef, which is required in order to be able to recreate information flow purely from SCL. 

The following sections should be modified to they are an invalid mechanism for subscribing to GOOSE and SMV:

Section LGos

Section LSvs";According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;;Closed;;

19;IOP_2013;19 # IOP_2013;"The use of ExtRef to subscribe to a SV was questioned.

There are several different mechanisms that could be used in 61850-6 to s";Low;Support;Closed;"The use of ExtRef to subscribe to a SV was questioned.

There are several different mechanisms that could be used in 61850-6 to subscribe to a SV. However, the IOP group decided to use ExtRef. The standard should be revised to make this the only mechanism.";;;;;See item 18 above. (Solution for GOOSE and SMV should be the same.);refer to 1402 TISSUE (related to the 1257);;Closed;;

20;IOP_2013;20 # IOP_2013;During GOOSE testing, an SCL GOCB was properly configured. However, the importer refused the file since some of the dataTypes of;High;Bug;Closed;"During GOOSE testing, an SCL GOCB was properly configured. However, the importer refused the file since some of the dataTypes of the DataSet members were not natively processed by the IED.

Also, During GOOSE testing, GOOSE messages were being transmitted and received. However, some of the DataSet member data could not be processed or displayed.

There is no mechanism to declare what data types are supported within SCL. A subset of mandatory supported data types needs to be defined or all data types need to be supported.

There is no mechanism to declare what data types are supported within SCL. A subset of mandatory supported data types needs to be defined or all data types need to be supported.";Standard clarification required;serious;WG10;;"Implementations shall support the configuration and subscription of a DataSet that contains any of the basic dataTypes defined in IEC 61850-7-2.  Additionally, DataSets configuration/subscription shall be allowed for FCDAs whose semantics the IED does not understand.  However, in this case, the IED shall not be required to take action on the FCDA. Subscribed basic DataTypes whose conversion to internal representation  does not support the full range of allowed values (e.g. INT64 to INT32 --full range)  shall not be allowed to be defined as an extRef. We have to revise the PICS to expose the information.

";According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;;Closed;;

21;IOP_2013;21 # IOP_2013;There is an issue about differentiation between ?fixed? /preconfigured DataSets and those that can be changed in a SCT. Some ICT;Low;Support;Closed;"There is an issue about differentiation between ?fixed? /preconfigured DataSets and those that can be changed in a SCT. Some ICTs expect specific DataSets to be returned to them. If the SCT changes these, the file will not import.

The issue is that there is currently no mechanism standardized to allow an ICT to declare that a specific DataSet must not be changed or deleted. The group believes that the valimport syntax should be added to DataSet definitions.";Already captured with TISSUE;;;;"Tissue #1298

As summary: for an IED all data sets are either fix (modify=false) and then must be preconfigured, or they are always modifiable, deletable and creatable to the limit. 

Proposed solution: change the explanation of ConfDataSet.modify by removing the word 'preconfigured'.

That means an IED has either ONLY fixed data sets and control blocks, or can be freely configured ? which means also that all preconfigured data sets and control blocks can be removed and modified accordingly.

This interpretation is new for Ed. 2 and may be incompatible with ED. 1 implementations.

";Closed with 2015 IOP Tissues 1444 & 1445;;Closed;;

22 (1);IOP_2013;22 (1) # IOP_2013;In a SCD there were LNodes in the substation section that were not associated to a specific IED/LN instance. In particular, an S;Low;Support;Closed;"In a SCD there were LNodes in the substation section that were not associated to a specific IED/LN instance. In particular, an SCD file contained an IEDName whose value was ?null?. 

This file did not import into certain tooling.

";Solved / Missunderstanding;;;;"Improvment of the schema or clarify the part 6. ""null"" is not a valid value. It should validate against IED names or ""None"". Also IED names in the IED section shall not be ""None"".

";Tissue 1365;;Closed;;

22 (2);IOP_2013;22 (2) # IOP_2013;In a SCD there were LNodes in the substation section that were not associated to a specific IED/LN instance. The question was if;Low;Support;Closed;"In a SCD there were LNodes in the substation section that were not associated to a specific IED/LN instance. The question was if this was allowed. This file did not import into certain tooling.

The 61850-6 standard is not explicit that LNodes imported from a SSD should be maintained. The IOP group believes that LNodes should be maintained and that the standard should be updated to reflect this.";Solved / Missunderstanding;;UCA Testing committee;;"Nothing in the standard prevents from having in an SCD file a substation section mixed with allocated LNs and non-allocated LNS (value of iedName attribute of the LNode element being None). The given example in Annex D shows such a mixed SCD file.

No clarification required. Have to be considered for the conformance testing.

For UCA testing committee for SCT/ICT testing.

";;;Closed;;

23;IOP_2013;23 # IOP_2013;There are normative ENUM definitions for 7-4. (e.g. Mod) but there is no guidance in regards to naming rules (e.g. Modkind).;Low;Support;Closed;There are normative ENUM definitions for 7-4. (e.g. Mod) but there is no guidance in regards to naming rules (e.g. Modkind).;Solved / Missunderstanding;;;;"Part 6, page 105

Enumeration definitions within a SCD file are valid for all IEDs; they are not IED typedependent.

Therefore the allowed names are standardized as follows:

? ...

? Enumerations from IEC 61850-7-4 are defined on top of ENC, ENS or ENG common data

classes ? For these enumerations the name of the data objects shall be taken ?

?

If private extensions of these enumerations are used, or private enumerations are defined, the

name must indicate this appropriately, i.e. none of the above defined names shall be used. ?";;;Closed;;

24;IOP_2013;24 # IOP_2013;The mechanism for defining a GI attribute in a ED.2 RCB does not validate and import into an ED.1 ICT.;Low;Support;Closed;The mechanism for defining a GI attribute in a ED.2 RCB does not validate and import into an ED.1 ICT.;Solved / Missunderstanding;;;;"Solution 1:

ICT implements the ""may ignore"" rule.

Part 6, page 31

? The ?may ignore all? strategy for elements (tags) is taken, i.e. ignore the

element and all its contained contents. For attributes just the attribute not understood is

ignored. ?

Solution 2:

SCT ""downgrades"" the ICD file to the an ED.1 compatible ICD, i-e removes the new GI attribute.";;;Closed;;

25;IOP_2013;25 # IOP_2013;The iedType attribute is optional within SCL. However, some SCL tools use this as part of validation. Lack of the attribute/valu;Low;Support;Closed;"The iedType attribute is optional within SCL. However, some SCL tools use this as part of validation. Lack of the attribute/value prevented import of the file.

It is suggested to make this attribute mandatory with a standardized value for ?unknown?.";Already captured with TISSUE;;;;"Part 6 Ed. 2 clause 9.5.1

? If it is important to keep the relation of the LNodeType to the IED type, then iedType should be set to the same value as the IED?s type attribute. Especially if an IED configurator needs the LNodeType contents back unchanged, it shall bind the LNodeType to the IED type by setting the iedType attribute identical to the IED?s type attribute. 

See also tissue #367";;;Closed;;

26;IOP_2013;26 # IOP_2013;An ICT provides an IID/ICD file that defines 4 GOCBs. The SCT imports this file, creates an SCD which has only 1 GOCB. The ICT r;Low;Support;Closed;"An ICT provides an IID/ICD file that defines 4 GOCBs. The SCT imports this file, creates an SCD which has only 1 GOCB. The ICT refuses to import the SCD as it is expecting 4 GOCBs.

At first analysis, the SCT should not remove the configured GOCBs. However, this is an issue that needs further clarification.";Already captured with TISSUE;;;;See Issue #21;;;Closed;;

27;IOP_2013;27 # IOP_2013;"How should an SCL file express the initial value of GOCB.Ena and SVCB.Ena.

It would appear that the Control Block schema definit";Low;Support;Closed;"How should an SCL file express the initial value of GOCB.Ena and SVCB.Ena.

It would appear that the Control Block schema definitions (in the IED section) need to be expanded to allow this capability.";Already captured with TISSUE;;;;"There is the tissue # 1241 in the Tissues Database Part 6 that has been set to green in 2014. The conclusion was that this was part of an IED specific configuration, i-e a local issue. However the discussion ended by ""No change for Ed2. A rediscussion for Ed3 might follow"".

Do we want to reopen the tissue?";;;Closed;;

28;IOP_2013;28 # IOP_2013;"An ED.2 SCT would not import an ED.1 SCL file.

This needs to be addressed with rules of transformation and the definition of a s";Low;Support;Closed;"An ED.2 SCT would not import an ED.1 SCL file.

This needs to be addressed with rules of transformation and the definition of a schema that can be used.";Solved / Missunderstanding;;;;"This issue lacks details about why the file didn't import.

Part 6 Ed. 2 SICS S15: SCL version 2003 as input shall always be imported.";;;Closed;;

29;IOP_2013;29 # IOP_2013;An SCL file was provided that had a <Val> for an OctetString value. A question was raised as to the correct format for the value;Low;Support;Closed;"An SCL file was provided that had a <Val> for an OctetString value. A question was raised as to the correct format for the value.

61850-6 has 2 references that could be interpreted as providing the format specification for the value. One is RFC 2045, the other is the W3C XML Schema Part 2 specification. The W3C specification does not have an explicit definition for Octetstring. It is suggest that this is the format specified as:

?([0-9A-Fa-f][0-9A-Fa-f])( *[0-9A-Fa-f][0-9A-Fa-f])*?";Solved / Missunderstanding;;;;"Currently, the only data object attribute whose type is OCTETSTRING that could be defined in SCL is originator.orIdent.

Part 6 Ed. 1 Table 42: The standard is clear about the coding: RFC 2045.

However, this couldn't be check by the schema.";;;Closed;;

30;IOP_2013;30 # IOP_2013;Should all SCTs support a substation section and the ability to associate LNodes into that section.;Low;Support;Closed;Should all SCTs support a substation section and the ability to associate LNodes into that section.;Solved / Missunderstanding;;;;"Part 6 Ed.2 mandates a substation section in the SCD file.

All the rest, editing the substation section, layout coordinates and LNode binding is optional (SICS S41 - S48) and is the plus value a vendor can add to its products.";;;Closed;;

31;IOP_2013;31 # IOP_2013;With the renaming of LNTypes, DOTypes, etc., there should be a specification as to the maximum size for these names. The XSD sho;Low;Support;Closed;With the renaming of LNTypes, DOTypes, etc., there should be a specification as to the maximum size for these names. The XSD should reflect the chosen size.;Already captured with TISSUE;;WG10;;Specify max size 256 octets;According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;June 2014 WG 10 Meeting;Closed;;

32;IOP_2013;32 # IOP_2013;Currently, in SCL, the size of an array is numeric. This could lead to issues of consistency (e.g. one having 32 array elements;Low;Support;Closed;Currently, in SCL, the size of an array is numeric. This could lead to issues of consistency (e.g. one having 32 array elements and the other 33). This is not allowed in CDCs such as HDEL. It is suggested that some mechanism be developed to use a single value instead of multiple integers.;;;;;unsure of problem, each phase array of an object of type HDEL has same length.;Addressed with Ed2;;Closed;;

33;IOP_2013;33 # IOP_2013;Throughout the IOP, there was discussion about validation. However, validation has several different levels to it. There is no v;Low;Support;Closed;"Throughout the IOP, there was discussion about validation. However, validation has several different levels to it. There is no vocabulary defined regarding this.

A model/set of definitions should be created to allow discussion about validation. The different levels already identified are:

1). XML ? is the file well-formed per the XML standard. 2). SCL Schema ? is the file well-formed per the SCL schema. 3). SCL ? is the file well formed in regards to mandatory/options expressed in 61850-6 that are not included in the schema.

4). Profile ? is the file well formed in regards to optional attributes that have been turned mandatory should a profile be created.

5). ObjectModel ? does the object model conform to the mandatory model components specified in 61850-7-3 and 61850-7-4.

6). Data Initialization ? do the <Vals> have the appropriate value (e.g. no String values for floating point values) and have the correct format.

Others?";;;;;"validation tools are now available online.

One tool is at https://www.trianglemicroworks.com/products/sclwebcheck";;;Closed;;

34;IOP_2013;34 # IOP_2013;"There is currently no mechanism to allow an array member to be added as a DataSet member

In the conformance tables of 8-1, alter";Low;Support;Closed;"There is currently no mechanism to allow an array member to be added as a DataSet member

In the conformance tables of 8-1, alternate access for arrays is marked out-of-scope. This prevents an element of an array to be used as a member of a DataSet.";;;;;Modify 8-1 Table to make Index and IndexRange conditional upon model supporting  arrays of FC=MX or FC=ST;Solved with tissue 1174;;Closed;;

35;IOP_2013;35 # IOP_2013;An SCL file was produced that had a GOOSE DataSet that contained members that had FC=CO and FC=CF. The SCT performing the import;Low;Support;Closed;"An SCL file was produced that had a GOOSE DataSet that contained members that had FC=CO and FC=CF. The SCT performing the import refused to import the file.

61850-7-3 ED.2 Specifies the allowed FCs for DataSets that are used for particular purposes (see clause 7.5.1). For GOOSE, only FCs of MX and ST are allowed. DataSets that are standalone, or used for reporting, may have any FC. In edition 2, the FC of CO no longer exists and therefore can?t be utilized. Additionally, 61850-7-3 ED.1 is mute on the allowed contents of a GOOSE DataSet (see Table 42), and therefore any FC is allowed.

This issue raises the issue of how and ED.1 device can co-exist in an ED.2 SCD";;;;;"Add note to 61850-7-3(Ed2)Tables 27 and 29 row ""datSet"": dataset may only contain members of FC=MX or ST";solved with tissue 1230 and 720;;Closed;;

36;IOP_2013;36 # IOP_2013;"A different client made use of a URCB that had been reserved in SCL for use by a different client via ClientLN.

Currently, there";Low;Support;Closed;"A different client made use of a URCB that had been reserved in SCL for use by a different client via ClientLN.

Currently, there is no way to enforce reservation on the server without utilizing Authentication which was not part of the IOP. Therefore, it is up to the clients to behave in accordance with the ClientLN reservation. Since the URCB does not have an indication that the RCB is reserved (e.g. no resvTms), this may happen in the real world. An option could be to add a reservation indicator into the control block as part of IEC 61850-8-1.";;;;;Already solved in http://tissue.iec61850.com/tissue.mspx?issueid=1276 . This requires Client to read the SCD file containing the reservation;According to Cathedral City meeting (ref. to UFTF-CathedralMOM20160219) this issue is closed.;;Closed;;

37;IOP_2013;37 # IOP_2013;"A question was raised in regards to how a client should resynchronize to receive the last report (Buffered Reporting).

The sta";Low;Support;Closed;"A question was raised in regards to how a client should resynchronize to receive the last report (Buffered Reporting).

The standard is clear that resynchronization gives the next report, not the last report. However, it was suggested that guidance be given on how clients should generally perform this (e.g. GI for synchronization of data and the use of EntryID.). Guidance also needs to be given on the use of PurgeBuf and EntryID=00000000.

Target would be for a system design document within UCA IUG.";;;;;"Guideline would be as follows:

Write BRCB.RptEna value ""false""

Write BRCB.EntryID to last known value

If (Response-)

     Write BRCB.PurgeBuf value ""true""

     (optional) Write BRCB.EntryID value zeros

}

Write BRCB.RptEna value ""true""

NB: Writing to EntryID not needed because:

1) Upon failure to write EntryID, state=disabled

2) transition from disabled to enabled ""start repoting with first available entry""

Alternative resync if client wants every available entry but Write BRCB.EntryID fails:

Client notes ""gap in data"" and simply writes BRCB.RptEna value ""true""";Solved with tissue 1276;;Closed;;

38;IOP_2013;38 # IOP_2013;"When should buffering start for a reserved and fully configured BRCB.

The discussion was that buffering should probably begin up";Low;Support;Closed;"When should buffering start for a reserved and fully configured BRCB.

The discussion was that buffering should probably begin upon power-up";;;;;"Enter TISSUE clause 17.2.1 first bullet (BRCB):

Entries are buffered while BRCB.DatSet contains a valid value regardless of the state of BRCB.RptEna";Refer to 7-2 clause 17.2.2.1;;Closed;;

39;IOP_2013;39 # IOP_2013;A question was raised in regards to the expected behavior of a server/BRCB that has been purged (e.g. no events buffered) and th;Low;Support;Closed;"A question was raised in regards to the expected behavior of a server/BRCB that has been purged (e.g. no events buffered) and the client resynchronizes with EntryID=00000000 indicating return the first set of events. This results in a client not knowing if the resync was successful or not.

61850-7-2 ED.2 Figure 24 indicates that in such a situation, the Resynch should fail and give an indication of the failure. In 61850-8-1, that would translate into the V-Put failing.

61850-8-1 should specify a specific failure code to represent this situation.";;;;;"Unclear on issue:

Fig 24 does not say ""Set EntryID"" should fail.

Client can detect data loss by first attempting to  Write BRCB.EntryID to last known value with Response-.

If client ""knows"" data lost then it can either perform a PurgeBuf or simply set RptEna to gather partial record of events.";category expired;;Closed;;

40;IOP_2013;40 # IOP_2013;A question was raised in regards can Report EntryIDs be reused after IED restart. If so, guidance needs to be given for system d;Low;Support;Closed;"A question was raised in regards can Report EntryIDs be reused after IED restart. If so, guidance needs to be given for system design on how to recover/resync

The standards do not mandate any particular behavior. In general, this should not represent an issue since the events previously buffered are no longer present.

The issue is if a client reads the RCB and sees the same EntryID, what should the client do. This is part of the resync process that needs to be described.

Target would be for a system design document within UCA IUG.";;;;;Add note to clause 17.2.2 (somewhere) that EntryIDs must be unique across restarts.;The unicity of the entry is given by the couple entryID and TimeOfEntry.;;Closed;;

41;IOP_2013;41 # IOP_2013;Some switches discard the IEEE 802.1Q tag known as VLAN 0 on packets sent/received on the trunk ports. Others discard the packet;Low;Support;Closed;"Some switches discard the IEEE 802.1Q tag known as VLAN 0 on packets sent/received on the trunk ports. Others discard the packet entirely.

The IEEE 802.1Q specification does not give guidance to switch manufacturers in regards to what to do with VLAN 0. However, IEC 61850-8-1 mandates the use of VLAN 0 as the default value to use since it represents a priority only tag and should not require the configuration of VLANs. The impact to users is that GOOSE and SV traffic will either lose their priority or be dropped entirely. It will make diagnosing network delivery problems difficult at best since there is no documentation provided regarding this behavior.

Switches claiming conformance/support for IEC 61850 should neither strip VLAN 0 nor discard those packets.

Add switch action pertaining to VLAN 0 to switch PICS statement. Address the use of VLAN 0 within WG10.";;;;;"802.1Q specifies ""A VLAN-aware Bridge ? shall support the use of all VID values in the range 0 through a maximum N ?""

801.1Q does not seem to allow switches to drop all packets with VID=0.

Standard could note (somewhere) that switches that drop VID=0 packets may not be suitable for use with 61850 systems unless the use of VID=0 is avoided.";Everything Is clear in the 90-4;;Closed;;

1;IOP_2015;1 # IOP_2015;"An ICT has required LGOS configuration coming from SCT to be able to subscribe GOOSE.

Is it the way it should work?

And is it re";Low;Support;Closed;"An ICT has required LGOS configuration coming from SCT to be able to subscribe GOOSE.

Is it the way it should work?

And is it required for an SCT to handle LGOS?";;;WG10;7-1, 7-4 ;"LGOS engineering to be described in Part 7-1.

Add note to 7-4 for LGOS/LSVS that 7-1 explains their engineering => Henry & Klaus-Peter.";Should be commented by a NC (German NC for 7-4);;Closed;;

2;IOP_2015;2 # IOP_2015;In the service section, there is the new element ?client services?. That element includes GOOSE (default FALSE). Is it required;Low;Support;Closed;"In the service section, there is the new element ?client services?. That element includes GOOSE (default FALSE). Is it required that every icd/iid file of a server (only), that supports GOOSE subscription, requires that element to be there? If missing, can a system tool assume that it cannot configure GOOSE messages to be sent to that device?

Issue centers around fix or conf referring to all CBs & datasets.  Is per-CB attribute needed?

If cbName = fix is CB deletable ?";;;WG10;6;"TISSUE to be written by The Bruce.

(In Part 6, GOOSE subscriber, not client.)";;;Closed;;

3;IOP_2015;3 # IOP_2015;An ICD file has predefined ReportControlBlock. With the SCT we attached a dataset to one URCB. Afterwards we decide to de-config;Low;Support;Closed;"An ICD file has predefined ReportControlBlock. With the SCT we attached a dataset to one URCB. Afterwards we decide to de-configure this URCB. SCT warning us and says that is not allowed to leave URCB empty so the tool delete the entire URCB.

Is it allowed to delete predefined RCB (blank or not RCB in an ICD file) ? There is a way to define a RCB services in the ICD file to clarify this issue?

Question:  is it allowed to delete predefined RCB (blank or not RCB in an ICD file) ? There is a way to define a RCB services in the ICD file to clarify this issue? ";;;WG10;6;"Refer to WG10 ---  Issue centers around fix or conf referring to all CBs & datasets.  Is per-CB attribute needed?

If cbName = fix is CB deletable?

WG10 Action:  No such thing as predefined.  It is either all fixed or not depends on service. See Tissue 1298.  Will create a tissue that clarifies the interaction service entries allowing delete of Control blocks vs fixed control block name.

Richard to post a TISSUE: how do we know if RCBs are all fixed or not? ConfReportControl: not clear of absence means they are all fixed.";Refer to the TISSUES 1444 and 1445;;Closed;;

4;IOP_2015;4 # IOP_2015;"Declaration of Clients in an SCL file:

The icd/iid file of a client only device can have a LN at the level of the access point.";Low;Support;Closed;"Declaration of Clients in an SCL file:

The icd/iid file of a client only device can have a LN at the level of the access point. The LN requires a data type template entry; even that the data model is not used ? is there a good reason for that?

A client LN reference may include a LD reference ? why, if the LN is at the access point?

If a client device declares in the icd/iid file a server with a LD and a LN e.g. IHMI, does this mean that this device has a well a server role?

If we have a device that has both a client as well as a server role, is the LN at the access point required, or is it then sufficient to have the LN in the server? Can a clientLN reference point to that LN in the server, even if there is as well a LN at the access point directly?

How to model an IED that supports two HMIs but has no server? Do we need to model two LN IHMI at the access point and we then configure to each of them a clientLN, differentiate the clinet LNs only by the Instance ID? What if the same device has as well a server and implements two logical device ? one each per HMI. Can I then configure the clientLN to the LD and LN of the server?

How should a client, and client/server SCL be defined and what should subscriptions look like.";;;WG10;6;No TISSUE as standard is clear.;;;Closed;;

5;IOP_2015;5 # IOP_2015;In the service section, an IED can declare ?modify dataset? to be FALSE. That means, datasets in the IED cannot be changed by th;Low;Support;Closed;"In the service section, an IED can declare ?modify dataset? to be FALSE. That means, datasets in the IED cannot be changed by the system tool.

Assume, an IED supports 10 datasets (declared in the service section), has preconfigured three datasets and declares modify dataset to be FALSE. Does the modify dataset only apply to the three preconfigured ones, and the SCT can add (and configure) 7 new datasets? Or does this mean, that the SCT cannot add any dataset, since it is no allowed to modify datasets.

If the second would be true, how can an IED declare that datasets can be added, but the existing ones cannot be changed?

Probably need more granularity on ?modify dataset?";;;WG10;6;"Issue: we may have 9-2 DS which are ?fixed?. Introduce modifiable flag on DS level?

TISSUE to be posted by Herb.";TISSUE 1444;;Closed;;

6;IOP_2015;6 # IOP_2015;"Declaration of CtlModel for controllable CDCs

(a) If a device does not support configuration of the ctlModel for a specific DO ?";Low;Support;Closed;"Declaration of CtlModel for controllable CDCs

(a) If a device does not support configuration of the ctlModel for a specific DO ? what is the correct way to declare this?

? Declare the DA as RO in SCL and configure a value (e.g. direct operate)

? Provide in the data model for that DO only the attributes required for the supported model (e.g. oper)

? Both of the above? And what if they disagree?";;;WG10;6;"If not writable outside of ICT/IED (i.e., valkind= RO and valImport = false), then it is optional. If restricted can deal as documentation only.

If writable, then only the supported control models shall be included (i.e., it must be restricted).";TISSUE 1447;;Closed;;

7;IOP_2015;7 # IOP_2015;"(a) If a device does not support configuration of the ctlModel for a specific DO ? what is the correct way to declare this?

? De";Low;Support;Closed;"(a) If a device does not support configuration of the ctlModel for a specific DO ? what is the correct way to declare this?

? Declare the DA as RO in SCL and configure a value (e.g. direct operate)

? Provide in the data model for that DO only the attributes required for the supported model (e.g. oper)

? Both of the above? And what if they disagree?

(b) If a device supports configuration of ctlModel, but does not support all variants

? Define the restrictions in a enum type, that is only applicable for all DOs that have the same constraint

? Provide in the data model for that DO only the DAs that are required for the supported model. Note that with that, you could not really define that a variant that is a subset (e.g. direct operate if SBO is supported as well), is not supported.

? Do a combination of above; e.g. define a enum type status only, sbo. Define the data model for some of the DOs that has oper and sbo DAs (this DO allows status only and sbo); and for some others, a data model that has none of the control attributes (this DO will be status only). Note: again, with that approach it may not be possible to support all variants.

? If restrictions are defined through a enum type, does the data model need to match the restriction (e.g., if a DO is defined with a specific enum type to support status only, is it forbidden to have oper in the data model?)

ENUMTYPE:

Declaration of enum types:

If a device does not support all possible values of an enum type (e.g. LN Mode ON-BLOCKED not supported), but it has no private additional values (extensions), it is allowed to define a enum type in the SCL file (data type template section) that is a subset of the standardized type.

- is it allowed or is it required to define a enum type that only includes the subset?

- In case it is required, does it need to be made for each usage of the enum type in a DO where it is different? With other words: assume some controllable DOs (e.g. of CDC SPS) allow only direct control without enhanced security; other DOs (e.g. of CDC DPS) allow only select before operate with or without enhanced security. Is it required to define two enum types or is it sufficient to define one that includes direct control without enhanced security, sbo without enhanced security and so with enhanced security. What in the case of units, when we have one DO that is currents (and apparently only SIUnit Amp applies) and another one that is PhV (and only Volts apply)?";;;WG10;6;"If not writable outside of ICT/IED, then it is optional to restrict the set of values. If restricted can deal as documentation only.

A DA is writable if

- it is a control service parameter, OR

- configuration DA (FC={SP,SE,CF}), and ( valKind!=?RO? OR valImport=true )

If writable, then only the supported enum values shall be included (i.e., EnumType MUST be restricted). Applies to DA level (of course restricted EnumType can be reused).

Are there exceptions, special cases? (Concern: SCL file size may increase.)

- Identified exceptions: SIUnitKind, MultiplierKind.

=> TISSUE to be written by? Herb!";Refer to TISSUE 1447;;Closed;;

8;IOP_2015;8 # IOP_2015;"An icd/iid file is not required to include the ?original SCL? element.

Is it required to be added to the IED instance in the SCD";Low;Support;Closed;"An icd/iid file is not required to include the ?original SCL? element.

Is it required to be added to the IED instance in the SCD file by the SCT in any case or is it sufficient to be added only if different from version referred to in namespace of the SCD?";;;WG10;6;"TISSUE to be posted by xxx, referring to 1398; make it clear that:

- ICD (Ed. 2 or later) shall set originalSclXxx attributes

- SCT shall set originalSclXxx attributes on importing an IxD file without originalSclXxx attributes according to the version of the SCL file

Add rule that for an IxD file, the originalSclXxx values shall match the SCL version/revision/release.";TISSUE 1450;;Closed;;

9;IOP_2015;9 # IOP_2015;"DUSTIN: 

Issue 1: X/Y Coordinates

Upon exchanging the SCD file between SCT tools, the drawing/visualization of the single line d";Low;Support;Closed;"DUSTIN: 

Issue 1: X/Y Coordinates

Upon exchanging the SCD file between SCT tools, the drawing/visualization of the single line diagram is incorrectly depicted. In general, there are a lack of X,Y coordinates supported to visualize the single line diagram between SCT tools. This is similar to SSD Problem Report (Vladen). Require coordinates for:

- Connectivity nodes

- Size & Location of All Objects

Some users/utilities have already created a standard/schema to model their single line diagram. Suggest using these as a starting point. 

VLADAN: During import of SSD file SST/SCT is not able to recognize Busbar connection node. 

It is connectivity node and there is no rule to recognize it during import.";;;WG10;6;"Consider with improvement of x/y coordinates. 

Explicit busbar would help CIM harmonization.

See TISSUE 1407 => Ed. 3";;;Closed;;

10;IOP_2015;10 # IOP_2015;"Issue 2: SCT Behavior When Revising/Replacing IED Configuration Between SCT Tools 

In terms of the data model structure and comm";Low;Support;Closed;"Issue 2: SCT Behavior When Revising/Replacing IED Configuration Between SCT Tools 

In terms of the data model structure and communication services, the SCT required a one-to-one relationship to be maintained between old IED and new IED, including:

- Physical Device Name

- Logical Device

- Logical Node

- Data Object

- Data Attribute

- Data Sets

- RCB?s

- Access points

- Communication Services";;;WG10;6;"2. Seems to be an implementation issue. Tool shall not crash.

? Is there a need to clarify Part 6 on what it means for an SCT to import an SCD? (It is a new project, not a merge.)

? Clarification of type of file to be used when another person is working on SCD, SED or SCD? For the first person, he may not have any rights on the IEDs anymore until the second person has done its work. Needs a picture in Part 6 to clarify. Complete Figure 1 for SCD import from 

? Note: SICS S7? have SCD import defined, but for the use case where one SCT is replaced by another (but no round-trip).

? Action item: Thierry & Chris to make a proposal till next WG10 meeting.";"Pictures to be in part 4 with description. Part 6, which needs comment on the CDV, has to be refered to part 4.

Closed because covered by the comment DE-12 on the part 6 Ed 2.1 CDV";;Closed;;

11;IOP_2015;11 # IOP_2015;"DUSTIN:

Issue 3: Symmetrical Bindings of DA In case of late Binding at DO/DA Level. 

IED expects DO at later binding, but source";Low;Support;Closed;"DUSTIN:

Issue 3: Symmetrical Bindings of DA In case of late Binding at DO/DA Level. 

IED expects DO at later binding, but source IED dataset has two DA of that specifc DO. In this case the SCT uses later binding to map first DA and also inserts a new ExtRef for 2nd DA. Since SCT is not allowed to insert intAddress. See slide 7 of WG10 ExtRef slides. Situations may occur when late binding is achieved using a combination of DO?s and DA?s. 

LOISEL:

Issue 3 ? GOOSE subscription

3.1. Can Inputs section be aggregated at LN0 level, or be within LN of subscription, or be somewhere else";;;WG10;6;Refer to WG10.   (extref presentation into standard) See new Annex in Part 6 (for Ed. 2.1);;;Closed;;

12;IOP_2015;12 # IOP_2015;"Issue 2 - IED restrictions not known by SCT 

2.1 IED support 50% URCB and 50% BRCB

Service section provide a total RCB number

2.";Low;Support;Closed;"Issue 2 - IED restrictions not known by SCT 

2.1 IED support 50% URCB and 50% BRCB

Service section provide a total RCB number

2.2 Ctlmodel

ICT vendor have a single Ctlmodel for the full IED. This limitation is not specified.";;;WG10;6;"Issue 2.1:  Allowed limitation need to be addressed in ED 2.1

Need to add a differentiation between URCB and BRCB in SCL 2.1: need to be able to indicate the limit on BRCB vs. URCBs? E.g., ConfReportControl.maxBuf (optional, no default; if not specified means can be up to max; cannot be greater than max). May only be defined (present) if bufMod = both.

Herb to write a tissue (should be for Ed. 2.1).

Issue 2.2: Recommendation that limitation be confirmed by WG10.

See ?SCL_Brunner_x_20150927_CtlModelDecl?.

If all controllables must have the same ctlModel value, then this is only allowed if all ctlModels are read-only (can only be set in the ICT) => all ctlModel DAs have valKind=RO and valImport=false.

? Thus, described situation is not allowed.

There is no DA defining the control model of a whole device.";TISSUE 1448;;Closed;;

13;IOP_2015;13 # IOP_2015;"Issue 3 ? GoCB confRev - behaviour if ConfRev=?0? 

IED rejected that value.

7-2: If there are inconsistent attribute values in t";Low;Support;Closed;"Issue 3 ? GoCB confRev - behaviour if ConfRev=?0? 

IED rejected that value.

7-2: If there are inconsistent attribute values in the GoCB (for example the value of DatSet is Null) or if the value of ConfRev equals 0, a SetGoCBValues with the parameter GoEna equals TRUE

Standard is clear on the behaviour of the IED if RCB ConfRev =?0?

7-2:The initial value for ConfRev is outside the scope of this part of IEC 61850. The value of 0 shall be reserved. The value of ConfRev, upon a restart of the IED, is a local issue.";;;WG10;6;"Issue 3:  WG10 needs to address and probably make consistent with RPT.

Text already aligned for GoCB for Ed. 2.1 in Part 7-2.

Need to clarify what ?The value of 0 shall be reserved? implies: means a tool SHALL never set a confRev to 0 (applies to RCB, GoCB, SVCB, LCB). Editors of 7-2 to clarify the text.";;;Closed;;

14;IOP_2015;14 # IOP_2015;"Issue 4 ? Private section ? namespace moved from SCL node to Private nodes

ICT added the namespace within the privates instead o";Low;Support;Closed;"Issue 4 ? Private section ? namespace moved from SCL node to Private nodes

ICT added the namespace within the privates instead of keeping them within the SCL top node. It leads to issues during IID update in SCT.";;;WG10;6;WG10 to analyze the example and determine if it is allowed or not.  Example IID/SCD/SCD to be provided.;Explanation added into part 6 ed 2.1;;Closed;;

15;IOP_2015;15 # IOP_2015;"2.2. BufMod is optional for ReportControl. No default value provided by the schema. SCT is interpreting as unbuffered only.

Com";Low;Support;Closed;"2.2. BufMod is optional for ReportControl. No default value provided by the schema. SCT is interpreting as unbuffered only.

Comment (Rome 060616) 

Changed after reading the original test report. The description regards BufMod, not BufConf.";;;WG10;6;Make BufMod mandatory and add upgrading rules coming from Thierry document (Annexe I part 6). The aim is to provide the appropriate value based on the device documentation.;"Need comment on the CDV (57/1697/CDV amendment 1 of edition 2 of part 6).

Done";;Closed;;

16;IOP_2015;16 # IOP_2015;"PAUL MYRDA:

In SCL it is possible to define unbuffered report control blocks with indexed set to false but with max instances se";Low;Support;Closed;"PAUL MYRDA:

In SCL it is possible to define unbuffered report control blocks with indexed set to false but with max instances set to higher than 1. This was possible for edition 1 since IEDs where supposed to handle connection specific request, but this was modified in Edition 2. 

The text in part 6 edition 2 should be reviewed. 

<ReportControl ? indexed=""false"">

    <RptEnabled max=""7"" />

</ReportControl>

Issue 1:

(Already reported) Indexed = ?false? is not allowed when max > 1 (that is not in line with max = ?7?). Index = ?false? is ok if max = ?1?

            <ReportControl name=""URep01"" rptID=""URep01"" confRev=""1"" bufTime=""250"" buffered=""false"" intgPd=""0"" indexed=""false"" datSet=""URDSet01"" desc=""Predefined Unbuffered Report 01"">

              <TrgOps dchg=""true"" qchg=""true"" period=""true"" />

              <OptFields seqNum=""true"" timeStamp=""true"" reasonCode=""true"" dataSet=""true"" dataRef=""false"" configRef=""false"" />

              <RptEnabled max=""7"" />

Also, what does max=?0? mean?

Issue 2:

(Implementation issue) Number of RCB :     <ConfReportControl max=""14"" bufMode=""both"" bufConf=""true"" /> 

But when we count all instances of RCB max = 56. Already clarified in TISSUE xyz

Issue 3: 

When converting SCD file from revision 2007B to 2003 should SCT maintain modification of Data model NS revision (to change everything to 2003) or ICT should bypass this issue?";;;WG10;6;"Need to fix the specification of indexed=false what the allowed value of max is (fix in part 6).

Issue clear in the standard.

Ed. 2 has the following restriction: ?In case of buffered control blocks indexed may only be set to false, if only one instance of this type is possible, i.e. max=1.? [Part 6]

So ?virtual URCBs? are allowed (indexed=false and RptEnabled>1). Just not for BRCB.

issue 3: WG10 to write down the rules for mixed versions and NC need to comment on the CDV in order to bring this into the FDIS. (to be discussed before the next WG10 meeting (Chris, Pierre, Herb, Thierry, Camille))";Issue 3: Done and will be included in part 6 (annex I);;Closed;;

17;IOP_2015;17 # IOP_2015;"Issue 1:

During import of SSD file SST/SCT is not able to recognize Busbar connection node. 

It is connectivity node and there i";Low;Support;Closed;"Issue 1:

During import of SSD file SST/SCT is not able to recognize Busbar connection node. 

It is connectivity node and there is no rule to recognize it during import.";;;WG10;6;May want to add a busBar in SCL.;See to the issue 9;;Closed;;

18;IOP_2015;18 # IOP_2015;"Issue 1:

History section is present in ICD but during import SCT is discarding this history section.

Also, maintenance of histor";Low;Support;Closed;"Issue 1:

History section is present in ICD but during import SCT is discarding this history section.

Also, maintenance of history section revisions during import of several ICD/IID files has to be addressed.

";;;WG10;6;"When is this history needed?

Not history, but version/revision information from the last IxD.

Proposal: add two attributes to IED matching the SCL/Header.version (and revision) of the last imported IxD.

=> Optional ixdVersion and ixdRevision attributes on IED, shall be set in the SCD/SED by SCT upon import of an IxD. ICT can remove that information from IxD it exports, if present, must be the same as the IxD History.version and revision attributes.

Also: in IxD file we need to ?remember? the last SCD imported. (Different set of attributes)

=> Optional attributes scdVersion and scdRevision on IED element, shall be set in the IxD by ICT, and imported by SCT as is.

SCT shall indicate in the SCD which IEDs were modified?

Conclusion: Thierry, Herb, and Chris to make a proposal for next WG10 October meeting.";DE06 german comment;;Closed;;

19;IOP_2015;19 # IOP_2015;"When IID file from ICT includes ?mustUnderstand? attribute in <GSEcontrol> such as 

<GSEControl desc=""System Logical Device GOOS";Low;Support;Closed;"When IID file from ICT includes ?mustUnderstand? attribute in <GSEcontrol> such as 

<GSEControl desc=""System Logical Device GOOSE Control Block 1"" name=""gcb01"" datSet=""ds_gcb1"" confRev=""10000"" appID=""AA1D1Q01KF1System/LLN0gcb01"">

 <Protocol mustUnderstand=""true"" />

</GSEControl>

where is the proper order to add <IEDName> attribute? Prior to it, or the next to it? In general case, bottom or top? If tool checks the appropriate attribute order according to schema, it could be issue.";;;WG10;6;"(2015-10-15): Thierry, Camille, Chris

The order of elements in SCL is clearly defined in the SCL schema, so no additional clarification is needed.

Nonetheless, Part 6 should  include an example showing the usage of the mustUnderstand attribute (with GSEControl/Protocol) for clarification.";it was done CDV amendment 2.1 part 6;;Closed;;

20;IOP_2015;20 # IOP_2015;Statement: an SCT A export an SED file with engineering rights ?fix? and expectation was SCT B could add Goose clients after imp;Low;Support;Closed;"Statement: an SCT A export an SED file with engineering rights ?fix? and expectation was SCT B could add Goose clients after importing SED file from SCT A.

Result: SCT B IS not allowing goose client cause by the engineering rights ?fix?

1-   A precision is require in the standard, Is the ?Fix? tag means also that is not allowed to add client to a goose from an IED already engineered by the fisrt SCT??

2-  When the engineering rights is ?fix? export a SED file should by restrictive down to the minimum ?";;;WG10;6;"(2015-10-15): Thierry, Camille, Chris

Even if engRight=fix you are allowed to add subscriber/client information.";it was done CDV amendment 2.1 part 6;;Closed;;

21;IOP_2015;21 # IOP_2015;"Issue 1: Content of CID with GOOSE Subscriptions

During testing we noticed some CID files contained a single IED, whereas others";Low;Support;Closed;"Issue 1: Content of CID with GOOSE Subscriptions

During testing we noticed some CID files contained a single IED, whereas others contained multiple IEDs. Many are under the perception that CID files are to only contain a single IED, however a CID file is also to contain the required information (e.g. MAC Address from other publishers) to bind the GOOSE publishers/subscribers, which may require multiple IEDs to be declared in a CID file.  

Some ICT tools are declaring the subscription information in private namespace instead of explicitly declaring it within the IED section using the SCL namespace. It should be clear that all information required for GOOSE binding is to be declared in the SCL namespace. 

The two issues are:

1. It is acceptable to have multiple IEDs in the CID file

2. Information required for GOOSE binding should be declared using the SCL namespace

This may also apply to Sample Values. ";;;WG10;6;"(2015-10-15): Thierry, Camille, Chris

1).  In a CID, it is acceptable to have multiple IEDs.  In an IID, it is not acceptable.

(2015-10-15): yes, already written in the standard.

- Ed. 1: ?It is an SCD file, possibly stripped down to what the concerned IED shall know?

- Ed. 2: ?It is an SCD file, possibly stripped down to what the concerned IED shall know (restricted view of source IEDs).?

CID shall not be used for exchanges between SCT/ICT tools. 

2).  The agreement on subscriptions has been made (e.g. not in private) but needs to be converted into the standard.

CID file is an SCL file and thus shall follow SCL rules => subscription must be in standard SCL at least (additional information may be required by the IED and is thus out of scope of the standard).";"the first part is already done

It will be done in the CDV amendment 2.1 part 6 for the second one";;Closed;;

22;IOP_2015;22 # IOP_2015;If the client reads a SCD file and loads then the data model (or vice versa ???) what data shall a client compare? confRef?s, da;Low;Support;In Progress;"If the client reads a SCD file and loads then the data model (or vice versa ???) what data shall a client compare? confRef?s, datSet in Control Blocks, ctlModels, everything...

There is nothing defined in the standard? or I missed it? but it makes sense that a client displays configuration mismatches, isn?t it?";;;WG10;7-2;;"assign to IEEE PSRC H30 working group

IEEE PSRC H30 (Deepak) in charge. To be checked regularly by the UFTF leader ";Contact again;Assigned;;Virtual-06-20

23;IOP_2015;23 # IOP_2015;"RptID attribute of a ReportControl section in SCL is optional, as stated in IEC 61850-6. 

IEC 61850-8-1 states to send RCB objec";Low;Support;Closed;"RptID attribute of a ReportControl section in SCL is optional, as stated in IEC 61850-6. 

IEC 61850-8-1 states to send RCB object reference as RptID when RptID is set to NULL in the Report service (17.1.2). 

But IEC 61850-8-1 does not state how to send RptID field when is set to NULL for GetBRCBValues/GetURCBValues (17.2.2 and 17.2.4).*";;;WG10;7-2;"It is described in part 6 (table 23 ed2) and 7-2 (17.2.2.4) and it is necessary to read both of them to understand.

The same informatioin is in the part 8.1 and shall be clarified or removed (Thierry Dufaure and Herb)";8-1 will remove the line after part 7-2CDV (amd 2.1) is accepted;;Closed;;

24;IOP_2015;24 # IOP_2015;"1. Report Control Block is disabled and four events (four reports) are generated

2. Client sends MMS Write RptEna=true to the BR";Low;Support;Closed;"1. Report Control Block is disabled and four events (four reports) are generated

2. Client sends MMS Write RptEna=true to the BRCB

3. Server sends the four InformationReport

4. Server sends the MMS Write success to the MMS Write RptEna=true request

5. Client ignores the four InformationReport because they were received before receiving the confirmation of the MMS Write RptEna=true operation

Should the standard clarify that this is a valid situation so the client should accept the InformationReport received before the confirmation to the Write operation?";;;WG10;7-2;;"Including in 2.1 amendment part 7-2 (17.2.2.1)

Tissue 1454";;Closed;;

25;IOP_2015;25 # IOP_2015;"For the latest TISSUE 1361 for Ed2.0 (statement in the attachment), there are two things to be clarified:

1. The statement: Swit";Low;Support;Closed;"For the latest TISSUE 1361 for Ed2.0 (statement in the attachment), there are two things to be clarified:

1. The statement: Switching between the modes (Mod.stVal) should only happen as a result of an operator command to the data object Mod. Mod and Beh are always accessible by the services.

Question: What does the operator command mean? Only communication service or an local switch is also allowed? The statement may influence the implementation. 

2. The statement: The communication services for the data object Mod do not care about the status of the Beh of the LN, i.e. Mod will always accept commands with Test=false.Mod, Beh and Health will always have validity=good.

Question1): When the server is in test Mode, what test quality of Mod, Beh, Health should be? The statement says something about validity, but not the other quality bits.

Question2): ? Mod will always accept commands with Test=false?, what if the client send a command with test=true when the server is in test Mode? ";;;WG10;7-4;"Item 1.1 resolved  by Tissue 1273

Item 2.1: Tissue needs to be opened that supersedes 1331.  The new tissue should state that Server behaviour for LN and LD Mod, Beh, and Health the q.Test shall be false.  In order to facilitate backward compatibility, Clients and Subscribers shall ignore the q.Test bit for LN and LD Mod, Beh, and Health. Should be an Interop tissue.

Item 2.2:  Tissue 1331 clarifies that Mod accepts commands regardless of the value of the service parameter test in operate.";"

Needs NC comments (after the CDV) to be included in 2.1 amendment part 7-4

Tissue 1456

Done";;Closed;;

26;IOP_2015;26 # IOP_2015;The Quality bits alignment in 9-2LE seems different from 8-1 quality bits with ASN.1. So it caused confusion that which bit shou;Low;Support;Closed;"The Quality bits alignment in 9-2LE seems different from 8-1 quality bits with ASN.1. So it caused confusion that which bit should be sent firstly, especially for Validity. During the IOP test, people don?t have the same understanding of the same value ?10? of Validity, some take it as reserved, and the others take it as invalid. 

A clarification of Validity bit sequence is strongly recommended.";;;WG10;9-2;Clarified in 9-2 edition 2.1 table 17 ;;;Closed;;

27;IOP_2015;27 # IOP_2015;Testing unconfigured VLAN, there is a question of how VLAN tags (e.g. 20) should be handled by the HSR ring. However, what sho;Low;Support;Closed;"Testing unconfigured VLAN, there is a question of how VLAN tags (e.g. 20) should be handled by the HSR ring.   However, what should an application do?  As an example, a dataset was GOOSE?d with VLAN 0 and received and processed by a IED.  When the publisher changes and publishes on VLAN 20, should the IED still process the packet.

Please note this filtering is typically handled in a switch.  But with HSR, the switch is internal to the device.  

Should IEDs enforce VLAN filtering, or should we generate a recommendation/warning that VLAN tag enforcement is not guaranteed with HSR?";;;WG10;90-4;;Solved with ed 2 of 61850-8-1 Clause C.2;;Closed;;

28;IOP_2015;28 # IOP_2015;"HSR and PRP are redundancy protocols. 

In order to prevent a single point of failure, many people are considering 2 red boxes";Low;Support;In Progress;"HSR and PRP are redundancy protocols.   

In order to prevent a single point of failure, many people are considering 2 red boxes to connect from HSR/PRP to RSTP.

Results in RSTP and HSR/PRP network instability.  In the case of HSR, network saturation occurred almost immediately.

11 MB/s = 88 Megabits/sec of a 100 Mb network.  The bandwidth restriction of HSR actually saved the RSTP network.";;;WG10;90-4;"Kalki needs to check its configuration and investigate.

Need to fix 61850-90-12 to enunciate the issue.  Need to refer to IEEE 802.1cd for the development of a standard to fix the issue.";"Wait for advice from TC65 to possibly add comment on the 90-4 (Laurent, Patrick W., Herb)

To be checked with Herb whether it is assigned during the next IOP2017

CRC to check 90-4 ed.2";Ask C.B.;Assigned;Ask Hubert about 62439-3 and 90-4;Virtual-06-20

29;IOP_2015;29 # IOP_2015;Priority of error checking in controls ? i.e. position-reached instead of Blocked-by-switching-hierarchy. The order of checks i;Low;Support;Closed;Priority of error checking in controls ? i.e. position-reached instead of Blocked-by-switching-hierarchy.  The order of checks is not specified, but could lead to serious problems of interpretation.;;;UCA Testing committee;;;;;Closed;;

31;IOP_2015;31 # IOP_2015;"These test cases assume that a server will send a negative response to an operate to the same value.

Some servers will accept th";Low;Support;Closed;"These test cases assume that a server will send a negative response to an operate to the same value.

Some servers will accept this behavior as described in PIXIT.

The goal of the test is to get a negative response, which was possible with other scenarios.";;;UCA Testing committee;;;;;Closed;;

32;IOP_2015;32 # IOP_2015;Buffered reporting testing ? anomaly with resynch (write of entryId failed, but buffered reports still sent). Because of indexe;Low;Support;Closed;Buffered reporting testing ? anomaly with resynch (write of entryId failed, but buffered reports still sent).  Because of indexed report control block names, client selected different BRCB on second connection, but had entryId?s from the first.  Check reporting guidelines document to make sure entryIds are associated with BRCB instance, not dataset.;;;UCA Testing committee;;;;;Closed;;

33;IOP_2015;33 # IOP_2015;IEC 61850-9-3 slaves can by design lock themselves to IEEE C37.238 (Power Profile) masters. This is intended behavior, since IEC;Low;Support;Closed;"IEC 61850-9-3 slaves can by design lock themselves to IEEE C37.238 (Power Profile) masters. This is intended behavior, since IEC 61850-9-3 was defined that way.

If, in a domain, there is a grandmaster with C37.238 profile and another with IEC 61850-9-3 profile, the BMCA of the masters may not work, as both may announce themselves as grandmaster. The reason for this is that according to C37.238 all clocks that do not send the C37.238 Extension TLV are to be excluded from the BMCA. So an IEC C37.238 clock will always announce itself as master regardless of the presence of better 61850-9-3 masters.

This is not an interoperability issue within a standard since two standards are involved.

Proposal: insert a note on this issue in C37.238 revision to warn network engineers about this fact (since C37.238:2011 altered the default BMCA) ";;;;;;;;Closed;;

34;IOP_2015;34 # IOP_2015;Does the SVID character have to be specifically mentioned to be within 10-34 characters? Some of the vendors have implemented th;Low;Support;Closed;"Does the SVID character have to be specifically mentioned to be within 10-34 characters? Some of the vendors have implemented the svID field in the configuration tool to have at least 10 characters.

1) Reference page 15/31 of Implementation guide of 9-2LE Rev2-1 

2)Reference Page 27 of  IEC 61869-9 working draft may 2015";;;;;61869 has a should not SHALL for length.;;;Closed;;

1;UFTF;1 # UFTF;Optionality in DOI NamPlt, PhyNam resp. in ICD/IID file: IED.manufacturer, .IED.type, makes a device recognition in a machine to;Low;Support;In Progress;"Optionality in DOI NamPlt, PhyNam resp. in ICD/IID file: IED.manufacturer, .IED.type, makes a device recognition in a machine to machine environment almost impossible.

Product standard could be more strict also for SCL files. Engineering guideline could also address the issue (system management TF?).";Profile or Guideline;;WG10;90-16;"Ask Thierry for clarifications and for completion on following proposals.

1. If this request is for offline use only, then specify that manufacturer and type value appears in the ICD file. 

2. If this request if for online use, then add restriction that valKind shall not be conf on this attributes.";"To be discussed in the context of the new TF, decided to be created in Sochi, in charge of discussing IED specifications and engineering processes.

(20180613)

Product standard could be more strict also for SCL files. Engineering guideline could also address the issue (system management TF?).";"2019 (first draft)

Draft is not still available. Contact Thierry Coste and Laurent Guise";Assigned;;Virtual-06-20

1;IOP_2017/1;1 # IOP_2017/1;IEC 61850-6 leaves the definition of the meaning of the authentication options to the SCSM. However, neither 8-1 nor IEC 62351-6;Low;Support;Closed;IEC 61850-6 leaves the definition of the meaning of the authentication options to the SCSM. However, neither 8-1 nor IEC 62351-6 seem to define the meaning of password, weak, strong or certificate. I think I know what they mean by the words themselves but I can?t find the definition in the standards.;;;Other TC or WG;;"IEC 62351-6 needs to be updated to correct this issue.  It is currently under revision and may need to change/extend the enumerated values due to changes in 62351-4.

61850-6 INF states:

2748 The mandatory Authentication element defines, in the case of a device description the

2749 authentication possibilities, in case of a device instantiated in a plant the method(s) to be

2750 used for authentication. If all attributes are missing, the default method is none (i.e. no

2751 authentication, meaning that the attribute none has the value true). The exact meaning of the

2752 other methods, especially weak and strong, is defined in the stack mappings (SCSMs).

";;;Closed;;

2;IOP_2017/3;2 # IOP_2017/3;In Version 2 of the IntegratedApplication.scd?, we found the IED ?CYG_PR7367_A1_P1? AccessPoint ?G1? which contains a GSEControl;Medium;Feature;Closed;"In Version 2 of the IntegratedApplication.scd?, we found the IED ?CYG_PR7367_A1_P1? AccessPoint ?G1? which contains a GSEControl named ?gocb? but there is no associated GSE address in the Communication section. This seems to be an invalid GOOSE configuration because it cannot be published without an address.

The GSEControl had a datSet!=null. Indicating that the gocb was configured (but with no communication entry).  The standard does not declare if this is valid or not.

There may be more errors like this, but this was just the first one we found.";Implementation - improve conformance testing;Usage;WG10;8-1;"UCA SCT conformance testing must address.

Make a generic rule at the beginning of -6 about inter section references. In this particular case,<GSE can not exist without the matching/referenced <GSEControl

";"Add a general statement into part 6 to not allow referencing a SCL element which does not exist in the file unless the reference is none.

-> OK

(2019-06): Solved in IEC 61850-8-1 Ed2.1. A requirement is included to define GSE section for each fully defined GOOSE.";2019-06;Closed;;

3;IOP_2017/5;3 # IOP_2017/5;"SCD file has ?originalSclVersion=2007? for all IED, including First Edition devices.

SCT should have added ?2003? when original";Medium;Feature;Closed;"SCD file has ?originalSclVersion=2007? for all IED, including First Edition devices.

SCT should have added ?2003? when originalSclVersion/OriginalSclRevision was not in ICD file.";Standard extension required;Usage;WG10;6;"Edition 2.1 line 2509-2510 (of INF) states: ?Both attributes are set by the IED tool when creating the ICD or IID file, and shall be kept within an SCD file.?

No issue for the standard.

";"clarification needed in table 10 regarding originalSclVersion default value.

Update below table 10 to force SCT to fill them -> OK";Solved in IEC 61850-6 Ed 2.1;Closed;;

4;IOP_2017/6;4 # IOP_2017/6;The R-GOOSE test area SCD was created by importing an ICD that was of schema 2007 B3. It exported 2007 B2 without removing/down;Low;Support;In Progress;"The R-GOOSE test area SCD was created by importing an ICD that was of schema 2007 B3.  It exported 2007 B2 without removing/downgrading the B3 IED information.

IEC 61850-6 2.1 specifies that an SCT must support the newest version (e.g. B3 instead of B2) if there is a B3 device to be used.  However, there is also a downgrade allowed that changes the IED model (Service Capability in this case) to support B2.  It also states that if the SCT does not support the newest version (e.g. B3) may reject the unsupported schema ICD.

Does this present a migration issue for systems in the field?";Standard extension required;;WG10;6;"User input needed.

SCL Update: Extend must understand rule to help tool vendors on how to validate.

(20180613) Does this present a migration issue for systems in the field?

";(20180613) It is matter of engineering workflow covered in add2.1 of Part 6.;Ed3;Assigned;;

5;IOP_2017/7;5 # IOP_2017/7;The use of the Simulation bit in the R-GOOSE Payload is not clearly defined. It refers only to 8-1 which currently only specifie;Low;Support;Closed;"The use of the Simulation bit in the R-GOOSE Payload is not clearly defined. It refers only to 8-1 which currently only specifies the meaning of the simulation bit in the GOOSE PDU. The standard does not describe that the payload Simulation bit should reflect whether or not the Simulation bit is set on ANY GOOSE PDUs in that payload.

J.3.2.6.3 states: 

Simulation shall be a BOOLEAN value (e.g. one octet) and shall be as defined in 

IEC 61850-8-1.

This clause is self-referencing and does not properly define what the definition is. ";;;;8-1;"Clarify the text so that it is clear that there is a Simulation Bit in the payload whose value is the same as the Simulation bit in the GOOSE PDU for which the payload production wraps.  The text should be similar to clause C.2.5 which states:

?S: simulated. The S bit mirrors the service parameter Simulation of the SendGOOSE service. Its (redundant) presence in the ethernet header has been specified to allow performant filtering on layer 2 level. ?. 

8-1 Ed2.1 CDV issue

Resolved in FDIS, no action needed.";covers by the next revision;Wait until 61850-8-1 Ed.2.1 IS is published;Closed;;Golden

6;IOP_2017/8;6 # IOP_2017/8;IEC 61850-6 does not allow the authentication configuration (none, password, weak, strong or certificate) to be used for Client;Low;Support;In Progress;IEC 61850-6 does not allow the authentication configuration (none, password, weak, strong or certificate) to be used for Client applications that do not include a server.;Standard extension required;;WG10;6;SCL must allow IEDs (client and server) to declare capabilities for security. Make the extension in 62351-6.;Wait for IEC 62351-6 IS and then address it in part 61850-6;Ask Frances;Assigned;;Golden

7;IOP_2017/9;7 # IOP_2017/9;"Definition of a data set must contain a data object name but SCL does not require the doName attribute in the <FCDA/> element. 

";Medium;Feature;Closed;"Definition of a data set must contain a data object name but SCL does not require the doName attribute in the <FCDA/> element. 

There was an FCDA declaration for a dataset that contained a single entry:

              <FCDA ldInst=""LD1"" lnClass=""MMXU"" fc=""MX"" lnInst=""1"" />

This file would pass validation and was interoperable at previous interoperability tests.

However, 7-2 clause 12.3.3.2.2 defines an FCD as an attribute of a data object. The FCD definition above contains no attribute specification (just FC and MMXU). 

Given the reference in 7-2 to data object it seems that the doName for the <FCDA/> should be mandatory. It is currently only mandatory for GSSE. Recommendation is that the doName attribute should be made mandatory in IEC 61850-6 Table 23 and the schema be updated accordingly.

The FCDA statement for the data set above should now be:

             <FCDA ldInst=""LD1"" lnClass=""MMXU"" fc=""MX"" lnInst=""1"" doName=""Hz"" />

             <FCDA ldInst=""LD1"" lnClass=""MMXU"" fc=""MX"" lnInst=""1"" doName=""PhV "" />

             <FCDA ldInst=""LD1"" lnClass=""MMXU"" fc=""MX"" lnInst=""1"" doName=""A "" />";Standard clarification required;Usage;WG10;6;"Forward to WG10:   Recommend to update such that doName is mandatory.  Clarify in -7-2, -6, maybe -7-1.

In table at 3030 (INF of 2.1) it states: The

doName attribute is optional only if the data set is assigned to a GSSE control block

Proposed revision to remove the confusion about GSSE as a GOOSE Control block is GSEControl.  Proposed the revised text to read ?doName attribute is mandatory if the FCDA is for any other service other than the deprecated GSSE services.?.

";"short proposal implemented -> OK

(2019-06): Specified in 6 Ed2.1. In Ed.3 XSD will include the restriction (now it is not possible for backward compatibility)";(2019-06) No target date was set.;Closed;;

8;IOP_2017/10;8 # IOP_2017/10;"Regarding the Network infrastructure:

Some MU/SAMU cannot configure their SV stream to different VLAN ID , fixed to 0 (but can c";Low;Support;Closed;"Regarding the Network infrastructure:

Some MU/SAMU cannot configure their SV stream to different VLAN ID , fixed to 0 (but can configure Priority)

Some  MU/SAMU only send SV without VLAN tag

Should we state that each SV publisher have to be configurable in terms of VLAN to fit every project needs (every infrastructure network)?

Should we be able to declare it in the capabilities of the device (send VLAN tag, configure this VLAN tag (ID, priority) )?

Switches in general don?t have the same way (by default) to handle VLAN 0 tagged packets. Two different switches implementation on substation 1 setup has to handle the problem in 2 different ways. Is it suitable?

(Same for GOOSE)";;;UCA Testing committee;;"For GOOSE and SV, configurability of VLAN is stated into (wait for Vladan notes)... Standard shall provide configurability of VLAN for SV (it shall refer to 8-1 Ed2.1 is not stated in 9-2). For GOOSE it is stated in 8-1 Ed2.1. In the product standard for MU (61869-9) it is stated that VID parameter configuration range is from 0-4095 i.e. it is configurable.

Update Testing Procedures. Send to user feedback TF for further discussion.

Solution must consider Layer 3 multicast.

";"To be discussed in between 8-1 and 9-2 editors

(20180613)

For GOOSE and SV, configurability of VLAN is stated in 8-1 Ed2.1. Standard 61850-9-2 shall also provide mandatory configurability of VLAN for SV (it shall refer to 8-1 Ed2.1). In the product standard for MU (61869-9) it is stated that VID parameter configuration range is from 0-4095 i.e. it is configurable.

Update Testing Procedures. Send to user feedback TF for further discussion. Solution must consider Layer 3 multicast.

19-01-23: (B. Muschlitz) Layer 3 is not considered by UCA TF because it is decided to test according to 61869-9 that is not taking into account R-SV (yet)

";"Standard IEC 61850-9-2 to be updated (IS editor Frederic Leconte).

19-01-23: update confirmed.

UCAIug -Testing committee will adopt tests for 61869-9 for this purpose (Bruce Muschlitz)

19-01-23: 

release in Q1 2019.";Closed;;Golden

9;IOP_2017/15;9 # IOP_2017/15;The attributes of the DA element and BDA element in 61850-6 define the attribute ?type? to be used only if bType=Enum or bType=S;Medium;Feature;Closed;"The attributes of the DA element and BDA element in 61850-6 define the attribute ?type? to be used only if bType=Enum or bType=Struct is used to refer to the appropriate enumeration type or DA Type definition.

The IOP .scd files have type defined where bType does not equal Enum or Struct, which does not follow the 61850-6 description (Table 49 and 50) of the bType attribute in the DA and BDA element.

Vendor was unable to open the low and high voltage .scd files because of this. After removing the incorrectly defined type elements, the .scd file was able to be read by tool.";Standard extension required;Usage;WG10;6;"SCT

INF line 4096-4097 states: type: Only used if bType= Enum or bType = Struct to refer to the appropriate enumeration type or DAType (attribute structure) definition.

Propose change:  ?Shall only??

";"short proposal implemented -> OK

(2019-06): Specified in 6 Ed2.1. Conformance testing matches the type with NSD, so in principal it is included. ""type"" is only allowed if ""bType"" is ""Struct"" or ""Enum""";(2019-06) No target date was set.;Closed;;

10;IOP_2017/16;10 # IOP_2017/16;The integrated application area SCD (IntegratedApplicationv4.2_2007B.SCD) was created by importing an ICD which LD (PROT) has a;Medium;Feature;Closed;"The integrated application area SCD (IntegratedApplicationv4.2_2007B.SCD) was created by importing an ICD which LD (PROT) has a SGCB in LLN0. But the settings with FC= SP outside this setting group was changed to FC=SE in the exported DOType part.

If the constraint change is correct in the SCD, there is also another problem that the fc attribute of <FCDA/> of the same settings in DataSet are still SP.";Standard extension required;Usage;WG10;6;"

FC=SP means Setting (outside setting group). The attribute is mandatory, if this data shall be a setting outside a setting group (IEC61850-6 Chapter 5).

The SCT shall not change any  function constraint of the ICD file.

Suggest adding text around INF 3850-3859:  SCT may change the name/id of LNodeType, DAType, etc. found in the DataTypeTemplate section.  The SCT shall not change the underlying definitions unless specified by an upgrade/downgrade rule.  ";"short proposal implemented -> OK

(2019-06): Specified in 6 Ed2.1 section 9.5.1";(2019-06) No target date was set.;Closed;;

11;IOP_2017/20;11 # IOP_2017/20;"V4.1 of the SCD file contains an invalid device;

1. The T2WPDIF logical contains DOs of TotW, TotVAr, TotVA, TotPF, Hz and PhV

";Medium;Feature;Closed;"V4.1 of the SCD file contains an invalid device;

1. The T2WPDIF logical contains DOs of TotW, TotVAr, TotVA, TotPF, Hz and PhV

2. The timestamp for the MV associated with the TotX and Hz elements is in the ST functional constraint.

These errors are in the ICD file. Seems like an SCT should have prevented this from being passed to the SCD?";Standard extension required;Usage;WG10;6;"Where in the engineering workflow is SCL validation required?

Suggest adding text from 7-1 14.5.4 restricting the extension of CDCs to somewhere in -6 lines 327-329 or add a direct reference to the clause in 7-1.

";"Add reference to part 7-1 ?14 in part 6 ?9.5.1 (datatype template) to indicate that datamodel restriction is defined by 7-1  

-> OK

(2019-06): Specified in 6 Ed2.1 section 9.5.1";(2019-06) No target date was set.;Closed;;

12;IOP_2017/21;12 # IOP_2017/21;"Merging Unit/ICT is not capable to publish sampled measured values outside of the recommended destination MAC address range.

";Medium;Feature;Closed;"Merging Unit/ICT  is not capable to publish sampled measured values outside of the recommended destination MAC address range.

Table in 8-1 is informative and is being used as normative.";Standard extension required;Usage;WG10;8-1 and 9-2;"Extend usable MAC address range of the merging unit.

Add allowed ranges to 8-1 in addition to recommended range.

Currently:  Addressed in 8-1, 9-2 needs to be aligned.

";(2019-06): Specified in 8-1 and in 9-2.;(2019-06) No target date was set.;Closed;;

13;IOP_2017/22;13 # IOP_2017/22;"An implementation did not allow BRCB resvTms to be written while rptEnable was true.

Both Ed2 and Ed2.1 require resvTms to be wr";Medium;Feature;Closed;"An implementation did not allow BRCB resvTms to be written while rptEnable was true.

Both Ed2 and Ed2.1 require resvTms to be written as long as another client does not ?owns? the control block.";Standard extension required;Usage;WG10;7-2;7-2 Editors have confirmed that this is correct behavior and has been clarified in Edition 2.1.  No action is needed.;Already adressed;(2019-06) No target date was set.;Closed;;

14;IOP_2017/23;14 # IOP_2017/23;MSVID shall be unique. The integrated application SCD file allowed duplicate SVID?s for two merging units.;Low;Support;Closed;MSVID shall be unique. The integrated application SCD file allowed duplicate SVID?s for two merging units. ;;;;;WG10 to review how to check for unique IDs, particularly for fixed configuration devices.;;;Closed;;

15;IOP_2017/24;15 # IOP_2017/24;"SCD import of IntegratedApplication.scdHVv5 to ICT generated the following error:

A GOOSE or Sampled Value Control Block can on";Medium;Feature;Closed;"SCD import of IntegratedApplication.scdHVv5 to ICT generated the following error:

A GOOSE or Sampled Value Control Block can only have one single control block address entry in the whole communication section. Adding a second control block address was denied for GoCB  Name='gcb1'  Description='BreakerControl' Ref='GE_C264_LINE_1CONTROL/LLN0.gcb1'

The two AP?s are connected to different subnets, but they belong to the same IED.";Standard extension required;Usage;WG10;6,7-2;"Refer to WG10.

Suggest adding reference to 7-2 Table 1 Note which states:? All the services for spontaneous sending are limited to one access point per control block instance? for 9.4.4 and 9.4.5.

";"reference added is more generic, indicating that rule for communication aspect has to be considered while reading the part 6

-> OK

(2019-06): Specified in 6, 7-2 Table 2";(2019-06) No target date was set.;Closed;;

16;IOP_2017/25;16 # IOP_2017/25;SCD file removed unconfigured GOOSE control block but did not remove the Connected AP section contained GSE information.;Low;Support;Closed;SCD file removed unconfigured GOOSE control block but did not remove the Connected AP section contained GSE information.;Standard extension required;refer issue 2;WG10;6;See Rep003;"Refer to issue 2

update wording on usage of Fix to indicate that if any setting is fix, removal and addition of CB is not allowed (for RCB, LCB, GoCB and SVCB)

-> OK

(2019-06): Specified in part 6 section 9.3.2";(2019-06) No target date was set.;Closed;;

17;IOP_2017/26;17 # IOP_2017/26;SCT did not import GOOSE and 3 of the sampled value control blocks that existed in PMU ICD file. This caused validation failures;Low;Support;Closed;SCT did not import GOOSE and 3 of the sampled value control blocks that existed in PMU ICD file. This caused validation failures during SCD import to PMU.;Implementation - improve conformance testing;;UCA Testing committee;;"WG10 to review ?fix? services meanings.  See Vizimax ICDs.

No action required by WG10.

";"No action required by WG10. 

Implementation issue. Improve conformance testing. ";Assigned UCAIug -Testing committee ? to add test for this purpose (Bruce Muschlitz).;Closed;;

18;IOP_2017/27;18 # IOP_2017/27;"Server is not responding to some of the MMS requests. (see below)

What should the client do this case?";Low;Support;Closed;"Server is not responding to some of the MMS requests. (see below)

What should the client do this case?";;;WG10;7-2 / 8-1 and 8-2;"Client should abort or timeout pending requests.

Refer to WG10.

";Time out is negotiated in initiation. This is implementation issue on the client side. No action for WG10.;;Closed;;

19;IOP_2017/29;19 # IOP_2017/29;"Problem 1: SCT Removed Privates that were provided in ICD that should have not been removed.

Implementation

Problem 2: SCT adde";Low;Support;Closed;"Problem 1: SCT Removed Privates that were provided in ICD that should have not been removed.

Implementation

Problem 2: SCT added Extrefs even though the ICD did not provide partial Extrefs.

Refer to standard ? how to identify constraints.

Problem 3:  SCT did not add subscriptions (e.g. IEDName) for the GOOSE that was specified in the ExtRefs.

Ed2.1 requirement, OK for Ed2.

Problem 4:  ICD did not provide partial Extrefs.

OK, this is optional per CB.

File names involved were: MU02 V4.02 Side 2.icd and IOP_LV_v4_All.scd.";;;;;No action required by WG10 except to publish the AMD-1.;;;Closed;;

20;IOP_2017/34;20 # IOP_2017/34;Unclear with regards to lgos whether the additional instances of gcob should be included in scd file. Should the IED include max;Low;Support;Closed;Unclear with regards to lgos whether the additional instances of gcob should be included in scd file. Should the IED include maximum objects capable of/allowable instances in the .ICD and create all, or create them as needed?;;;;;Refer to WG10.;;;Closed;;

21;IOP_2017/35;21 # IOP_2017/35;Some SCT tools are removing incomplete Inputs with ExtRef?s of serviceType=?SMV? that are used for late binding of sample values;Medium;Feature;Closed;Some SCT tools are removing incomplete Inputs with ExtRef?s of serviceType=?SMV? that are used for late binding of sample values in all versions of the IntegratedApplicationHV.scd file.;Standard extension required;Usage;WG10;6;"Refer to WG10

Table 35, and its text, needs to be modified to state that  ExtRefs shall not be removed by the SCT as if the value of intAddr is not ?null?.

";"add statement in ExtRef description to not allow removing of ExtRef with intAddr defined

-> OK

(2019-06): Specified in part 6";(2019-06) No target date was set.;Closed;;

22;IOP_2017/36;22 # IOP_2017/36;9-2 LE requires that the APPID shall always be 0X4000. In 61869-9 Table 908 it is recommended to be unique to allow for filterin;Low;Support;Closed;9-2 LE requires that the APPID shall always be 0X4000. In 61869-9 Table 908 it is recommended to be unique to allow for filtering and enforced by the configuration system. There should be a note to allow for backward compatibility for 9-2 LE systems.;;;Other TC or WG;;Refer to WG10;;;Closed;;

23;IOP_2017/38;23 # IOP_2017/38;"An SCT deleted 2 sampled value control blocks out of 4, because in SMVsc, the value max was set to 2.

The reason that the ICT h";Medium;Feature;Closed;"An SCT deleted 2 sampled value control blocks out of 4, because in SMVsc, the value max was set to 2.

The reason that the ICT had max set to 2 was, that it wanted to express that out of the 4 a maximum of 2 is allowed to be activated.";Standard extension required;Usage;WG10;6;"Refer to WG10.

Conclusion:  Table 11 needs to be corrected so that max for MSV is the same definition for as GOOSE and Report Control.

";"fix the definition of max for SMVsc according to GOOSE

-> OK

(2019-06): Specified in part 6";(2019-06) No target date was set.;Closed;;

24;IOP_2017/40;24 # IOP_2017/40;We had PIM operability issues between vendors that prevented R-SV testing from Substation 1 to Substation 2.;Medium;Feature;Closed;We had PIM operability issues between vendors that prevented R-SV testing from Substation 1 to Substation 2.;Solved / Missunderstanding;Usage;WG10;8-1;"Prior planning requires that vendors are made aware of the exact requirements of each test to provide the equipment necessary to provide compatibility between vendors.

Vendors may wish to bring multiple devices of the same type to create a sandbox of interoperability testing.

";(2019-06): No related to the standard;(2019-06) No target date was set.;Closed;;

25;IOP_2017/44;25 # IOP_2017/44;Vendor has implemented TestBlock condition only in XCBR wherein the contact outputs are not operated in test block condition. Te;Medium;Feature;Closed;"Vendor has implemented TestBlock condition only in XCBR wherein the contact outputs are not operated in test block condition. Test block condition are not implemented in any of Rxxx and Pxxx logical nodes as they are not expected to trip breaker directly.

There exist used cases wherein PTOC/PDIS elements can exist in an IED directly in breaker compartment in field and XCBR node in a bay controller IED located in relay building. In such cases, it is expected that Pxxx or Rxxx nodes are expected to trip directly the breaker.";Solved / Missunderstanding;Usage;WG10;7-5;In order to allow this, binary contacts (input & outputs) should have representation in the standard so that test block condition can be implemented at the binary output level and there is no need to have this attribute in any other logical node.;(2019-06): Not accepted. PXXX and RXXX cannot trip directly the breaker. XCBR is needed to trip the breaker.;(2019-06) No target date was set.;Closed;;

26;IOP_2017/46;26 # IOP_2017/46;"Visualization issues:

1) IEC 61850-6 identifies a method of placing the SLD objects in the single line diagram. However, it doe";Medium;Feature;Closed;"Visualization issues:

1) IEC 61850-6 identifies a method of placing the SLD objects in the single line diagram.  However, it does not address the size of objects that have been place.

2) Also the connectivity of the objects is not available in the SSD.  Tools are connecting them per the internal logic.";Standard extension required;Usage;WG10;6-2;Refer to HMI standardization group.;(2019-06): SCL coordinates will remain as it is in Ed2.1 and will be removed in Ed.3 when IEC 61850-6-2 (HMI) is ready;(2019-06) No target date was set.;Closed;;

27;IOP_2017/47;27 # IOP_2017/47;Different level of expectations between the ICT and SCT. There is not a clear definition demarking the expectations between the;Medium;Feature;Closed;Different level of expectations between the ICT and SCT.  There is not a clear definition demarking the expectations between the tools.;Solved / Missunderstanding;Usage;WG10;part 6 ?10 anex G;;"add in ?6.3 reference to ?10 which explain more in detail the role of ICT/SCT

-> OK

(2019-06) It was stated in section 10 of part 6 Ed2.1, and it was in edition 2";(2019-06) No target date was set.;Closed;;

28;IOP_2017/49;28 # IOP_2017/49;"The BCs should adjust the clock accuracy to reflect their actual accuracy, not that of their grandmaster.

The indicator ?stepsR";Low;Support;In Progress;" The BCs should adjust the clock accuracy to reflect their actual accuracy, not that of their grandmaster.

The indicator ?stepsRemoved? is not sufficient. ";;;;9-3;To send to Hubert for next 9-3 revision;;;Assigned;;Virtual-06-20

29;IOP_2017/50;29 # IOP_2017/50;"The start-up behaviour of BCs is unsatisfactory.

A BC in holdover (i.e. grandmaster with no time reference), should not return t";Low;Support;In Progress;"The start-up behaviour of BCs is unsatisfactory.

A BC in holdover (i.e. grandmaster with no time reference), should not return to BC mode when the time reference is restored before its clock oscillator stabilizes to the new grandmaster.  The tested BC when connected to the time reference (GPS) immediately forward the GrandMaster time advertising the accuracy of the grandmaster. 

Otherwise, all slave clocks below the BC will be subject to the additional jitter of the BC?s clock resynchronizing to the GM.

This can be tested by disconnecting the BC for some minutes and then reconnect it to the grandmaster. ";;;;9-3;To send to Hubert for next 9-3 revision;;;Assigned;;Virtual-06-20

30;IOP_2017/51;30 # IOP_2017/51;"IEC/IEEE 61850-7-2 should clarify the relation between the PTP clock clockQuality signals and the

timeQuality in TimeStamp.

E.g.";Low;Support;In Progress;"IEC/IEEE 61850-7-2 should clarify the relation between the PTP clock clockQuality signals and the

timeQuality in TimeStamp.

E.g.  ?Clock Not Synchronized? refers to the slave clock, not to the grandmaster. The fact that the PTP grandmaster loses its GPS reference signal is not an indication that the IED clock is not synchronized, since the grandmaster could have an excellent stability. The total loss of PTP Sync messages during xx seconds should raise the ?Clock Not synchronized? flag, depending on the slave clock?s quality. 

This is best placed in IEC/IEEE 61850-9-3, but 7-2 should make a reference to it.";;;;9-3;To send to Hubert for next 9-3 revision;;;Assigned;;Virtual-06-20

31;IOP_2017/52;31 # IOP_2017/52;All masters adjust correctly (and conservatively) the ClockAccuracy field when degrading (loss of GPS) but they do not adjust th;Low;Support;In Progress;"All masters adjust correctly (and conservatively) the ClockAccuracy field when degrading (loss of GPS) but they do not adjust the variance (offsetScaledLogVariance) correctly. This is a measured value that is used in the Best Master selection. Most clocks set the variance to 0 or 65535, or to a fixed (not computed) value. 

Therefore, this field is unusable in the BMCA, a clock with a very poor variance could win over another clock that claims 0 variance. 

IEC/IEEE 61850-9-3 should indicate specifically that the variance has to be adjusted. ";;;;9-3;To send to Hubert for next 9-3 revision;;;Assigned;;Virtual-06-20

32;IOP_2017/53;32 # IOP_2017/53;To avoid errors of up to 800ns in media converters (e.g. 1 Gbit/s ? 100 Mbit/s, SFPs), IEC/IEEE 61850-9-3 should specify that th;Low;Support;In Progress;"To avoid errors of up to 800ns in media converters (e.g. 1 Gbit/s ? 100 Mbit/s, SFPs), IEC/IEEE 61850-9-3 should specify that the Sync messages have to be padded to the same length as the Pdelay_Req and Pdelay_Resp messages. Media converters should be tested for asymmetry.

This will be stated in the revision of IEEE 1588, but IEC/IEEE 61850-9-3 refers to IEEE 1588:2008.";;;;9-3;To send to Hubert for next 9-3 revision;;;Assigned;;Virtual-06-20

33;IOP_2017/54;33 # IOP_2017/54;"Some TC that are not set to the correct domain disrupt the network because they do not respond to 

Pdelay_Req coming from anothe";Low;Support;In Progress;"Some TC that are not set to the correct domain disrupt the network because they do not respond to 

Pdelay_Req coming from another domain than their own. 

This means that a replacement TC inserted out of the box could disrupt the network until it is properly configured.

According to IEEE 1588:2008, a TC only has a ?primary domain? for syntonization, but otherwise should respond to other domain TCs should respond to other domains.

A slave-only clock is not obliged to respond to a Pdelay_Req that is not from its domain.

To be clarified in IEC/IEEE 61850-9-3.   ";;;;9-3;To send to Hubert for next 9-3 revision;;;Assigned;;Virtual-06-20

34;IOP_2017/55;34 # IOP_2017/55;"IEC/IEEE 61850-9-3 should clarify the meaning and use of TimeTraceable and FrequencyTraceable.

In particular, it should clarify";Low;Support;In Progress;"IEC/IEEE 61850-9-3 should clarify the meaning and use of TimeTraceable and FrequencyTraceable.

In particular, it should clarify that the clockAccuracy is only valid if TimeTraceable is true, and that 

a temporary loss of signal to the reference clock does not clear the TimeTraceable flag, as long as the master retains the ability to announce a leap second correctly. ";;;;9-3;To send to Hubert for next 9-3 revision;;;Assigned;;Virtual-06-20

1;H30;1 # H30;"? Loss of GOOSE is equivalent to traditional

? SV reliability implications? 

Loose of SV is equivalent to losing the CT/PT signa";Low;Support;In Progress;"? Loss of GOOSE is equivalent to traditional

? SV reliability implications? 

Loose of SV is equivalent to losing the CT/PT signal

Protection applications typically need reliability (less than 1 electrical cycle). Currently SV profiles block protection element. 

Performance requirement for SV (to be defined). To be completed by H30";;;;;;;;Accepted;;

2;H30;2 # H30;"? Failover at link layer ? from 2ms to 2 sec.

Link Failover reliability problem ? 

Solution 1: need for end-end to connection or";Low;Support;In Progress;"? Failover at link layer ? from 2ms to 2 sec.

Link Failover reliability problem ? 

Solution 1: need for end-end to connection oriented monitoring

Feedback: Can relays monitor end-end link integrity? What existing IEEE 802.x standards? What new network standards ? PSCC, ?? Can failover be less then 1ms?

Solution 2: End-end communication path monitoring + centralized network monitoring including relay communication.

FAST switchover to backup protection (within 1 ms).

To define reassessment for other relative parties. To be completed by H30";;;;;;;;Accepted;;

3;H30;3 # H30;Rendundant CT/TT measurements;Low;Support;In Progress;Rendundant CT/TT measurements;Profile or Guideline;;WG10;90-20;"Manage dynamic selection of sampled value sources. Possible option is to define additional semantics in InRef, ExtRef to handle main and backup sources.

A new use case will be added to 90-20 document.";"Will be address in 90-20 task force

CRC: Ask Johan about this issue";;Assigned;;Virtual-06-20

29;ENTSO-E;29 # ENTSO-E;"Lockout: How should we model lock out by protection functions?

? Lock out by breaker failure

? Lock out by transformer protectio";Medium;Feature;Closed;"Lockout: How should we model lock out by protection functions?

? Lock out by breaker failure

? Lock out by transformer protection

? Lock out by cable differential protection";Standard extension required;Usage;WG10;;"In XCBR there is a Blkopen and Blkclose. Question is if it is sufficient to control these trough engineering or we need a new LN in order to control it automatically through this LN. This LN would handle as wel the reset. Proposition is to create a new LN in order create the most flexible solution and create the necessary signals/alarms for the scada

To create new LN in protection domain

19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (V.Cvejic) To be addressed by TF 7-5 (approval and deffinition what has to be done)

19-06-06: Use case presented and accepted. PTRC.Tr could be persistent or not, use case will be updated.";This use case will be sent to 90-25 TF to take it into account.;"19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (Vladan C) To send for comments to H31.

19-06-06: Finished";Closed;;

30;ENTSO-E;30 # ENTSO-E;Busbar protection (BBP): Diff/Kirchoff BBP;Low;Support;In Progress;Busbar protection (BBP): Diff/Kirchoff BBP;Standard extension required;;WG10;;"? Option 1: use PDIF instance per zone, but we could need additional DO and DA to the PDIF to cover busbar specific signals

? Option 2: we need a new LN for the busbar diff protection ? prefered solution of WG10

To create new LN in protection domain

19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (V.Cvejic) To be addressed by TF 7-5 (approval and deffinition what has to be done)";;19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (Vladan C) To send for comments to H31.;Assigned;;

31;ENTSO-E;31 # ENTSO-E;Busbar protection: ARC detection protection;Low;Support;In Progress;Busbar protection: ARC detection protection;Standard extension required;;WG10;;"? There is an arc detection LN but not a specific LN covering the busbar protection based on arc detection blocking

To revise ARC detection LN to cover BBP blocked by ARC prot.

19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (V.Cvejic) To be addressed by TF 7-5 (approval and deffinition what has to be done)";;19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (Vladan C) To send for comments to H31.;Assigned;;

32;ENTSO-E;32 # ENTSO-E;"Busbar protection: Simplified logic

(used for ex as a combination of the start of backward distance protection zones or combinin";Low;Support;Closed;"Busbar protection: Simplified logic

(used for ex as a combination of the start of backward distance protection zones or combining overcurrent start en directional overcurrent blocking)";Out of Scope;;;;"?The PDIR covers the simplified busbar protection based on directional overcurrent

?The ramelot (specific Elia application) is not covered by the standard but you could through eningeering derive if the trip comes from the ramelot (by using a specific stage of the overcurrent protection, that can be blocked by feeder overcurrent operates)

PDIR covers simplified logic protection and ramelot";;;Closed;;

33;ENTSO-E;33 # ENTSO-E;Pole discrepancy: no LN to cover Trip and pole disc. Identification;Low;Support;Closed;Pole discrepancy: no LN to cover Trip and pole disc. Identification;Out of Scope;;;;to check 7-500. There is engineering practice proposal if it is related to pole discrepancy.;;;Closed;;

34;ENTSO-E;34 # ENTSO-E;Transformer diff. protection: Restricted earthfault protection;Low;Support;Closed;Transformer diff. protection: Restricted earthfault protection;Out of Scope;;;;covered by PDIF;;;Closed;;

35;ENTSO-E;35 # ENTSO-E;Transformer diff. protection: Protection blocked by harmonics;Low;Support;Closed;Transformer diff. protection: Protection blocked by harmonics;Out of Scope;;;;There is PHAR that can be used for PDIF blocking.;;;Closed;;

36;ENTSO-E;36 # ENTSO-E;S/S related applications: Auxiliary transfer;Low;Support;Closed;S/S related applications: Auxiliary transfer;Out of Scope;;;;Found AATS LN in 90-6;;;Closed;;

37;ENTSO-E;37 # ENTSO-E;S/S related applications: DC battery model and converter/charger/rectifier alarms;Low;Support;Closed;S/S related applications: DC battery model and converter/charger/rectifier alarms;Out of Scope;;;;Found LNs (7-4, 90-3): ZBAT, SBAT, ZCON, ZBTC;;;Closed;;

38;ENTSO-E;38 # ENTSO-E;S/S related applications: Diesel aggregat alarm;Low;Support;In Progress;S/S related applications: Diesel aggregat alarm;Standard extension required;;WG10;;"in 7-420 (top check reciprocating generator) - found LN DCIP

19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (V.Cvejic) To be addressed by TF 7-5 (approval and deffinition what has to be done)";;19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (Vladan C) To send for comments to H31.;Assigned;;

39;ENTSO-E;39 # ENTSO-E;S/S related applications: 400VAC/110VDC;Low;Support;Closed;S/S related applications: 400VAC/110VDC;Out of Scope;;;;in 7-4 ZAXN and QVVR LN found;;;Closed;;

40;ENTSO-E;40 # ENTSO-E;S/S related applications: Fire detection/extinction;Low;Support;Closed;S/S related applications: Fire detection/extinction;Out of Scope;;;;SFIR (90-3) become KFIR (90-6);;;Closed;;

41;ENTSO-E;41 # ENTSO-E;S/S related applications: Access security system;Low;Support;In Progress;S/S related applications: Access security system;Standard extension required;;WG10;;"7-4 GSAL (Generic security alarm)?

19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (V.Cvejic) To be addressed by TF 7-5 (approval and deffinition what has to be done)";;19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (Vladan C) To send for comments to H31.;Assigned;;

42;ENTSO-E;42 # ENTSO-E;Health: Health of prot relay/subfunction;Low;Support;Closed;Health: Health of prot relay/subfunction;Out of Scope;;;;Will be clarified in 7-5;;;Closed;;

43;ENTSO-E;43 # ENTSO-E;Insulation Supervision: Gas detector sensor;Low;Support;Closed;Insulation Supervision: Gas detector sensor;Out of Scope;;;;covered by SIML LN;;;Closed;;

44;ENTSO-E;44 # ENTSO-E;S/S related applications: Auxiliary circuit supervision;Low;Support;In Progress;S/S related applications: Auxiliary circuit supervision;;;;;"More info needed

19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (V.Cvejic) To be addressed by TF 7-5 (approval and deffinition what has to be done)";;19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (Vladan C) To send for comments to H31.;Assigned;;

45;ENTSO-E;45 # ENTSO-E;Tap Changer Supervision: Tap discrepancy (3 pole transformer case);Medium;Feature;In Progress;Tap Changer Supervision: Tap discrepancy (3 pole transformer case);Standard extension required;Usage;WG10;;"To have similar solution like Pole discrepancy in XCBR (to extend YLTC)

19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (V.Cvejic) To be addressed by TF 7-5 (approval and deffinition what has to be done)";;19-01-23: To create Use-case with different scenarios in order to clearly define scope of application (Vladan C) To send for comments to H31.;Assigned;;

46;ENTSO-E;46 # ENTSO-E;"Protection scheme: Weak end infeed (1 phase and 2/3 phase operate missing)

According to 7-4 there is no operation defined for We";Medium;Feature;In Progress;"Protection scheme: Weak end infeed (1 phase and 2/3 phase operate missing)

According to 7-4 there is no operation defined for Week end infeed granulated in such way to have information about 1 phase or 2/3 phases operation.

a) Allocation of WEI is in PSCH.

b) If WeiMod is correctly defined (for example Echo and Operate) then there will be both EchoWei (SPS) and EchoWeiOp (SPS).

c) By logic: AND(PSCH.Op.general, PSCH.EchoWeiOp.stVal)==True can be retrieved signal required by ENTSO-e : Operate 1 phase by weak end infeed or:

By logic: AND(OR(AND(PSCH.Op.phsA, PSCH.Op.phsB, PSCH.Op.neut), AND(PSCH.Op.phsB, PSCH.Op.phsC, PSCH.Op.neut),?., AND(PSCH.Op.phsA, PSCH.Op.phsB, PSCH.Op.PhsC)), PSCH.EchoWeiOp.stVal )==True can be retrieved signal: Operate 2/3 phase by weak end infeed

d) Question is ? how to maintain semantics and not use GGIO to recreate this logical creation of signal for applications such as Gateway TC interface, HMI event list presentation, additional Logic?? Basically, building blocks are there but how to use them in standardized way?

Similar question arise for Distance protection 2/3 phase operate ? where logic (for example): OR(AND(PDIS.Op.phsA, PDIS.Op.phsB, PDIS.Op.neut), AND(PDIS.Op.phsB, PDIS.Op.phsC, PDIS.Op.neut),?., AND(PDIS.Op.phsA, PDIS.Op.phsB, PDIS.Op.PhsC))==True 

can result in expected Distance protection 2/3 phase operate but if we follow practice that DA(sometimes DO) = SCADA signal that this can be identified only as a gap.

";Standard extension required;Usage;WG10;;"To revise PSCH LN or to create new LN in protection domain

(19-06-06) To create Use-case with different scenarios in order to clearly define scope of application (Vladan C)";;"

Next meeting in Charlotte - 19/09";Assigned;;

47;ENTSO-E;47 # ENTSO-E;"Protection scheme: Reversal current logic LN/DO/DA missing

Does exist in some vendor solutions as extension of PSCH (that could";Medium;Feature;In Progress;"Protection scheme: Reversal current logic LN/DO/DA missing

Does exist in some vendor solutions as extension of PSCH (that could be in line that both WEI and Current reversal are used to manipulate Protection schemes). But at the moment there are no signal related to RCL.";Standard extension required;Usage;WG10;;"To revise PSCH LN or to create new LN in protection domain

(19-06-06) To create Use-case with different scenarios in order to clearly define scope of application (Vladan C)";;2020/02;Assigned;;

48;ENTSO-E;48 # ENTSO-E;"Distance protection: Distance protection - 1 phase and 3 phase zone extension signal missing

The zone extension is activated by";Medium;Feature;In Progress;"Distance protection: Distance protection - 1 phase and 3 phase zone extension signal missing

The zone extension is activated by the status of the autorecloser and the status of the teleprotection: if the autorecloser is in service and the teleprotection is out of service we extend the Z1 from 80% of the line to 100% of the line in order to trip on all faults on the full line is base time.";Standard extension required;Usage;WG10;;"To revise PDIS and exend with additional signals (zone extension)

(19-06-06) To create Use-case with different scenarios in order to clearly define scope of application (Vladan C)";;2020/02;Assigned;;

49;ENTSO-E;49 # ENTSO-E;"Switch on to Fault: operate by SOTF (FW) and SOTF (BW)

PSOF LN is related to Switch onto fault and there is Str (ACD) where, for";Medium;Feature;Closed;"Switch on to Fault: operate by SOTF (FW) and SOTF (BW)

PSOF LN is related to Switch onto fault and there is Str (ACD) where, for example, logic:

PSOF.Str.dirGeneral == Forward / Backward 

could create both Operate by SOTF (FW) and Operate by SOTF(BW) respectively.

";Standard extension required;Usage;WG10;;To revise PSOF LN;No issue. The Op DO is always ACT. Str DO is ACD. The direction information can be retrieved from Str DO.;2019-06;Closed;;

50;ENTSO-E;50 # ENTSO-E;"Busbar protection: End Fault protection

It is related to dead zone (to protected small section between breaker and CT).

In most";Medium;Feature;In Progress;"Busbar protection: End Fault protection

It is related to dead zone (to protected small section between breaker and CT).

In most cases, bus coupler is not having 2 CTs across the breaker to create overlapping zones and protect dead zone. Thus, with supervision of CB position (if breaker is open) and measuring threshold current of respective CT, BBP can be triggered to clear the fault in dead zone (solution depends on position of CT relative to protective zone). 

In existing vendor solutions today, extension of modeling is used to create REFP (protection related function End Fault Protection). It should be defined in IEC 61850 model.

";Standard extension required;Usage;WG10;;"To create new LN (name: REFP)

(19-06-06)  To create Use-case with different scenarios in order to clearly define scope of application (Vladan C). Possible new LN  PSTB";;2019/09;Assigned;;

51;ENTSO-E;51 # ENTSO-E;Voltage protection: Overvoltage protection - 3ph operate;Low;Support;Feedback;Voltage protection: Overvoltage protection - 3ph operate;;;;;;;;;;

52;ENTSO-E;52 # ENTSO-E;Voltage protection: Undervoltage protection - 3ph operate;Low;Support;Feedback;Voltage protection: Undervoltage protection - 3ph operate;;;;;;;;;;

53;ENTSO-E;53 # ENTSO-E;S/S related applications: Disturbance recorder - communication session active;Low;Support;Feedback;S/S related applications: Disturbance recorder - communication session active;;;;;;;;;;

54;ENTSO-E;54 # ENTSO-E;Synchrocheck: Synchrocheck - missing signals;Low;Support;Feedback;Synchrocheck: Synchrocheck - missing signals;;;;;;;;;;

55;ENTSO-E;55 # ENTSO-E;Autoreclosure: Autoreclosure - 3ph closing command missing;Low;Support;Feedback;Autoreclosure: Autoreclosure - 3ph closing command missing;;;;;;;;;;

1122;IOP_2019;1122 # IOP_2019;SCL validation was performed on ICD files with an SCL validation tool. An error was raised: ERROR: [SemanticConstraints] FCDA (;Medium;Feature;In Progress;"SCL validation was performed on ICD files with an SCL validation tool.  An error was raised: ERROR: [SemanticConstraints] FCDA (line 189) does not refer any existing DA or BDA in DataTypeTemplates section.

<DataSet desc=""Analog Data"" name=""DSet01"">

   <FCDA ldInst=""MET"" prefix=""MET"" lnClass=""MMXU"" lnInst=""1"" doName=""TotW"" fc=""MX"" />

   <FCDA ldInst=""MET"" prefix=""MET"" lnClass=""MMXU"" lnInst=""1"" doName=""Hz"" daName=""mag"" fc=""MX"" />

   <FCDA ldInst=""MET"" prefix=""MET"" lnClass=""MMXU"" lnInst=""1"" doName=""PhV"" fc=""MX"" />

   <FCDA ldInst=""ANN"" prefix=""ANN"" lnClass=""GGIO"" lnInst=""1"" doName=""AnIn01"" daName=""mag"" fc=""MX"" />

   <FCDA ldInst=""ANN"" prefix=""ANN"" lnClass=""GGIO"" lnInst=""1"" doName=""AnIn02"" daName=""mag"" fc=""MX"" />

   <FCDA ldInst=""ANN"" prefix=""ANN"" lnClass=""GGIO"" lnInst=""1"" doName=""AnIn03"" daName=""mag"" fc=""MX"" />

   <FCDA ldInst=""ANN"" prefix=""ANN"" lnClass=""GGIO"" lnInst=""1"" doName=""AnIn04"" daName=""mag"" fc=""MX"" />

   <FCDA ldInst=""ANN"" prefix=""ANN"" lnClass=""GGIO"" lnInst=""1"" doName=""AnIn05"" daName=""mag"" fc=""MX"" />

   <FCDA ldInst=""ANN"" prefix=""ANN"" lnClass=""GGIO"" lnInst=""1"" doName=""AnIn06"" daName=""mag"" fc=""MX"" />

   <FCDA ldInst=""ANN"" prefix=""ANN"" lnClass=""GGIO"" lnInst=""1"" doName=""AnIn07"" daName=""mag"" fc=""MX"" />

   <FCDA ldInst=""ANN"" prefix=""ANN"" lnClass=""GGIO"" lnInst=""1"" doName=""AnIn08"" daName=""mag"" fc=""MX"" />

 </DataSet>

Extract from DatatypeTemplates section:

<LNodeType id=""MMXU_RTAC"" iedType="""" lnClass=""MMXU"">

   <DO name=""Mod"" type=""ENC_mode_direct_enhanced_5032""/> 

   <DO name=""Beh"" type=""ENS_behavior_5032""/>

   <DO name=""Health"" type=""ENS_health_5032""/>

   <!-- Status information -->

   <DO name=""TotW"" type=""MV_5032""/>

   <DO name=""Hz"" type=""MV_5032""/>

   <DO name=""PhV"" type=""WYE_RTAC""/> [1]

</LNodeType>

<DOType id=""WYE_RTAC"" cdc=""WYE"">

   <SDO name=""phsA"" type=""CMV_5032""/> [2]

   <SDO name=""phsB"" type=""CMV_5032""/> [2]

   <SDO name=""phsC"" type=""CMV_5032""/> [2]

   <DA name=""phsToNeut"" bType=""BOOLEAN"" valKind=""RO"" fc=""CF"">

     <Val>true</Val>

   </DA>

</DOType>

<DOType id=""CMV_5032"" cdc=""CMV"">

  <DA name=""instCVal"" bType=""Struct"" type=""Vector_5032"" fc=""MX""/>

  <DA name=""cVal"" bType=""Struct"" type=""Vector_5032"" dchg=""true"" fc=""MX""/>

  <DA name=""q"" bType=""Quality"" qchg=""true"" fc=""MX""/>

  <DA name=""t"" bType=""Timestamp"" fc=""MX""/>

</DOType>

The doName ?PhV? of type ?WYE_RTAC? [1] is a structured object type (SDO)[2]

 and RiseClipse validation was expecting  the following FCDAs as per table 22 of  IEC 61850-6 Edition 2.1 2018-06  (Page:  95):

<FCDA ldInst=""MET"" prefix=""MET"" lnClass=""MMXU"" lnInst=""1"" doName=""PhV.phsA"" fc=""MX"" />

<FCDA ldInst=""MET"" prefix=""MET"" lnClass=""MMXU"" lnInst=""1"" doName=""PhV.phsB"" fc=""MX"" />

<FCDA ldInst=""MET"" prefix=""MET"" lnClass=""MMXU"" lnInst=""1"" doName=""PhV.phsC"" fc=""MX"" />

SCL Standard reference: IEC 61850-6 Ed2.1 Table 22 - Attributes of a FCDA element.

Should all name parts of PhV be contained in the doName?";Standard clarification required;usage;WG10;6;Create a tissue to clarify text;CBL: Create the tissue when the database is available, accept it and update standard.;"Once the folder for edition 2.1 is created in the new tissue database. Around june-20 

Folder has been created, Camille Bloch to create the tissue (sep-20)";Assigned;;Virtual-06-20

1337;IOP_2019;1337 # IOP_2019;A device presents all ethernet ports as a single access point. SCTs unable to configure the device to communicate on multiple su;Medium;Feature;In Progress;A device presents all ethernet ports as a single access point. SCTs unable to configure the device to communicate on multiple subnets due to having a single AP. The manufacturer of the device states IEC 61850-6 fails to clearly define what constitutes an AP and a subnet.;Standard clarification required;Usage;WG10;6; Recommend discussion of standard implementation for APs and subnets.;"61850-6 does not specify what a subnet is.

Multiple ethernet PHYs can be on the same AP

Services must be consistent across PHYs in a single AP.

2nd AP with serverAt is the conformant solution.

CBL and HF: Create a tissue to clarify this discussion plus the issue 1337.

Work has been done and there is a big discussion regarding the tissue. An agreement is needed first. Still open.

2020-10-29: A tissue #1672 has been created as a future work. To be solved in Ed2.2. There is no clear solution that accomodate to Ed2.1 and we have to create new attributes and upgrading/downgrading rules to make it compatible if needed. A new service capability description need to be created. And Ed2.1 client will not be able to be configure in such configuration. You will need to update your client before if you want to use the new configuration. The review request has been prepared but it is not circulated yet.

This issue represents a new use case not covered by IEC 61850-6, so the use case has to be created and addressed so no compatibility issue with previous editions as that is a new functionality";"It will be solved in IEC 61850-6 Ed2.2

(2022)

";Assigned;;V2020-10-29

1340;IOP_2019;1340 # IOP_2019;"Error found by ?rise-clipse? SCL File: IOP_2019_HV_v6_ed2.0.scd.

ERROR [RequiredAttributes] content shall be valid a";Medium;Feature;In Progress;"Error found by ?rise-clipse? SCL File: IOP_2019_HV_v6_ed2.0.scd.

ERROR            [RequiredAttributes] content shall be valid according to its type in P (line 1011)). The current value is 000 for type OSI-AP-Title.

As a consequence, the client application cannot connect to these IED.

This issue was detected when trying to connect to a relay. The value for AP-Title was not present in the ICD file, and a non-valid value was set by the SCT tool.

These values (000) are not correct for the application, although they are compliant with the SCL grammar (XSD schema)

";Standard clarification required;Usage;WG10;6;;"Bruce to Create a tissue to update the schema to validate the format of AP-Title and others.

Feb-2020: The tissue 1668 has been created, has been accepted and still under discussion the check that can be added.

Jun-2020: There is an agreement on the tissue but it is still not green.";;Assigned;;Virtual-06-20

1404;IOP_2019;1404 # IOP_2019;"In DataTypeTemplate, 125 LNodeTypes are not used in the IED section of the ICD file.

Example of error :

ERROR: [SemanticConstrai";Medium;Feature;Closed;"In DataTypeTemplate, 125 LNodeTypes are not used in the IED section of the ICD file.

Example of error :

ERROR: [SemanticConstraints] Unused LNodeType (id=LLN0_4) (line 156483) there is no LN or LNode referring this LNodeType

In addition, 3 DOTypes are not used in the IED section of the ICD file.

Example of error :

ERROR: [SemanticConstraints] Unused DOType (id=ENC_0) (line 161929) there is no DO or SDO referring this DOType

Is it allowed / usefull to keep all these unused LNodeTypes and DOTypes in the DataTypeTemplate section ?

";Solved / Missunderstanding;Usage;WG10;6;Unused types may be removed by the SCT. No guarantee that they are conserved in the SCD file.;It is allowed to maintain unused data types so the tool must handle it. No standard issue.;;Closed;;

1548;IOP_2019;1548 # IOP_2019;There is more than one redundant PhysConn for ConnectedAP of IED AccessPoint ?S1?. In addition there are none redundant PhysCon;Medium;Feature;Closed;"There is more than one redundant PhysConn for ConnectedAP of IED  AccessPoint ?S1?. In addition there are none redundant PhysConn on same AP.

<PhysConn type=""Connection"">

  <P type=""Port"">1-A</P>

  <P type=""Plug"">RJ45</P>

  <P type=""Type"">100BaseT</P>

  <P type=""Cable"">1</P>

</PhysConn>

<PhysConn type=""RedConn"">

  <P type=""Port"">1-B</P>

  <P type=""Plug"">RJ45</P>

  <P type=""Type"">100BaseT</P>

  <P type=""Cable"">2</P>

</PhysConn>

<PhysConn type=""RedConn"">

  <P type=""Port"">1-C</P>

  <P type=""Plug"">LC</P>

  <P type=""Type"">FOC</P>

  <P type=""Cable"">3</P>

</PhysConn>";Implementation - improve conformance testing;Usage;WG10;6;Resolve how RedCon are allowed;Part 6 (9.4.6 bullet 3 of restrictions) states that there can be only one (maximum) RedConn if there is a Connection physical port;;Closed;;

1700;IOP_2019;1700 # IOP_2019;Under the report block (below), the device was not able to process the code with ?indexed? = false and RptEnabled NOT EQUAL TO ?;Medium;Feature;In Progress;"Under the report block (below), the device was not able to process the code with ?indexed? = false and RptEnabled NOT EQUAL TO ?1?.  They had to change ?indexed? to ""true"" if RptEnabled is GREATER THAN ?1?.  

<ReportControl desc=""S"" datSet=""ds_rcb2"" name=""rcb4"" intgPd=""0"" buffered=""false"" bufTime=""0"" confRev=""10000"" indexed=""false"" rptID=""BT_BCUCCTBRK/LLN0.rcb4"">

              <TrgOps dchg=""true"" dupd=""false"" gi=""true"" period=""false"" qchg=""true""/>

              <OptFields configRef=""true"" dataRef=""false"" dataSet=""true"" entryID=""false"" reasonCode=""false"" seqNum=""false"" timeStamp=""true""/>

              <RptEnabled max=""7"">

From IEC61850-6 (2018), ?indexed? must = true if the max number of enabled reports is greater than 1";Standard clarification required;Usage;WG10;6;"Verify the conformance test and of ClientLN vs max

Additional information: Server is using AA Specific and needs a mechanism to allow Clients to be notified that they need to pay attention to the control block.

";"CBL to create a tissue to clarify usage of max of RptEnabled when indexed attribute is false and the relationship to RptEnabled.

Folder has been created, Camille Bloch to create the tissue (sep-20)";Once the folder for edition 2.1 is created in the new tissue database. Around june-20 ;Assigned;;Virtual-06-20

1800;IOP_2019;1800 # IOP_2019;"Client/server test.

The data model uploaded in the Client from the SCD file (v7) shows 32 Buffered Report CB (brcbA01=>16 and br";Medium;Feature;In Progress;"Client/server test.

The data model uploaded in the Client from the SCD file (v7) shows 32 Buffered Report CB (brcbA01=>16 and brcbB01=>16). While trying to enable the BRCB ?brcbA12?, we got an error response (object non existent).

In fact, this report brcbA12 doesn?t exist in the IED. It seems that the SCD, while instancing the RCB, exceeds the IED capabilities :

Extract from ICD file :

<ReportControl name=""brcbA"" confRev=""0"" buffered=""true"" desc=""System Logical Device Report Control Block""> (?) <RptEnabled max=""8""/>

Extract from SCD file

<ReportControl name=""brcbA"" confRev=""60000"" rptID=""L2_PU_GE_P443_Meas"" buffered=""true"" desc=""System Logical Device Report Control Block"" (?)              <RptEnabled max=""16"">

";Implementation - improve conformance testing;Usage;WG10;6;Device should reject config rather than serving part;CBL to create a tissue to modify part 6 adding a statement about ICT having to check the validity of the SCD file regarding the IED constraints. We will need a SICS statement to test.;oct-20;Assigned;;Virtual-06-20

1857;IOP_2019;1857 # IOP_2019;A reservation could not be made via SCL for an IED?s report due to the lack of a ConnectedAP associated with the client?s Access;Medium;Feature;In Progress;"A reservation could not be made via SCL for an IED?s report due to the lack of a ConnectedAP associated with the client?s AccessPoint.

The ICD file describes its client and server via independent AccessPoint definitions.

-6 Ed2 :

First paragraph after table 36

?Each connected access point optionally has one server-related address, and additional address

information for real time communication-related control blocks such as GSE control and SMV

control. If all three are missing, it describes only the Subnetwork connection topology, for

example for communication performance studies. For a complete SCD file, either the server

address or at least one control block address shall be specified.?

9.4.3 Address definition

Second paragraph:

?The access point address shall be filled with a unique value at least for server type access

points to get a complete SCD description.?

";Standard clarification required;Usage;WG10;6;The above citations show a need for clarification of the standard.  The first citation seems to suggest that a ConnectedAP is only applicable to a server.  The second seems to suggest that AccessPoint addresses are required to be unique ? preventing a client and server from sharing an IP address. ;"Clarification will be done through tissues of issues 1337 and 1800.

See 1337 issue.";"2022

";Assigned;;V2020-10-29

IntApp;IOP_2019;IntApp # IOP_2019;"IED in the SCD contains access points (S1 and others) with GSE with ldInst = ?Prot? and a single GoCB.

However, the GoCBs are i";Medium;Feature;Closed;"IED in the SCD contains access points (S1 and others) with GSE with ldInst = ?Prot? and a single GoCB.

However, the GoCBs are instantiated only in the ldInst=?Master? and no MAC-Address is provided for GSE where ldInst=?Master?.

The Access Points should refer to ?Master? not ?Prot? for the GSE

The posted IID file for this device has IED name = TEMPLATE and no GoCBs in any LDs

While this is apparently a ?simple? implementation error, not validating SCD files is causing numerous problems for some participants.

";Implementation - improve conformance testing;Usage;UCA Testing committee;;It appears that the device allows GoCB but only in some LD.  No way to express this in SCL currently.;"Tissue #1445 ed2 and 61850-6 ed2.1 table 11 states that if GSE configuration is not fixed, SCT can add or delete GoCB in any LLN0. It has to be tested. Bruce to guarantee is going to be tested in conformance testing.

Bruce answers: ""New test procedure regarding the issue.

Verify that GSEControl can be added to any LN0

Add one GSEControl to first and last LN0 in the configuration of the device

Condition: Services/GSESettings attribute cbName is not ?fix? or absent and multiple Logical Devices exist and GOOSE max > 1""";;Closed;;Virtual-06-20

1601;IOP_2019;1601 # IOP_2019;"It is unclear, how to disable SV control blocks that are not in use.

No SV control block can be deleted. How do we indicate, whi";Medium;Feature;Closed;"It is unclear, how to disable SV control blocks that are not in use.

No SV control block can be deleted. How do we indicate, which ones we want to send and which ones we want to disable? Is it allowed to not provide to the unused SMVC a communication address?";Standard clarification required;Usage;WG10;6;;"IEC 16850-8-1 Ed2.1 states that if GOOSE or SV is not fully configured, it will not be published.

CBR: An editorial tissue to part 6 will be created to clarify it.

Refer to Tissue #1241 related to GOOSE.

Feb-20: It will be available in 8-1 and 9-2 Ed2.1 that if GSE or SMV is not present, then the GOOSE or SV Control Block will not be published.

No update on part 6 is neccesary";feb-20;Closed;;Golden

1642_01;IOP_2019;1642_01 # IOP_2019;"Server and ServerAt access points are connected to the same SubNetwork.

Reverse engineering of subscription is not possible at S";Medium;Feature;Closed;"Server and ServerAt access points are connected to the same SubNetwork.

Reverse engineering of subscription is not possible at SCD import.

According to part 6:

";Implementation - improve conformance testing;Usage;WG10;6;;The standard is clear. It is an implementation issue however we may consider to allow in the future as part of other discussions related to subnetwork.;;Closed;;

1642_04;IOP_2019;1642_04 # IOP_2019;"Sample value supervision LSVS.SvCBRef were not configured.

Incomplete configuration.

How does the SCT know whether to configure";Medium;Feature;Closed;"Sample value supervision LSVS.SvCBRef were not configured.

Incomplete configuration.

How does the SCT know whether to configure or not?";Design error;Usage;WG10;;;Clarified in IEC 61850-7-1 Ed2.1 Annex G;;Closed;;

1710;IOP_2019;1710 # IOP_2019;"An IED declares the following constraints, that are not machine processable, in ""desc"" attributes:

<AccessPoint name=""ETH_1"" des";Medium;Feature;Closed;"An IED declares the following constraints, that are not machine processable, in ""desc"" attributes:

<AccessPoint name=""ETH_1"" desc=""Ethernet 1 Port, WARNING: If PRP redundancy is used this access point is unavailable"">

<SampledValueControl name=""MMSVCB02"" desc=""Only 2 streams can be enabled simultaneously"" ...>";Out of Scope;Usage;WG10;;Do we have a better way of declaring this restrictions?;The only way to expose the restrictions is to provide different ICD files.;;Closed;;

1120;IOP_2019;1120 # IOP_2019;"SCTs updating the confRev of 9-2 LE Sampled Value streams.

9-2 LE states attribute ConfRev to always have the same value.

Hence,";Medium;Feature;In Progress;"SCTs updating the confRev of 9-2 LE Sampled Value streams.

9-2 LE states attribute ConfRev to always have the same value.

Hence, the test tools which inject 9-2LE SV streams wouldn?t allow the user to modify the confRev.

But, the IEDs which do a check on the confRev of SV stream(s) before accepting the to 9-2LE streams wouldn?t subscribe to the SV streams from the test tools as there is a mismatch between the confRev of SV from the test tool (which is 1) and confRev of SV which the IED is expecting (as defind in the SCD).

1. The SCTs shouldn?t increment the confRev of 9-2LE SVs.

2. Suggestion: the IEDs accepting 9-2LE streams should perform a check on the confRev and should declare this in the PIXIT.

";Standard clarification required;usage;WG10;TF Communication superivison;SCT must recognize 9-2LE as fixed configuration.;"- ConfRev in the message serves the purpose that the subscriber/client needs to be reconfigured

- Reconfiguration may be dynamic (e.g. a client retrieving from the server the changes)

- Based on that ? detailed rules need to be defined, in what cases confRev needs to be increased ? this is currently discussed in the TF communication supervision

Feb-20: CRC: Check with Christophe Camelis

Jun-20: There are still discussions about ConfRev. A NWIP will be launched.";;Assigned;;Virtual-06-20

2108;IOP_2019;2108 # IOP_2019;"The SCT tool created an invalid ReportControl element.

<ReportControl desc=""Created by HELINKS STS"" datSet=""ds_rcb1"" name=""rcb2";Medium;Feature;In Progress;"The SCT tool created an invalid ReportControl element.

<ReportControl desc=""Created by HELINKS STS"" datSet=""ds_rcb1"" name=""rcb2"" intgPd=""0""

       buffered=""true"" bufTime=""100"" confRev=""10000"" indexed=""false"" 

       rptID=""INCB_BCUCFG/LLN0.rcb2"">

   <TrgOps dchg=""true"" dupd=""false"" gi=""true"" period=""false"" qchg=""true""/>

   <OptFields bufOvfl=""true"" configRef=""true"" dataRef=""false"" dataSet=""true"" entryID=""false"" 

        reasonCode=""false"" seqNum=""true"" timeStamp=""true""/>

   <RptEnabled max=""7"">

   </RptEnabled>

</ReportControl>

Per the standard, a buffered report is limited to one instance.

";Standard extension required;Usage;WG10;6;;"There were more investigations done on the issue: The problem was, that the IED intended to have association specific control blocks. Association specific control blocks can not be buffered so we assume for the remaining discussion, that the issue is with unbuffered control blocks.

For reports with indexed=false, max > 1 indicates the number of clients that can reserve the report; as they all have the same rcb name and hence it is association specific.

Client LNs may be added to indicate to the client that he shall use that control block. There shall not be more ClientLNs added than max

TISSUE for part 6 ? have a table representation of the use cases as TISSUE resolution.

Feb-20: CBL:TISSUE for part 6 ? have a table representation of the use cases as TISSUE resolution.";oct-20;Assigned;;Virtual-06-20

12;IOP_2019;12 # IOP_2019;"ICD files did not match requirements.

The icd file delivered for the initial configuration had a generic (out of the box) data";Medium;Feature;In Progress;"ICD files did not match requirements.

The icd file delivered for the initial configuration had a generic (out of the box) data model. The SCT was not able to map all required information into the IED ? multiple iterations were required until the ICD file was finally reflecting the requirements.

Sometimes, that was just the data model as such (i.e., the control of a switch (CSWI.Pos) was preconfigured as status-only and could not be changed by the tool as the data model did not provide the structure for control) ? the system design engineer had to communicate verbally with the IED what is needed and got a new file back with the modifications in the IED tool.

Sometimes, GOOSE messages could not be configured. Again ? through verbal interaction, the system design engineer told the IED design engineer what he needs as signals and the IED engineer configured the dataset for the GOOSE control block accordingly, such that it could then support the requirements. This required additional iterations.

The process needs to be clarified! According the standard, an icd file is a ? if needed pre-configured ? file that matches the requirements from the substation. The less flexibility an IED tool provides regarding configurability by the system tool, the more preconfiguration is needed. That requires the essential design work to be done in multiple tools.

To avoid this, the standard should enforce flexibility of the IED tools with regard to engineering capabilities through the system tool.

";Profile or Guideline;Usage;UCA IEC61850 group;;"Generate WP of best practices.

IOP to record a best practices guideline as a result of the IOP";"Generate guideline of best practices.

Feb-20: Check with Bruce

Jun-20: Check with Herb";;Assigned;;Virtual-06-20

1947;IOP_2019;1947 # IOP_2019;"Various ICT support different mechanisms where a SCT must connect the ExtRef, including:

- A dedicated GGIO LN

- A InRef at LN L";Medium;Feature;Closed;"Various ICT support different mechanisms where a SCT must connect the ExtRef, including:

- A dedicated GGIO LN

- A InRef at LN LGOS

But icd files do not declare noIctBinding

Connecting through an InRef does not seem the right approach.

Requiring dedicated places to bind, from Ed 2.1 on requires the declaration of noIctBinding

";Implementation - improve conformance testing;Usage;WG10;7-1;ICT issue;Has been clarified in IEC 61850-7-1 Ed2.1 Annex H;;Closed;;

637;IOP_2019;637 # IOP_2019;"ICD files contain an empty type=?? attribute in their IED element.

 <IED name=""IED name"" desc=""IEC61850 IED"" type="""" manufactu";Medium;Feature;Closed;"ICD files contain an empty type=?? attribute in their IED element.

  <IED name=""IED name"" desc=""IEC61850 IED"" type="""" manufacturer=""xxxxxx"" configVersion=""1"" originalSclVersion=""2007"" originalSclRevision=""B"">";;Usage;WG17;90-16;The validity/meaning of an empty string as a type should be clarified.;Will be addressed in 90-16 and it will be discussed in UCAIug SCL best practices whitepaper;;Closed;;

1742;IOP_2019;1742 # IOP_2019;Merging Unit standard requires MU clock to jump on PTP time jumps. But this cannot work if Boundary clocks exist between the clo;Medium;Feature;In Progress;Merging Unit standard requires MU clock to jump on PTP time jumps. But this cannot work if Boundary clocks exist between the clock source and sink because boundary clocks are not required to perform this jump.;;Usage;WG10;09-mar;Involves step requirement of 61869-9.  With boundary clocks that ramp, IEDs will not be able to meet the step requirement of 61869-9;"TISSUE needs to be raised against 61850-9-3 to place requirements on Boundary clocks

Feb-20: CRC: Check with Huber (put Christoph Brunner in copy of the e-mail)

Jun-20: CRC: Check the answer from Hubert and also wait to see if 9-3 is going to be reviewed";;Assigned;;Virtual-06-20