Logical Node mapping is a node-level binding: it tells STS that specification LN A corresponds to IED LN A'. But signals reference specific data points inside a Logical Node (Data Objects and Data Attributes — for example MMXU1.A.phsA.cVal.mag.f). It can happen that the IED Logical Node does not expose the exact data point the signal expects.
When this happens, the signal is unresolved: the Logical Node link is in place, but the inner data reference does not exist on the implementing IED.
In this example, our function contains a specification Logical Node PTRC2 with a signal referencing data attribute Tr.phsA.
We then implement this virtual IED with a real IED, and map the specification Logical Node PTRC2 to an IED Logical Node PTRC1. The signal status now becomes unresolved. This is because the logical node type of PTRC1 does not contain the data attribute Tr.phsA.
We can resolve the signal by mapping it to a different data attribute within the PTRC1 Logical Node. To open the Data Attribute Selection dialog, we click on the data column of the signal.
In the dialog, we can see all data present in the logical node type of PTRC1. We select a suitable data attribute, in this case Tr.general, and press OK.
The data column of the signal has now changed to PTRC1.Tr.general, and the status is implemented differently, because we have now deviated from the specification by using a different data attribute in this IED.
If we virtualize the IED again, the Logical Node will snap back into its specification state PTRC2 and the signal will reflect the data attribute we selected initially. Our specification is unchanged; we have only created a mapping for a particular type of IED.
