Improvement #7080
When an exchange is defined between 2 IEDs, check that they are connected on the same Subnetwork (at the AccessPoint level)
0%
Description
Background of OCL rule:
In case of reports, ClientLN.apRef and ClientLN.iedName (client using report) are checked against Servers apName and IedName (they should belong to the same Subnetwork)
In case of GOOSE and SV CB, IEDName.apRef and IEDName.value (subscriber to the GOOSE/SV) are checked against publisher apName and IedName (they should belong to the same Subnetwork)
While creating/testing an OCL Rule with definition as in Subject it was observed following:
When big scd file from IOP was tested, a lot of errors were reported ... Errors were also checked manually, and they are real errors. First question is - if these settings (IEDName and ClientLNs) are checked by SCTs? Should they be checked?
Also, what is interesting - IEDs ConnectedAP/Address were set like 192.168.1.xx with subnet mask 255.255.0.0 (belongs to one Subnetwork) and others are set like 192.168.10.xx with subnet mask 255.255.0.0 (belongs to another Subnetwork) - and because of such subnet mask they can 'see' each other - and Client/server communication will work even if they are not in the same subnetwork. Subnetwork is more a logical concept and it, also, will not stop GOOSE/SV to be distributed across the whole network (unless VLAN/Mcast filtering is used).
SCTs involved in engineering were not aware of this rule. And in SICS there is only requirement 'S361 - Allocate control block instances to clients & define data destinations (ClientLn element, IEDName element) for all types of data flow related control blocks.' Should there be another SICS requirement with regards to data flow and this limitation?
Another comment is - This question shall be pushed to TF 90-4, because there could be some equipment which can bridge subnetworks together allowing them (IEDs) to communicate.