FunctionalEntityType is the base type for the definition of all functionality in an OPC UA FX Information Model. A FunctionalEntity can provide InputData, OutputData, ConfigurationData, diagnostic information and Methods for manipulating or sharing the data. It is expected that other models will subtype the FunctionalEntityType. It can have SubFunctionalEntities and relationships to other Objects defined in this model or other models. A FunctionalEntity may be implemented using the IFunctionalEntityType Interface. It does not need to be an instance of FunctionalEntityType or an instance of a subtype of FunctionalEntityType.

The FunctionalEntityType is illustrated in Figure 24.

image027.png

Figure 24 – FunctionalEntityType overview

The FunctionalEntityType is formally defined in Table 40. Most of this ObjectType is obtained from the I FunctionalEntityType Interface (see 7.2). The description of the components and properties in a FunctionalEntityType is in this clause; the I FunctionalEntityType only references this clause. For examples of extending FunctionalEntityType or utilising it in an existing model, see Annex B.

Table 40 – FunctionalEntityType definition

Attribute

Value

BrowseName

3:FunctionalEntityType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:BaseObjectType defined in OPC 10000-5

0:HasInterface

ObjectType

3:IFunctionalEntityType

Applied from IFunctionalEntityType

0:HasProperty

Variable

3:AuthorUri

0:UriString

0:PropertyType

O

0:HasProperty

Variable

3:AuthorAssignedIdentifier

0:String

0:PropertyType

O

0:HasProperty

Variable

3:AuthorAssignedVersion

3:FxVersion

0:PropertyType

O

0:HasProperty

Variable

3:ApplicationIdentifier

3:ApplicationIdentifierDataType[]

0:PropertyType

O

0:HasComponent

Method

3:Verify

Defined in 6.4.3

O

0:HasComponent

Object

3:InputData

3:InputsFolderType

O

0:HasComponent

Object

3:OutputData

3:OutputsFolderType

O

0:HasComponent

Object

3:ConfigurationData

3:ConfigurationDataFolderType

O

0:HasComponent

Object

3:Capabilities

3:FunctionalEntityCapabilitiesType

O

0:HasComponent

Object

3:PublisherCapabilities

3:PublisherCapabilitiesType

O

0:HasComponent

Object

3:SubscriberCapabilities

3:SubscriberCapabilitiesType

O

0:HasComponent

Object

3:ConnectionEndpoints

3:ConnectionEndpointsFolderType

O

0:HasComponent

Object

3:ControlGroups

3:ControlGroupsFolderType

O

0:HasComponent

Variable

3:OperationalHealth

3:OperationalHealthOptionSet

0:BaseDataVariableType

O, RO

0:HasComponent

Object

3:OperationalHealthAlarms

0:FolderType

O

3:HasSubFunctionalEntity

Object

3:<SubFunctionalEntity>

3:FunctionalEntityType

OP

ConformanceUnits

UAFX FunctionalEntity Base

The FunctionalEntityType is a base ObjectType. It is expected that companion specifications or vendors will define subtypes of FunctionalEntityType. Subtypes will define additional Variables that would exist in InputData, OutputData and ConfigurationData. The subtypes might also add Objects and Methods or define nested FunctionalEntityType instances. In addition, the information in the FunctionalEntityType may be directly used in an existing ObjectType, either via the AddIn concept or Interface concept defined in OPC 10000-3. For an illustration of how this can be accomplished, see B.3.

The optional AuthorUri is a string that is a URI that resolves to the website of the company that is responsible for this FunctionalEntity.

NOTE Multiple instances of FunctionalEntityType could reference the same instance of AuthorUri.

The optional AuthorAssignedIdentifier provides a unique code used to identify the author-defined type of this FunctionalEntity. This Property is maintained by the author. The semantics of the AuthorAssignedIdentifier is author-specific.

