A Client is able to verify whether a FunctionalEntity meets the expectation of system engineering. This example demonstrates how to use verification.


Figure D.31 – Sample for a FunctionalEntity

Figure D.31 illustrates a simple FunctionalEntity. The author defining the AcmeFEType provides mandatory input and output Variables (a, b, c, and d) and optional Variables x and y.

The author-defined type of a FunctionalEntity is uniquely identified by AuthorUri, AuthorAssignedIdentifier, and AuthorAssignedVersion. Therefore, a Client using the Verify Method may pass the following ExpectedVerificationVariables:

Since the author decided to provide optional Variables, an instance of this type may or may not provide x or y. To verify whether Variable x exists, a Client may pass the following ExpectedVerificationVariable:

The ApplicationIdentifier allows the identification of a specific instance of a FunctionalEntity and (if provided) any customization by using a name (for user representation) and a unique ID (for verification). A sample for customization is a drive or a process automation device that was configured by a specific engineering tool. A Client may pass the following ExpectedVerificationVariable:

  • PortableNodeIdentifier=“ApplicationIdentifier”,[0] Value =“537a9b43-5c84-4aaa-a105-a04fab2ba5b6” [1] Value=“827a9d43-8e86-6bcd-1256-b03fdc7ab9d3”.

Figure D.32 illustrates other items that might be validated.

Relative paths may also be used for verifying the FunctionalEntity. For example, a Client may verify whether CalcBlock is provided by the correct AuthorUri or that a configuration variable is set to a correct value, as illustrated in Figure D.32.


Figure D.32 – Additional verification items