Figure D.14 illustrates the Assets of a rack-based controller. The vendor modelled a 12-slot rack with Connectors, a communications module, and two controllers (CPU) modules. The IsPhysicallyConnectedTo Reference indicates that the modules are plugged into slots 1 & 2, whereas slot 3 is unused. IO modules are plugged into slot 4, slot 6, slot 7 and slot 10.
Assume that the Descriptor contains for CPU1: ProductCode “ZY456”, MajorAssetVersion “2”, MinorAssetVersion”4”, and SerialNumber “N475655”, and for CPU2: ProductCode “YY544”, MajorAssetVersion “2”, MinorAssetVersion”7”, and SerialNumber “Z234545”.
A Client checking for compatibility of the Assets Controller1 and Controller2 by using VerificationMode AssetCompatibility will set the ExpectedVerificationVariables in VerifyAsset to the values as stated above, without the given SerialNumbers. The SerialNumbers should be added when using VerificationMode AssetIdentityAndCompatibility.
If the verified Assets match the expected values exactly, i.e., ManufacturerUri, ProductCode, MajorAssetVersion, and MinorAssetVersion are identical, Match will be returned. For example, if Controller2’s actual MinorAssetVersion is set to “9” but the Asset is still compatible with MinorAssetVersion “7”, Compatible will be returned.
Consider, for example, verifying whether an IOModule (NetIO-1) is plugged into Slot7. This can be done, as illustrated in Figure D.16, by using a relative path as:
The Client can verify that NetIo-1 is physically connected to Slot7 by resolving this relative path. The VerifyAsset Method may now be used by the Client to verify that the resolved Node has a value of 7.
This same concept can also be used to verify Assets that might not be directly linked to the AutomationComponent, i.e., they are not in the Assets folder but only referenced from existing Assets( see Figure D.16). In this example, the BrowsePath would look like:
This process could also be used to verify the values of configuration settings such as EngineeringUnits.