The optional AuthorAssignedVersion provides the version of this FunctionalEntity. The semantic of the AuthorAssignedVersion is author-specific. This identifier is provided to allow additional information beyond what the AuthorAssignedIdentifier provides. For example, some authors might have more than one version of the motor controller model or the PID controller algorithm.

The optional ApplicationIdentifier – provides application information consisting of two properties: a localized Name that is intended to be human-readable and a unique identifier that is intended to be machine-readable. For a definition of the ApplicationIdentifierDataType, see 10.3. The ApplicationIdentifier shall be used as follows:

  • Name provides the name of the application this FunctionalEntity is used in. The Name is given by the system integrator, manufacturer or end-user that created the application.
  • UniqueIdentifier provides a unique identifier for the application in which FunctionalEntity is used. UniqueIdentifier is maintained by the creator of the identifier. This field is of ApplicationId DataType to allow the creator to create any type of identifier. An ApplicationId DataType allows the field to contain a string, integer, GUID, or ByteString. It is up to the creator of the identifier to choose which of these types is used.

The optional ApplicationIdentifier is specified as an array since it may indicate multiple levels of application and thus have multiple values. For example, the product vendor of an advanced alarm control creates a FunctionalEntity and assigns to it an identifier. A system integrator customizes it with settings for boiler alarming and assigns an additional identifier. The end-user may further deploy an instance of the configured FunctionalEntity on “Boiler #5” and provide an additional identifier.

The optional InputData provides a grouping of information in this FunctionalEntity. It provides a reference to all data that this FunctionalEntity can use as input to its processing. The InputsFolderType is defined in 6.4.4.

The optional OutputData provides a grouping of information in this FunctionalEntity. It provides a reference to all data that this FunctionalEntity can use as output from its processing. The OutputsFolderType is defined in 6.4.5.

The optional ConfigurationData provides a grouping of information in this FunctionalEntity into a logical grouping of information that is considered configuration information (for additional information, see 5.4). The ConfigurationDataFolderType is defined in 6.4.6.

The optional Capabilities is a FunctionalEntityCapabilitiesType Folder that describes functionality provided by a FunctionalEntity (see 6.4.7).

The optional PublisherCapabilities provide the Publisher capabilities associated with this FunctionalEntity. They also apply to all sub-FunctionalEntities of this FunctionalEntity. The PublisherCapabilities for the FunctionalEntity describes additional restrictions of the PublisherCapabilities defined in the AutomationComponent. It can also be further restricted by the PublisherCapabilities provided in OutputData or a sub-FunctionalEntity.

The optional SubscriberCapabilities provide the Subscriber capabilities associated with this FunctionalEntity. They also apply to all sub-FunctionalEntities of this FunctionalEntity. The SubscriberCapabilities for the FunctionalEntity describes additional restrictions of the SubscriberCapabilities defined in the AutomationComponent. It can also be further restricted by the SubscriberCapabilities provided in InputData or a sub-FunctionalEntity.

NOTE   The PublisherCapabilities and SubscriberCapabilities on the FunctionalEntity level apply to data and heartbeats. PublisherCapabilities and SubscriberCapabilities on Output-/InputData level only apply for that data, i.e., not for heartbeats.

The ConnectionEndpoints Folder provides a container for all Connection-related information that this FunctionalEntity might contain. For details on the ConnectionEndpointsFolderType, see 6.4.8. For details on the ConnectionEndpointType that this Folder contains, see 6.6. If the FunctionalEntity does not expose ConnectionEndpoints, the Folder may be missing.

The ControlGroups Folder provides a container for all ControlGroupType instances this FunctionalEntity might contain. For the concepts, see 5.3. For details on the ControlGroupsFolderType, see 6.4.9. For details on the ControlGroupType that this Folder contains, see 6.5.

The optional OperationalHealth indicates the operational health of the FunctionalEntity. It aggregates the health of its SubFunctionalEntities and the health of ConnectionEndpoints. For the definition of the OperationalHealthOptionSet, see 10.30.

