1331   Mod, Beh and Health with q=TEST, client can't receive their states

Created: 18 Nov 2014

Status: In Force (green)

Part: Part 7-4 (2010; Edition 2)

Links: #1374 On-blocked Mode & Quality , #1370 Mod/Beh definition of value=2 "on-blocked" is contradictory to part 6 , #1330 proposal in tissue 830 seems not consistent with 7-3 Ed2 , #1273 Behavior of DOI "Beh" due internal condition , #1205 Behavior computation , #838 Testing in Beh=Blocked , #830 Mode/Behaviour & Quality , #712 interpretation of quality operatorBlocked , #671 mistake in definition of Mod & Beh

Page: 157

Clause: Annex A

Paragraph:

Category: Issue may impact interoperability of implementations of Edition 2

Issue

According to TISSUE 671, if an IED has its behaviour as "On" but an incoming data is with quality Test=TRUE, the expected behaviour of LN shall be “Processed as invalid”.

In this case, when datapoints Mod, Beh and Health have their quality bits Test=TRUE, all clients don't use the datas (see IEC61850-7-3 clause 6.2.2).
So if we want to change the behaviour of a LN of an IED through a client, we have to send a command on Mod datapoint. If Mod.stVal was 1 (ON), we change it to 3 or 4 (TEST or TEST/BLOCKED). When the positive command termination is sent by server, this one has to sent a report with the new value of Mod and Beh with quality bit Test=TRUE.

But as indicated in TISSUE 671, incoming data with quality bit Test=TRUE is processed as invalid, so not used by the client. In this case client doesn't know the new state of datapoints Mod, Beh and Health in the server.

Moreover if a client is lost and server has a LN passed with Beh=TEST or TEST/BLOCKED, at the reconnection of the client, it will not have the new states of datapoints in the LN of the server.

Proposal

1) Mod, Beh and Health have never their quality bit test=TRUE, client can receive the new value of datapoints.

2) We can create an exception for Mod, Beh and Health: if LN has the Beh=Test or Test/Blocked (so Mod.stVal=Test or Test/Blocked), quality bit test or Mod, Beh and Health is TRUE but client doesn't process them as invalid but as valid.

Discussion Created Status
Change to green 16 Sep 15 In Force (green)
As a summary the newest version of annex A has been provided (57-61850-7-4ed2-annex_A_20150730.pdf). All other attached files has been withdrawn.
The tissue goes to final proposal and is assigned to be category "interop". 		30 Jul 15 Ballot Period
1) Mod/Beh in blocked or test/blocked:
The question is very valid.
My proposal to change the description:

blocked - Control commands with Test=false will be accepted. Control commands with Test=true will be rejected (negative acknowledgment with AddCause=Blocked-by-Mode).

test/blocked - Control commands with Test=true will be accepted. Control commands with Test=false will be rejected (negative acknowledgment with AddCause=Blocked-by-Mode).

2) Health
The DO Health informs not only about the LN-function but also about communication services of this LN. The LN answers on request with all DO (value, quality; quality of calculated/process DO =invalid). Mod is still controllable; Settings and configuration attributes are still modifiable. Therefore, I think, Health shall be q.validity=good in case of Beh=off. The value (Ok, Warning, Alarm) of it can be a local issue (depending if it is a LLN0.Health or depending of the implementation of the LN supervision). 		27 Jul 15 Discussion (red)
I support this statement. The sentence in the first paragraph "Both, Mod and Beh, will always have validity=good" will be changed into "Mod, Beh and Health will always have validity=good."

The voting period for final proposal will restart on next Monday (20.July) if no opposition to this until Sunday. 		14 Jul 15 Discussion (red)
The final Proposal states:

Both, Mod and Beh, will always have validity=good.

No statement regarding to Health is made.
The Quality of DO Health should also represent an exception as the Health acquisition is independant of the Beh of the function.
Health is not a "Process Data". 		13 Jul 15 Discussion (red)
Change to cat. Interop. 09 Jul 15 Ballot Period
The annex file 57-61850-7-4ed2-annex_A_20150518.docx will be considered as the final source for amendment 2.1. of part 7-4.
Tissue goes to final proposal 		29 Jun 15 Ballot Period
Some small improvement in the description text of the annex given in attachement 57-61850-7-4ed2-annex_A_20150518.docx. 18 May 15 Discussion (red)
In attachment 57-61850-7-4ed2-annex_A_20150513.docx a new proposal will be provided. 13 May 15 Discussion (red)
I don’t see CILO as a special case. CILO (Beh=on) will never process the receiving data as valid when q=test. Status of incoming data has always to not be considered when Behavior of a LN is “on” and data is received when quality bit indicating test purpose. Data has to be processed as invalid, as it is done when quality bits indicates that the data is invalid. In any case, I agree that CILO can try to calculate interlock condition but it will not use the status value received, because received data is invalid.
With Xavier, we have updated the document with this remark.
04 May 15 Discussion (red)
The document Mod_Beh 20150415 says that "Process as valid" means that node must react accordingly its intended functionality, this must resolve problem with different reactions, but in this situation different manufactures must realize same functionality and reactions for the same nodes. 30 Apr 15 Discussion (red)
Clarification of the description in the table. Additionally I want to remember the following statement of edition 2: "The communication services for the data object Mod do not care about the status of the Beh of the LN." 15 Apr 15 Discussion (red)
Some additional input for the discussion:
There are different reactions on signals received with quality.validity=good and test:
e.g.
- PTRC (Beh=on) receives PTOC.Op with q=test. PTRC will not process the Op (filter out this test signal) , because it will execute a truly Op from another P-LN.
- CILO (Beh=on) receives XCBR.Pos with q=test from another bay. CILO will process this information as valid and can calculate interlocking conditions.

Regarding Mod/Beh/Health: I would suggest to add the following note: Mod/Beh/Health.quality.test will not set to true as proposed in the tissue (proposal 1 of the tissue). 		08 Apr 15 Discussion (red)
We provide a new table Mod/Beh for discussion. According this table data with validity=good and test=true will be processed as valid. So Mod, Beh and Health are valid too and will also be processed. 01 Apr 15 Discussion (red)
The tissue is right and accepted as such. A solution shall be discussed within editors and shall be included in revision 2.1part7-4.
18 Nov 14 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 25.2.18.2