There are multiple ways to represent the situation in which a single Server can be accessed via two or more IP addresses. It is necessary to define a standard method of doing so. Some existing options are:
1. Create a second AccessPoint within the IED, referenced by a second ConnectedAP within a SubNetwork. Unfortunately, since Servers are contained within AccessPoints, this would require duplicating the entire Server and the entire LN structure beneath it. This is wasteful and prone to errors.
2. Add more "P" addresses to those permitted under Address, e.g. IP-SECONDARY. This can be done as an extension right now, but only if xsi:type is not specified within the "P". This means the validation process will do no checking of the format of the address. e.g.
<P type="IP" xsi:type="tP_IP">10.0.0.11</P>
<P type="IP-SUBNET" xsi:type="tP_IP-SUBNET">255.255.255.0</P>
<P type="IP-GATEWAY" xsi:type="tP_IP-GATEWAY">10.0.0.101</P>
Format checking could be added by creating new types, e.g. tP_IP-SECONDARY. There would also have to be tP_IP-SECONDARY-SUBNET, however, and tP_IP-SECONDARY-GATEWAY.
There is a third solution that is more intuitive.
Propose that the standard method be to create a second SubNetwork with a different SubNetwork.name, but containing a ConnectedAP having the same ConnectedAP.iedName and ConnectedAP.apName, as illustrated below. Then ConnectedAP/Address/P.IP can be different, representing the alternate IP address. This is consistent with the Internet Protocol concept of a sub-network.
It may even be worthwhile to move the Subnet Mask (IP-SUBNET)and Gateway (IP-GATEWAY) from the ConnectedAP and make them attributes of SubNetwork. The latter might be an optional feature since there are some topologies where devices on the same sub-network might not share the same gateway.
However, regardless of how the subnet mask and gateway are handled, this method is possible NOW. The schema currently checks for uniqueness of iedName and apName within a given SubNetwork, but not across all SubNetworks. This is good, because the solution therefore requires no changes to the schema. It only requires that WG10 agree that this is the standard method for representing redundant IP addresses.
At the moment IEC61850 defines that only one access point per server exists, and that each access point has a unique IP address. As long as there is no functional reason, e.g. communication redundancy, formally defined in 61850, there is no need for a second IP address. If new functionality is introduced by new work items, which might need a second IP address or not, it can be decided, how this is best be modelled. This is however outside the scope of this Tissue list.