The aggregation rules are defined as follows:

All top-level FunctionalEntities shall implement OperationalHealth. The OperationalHealth of the top-level FunctionalEntities is aggregated into AggregatedOperationalHealth (see 9.1.2) Variable of the AggregatedHealth Variable in the AutomationComponent (see 6.2.2).

The optional OperationalHealthAlarms Folder shall be restricted to hold only instances of Alarms. No UAFX-specific Alarms are defined in this release, but base OPC UA Alarms can be used. In future versions of this document, UAFX-specific Alarms will be defined.

The optional <SubFunctionalEntity> allows for the nesting of FunctionalEntities. A FunctionalEntity can have any number of SubFunctionalEntities. SubFunctionalEntities are identified by the HasSubFunctionalEntity ReferenceType. They may be of FunctionalEntityType or another ObjectType that implements the IFunctionalEntityType Interface.

The Verify Method allows a Client to verify whether a FunctionalEntity meets the expectation of system engineering (e.g., whether it is of the expected author, but also if it implements any optional Variables required by a Client application). It also supports verifying any Variables defined by the application.

The signature of this Method is specified below; the arguments are defined in Table 41.

Signature

Verify (

[in] 2:NodeIdValuePair[] ExpectedVerificationVariables,

[out] 2:FunctionalEntityVerificationResultEnumVerificationResult,

[out] 0:StatusCode[] VerificationVariablesErrors

);

Table 41 – Verify Method arguments

Argument

Description

ExpectedVerificationVariables

An array of NodeIdValuePair containing verification variables. NodeId shall be the NodeId of the variable to verify and Value its expected value.

The following rules shall apply to the usage of NodeIdValuePair:

A Client may pass in any NodeId with a null Value to verify if the Node exists in the Server. The Node may be of any NodeClass, but only the NodeClass of Variable or VariableType can have a non-null value.

VerificationResult

The result of the verification; see 10.20 for a definition of the FunctionalEntityVerificationResultEnum.

The following general rules apply to determine VerificationResult:

  • All string-type variables shall be stripped of leading and trailing whitespaces before processing.

The following specific rules shall apply to determine VerificationResult:

VerificationVariablesErrors

An array of StatusCode corresponding to the ExpectedVerificationVariables input argument that indicates any errors (if VerificationResult equals NotSet) or detailed verification results (if VerificationResult equals Mismatch). If this array is populated, the length of this array shall match the length of ExpectedVerificationVariables. For possible values in this array, see Table 43.

The Method result codes are formally defined in Table 42.

Table 42 – Verify Method result codes

Result Code

Description

Bad_InvalidArgument

ExpectedVerificationVariables is empty.

Uncertain

There was at least one error or warning for one of the Variables to be verified. VerificationVariablesErrors will contain additional information.

The VerificationVariablesErrors StatusCodes are formally defined in Table 43.

Table 43 – VerificationVariablesErrors StatusCodes

Result Code

Description

Bad_TypeMismatch

The value supplied for the verification variable (if non-null) is not of the same type as the implemented verification variable.

Bad_NodeIdInvalid

The NodeIdValuePair contains a NodeId with an invalid syntax in its key field.

Bad_NodeIdUnknown

The NodeIdValuePair contains a NodeId in its key field that does not exist in the Server address space.

Bad_OutOfRange

The value supplied for the Variable is not equal to the actual value of the Variable (if non-null).

Bad_NothingToDo

The operation was skipped.

Verification of this variable was skipped because verification of preceding variables already resulted in VerificationResult to be set to Mismatch.

Good

The verification for this Variable succeeded.

The Verify Method representation in the AddressSpace is formally defined in Table 44.

Table 44 – Verify Method AddressSpace definition

Attribute

Value

BrowseName

3:Verify

References

Node Class

BrowseName

DataType

TypeDefinition

Other

0:HasProperty

Variable

0:InputArguments

0:Argument[]

