1465   Behaviour of 'unsupported trigger option in Edition 1 and Edition 2

This tissue has following status: blue

Created: 18 Nov 2015

Links: #780 What are 'unsupported trigger option at a control block?

Page:

Clause: 17.2.2.11 Ed 2 and 14.2.2.11 Ed 1

Paragraph:

Category: No impact on this part

Issue: Edition 1 and Edition 2 says,
"If a BRCB does not support one or more of the trigger options, the attempt to set the TrgOps attribute to TRUE for one of these not supported values shall cause a negative response of the SetBRCBValues service"
and Edition 2 tissue 780 says,
"The BRCB must support all of the trigger options."

Does this mean edition 1 behavior should be changed as per tissue 780 or should it behave as it was earlier. Currently Edition 1 client devices are expecting negative responses for unsupported trigger options and to change the behavior of all the existing relays to support all trigger option doesn't seems to be a practical solution, also to simply sent a positive response for SetBRCBValues even though we don't support also will create issues in client devices.

Proposal: Edition 1 behavior should be the same as it was earlier
and Edition 2 should be as agreed in tissue 780.

Discussion Created Status
?
Ballot until Editor
Yes. Also SCL allows to set all trigger options, and this must be accepted by the IED. A server must support GI and integrity reporting and all other defined trigger options. If events for this will be delivered depends on the data model and the process. 24 Nov 15 blue
To sum up, if a client sends a SetBRCBValues (TrgOps, 011111) for trigger options, server has to send a positive response. But in this case if client sends a GetBRCBValues (TrgOps), all trigger options are TRUE even if server doesn't implement all trigger options?

In part 6, all trigger options managed by a Report Control are optional and not mandatory. Trigger options managed by the report are known from TrgOps element of ReportControl element from SCL definition.

Example:
<ReportControl name="PosReport" rptID="E1Q1Switches" datSet="Positions" confRev="0">
<TrgOps dchg="true" qchg="true"/>
<OptFields/>
<RptEnabled max="5">
<ClientLN iedName="A1KA1" ldInst="LD0" lnInst="1" lnClass="IHMI"/>
</RptEnabled>
</ReportControl>
20 Nov 15 blue
Have a look into the discussion of 780:
'A BRCB (and URCB and LCB) must support all trigger options' means, that setting any trigger option defined in the Edition of the server to TRUE or FALSE (e.g. by SetBRCBValue service or by SCD file) must be accepted.
Naturally if e.g. the data model does not provide trigger option 'dupd', or an appropriate event is never generated, then such an event will also never be reported.
Tissue 780 is valid for Edition 2. If this clarification shall also be used for testing Ed1 IEDs needs to be decided by UCA. In general all open Ed1 issues shall be solved as clarified in/for Ed2.
18 Nov 15 blue
The sentence "The BRCB must support all of the trigger options" is not really clear.

In Ed1 it's not mandatory to support all trigger option and in this case no all trigger options are implemented. For example in Ed1 trigger option "data update" is only in LN BCR, HMV, HWYE and HDEL. So if IED has not these LN, trigger option "data update" is not implemented.

So the behavior of server has to be clarify for Ed2 for BRCB.

Does it mean servers have to implement all trigger option?
Or does it mean servers have to send a positive response but in case of unsupported trigger the attribute value in server doesn't change?
18 Nov 15 white

 

Privacy | Contact | Disclaimer