Applicable use cases include:
- commissioning an automation system (e.g., a machine) to ensure all Assets in an engineered system are from the expected manufacturer and are the expected model;
- prior to or at the initiation of data communication between AutomationComponents to ensure nothing has been (adversely) changed (e.g., during maintenance or shutdown);
- after conducting a firmware update to ensure the updated Asset is compatible with what was engineered;
- after replacing an Asset to ensure that the Asset has been replaced by one that is compatible or identical to what was engineered;
- verification of the instance of an Asset (e.g., serial number), which is often a requirement in certain applications and industries (e.g., pharmaceutical).
Asset identity refers to an Asset’s properties that make unambiguous identification possible. The IAssetRevisionType VerifyAsset Method, in combination with the AssetVerificationModeEnum AssetIdentity or AssetVerificationModeEnum AssetIdentityAndCompatibility, provides the possibility to verify an Asset’s identity. See 6.3.3 for a detailed description.
An important use case is AutomationComponent replacement. If an identical replacement (same manufacturer, model, and firmware) is unavailable, the vendor may be shipping a compatible substitute with updated hardware or firmware.
Asset compatibility verification provides functionality to verify whether a specific Asset’s properties match or are compatible (e.g., a newer firmware that is backwards compatible) with what was expected by system engineering.
Knowledge about Asset (and/or firmware) compatibility typically only exists with the vendor of a specific Asset. Thus, compatibility may only be able to be determined by vendor-specific tools or a vendor’s Asset.