0:PropertyType

M

0:HasProperty

Variable

0:OutputArguments

0:Argument[]

0:PropertyType

M

ConformanceUnits

UAFX IFunctionalEntity Verify

The InputsFolderType is a subtype of the FolderType defined in OPC 10000-5.

The InputsFolderType is formally defined in Table 45.

Table 45 – InputsFolderType definition

Attribute

Value

BrowseName

3:InputsFolderType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:FolderType defined in OPC 10000-5

0:HasComponent

Object

3:SubscriberCapabilities

3:SubscriberCapabilitiesType

O

3:HasInputGroup

Object

3:<InputGroup>

3:InputsFolderType

OP

0:Organizes

Variable

3:<InputVariable>

0:BaseDataType

0:BaseDataVariableType

OP

ConformanceUnits

UAFX FunctionalEntity Base

The InputsFolderType provides for the grouping of input variables. It shall be restricted to hold only Variables. The InputsFolder may be empty.

The optional SubscriberCapabilities shall only be present on InputData of the FunctionalEntity. It provides the Subscriber capabilities associated with the InputData and describes additional restrictions of the SubscriberCapabilities defined in the FunctionalEntity or AutomationComponent.

<InputsGroup> allows for the nesting of Folders. Nested instances can be used to create a structure of input groups.

The OutputsFolderType is a subtype of the FolderType defined in OPC 10000-5.

The OutputsFolderType is formally defined in Table 46.

Table 46 – OutputsFolderType definition

Attribute

Value

BrowseName

3:OutputsFolderType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:FolderType defined in OPC 10000-5

0:HasComponent

Object

3:PublisherCapabilities

3:PublisherCapabilitiesType

O

3:HasOutputGroup

Object

3:<OutputGroup>

3:OutputsFolderType

OP

0:Organizes

Variable

3:<OutputVariable>

0:BaseDataType

0:BaseDataVariableType

OP

ConformanceUnits

UAFX FunctionalEntity Base

The OutputsFolderType provides for the grouping of output variables. It shall be restricted to hold only Variables. The OutputsFolder may be empty.

The optional PublisherCapabilities shall only be present on OutputData of the FunctionalEntity. It provides the Publisher capabilities associated with the OutputData and describes additional restrictions of the PublisherCapabilities defined in the FunctionalEntity or AutomationComponent.

<OutputGroup> allows for the nesting of Folders. Nested instances can be used to create a structure of output groups.

The ConfigurationDataFolderType is used to organize ConfigurationData Variables and provides the Methods for supporting storage of Variables (see 5.4). A ConfigurationDataFolder may contain sub-Folders derived from FunctionalGroupType.

The ConfigurationDataFolderType is illustrated in Figure 25.

image028.png

Figure 25 – ConfigurationDataFolderType illustration

The ConfigurationDataFolderType extends the FunctionalGroupType defined in OPC 10000-100.

The ConfigurationDataFolderType is formally defined in Table 47.

Table 47 – ConfigurationDataFolderType definition

Attribute

Value

BrowseName

3:ConfigurationDataFolderType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the 5:FunctionalGroupType defined in OPC 10000-100

0:Organizes

Variable

3:<ConfigurationVariable>

0:BaseDataType

0:BaseDataVariableType

OP

0:HasComponent

Method

3:SetStoredVariables

Defined in 6.4.6.3

O

0:HasComponent

Method

3:ClearStoredVariables

Defined in 6.4.6.4

O

0:HasComponent

Method

3:ListStoredVariables

Defined in 6.4.6.5

O

ConformanceUnits

UAFX FunctionalEntity Base

<ConfigurationVariable > - represents the optional configuration data that this Folder can organize.

The optional Methods SetStoredVariables, ClearStoredVariables, and ListStoredVariables allow maintaining the storage for configuration Variables. If storage is supported, SetStoredVariables, ClearStoredVariables, and ListStoredVariables shall be supported.

