In case of multiple clients, 2 clients could reserve the same RCB. The first will succeed, the second will fail. The standard does not specify:
- How to prevent that 2 clients try to reserve the same RCB? This is prevented by pre-assigning RCB to client in the SCD. However the standard does not specify that pre-assignment of RCB is mandatory for client.
- Behavior of the client system in case another client has accidently reserved the URCB/BRCB. For example the client shall try the next index.
Proposal
The solution to prevent 2 clients to reserve the same RCB is to make pre-assignment of RCB in SCD mandatory for clients.
And/or make ResvTms mandatory for servers. as such it's easier for the client to determine if the BRCB is pre-assigned or not.
The server shall allow that a client sets all trigger options and all optional fields (already required for Ed2 as part server conformance testing). As such when writing a trigger option fails it is caused by a reservation and not because of an unsupported option.
Define behavior of a client in case URCB/BRCB is accidently reserved by other client (like a browser). The client shall try the next index. Compare the workflow of the attached guideline
Discussion
Created
Status
08 Dec 14
In Force (green)
No Change required.
08 Oct 14
Ballot Period
As part 6 definition is enough for specifying how preconfiguration of control block is to be done, no change are required.
Also the conclusion of the Testing Group on July/8th.
Proposal: no change
08 Jul 14
Discussion (red)
As Wolfgang mentioned, the standard defines an interface not an implementation.
The standard does not define for instance how a GOOSE subscriber detecting a GOOSE mismatch does recover from it. This would be an inplemenation issue to use the available services to recover from a configuration mismatch.
This is not a interface issue to define the recovery of the client.
24 Jun 14
Discussion (red)
Part 6 (Clause 9.3.8) defines how to define reserved RCB instances using ClientLN elements.
It additionally specifies (same clause):
- “for all permanently used buffered control blocks, a ClientLN shall be preconfigured, and ResvTms set to -1, if it exists. For all other
control block instances an existing ResvTms shall be set to 0”
- “If ClientLNs are preconfigured for unbuffered RCBs, then the Resv (URCB Reservation is described in IEC 61850-7-2) attribute of the RCB shall be set to true”
- “If ClientLNs are defined and the attribute indexed is set to true (which is the default value), the index (position) of the ClientLN in the list contained in the RptEnabled element is used as this number for this client (the first client relates to index 01)”
17 Jun 14
Discussion (red)
IEC 61850 as communication standard is open for different system solutions from completely statically predefined systems until completely dynamic systems. Therefore, as a standard,it must allow different implementation strategies for clients. In the SA world for security reasons typically fixed predefined systems are preferred. In this case clients must be able to read SCD files and use the definitions inside it. However, this kind of profile is not the only possible, and therefore not mandatory from a standard point of view. A manufacturer of a client must decide in which kind of systems his client shall be used, and the system integrator has to select those clients fitting into his intended profile.
Concerning ResvTms: the reason it is not mandatory is backwards compatibility with Ed1. Clients must be aware that there exist BRCBs without ResvTms! For Ed2 devices it is strongly recommended to implement it.