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:
- SubOperationalWarning is set to TRUE if at least one SubFunctionalEntity has OperationalWarning or SubOperationalWarning set to TRUE.
- SubOperationalError is set to TRUE if at least one SubFunctionalEntity has OperationalError or SubOperationalError set to TRUE.
- The lower 16 bits of OperationalHealth are set to the result of a logical OR of CommHealth in the ConnectionEndpoints Folder of the FunctionalEntity, and the lower 16 bits of the OperationalHealth of all SubFunctionalEntities.
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.