The optional SetStoredVariables Method allows a Client to store current values of configuration Variables for the FunctionalEntity and its SubFunctionalEntities.

The FunctionalEntity shall apply the stored values to the configuration variables after a power cycle.

The signature of this Method is specified below; the arguments are defined in Table 48.

Signature

SetStoredVariables (

[in] 0:NodeId[] VariablesToStore,

[out] 0:StatusCode[]Results

);

Table 48 – SetStoredVariables Method arguments

Argument

Description

VariablesToStore

An array of NodeIds containing configuration data variables. NodeId shall be the NodeId of a configuration data variable belonging to ConfigurationData of this FunctionalEntity or one of its SubFunctionalEntities.

Results

An array of StatusCode corresponding to the VariablesToStore input argument that indicates any errors that occurred during the processing of VariablesToStore. If this array is populated, it has the same length as the VariablesToStore array. For possible values in this array, see Table 50.

The possible Method result codes are formally defined in Table 49.

Table 49 – SetStoredVariables Method result codes

Result Code

Description

Uncertain

There was at least one error while processing the Variables to be stored. Results will contain additional information.

The Results StatusCodes are formally defined in Table 50.

Table 50 – Results StatusCodes

Result Code

Description

Bad_InvalidArgument

The NodeId is not a ConfigurationData Variable or does not belong to this FunctionalEntity or one of its SubFunctionalEntities.

Bad_NotSupported

The NodeId specifies a Variable that is non-volatile.

Bad_ResourceUnavailable

There are not enough resources for storing this Variable.

Good

Storing this Variable succeeded.

The SetStoredVariables Method representation in the AddressSpace is formally defined in Table 51.

Table 51 – SetStoredVariables Method AddressSpace definition

Attribute

Value

BrowseName

3:SetStoredVariables

References

Node Class

BrowseName

DataType

TypeDefinition

Other

0:HasProperty

Variable

0:InputArguments

0:Argument[]

0:PropertyType

M

0:HasProperty

Variable

0:OutputArguments

0:Argument[]

0:PropertyType

M

ConformanceUnits

UAFX ConfigurationDataFolder VariableStorage

The optional ClearStoredVariables Method allows a Client to clear the Variable from the list of Variables that are to be restored.

The signature of this Method is specified below; the arguments are defined in Table 52.

Signature

ClearStoredVariables (

[in] 0:NodeId[] VariablesToClear,

[out] 0:StatusCode[]Results

);

Table 52 – ClearStoredVariables Method arguments

Argument

Description

VariablesToClear

An array of NodeId containing configuration data variables.

Results

An array of StatusCode corresponding to the VariablesToClear input argument that indicates any errors that occurred during the processing of VariablesToClear. If this array is populated, it has the same length as the VariablesToClear array. For possible values in this array, see Table 54.

The possible Method result codes are formally defined in Table 53.

Table 53 – ClearStoredVariables Method result codes

Result Code

Description

Uncertain

There was at least one error while processing the Variables to be cleared.

Results will contain additional information.

The Results StatusCodes are formally defined in Table 54.

Table 54 – Results StatusCodes

Result Code

Description

Bad_InvalidArgument

The NodeId is not a ConfigurationData Variable or does not belong to this FunctionalEntity or one of its SubFunctionalEntities.

Bad_NotSupported

The NodeId specifies a Variable that is non-volatile or does not have storage for the Variable.

Good

Clearing the storage for this Variable succeeded.

The ClearStoredVariables Method representation in the AddressSpace is formally defined in Table 55.

Table 55 – ClearStoredVariables Method AddressSpace definition

Attribute

Value

BrowseName

3:ClearStoredVariables

References

Node Class

BrowseName

DataType

TypeDefinition

Other

0:HasProperty

Variable

0:InputArguments

0:Argument[]

0:PropertyType

M

0:HasProperty

Variable

0:OutputArguments

0:Argument[]

0:PropertyType

M

