173   Ctl modelling harmonization

Created: 27 Jun 2005

Status: In Force (green)

Part: General

Links:

Page:

Clause:

Paragraph:

Category: Issue for edition 2 of this part

Issue

7-2 contains parameters for Operate and Select request like origin, ctlNum etc. Due to a foreseen MMS mapping these service parameters are within 7-3 also explicitely modelled as attributes with FC=CO. Now, 8-1 maps these service parameters differently onto service type dependent data structures (SBO, SBOw, Oper,..), so that the 7-3 attributes are within 8-1 without any meaning, and lead to misunderstandings when mapping 7-3 data models to MMS. This should either be harmonized, or clarified better.

Proposal

Remove all attributes with FC=CO from the 7-3 data model, except the ctlVal. Change description of ctlVal such that it is not part of the data model, however defines the output data type of the Operate / Select services of 7-2. Then the appropriate texts in 8-1 would lead to a consistent interpretation. Further it is from the 7-2/7-3 modelling clear, that the service parameter values only 'live' for the time of the service execution, and can not be read back, if they are not mapped to the corresponding attributes with FC=ST/MX.

Discussion Created Status
Example SCD file added to illustrate the new data model inclusive additions from 8-1 12 Dec 05 In Force (green)
no negative comment received on voting; set to green 17 Nov 05 In Force (green)
Currently, there is one error in the proposal. I copied the service parameter T from part 7-2, but I did not take care about TISSUE #35 which changed the type for T from EntryTime to TimeStamp. Therefore of course, the type for the service parameter T should be TimeStamp. This is updated in the revision 2 of the proposal which is attached. 20 Oct 05 Ballot Period
Editor meeting for Final proposal:
Changes as defined in the attachement "TISSUE173_Control" shall be made.

In addition, add an example to Part 6 and 8-1 		10 Oct 05 Ballot Period
Final proposal:
Changes as defined in the attachement "TISSUE173_Control" shall be made. 		03 Oct 05 Discussion (red)
There is no need to change the type EntryTime. It should remain as it is, since we now can have backward incompatibility with the IEC devices already in fields. 23 Sep 05 Discussion (red)
I do not believe that EntryTime is an issue for Controls. 20 Sep 05 Discussion (red)
I am not sure about the issue with EntryTime. What I remember (but that may be outdated), EntryTime was used everywhere, where backward compatibility with UCA was an issue. It was discussed in Pittsburgh (see slideset attached) that new IEC devices and old UCA devices shall be able to exchange GOOSE messages and that although IEC is adding new services, the common set of services and control blocks shall be bit compatible.

But I am not sure, if the timestamp T falls into this category; I guess Herb or George should be able to answer that question. 		20 Sep 05 Discussion (red)
accepted, with one remark: according to my current understanding the data type EntryTime should always be replaced by or be identical to TimeStamp. 20 Sep 05 Discussion (red)
According to my understanding of the discussion in Klaus, we have also seen the possibility to define the CO attributes as service parameters in IEC 61850-7-3. Based on that, I have worked out a proposal that is outlined in the attachement. 19 Sep 05 Discussion (red)
Aaggreed in Klaus we proposed to add the Oper struture in the controllable CDCs, and move ctlVal, operTm, origin, and ctlNum, as well as T, Test and Check in 7-3.
8-1 takes care of introducing the SBOw and Cancel structures pararell to the Oper defined in 7-3. So there shouldn't be any uninteroperabilities issue anymore.
05 Sep 05 Discussion (red)
I do agree with Wolfgang. The FC=CO attributes should be defined in 7-2 genericaly and not in 7-3. This is already the case for the attributes T, Test and Check. They are only defined in 7-2 and mapped in 8-1 within the SBOw, Oper and Cancel structures.
These FC=CO attributes are defined to make the DO controlable (parameters of the service to control the object) and therefore the mapping has to specify how they should be interact with the common data class as it done in 8-1 annex E.
We had already several interpretation/interoperabilty problems regarding the mms variables and their description within the ICD file, and a powerfull model has to be fixed, that will not lead to any interoperability problem. 		04 Aug 05 Discussion (red)
For me, there is something inconsistent in 7-2:
clause 17.5.2.2 defines the service parameter Value to include ALL CO DataAttributes (including CtlVal).
clause 17.5.3.1 defines, that the DataAttributes except ctlVal need to be set before the control service can be issued on the DataAttribute ctlVal.
clause 17.5.2.1 defines as ControlObjectReferece the DATA to be accessed (not the DataAttribute; i.e. what is said in 17.5.3.1 is not possible)

This should be clarified. For me it looks like according to 7-2 (except what is said in clause 17.5.2.1) ctlVal is not different from the other CO attributes. Therefore, I do not see, why in 7-3 it should be treated different.
In addition, if clause 17.5.3.1 is true, it means that these CO attributes need to exist in the data model, since they have to be set (what I interprete as writing the values in the data model) before. 		27 Jun 05 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.3.6.1