1587 Add a optional scl:srcAPRef to scl:ExtRef as a prefered AccessPoint
Created: 14 Jun 2017
Status: Discussion (red)
Part: Part 6 (2009-12; Edition 2)
Category: No impact on this part
When the stack or tools to parse and decode scl:ExtRef (a piece of signal flow between subscriber(client LN) and publisher(server LN)), There is possible one case in which scl:ExtRef can NOT deduce the Server LN when One IED has two AccessPoints, each of which has the same LDInst, the same LN(prefix+lnClass+inst), and the same CB Name.
Given the SubNetwork topology is correctly configured in the Communication section, from the topology we can select the related SubNetworks using the scl:ExtRef->scl:iedName and the scl:ExtRef/scl:LN/scl:AccessPoint->scl:name. When the case above happen, there are two scl:AccessPoints to match, so add scl:srcAPRef as a prefered AccessPoint can work around this issue.
BTW: scl:fc is a good filter when scl:daName is missing in scl:ExtRef, why not have it added an optional attribute?
Add a optional scl:srcAPRef to scl:ExtRef as a prefered AccessPoint
For reports each client gets a unique control block. Thus the information is accessable via each AP where the data model is visible at all, and only these can be used for reports. Therefore also here the AP attribute is not needed.
||07 Feb 18
In case of multicast association, it seems to work. In case of connection-oriented services like Report,Poll(read in MMS), the client LN need to access the ControlBlock information of the Server LN. For example, in case of ReportControl block, the Client LN needs to know the DataSet name using scl:datSet so as to decode the target DataSet's FCDA entries sequences, flatten name and its data type attributes etc. When the ReportControl block is marked as indexed, the Client LN also requires to access the RptEnabled/ClientLN directory so as to decide on the index(as suffix) that belongs to the Client LN like CBName01 (scl:srcCBName +suffix). If AccessPoint can not be uniquely selected, How those information can be accessed by the Client LN?
||14 Jun 17
According to IEC 61850-7-2, the services sendGOOSEmessage, sendMSVMessage, sendUSVMessage, Report occur only over 1 access point.
In case of multicast association, there can only be one GSE resp. one SMV over all access points of the publisher. Therefore, the APRef in the ExtRef delivers a redundant information.
In case of unicast association, the meesage is received over the access point that is used for enabling the communication. Having an APRef in the ExtRef would disable the usage of hot/hot, or hot/standby redundancy communication and is therefore not suitable.
|14 Jun 17
Privacy | Contact | Disclaimer
Tissue DB v. 126.96.36.199