In an industrial automation system, device identity and compatibility refers to the process and mechanisms used to check that AutomationComponents (e.g., controllers, drives, IO devices) in a system allow operation that is consistent or compatible with what was expected by system engineering.

It is a common practice that various properties of communicating AutomationComponents are verified to check that:

• AutomationComponents present in a system are either consistent with system engineering (i.e., match expectation);
• their communication interfaces and exhibited application behaviour are compatible with system engineering expectations.

There are several scenarios where the verification of various properties of an AutomationComponent is utilized in an automation system:

• ensuring that AutomationComponents match system engineering expectations during commissioning or initiating communication (e.g., detecting potentially missing Assets like IO modules in a modular IO system);
• replacing or updating an AutomationComponent or any of its subcomponents.

Identity and compatibility verification can be done at any time (and executed by any AutomationComponent or tool that knows expected properties and their values) as long as the AutomationComponents can be accessed via Client Server services. In an automation system, verification is typically done before AutomationComponents participate in the industrial control application or process. It is crucial to ensure that the participating AutomationComponents will supply output data (to a consuming AutomationComponent) and use the input data (from a producing AutomationComponent) in an expected way.

This document defines verification modes and a verification Method for Assets, which provides the possibility to verify an Asset’s identity and whether or not it performs at a level that is compatible with what is expected by system engineering. For FunctionalEntities, a verification Method is defined, which may be used to verify instance-specific properties (e.g., identifying properties) to ensure that it is consistent with what is expected by system engineering.

The subsequent clauses provide the general concepts for identity and compatibility verification.

Asset verification provides functionality to verify whether a given Asset’s type and instance information match or are compatible with what was expected by system engineering.

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 provides the possibility to verify an Asset’s identity. See 6.3.3 for a detailed description.

This clause introduces the concept of Asset compatibility, which allows an Asset to report if it is compatible with what was expected by system engineering.

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.

The IAssetRevisionType VerifyAsset Method combined with the AssetVerificationModeEnum AssetCompatibility allows verifying an Asset’s compatibility; see 6.3.3 for a detailed description.

FunctionalEntity verification ensures that a given FunctionalEntity conforms to what was expected by system engineering. This verification includes checking the FunctionalEntity’s author, identifier, or version (issued by the author of a FunctionalEntity). It also supports checking any Variables defined by the application.

It may include checking for instance-specific additional properties (e.g., the existence and values of optional properties that may represent the configuration of optional functionality or whether a FunctionalEntity is part of a specific application).

The IFunctionalEntityType Verify Method provides the possibility to verify instance-specific properties of a FunctionalEntity; see 6.4.3 for a detailed description.