A Client is able to verify whether a FunctionalEntity meets the expectations of system engineering. This example demonstrates how to use verification.
Figure D.32 – Sample for a FunctionalEntity
Figure D.32 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 can pass the following ExpectedVerificationVariables:
- PortableNodeIdentifier=“AuthorUri”, Value =“http://acme.org”
- PortableNodeIdentifier=“AuthorAssignedIdentifier”, Value =“7852-14”
- PortableNodeIdentifier=“AuthorAssignedVersion”, Value =“1.2”
Since the author decided to provide optional Variables, an instance of this type can or cannot provide x or y. To verify whether Variable x exists, a Client can pass the following ExpectedVerificationVariable:
- PortableNodeIdentifier=“x”, Value =null
The ApplicationIdentifier allows the identification of a specific instance of a FunctionalEntity and (if provided) any customisation by using a name (for user representation) and a unique ID (for verification). A sample for customisation is a drive or a process automation device that was configured by a specific engineering tool. A Client can pass the following ExpectedVerificationVariable:
- PortableNodeIdentifier=“ApplicationIdentifier”,[0] Value =“537a9b43-5c84-4aaa-a105-a04fab2ba5b6” [1] Value=“827a9d43-8e86-6bcd-1256-b03fdc7ab9d3”.
Figure D.33 illustrates other items that might be validated.
Relative paths can also be used for verifying the FunctionalEntity. For example, a Client can 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.33.
