1202   GI not optional

Created: 15 Jan 2014

Status: In Force (green)

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

Links: #1439 GI is not optional in BRCB/URCB

Page: 102

Clause: 17.2.2.13

Paragraph: before last

Category: Issue for edition 2 of this part

Issue

This paragrah states: "If a BRCB does not support general-interrogation then an attempt to set.....".
From this paragraph one could conclude that supporting GI mechanism is optional. This will cause serious interoperability problems for SCADA kind of client systems. Such client systems use the GI mechanism to initialize the state values and to determine the old buffered events <> new events after a connection loss.

Proposal

Remove this paragraph. Even better to state that the server device shall support the GI mechanism for both URCB/BRCB.

Discussion Created Status
08 Dec 14 In Force (green)
The paragraph will be replaced with "The server device shall support the GI mechanism for both URCB/BRCB."


This does not prevent the GI from being disabled by TrgOpts.GI as described in the last paragraph of 17.2.2.13. 		06 Nov 14 Ballot Period
Note that this was already discussed for Edition 1. Tissue 275 explicitly states that it must be possible to disable a GI - and providing a negative response in case that GI is disabled.
However, we can nevertheless demand that the mechanism shall be supported by ALL servers - with possibility to disable it... 		04 Nov 14 Ballot Period
Resolution is not clear.
Will paragraph be removed or replaced with "the server device shall support the GI mechanism for both URCB/BRCB."? 		04 Nov 14 Ballot Period
Proposal Accepted as written. 08 Oct 14 Ballot Period
I agree with Richard proposal.
I also see GI as essential in the power utility context.
Additionaly to the general interogation, the GI with OptFlds.dataRef=true is a way to get a dataSet definition, when the dataSet definition is bigger that the MMS PDU negotiated size.
21 Jan 14 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1