ConformanceUnits

UAFX ConfigurationDataFolder VariableStorage

The optional ListStoredVariables Method allows a Client to list the Variables that are currently in storage.

The signature of this Method is specified below; the arguments are defined in Table 56.

Signature

ListStoredVariables (

[out] 2:NodeIdValuePair[] StoredVariables

);

Table 56 – ListStoredVariables Method arguments

Argument

Description

StoredVariables

An array of NodeIdValuePair. Key indicates a Variable belonging to ConfigurationData of this FunctionalEntity or one of its SubFunctionalEntities. Value indicates the stored value.

The ListStoredVariables Method representation in the AddressSpace is formally defined in Table 57.

Table 57 – ListStoredVariables Method AddressSpace definition

Attribute

Value

BrowseName

3:ListStoredVariables

References

Node Class

BrowseName

DataType

TypeDefinition

Other

0:HasProperty

Variable

0:OutputArguments

0:Argument[]

0:PropertyType

M

ConformanceUnits

UAFX ConfigurationDataFolder VariableStorage

The FunctionalEntityCapabilitiesType extends the FolderType defined in OPC 10000-5. It shall be restricted to hold only Variables that reflect the capabilities of the FunctionalEntity.

The FunctionalEntityCapabilitiesType is formally defined in Table 58.

Table 58 – FunctionalEntityCapabilitiesType definition

Attribute

Value

BrowseName

3:FunctionalEntityCapabilitiesType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:FolderType defined in OPC 10000-5

3:HasCapability

Variable

3:<Capability>

0:BaseDataType

0:BaseDataVariableType

OP

3:HasCapability

Variable

3:FeedbackSignalRequired

0:Boolean

0:BaseDataVariableType

O

ConformanceUnits

UAFX FunctionalEntity Base

<Capability> - is a placeholder to indicate that additional capabilities may be added by this document or by a companion specification at any time. These capabilities shall include a Description.

If the optional FeedbackSignalRequired is present and set to TRUE, the FunctionalEntity requires a feedback signal for all Connections. A feedback signal is represented by the reception of either data or a heartbeat. The following connection types (see 5.5.1) support feedback: bidirectional, unidirectional with heartbeat, unidirectional Subscriber, and autonomous Subscriber. If FeedbackSignalRequired is missing or set to FALSE, the connection types unidirectional Publisher and autonomous Publisher are also supported.

The ConnectionEndpointsFolderType extends the FolderType defined in OPC 10000-5. It shall be restricted to hold only instances of ConnectionEndpointType or subtypes of ConnectionEndpointType. It may be empty.

The ConnectionEndpointsFolderType is formally defined in Table 59.

Table 59 – ConnectionEndpointsFolderType definition

Attribute

Value

BrowseName

3:ConnectionEndpointsFolderType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:FolderType defined in OPC 10000-5

HasConnectionEndpoint

Object

3:<ConnectionEndpoint>

3:ConnectionEndpointType

OP

0:HasComponent

Variable

3:CommHealth

3:CommHealthOptionSet

0:BaseDataVariableType

O, RO

ConformanceUnits

UAFX FunctionalEntity Base

The optional CommHealth aggregates the Status of all ConnectionEndpoints contained in the Folder. The aggregation rules are defined as follows:

For the definition of the CommHealthOptionSet, see 10.9.

The ControlGroupsFolderType extends the FolderType defined in OPC 10000-5. It shall be restricted to hold only instances of ControlGroupType (see 6.5). The ControlGroupsFolder may be empty.

The ControlGroupsFolderType is formally defined in Table 60.

Table 60 – ControlGroupsFolderType definition

Attribute

Value

BrowseName

3:ControlGroupsFolderType

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Other

Subtype of the 0:FolderType defined in OPC 10000-5

3:HasControlGroup

Object

3:<ControlGroup>

3:ControlGroupType

OP

ConformanceUnits

UAFX FunctionalEntity Base